サプライチェーンアタック対策とdependabot活用
注: 本記事は執筆時点(2026年4月)の情報をもとに書いています。実際のご利用にあたっては、公式ドキュメント等の最新情報を参照し、正確性を確認の上ご利用ください。
さて、axiosへの攻撃の件で、サプライチェーンアタックの恐ろしさを改めて感じさせられました。外部ライブラリを使う場合、基本的にはセキュリティ面も含めて最新バージョンを使いたいわけですが、その更新作業は脆弱性が入り込みやすいタイミングでもあるというジレンマがあるわけです。
なので、以下のようなポリシーとフローでの外部ライブラリ利用が現状の推奨要件と言えるでしょう。
- 基本は最新バージョンを使う
- 機能面、パフォーマンス、セキュリティ面でより良い
- 追随を怠ると更新が困難になり、新機能が使えないだけではなく、セキュリティリスクも高まる
- ただし、新バージョンリリース直後ではなく、しばらくしてから最新版を適用する
- 最新バージョンに問題が無いか様子見をしてから入れるということ
- 特に最近は単なるバグや脆弱性だけではなくmalwareが仕込まれるケースが出てきた
- 検証してから最新バージョンに更新する
- CIでテストが通るか・おかしな挙動が無いか確認してからコードベースに反映する
- その後、開発者の手元、本番環境でも更新をおこなう
特に2点目が最近よく言われるようになってきたポイントです。"Minimum release age" や "cooldown" と言われる、リリースから一定の期間経過後に最新バージョンを入れるというものです。dependabotやrenovateなどの更新ツール、JavaScript周辺のパッケージマネージャーは一通りそのための機能をすでに備えています。
3点目の「検証してから最新バージョンに更新する」も簡単に書きましたが、厳密に考えると少し厄介です。検証時点でmalwareが混入する可能性があるからです。今回のaxiosの件もまさにそういうケースでした。
そう考えると先程の要件を一通り満たすためには以下のプラクティスが必要です。
- 自動的にバージョンアップが促されるワークフローを構築する
- "Minimum release age" 設定ができるツールを利用する
- 秘匿情報にアクセスできない隔離された環境で新バージョンの検証を行う
これらをDependabotで実現する方法を紹介します。
Dependabotでの実践例
Dependabotを導入し、自動的にバージョンアップが促されるようにする
Dependabotは依存ライブラリ更新のワークフローを構築するGitHub組み込みの機能であり、無償で利用できます。定期的に依存関係の更新をチェックし、PRを起票してくれます。
以下のようなYAML設定を配置するだけで利用を開始できます。
# .github/dependabot.yml
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"
cooldown:
default-days: 7
上記はnpmに対して週次でチェックをするシンプルな設定例ですが、チェック頻度の変更、他のパッケージシステムでの利用、グルーピング設定なども出来ます。詳しくはドキュメントを参照ください。
Dependabot quickstart guide - GitHub Docs
cooldown項目でminimum release ageを設定する
先のYAMLの例の中にも書いていましたが、cooldown項目で、リリースから一定期間経過してから最新バージョンを入れるようにできます。これも細かい設定が可能で、例えば、一部のライブラリは除外したり、上がったバージョンがメジャーバージョンかマイナーかで期間を変えたりもできます。これもドキュメントを参照してください。
Dependabot options reference - GitHub Docs
dependabotが起票したpull request上で検証を行う
dependabotはpull requestの形でバージョンアップの提案をしてくれます。ですので、そのPR上のGitHub ActionsのCIワークフローで検証を行えます。
dependabotはリポジトリシークレットにアクセスできない
ここで嬉しいのは、このPR上のワークフローは外部のforkリポジトリからのPRと似たような権限モデルで動くことです。具体的にはリポジトリシークレットなどにはアクセスできないため、そこからトークン等が漏洩する心配はありません。GITHUB_TOKEN もデフォルトではread-onlyになります。
Dependabot が更新する依存パッケージには信頼できないコードが含まれる可能性があるため、fork からの PR と同等に扱うということなのでしょう。その点では、package.json などのバージョンファイルを開発者が更新してPRを起票するより、dependabotに任せた方が安全とも言えます。詳しくは以下を参照してください。
Troubleshooting Dependabot on GitHub Actions - GitHub Docs
github actions workflow runs that are triggered by dependabot from
push,pull_request,pull_request_review, orpull_request_review_commentevents are treated as if they were opened from a repository fork.
Dependency reviewと組み合わせる
パブリックリポジトリや、GitHub Advanced Security (GHAS) の契約がある場合、dependency reviewを使えば、PR上の依存関係変更に対するレビューを追加でおこなえます。具体的にはGitHub Advisory Databaseを参照し、依存関係に脆弱性がないかをチェックしてくれます。これもPR上で動くワークフローで実行できるため、問題がある場合に変更をブロックできます。
# .github/workflows/dependency-review.yml
name: Dependency Review
on: [pull_request]
permissions:
contents: read
jobs:
dependency-review:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v6
with:
persist-credentials: false
- uses: actions/dependency-review-action@v4
Dependency reviewには、自分たちのコードベースに望ましくないライセンスのコードの混入を防ぐ機能などもあります。OSSだと無償なので積極的に使うと良いでしょう。詳しくはドキュメントを参照してください。
About dependency review - GitHub Docs
ローカルマシンのリスク軽減
ここまで説明した通り、依存ライブラリの安全性を確認してから、各開発者のローカルマシンに展開していくのが安全なフローです。
ただ、開発者やローカルのコーディングエージェントがこのフローを守らず手元でうっかりアップデートしてしまう場合には無力です。それを防ぐためにはやはり、.npmrc など、手元の開発環境の設定も合わせてしっかりやることも重要です。
また、AIコーディングエージェントはかなり気軽にnpm install や pip install 等を実行するため、変なサイトに情報を流さないようにサンドボックス機能があるとやはり嬉しいところです。先日紹介したfenceのようなサンドボックスツールを活用するのも一つの方法でしょう。
コードベース窃取等の外部送信への対策
どこまで気にするかという話もありますが、今回のaxiosのようにシークレットを狙うのではなく、コードベースを丸ごと盗もうとするようなmalwareの場合には、上記の方法だけでは不十分です。ただ、こういった無差別型の攻撃の場合、攻撃者はコードベースよりシークレットを窃取しようとすることが多いため、気にするべきリスクの優先順位としては低くはなります。
ただ、その辺りも含めて外部への情報送信リスクを懸念するようであれば、CI環境で怪しいサイトへの通信をブロックすることでリスクを低減できます。GitHub ActionsのGitHub-hosted runnerの場合、etc/hosts ファイルのプロビジョニングで怪しいサイトへの通信はブロックするという基本的な対策は入っています。
更に追加で自分たちで監査したり、許可・拒否リストの管理をしたいケースでは、サードパーティのStepSecurityのHarden-Runnerなどの導入が手軽ですが、プライベートリポジトリの場合は有料です。他には、GitHub Actionsからの外部通信をAzure private networking経由にする方法やSelf-hosted runnerで自分たちでしっかりネットワーク制限をかける方法もありますが、運用コストは上がります。
これについての本命として、GitHubも最近発表したセキュリティロードマップの中で、"Native egress firewall for GitHub-hosted runners" を年内くらいのターゲットで提供予定であることを公表しているので、期待したいところです。それ以外の下記の記事に記載されているロードマップ機能にはいずれも期待しています。