サプライチェーンの完全性(SBOM・Sigstore・SLSA)

「出所を証明できる成果物」を組み立てる

サプライチェーン攻撃 の本質は、自社コードではなく「信頼して取り込む調達過程」が汚染源になる点にあります。だから防御の目標は、配布される成果物（バイナリ・コンテナイメージ・パッケージ）について「何で出来ているか・誰が・どのソースから・どう作ったか」を、受け取り側が機械的に検証できる状態にすることです。ここで噛み合う三つの部品が、構成を記す SBOM、改ざん不能に署名する Sigstore、ビルド経緯を保証する SLSA / in-toto です。これらは別々の規格ですが、最終的には「成果物 → 署名 → 来歴 → 構成部品」を一本の検証可能な鎖にまとめ、取り込み前にポリシーで強制するために組み合わされます。

SBOM:成果物の機械可読な部品表

SBOM(Software Bill of Materials) は、成果物に含まれる全コンポーネントを、名前・バージョン・一意識別子つきで列挙した部品表です。人間向けの一覧ではなく、ツールで突き合わせられる機械可読である点が要です。各コンポーネントは purl(package URL、例 pkg:npm/left-pad@1.3.0) や CPE で識別され、脆弱性データベース(CVE/OSV)と照合できます。新しい脆弱性が公表された瞬間に「自分の成果物が影響を受けるか」を、棚卸しではなくクエリ一発で判定できるのが最大の利得です。

二大フォーマットが SPDX(ISO/IEC 5962、ライセンス管理由来) と CycloneDX(OWASP、セキュリティ由来) です。重要なのは依存の深さで、直接依存だけでなく推移的依存まで列挙して初めて意味を持ちます。

Sigstore:鍵を持たない keyless 署名

成果物への署名は完全性の土台ですが、従来方式の弱点は長期の秘密鍵管理でした。鍵が漏れれば全署名が危うく、失効・ローテーションも重い。Sigstore はこれを keyless 署名で解きます。発想は「長期鍵を持たず、その都度ごく短命の証明書を発行する」ことです。

keyless 署名のフロー(概念):

1. 署名者がローカルで一時鍵ペア(ephemeral key)を生成
2. OIDC で身元を証明する ID トークンを取得
   (CI なら GitHub Actions 等のワークロード ID、人なら Google/GitHub アカウント)
3. Fulcio(認証局)へ ID トークン + 公開鍵を提示
   → Fulcio は「この身元(メール/ワークロード)= この公開鍵」を束ねた
     有効期間 約20分 の短命 X.509 証明書を発行
4. その一時鍵で成果物に署名
5. 署名 + 証明書 + 公開鍵を Rekor(透明性ログ)へ記録
6. 一時鍵は破棄してよい(証明書はすぐ失効する)

肝は、秘密鍵を保管しない点です。鍵は署名直後に捨ててよく、証明書は十数分で失効するため、漏れても悪用余地がほとんどありません。「鍵そのもの」ではなく「OIDC で確認した身元」を信頼の起点に置き換えたわけです。証明書チェーンの検証は通常の X.509 チェーン検証 と同じ枠組みで、信頼の根は Fulcio のルート CA になります。

Rekor:署名を消せなくする透明性ログ

短命証明書には弱点があります。署名後すぐ証明書が失効するなら、検証時にはもう有効期間が切れている――これでは検証できません。これを解くのが Rekor(透明性ログ、transparency log) です。

Rekor は 追記専用(append-only)の Merkle 木 ログで、署名・証明書・成果物ハッシュのエントリを記録し、署名がその証明書の有効期間内に行われた事実をタイムスタンプ付きで固定します。検証側は「証明書が今有効か」ではなく「Rekor に載った時刻に有効だったか」を確認します。

検証ロジック(概念):
  Rekor のエントリ = { 成果物ハッシュ, 署名, Fulcio 証明書, 包含証明, 署名時刻 }
  ① 包含証明で「このエントリは確かに Rekor に存在する」を検証
  ② 署名時刻が Fulcio 証明書の有効期間内かを確認
  ③ 証明書の身元(OIDC identity)が期待する署名者かをポリシー照合
  ④ 署名が成果物ハッシュに対し正しいかを暗号検証

Merkle ログなので、運営者でも過去エントリの差し替えができず、一貫性証明で「人によって違う履歴を見せる split-view」も監査で検出できます。結果、「誰が・いつ・どの成果物に署名したか」が消去・改ざん不能な公開記録として残ります。

in-toto と SLSA:ビルドの来歴を保証する

署名は「配布物が改ざんされていない」を保証しますが、「そのビルド自体が正しく行われたか」は別問題です。汚染された CI が綺麗なソースから汚れた成果物を作り、正規署名を付けてしまえば素通りされます。ここを埋めるのが来歴(provenance) で、その枠組みが in-toto と SLSA です。

in-toto attestation は、ビルドの各ステップについて「この入力(ソース/依存)から、このビルダーが、この成果物を生成した」という対応関係を、署名付きの宣言(statement) として残す仕組みです。predicate(述語)部分に来歴・SBOM・脆弱性スキャン結果などを差し込め、Sigstore で署名・Rekor 記録するのが典型構成です。

SLSA(Supply-chain Levels for Software Artifacts) は、来歴の厳密さを段階化したフレームワークです。「証明したいか」ではなく「どこまで改ざんしにくいビルドか」を基準にレベルを定めます。

レベルが上がるほど、ビルダーは独立・隔離され(ステップ間で環境を共有しない)、来歴はビルダー自身が署名して人手で改ざんできなくなります。SLSA L3 ともなると、ソースの改ざん・ビルド経路の汚染・来歴の偽造をまとめて潰せます。

多層防御として束ねる

各部品は単独でも有効ですが、防御として効くのは鎖としてポリシーで強制したときです。攻撃面ごとに、どの部品が効くかを対応づけます。

実務では取り込み(admission)時にこれらを検証ポリシーで強制します。例えば「Rekor に署名があり、来歴のリポジトリが許可リストに入り、SLSA L3 以上で、SBOM に既知 Critical 脆弱性がない成果物だけをデプロイ可」といった具合です。ビルダーの権限を 最小権限 に絞り、シークレット管理 を固めることが、来歴の信頼の前提になります。

サプライチェーンの完全性を「署名すれば安心」で止めず、SBOM が答える問い・keyless 署名がなぜ鍵を捨てられるのか・透明性ログが何を不能にするか・来歴がビルドの何を保証するかまで分解できると、汚染がどの層で止まるか、なぜ単独の対策では素通りされるかが一本の線でつながります。