Dependabot security updates 체크리스트: 알림 쌓였을 때 안전한 처리 순서

Dependabot alerts가 한 번에 쌓이면 먼저 새 버전부터 올리고 싶어집니다. 작은 팀이라면 그 전에 alert가 가리키는 affected manifest, 취약점 severity, security updates pull request 존재 여부, CI와 rollback 경로를 한 장의 체크리스트로 묶어두는 편이 안전합니다.

기준일: 2026-06-21. GitHub 보안 기능, UI 경로, 공식 문서 내용은 나중에 달라질 수 있으니 발행 전이나 실제 운영 반영 전에는 아래 GitHub Docs 링크를 다시 확인하세요.

먼저 판단할 순서는 무엇인가요?

알림이 많을수록 severity만 보고 정렬하면 놓치는 항목이 생깁니다. 운영 순서는 alert의 위험도, 영향을 받는 manifest, 자동 생성된 security updates PR, CI 결과, 배포 영향, rollback 가능성을 같이 봐야 합니다.

Alert triage 체크리스트

GitHub 문서 기준으로 Dependabot alerts는 취약한 dependency를 알려주며, alert에는 affected file, severity, fixed version 정보가 붙는 경우가 있습니다. 첫 화면에서 바로 닫기보다 아래 항목을 티켓이나 PR 설명에 복사해 남기는 방식이 좋습니다.

• Repository 기본 branch에서 나온 alert인지 확인합니다.
• affected file이 package manifest인지, lockfile인지, GitHub Actions workflow인지 구분합니다.
• severity와 CVE/GHSA 내용을 보되, 실제 서비스 runtime에서 쓰는 dependency인지 함께 봅니다.
• fixed version이 표시되어 있으면 현재 버전과 목표 버전 차이를 기록합니다.
• security updates PR이 이미 열렸는지 확인하고, 같은 package를 여러 PR에서 동시에 올리지 않습니다.
• 패치가 없거나 자동 PR이 실패했다면 alert를 닫지 말고 보류 사유와 재확인 날짜를 남깁니다.

작은 팀 기준으로는 alert 닫기가 완료가 아닙니다. dependency가 실제로 업데이트됐고, CI와 최소 smoke test를 지나갔으며, 문제가 생겼을 때 되돌릴 수 있어야 처리 완료로 보는 편이 안전합니다.

Dependabot security updates PR은 어떻게 검토하나요?

Dependabot security updates를 켜면 GitHub는 가능한 패치가 있는 open Dependabot alert를 해결하기 위해 PR 생성을 시도합니다. 공식 문서 기준으로 security updates는 manifest 또는 lock file에 지정된 dependency에서 트리거되며, 가능한 경우 패치가 포함된 최소 버전으로 업데이트합니다.

1. PR 제목과 연결된 Dependabot alert를 확인합니다.
2. 변경된 manifest와 lockfile을 함께 봅니다. lockfile만 바뀌었더라도 배포 산출물에 영향이 갈 때가 있습니다.
3. 패치 버전이 minimum patched version인지, major/minor jump가 생겼는지 확인합니다.
4. CI, 테스트, build, lint가 모두 통과했는지 보고, 실패하면 실패 로그를 dependency 변경과 연결해 봅니다.
5. release notes나 changelog에서 breaking change, deprecated API, Node/Python/Java 버전 조건을 확인합니다.
6. 운영 영향이 큰 package라면 staging 배포나 smoke test를 먼저 진행합니다.
7. merge 뒤 alert가 자동으로 닫혔는지 확인하고, 닫히지 않으면 남은 vulnerable dependency 경로를 다시 봅니다.

Minimal dependabot.yml 체크리스트

dependabot.yml은 security alerts 자체를 만드는 파일이 아니라 Dependabot 동작, 특히 version updates와 PR 생성 방식을 조정하는 설정입니다. 다만 GitHub 문서는 일부 PR 설정이 security updates PR에도 영향을 줄 수 있다고 설명하므로, 운영 파일은 작게 시작하고 변경 이유를 남기는 편이 좋습니다.

• version: 2를 사용합니다.
• 각 ecosystem마다 package-ecosystem, directory, schedule.interval을 명시합니다.
• 처음부터 모든 ecosystem을 켜지 말고, 실제 운영 manifest가 있는 위치부터 넣습니다.
• monorepo라면 directory 범위를 넓히기 전에 PR 폭증 가능성을 먼저 봅니다.
• groups는 patch/minor 업데이트 소음 제어에 쓰되, security updates와 version updates가 같은 의미라고 보지 않습니다.
• ignore를 쓸 때는 왜 무시하는지와 재검토 날짜를 PR이나 운영 문서에 남깁니다.
• open-pull-requests-limit는 version updates의 열린 PR 수를 조정하는 값입니다. GitHub 문서 기준 security updates에는 별도 내부 제한이 있으므로 같은 레버로 이해하면 안 됩니다.

