サプライチェーンセキュリティ：本番アーティファクトのためのSLSA、SBOM、Sigstore

現在の監査で最も難しい質問は、「コードにCVEはないか？」ではなく、「本番で稼働しているアーティファクトが、改ざんなくこのソースからビルドされたことをどう証明するか？」です。

代表的な3種類のサプライチェーン攻撃

依存関係の取り違え / タイポスクワット（npm、pypi、RubyGems）：社内ライブラリと似た名前のパッケージを公開する手口。
ソースの侵害（xz utils、Codecov bash uploader）：上流プロジェクトに悪意あるコードを注入する手口。
ビルドポイズニング（SolarWinds）：ビルドサーバを侵害し、ソースコードはクリーンなままアーティファクトに注入する手口。

標準的な対応フレームワークは、OpenSSFがメンテナンスするSLSA（Supply-chain Levels for Software Artifacts）です。

SLSA——ビルド完全性の4段階

レベル	主な要件
L1	ビルドが文書化されており、基本的なprovenanceを生成。
L2	ホスト型CIでのビルド、provenanceに署名、ソースはバージョン管理。
L3	分離・ハードニングされた環境でのビルド、ユーザーがprovenanceを偽造できない。
L4	密閉的（hermetic）かつ再現可能なビルド、2者レビュー。

多くの組織にとっての現実的な目標はSLSA Build L2-L3です。L4はまだ稀でコストもかかります。

SBOM：CycloneDXとSPDX、どちら？

2つの標準フォーマット：

CycloneDX（OWASP）：セキュリティユースケースに重点を置き、脆弱性、サービス、MLモデルをサポート。ツールエコシステムが豊富（Trivy、Syft、Dependency-Track）。
SPDX（Linux Foundation）：ライセンスコンプライアンス重視で、多くの規制当局に受け入れられている（米国EO 14028）。

主軸となる1つを選び、必要に応じてもう一方の形式へエクスポートしましょう。各本番アーティファクトには、CIで自動生成されたSBOMがアーティファクトと一緒に保存されている必要があります。

Sigstore：あらゆるアーティファクトに対するキーレス署名

Sigstoreは3つのコンポーネントで構成されます：

Cosign：イメージ、blob、attestationの署名/検証CLI。
Fulcio：OIDCアイデンティティに基づく短命証明書（TTL 5分）を発行するCA。
Rekor：すべての署名を保存する不変な透明性ログ——あなたのアイデンティティで作成された不審な署名がないかを確認できます。

最大のメリット：保管・ローテーション・バックアップが必要な秘密鍵が存在しません。

Provenanceとin-toto attestation

Provenanceは誰が、どのソースから、どのツールで、いつビルドしたかを記述するメタデータです。標準フォーマットは、predicate type https://slsa.dev/provenance/v1を持つin-toto attestationです。

GitHub Actionsには公式のジェネレーターがあります：

jobs:
  build:
    outputs:
      digest: ${{ steps.push.outputs.digest }}
    # ... build & push image
provenance:
needs: [build]
permissions:
id-token: write
packages: write
contents: read
uses: slsa-framework/slsa-github-generator/.github/workflows/[email protected]
with:
image: ghcr.io/org/app
digest: ${{ needs.build.outputs.digest }}
registry-username: ${{ github.actor }}

このワークフローは分離された再利用可能ワークフロー内でビルドし、provenance生成 + Cosignキーレス署名を行います——追加コードなしでSLSA L3に到達できます。

デプロイ前のprovenance検証

cosign verify-attestationを使用：

cosign verify-attestation --type slsaprovenance \
  --certificate-identity-regexp "https://github.com/org/.+/.github/workflows/build.yml@.+" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
  ghcr.io/org/app@sha256:...

あるいは、OIDC subjectをattestorとするKyverno verifyImagesでクラスタ内にエンフォースします。正しいprovenanceを持たないイメージはアドミッションで拒否されます。

依存関係を賢く管理する

ダイジェスト/ロックファイルでピン留め：package-lock.json、poetry.lock、go.sum。latestは絶対に避ける。
GitHub ActionはSHAでピン留め（タグは移動可能なため）。
npm/pypiパブリックから直接プルするのではなく、社内パッケージ用のベンダーミラー（Artifactory、Nexus）を用意。
Renovate/Dependabotにはポリシーを設定：パッチは自動マージ、マイナー/メジャーは手動レビュー、悪意あるバージョンが公開直後に取り込まれないようクールダウンを設ける。

サプライチェーンの簡潔なチェックリスト

すべての本番アーティファクトにCycloneDX/SPDX形式のSBOMがあり、保管されている。
イメージはCosignキーレスで署名され、署名がRekorに保存されている。
ビルドは分離された再利用可能ワークフローで実行（SLSA L2-L3を達成）。
クラスタには、Pod許可前に署名 + provenanceを検証するポリシーがある。
依存関係はロックファイル + ダイジェストでピン留めされ、社内ミラーがある。
Dependency-TrackがSBOM経由でロングテールなCVEを追跡している。

結論

サプライチェーンセキュリティはもはやオプションではありません——EU CRA、米国EO 14028、多くのエンタープライズ顧客がRFPでSBOMと署名済みアーティファクトを要求しています。良いニュース：オープンスタックのSigstore + SLSA + CycloneDXは、OpenSSFの再利用可能ワークフローのおかげで、ほぼゼロコストでSLSA L3に到達できます。これを2026年に必須となる技術ベースラインとして扱いましょう。