サプライチェーンとは？ITでどうかかわる？ソフトウェアや委託先とのつながりを解説

「サプライチェーン」という言葉は、もともと物流や製造の話でよく出ます。 でも IT でもかなり重要で、しかも最近は「ソフトウェアサプライチェーン」や「サプライチェーン攻撃」の文脈で見かけることが増えました。

ここで混ざりやすいのは、「うちはソフト会社だから物流の話は関係ないのでは」と思いやすいことです。 実際には、社内で書いたコードであっても、使っているライブラリ、クラウド、コンテナイメージ、CI/CD、配布基盤、委託先が全部つながっています。IT のサプライチェーンはかなり身近です。

このページでは、NIST の Cybersecurity Supply Chain Risk Management、NIST IR 7622、CISA の SBOM、CISA/NIST の Defending Against Software Supply Chain Attacks を確認しながら整理しています。さらに今回は、実際にどのコマンドで依存を見える化するか、xz utils 事件で何が起きたか、委託先をどうチェックするかまで、手を動かせる粒度で書きます。

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

サプライチェーン は、原材料や部品の調達から、製造、流通、販売、保守までの一連の流れやつながりを指す言葉です。 要するに「何かを作って届けるまでの経路全体」です。

初心者向けには、「1社だけで完結しているように見えても、実際にはいろいろな会社や仕組みがつながっている」と考えると入りやすいです。 製造業なら部品メーカーや物流会社が見えやすいですが、IT でも同じです。

IT ではどうかかわるのか

IT の場合、目に見える物流よりも「ソフトウェアやサービスのつながり」として現れます。

たとえば、ひとつの Web サービスでも次のようなものが関係します。

• 自社が書いたアプリケーションコード
• OSS ライブラリやパッケージ
• ベースイメージやコンテナレジストリ
• Git ホスティング、CI/CD、ビルド基盤
• クラウド、SaaS、CDN、監視サービス
• 外注先や保守委託先
• 配布先の顧客環境や端末

つまり IT のサプライチェーンは、「コードを書く前後の外部依存のつながり」と言い換えてもかなり近いです。

ソフトウェアサプライチェーンとは何か

ソフトウェアサプライチェーン は、ソフトウェアが作られ、ビルドされ、配布され、更新されるまでの一連の流れです。 NIST や CISA の文脈でも、設計、開発、配布、導入、保守までライフサイクル全体で見る考え方が出てきます。

初心者向けには、こう考えると分かりやすいです。

• 書いたコードそのもの
• 取り込んだ依存関係
• それをビルドした環境
• できあがった成果物の配布経路
• 導入先での更新運用

このどこかが壊れても、利用者まで影響します。

なぜ IT で重要なのか

理由はシンプルで、いまのソフトウェアは「自社だけで全部作っていない」からです。

1. 依存関係が多い

アプリ本体は少なくても、実際には何十、何百というライブラリやパッケージに依存していることがあります。たとえば中規模の Node.js プロジェクトで package.json の直接依存が 30 個でも、node_modules をたどると間接依存を合わせて 800〜1,500 個になることは珍しくありません。 そのどれかに脆弱性や改ざんがあると、自社コードが無事でも影響を受けます。

2. ビルドや配布の途中も狙われる

攻撃者は、本番サーバーだけでなく、ビルド環境、CI/CD、配布基盤、アップデート配信経路も狙います。 ここで改ざんされると、正規アップデートに見える形で広がることがあります。

3. 委託先やクラウドも含めて影響する

自社が直接ミスしていなくても、委託先の運用不備や外部サービス側の問題で影響を受けることがあります。 「うちの範囲ではない」と切り分けても、利用者から見ると自社サービスの障害や事故です。

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

サプライチェーン攻撃 は、最終的な標的そのものではなく、その手前にある開発元、委託先、ライブラリ、更新経路、配布経路などを狙って侵入や改ざんを行う攻撃です。

CISA と NIST の 2021 年の資料でも、ソフトウェアベンダー側へ侵入し、出荷前のソフトウェアへ悪意あるコードを混入させるような例が説明されています。 有名な SolarWinds 事件が語られるのも、この文脈です。

初心者向けには、「本命の会社を直接殴るのではなく、その会社が信頼している流れを使って入り込む攻撃」と考えるとかなり分かりやすいです。

xz utils 事件(CVE-2024-3094)で実際に何が混入したか

2024年3月に発覚した xz utils のバックドアは、「ソフトの中身ではなくビルドの過程が狙われる」典型例として、いまも繰り返し引かれます。何が起きたかを一段詳しく追うと、対策のイメージがつかみやすくなります。

