サプライチェーン攻撃

概要

サプライチェーン攻撃は、標的そのものを直接攻撃するのではなく、標的が信頼して取り込んでいる「供給網」— 依存ライブラリ、開発ツール、ビルド基盤、配布経路 — を汚染することで、間接的に標的へ悪意あるコードを届ける攻撃です。製造業で部品の供給網をサプライチェーンと呼ぶことになぞらえ、ソフトウェア開発の部品供給網を狙うことからこの名が付きました。

この攻撃が防御側にとって厄介なのは、「自分のコードをどれだけ堅牢に書いても防げない」ことです。現代のアプリケーションは、自分で書いたコードよりも取り込んだコードのほうが圧倒的に多いのが普通です。npm のプロジェクトで依存ツリーを展開すれば、直接依存の数十パッケージの裏に間接依存が数百〜数千個ぶら下がります。そのすべての作者・メンテナ・公開基盤を信頼していることになり、攻撃者から見ればどこか一箇所の最も弱い環を突けばよいのです。

なぜ生まれたか

背景にあるのは、ソフトウェア開発の生産性がコードの再利用の上に成り立っているという構造そのものです。パッケージレジストリ（npm、PyPI、RubyGems など）の普及により、一行のインストールコマンドで世界中の誰かのコードを取り込めるようになり、開発速度は劇的に向上しました。しかしこのエコシステムは「公開されているコードは善意で書かれている」という暗黙の信頼で動いており、その信頼を検証する仕組みは後回しにされてきました。

一方で防御側の進歩が、攻撃者を供給網へ向かわせました。正面からの攻撃が脆弱性管理やWAFの普及で難しくなるにつれ、「標的が自分から実行してくれるコードに混入する」経路の費用対効果が相対的に上がったのです。象徴的な事件が2020年の SolarWinds 事件で、ネットワーク管理製品のビルド基盤に侵入した攻撃者が正規の署名付きアップデートにバックドアを仕込み、それを適用した米政府機関を含む多数の組織が侵害されました。npm の世界でも2018年の event-stream 事件 — 多忙なメンテナから善意を装って引き継いだ人物が、暗号通貨ウォレットを狙うコードを依存パッケージ経由で混入させた事件 — が、「メンテナの信頼」自体が攻撃対象になることを示しました。

詳細

攻撃経路の全体像

防御を考えるには、まず「どこが汚染されうるか」を経路として整理するのが近道です。コードが書かれてから本番で動くまでの各段階に、それぞれ固有の攻撃面があります。

依存パッケージの段階では、人気パッケージと一文字違いの名前で偽物を公開する「タイポスクワッティング」や、社内パッケージと同名のものを公開レジストリに置いて取り違えを誘う「依存関係かく乱（dependency confusion）」が代表的です。メンテナ自身が標的になることもあり、アカウントの乗っ取りや、event-stream 事件のような悪意ある引き継ぎがここに入ります。ビルド基盤の侵害は最も深刻で、ソースコードが正しくてもビルド時に改ざんされれば、署名付きの「正規の」成果物として汚染コードが配布されます。

防御の第一層 — 依存を固定し、監査する

防御の出発点は「何に依存しているかを把握し、それが勝手に変わらないようにする」ことです。ロックファイル（package-lock.json など）は全依存のバージョンとハッシュを固定し、レジストリ上のパッケージが差し替えられても取得時の検証で検知できるようにします。ロックファイルは必ず Git にコミットし、CIでは lockfile どおりに厳密インストールする（npm なら npm ci）のが基本です。その上で、npm audit や Dependabot のような依存監査ツールで既知の脆弱性を継続的にスキャンします。ただし「自動で最新に上げ続ける」ことは、汚染された新バージョンを即座に取り込むリスクとも表裏一体です。公開直後のバージョンを避けて一定期間置いてから更新する、更新のdiffを確認するなど、速度と検証のバランスを取ります。バンドラによるビルドを経る場合、最終成果物に何が含まれたかが見えにくくなる点にも注意が必要です。

防御の第二層 — SBOM・署名・ビルドの信頼性

一歩進んだ対策が、供給網そのものの透明性と検証可能性を高めることです。SBOM（Software Bill of Materials: ソフトウェア部品表）は、成果物に含まれる全コンポーネントの一覧で、インシデント発生時に「うちはこの汚染パッケージを使っているか」を即答するための土台になります。成果物への署名（Sigstore/cosign など）と、ビルドの来歴（provenance）の記録は、「この成果物は確かにこのソースからこのCIでビルドされた」ことを検証可能にします。SLSA のようなフレームワークは、ビルド基盤の信頼性を段階的に高める指針を提供しています。いずれも根底にあるのは、「信頼する」から「検証できる」への転換であり、これはゼロトラストの思想を供給網に適用したものです。

防御の第三層 — 被害を閉じ込める

汚染を完全には防げない前提で、実行される場所の権限を絞ることも欠かせません。CI/CD パイプラインは供給網攻撃の主戦場であり、ここで盗まれた認証情報が次の攻撃の足がかりになります。CIジョブには最小権限の原則を徹底し、長期の認証情報を置かず（シークレット管理の基盤や短命トークンを使う）、サードパーティのCIアクション・プラグインもバージョンをハッシュで固定します。インストール時に任意コードが走る仕組み（npm の postinstall スクリプトなど）は無効化やサンドボックス化を検討します。依存を一つ増やすことは、その作者と供給網を丸ごと信頼することだ — この感覚を開発チームで共有することが、あらゆるツールに先立つ防御になります。