# ソフトウェアサプライチェーン攻撃とは？OWASP A03:2025の要点と対策

OWASP Top 10 2025のA03「Software Supply Chain Failures」をもとに、ソフトウェアサプライチェーン攻撃の仕組みと実例、脆弱になりやすい状態、SBOMによる把握、npm ciやnpm audit signaturesを使った依存関係の守り方を開発者向けに解説します。

ソフトウェアサプライチェーン攻撃は、アプリそのものではなく、アプリが使うライブラリ・ビルド環境・配布の仕組みを狙う攻撃です。OWASP Top 10の2025年版では、A03「Software Supply Chain Failures（ソフトウェアサプライチェーンの失敗）」として、旧「脆弱で古くなったコンポーネント」を広げたカテゴリになりました。

<Points>

- 依存ライブラリだけでなく、IDE・リポジトリ・CI/CD・成果物の置き場まで含めた「作って届ける過程」全体が対象
- OWASPのコミュニティ調査では回答者のちょうど50%が1位に挙げた、最も懸念されているカテゴリ
- 対策は「把握する（SBOM）」「変更を追う」「関わるシステムを固める」の3本柱

</Points>

## ソフトウェアサプライチェーン攻撃とは

OWASPは、このカテゴリを「ソフトウェアを作り、配布し、更新する過程での不備や侵害」と定義しています。多くは、脆弱な、あるいは悪意のあるサードパーティのコード・ツール・依存関係が原因です。

自分たちのコードに問題がなくても、取り込んだ部品や、それを組み立てる仕組みが侵害されれば、利用者には正規の更新として悪意のあるコードが届きます。

<Flow
  title="サプライチェーンのどこが狙われるか"
  steps={[
    { label: "開発者の端末・IDE", note: "拡張機能や端末の乗っ取り" },
    { label: "コードリポジトリ", note: "秘密情報の混入、保護されていないブランチ" },
    { label: "依存パッケージ", note: "脆弱なバージョンや悪意のある版" },
    { label: "ビルド・CI/CD", note: "パイプラインの改ざん" },
    { label: "成果物・配布", note: "署名のない成果物の差し替え" },
  ]}
/>

この題材は2013年版のA9「Using Components with Known Vulnerabilities」から続くもので、2025年版で「既知の脆弱性」に限らずサプライチェーンの失敗全体へ範囲が広がりました。

<Stats source="OWASP Top 10:2025 A03 Software Supply Chain Failures">
<Stat value="50%" label="コミュニティ調査でこのカテゴリを1位に挙げた回答者の割合" />
<Stat value="6" label="対応づけられたCWEの数" />
<Stat value="215,248" label="データ上の総出現数" />
</Stats>

OWASPは、このカテゴリをデータ上の平均発生率が最も高いカテゴリとしています。一方で、対応づけられたCVEは11件にとどまります。

## 実際に起きた例

OWASPは攻撃シナリオとして、次の事例を挙げています。

<Figure title="OWASPが挙げるサプライチェーンの事例" source="OWASP Top 10:2025 A03">

| 事例 | 何が起きたか |
| --- | --- |
| SolarWinds（2019年） | 信頼されたベンダーがマルウェアで侵害され、更新を通じて約18,000の組織に届いた |
| Bybit（2025年） | ウォレットソフトへのサプライチェーン攻撃で15億ドルが盗まれた。悪意のあるコードは標的のウォレットが使われているときだけ動いた |
| Shai-Hulud（2025年） | 初めて成功した自己増殖型のnpmワーム。post-installスクリプトで情報を集め、見つけたnpmトークンで拡散し、500を超えるパッケージのバージョンに及んだ |
| Apache Struts 2（CVE-2017-5638） | リモートコード実行の脆弱性が大きな侵害につながった |
| Log4Shell（CVE-2021-44228） | Apache Log4jのゼロデイの脆弱性がランサムウェアや暗号資産の採掘などに使われた |

</Figure>

OWASPは、部品はアプリケーションと同じ権限で動くことが多いため、部品の欠陥が深刻な影響を及ぼしうると指摘しています。

## 脆弱になりやすい状態

OWASPは、次のような状態にあるシステムを脆弱になりやすいとしています。自分たちの開発体制と照らし合わせてみてください。

<Figure title="サプライチェーンで脆弱になりやすい状態" source="OWASP Top 10:2025 A03">

| 観点 | 当てはまると危ない状態 |
| --- | --- |
| 把握 | 間接的な依存（推移的依存）を含めて、部品のバージョンを追えていない |
| 古さ | OS・サーバー・データベース・ランタイムなどに、サポート切れや古いものがある |
| 情報収集 | 定期的なスキャンや、セキュリティ情報の購読をしていない |
| 変更管理 | IDE・リポジトリ・成果物の置き場の変更を追えていない |
| 権限 | 1人でコードを本番まで出せる。最小権限になっていない |
| 入手元 | 信頼できない入手元の部品を本番で使っている |
| 更新 | 月1回・四半期ごとなど、リスクを考えない遅い周期でしか更新しない |
| CI/CD | パイプラインのセキュリティが、デプロイ先のシステムより弱い |

