# Dependabot을 끄자 > Clean Markdown view of GeekNews topic #26873. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=26873](https://news.hada.io/topic?id=26873) - GeekNews Markdown: [https://news.hada.io/topic/26873.md](https://news.hada.io/topic/26873.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-02-21T22:33:07+09:00 - Updated: 2026-02-21T22:33:07+09:00 - Original source: [words.filippo.io](https://words.filippo.io/dependabot/) - Points: 1 - Comments: 1 ## Topic Body - **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 등의 후원을 받아 지속됨 - 이러한 모델은 **오픈소스 생태계의 안정적 유지와 보안 품질 향상**에 기여함 ## Comments ### Comment 51551 - Author: neo - Created: 2026-02-21T22:33:07+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47094192) - 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](https://github.com/imjasonh/govulncheck-action)을 만들어 사용 중임. Dependabot 자동 병합과 함께 쓰면 JS 코드베이스 관리에도 괜찮은 조합임 - Govulncheck도 완벽하진 않음. **오탐**이 있고, CVE 번호로 특정 취약점을 제외할 방법이 없음 - Dependabot은 유용하지만, 동시에 **의존성 최소화의 중요성**을 매일 상기시켜줌 - 나도 아침마다 Dependabot PR을 처리하면서 하루를 시작함. 테스트가 충분하다면 새 버전에서 버그를 발견하기도 하지만, 그 과정에서 **오픈소스 기여**로 이어지기도 함. 귀찮지만 좋은 습관을 만들어줌 - 나도 동의함. 프로젝트가 많진 않지만 Dependabot은 꽤 쓸 만함 - Dependabot이 이메일 대신 **리포지토리 내 탭 형태**로 관리되면 좋겠음. 이메일 알림은 귀찮고, PR이 쌓이는 것도 싫음. 특정 시간대에만 집중적으로 처리하고 싶음 - `dependabot.yml` 설정으로 실행 주기와 PR 개수를 조절할 수 있음 [공식 문서](https://docs.github.com/en/code-security/reference/supply-chain-security/dependabot-options-reference) 참고 - 자동 PR을 끄고, 필요할 때만 수동으로 생성할 수도 있음. 직접 수정하면서 이슈 수를 줄이는 방식도 가능함 - [Refined GitHub 확장](https://github.com/refined-github/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 수를 줄이는 건 여전히 어려움