Dependabot 경고가 사라지고 410이 뜬다면, 수정 완료일까?

410은 패치 성공 응답이 아니다

저장해 둔 Dependabot 경고 번호를 조회했는데 410 Gone이 돌아왔다면, 그 응답을 ‘수정 완료’로 기록하면 안 된다. GitHub는 10월 13일 변경에서 근거가 된 보안 권고나 취약성이 더 이상 유효하지 않을 때 경고를 철회하고 제거한다고 설명했다.

이전에는 철회된 경고를 읽거나 수정하려 하면 404가 반환됐다. 이제 이 경우 410을 반환해 애초에 없던 경고와 구분할 수 있게 됐다. REST 참조 문서의 단건 GET과 PATCH 응답표에도 410이 들어 있다.

적용 대상은 /repos/OWNER/REPO/dependabot/alerts/ALERT_NUMBER처럼 경고 하나를 지정하는 요청이다. 외부 도구에서 이 응답을 일반적인 조회 실패와 한 묶음으로 처리하면, 경고가 왜 사라졌는지 알 수 있는 새 정보를 버리게 된다.

경고를 닫는 사유를 하나로 합치지 않는다

수정과 해제는 원래도 다른 처리다. GitHub의 경고 관리 안내는 안전한 의존성 버전으로 바꾸는 작업과, 평가한 경고를 사유와 함께 해제하는 작업을 구분한다. 수정하지 않은 해제 경고는 나중에 다시 열 수도 있다.

이 표의 외부 기록 방식은 연동 설계에 적용할 구분이다. withdrawn을 경고 수정 API의 상태값으로 보내라는 뜻은 아니다. 경고가 목록에 없다는 이유만으로 수정 건수를 올리면 해제·철회·조회 문제까지 패치 성과로 섞이게 된다.

삭제되기 전 식별자를 웹훅으로 받는다

dependabot_alert 이벤트에는 새 withdrawn 액션이 추가됐다. 경고 제거 전에 확보한 경고 번호, GHSA·CVE 식별자, 패키지와 manifest 경로가 전달된다. 외부 티켓과 연결할 정보를 경고 재조회에만 의존하지 않아도 되는 변화다.

기존에 이 이벤트를 구독하고 있다면 새 액션도 자동으로 전달된다. 수신 쪽이 알고 있는 액션만 처리하도록 구성돼 있다면 withdrawn이 무시되지 않는지 확인할 필요가 있다. GitHub App의 구독 조건은 저장소 Dependabot alerts에 대한 최소 읽기 권한이다.

GitHub는 github.com의 모든 저장소에서 이 변경을 제공하며 Enterprise Server에는 3.24에 포함할 예정이라고 밝혔다. 자체 운영 서버를 쓰는 팀은 github.com 공지와 설치 버전의 지원 범위를 구분해야 한다.

외부 티켓에는 ‘왜 끝났는가’를 남긴다

외부 연동에서는 저장소와 경고 번호로 기존 티켓을 찾고, 전달된 권고 식별자·패키지·파일 경로를 함께 보존하는 흐름을 적용할 수 있다. 그 뒤 종료 사유를 ‘철회’로 기록하면 나중에 패치 PR이 없는 이유를 설명할 수 있다.

정기 조회 도중 410을 만났을 때도 같은 구분을 사용한다. 403이나 404라면 먼저 조회 조건을 확인하고, 기존 티켓을 곧바로 ‘수정됨’으로 닫지 않는다. 같은 경고의 조회 상태와 보안 처리 상태를 따로 보관하면 둘을 혼동하지 않는다.

패치가 필요한 경고라면 작업은 여전히 의존성 변경으로 이어져야 한다. Dependabot가 제공하는 저장소 경고와 운영 환경에 배포한 결과도 구분해야 한다. 새 410 응답의 가치는 수정 건수를 늘리는 데 있지 않고, 없어진 경고의 종료 사유를 정확히 남기는 데 있다.