Goライブラリのメンテナーは、依存関係スキャンツールの誤検知が「アラート疲れを引き起こしてセキュリティを低下させる」として、開発者にGitHubのDependabotをオフにするよう促した。
かつてGoogleのGoセキュリティチームを率いていたFilippo Valsordaは、現在Go標準ライブラリの暗号化パッケージを保守している。
先週、彼が保守するライブラリの1つであるfilippo.io/edwards25519（EdDSA（Edwards-curve Digital Signature Algorithm）暗号化に使用される）のセキュリティ修正をリリースした。その結果、Dependabotは「影響を受けていないリポジトリに対して数千のPR [プルリクエスト]を開いた」とValsordaは述べた。
自動化プロセスはまた、Valsordaが「無意味ででっち上げられたCVSS [Common Vulnerability Scoring System] v4スコア」と呼ぶものを生成し、修正が「誰も使わないメソッドの1行」であったにもかかわらず、73パーセントの互換性スコアを警告し、コードが壊れる可能性が27パーセントあることを示唆した。
このライブラリに依存する最も一般的な理由は、Go MySQLデータベースドライバがそれを使用していることであるが、修正された関数（MultiScalarMult）を呼び出さないため、影響を受けていない。ValsordaはGitHubツールを「ノイズマシン」と呼び、それをオフにすることを勧めた。
Dependabotは第三者ツールとして始まり、2019年5月にGitHubが買収した。GitHub Advisory Databaseのデータを使用して、リストされた脆弱性に依存するリポジトリでプルリクエストとセキュリティアラートを自動化する。
ValsordaはDependabotはその目的に対してあまりにもうるさく、かつ不十分であると述べた。依存関係が存在するかどうかのみをチェックしているようであり、影響を受ける関数またはコードパスが実際に使用されているかどうかではないため、あまりにもうるさい。
「まともな脆弱性スキャナーは、最低でもパッケージに基づいてフィルタリングする」と彼は述べた。さらに、彼はgovulncheck（Go脆弱性の場合）のような静的分析ツールを使用することを推奨し、欠陥の到達可能性を識別する。
ValsordaはDependabotがうるさいにもかかわらず、本当の脆弱性は「その影響について評価されるべきだ：本番環境の更新が必要かもしれない、秘密がローテーションされた、ユーザーに通知される」ため不十分だとも述べた。開発者がDependabotに依存して依存関係の脆弱性を管理する場合、彼らは十分なことをしていない。
ValsordaはまたDependabotの別の機能も嫌っている：依存関係を最新バージョンで最新に保つこと。彼は、パッケージの新しいバージョンが表示されるたびにではなく、プロジェクトの開発サイクルに従って依存関係を更新すべきだと主張している。パッケージに悪意のあるコードが追加されている場合、素早く更新することにもいくつかのリスクがある。
彼は、本番コードを更新することなく問題を発見するために、サンドボックス化された継続的インテグレーションプロセスで更新されたパッケージをテストすることを推奨している。
この主題に関するHacker Newsの議論は、顧客が微妙なニュアンスを理解していない可能性があるが、Valsordaのポイントについて広範な合意を見つけた。
「顧客はこれらのツールであなたのコードをスキャンし、「私たちはその機能を呼び出さなかった」を答えとして受け入れないだろう…これは実際のセキュリティがセキュリティの名前の下に開発した慣行から本当に分岐し始めるところだ」とあるコメントは述べた。
Dependabotのコストはその代わりに何が置かれるかに応じて異なるという見方もある。Goエコシステムは依存関係チェック用に十分にセットアップされており、Valsordaは開発者が使用できる他のツールとプロセスについて説明している。他の場合には、リソースが限定されており明らかな代替がない場合、Dependabotはそれが対処する問題を無視するよりもおそらく良いだろう。®
翻訳元: https://go.theregister.com/feed/www.theregister.com/2026/02/24/github_dependabot_noise_machine/
