SBOMとSigstore完全入門！ソフトウェアサプライチェーン攻撃を防ぐ次世代セキュリティ

現代のWebアプリケーションやクラウドインフラ開発において、オープンソースソフトウェア（OSS）の活用はもはや不可欠です。しかし、私たちが日々npm installやpip install、Dockerイメージのプルで行っている依存パッケージの取り込みに、深刻なセキュリティ脅威が潜んでいることをご存知でしょうか？

攻撃者が人気のOSSメンテナのアカウントを乗っ取ったり、タイポスクワッティング（意図的なタイプミスを誘う悪意ある同名パッケージ）を仕掛けたりして、ビルド時にバックドアを埋め込む「ソフトウェアサプライチェーン攻撃」が世界中で激増しています。

この脅威に対抗するための世界標準が、「SBOM（Software Bill of Materials: ソフトウェア部品表）」とオープン署名規格「Sigstore」です。本記事では、すべての依存関係を可視化し、CI/CDパイプライン上でコンテナやバイナリの真正性を保証する実践手法を解説します。

1. なぜ「SBOM」が世界中で義務化されているのか？

SBOM（ソフトウェア部品表）とは、料理でいう「原材料表示ラベル」のようなものです。アプリケーションが利用している直接のライブラリだけでなく、間接的に依存している数千〜数万個のサブパッケージ、バージョン、ライセンス、ハッシュ値を機械可読な形式（JSONやXML）で一覧化します。

米国のサイバーセキュリティ大統領令をはじめ、日本国内でも経済産業省がガイドラインを策定するなど、政府調達やエンタープライズ開発においてSBOMの提出・管理が急速に義務化されています。Log4jの脆弱性のように「自社システムのどこに危険なライブラリが使われているか分からない」という事態を秒単位で特定するために不可欠だからです。

GitHub ActionsなどのCI/CD環境で自動化されたセキュリティテストやGitワークフローを構築する際は、GitHub・Git実践入門書籍でパイプラインの安全な設計パターンを学んでおくと、開発効率と堅牢性を両立できます。

2. Sigstore（Cosign）が変えた「キーレス署名」の革命

SBOMを生成しても、「そのコンテナイメージやSBOM自体が途中で改ざんされていないか」を証明できなければ意味がありません。従来のPGP暗号署名は「秘密鍵の紛失・流出リスク」が常に問題でした。

Linux Foundation傘下で開発されたSigstore（Cosign）は、秘密鍵を永久管理する必要のない「キーレス（Keyless）署名」を実現しました。

• 🔑OIDC（OpenID Connect）連携：GitHubやGoogleのアカウント認証を利用して、署名実行時のみ有効な「短命な証明書（数分で失効）」を発行。
• 📜Rekor（改ざん不能な透明性ログ）：署名された事実をブロックチェーンに似た公開監査ログに追記し、後からの偽造を完全防止。
• 🛡️Kubernetesデプロイ時自動ブロック：信頼された署名がないコンテナの実行をクラスタ側で自動遮断。

開発者アカウントやGitHubのコミット署名のセキュリティを最高レベルに引き上げるには、フィッシング耐性を持つ物理トークンであるFIDO2対応ハードウェアセキュリティキー（YubiKey等）を組み合わせるのが業界標準のベストプラクティスです。

3. CI/CDパイプラインへの組み込み手順

GitHub ActionsにおけるSBOM生成と署名の標準的な流れは以下の通りです。

まとめ

ソフトウェアサプライチェーンセキュリティは、もはや大規模企業だけでなく、すべてのWebサービスやオープンソース開発者が取り組むべき基本インフラとなりました。

SBOMの自動出力とSigstoreによるキーレス署名は、既存のCI/CDパイプラインにわずか数ステップで組み込めます。開発物の透明性と信頼性を高めるために、ぜひ次のリリースサイクルから導入してみてください。