Dependabot을 끄자

• Dependabot의 과도한 알림이 실제 보안 문제 해결보다 개발자의 시간을 낭비하게 만든다는 지적
• Go 생태계에서 발생한 사례처럼, 영향받지 않은 저장소에도 수천 개의 PR과 경고가 생성되어 혼란을 초래함
• govulncheck 기반 GitHub Action을 사용하면 실제로 취약한 코드만 탐지하고, 불필요한 경고를 제거할 수 있음
• 의존성 업데이트는 자동화된 PR보다 주기적 테스트와 최신 버전 검증으로 관리하는 것이 더 안전하고 효율적임
• 이러한 접근은 경고 피로(alert fatigue) 를 줄이고, 오픈소스 유지보수자의 부담을 완화하는 데 중요함

---

Dependabot의 문제점

• Dependabot은 보안 경고와 자동 PR을 대량 생성해 개발자가 실제로 중요한 문제를 구분하기 어렵게 함
  • Go 패키지 filippo.io/edwards25519의 사소한 수정에도 수천 개의 PR이 생성됨
  • 영향받지 않은 저장소(Wycheproof 등)에도 잘못된 보안 경고가 전달됨
• 경고에는 허위 CVSS 점수와 낮은 호환성 지표가 포함되어, 불필요한 불안감을 조성함
• 이러한 과도한 알림은 보안 대응의 신뢰도와 효율성을 저하시키는 원인으로 지적됨

govulncheck를 이용한 대안

• Go Vulnerability Database는 버전, 패키지, 심볼 단위의 세밀한 메타데이터를 제공
  • 예시로 GO-2026-4503 취약점은 Point.MultiScalarMult 심볼에만 영향을 미침
• govulncheck는 정적 분석을 통해 실제로 호출 가능한 취약 코드만 탐지
  • go mod why와 함께 사용 시, 간접 의존성의 영향 여부를 정확히 판단 가능
  • 검사 결과, 취약점이 존재하더라도 코드가 해당 심볼을 호출하지 않으면 경고하지 않음
• CLI(govulncheck -json)나 Go API(golang.org/x/vuln/scan)로 손쉽게 통합 가능

GitHub Actions로의 대체

• Dependabot 대신 govulncheck GitHub Action을 설정해 매일 자동 검사 수행
  • 실제 취약점이 발견될 때만 알림을 발송
  • 자동 PR을 생성하지 않아, 개발자가 중요한 보안 이슈에 집중할 수 있음
• 잘못된 경고를 줄이면 보안 경고 피로(alert fatigue) 를 완화하고, 대응 품질을 높일 수 있음
• 오픈소스 유지보수자에게 불필요한 PR을 보내는 문제도 해소됨

의존성 업데이트 관리 방식

• 의존성은 각 프로젝트의 개발 주기에 맞춰 일괄적으로 관리해야 함
  • 매일 최신 버전으로 테스트를 수행하되, 실제 업데이트는 필요 시점에만 진행
  • Go에서는 go get -u -t ./..., npm에서는 npm update 명령으로 최신 버전 테스트 가능
• 이 방식은 보안 취약점 대응 속도와 안정성을 모두 확보
  • 최신 버전 테스트를 통해 호환성 문제를 조기에 발견
  • 악성 코드가 포함된 의존성이 즉시 배포되지 않도록 차단
• geomys/sandboxed-step을 이용하면 CI 환경에서 gVisor로 격리 실행 가능

결론 및 지원 배경

• Dependabot의 자동화는 보안보다 소음(noise) 을 유발하는 경우가 많음
• govulncheck와 주기적 테스트 기반 접근이 더 정확하고 지속 가능한 보안 관리 방법
• 글 작성자의 오픈소스 유지보수는 Geomys 조직을 통해 Ava Labs, Teleport, Tailscale, Sentry 등의 후원을 받아 지속됨
• 이러한 모델은 오픈소스 생태계의 안정적 유지와 보안 품질 향상에 기여함

[GN⁺]

Hacker News 의견들

• Dependabot은 일정 부분 가치가 있음
  하지만 단순히 버전 번호와 취약점 DB만 비교하는 도구는 실제 코드가 그 취약점에 노출되어 있는지 판단하지 못해 노이즈가 많음
  최근 인상 깊었던 도구는 CodeQL임. GitHub Advanced Security에서 실행 가능하며, 코드의 실제 흐름을 추적해 입력값이 위험한 사용으로 이어지는 전체 경로를 시각적으로 보여줌
  덕분에 실질적인 수정이 가능한 정보가 제공되고, 오탐이 적음. 물론 Python 같은 동적 언어에서는 탐지를 피할 수 있는 코드도 있겠지만, 대부분의 경우 충분히 유용함
  • 예전엔 CodeQL이 프로젝트에 도움이 되었지만, 최근엔 너무 짜증나는 수준이라 팀에서 꺼버림
    단순히 CodeQL의 경고를 피하려고 쓸모없는 중간 변수를 추가하는 식의 코멘트가 생김. 데이터에 과적합된 도구처럼 느껴짐
  • “오탐이 거의 없다”는 말엔 동의하기 어려움. Rice 정리에 따르면 그런 완벽한 분석은 불가능함
  • 내 경험상 CodeQL은 오탐이 많고, 로컬에서 쉽게 실행할 방법이 없어 벤더 종속성이 생김
  • 의존성 버전을 올린다고 해서 보안이 개선된다는 보장은 없음. 새 버전이 새로운 취약점을 가져올 수도 있음
