Dependabot 경고 12월 8일 자동 중지 예고: 오래된 운영 저장소 점검

운영 서버는 계속 동작하지만 저장소의 보안 경고는 잠들 수 있다는 상황을 표현한 생성형 개념 이미지. 실제 GitHub 화면이나 구성도는 아니다.

코드 변경이 거의 없는 서비스도 취약한 의존성을 계속 실행할 수 있다. 그래서 GitHub의 이번 정책은 오래된 실험용 저장소를 정리하는 문제와 함께, 배포는 살아 있지만 개발 활동이 뜸한 저장소의 보안 점검으로 읽어야 한다.

GitHub는 2026년 11월 10일, 12월 8일부터 최근 1년간 활동이 없는 대부분의 저장소에서 Dependabot alerts를 끈다고 발표했다. 기존 경고는 삭제하지 않고 보관하며 다시 활성화하면 복원한다. 적용 대상은 github.com의 모든 플랜과 데이터 레지던시를 사용하는 GitHub Enterprise Cloud다. GitHub Enterprise Server는 제외된다. GitHub 공식 변경 공지

무엇을 활동으로 보는지 먼저 확인한다

공지에 명시된 활동은 다음 세 가지다.

• 어느 브랜치나 태그든 push하기

• 저장소 생성하기

• Dependabot alerts 켜기

이번 정책으로 경고가 꺼진 저장소는 브랜치나 태그에 push하거나 설정에서 경고를 다시 켜면 보관된 경고가 복원되고 1년의 계산이 다시 시작된다. 이슈 댓글, 페이지 방문, 단순한 서비스 실행은 공지의 활동 목록에 없다. 이런 동작만으로 감시가 유지된다고 가정하지 않는다. 활동과 재활성화 기준

운영상 중요한 질문은 “최근에 커밋했는가”에서 끝나지 않는다. 오래된 배치, 고객에게 배포한 패키지, 재해 복구용 도구처럼 변경은 적어도 유지보수 책임이 남는 자산을 찾아야 한다. 반대로 실행도 배포도 끝난 실험 프로젝트라면 운영 서비스와 같은 우선순위를 줄 필요는 없다.

경고 보관과 저장소 보관은 다르다

이번 공지의 archived alerts는 경고의 보관 상태다. 저장소 자체를 read-only로 바꾸는 Archive repository 작업과 혼동하면 안 된다.

GitHub 문서는 별도로, 보관된 저장소는 Dependabot이 스캔하지 않는다고 설명한다. 또한 Dependabot alerts는 기본 브랜치를 대상으로 새 보안 권고나 의존성 그래프 변경을 감지한다. 따라서 다른 브랜치의 push로 활동 조건을 충족했다는 것과 실제 배포 버전의 의존성을 점검했다는 것은 다른 확인 항목이다. Dependabot의 검사 범위와 제한

다음처럼 관리 대상을 나누면 판단이 쉬워진다.

이 표는 GitHub의 자동 판정표가 아니라 운영 검토를 위한 분류 예시다.

저장소 목록을 읽기 전용으로 확보한다

GitHub CLI가 이미 설치되어 있고 필요한 읽기 권한으로 로그인되어 있다면 아래처럼 점검 후보를 모을 수 있다. OWNER를 자신의 계정 또는 조직 이름으로 바꾼다.

이 명령은 이름, 마지막 push 시각, 저장소 보관 여부와 URL을 읽는다. 저장소 설정이나 경고 상태는 바꾸지 않는다. 공식 CLI는 이 JSON 필드와 jq 출력을 지원하며, 기본 목록 개수는 30개다. gh repo list 공식 문서

출력은 점검 후보 목록으로 사용한다. pushedAt만으로 비활성화 대상을 확정할 수는 없다. 이 결과에는 경고를 마지막으로 켠 시각, 강제 보안 구성, 엔터프라이즈 정책이 없기 때문이다.

목록의 범위에도 주의한다. 지정한 소유자의 저장소만 조회하므로 별도 조직과 개인 소유 저장소는 각각 확인한다. 1,000개는 예제의 조회 상한이다. 결과가 상한에 도달하거나 계정의 접근 권한이 제한되어 있다면 전체 자산을 확인했다고 기록하지 않는다.

오래 유지할 저장소는 정책으로 관리한다

