サプライチェーン攻撃

標的組織を直接攻撃するのではなく、取引先・委託先や、利用しているソフトウェアの依存関係・配布経路といった「供給網(サプライチェーン)」上の弱い箇所を経由して侵入・被害を及ぼす攻撃の総称。侵入口を直接守っていても、供給網の別の場所が破られると影響が及ぶ点が特徴。

#security #supply-chain-attack #moc

大別すると2種類ある

  • 取引先・委託先経由型: 標的企業のセキュリティが堅くても、取引先や委託先企業のシステムが侵害され、そこを踏み台に、あるいは業務停止という形で影響が波及する。小島プレス工業の事案が代表例。
  • ソフトウェア・OSS依存関係型: パッケージレジストリ(npm/crates.io/PyPI等)で配布されるライブラリそのものが乗っ取られ、それに依存する無数のプロジェクトへ悪意あるコードが伝播する。arrayref Rustクレートの事案が代表例。

事例

ビルドツール自体が運び屋になる型

依存パッケージやレシピではなく、ビルドに使うツールのバイナリ側を汚染する型もある。trusting trust攻撃がその原型で、汚染されたコンパイラが自分の後継バイナリに汚染を再注入し続けるため、ソースをいくら監査しても見つからない。2026年にはstripを運び屋にした攻撃がNixOSのブートストラップ上で実証され、コンパイラ以外のビルドユーティリティでも同じことが成立すること、そして再現可能ビルドやSLSA的なattestationがこの型には発火しないことが示された。

標準・対策の枠組み

  • OWASP Top 10:2025は「A03:2025 Software Supply Chain Failures」として、依存関係・ビルドシステム・配布インフラ全体のリスクを独立カテゴリに格上げしている。
  • OpenSSFの「Alpha-Omega」プロジェクトはOSSのサプライチェーンセキュリティ改善を目的とした大規模な取り組み。
  • vlt (vōlt)のように、パッケージインストール時にマルウェア・不正パッケージをスキャン・ブロックする機能を持つツールも登場している。

「何が入っているか」「どう作られたか」「誰が署名したか」の3つを押さえるのが基本線で、それぞれに対応する枠組みがある。

  • SBOM — 成果物に含まれるコンポーネントを機械可読に列挙する。影響範囲の特定に使う。
  • SLSA — ビルドパイプラインの改竄耐性をレベルで表現し、provenance(どう作られたか)を機械可読に証明する。
  • Sigstore — 長期保管する秘密鍵なしで成果物に署名・検証する仕組み。SLSAのprovenance署名の実装手段としても使われる。
  • in-toto — 「アーティファクトについての署名された主張」を表現する共通フォーマット。SLSA provenanceもSBOMもVEXもこの器に載る。
  • VEX — 「入ってはいるが影響しない」という判断とその根拠を機械可読に流通させる。SBOMを補完する。
  • TUF — 更新の配布側で、鍵の漏洩やリポジトリ侵害があっても被害範囲が閉じるようにロールと鍵を分割する枠組み。
  • 透明性ログ — 署名や発行の記録を追記専用の公開ログに載せ、「不正をしたら必ず観測される」状態を作る。
  • DSSE — 上記の主張群に署名するための共通エンベロープ形式。JSONの正規化問題を「正規化しない」ことで回避する。

事例としてのLog4Shell

Log4Shell (CVE-2021-44228)は、攻撃そのものはサプライチェーン攻撃ではないが、「推移的依存として広く埋め込まれたライブラリの脆弱性に、誰も影響範囲を即答できない」という問題を可視化した。SBOMが調達要件として広がる直接の契機になっている。

攻撃面そのものを減らすアプローチ

依存を検査するのではなく、そもそも余計なものを持ち込まない方向の対策もある。

  • distroless — コンテナイメージからシェル・パッケージマネージャ・コアユーティリティを取り除き、攻撃面とCVEノイズを減らす設計。
  • Chainguard / Wolfi — OSSアーティファクトをソースから再ビルドして配ることで、アップストリームのビルド済みバイナリを信頼せずに済ませる商用サービスとその基盤ディストリビューション。

🔗 リンクされているノート

作成日時: 2026-08-21 07:57 / 更新日時: 2026-09-06 01:15