サプライチェーン攻撃

サプライチェーン攻撃とは何か

現代のソフトウェアは、自社で 1 から書く部分はごく一部で、大半は外部から取り込んだ部品で出来ています。オープンソースのライブラリ、パッケージ、コンテナイメージ、ビルドツール、CI/CD のプラグイン――こうした「調達してくるもの」全体がソフトウェアサプライチェーンです。

サプライチェーン攻撃は、この調達過程のどこかを汚染し、そこを信頼して取り込む多数の利用者をまとめて侵害する攻撃です。攻撃者は、堅牢に守られた標的を正面から破るのではなく、標的が信頼して使っている部品を狙います。

恐ろしいのは被害の連鎖です。広く使われるライブラリ 1 つにバックドアを仕込めれば、それを取り込んだ何千ものアプリやサービスが一斉に汚染されます。自社のコードをいくら堅牢にしても、信頼して取り込んだものが汚染源なら、防御は素通りされてしまいます。

どこが狙われるのか

汚染の入口は 1 つではありません。「信頼して取り込む接点」すべてが攻撃面になり得ます。

狙われる箇所	手口の例
依存ライブラリ	人気パッケージの乗っ取り、悪意ある更新の公開
パッケージ名	正規名と紛らわしい名前を登録する（typosquatting）
ビルド環境	CI/CD を侵害し、ビルド時に悪意あるコードを混入
配布経路	正規の配布物を途中ですり替える
開発者の認証情報	メンテナのアカウントを乗っ取り、正規名義で公開

特に厄介なのが、正規の更新を装った汚染です。普段から信頼している人気ライブラリが、ある日のアップデートでこっそり悪意あるコードを含む――利用者は「いつもの更新」と思って取り込むため、気づきにくいのです。ビルド環境（CI/CD）の侵害も深刻で、ソースコード自体は綺麗でも、ビルドの瞬間に改ざんが混入すると、出来上がった成果物だけが汚染されます。

間接依存（推移的依存）も攻撃面

自分が直接選んだライブラリだけでなく、**そのライブラリが内部で使っている依存（推移的依存）**も汚染源になります。直接依存が 10 個でも、芋づる式にたどると数百個に膨らむことは珍しくありません。「自分は信頼できるものしか入れていない」と思っていても、その奥に何が潜んでいるかは別問題です。依存ツリー全体を見える化する必要があります。

対策の柱：見える化・検証・固定

防御の基本発想は、「取り込む前に検証する」「何を取り込んだか把握する」ことです。主な対策を整理します。

対策	何をするか	効果
SBOM	使っている部品を一覧化する	脆弱性公表時に「自分が影響を受けるか」を即判断
署名と検証	成果物に署名し、取り込み側で検証	途中ですり替えられた偽物を弾く
バージョン固定	依存を特定バージョンに固定	勝手な更新で汚染版が入るのを防ぐ
依存スキャン	既知脆弱性を自動チェック	危険な依存を早期に発見

**SBOM（Software Bill of Materials／ソフトウェア部品表）**は、料理でいう「原材料表示」です。どのライブラリのどのバージョンを使っているかを一覧化しておけば、新しい脆弱性が公表されたとき「自分のシステムに影響があるか」を即座に判断できます。SBOM がなければ、世界的な脆弱性が出るたびに手作業で棚卸しする羽目になります。

署名と検証は、配布物が途中ですり替えられていないかを確かめます。発行元が成果物に電子署名し、取り込む側がそれを検証することで、正規の発行元が作った、改ざんされていないものだけを通せます。

対策の柱：依存とビルド経路を守る

部品を「固定」し、ビルドの過程そのものを守ることも欠かせません。

バージョンの固定（ロックファイル）：package-lock.json や同等のロックファイルで、依存をハッシュ付きで特定バージョンに固定します。これにより、ある日突然新しい（汚染された）版が入り込むのを防ぎます。
依存スキャンの自動化：既知脆弱性を持つ依存を、CI で取り込み時に自動チェックします。npm audit や OWASP Dependency-Check のようなツールが該当します。
ビルド環境の保護：CI/CD に渡す権限を最小権限に絞り、シークレットを安全に管理し、ビルド工程を改ざんされにくくします。
取り込み元の信頼：パッケージ名のタイプミス（typosquatting）に注意し、信頼できるレジストリ・ミラーから取得します。

# ロックファイルが依存を「名前＋バージョン＋ハッシュ」で固定する概念
# fences 内なので記号をそのまま書ける
left-pad@1.3.0  sha512-...（このハッシュと一致しなければ取り込まない）

完全な防御より「素早く気づける」体制を

サプライチェーンは外部に依存する以上、汚染をゼロにするのは困難です。だからこそ、SBOM で何を使っているかを常に把握し、脆弱性が公表されたときに「影響範囲を即特定して素早く対応できる」体制が現実的な要になります。加えて、依存は必要最小限に絞る（使わないものは入れない）、更新は内容を確認してから取り込む、といった日々の規律が効きます。

まとめ

サプライチェーン攻撃は、自社のコードではなく、信頼して取り込む調達過程（依存ライブラリ、ビルド経路、配布物など）を汚染し、多数の利用者を一度に侵害する攻撃です。自社の守りが堅くても、汚染された部品を取り込めば素通りされ、被害が連鎖的に広がります。

対策は、SBOM による見える化、署名と検証、バージョン固定と依存スキャン、ビルド経路の保護を組み合わせ、「取り込む前に検証し、取り込んだ後も把握し続ける」体制を作ることです。これは最小権限やシークレット管理と地続きの取り組みであり、攻撃面の全体像は OWASP Top 10 と合わせて捉えると位置づけが明確になります。

サプライチェーン攻撃