GitHub는 두 경우에 이번 자동 중지를 적용하지 않는다고 밝혔다.

1. Dependabot alerts를 켜는 강제 적용 보안 구성이 있는 저장소

2. 저장소 관리자가 Dependabot alerts를 켜거나 끌 수 없도록 제한한 엔터프라이즈 정책의 적용 대상 저장소

단순히 현재 경고가 켜져 있다는 것과 이 예외에 해당한다는 것은 다르다. 자동 중지 예외

조직에서는 Advanced Security의 Configurations에서 구성 내용을 검토한다. Dependabot alerts를 Enabled로 지정하고, 필요한 경우 Policy의 Enforce configuration을 적용하는 방식이다. 설정하지 않은 기능은 강제 적용 대상이 아니므로, 구성 이름만 보고 확인을 끝내지 않는다. 다른 보안 제품까지 함께 활성화하면 비공개 저장소에서 사용료나 라이선스가 필요할 수 있으므로 변경 범위를 확인한다. 사용자 정의 보안 구성

구성을 만드는 것만으로 대상 저장소에 적용되지는 않는다. Repositories 탭에서 대상과 적용 구성을 확인하고, 변경에 따른 라이선스 소비 안내를 검토한다. 조직으로 이전한 저장소는 새 저장소용 기본 구성에만 의존하지 말고 별도 적용 여부를 확인해야 한다. 기존 저장소에 구성 적용하기

엔터프라이즈 정책을 쓰는 경우에는 Policies → Advanced Security의 “Enable or disable Dependabot alerts by repository admins” 항목을 확인한다. 이 정책은 저장소 관리자에게 적용되는 제어다. 조직 소유자와 보안 관리자의 권한까지 동일하게 제한한다고 해석하지 않는다. 엔터프라이즈 보안 정책

다시 켠 뒤에는 화면에서 결과를 확인한다

개별 저장소는 Settings → Advanced Security → Dependabot alerts에서 Enable을 선택하는 경로를 사용할 수 있다. 먼저 대상 저장소와 현재 정책을 확인하고, 조직의 승인 절차에 맞춰 변경한다. 저장소별 설정 안내

운영 점검에서는 다음을 함께 기록하는 편이 좋다.

• 경고 기능이 활성화되어 있는지

• 기존 경고가 보이는지와 처리 담당자가 누구인지

• 실제 운영 버전과 기본 브랜치의 의존성 차이가 있는지

• 경고를 계속 유지할 정책이 적용되어 있는지

• 다음 검토 시점과 책임자가 정해져 있는지

메일이 오지 않았다는 사실만으로 정상 여부를 판단하지 않는다. 알림은 권한과 구독 설정의 영향을 받으며, 최초 활성화에서 발견한 모든 취약점이 이메일로 전달되는 것도 아니다. 경고 목록 자체를 확인하는 단계가 필요하다. 경고와 알림의 차이

API로 설정을 관리하는 팀에는 한 가지 확인이 더 필요하다. 강제 적용된 구성의 기능을 바꾸려는 REST 요청은 성공처럼 보이지만 실제 상태는 변하지 않을 수 있다고 GitHub가 문서화했다. 상태 코드만 저장하지 말고 최종 설정을 다시 읽어 검증한다. 강제 구성과 REST API의 동작

완료 기준은 경고를 받을 자산이 빠지지 않는 것이다

기한을 피하려고 의미 없는 커밋을 예약하기보다는, 운영 중인 자산 목록과 보안 감시 대상 목록을 대조하는 편이 유지보수에 도움이 된다. 경고가 없는 저장소를 곧바로 안전한 저장소로 분류하지 않고, 기능의 활성화 상태와 검사 범위를 함께 남긴다.

이번 변화에 대한 준비는 세 가지로 정리할 수 있다. 변경이 적은 운영 저장소를 찾고, 경고 유지 방식을 정하고, 설정과 경고 목록을 실제로 확인한다. 취약점 경고를 복원하는 것과 취약한 의존성을 수정·배포하는 것은 각각 완료해야 할 작업이다.

확인 기준은 2026년 11월 10일 GitHub 공지와 11월 11일 한국시간에 확인한 공식 문서다. CLI 명령은 공식 문서에 근거한 읽기 전용 예시이며, 실제 사용자 저장소에서 실행하거나 보안 정책을 변경하지 않았다.