Dependabot에 버전 필드 추가, null은 안전하다는 뜻일까?

취약한 범위와 우리 저장소의 기록값이 나뉜다

Dependabot 알림을 외부 도구로 옮길 때, 취약점이 영향을 주는 버전 범위만으로는 저장소에서 어떤 버전이 발견됐는지 알기 어려웠다. 이번 GitHub 변경은 dependency.version_requirement에 Dependabot가 해당 알림에 대해 마지막으로 기록한 버전 또는 제약을 제공한다.

이제 그 값을 가져오기 위해 별도로 lockfile을 해석하거나 GraphQL의 vulnerableRequirements를 요청할 필요가 줄어든다. 다만 이름에 version이 들어간다고 항상 설치된 버전 하나를 뜻하지는 않는다.

REST 응답에는 취약 범위를 나타내는 security_vulnerability.vulnerable_version_range와 최초 수정 버전 정보인 first_patched_version도 있다. 저장소에서 기록한 값, 알려진 취약 범위, 수정 버전은 서로 다른 질문에 답한다.

lockfile이 있느냐에 따라 값의 의미가 달라진다

같은 필드라도 Dependabot가 의존성을 발견한 경로에 따라 고정 버전 또는 선언된 조건이 들어간다.

의존성 그래프는 저장소의 manifest·lockfile과 별도로 제출된 의존성 정보를 모은다. 따라서 대시보드 열 이름을 무조건 ‘현재 설치 버전’으로 붙이면 선언된 범위까지 설치 결과로 오해하기 쉽다. ‘기록된 버전·제약’처럼 값의 성격을 드러내는 이름이 적절하다.

null은 값이 없다는 뜻이며, 버전 하나가 전부는 아니다

GitHub는 값을 제공할 수 없을 때 null을 반환한다고 설명한다. 취약점이 없거나 수정됐다는 상태값이 아니다. 한 알림이 여러 취약 버전을 포함하면 필드에는 기록값 하나가 들어가므로, 다른 취약 버전까지 모두 보여 준다고 해석해서도 안 된다. 긴 버전 제약은 잘릴 수 있다.

운영 서버의 현재 상태와도 구분해야 한다. Dependabot 알림 문서는 기본 브랜치를 검사하며 새 취약점 정보나 의존성 그래프 변화에 따라 알림을 만든다고 설명한다. 저장소의 기록값을 읽는 기능을 실행 중인 서버의 패키지를 조회하는 기능으로 바꿔 읽을 수는 없다.

예를 들어 보안 대시보드가 null을 빈 문자열로 바꾼 뒤 ‘영향 없음’으로 표시하면, 알 수 없는 값을 안전하다는 결론으로 바꾸는 셈이다. 값이 없다는 상태를 그대로 보존하고, 알림의 state와 구분해 표시해야 한다.

REST와 웹훅 모두에서 받을 수 있다

새 필드는 알림 단건 조회와 저장소·조직·엔터프라이즈 목록, dependabot_alert 웹훅에 포함된다. github.com과 데이터 레지던시를 사용하는 GitHub Enterprise Cloud에서 제공되며, GitHub Enterprise Server에는 3.24에 포함될 예정이다.

연동 권한은 여전히 필요하다. 웹훅 문서에 따르면 GitHub App이 이 이벤트를 구독하려면 저장소의 Dependabot alerts에 최소 읽기 권한이 있어야 한다.

대시보드에 적용한다면 패키지명·manifest_path·기록값·알림 상태를 함께 표시하는 구성이 유용하다. 같은 패키지 이름이라도 어느 파일에서 나온 값인지 확인할 수 있고, 버전 문자열과 처리 상태를 혼동하지 않게 된다. 수정 확인은 해당 의존성의 변경과 실제 배포 확인으로 이어져야 한다.

자주 묻는 질문

새 필드는 알림을 외부 도구로 옮길 때 필요한 조회를 줄인다. 그 값이 어디서 왔는지 보존해야 연동 결과도 정확해진다.