pnpm 12로 바꾼 뒤 Dependabot 알림이 사라졌다면

업데이트 PR이 와도 보안 탐지가 정상이라는 뜻은 아니다

pnpm 12 전환 뒤 Dependabot 경고가 사라졌다면, 취약점이 고쳐졌는지보다 먼저 탐지 대상이 빠졌는지 확인해야 한다. GitHub는 10월 20일 지원 확대 공지에 잠금 파일이 YAML 문서 두 개로 쓰일 때의 제한을 명시했다. 버전 업데이트는 작동하지만 의존성 그래프가 해당 파일의 의존성을 감지하지 못해, 보안 알림·보안 업데이트가 생성되지 않고 기존 알림도 닫힐 수 있다.

개발자들이 궁금해한 지점도 이 차이였다. dependabot-core 이슈에서는 10월 21일 지원 발표 후 복수 문서 형식도 제대로 읽는지 묻는 질문이 나왔다. 업데이트 봇의 지원과 GitHub 의존성 그래프의 지원을 같은 상태로 받아들이기 쉬운 상황이다.

파일 하나에 YAML 문서가 둘 들어갈 수 있다

pnpm 공식 형식 문서에 따르면 두 문서 형식에서는 앞쪽에 pnpm 버전·설정 의존성을 담은 boot 문서가 오고, 마지막에 프로젝트의 의존성 목록이 온다. 두 문서는 같은 lockfileVersion을 사용할 수 있다. 버전 숫자만 보고 기존 형식과 같다고 판단할 수 없는 이유다.

pnpm 버전을 고정한 pnpm 12 프로젝트에서는 이 형식을 만나기 쉽다. 확인할 것은 ‘pnpm 12를 쓰는가’에서 끝나지 않는다. 실제 생성된 pnpm-lock.yaml이 어떤 문서를 포함하고, 프로젝트 패키지가 어느 문서에 있는지까지 봐야 한다.

첫 문서에도 패키지가 있으므로 목록이 완전히 비어 있지 않다는 사실만으로 파싱 성공을 판단하기도 어렵다. pnpm 자신의 실행에 필요한 패키지만 보이는 경우와 앱이 쓰는 패키지까지 보이는 경우를 구분해야 한다.

Dependabot라는 이름 아래 서로 다른 세 기능이 있다

버전 업데이트는 취약점 유무와 관계없이 오래된 의존성을 새 버전으로 바꾸는 PR을 만든다. 저장소의 dependabot.yml이 검사할 파일 위치와 업데이트 동작을 정한다. 따라서 버전 업데이트 PR이 도착했다는 사실은 그 경로가 작동한다는 증거다.

Dependabot 알림은 기본 브랜치를 검사하며, 새로운 보안 권고가 등록되거나 의존성 그래프가 달라질 때 생성된다. 보안 업데이트는 그래프의 취약 의존성에 대한 알림을 바탕으로 수정 가능한 버전으로 올리는 PR을 시도한다. 의존성 그래프에서 패키지가 빠지면 해당 패키지의 보안 알림과 수정 PR도 누락될 수 있다.

경고 숫자보다 패키지명과 버전을 대조한다

확인은 실제 파일과 탐지된 목록을 나란히 보는 데서 시작한다. 저장소의 Insights → Dependency graph에서 의존성을 검색하면 버전과 해당 항목의 출처 파일을 볼 수 있다. 기본 브랜치의 잠금 파일에 있는 프로젝트 의존성이 그 화면에도 나타나는지 대조한다.

1. pnpm 전환 커밋에서 잠금 파일이 두 문서 형식으로 바뀌었는지 본다.
2. 그 파일에 있는 앱 패키지를 이름으로 검색하고, 표시된 버전·출처 파일을 맞춰 본다.
3. 닫힌 보안 알림의 패키지가 실제로 수정 버전으로 올라갔는지 변경 내역을 확인한다.

이 순서는 알림 개수 대신 탐지 범위와 실제 변경을 확인하기 위한 것이다. 예를 들어 경고가 닫혔는데 같은 취약 버전이 잠금 파일에 남아 있다면, 그 종료를 패치 완료 실적으로 집계할 수 없다.

업그레이드 완료의 기준은 PR이 계속 오는지가 아니라, 사용 중인 의존성이 보안 탐지에도 들어오는지다. 누락이 확인되면 공식 지원 상태와 파일 형식 문제를 해결한 뒤 패키지 목록을 다시 대조해야 한다. 알림 0개라는 결과만으로 보안 점검을 끝내서는 안 된다.