Dependabot가 업데이트를 3일 기다린다: 공급망 공격을 늦추는 기본값

새 라이브러리가 공개되자마자 자동 업데이트 풀 리퀘스트가 열리는 속도는 개발팀의 유지보수를 편하게 만들었습니다. 하지만 패키지 계정 탈취나 악성 릴리스가 발생하면 그 속도가 공격 코드의 유입 경로가 될 수도 있습니다. GitHub는 이 위험을 줄이기 위해 Dependabot 일반 버전 업데이트에 기본 3일 대기 시간을 적용했습니다.

무엇이 바뀌었나

Dependabot은 이제 패키지 레지스트리에 새 버전이 등록된 뒤 최소 3일이 지나야 일반 버전 업데이트 풀 리퀘스트를 만듭니다. 별도 설정을 추가하지 않아도 GitHub.com에서 지원하는 패키지 생태계에 기본 적용되며, GitHub Enterprise Server에서는 3.23부터 적용될 예정입니다.

중요한 예외가 있습니다. 이번 대기 시간은 기능 개선이나 버그 수정 같은 버전 업데이트에만 적용됩니다. 알려진 취약점을 해결하는 보안 업데이트는 기존처럼 즉시 열립니다. 긴급 패치를 늦추지 않으면서 새 릴리스가 충분히 검증되기 전 자동 유입되는 위험만 줄이려는 구분입니다.

왜 하필 3일인가

소프트웨어 공급망 공격은 새 버전이 배포된 직후의 짧은 틈을 노립니다. 유지관리자 계정이 탈취되거나 배포 파일이 오염되더라도 저장소와 커뮤니티가 이상을 발견하고 패키지를 철회하기까지 시간이 필요합니다. 자동 업데이트가 새 버전을 즉시 가져오면 사람과 보안 도구가 경고 신호를 만들기 전에 악성 코드가 개발·배포 파이프라인으로 들어갈 수 있습니다.

3일은 모든 위험을 제거하는 보증 기간이 아닙니다. 다만 릴리스 직후의 가장 불확실한 구간을 피하고, 유지관리자와 보안 연구자, 레지스트리 운영자가 문제를 발견할 시간을 확보하는 완충 장치입니다. GitHub는 다른 생태계의 최소 패키지 연령 정책과도 비슷한 수준이라고 설명합니다.

개발팀에 미치는 실제 변화

• 일반 업데이트 PR이 늦게 도착합니다. 매일 Dependabot을 실행해도 공개 후 3일이 지나지 않은 버전은 후보에서 제외됩니다.
• 보안 대응 속도는 유지됩니다. 취약점 경고로 만들어지는 보안 업데이트 PR에는 기본 대기 시간이 적용되지 않습니다.
• CI 부하는 조금 완만해질 수 있습니다. 공개 직후 잦은 재배포와 철회가 반복되는 패키지에서 불필요한 테스트 실행을 줄일 여지가 있습니다.
• 최신 버전 즉시 검증이 필요한 팀은 설정을 조정해야 합니다. 프레임워크·SDK 호환성 시험처럼 공개 당일 확인이 중요한 저장소는 자체 정책을 명시하는 편이 좋습니다.

프로젝트에 맞게 대기 시간을 조정하는 법

.github/dependabot.yml의 cooldown 항목에서 기본값과 시맨틱 버전 단계별 기간을 조정할 수 있습니다. 다음 예시는 메이저 업데이트는 30일, 마이너는 7일, 패치는 3일 동안 기다리도록 설정합니다.

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "daily"
    cooldown:
      default-days: 5
      semver-major-days: 30
      semver-minor-days: 7
      semver-patch-days: 3

대기 기간은 1일에서 90일 사이로 설정할 수 있습니다. 특정 패키지에만 적용하거나 제외하려면 include와 exclude를 사용할 수 있으며, 각 목록은 최대 150개 항목을 지원합니다. SemVer 단계별 옵션은 해당 패키지 관리자가 시맨틱 버전을 지원할 때만 의미가 있으므로 Docker·Terraform 같은 생태계에는 기본 기간 중심으로 접근하는 편이 안전합니다.

설정 전에 확인할 네 가지

1. 보안 업데이트가 켜져 있는가: 일반 버전 업데이트의 지연이 취약점 대응을 대신하지 않습니다. Dependabot alerts와 security updates가 실제로 활성화돼 있는지 확인해야 합니다.
2. 자동 병합 조건이 충분한가: 대기 시간이 지나도 테스트, 잠금 파일 검증, 출처 확인 없이 자동 병합하면 공급망 위험은 남습니다.
3. 내부 패키지의 배포 방식이 다른가: 신뢰된 사내 레지스트리와 공개 레지스트리는 위험 모델이 다릅니다. 모든 의존성에 같은 기간을 적용하기보다 예외를 문서화하는 편이 좋습니다.
4. 업데이트 지연이 릴리스 일정에 영향을 주는가: 브라우저·모바일 SDK처럼 외부 정책 변화에 빠르게 대응해야 하는 프로젝트는 패키지별 기간을 따로 두는 것이 현실적입니다.

대기 시간은 방어선 하나일 뿐이다

이번 기본값은 자동화의 속도를 조금 늦춰 안전 신호가 쌓일 시간을 사는 조치입니다. 효과를 높이려면 잠금 파일과 해시 검증, 최소 권한의 CI 토큰, 빌드 출처 확인, 의존성 변경에 대한 사람의 검토가 함께 필요합니다. 특히 업데이트 PR이 통과할 수 있는 권한과 배포 비밀값의 범위를 줄이면 악성 패키지가 들어왔을 때 피해 반경을 제한할 수 있습니다.

개발팀이 얻어야 할 결론은 “업데이트를 늦추면 안전하다”가 아닙니다. 일반 업데이트와 긴급 보안 업데이트의 경로를 분리하고, 프로젝트 특성에 맞는 대기 시간과 검증 절차를 명시해야 한다는 것입니다. 기본 3일은 그 정책을 시작하기 위한 현실적인 출발점입니다.

출처: GitHub Blog — The case for a cooldown · GitHub Changelog — Dependabot version updates introduce default package cooldown · GitHub Docs — Optimizing Dependabot version updates · DevOps.com — GitHub and PyPI bet on time