Dependabotをオフにしよう

 (words.filippo.io)
1 ポイント 投稿者 GN⁺ 2026-02-21 | 1件のコメント | WhatsAppで共有
  • 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の自動化は、セキュリティよりもノイズを生むことが多い
  • govulncheckと定期的テストに基づくアプローチのほうが、より正確で持続可能なセキュリティ管理方法だ
  • 記事執筆者のオープンソースメンテナンス活動は、Geomys組織を通じてAva Labs、Teleport、Tailscale、Sentryなどの支援を受けて継続されている
  • このようなモデルは、オープンソースエコシステムの安定的な維持とセキュリティ品質の向上に貢献する

関連記事

1件のコメント

 
GN⁺ 2026-02-21
Hacker Newsのコメント
  • Dependabotにはある程度価値がある
    ただし、単にバージョン番号と脆弱性DBを照合するだけのツールでは、その脆弱性に実際のコードがさらされているか判断できず、ノイズが多い
    最近感心したツールはCodeQL。GitHub Advanced Securityで実行でき、コードの実際のフローを追跡して、入力値が危険な使われ方に至る経路全体を視覚的に示してくれる
    そのおかげで実際に修正可能な情報が得られ、誤検知も少ない。もちろんPythonのような動的言語では検出を逃れられるコードもあるだろうが、ほとんどの場合は十分有用
    • 以前はCodeQLがプロジェクトの役に立っていたが、最近はあまりにうっとうしいレベルになったので、チームで無効化した
      ただCodeQLの警告を避けるためだけに、役に立たない中間変数を追加するようなコメントが出る。データに過剰適合したツールのように感じる
    • 「誤検知がほとんどない」という意見には同意しにくい。ライスの定理によれば、そんな完璧な解析は不可能だ
    • 私の経験では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数を減らすのは依然として難しい