サプライチェーン攻撃の仕組み — 信頼の連鎖が崩れるとき

レストランに例えるとわかりやすいよ。料理人がどんなに衛生管理を徹底しても、仕入先から届いた食材にすでに毒が混入されていたら防げないよね。ソフトウェアでも同じで、自分のコードは安全でも、使っているライブラリやツールが汚染されていたら、そこから攻撃が広がるんだ。

あるよ。現代のソフトウェア開発では、npmやPyPIといったパッケージレジストリからライブラリをダウンロードして使うのが当たり前だよね。さらにGitHub ActionsなどのCI/CDツールでビルドやデプロイを自動化している。こうしたライブラリやツールの提供元すべてが「サプライチェーン」なんだ。

代表的な手口がいくつかあるよ。まず「パッケージ乗っ取り」。npmやPyPIで人気のあるパッケージの管理者アカウントを侵害して、悪意のあるコードを仕込んだバージョンを公開するんだ。利用者がいつも通りアップデートするだけで感染する。

「タイポスクワッティング」は、有名なパッケージによく似た名前の偽パッケージを登録する手口だよ。たとえば「lodash」を「lodahs」にするとか。タイプミスした開発者が間違ってインストールしてしまう。あと「依存関係混乱攻撃」もあって、企業が社内で使っているプライベートパッケージと同じ名前を公開レジストリに登録して、ビルドシステムに公開版を優先的に取得させるんだ。

あるよ。2026年1月にはセキュリティスキャンツールのTrivyでまさにこれが起きたんだ。GitHub Actionsで使うアクションのタグを攻撃者が書き換えて、本来のコードとは違う悪意あるコードが実行されるようにした。タグは同じ名前のままだから、利用者側からは変更があったことすら気づけないんだよ。

サプライチェーン攻撃の厄介なところは、「信頼済み」のコードとして実行されることなんだ。ウイルス対策ソフトもファイアウォールも、正規のパッケージマネージャ経由でインストールされたコードは基本的に信頼する。攻撃者はその信頼の仕組みそのものを悪用しているから、従来のセキュリティ対策では見つけにくいんだよ。

いくつか対策があるよ。まず「バージョンピン留め＋ハッシュ検証」。依存パッケージのバージョンを固定して、さらにパッケージのハッシュ値を記録しておけば、中身が書き換えられたら検知できる。npmならpackage-lock.json、Pythonならpip freezeとハッシュ検証が使えるね。

「SBOM（ソフトウェア部品表）」を管理するのも大事だよ。自分のアプリがどのライブラリのどのバージョンに依存しているかを一覧にしておく。脆弱性が見つかったとき、影響範囲をすぐ特定できるんだ。あとCI/CDでは「最小権限の原則」が重要で、ビルドに使うトークンの権限を必要最低限にしておけば、万が一パイプラインが侵害されても被害を限定できる。Sigstoreやcosignによる署名検証も普及してきているよ。

歴史を振り返ると、2020年のSolarWinds事件が転換点だね。ネットワーク監視ツールのビルドシステムが侵害されて、米国政府機関を含む18,000以上の組織にバックドアが配布された。2021年のLog4Shellは、Javaの超定番ログライブラリLog4jにゼロデイ脆弱性が見つかって世界中が大混乱した。2024年にはLinuxの圧縮ツールxz-utilsに、数年がかりで信頼を築いたメンテナーがバックドアを仕込んでいたことが発覚して衝撃を与えたんだ。

実はOSSの信頼モデルには根本的な課題があるんだ。世界中の企業が何十億ドルもの利益を上げているシステムの土台に、個人がボランティアでメンテナンスしているライブラリがある。xz-utils事件では、たった一人の疲弊したメンテナーに攻撃者が「手伝うよ」と近づいて権限を得た。技術的な対策だけでなく、OSSのメンテナーを持続的に支援する仕組み — OpenSSFやGitHub Sponsorsのような取り組み — が本質的に重要なんだよ。信頼の連鎖を守るには、その連鎖を支えている人たちを守る必要があるんだね。