Dependabot API 버전 필드 추가: 기록된 값과 실제 배포 버전을 구분하기

보안 티켓에 패키지 이름과 취약 범위만 있으면 담당자는 우리 저장소가 어떤 버전을 쓰는지 다시 조사해야 한다. GitHub는 2026년 10월 20일 Dependabot 경고 REST API에 dependency.version_requirement를 추가했다. 연동 도구가 참고할 값이 생겼지만 이 문자열을 현재 운영 서버에 설치된 정확한 버전이라고 부르면 새로운 오판을 만들 수 있다. 이번 글은 공식 기능의 범위와 팀이 선택할 검증 절차를 구분한다.

취약 범위와 저장소 기록은 다른 열이다

기존 응답의 vulnerable_version_range는 권고가 설명하는 취약한 버전 범위다. 새 필드는 Dependabot이 해당 경고에서 마지막으로 기록한 의존성 버전 또는 제약 조건이다. 둘을 같은 열에 덮어쓰지 않는다. 티켓에는 패키지·생태계·manifest_path와 함께 각각의 값을 표시한다. 예를 들어 허용 범위 문자열을 단일 설치 버전처럼 정렬하면 조사 우선순위가 잘못 바뀔 수 있다. 표시 이름부터 “기록된 버전/조건”으로 정하면 검토자가 출처를 다시 묻게 된다.

탐지 경로에 따라 값의 의미가 달라진다

공식 공지는 lockfile에서는 해석된 버전, lockfile 없는 manifest에서는 선언된 버전 또는 제약, dependency submission API에서는 빌드 도구가 제출한 해석된 버전이라고 설명한다. REST의 단일 경고·저장소·조직·엔터프라이즈 목록과 dependabot_alert webhook에 제공된다. github.com과 데이터 레지던시를 사용하는 Enterprise Cloud에서 이용 가능하며 Enterprise Server 3.24에 포함될 예정이다. 이 일정이 기존 Server의 지원을 뜻하지는 않는다. 사용 중인 호스트와 응답을 먼저 대조한다.

null과 여러 버전을 정상 입력으로 다루기

값이 없으면 null이며, 한 경고가 여러 취약 버전을 다루면 기록된 한 값만 담아 전체를 대표하지 못할 수 있다. 긴 제약 조건은 잘릴 수도 있다. 아래는 팀 운영 제안이다. 동기화 파서는 문자열과 null을 모두 보존하고, 알 수 없음을 안전함으로 바꾸지 않는다. 기존에 만든 티켓도 새 필드를 받지 못할 수 있으므로 누락 상태를 별도로 표시한다. 보안 경고 수가 같다는 사실만으로 버전 정보가 완전하다고 판단하지 않는다.

연동 변경은 대표 경고로 작게 검증한다

대표 저장소에서 응답 원본의 비밀을 제거하고 수집 시각·경고 번호·manifest 경로·기록된 값을 함께 남긴다. lockfile 기반, manifest 제약 기반, null 응답을 티켓 화면까지 보내 의미가 유지되는지 확인한다. webhook과 목록을 함께 소비한다면 같은 경고가 두 티켓이 되지 않도록 저장소와 경고 식별자를 대조한다. 권한은 사용하는 엔드포인트 문서대로 확인하고 테스트 편의를 위해 일괄 확대하지 않는다. 이는 권장 운영 절차이며 새 제품 보장이나 자동 수정 기능이 아니다.

현재 배포 증거가 필요하면 별도 빌드·배포 기록을 확인한다. 의존성 업데이트 뒤에는 기존 테스트와 경고 상태도 다시 읽는다. 새 필드가 조사 왕복을 줄일 수는 있어도 모든 환경의 현재 설치 버전을 증명하지는 않는다. 연동을 단순화할 여지가 있다는 이유만으로 기존의 배포 검증까지 삭제할 필요는 없다. 오늘의 완료 기준은 필드가 보인다는 화면이 아니라 null·제약·대표 버전이 티켓에서 구별되고 담당자가 다음 확인 대상을 알 수 있다는 것이다.

공식 출처

GitHub Changelog · Dependency versions

GitHub Docs · Dependabot alerts REST API

2026년 10월 21일 확인 기준. 대표 경고 하나에서 API 응답과 보안 티켓의 버전 표시를 함께 확인해 보자.