GitHub Dependabot, 철회 경고를 웹훅 withdrawn과 API 410으로 구분

경고가 사라진 이유를 외부 도구에도 전달

깃허브는 10월 13일 철회된 디펜다봇 경고를 외부 연동 도구에서 더 쉽게 감지하도록 웹훅과 REST API를 개선했다. 경고의 근거가 된 보안 자문이나 취약점이 더 이상 유효하지 않으면 디펜다봇은 경고를 철회하고 제거한다. 이번 변경은 그 제거 사실을 단순한 조회 실패와 구분하는 데 초점을 맞춘다.

취약한 의존성을 업데이트해 해결한 경우와 근거 자체가 무효화된 경우는 다른 이력이다. 대시보드에서 열린 경고 수가 줄었다는 결과만 합산하면 코드 수정 성과와 자문 정정 효과가 섞일 수 있다. 철회 신호를 별도로 남기면 외부 보안 현황도 이 둘을 구별할 수 있다. 이는 공개된 제거 조건에 근거한 운영상 해석이다.

기존 구독에 withdrawn 동작이 추가된다

dependabot_alert 웹훅에는 withdrawn 동작이 추가된다. 전달 본문에는 경고를 제거하기 전에 확보한 경고 번호, GHSA·CVE 식별자, 패키지, 매니페스트 경로 같은 정보가 들어간다. 이미 이 이벤트를 구독하고 있다면 별도 이벤트 구독을 추가하지 않아도 새 전달을 받는다.

구독이 유지된다는 것과 수신 프로그램이 새 동작을 처리한다는 것은 다르다. 공식 권장 사항은 X-GitHub-Event 헤더로 이벤트 종류를, 본문의 최상위 action으로 동작을 확인하라고 안내한다. 기존 코드가 알고 있는 동작만 처리한다면 withdrawn을 무시할 수 있으므로 처리 분기와 기록 상태를 함께 점검해야 한다.

삭제 이후 재조회 대신 식별 정보를 보존한다

새 본문이 제거 전 식별자를 포함한다는 점은 연동 설계에서 유용하다. 웹훅을 받은 뒤 항상 원본 경고를 다시 조회해 정보를 보강하던 방식은 철회된 경고에 대해서는 기대한 상세 응답을 얻지 못할 수 있다. 저장소와 경고 번호를 기준으로 기존 기록을 찾고, 전달된 패키지·매니페스트와 자문 식별자를 철회 이력에 연결하는 방식이 타당하다.

공식 이벤트 문서는 깃허브 앱이 dependabot_alert를 구독하려면 저장소의 Dependabot alerts 권한을 최소 읽기 수준으로 받아야 한다고 설명한다. 새 동작의 자동 전달이 앱의 저장소 접근 범위나 보안 경고 권한을 자동 확대하는 것은 아니다.

조회와 수정은 410 Gone을 별도 처리한다

철회된 경고의 조회나 수정 요청은 이전의 404 Not Found 대신 410 Gone을 반환한다. 공식 REST 문서도 두 엔드포인트의 응답 상태에 410을 명시한다. 조회는 GET, 수정은 PATCH이며 저장소 소유자·저장소 이름·경고 번호로 대상을 지정한다. 세분화된 토큰 기준으로 조회에는 Dependabot alerts 읽기, 수정에는 쓰기 권한이 필요하다.

운영 도구는 410을 일시적인 장애로 보고 무한 재시도하기보다 철회 기록을 반영하는 분기로 처리할 수 있다. 다만 모든 404가 철회라는 뜻은 아니다. 새 상태는 확인된 철회를 구별하는 신호이므로, 다른 응답의 원인을 이 상태와 합쳐 추정해서는 안 된다.

경고 철회 처리도 서명과 재전송을 고려해야

철회 이벤트가 외부 보안 대시보드의 상태를 바꾼다면 수신 요청의 출처 검증이 중요하다. 깃허브의 공식 절차는 웹훅 비밀값과 전달 본문으로 계산한 HMAC-SHA256 값을 X-Hub-Signature-256 헤더의 서명과 비교하는 방식이다. 프록시에서 본문을 바꾸면 검증이 실패할 수 있으므로 처리 전 원래 내용을 기준으로 검증해야 한다.

전달 식별자인 X-GitHub-Delivery는 재전송 때도 원래 값이 유지된다. 같은 전달을 다시 받아도 철회 처리와 집계가 중복되지 않도록 구성할 수 있다는 의미다. 빠른 수신 응답 뒤 비동기로 처리하는 구조를 쓴다면, 응답 성공과 실제 상태 반영 완료를 구분해 추적하는 것이 유용하다. 이는 서명 검증 및 재전송 문서를 연동 상황에 적용한 제안이다.

클라우드 전체 저장소와 서버 버전의 차이

이번 변경은 깃허브닷컴의 모든 저장소에 제공되며 Enterprise Server에는 3.24에 포함될 예정이다. 자체 서버 사용자는 클라우드의 새 웹훅이나 410 응답을 기존 서버에서도 즉시 받을 것으로 가정할 수 없다. 연동 도구가 양쪽 환경을 지원한다면 서버 버전에 따른 응답 차이를 유지하면서, 새 환경에서 철회 상태가 정상적으로 전달되고 보존되는지 확인해야 한다. 개선의 핵심은 경고를 더 많이 만드는 것이 아니라 경고가 사라지는 이유를 정확히 동기화하는 데 있다.