はじめに
近年のセキュリティインシデントの多くは、アプリケーションそのものではなく、ソフトウェアサプライチェーンを狙った攻撃です。
- 依存パッケージの改ざん
- CI/CDパイプライン侵害
- ビルド成果物のすり替え
こうしたリスクに対抗するために登場したのが、SLSA（Supply-chain Levels for Software Artifacts）です。
SLSAは、ソフトウェアの信頼性を段階的に高めるための成熟度モデルです。
1. SLSAとは？
SLSAはGoogle主導で提唱された、ソフトウェアサプライチェーンのセキュリティフレームワークです。
目的
- ソフトウェアの出所を証明する
- 改ざんを防ぐ
- 再現可能なビルドを実現する
2. SLSAレベル（1〜4）
| レベル | 概要 |
|---|---|
| SLSA 1 | ビルドプロセスの記録（ログあり） |
| SLSA 2 | 改ざん防止されたビルド環境 |
| SLSA 3 | 信頼されたビルドサービス |
| SLSA 4 | 完全な再現性・検証可能なビルド |
3. 各レベルの詳細
SLSA Level 1
- ビルドプロセスの可視化
- ログ保存
SLSA Level 2
- CI/CDの認証（GitHub Actionsなど）
- ビルド定義のバージョン管理
SLSA Level 3
- 改ざん不可能なビルド環境
- 署名付きビルド
SLSA Level 4
- 再現可能ビルド（Reproducible Builds）
- ソースと成果物の完全一致検証
4. SLSAとSigstoreの関係
SLSAの実装において重要なのがSigstoreです。
| SLSA要件 | Sigstore対応 |
|---|---|
| 署名 | cosign |
| 証明書 | Fulcio |
| 透明ログ | Rekor |
5. SLSA準拠CI/CDアーキテクチャ
Source（Git） ↓ CI（GitHub Actions） ↓ Build（再現可能） ↓ Sign（cosign） ↓ Provenance生成 ↓ Verify（Kubernetes） 6. Provenance（証明情報）
SLSAの核心は「Provenance（来歴）」です。
{ "builder": "GitHub Actions", "source": "repo URL", "commit": "abc123", "artifact": "image digest" }この情報を検証することで信頼性を担保します。
7. Kubernetesでの活用
SLSAはKubernetesと組み合わせることで真価を発揮します。
- Admission Controllerで署名検証
- 未署名イメージの拒否
- Provenanceチェック
8. 実務での導入ステップ
Step1
CI/CDログの保存（Level 1）
Step2
OIDC認証導入（Level 2）
Step3
Sigstore署名（Level 3）
Step4
再現可能ビルド（Level 4）
9. よくある課題
- 再現可能ビルドが難しい
- 開発フローが複雑化
- ツール統合の難易度
10. ベストプラクティス
- 段階的導入（Level 1→3）
- Sigstoreを標準採用
- CI/CDと完全統合
まとめ
- SLSAはサプライチェーンセキュリティの標準
- Level 3以上で実用レベル
- Sigstoreと組み合わせることで実現可能
これからの時代、「信頼できるビルド」だけが本番に入るのが前提になります。
