成果物の来歴とソフトウェア部品表（SBOM/SLSA）

サプライチェーン攻撃と「来歴」という発想

ソフトウェアサプライチェーン攻撃は、アプリ本体のコードではなく 作る過程 を狙います。汚染されたビルドサーバー、改竄された依存、差し替えられた成果物——いずれも「最終的に配布されたバイナリ」を見ただけでは正規かどうか判別できません。署名されたリリースであっても、署名された 対象そのもの がビルド工程で汚染されていれば無力です。

ここで効くのが 来歴（provenance） という発想です。来歴とは「この成果物は、どのソースコードから、どのビルダーが、どんなコマンドで、いつ作ったか」を構造化して記録し、署名したものです。検証側は配布された成果物のハッシュを計算し、来歴に記録されたハッシュと突き合わせる。一致すれば「主張どおりの工程で作られた本物」と機械的に確認でき、不一致なら途中で差し替えられたと分かります。

SLSA：ビルド完全性の成熟度レベル

SLSA（Supply-chain Levels for Software Artifacts、「サルサ」） は、来歴の信頼度を 段階的なレベル で定義するフレームワークです。一度に完璧を求めず、組織が段階的に堅牢化できるよう成熟度として刻んでいます。要点は「来歴を 出すか／誰が出すか／どれだけ改竄しにくい環境で出すか」が上がっていくことです。

レベルが上がる本質は 「来歴を誰が・どこで作るか」の信頼基盤が強くなる ことです。L1 は単に来歴を出すだけで、開発者が手で書けてしまうため偽造に弱い。L2 は ホスト型ビルドサービス（CI 基盤）が来歴を自動生成し署名するため、人手の介入余地が減る。L3 はさらにビルドを 隔離（isolation） し、署名鍵がビルドスクリプトから触れない設計にする。これにより「ビルドを乗っ取った攻撃者が、汚染成果物に正規の来歴を付ける」経路を断ちます。

SBOM：何が入っているかの部品表

SBOM（Software Bill of Materials、ソフトウェア部品表） は、成果物に含まれる 全コンポーネントの一覧——名前・バージョン・ライセンス・ハッシュ・依存関係——を記述した文書です。製造業の部品表になぞらえた概念で、直接依存も推移的依存もすべて列挙します。

標準フォーマットは主に二つです。

SBOM の価値が際立つのは 新たな脆弱性が公表された瞬間 です。「あのライブラリの特定版に重大な穴」と発表されたとき、SBOM があれば「自社のどの製品・どのリリースが該当するか」を即座に検索できます。SBOM がなければ全プロジェクトを手で洗い直すことになります。さらに VEX（Vulnerability Exploitability eXchange） を併用すると、「その脆弱な版を含むが、該当機能を呼んでいないため実質影響なし」といった 到達可能性の文脈 を付与でき、ノイズを減らせます。

重要なのは 来歴と SBOM が答える問いの違い です。来歴は「どう作られたか（プロセス）」、SBOM は「何が入っているか（中身）」を答える。両者は補完関係で、片方だけでは守れません。

in-toto：工程をつなぐ署名連鎖

SLSA の来歴を実際に運用する基盤として広く使われるのが in-toto です。in-toto は、サプライチェーンの 各工程（ステップ）に署名された証跡（attestation）を残し、それを連鎖させる 枠組みです。

考え方はこうです。あらかじめ「正しいパイプラインはどの工程をどの順で踏み、各工程の入出力ハッシュはどう連なるべきか」を レイアウト（layout） として定義し、署名しておく。各工程の実行者は、自分が受け取った成果物（入力）と生成した成果物（出力）のハッシュを記録し署名する。検証時には、

ステップA(出力ハッシュ) == ステップB(入力ハッシュ)
ステップB(出力ハッシュ) == ステップC(入力ハッシュ)
... 連鎖が途切れず、各署名が正しい鍵か

を全工程について確認します。途中で誰かが成果物を差し替えれば、隣接工程のハッシュ連鎖が切れて検出される。これはサプライチェーンの各受け渡しを暗号的に封緘する発想で、SLSA の来歴は in-toto の attestation 形式（in-toto Statement）として表現されることが多いです。

多層防御として組み立てる

これらは単独では穴が残り、重ねて初めて サプライチェーン全体を覆えます。攻撃面ごとに担当が違うことを押さえるのが要点です。

実装の勘所は、これらの検証を CI/CD パイプラインに強制する関所として組み込む ことです。来歴のないイメージや、SLSA レベルが基準未満の成果物は、デプロイ前のアドミッション制御で 拒否 する（CI/CD やGitOps のポリシーゲート）。「来歴を生成するだけ」で 検証しなければ 意味がない点に注意が要ります。生成と検証は別物で、防御になるのは後者です。

まとめ

• 来歴（provenance）は「どのソースをどのビルダーがどう作ったか」の署名付き記録。成果物ハッシュとの照合で改竄・差し替えを機械的に検出する。
• SLSA はビルド完全性の成熟度レベル。来歴開示（L1）→ホスト型ビルドの署名付き自動生成（L2）→隔離と鍵到達不能による改竄耐性（L3）と上がる。保証範囲はあくまでビルド工程。
• SBOM（SPDX/CycloneDX）は「何が入っているか」の部品表。VEX で到達可能性を補い、脆弱性公表時の影響範囲を即特定する。来歴とは補完関係。
• in-toto は工程ごとの署名済み attestation を連鎖させ、受け渡しの封緘を検証する。SLSA 来歴はこの形式で表現されることが多い。
• 各層は単独では穴が残る。署名鍵の隔離（keyless）と、CI/CD での 検証の強制 を含め、多層で重ねて初めて防御になる。