SBOMとSLSA：サプライチェーンの世界標準

あなたのアプリは、あなたが書いた（AIが書いた）コードだけでできているわけではありません。何百という他人の部品（パッケージ）を組み合わせて動いています。経理が仕入先台帳と部品表を持つように、アプリにも部品表が要ります。それがSBOMです。この章では、SBOMの世界標準と、部品の「来歴」を保証するSLSAや署名の仕組みを読み、自分のアプリの部品表を実際に出します。

SBOM：ソフトウェアの部品表

SBOM（Software Bill of Materials、ソフトウェア部品表）は、CISAの定義では「ソフトウェアを構成する部品の、入れ子になった一覧。いわば原材料表示」です。製造業の部品表（BOM）と同じ言葉が使われているのは偶然ではありません。「この製品に、どの部品が、どの版で、どこから入っているか」を機械が読める形で持つ、という発想です。

経理に引き寄せるなら、仕入先台帳に近いものです。ある仕入先に問題が起きたとき、台帳があれば「どの製品に、その部品が入っているか」がすぐ分かります。台帳が無ければ、全製品を一つずつ調べることになります。広く使われている部品に重大な脆弱性が公表されたとき、「自社のどこにその部品が入っているか分からない」状態に陥る組織は少なくありません。SBOMは、その状態を無くすためのものです。

制度は米国が先行しています。2021年5月の大統領令14028が政府に納めるソフトウェアにSBOMを求め、同年7月12日に米国商務省NTIAが「SBOMの最小要素（The Minimum Elements For a Software Bill of Materials）」を公表しました。3つの区分に分かれます。

2025年8月22日には、CISAが「2025 Minimum Elements for a Software Bill of Materials」の草案を連邦官報で公表し、10月3日まで意見を募集しました。CISAの発表によれば、2021年版に「部品のハッシュ値」「ライセンス」「生成ツール名」「生成時の文脈」が追加されています。本稿執筆時点で確定版の公表は確認できていません。日本では、経済産業省が「ソフトウェア管理に向けたSBOMの導入に関する手引 ver 2.0」（2024年8月）を公開しています。

2つの形式：SPDXとCycloneDX

SBOMの形式は、実務上2つに集約されています。どちらも機械が読めるファイル（JSONなど）で、人が目で読むものではありません。

SPDX

Linux Foundationが主催する形式。2021年8月にISO/IEC 5962:2021として国際規格になりました。3.0は2024年4月に公開され、同年12月に修正版の3.0.1が出ています。ライセンス情報の記述から発展してきた経緯があります。

CycloneDX

OWASPが主催する形式。Ecma InternationalのTC54と共同で進められ、ECMA-424として標準化されています。SBOMだけでなく、脆弱性情報（VEX）なども同じ枠組みで扱えます。

どちらを使うかで悩む必要はありません。相手（取引先、監査、ツール）が指定する形式に合わせるだけです。

個人開発でのSBOM：もう持っている

あなたのリポジトリには、すでにSBOMの材料があります。Node.jsなら package-lock.json です。間接依存まで含めて「どのパッケージの、どの版を使っているか」を固定したファイルで、NTIAのデータ項目のうち部品名と版と依存関係を含んでいます。

Pythonの requirements.txt は事情が違います。版を == で固定して書くこともできますが、版を書かないことや、範囲（>= など）で書くことも許されており、間接依存が入っているとも限りません。pip freeze で書き出した一覧なら、その時点で入っているパッケージと版は固定されますが、「どれがどれに依存しているか」の関係は含まれません。そのままでは完全な部品表にならない、と覚えておいてください。

標準形式に変換する道具もあります。npmの npm sbom コマンドは、--sbom-format に cyclonedx か spdx を指定すると、依存関係をその形式で出力します。--sbom-type application でアプリケーションであることを示せます。npmの公式ドキュメントに載っている機能です。

ここで大切な区別が、直接依存と間接依存です。

直接依存

あなた（またはAI）が package.json に書いて入れたパッケージ。自分で選んだ仕入先。

間接依存

直接依存のパッケージが、さらに使っているパッケージ。仕入先の、そのまた仕入先。自分で選んでいないのに、アプリの中で動いている。

直接依存が十数個でも、間接依存を含めると数百を超えることは珍しくありません。論文で「サプライチェーンの不備」が73件（6.16%）あったのは、この「自分で選んでいない部品」の管理が抜けるからです。第12章で有効にしたDependabotは、この部品表を自動で読んで「脆弱性のある部品が入っている」と知らせる仕組みです。