</Figure>

## 対策

OWASPの「How to Prevent」は、把握、変更管理、堅牢化の3つに分かれています。

<Steps>
<Step title="把握する：SBOMと依存関係の一覧">

ソフトウェア全体のSBOM（ソフトウェア部品表）を一元的に作って管理し、直接の依存と推移的な依存を追います。使っていない依存・機能・ファイルは取り除きます。CVE・NVD・OSVを監視し、ソフトウェア構成分析（SCA）やSBOMのツールで通知を受け取ります。

</Step>
<Step title="入手元とバージョンを意図して選ぶ">

部品は信頼できる入手元から安全な経路で取得し、署名付きのパッケージを優先します。依存のバージョンは意図して選び、必要なときだけ上げます。保守が止まった部品は移行を検討し、移行できなければ仮想パッチも選択肢にします。

</Step>
<Step title="変更を追う">

CI/CDの設定とビルドパイプライン、コードリポジトリ、開発者のIDE、SBOMのツールと生成物、ログ、SaaSを含む外部連携、成果物リポジトリとコンテナレジストリの変更を記録します。

</Step>
<Step title="関わるシステムを固める">

多要素認証を有効にし、IAMを絞ります。リポジトリには秘密情報をコミットせず、ブランチを保護します。CI/CDでは職務の分離、署名付きビルド、環境ごとに分けた秘密情報、改ざんが分かるログを使います。成果物は署名とタイムスタンプで完全性を確かめ、環境ごとに作り直さず同じものを昇格させます。

</Step>
<Step title="段階的に展開する">

すべてのシステムを一度に更新せず、段階的な展開やカナリアリリースを使います。CI/CDやIDEなど開発ツール自体も定期的に更新します。

</Step>
</Steps>

多要素認証の方式の選び方は[多要素認証の解説](/multi-factor-authentication/)にまとめています。

## npmプロジェクトでできること

JavaScriptのプロジェクトなら、npmに用意されたコマンドで対策の一部をすぐに始められます。

<Compare>
<Column title="npm install">

- package.jsonの範囲内で依存を解決する
- ロックファイルを書き換えることがある
- 手元での開発向け

</Column>
<Column title="npm ci" tone="accent">

- ロックファイルが必須
- package.jsonと食い違うとエラーで止まる
- package.jsonもロックファイルも書き換えない

</Column>
</Compare>

npmの公式ドキュメントによれば、`npm ci` はCIやデプロイなど自動化された環境向けのクリーンインストールで、既存の `node_modules` を消してからロックファイルどおりに入れます。CIでは `npm install` ではなく `npm ci` を使うと、意図しないバージョンが入り込むのを防げます。

```bash
# ロックファイルどおりに入れる（CI向け）
npm ci

# 既知の脆弱性を確認し、high以上があればCIを失敗させる
npm audit --audit-level=high

# レジストリの署名と来歴（provenance）の証明を検証する
npm audit signatures
```

`npm audit` は依存関係の一覧をレジストリに送り、既知の脆弱性の勧告を受け取ります。`--audit-level` は失敗扱いにする最低の深刻度を決めるオプションで、レポートの表示は絞りません。`npm audit signatures` は、レジストリが公開しているECDSAの公開鍵による署名と、来歴の証明（provenance attestations）を確かめます。

<Note tone="caution">

`npm audit fix --force` は、メジャーバージョンの更新など依存の範囲を変える修正まで行います。npmのドキュメントは、影響を理解したうえでのみ使うよう注意しています。自動で直した後も、互換性のテストは欠かせません。

</Note>

## よくある質問

### Q. サプライチェーン攻撃は大企業だけの問題ですか？

いいえ。オープンソースの部品を使うアプリはすべて対象です。Shai-Huludのように、npmのパッケージを通じて広がる攻撃は、規模にかかわらず依存関係を持つ開発者に届きます。

### Q. SBOMとは何ですか？

ソフトウェア部品表のことで、アプリがどの部品のどのバージョンを使っているかの一覧です。新しい脆弱性が公表されたとき、影響を受けるかどうかをすぐに判断する土台になります。OWASPはSBOMを一元的に作って管理するよう勧めています。

### Q. 依存ライブラリは常に最新にしておけばよいですか？

最新にするだけでは安全になりません。悪意のある新しい版が公開されることもあるため、OWASPはバージョンを意図して選び、必要なときに上げること、更新した部品の互換性をテストすること、段階的に展開することを勧めています。

出典: [OWASP Top 10:2025 A03 Software Supply Chain Failures](https://top10.owasp.org/2025/A03_2025-Software_Supply_Chain_Failures/)、[npm Docs「npm ci」](https://docs.npmjs.com/cli/v11/commands/npm-ci)、[npm Docs「npm audit」](https://docs.npmjs.com/cli/v11/commands/npm-audit)