世界を動かす技術を、日本語で。

Dependabotをオフにする

概要

Dependabotによる自動アラートは、Goエコシステムではノイズが多く有用な作業を妨げることが多い。 govulncheckなどの静的解析ベースの脆弱性スキャナへの切り替えが推奨される。 依存関係の更新は開発サイクルに合わせ、CIで最新依存関係のテストを行う運用が安全。 過剰なアラートはセキュリティ対策の質を下げ、オープンソース維持にも負担を与える。 GitHub Actionsによる自動化で、実際に対応が必要な脆弱性のみ通知できる体制構築。

Dependabotの課題とGoエコシステムへの影響

  • Dependabot は大量のプルリクエストとアラートを自動生成し、 本質的でない作業 を増やす要因
  • セキュリティアラートの多くが 実際には無関係なリポジトリ にも通知される現状
  • Goエコシステムでは、 パッケージ単位での依存分離 が一般的なため、影響範囲の誤認が頻発
  • 例: filippo.io/edwards25519 の脆弱性修正時、無関係なリポジトリにも 偽陽性アラート が発生
  • CVSSスコアや互換性スコアも 誤解を招きやすい 情報源

静的解析ベースの脆弱性スキャナの有効性

  • Go Vulnerability Database はバージョン・パッケージ・シンボル単位で 詳細なメタデータ を提供
  • govulncheck は静的解析により、 実際に到達可能な脆弱性のみ通知
    • パッケージレベルでのフィルタリングで 誤検知の大幅削減
    • シンボルの到達性まで解析することで 本当に影響のある脆弱性のみ抽出
  • CLIやGo APIとして 容易にCIへ組み込み可能

govulncheck GitHub Actionの導入例

  • Dependabotの代替として govulncheckを定期実行するGitHub Action を推奨

  • 必要なGitHub Actionsワークフロー例:

    name: govulncheck
    on:
      push:
      pull_request:
      schedule:
        - cron: '22 10 * * *'
      workflow_dispatch:
    permissions:
      contents: read
    jobs:
      govulncheck:
        runs-on: ubuntu-latest
        steps:
          - uses: actions/checkout@v5
            with:
              persist-credentials: false
          - uses: actions/setup-go@v6
            with:
              go-version-file: go.mod
          - run: |
              go run golang.org/x/vuln/cmd/govulncheck@latest ./...
    
  • 実際に注意が必要な脆弱性のみ通知 され、アラート疲労を防止

アラート疲労とオープンソースへの影響

  • 誤検知や低価値なアラート は時間の浪費だけでなく、 本当のセキュリティリスクへの対応品質を低下
  • オープンソースメンテナへの 不必要な依存更新要請 が増加し、 持続可能性を損なう
  • 正しい運用 :プロジェクトが実際に脆弱性の影響を受けていないことを確認する責任
  • スキャナには 誤検知を抑制する責任 がある

依存関係の更新とCIでの最新テスト

  • Dependabotによる 自動更新は開発サイクルと乖離しやすい ため、CIでの 最新依存関係テスト が推奨

  • goでの運用例:

    name: Go tests
    on:
      push:
      pull_request:
      schedule:
        - cron: '22 10 * * *'
      workflow_dispatch:
    permissions:
      contents: read
    jobs:
      test:
        runs-on: ubuntu-latest
        strategy:
          fail-fast: false
          matrix:
            go:
              - { go-version: stable }
              - { go-version-file: go.mod }
            deps:
              - locked
              - latest
        steps:
          - uses: actions/checkout@v5
            with:
              persist-credentials: false
          - uses: actions/setup-go@v6
            with:
              go-version: ${{ matrix.go.go-version }}
              go-version-file: ${{ matrix.go.go-version-file }}
          - uses: geomys/sandboxed-step@v1.2.1
            with:
              run: |
                if [ "${{ matrix.deps }}" = "latest" ]; then
                  go get -u -t ./...
                fi
                go test -v ./...
    
  • 依存関係更新による問題の早期検知サプライチェーン攻撃リスクの緩和

  • CIサンドボックス(geomys/sandboxed-step)による 安全性向上

まとめと推奨運用

  • Dependabotのノイズを抑制 し、 govulncheck等の静的解析スキャナ を利用
  • 依存関係は 開発サイクルに合わせて一括管理CIで最新依存関係のテスト を実施
  • 本当に対応が必要な脆弱性のみ通知 される体制構築で、 セキュリティ・開発効率の両立
  • オープンソース維持の持続可能性と、 開発者・利用者双方の負担軽減

参考情報や最新の意見 はBluesky(@filippo.abyssdomain.expert)やMastodon(@filippo@abyssdomain.expert)を参照。 Geomys によるプロフェッショナルなGoメンテナンスやパートナー企業(Ava Labs, Teleport, Tailscale, Sentry)のサポート体制も紹介。

Hackerたちの意見

GovulncheckはGoエコシステムの中でも最高の機能の一つだよ!GitHubアクションを作って、PRに脆弱な呼び出しが追加されたらアラートが出るようにしたんだけど、これは脆弱な呼び出しを実際に修正するアドバイスと相性がいいと思う。 https://github.com/imjasonh/govulncheck-action GHAで標準のツールを実行することもできるけど、PR内でアノテーションやコメントがもらえるのが好きだったな。ちなみに、そのリポジトリはDependabotが有効になってて、PRは自動マージされるから、JSコードベースにはこれが一番いいと思う。

Dependabotのアラートで見るReDoSの脆弱性が、クライアントコードでしか使ってないNPMパッケージに対しては異常だよ。パッケージがバックエンドで動いているかどうかを考慮した修正があればいいのに。クライアント側のReDoSは全然関係ないからさ。