• 圧縮ライブラリ xz utils(liblzma)のメンテナーに、攻撃者が数年がかりで近づき、共同メンテナーの地位を得ました。技術的な脆弱性ではなく、信頼を獲得する社会工学が出発点でした。
• 悪意あるコード本体は、Git リポジトリの普段読むソースには置かれず、配布用 tarball にだけ含まれる build-to-host.m4 というビルドスクリプトと、テスト用データを装ったバイナリに分けて隠されました。GitHub 上のコードをレビューしても見つけにくい構造です。
• ビルド時、このスクリプトがテストデータから本体を組み立て、liblzma に注入します。注入は Debian / Fedora など、sshd を liblzma 付きでビルドする特定ディストリビューション向けに条件分岐していました。
• 結果として、攻撃者が持つ特定の Ed448 秘密鍵で署名したリクエストを送ると、sshd の認証をすり抜けて任意コードを実行できる状態でした。つまり実質的なリモートコード実行のバックドアです。
• 発覚のきっかけは、ある開発者が sshd のログインが約 500ms 遅くなったことに気づき、調査したことでした。攻撃そのものより「たまたまの違和感」で見つかったため、対象バージョン(5.6.0 / 5.6.1)が広く本番に乗る前に止められました。

ここでの教訓は、(1) リポジトリのコードだけでなく配布物とビルド工程まで含めて経路だということ、(2) 個人メンテナー1人に依存した OSS は人の乗っ取りで一気に崩れること、(3) 何が入っているかを SBOM で把握しバージョンを固定しておくと、影響有無を即答できることです。

実務ではどこを見るのか

全部を完璧に見るのは難しいので、実務ではまず「何に依存しているかを把握する」ところから始めるのが現実的です。

1. 外部依存の棚卸し

まずは、何を使っているかを洗い出します。

• OSS パッケージ
• ベースイメージ
• SaaS
• クラウドサービス
• 外注先や保守委託先
• 署名鍵や配布基盤

これが見えていないと、問題が出たときに「うちに関係あるのか」すら判断しにくいです。

2. 依存スキャンと SBOM を使った見える化

棚卸しを目視でやると抜けます。標準ツールで機械的に出すのが実務的です。代表的なコマンドを挙げます。

Node.js: 既知脆弱性を npm audit で確認する

$ npm audit

# 典型的な出力(抜粋)
# found 7 vulnerabilities (3 moderate, 3 high, 1 critical)
#   in 1024 scanned packages

# 機械処理したいときは JSON で
$ npm audit --json > npm-audit.json

# パッチ範囲内で直せるものを自動修正(破壊的変更まで許すなら --force)
$ npm audit fix

npm audit は package-lock.json を見て GitHub Advisory などの脆弱性データベースと突き合わせます。fix は semver の許容範囲で上げ、メジャー更新が要るものは「--force が必要」と表示して止まります。CI では npm audit --audit-level=high のように一定深刻度以上で失敗させる使い方が定番です。

Python: pip-audit で requirements を監査する

$ pip install pip-audit
$ pip-audit -r requirements.txt

# 典型的な出力(抜粋)
# Found 2 known vulnerabilities in 1 package
# Name     Version  ID             Fix Versions
# -------  -------  -------------  ------------
# requests 2.25.0   CVE-2023-32681 2.31.0

# レポートを残すなら JSON 出力
$ pip-audit -r requirements.txt --format json > pip-audit.json

# 直せるものを上げる(まず --dry-run で確認)
$ pip-audit -r requirements.txt --fix --dry-run

言語横断: syft で SBOM を生成する

SBOM(ソフトウェア部品表)は、何がどのバージョンで入っているかの一覧です。Anchore の syft なら、ソースディレクトリでも Docker イメージでも出せます。

# カレントディレクトリの依存をCycloneDX JSONで
$ syft dir:. -o cyclonedx-json=sbom.json

# Dockerイメージから直接SPDX JSONで
$ syft myapp:latest -o spdx-json=sbom-spdx.json

# 出力ファイル冒頭のイメージ(CycloneDX)
# {
#   "bomFormat": "CycloneDX",
#   "specVersion": "1.5",
#   "components": [
#     { "type": "library", "name": "openssl",
#       "version": "3.0.13",
#       "purl": "pkg:deb/debian/openssl@3.0.13" }, ...

SBOM を一度出しておくと、新しい CVE が公表されたときに「openssl 3.0.13 が入っているか」をファイル検索だけで即答できます。さらに同じく Anchore の grype sbom:sbom.json に食わせれば、その SBOM に対する既知脆弱性を後から突き合わせられます。フォーマットは CycloneDX か SPDX を選んでおくと、他ツールと連携しやすいです。

3. 委託先やベンダーの管理

IT のサプライチェーンは、ライブラリだけでは終わりません。開発委託、保守委託、運用委託、SaaS ベンダー、クラウド事業者も含まれます。口頭の「大丈夫です」で済ませず、最小限でも書面で確認します。下はそのままコピーして使える最小チェックリストの雛形です。

この8項目は、初回の選定時に確認し、その後は年1回程度を目安に見直すと運用に乗せやすいです。すべて満点である必要はなく、「答えられない項目がどこか」を可視化することがまず大事です。