SLSA：ビルドの来歴を保証する

SBOMは「何が入っているか」を答えます。しかし「その部品は、本当に名乗っている通りの出どころから、改ざんされずに来たのか」には答えません。それを扱うのがSLSA（Supply-chain Levels for Software Artifacts、「サルサ」と読みます）です。Linux Foundation傘下のOpenSSFが進める枠組みで、「改ざんを防ぎ、完全性を高め、パッケージと基盤を守るための基準と統制のチェックリスト」と自己定義しています。

中心にある概念が来歴（provenance）です。SLSAの定義では「どの主体が、どの手順で、どの入力から、その成果物を作ったか」を記した情報です。経理で言えば、納品物に添付される「製造元と製造工程の証明書」です。現在の承認済みの版はv1.2で、「Build（ビルド）」と「Source（ソース）」の2つのトラックがあります。

Source L4の「2名のレビュー」は、経理の職務分掌そのものです。AIが書いた変更を自分だけで本番に入れている個人開発は、Source L1かL2の段階です。だからこそ「レビューを別のセッションや別のAIに通す」という第13章の原則が効きます。

署名と来歴の実装：Sigstoreとnpm provenance

SLSAの来歴を実際に作り、確かめる道具として、Sigstoreがあります。OpenSSF（Linux Foundation）が支える公共のサービスで、署名用のクライアント（cosign）、身元と結びついた短命の証明書を発行する認証局（Fulcio）、署名の記録を追記専用の公開台帳に残す透明性ログ（Rekor）で構成されます。長期の秘密鍵を自分で管理せずに済み、記録は登記簿のように公開されます。

npmはこれを「npm provenance（来歴）」として組み込んでいます。npmの公式ドキュメントによれば、GitHub ActionsやGitLab CI/CDのホスト型の実行環境から npm publish --provenance で公開すると、そのパッケージが「どのリポジトリの、どのコミットから、どの手順で作られたか」を示す来歴証明が、Sigstoreの公開サーバーで署名され、公開台帳に記録されます。利用者側は npm audit signatures で、インストール済みのパッケージのうち署名と来歴証明が検証できたものの数を確認できます。

ただし、npmのドキュメント自身が「来歴は、パッケージに悪意あるコードが無いことを保証するものではない」と明記しています。来歴が示すのは「名乗っている出どころから来た」ことだけです。印鑑証明が付いていても、その会社が架空取引をしていないことまでは証明されないのと同じです。

第16章との接続：slopsquattingと影響範囲

第16章で見たslopsquatting（AIが幻覚した存在しないパッケージ名を、攻撃者が先回りして登録する手口）は、第23章のATLASではAML.T0060「Publish Hallucinated Entities」、ATT&CKではT1195.001「Compromise Software Dependencies and Development Tools」に当たります。この手口への備えとして、SBOMは2つの役割を果たします。

• 事前：SBOMを出して直接依存の一覧を目で見ると、「このパッケージ、自分は入れた覚えがない」「名前が似た別物ではないか」に気づけます。AIが提案したパッケージ名は、公式レジストリ（npmjs.com、pypi.org）で実在と公開日、週間ダウンロード数、来歴の有無を確かめてから入れます。
• 事後：あるパッケージが悪意あるものだったと公表されたとき、SBOMがあれば「自分のアプリに入っているか、どの版か、何経由で入ったか」を数分で答えられます。無ければ、全ファイルを探すことになります。

このリポジトリの依存関係を、サプライチェーンの観点で整理してください。

1. 直接依存（package.json または requirements.txt に書かれているもの）の一覧を、「パッケージ名／版／用途（このアプリで何に使っているか）／最後にインストールした理由が分かるか」の表にしてください
2. 直接依存の数と、間接依存を含めた総数を、ロックファイル（package-lock.json など）から数えてください
3. 直接依存のうち、このアプリのコードから実際には使われていないもの（import や require が無いもの）を挙げてください
4. 名前が有名なパッケージと紛らわしいもの、公式レジストリでの確認が必要と思われるものがあれば、理由を添えて挙げてください
5. 修正やアンインストールはまだしないでください。報告だけお願いします

パッケージの実在や公開日、ダウンロード数は推測せず、「公式レジストリで確認が必要」と書いてください。