Dependabot 악성 패키지 경고 설정과 type:malware 필터로 공급망 위험 찾기
설정, 공개 검색, 저장소 경고는 서로 다른 단계다
Dependabot 악성 패키지 경고를 켜려고 찾아보면 설정 토글과 type:malware 검색어가 한꺼번에 나와서 살짝 헷갈려요. 먼저 딱 나눠두면 편합니다. 기능 활성화는 저장소 Settings, 공개 악성 패키지 조사는 GitHub Advisory Database, 내 저장소에 생긴 경고 처리는 Security and quality 화면에서 해요.
이번 글은 2026년 8월 2일 기준 GitHub 공식 문서와 OpenSSF 원문을 대조하고, 공개 type:malware 결과를 읽기 전용으로 확인해 정리했습니다. 실제 저장소의 설정을 켜거나 악성 의존성을 추가한 테스트는 하지 않았어요. 설정법은 확인했지만 특정 저장소에서 경고가 실제 발생했다고 말할 수는 없음. 이 경계가 꽤 중요합니다.
소스코드 취약점 탐지와 패키지 공급망 경고의 차이도 함께 확인하려면 GitHub 코드 스캐닝 AI 보안 탐지를 PR에서 검증하는 법을 참고할 수 있어요.
먼저 켤 것은 두 개의 Alert 토글
저장소 단위 설정 순서는 아래와 같습니다.
- 저장소에서
Settings를 엽니다. - 왼쪽
Security영역의Advanced Security로 이동해요. Dependabot alerts를 먼저 Enable 합니다.- 이어서
Dependabot malware alerts를 Enable 합니다.
Malware alert의 선행 조건이 일반 Dependabot alerts라서 순서가 두 단계예요. 조직이나 엔터프라이즈라면 custom security configuration으로 여러 저장소에 적용할 수 있습니다. 정확한 경로는 GitHub의 Malware alert 설정 문서에서 다시 확인할 수 있어요.
여기서 자주 섞이는 파일이 .github/dependabot.yml인데요. 이 파일은 자동 버전 업데이트와 보안 업데이트 PR의 동작을 세밀하게 제어합니다. Malware alert 자체를 켜는 스위치는 아니에요. Alert 활성화는 Settings에서, 업데이트 동작은 YAML에서. 이름이 비슷해서 괜히 한참 찾기 쉬운 구간입니다. dependabot.yml 개념 문서
설정을 켰는데 이메일이 오지 않는다고 바로 실패로 판단할 수도 없어요. Alert 발생과 개인 알림 수신은 별도 조건이거든요. 기본 이메일 알림은 해당 저장소에 write·maintain·admin 권한이 있고, 저장소를 watch하면서 Security alerts 또는 All activity 알림을 켠 사람을 대상으로 합니다. 그래서 Alert 존재 여부 → 저장소 watch → 개인 알림 설정 순으로 나눠 확인하는 편이 안전함. Malware alert 개념, 보안 알림 문서
type:malware는 저장소 Alert 필터가 아니다
type:malware는 github.com/advisories에서 공개 Malware Advisory만 골라보는 검색 한정자입니다. 즉 “공개 데이터베이스에 어떤 악성 패키지 보고가 있나?”를 조사할 때 써요.
type:malware ecosystem:npm
type:malware ecosystem:pip
type:malware affects:PACKAGE_NAME
type:malware is:withdrawn
type:malware sort:created-desc
생태계, 패키지명, 철회 여부, 등록 순서까지 조합할 수 있습니다. 공개 Advisory 상세에서 Dependabot alerts를 선택하면 자신이 접근할 수 있는 영향받은 저장소도 확인할 수 있어요. GitHub Advisory Database 검색 문서
반면 자기 저장소에 실제로 생성된 경고는 Security and quality → Findings → Dependabot → Malware에서 봅니다. 여기서는 Alert 상세를 확인하고 dismiss하거나, 닫았던 항목을 다시 reopen해요. 공개 목록을 뒤지는 검색창과 내 저장소의 처리함이 서로 다른 셈. type:malware를 저장소 Findings 검색창에 넣는 방식으로 설명하면 안 됩니다. Malware alert 관리 문서
경고는 정기 스캔보다 두 가지 변화에서 시작된다
GitHub는 기본 브랜치의 manifest·lockfile에서 파악한 의존성을 GitHub Advisory Database의 악성 패키지 정보와 대조합니다. 알려진 악성 패키지를 추가하거나 악성 버전으로 갱신한 변경이 기본 브랜치에 push될 때, 또는 새로운 Malware Advisory가 데이터베이스에 등록될 때 검사가 일어나요. 일정표에 따라 한 번씩 전체를 훑는 방식은 아닙니다. 취약 의존성 탐지 문서
그래서 예전에 추가한 의존성도 나중에 새 Advisory가 등록되면 경고 대상이 될 수 있어요. 다만 dependency graph가 package와 정확한 버전을 알아낼 수 있어야 하고, GitHub가 검토한 Advisory여야 합니다. archived repository는 검사하지 않으며 GitHub Actions는 SemVer를 쓰는 Action에 대해서만 Alert가 생성되고 SHA 고정 버전은 해당하지 않는다는 제한도 있어요. Alert가 없다고 안전 판정 완료! 할 수 없는 이유입니다. Malware alert 개념
OpenSSF 연동으로 공개 범위는 넓어졌지만 문서는 충돌한다
GitHub는 2026년 7월 28일부터 OpenSSF malicious-packages의 OSV 형식 보고서를 GitHub Advisory Database에 자동 수집한다고 발표했습니다. 기존에 Malware alerting을 켜둔 저장소는 추가 설정 없이 확대된 데이터의 이점을 받는다는 설명도 함께 나왔어요. GitHub Changelog, OpenSSF malicious-packages
2026년 8월 2일 공개 type:malware 결과를 직접 열어보니 43,293건이 표시됐고 npm뿐 아니라 pip, RubyGems, NuGet, Go, Rust, Maven, Composer 항목도 확인됐습니다. 이 수치는 계속 바뀌는 당시 스냅샷이에요. 여기까지는 공개 Advisory Database의 다중 생태계 범위를 확인한 결과입니다.
근데 한 가지가 딱 걸립니다. 같은 날 확인한 GitHub의 Malware alert 개념 문서에는 여전히 npm 생태계에서 사용할 수 있다는 문구가 남아 있었어요. 최신 발표가 개념 문서에 아직 반영되지 않았을 가능성은 있지만, 그건 추론입니다.
따라서 현재 안전한 해석은 이렇습니다.
- 공개 Advisory Database에는 npm 외 여러 생태계의 Malware 데이터가 있다.
- GitHub는 기존 활성 저장소가 확대된 데이터의 이점을 별도 설정 없이 받는다고 발표했다.
- 그렇다고 공개 목록에 보이는 모든 생태계가 모든 저장소 형태에서 똑같이 Alert를 만든다고 단정할 수는 없다.
- npm 외 생태계는 자기 저장소의 Malware 뷰와 dependency graph 인식 결과로 확인한다.
일반 Dependabot 지원 생태계 표도 Malware alert 전용 지원표는 아니에요. version updates나 security updates 등 여러 기능을 함께 비교한 표라서, 여기에 패키지 매니저 이름이 있다고 Malware alert까지 자동으로 보장된다고 읽으면 너무 멀리 갑니다. Dependabot 지원 생태계 문서
오탐은 숨기기보다 근거를 남겨 닫는다
사내 패키지의 생태계·이름·버전이 공개 악성 패키지와 같으면 false positive가 생길 수 있습니다. 그렇다고 이름이 같다는 이유만으로 냅다 dismiss하면 곤란해요. 실제 registry 출처와 해석된 package version을 먼저 확인해야 합니다. dependency confusion 가능성과 맞닿은 상황이라 더 그렇고요.
개별 Alert에서는 dismiss reason을 선택하고 코멘트를 남길 수 있습니다. 그 코멘트는 Alert timeline에 남으며, 판단이 바뀌면 Closed 목록에서 reopen 가능해요. “사내 패키지라서 제외” 한 줄보다 어떤 registry와 버전을 확인했는지까지 기록하는 방식이 나중에도 마음 편-안. Malware alert 관리 문서
Dismiss package malware alerts 프리셋도 있습니다. 모든 버전이 악성으로 표시된 패키지 Alert를 자동 dismiss하는 규칙인데 기본값은 disabled예요. 내부 이름 충돌로 생기는 경고를 줄일 수 있지만, 기여자가 실제 악성 의존성을 추가한 경우까지 가릴 수 있다고 GitHub가 경고합니다. 편하다고 바로 전체 적용하기보다 실제 오탐 패턴과 감사 요구를 먼저 보는 게 맞습니다. Dependabot auto-triage 문서
원천 데이터 자체가 잘못됐다면 저장소 Alert를 dismiss하는 것과 OpenSSF에 정정을 제보하는 일도 분리해야 해요. OpenSSF는 ecosystem, package, 영향 버전과 관련 링크를 담아 issue를 만들도록 안내합니다. 전체 보고가 오탐이면 withdrawn 처리하고, 일부 버전만 문제라면 해당 버전을 별도로 표시하는 방식이에요. 다만 false positive 처리 지원이 아직 TBC라고 적힌 부분도 있어 즉시 반영을 보장할 수는 없습니다. OpenSSF malicious-packages
저장소에서 확인할 순서
실제로 점검할 때는 아래 순서면 덜 헤맵니다.
- 저장소가 archived 상태인지 확인합니다.
Settings → Advanced Security에서Dependabot alerts와Dependabot malware alerts를 차례로 확인해요.- 기본 브랜치의 manifest·lockfile과 dependency graph의 package·version 인식 여부를 봅니다.
- 공개 조사는
github.com/advisories에서type:malware에ecosystem:또는affects:를 조합합니다. - 실제 저장소 경고는
Security and quality → Findings → Dependabot → Malware에서 확인해요. - Alert의 영향 파일, package, affected versions, patched version 유무와 조치 내용을 읽습니다.
- 내부 패키지 충돌이 의심되면 registry와 버전을 검증한 뒤 사유와 코멘트를 남겨 dismiss합니다.
- npm 외 생태계는 공개 Advisory 존재만으로 지원을 단정하지 않고 실제 저장소 결과를 확인합니다.
기능을 켜는 곳과 조사하는 곳, 처리하는 곳만 분리해도 절반은 해결됩니다. 남은 절반은 “경고 없음 = 안전”으로 단정하지 않고 dependency graph와 문서 범위를 함께 보는 일. 완벽한 자동 판정은 아니지만 공급망 위험을 놓치지 않으면서 오탐도 감사 가능하게 다루는 현실적인 선입니다.
자기 저장소의 Settings → Advanced Security와 공개 type:malware 결과를 각각 열어, 활성화 상태와 현재 공개된 패키지 범위를 따로 확인해 보세요.
FAQ
Malware alert를 켜려면 일반 Dependabot alerts도 활성화해야 하나요?
네. 저장소의 Settings → Advanced Security에서 일반 Dependabot alerts를 먼저 켠 뒤 Dependabot malware alerts를 활성화해야 합니다. .github/dependabot.yml 생성은 이 토글의 선행 조건이 아닙니다.
type:malware ecosystem:pip처럼 필터를 조합할 수 있나요?
가능합니다. 다만 이 검색 한정자는 저장소 Alert 목록이 아니라 공개 GitHub Advisory Database에서 Malware Advisory를 생태계별로 좁힐 때 사용해요.
새 Malware Advisory가 등록되면 기존 의존성도 다시 검사하나요?
GitHub 문서상 새 Advisory 등록은 검사 계기 중 하나입니다. 기본 브랜치의 manifest·lockfile에서 의존성과 정확한 버전을 파악할 수 있어야 하며, GitHub가 검토한 Advisory여야 Alert로 이어집니다.
npm 외 PyPI 같은 생태계에서도 Alert가 보장되나요?
공개 Advisory Database에서 pip 등 여러 생태계의 Malware 데이터는 확인됐고 GitHub도 OpenSSF 연동에 따른 확대를 발표했습니다. 하지만 Malware alert 개념 문서에는 npm-only 문구가 남아 있어 모든 저장소에서의 동작을 일괄 보장한다고 단정하기 어렵습니다. 실제 저장소의 Malware 뷰와 dependency graph 인식 상태를 확인해야 해요.
오탐으로 닫은 Alert를 다시 열 수 있나요?
네. Alert 상세에서 사유와 코멘트를 남겨 dismiss할 수 있고, 이후 Closed 목록에서 reopen할 수 있습니다. 내부 패키지 이름 충돌이라면 registry와 정확한 버전을 확인한 근거를 코멘트에 남기는 편이 좋습니다.
