A03 ソフトウェアサプライチェーンの不備

自分で書いていないコードが、アプリと同じ権限で動く。入口は部品そのものだけでなく、それを作って届ける仕組み、つまり開発者の端末、リポジトリ、CI、成果物の置き場にもある。

OWASP Top 10:2025 A03 Software Supply Chain Failures。2021年版の A06 脆弱で古くなったコンポーネントを、依存、ビルド、配布の全体へ広げた新しいカテゴリ。コミュニティの調査では回答のちょうど50%が1位に選んだ。対応するCWEは一覧で6つ[1]。2026年11月時点の記載で書いています。

成立の条件

部品が作られてから本番で動くまでの、どの段でも、確かめずに次へ渡せば成り立つ。

• 把握していない 直接と推移的な依存、端末側とサーバー側の部品の版を追っていない。OS、Webサーバー、データベース、実行環境も含む[1]。
• 直さない 修正を月次や四半期の作業にして、その間を無防備にする。更新した部品の互換を試さないので上げられない[1]。
• 固めていない CI と CD が、それが作る本番より弱い。1人でコードを書いて本番まで出せる[1]。

A08 ソフトウェアまたはデータの完全性の不備との境目について、OWASP は A08 を A03 より低い水準で完全性の検証と信頼の境界を扱うものと位置づける[2]。署名や外部のスクリプトの完全性の確かめは A08 で扱う。

型1 既知の脆弱性を持つ部品を使い続ける

脆弱性は、直接選んだ部品より、その下の推移的な依存に潜むことが多い。直接の依存だけを見ていると気づけない。OWASP は例に、Apache Struts 2 の CVE-2017-5638 と、Apache Log4j の CVE-2021-44228 を挙げる[1][9]。

悪い例。CI で範囲の中の最新を入れる

npm install   # 範囲の中で新しい版が入り、ロックファイルを書き換える

直した例。ロックファイルどおりに入れ、脆弱性で止める

npm ci                         # package.json とロックファイルが食い違えば失敗する
npm audit --audit-level=high   # 高以上の既知の脆弱性があれば失敗する

• npm ci はロックファイルが要り、食い違えばロックファイルを直さずに失敗する[7]。版を意図して選び、要るときにだけ上げる、という OWASP の求めに合う[1]。
• 版を固定すると、修正の版も自動では入らない。固定と、修正を早く入れる仕組みは対で置く。脆弱性の情報源は CVE、NVD、OSV を見張る[1]。
• 保守が止まった部品と、更新できない部品は、それぞれ CWE-1104 と CWE-1329。修正が出ないなら別の部品へ移し、移せないなら仮想パッチで見張り、検知し、守る[1]。

型2 悪意ある版が入る

信頼していた部品の作者のアカウントや公開の仕組みが乗っ取られ、悪意ある版が正規の名前で出る。2025年9月の Shai-Hulud では、npm の500を超える包みが侵害された。入れた環境から GitHub の個人アクセストークンと、AWS、GCP、Azure の鍵を集めて公開のリポジトリへ上げ、見つけた npm の資格情報で他の包みにも悪意ある版を公開して広がった[3]。

直した例。CI では導入時のスクリプトを走らせない

# .npmrc
ignore-scripts=true

# CI
npm ci --ignore-scripts
npm rebuild some-native-module   # 本当に要る部品だけ、中身を確かめてから個別に

• ignore-scripts を有効にすると、依存の導入の前後に走るスクリプトが止まる。npm test のように明示して呼ぶスクリプトは走るが、その前後のスクリプトは走らない[8]。
• CISA の勧めは、ロックファイルで影響を受けた部品を洗い出す、侵害の前の版に固定する、開発者の資格情報を全部回す、GitHub と npm にフィッシングに強い多要素認証を義務づける、ブランチの保護と秘密の走査を有効にする、こと[3]。
• 公開の権限を持つトークンは、包みの単位と期限で絞る。開発の端末には公開の権限を置かない。
• 新しい版を出た直後に全環境へ入れない。OWASP は、信頼していた作者が侵害された場合に備え、段階的な展開やカナリアで影響を限るよう求める[1]。

型3 ビルドと配布の仕組みを乗っ取られる

CI は本番へ出す鍵と、成果物を書き換える権限を持つ。CI の定義が外部の手順を可変の名前で呼び、権限を広く与えていると、外部の手順が書き換えられた時点で本番の鍵が外へ出る。

悪い例。架空の CI の定義

permissions: write-all
jobs:
  deploy:
    steps:
      - uses: example-org/deploy-action@v2
        with:
          token: ${{ secrets.PROD_DEPLOY_KEY }}

直した例。中身で固定し、権限を絞り、本番の秘密を環境に閉じる

permissions:
  contents: read
jobs:
  deploy:
    environment: production   # 承認の要る環境にだけ本番の秘密を置く
    steps:
      - uses: example-org/deploy-action@3f1c0e5a9b7d2c4e6f8a0b1c2d3e4f5a6b7c8d9e  # v2.4.1
        with:
          token: ${{ secrets.PROD_DEPLOY_KEY }}

• GitHub は、外部のアクションを完全な長さのコミットのハッシュで固定するよう勧め、タグでの固定は作者を信頼できる場合に限るとする。ハッシュの指す中身を差し替えるには SHA-1 の衝突を作る必要がある[6]。
• OWASP は CI と CD に、職務の分離、アクセス制御、署名したビルド、環境に絞った秘密、改ざんの分かる記録を求め、成果物は環境ごとに作り直さず同じものを昇格させるよう求める[1]。
• どこで、何から、どう作ったかの来歴を成果物に付ける。SLSA は来歴の有無を Build L1、ホストされたビルドの仕組みを L2、固めたビルドを L3 と段に分ける[5]。
• CI の定義、IaC、ログの仕組み、成果物とコンテナの置き場の変更も、コードと同じく追跡と承認の対象にする[1]。

守り方

診断で見る所

A03 は外からの診断より、組織の中の点検とコードのレビューで見つかる。依存の扱いはチートシートが詳しい[10]。

関連するCWE

A03 の一覧に載る6つ[1]。

参照

1. A03:2025 Software Supply Chain Failures OWASP Top 10:2025
2. Introduction, OWASP Top 10:2025 OWASP Foundation
3. Widespread Supply Chain Compromise Impacting npm Ecosystem CISA。2025年9月23日
4. Dependency Graph and SBOM Cheat Sheet OWASP Cheat Sheet Series
5. SLSA v1.0 Security levels SLSA。OpenSSF
6. Secure use reference GitHub Docs
7. npm ci npm Docs
8. npm config, ignore-scripts npm Docs
9. CVE-2021-44228 NIST National Vulnerability Database
10. Vulnerable Dependency Management Cheat Sheet OWASP Cheat Sheet Series
11. CWE-477 Use of Obsolete Function MITRE