本当に!これには我々も悩まされてる。場合によってはDev依存関係のせいだけど、ReDoSからのノイズがどれだけひどいかは信じられないよ…

正直、DoSは脆弱性として扱うのをやめるべきだと思う。これは可用性の問題で、可用性はCIAの一部ではあるけど、実際にはセキュリティの領域というよりもセキュリティの原則に近い。実際には、可用性はセキュリティの問題よりも運用やエンジニアリングの問題として分類する方がずっと適切だし、DoSをセキュリティの問題として扱うことは、助けるよりもはるかに多くの害をもたらす。DoSを特別扱いするのは、ただの歴史的な遺物だと思う。

lintingやCIでnpm-better-auditみたいなものを使うと、devDependenciesを除外できるから、ノイズがかなり減るよ。viteサーバーの脆弱性なんて気にしないし。

debugを管理してるけど、意味不明なReDoSの脆弱性レポートがたくさん来るんだ(CVSSスコアが高いCVEも含まれてるけど、私には一切開示されてない)。それが原因で、JSの世界から完全に引き下がりたくなってる。

JSエコシステムに同じようなものはあるの?もしないなら、Dependabotがクールダウン後に自動で依存関係を更新するのがまだマシな選択肢だと思う。自動じゃないと、依存関係を全く更新しない可能性が高いからね。

Dependabotのクールダウンが本当に頭悪いのが残念。1週間のクールダウンを設定して、依存関係がうまくいかなくて毎日リリースしてたら、リリースのペースに何の魅力もないのに、1週間後に最初の(古い)リリースのPRが作られ始めるんだよ。

RenovateBotはたくさんの言語をサポートしてるし、私の経験ではnpmエコシステムにはDependabotよりもずっと良く機能するよ。特にyarnやpnpmのような代替パッケージマネージャーを使ってるならね。

我々はモダンなDependabot(またはそれと連携する)エージェントを作ったよ:fossabotはアプリのコードを分析して、依存関係の使い方を把握してから、アップグレードごとにカスタムの安全性/レビューが必要な判定を出すんだ。安全なアップグレードをまとめて、より戦略的なジャンプができるようにすることもできる。エージェントのコンテキストがとても充実しているから、破壊的な変更も修正できるよ。 https://fossa.com/products/fossabot/ このユースケースに特化したカスタム静的解析エンジンを基にした、最高のJS/TS分析があるんだ。毎月無料クレジットがもらえるし、次にどのエコシステムがいいかフィードバックもらえると嬉しいな…Java、Python?著者が言ってるように、govulncheckのような静的解析がこの問題の成功の秘密兵器だと思う!動的言語は本当に難しいからね。すごくクールなevalフレームワークもあって、それについてもブログに書いたよ。

PythonとGoは素晴らしいユースケースになると思う。

あなたたちのエージェントの名前が、確立された人気のストリーミングボット/ツールと衝突してるの知ってる? https://fossabot.com

Rustのためにこれが見たいな!

DependabotのPRに関する分析の例: https://github.com/daniellockard/tiltify-api-client/pull/36#...

Dependabotがリポジトリのコントリビューターアクセスがあるときに見える別のタブだったらいいのにな。メールはうざいし、ほとんどフィルタリングしてるけど、古いPRがたくさん残ってるのも嫌なんだよね…役に立つけど、数時間だけこういう問題に取り組みたいときだけに限定してほしいな。

Dependabotがいつ実行されるか、同時に開くPRの数を調整するためにdependabot.ymlの設定を追加できるよ。https://docs.github.com/en/code-security/reference/supply-ch...

refined github extensionは、デフォルトの表示をちょっとマシにしてくれる設定があるよ。あとは、個人的にはRenovateをおすすめするね。こっちはもっと多くのエコシステムとカスタマイズオプション(自動マージとか)に対応してるから。[0]: https://github.com/refined-github/refined-github

Dependabotはすごく役立つと思う。イライラさせられるけど、依存関係を絶対に最小限に保つことの重要性を思い出させてくれる。

これはかなり良いアドバイスだと思う。Dependabotは、スケジュールされた依存関係のバンプを管理するのに役立つ(それがAPIの変更を見つけるのにも役立つし、意図しないsemverの破損も含まれる)けど、Dependabotの組み込みの脆弱性スキャンは、ほとんどのエコシステムの独自の組み込みソリューションよりも明らかに劣ってる。

カスタムGithub Actionsのアプローチは、すごくカスタマイズ可能で柔軟だよ。理論的には、自動でバンプを承認することもできるし、もっと構造的なものが欲しいなら、Renovateを試してみて!(関係ないけどね)Renovateはもっと多くのエコシステムに対応してるし、コミュニティも良いし、カスタマイズもできる。使ってみたら、Dependabotがどれだけ使えないかに驚いたよ。デフォルトのツールなのに、なんでこんなのを我慢してるんだろう。例えば、マルチレイヤーのDockerfileみたいなシンプルなものがあるけど、これってもうしばらくDockerの機能なのに、Dependabotではサイレントにサポートされてないんだよね!

競争がないとこうなるんだよね。Githubは根付いてしまって、 complacent(無気力)になってる。

もうこの段階では、GitHub Actionsのセキュリティの火事はスキップしちゃっていいよ。GitHubのWebhookを聞きながら、goコマンドを実行して、GitHubのチェックAPIでチェックを更新すればいいだけ。GitHub Actionsがこのセットアップの中で一番のセキュリティリスクだと思う。正直、そんなに複雑じゃないよ。

この部分がちょっと引っかかってるんだよね: > これらのPRには、意味不明な作り話のCVSS v4スコアと、エコシステムでの更新による壊れ具合に基づく73%の互換性スコアを伴うセキュリティアラートがあった。CVSSスコアは一体どこから来たの?Dependabotは自動でCVEを生成するの?