4. 更新経路とビルド経路の保護

更新の配布元や CI/CD が乗っ取られると、かなり重いです。なので、署名、権限分離、Secrets 管理、レビュー、ログ監査まで含めて見ます。xz 事件のように「ビルド時だけ動くスクリプト」が経路になるため、本番コードだけでなくビルド工程の差分もレビュー対象にするのが効きます。

初心者はどう考えると入りやすいか

最初は次の順で考えるのがおすすめです。

1. 自社システムは何に依存しているか
2. その中で、更新されたら一気に影響するものは何か
3. 外部サービスや委託先で止まると困るものは何か
4. 問題が出たとき、影響範囲を追える情報があるか

この4つが見えるだけでも、「サプライチェーン = なんとなく難しい言葉」からかなり抜けやすくなります。

実務で最初にやりたいこと

いきなり大規模な仕組みを入れなくても、まずはこれが効きます。

ITサプライチェーンに関するよくある質問

Q. サプライチェーン攻撃とは具体的に何ですか？

A. ソフトウェアの提供元、配布経路、ビルド工程、第三者ライブラリ、業務委託先などを経由して標的に侵入する攻撃です。SolarWinds 事件や、Linux の xz utils 事件(CVE-2024-3094)が代表例として知られています。

Q. xz utils 事件はなぜ「ビルド経路の攻撃」と呼ばれるのですか？

A. 悪意あるコードが GitHub のソースではなく、配布用 tarball のビルドスクリプト build-to-host.m4 とテストデータに分けて隠され、ビルド時に liblzma へ注入される仕組みだったためです。コードレビューだけでは見つけにくく、出荷物とビルド工程まで見ないと検知できない点が特徴です。

Q. SBOM はどうやって作れば良いですか？

A. syft dir:. -o cyclonedx-json=sbom.json のように1コマンドで生成できます。CycloneDX や SPDX が代表的なフォーマットで、後から CVE が出たときに「自分のシステムに該当バージョンが入っているか」をファイル検索や grype ですぐ確認できます。

Q. npm や PyPI などのパッケージは安全ですか？

A. 一般には安全ですが、typosquatting(名前の似た悪意あるパッケージ)、dependency confusion、メンテナー乗っ取りなどのリスクがあります。lockfile の固定、依存関係の最小化、npm audit や pip-audit による定期スキャンが基本対策です。

Q. 中小企業もサプライチェーンセキュリティの対象ですか？

A. 対象です。大企業から「取引先のセキュリティが緩いと取引できない」と言われる流れが進んでおり、ISMS、SOC 2、IPA の「サプライチェーン情報セキュリティガイドライン」などが交渉材料になります。

Q. オープンソースを使うのは危険ですか？

A. 危険ではありませんが、誰がメンテしているか、最終更新はいつか、脆弱性履歴は健全か、を確認する習慣が大事です。xz 事件のように個人メンテナー1人依存のプロジェクトは人の乗っ取りに弱いので、商用サポート付きや企業がスポンサーするプロジェクトを優先するのも有効です。

Q. 業務委託先のセキュリティはどう確認すれば良いですか？

A. 本文のチェックリスト雛形(再委託範囲、データ保管、権限、認証、パッチ方針、ログ、インシデント通知、契約終了時のデータ扱いの8項目)を使い、契約時に確認して年1回程度見直すのが実務的です。答えられない項目を洗い出すこと自体が成果になります。

Q. SLSA とは何ですか？

A. Supply-chain Levels for Software Artifacts の略で、Google が中心となって策定したサプライチェーンセキュリティの成熟度フレームワークです。レベルが上がるほど、ビルドの再現性、来歴(provenance)の検証可能性、改ざん防止の度合いが高まります。

まとめ

サプライチェーン は、何かを作って届けるまでのつながり全体です。 IT ではそれが、ソフトウェアサプライチェーン、依存ライブラリ、委託先、クラウド、CI/CD、配布経路の話として現れます。

つまり、「自社コードだけ見ていればよい」ではありません。どこに依存していて、どこが止まると困るのか、どこから改ざんや脆弱性が入りうるのかを見えるようにしておくのが大事です。

最初の一歩としては、npm audit や pip-audit での依存スキャン、syft での SBOM 生成、委託先チェックリストの適用あたりがかなり効きます。ここができると、IT のサプライチェーンが「怖いけど曖昧な話」ではなく、実務で管理する対象として見えやすくなります。

参考リンク

• NIST CSRC: Cybersecurity Supply Chain Risk Management
• NIST IR 7622: Notional Supply Chain Risk Management Practices for Federal Information Systems
• CISA: Software Bill of Materials (SBOM)
• CISA/NIST: Defending Against Software Supply Chain Attacks
• Anchore syft: GitHub - anchore/syft
• PyPA pip-audit: GitHub - pypa/pip-audit