📖 推定読了時間：約6分
オープンソースソフトウェア（OSS）は現代のあらゆるWebサービスや企業システムの土台ですが、近年その土台を根底から揺るがす深刻なサイバーインシデントが急増しています。2020年のSolarWinds事件や2024年のXZ Utilsバックドア事件のように、**「開発者の認証情報を盗み、ビルド環境や公開リポジトリを改ざんして、無害を装った悪意あるコードを配布する」**というサプライチェーン攻撃です。
どれほど安全なコードを書いても、配布されるコンテナイメージやライブラリ自体がビルドの隙間にすり替えられてしまえば防ぎようがありません。この悪夢を根本から根絶するためにGoogleやLinux Foundationが中心となって標準化したのが、来歴証明フレームワーク「SLSA（サルサ）」と、画期的なキーレス暗号署名基盤「Sigstore（シグストア）」です。
この記事のポイント
- 従来のPGP署名が抱えていた「秘密鍵の紛失・漏洩・鍵管理の破綻」問題
- 短寿命証明書と透過性ログ（Rekor）による「キーレス署名」の仕組み
- 成果物がどのソース・どのCIジョブから生成されたかを保証するSLSAの来歴（Provenance）
- KubernetesのAdmission Controllerと連携した「未署名コンテナの起動拒否」実践
1. なぜ従来のコード署名（PGP等）は破綻したのか？
これまでもコードの正当性を証明する手段としてPGP/GPG署名は存在しました。しかし、現実の開発現場では「開発者のローカルPCにある秘密鍵がマルウェアで盗まれる」「鍵の有効期限管理が放置される」「Web of Trust（信頼の輪）が機能しない」といった運用上の破綻が常態化していました。
攻撃者はCIパイプラインの途中に侵入し、テスト済みの成果物をこっそり悪意あるバイナリに差し替えて正規の鍵で署名させる手法（ビルド環境汚染）を確立させてしまったのです。
- ⚠️長寿命な秘密鍵の存在：CI/CDのシークレット変数や開発機に秘密鍵を保存する限り、漏洩リスクが常に付きまとう。
- ⚠️来歴（Provenance）の不在：「誰の鍵で署名されたか」は分かっても、「どのGitコミットから、どのビルド環境で生成されたか」が第三者に証明できない。
- ⚠️検証の自動化困難：デプロイ時にKubernetesクラスタ側で署名を自動検証する仕組みが普及していなかった。
クラウドネイティブ環境におけるDevSecOpsパイプライン全体の堅牢化については、コンテナセキュリティDevSecOps実践解説書などを参照すると、コンテナの静的脆弱性スキャンと動的ポリシー適用の実践ノウハウが身につきます。
2. Sigstoreがもたらした「キーレス署名」の魔法
Sigstoreの革新性は、Webにおける「Let's Encrypt」のように、署名から面倒な秘密鍵管理を完全に消し去った（キーレス化した）点にあります。その心臓部は以下の3大コンポーネントで構成されています。
| コンポーネント | 役割 | 技術的メカニズム |
|---|---|---|
| Fulcio（認証局） | 短寿命証明書の発行 | OIDCトークン（GitHub ActionsやGoogleアカウント）を検証し、有効期間わずか10分程度の使い捨てX.509証明書を発行 |
| Rekor（透過性ログ） | 改ざん不能な署名台帳 | マークルツリー構造による追記専用台帳。誰がいつ何を署名したかを公開し、後からの改ざんや否認を防止 |
| Cosign（署名ツール） | アーティファクトの署名・検証 | コンテナレジストリ（OCI）に署名やメタデータを直接アタッチし、デプロイ時に検証するCLI |
ビルド時、CI環境（GitHub Actions等）はオンメモリで一時的な公開鍵・秘密鍵ペアを生成します。Fulcioから短寿命証明書を取得して成果物に署名し、その記録をRekorに刻んだら、**秘密鍵をメモリから即座に破棄**します。秘密鍵がどこにも保存されないため、「秘密鍵が盗まれるリスク」そのものが物理的に消滅するのです。
認証やアクセス制御の根本原理を学び直すには、セキュリティ実践入門などの入門書で公開鍵暗号やOIDCフェデレーションの基礎を固めておくと理解がスムーズです。
「秘密鍵を持たないのにどうやって後から検証するのか？」と疑問に思うかもしれませんが、Rekorの透明性ログに『証明書が有効だったその10分間に確かに署名された』という暗号学的タイムスタンプが永久保存されるため、完全な検証が可能です。
3. SLSAフレームワーク：成果物の「生まれ故郷」を保証する
Sigstoreが「印鑑」だとすれば、SLSA（Supply-chain Levels for Software Artifacts）は「戸籍謄本」です。ソフトウェアがソースコードからバイナリになるまでの全工程において、不正な介入がなかったかを段階的に保証します。
特に最高峰の「SLSA Level 3/4」では、以下の厳格な条件が求められます。
- 🛡️隔離されたビルド環境：他のジョブからメモリやディスクを覗き見できない専用ランナーで実行されること。
- 🛡️改ざん不能な来歴（Provenance）：ビルドランナー自体が「この成果物はリポジトリXのコミットYから生成された」という暗号証明書を発行すること。開発者が偽装することは不可能。
- 🛡️2名以上のレビュー承認：コードの変更が最低2人の人間によってレビューされマージされていること。
4. 導入時の重大な落とし穴：検証の自動化抜け
SigstoreやSLSAを導入する組織が最も陥りがちな致命的ミスがあります。それは「署名をつけて満足し、本番クラスタでの検証（ポリシー強制）を忘れる」ことです。
💡 KyvernoやPolicy Controllerで「未署名イメージはPod起動拒否」を徹底せよ
どれほど精巧な署名や来歴を作成しても、本番Kubernetesが未署名の野良イメージをそのまま受け入れて起動してしまえば、セキュリティ上の意味はありません。デプロイパイプラインのゲートウェイでCosign検証を行い、指定のGitHubリポジトリから発行された有効な証明書を持たないイメージは即座に拒否するアドミッション制御を必ずセットで構築してください。
また、CI/CDの設定変更権限や本番クラスタへのアクセス権を持つ管理者のアカウントには、フィッシング耐性のあるFIDO2対応ハードウェアセキュリティキー（YubiKey等）を義務付けることで、ID乗っ取りによるパイプライン侵害を鉄壁に防御できます。
まとめ
ソフトウェアサプライチェーン攻撃の巧妙化が進む中、「性善説に基づいたOSS利用」の時代は完全に終わりました。Sigstoreによるキーレス署名とSLSAによる厳密な来歴証明は、開発者と利用者の間に真の信頼の架け橋を築く必須インフラです。
GitHub Actionsなら、数行のワークフロー設定を追加するだけで公式のSLSAジェネレーターやCosign署名を今すぐ体験できます。自社の成果物にもデジタルの「安全封印」を施してみませんか？
0 件のコメント:
コメントを投稿