• NPM 패키지에서 ReDoS 경고가 너무 많이 뜸. 대부분은 클라이언트 코드에서만 쓰이는 패키지인데, 백엔드와 무관한 경고가 너무 많음. 클라이언트 측 ReDoS는 우리에겐 의미가 없음
  • 사실 DoS는 보안 취약점이 아니라 가용성 문제라고 생각함. 보안의 CIA 중 하나이긴 하지만, 실제로는 운영상의 이슈에 더 가까움. DoS를 보안 문제로 분류하는 건 역사적 유물에 불과함
  • 나는 debug 패키지를 유지보수 중인데, 엉터리 ReDoS 보고서가 너무 많음. CVE까지 등록된 경우도 있어서 JS 생태계에서 손을 떼고 싶을 정도임
  • AI 코드 리뷰 도구에서도 비슷한 문제를 겪음. 로컬에서 사용자 권한으로 실행되는 도구인데도 입력값을 불필요하게 sanitize하라고 함. 결국 시간 낭비임
  • 우리도 같은 문제를 겪음. 특히 Dev dependency에서 오는 ReDoS 경고가 불필요한 소음을 많이 만듦
  • ReDoS는 정규식 엔진의 버그인데, V8 같은 엔진이 여전히 안전한 정규식 엔진을 기본 제공하지 않음
• Govulncheck는 Go 생태계의 최고의 기능 중 하나임
  PR에서 취약한 호출이 추가되면 알림을 주는 GitHub Action을 만들어 사용 중임.
  Dependabot 자동 병합과 함께 쓰면 JS 코드베이스 관리에도 괜찮은 조합임
  • Govulncheck도 완벽하진 않음. 오탐이 있고, CVE 번호로 특정 취약점을 제외할 방법이 없음
• Dependabot은 유용하지만, 동시에 의존성 최소화의 중요성을 매일 상기시켜줌
  • 나도 아침마다 Dependabot PR을 처리하면서 하루를 시작함.
    테스트가 충분하다면 새 버전에서 버그를 발견하기도 하지만, 그 과정에서 오픈소스 기여로 이어지기도 함. 귀찮지만 좋은 습관을 만들어줌
  • 나도 동의함. 프로젝트가 많진 않지만 Dependabot은 꽤 쓸 만함
• Dependabot이 이메일 대신 리포지토리 내 탭 형태로 관리되면 좋겠음.
  이메일 알림은 귀찮고, PR이 쌓이는 것도 싫음. 특정 시간대에만 집중적으로 처리하고 싶음
  • dependabot.yml 설정으로 실행 주기와 PR 개수를 조절할 수 있음
    공식 문서 참고
  • 자동 PR을 끄고, 필요할 때만 수동으로 생성할 수도 있음.
    직접 수정하면서 이슈 수를 줄이는 방식도 가능함
  • Refined GitHub 확장을 쓰면 기본 뷰가 좀 더 깔끔해짐.
    개인적으로는 Renovate를 추천함. 더 많은 언어와 자동 병합 옵션을 지원함
• Go의 govulncheck 방식(실제 호출 경로 추적)은 모든 생태계의 기본이 되어야 함
  Dependabot의 근본 문제는 의존성 관리를 보안 문제로 착각한다는 점임.
  호출되지 않는 함수의 취약점은 보안 이슈가 아니라 노이즈임
  Python에서는 pip-audit --desc가 Dependabot보다 낫다고 느낌.
  완벽한 정적 분석이 나오기 전까지는 분기별 수동 점검이 오히려 더 안전할 수도 있음
  • 하지만 고객이 이런 도구로 코드를 스캔하면 “그 함수를 안 쓴다”는 답변을 믿지 않음.
    실제 보안과 보안 관행의 괴리가 여기서 생김
  • “안 쓴다면 왜 그 함수가 코드에 남아 있냐”는 질문도 타당함
• 업계가 왜 이런 피상적인 보안 스캐너를 받아들였는지 모르겠음
  대부분의 CVE는 실제로 영향을 주지 않는데, 기업들은 컨테이너 이미지의 취약점 수를 0으로 만들려고 애씀
  게다가 의존성을 업데이트하면 새로운 CVE가 생기기 마련임. 대부분의 소프트웨어가 백포트 패치를 하지 않기 때문임
  • “백포트를 안 한다”는 부분이 앞 문장과 어떻게 연결되는지 잘 모르겠음
• Dependabot이나 Renovate의 장점은 언어 불문으로 작동한다는 점임
  리포지토리가 많고 언어가 다양할수록, 완벽한 CI 워크플로를 추가하는 건 비현실적임
  완벽하진 않아도, 아무것도 안 하는 것보단 훨씬 낫다고 생각함
• Dependabot의 CVSS 점수가 어디서 오는지 궁금함.
  자동으로 CVE를 생성하는 건가?
  • CVSS는 최악의 경우를 가정한 점수라 실제 위험도를 반영하지 않음.
    GitHub의 취약점 DB는 품질보다 양에 집중되어 있고, Dependabot은 지능 없는 스팸 알림기처럼 작동함
  • 실제로 그 버그가 진짜 취약한지조차 의문임.
    잘못된 방식으로 함수를 호출해야만 문제가 생기는 경우라면, 이미 코드가 작동하지 않았을 가능성이 큼
• 우리 회사도 비슷한 문제를 겪음.
  GCP 컨테이너 이미지 스캔이 Vanta에 수많은 CVE 경고를 쏟아내는데, 대부분은 수정 불가하거나 실제로는 사용되지 않는 경로임
  이런 맥락 기반 필터링을 해주는 도구가 있을까 궁금함
  • 우리 회사는 Aikido Code를 사용 중임. AI로 취약점의 실제 영향을 필터링하려고 함.
    결과는 대체로 긍정적이지만, 코드베이스가 크고 의존성이 많아 CVE 수를 줄이는 건 여전히 어려움