Dependabot에서 PAT를 지울 수 있다…단, 권한 설정은 남는다

GitHub는 2026년 9월 8일 Dependabot이 비공개 GitHub Packages를 개인 액세스 토큰(PAT) 없이 읽는 기능을 재활성화했다. GitHub의 9월 8일 변경 공지 에 따르면 Dependabot 작업은 자체 GITHUB_TOKEN으로 패키지 읽기 권한을 요청하며, 조건을 충족한 패키지에 추가했던 PAT 기반 레지스트리 항목은 제거할 수 있다.

9월 8일 재활성화의 범위는 GitHub가 호스팅하고 Dependabot이 지원하는 패키지 레지스트리다. 독립적인 개발 도구 요약 도 같은 변경과 함께 패키지 설정의 Manage Actions access에서 Dependabot 실행 저장소에 Read 권한을 부여해야 한다는 조건을 확인했다. 따라서 없어지는 것은 해당 패키지의 PAT 인증이지, 저장소별 접근 통제 자체가 아니다.

자동 접근은 기존 권한을 재사용한다

새 방식에서 Dependabot은 작업에 발급된 GITHUB_TOKEN으로 packages: read 권한을 요청한다. 작업이 *.pkg.github.com 또는 ghcr.io에서 패키지를 가져올 때 이 토큰을 보내고, 대상 패키지가 저장소에 이미 허용한 Actions 접근 권한을 이용한다. 적용 대상은 Dependabot이 지원하는 GitHub Packages 생태계이며, 지원하지 않는 패키지 형식까지 새로 포함한다는 발표는 아니다.

이 토큰은 모든 레지스트리 요청을 강제로 가로채는 기본 자격 증명이 아니라 대체 인증 수단으로 작동한다. 명시적으로 설정한 레지스트리 자격 증명과 정상적인 레지스트리 경로가 먼저 적용되고, 자동 GitHub Packages 인증은 그 뒤에서 사용된다. 이는 일부 npm 업데이트 작업이 공개 패키지를 GitHub Packages를 통해 해석했던 충돌을 피하기 위해 재활성화 버전에 추가된 경계다.

이번 기능은 2026년 6월 23일 처음 출시된 뒤 해당 npm 충돌이 발견돼 일시적으로 되돌려졌다. 9월 8일 공지는 문제의 원인을 공개하고 fallback 방식으로 기능을 다시 켰다고 명시한다. 따라서 현재 상태는 최초 예고나 제한된 시험이 아니라, 인증 우선순위를 수정한 기능의 재출시다.

Manage Actions access의 Read 권한은 남는다

PAT를 제거하기 전에 확인할 곳은 Dependabot 설정 화면만이 아니라 각 패키지의 설정 화면이다. 조직 또는 개인 계정의 Packages 탭에서 대상 패키지를 열고, Manage Actions access에 Dependabot 작업이 실행되는 저장소를 추가한 뒤 역할을 Read로 지정해야 한다. Dependabot이 여러 비공개 패키지를 읽는다면 이 설정은 필요한 패키지마다 확인해야 한다.

Read 권한은 패키지 다운로드와 메타데이터 조회에 필요한 범위다. 패키지를 게시한 저장소와 이를 소비하는 저장소가 다를 때는 두 저장소가 같은 조직에 속한다는 사실만으로 접근이 자동 허용된다고 볼 수 없다. 권한의 대상은 사용자나 팀이 아니라 Dependabot이 실행되는 소비 저장소이며, 그 저장소가 패키지의 Manage Actions access 목록에 들어 있어야 한다.

패키지의 기존 권한 모델도 함께 봐야 한다. 저장소에 연결된 패키지가 연결 저장소의 권한을 상속하는 경우와, 사용자·조직 범위에서 별도 권한을 관리하는 경우는 접근 관계가 다르다. 핵심 판단 기준은 패키지가 비공개인지 여부만이 아니라 해당 패키지가 실제 Dependabot 실행 저장소에 Read 접근을 허용했는지다.

• 의존성이 GitHub Packages 또는 GitHub Container Registry에 저장돼 있는지 확인한다.
• 해당 패키지 생태계를 Dependabot이 지원하는지 확인한다.
• 각 패키지의 Manage Actions access에 실제 소비 저장소가 등록돼 있는지 확인한다.
• 그 저장소의 역할이 Read 이상인지 확인한다.