아래 예시는 generic starting point입니다. 이 저장소에서 테스트한 설정이 아니며, package ecosystem과 directory는 실제 manifest 위치에 맞게 바꿔야 합니다.

# Generic starting point only. Not tested for your repository.
version: 2
updates:
  - package-ecosystem: npm
    directory: /
    schedule:
      interval: weekly
    groups:
      npm-patch-and-minor:
        patterns:
          - "*"
        update-types:
          - patch
          - minor
  - package-ecosystem: github-actions
    directory: /
    schedule:
      interval: weekly

GitHub Actions 업데이트는 따로 봐야 하나요?

따로 봐야 합니다. GitHub Actions는 애플리케이션 dependency와 달리 workflow 권한, 배포 토큰, OIDC trust policy, runner 환경까지 연결됩니다. GitHub 문서는 GitHub Actions version updates를 위해 package-ecosystem: github-actions, directory: /, schedule.interval 설정을 안내합니다.

• .github/workflows 안에서 외부 action을 쓰는 workflow를 확인합니다.
• 배포 workflow라면 action 버전 변경이 cloud role, environment protection, approval 흐름에 영향을 주는지 봅니다.
• 권한이 큰 workflow는 permissions 범위를 함께 확인합니다.
• OIDC를 쓰는 배포라면 GitHub Actions OIDC 체크리스트의 trust policy 점검 순서와 같이 봅니다.
• 새 action 버전이 major 변경이면 release notes를 보고, 가능하면 별도 PR로 분리합니다.
• workflow가 실패하면 Dependabot PR을 바로 닫지 말고 action 입력값, Node runtime, deprecated command 사용 여부를 확인합니다.

Rollback과 noise control 체크리스트

Dependabot 운영에서 소음은 단순히 PR 수가 많은 문제가 아닙니다. 어떤 업데이트가 보안 패치이고, 어떤 업데이트가 일반 version updates인지 구분되지 않으면 중요한 alert가 평범한 유지보수 PR 사이에 묻힙니다.

• Critical/High security updates PR은 일반 version updates PR보다 먼저 본다는 규칙을 둡니다.
• 같은 ecosystem의 patch/minor 업데이트는 groups로 묶되, major 업데이트는 분리 검토합니다.
• 무시한 package는 ignore만 남기지 말고 보류 사유, 위험, 재확인 날짜를 적습니다.
• merge 전에는 lockfile diff와 CI 결과를 확인합니다.
• merge 뒤 배포 문제가 생기면 dependency 업데이트 PR만 revert할지, 후속 fix forward를 할지 미리 정합니다.
• rollback 뒤 alert가 다시 열리면 운영 영향과 취약점 위험을 비교해 임시 mitigation을 남깁니다.
• PR이 너무 많으면 version updates schedule을 줄이고, security updates 처리 대기열은 따로 봅니다.

Secret Scanning 글과 같이 보면 좋은 지점

dependency 취약점 대응은 토큰 유출 대응과 성격이 다르지만, 운영 기록을 남긴다는 점은 같습니다. 노출된 secret을 먼저 비활성화해야 하는 상황이라면 GitHub Secret Scanning 알림 대응 체크리스트와 AI API 키 유출 방지 체크리스트를 함께 보면 처리 순서를 나누기 쉽습니다.

저장소에 남길 운영 규칙

Dependabot security updates는 자동 PR을 만들어 시간을 줄여주지만, merge 판단까지 대신해주지는 않습니다. 작은 팀이라면 아래 다섯 줄만 저장소 운영 문서에 남겨도 alert 처리 품질이 좋아집니다.

1. Critical/High alert는 affected manifest와 runtime 사용 여부를 먼저 본다.
2. security updates PR은 CI, lockfile, release notes, rollback 기준을 확인한 뒤 merge한다.
3. GitHub Actions 업데이트는 배포 권한과 workflow 영향까지 같이 본다.
4. ignore와 groups는 소음 제어 도구이지, 위험 제거 도구가 아니다.
5. 닫은 alert는 처리 근거와 재발 방지 설정을 남긴다.

출처 및 참고자료

1. GitHub Docs – About Dependabot alerts
2. GitHub Docs – About Dependabot security updates
3. GitHub Docs – Dependabot.yml configuration options
4. GitHub Docs – Keeping your actions up to date with Dependabot