dependabot.yml에서는 PAT 항목만 골라내야 한다

조건을 충족한 GitHub 호스팅 패키지는 새 자동 접근을 위해 dependabot.yml에 별도 항목을 추가할 필요가 없다. 제거할 수 있는 것은 이 패키지의 인증을 위해 추가했던 PAT 기반 레지스트리 정의와 그 정의만을 가리키는 참조다. 업데이트 일정, 대상 디렉터리, package-ecosystem 같은 Dependabot 작업 자체의 설정까지 지우라는 의미는 아니다.

구성 파일의 최상위 registries에는 여러 레지스트리의 인증 정보가 함께 정의될 수 있고, 개별 updates 블록은 특정 이름이나 registries: "*"로 이를 불러올 수 있다. 따라서 GitHub Packages용 항목을 삭제하기 전 어떤 업데이트 블록이 그 이름을 참조하는지 확인해야 한다. 별도 레지스트리 라우팅을 위해 남겨야 할 설정을 PAT와 함께 없애면 패키지가 예상한 주소에서 해석되지 않을 수 있다.

1. registries에서 *.pkg.github.com 또는 ghcr.io를 가리키며 PAT secret을 쓰는 정의를 찾는다.
2. 각 updates 블록의 레지스트리 참조와 패키지 경로를 확인한다.
3. 대상 패키지에 소비 저장소의 Read 권한을 먼저 부여한다.
4. GitHub Packages 인증에만 쓰인 PAT 정의와 불필요해진 참조를 제거한다.
5. 이후 Dependabot 작업이 비공개 의존성을 정상적으로 조회하는지 확인한다.

저장소나 조직에 저장된 secret의 삭제는 별개의 판단이다. 같은 PAT를 다른 Dependabot 레지스트리, GitHub Actions 워크플로 또는 외부 자동화가 참조한다면 구성 파일에서 한 항목을 제거해도 secret의 사용처는 남아 있다. 다른 참조가 없다는 사실을 확인한 뒤 폐기해야 제목의 ‘PAT를 지운다’는 결과가 안전하게 성립한다.

외부 비공개 레지스트리의 인증은 그대로다

이번 자동 접근은 GitHub가 호스팅하는 지원 대상 패키지에 한정된다. Docker Hub의 비공개 저장소, Private Packagist, 자체 운영 레지스트리와 다른 공급자의 아티팩트 저장소가 동일한 GITHUB_TOKEN으로 자동 개방되는 것은 아니다. GitHub Packages용 PAT를 정리하면서 이들 레지스트리의 자격 증명까지 지우면 Dependabot은 외부 의존성을 가져오지 못할 수 있다.

Dependabot 비공개 레지스트리 문서 는 외부 레지스트리에 토큰, 사용자 이름과 비밀번호 또는 지원되는 OIDC 인증을 구성할 수 있다고 설명한다. dependabot.yml을 사용하는 경우 최상위 registries에서 인증 정보를 정의하고 updates 블록에서 사용할 레지스트리를 연결하는 구조도 계속 유효하다.

PAT가 불필요해지는 작업 범위 역시 Dependabot의 해당 패키지 읽기다. 개발자가 로컬 명령줄에서 패키지를 설치하거나, 별도 배포 시스템과 다른 자동화가 패키지를 가져오는 데 필요한 인증은 각 실행 환경의 권한에 따라 남을 수 있다. 하나의 PAT를 여러 작업이 공유했다면 Dependabot 전환만으로 토큰 전체를 즉시 폐기할 수 없는 이유다.

현재 확인된 변화는 비공개 GitHub Packages에 허용된 저장소 권한을 Dependabot이 재사용한다는 것이다. 해당 패키지용 PAT 항목은 제거할 수 있지만 패키지별 Read 허가, 정상적인 레지스트리 경로와 외부 레지스트리 인증은 계속 필요하다. 재출시 버전에서는 명시적 자격 증명과 기존 라우팅이 자동 인증보다 우선한다.

함께 읽기:

• Google ‘내 활동’ 자동 삭제, 브라우저 기록은 그대로 남는다