<p><!--META { "title": "SLSA Provenanceとサプライチェーンセキュリティの脅威と対策", "primary_category": "DevSecOps", "secondary_categories": ["サプライチェーンセキュリティ","ソフトウェア開発"], "tags": ["SLSA", "Provenance", "Supply Chain Security", "SBOM", "Sigstore", "in-toto", "DevSecOps"], "summary": "SLSA Provenanceを活用したソフトウェアサプライチェーンの脅威モデル、攻撃シナリオ、検出・緩和策、運用対策をセキュリティエンジニア視点で解説します。", "mermaid": true, "verify_level": "L0", "tweet_hint": {"text":"ソフトウェアサプライチェーンのセキュリティ強化に不可欠なSLSA Provenanceについて、脅威モデルから具体的な対策、運用上の落とし穴まで解説。Mermaidによる攻撃チェーン図解も。 #SLSA #サプライチェーンセキュリティ #DevSecOps","hashtags":["#SLSA","#サプライチェーンセキュリティ","#DevSecOps"]}, "link_hints": ["https://slsa.dev/blog/2023/10/slsa-1.0", "https://cloud.google.com/blog/products/identity-security/how-slsa-helps-improve-supply-chain-security-and-compliance", "https://www.sigstore.dev/about", "https://owasp.org/www-project-top-10-software-supply-chain-risks/"] } --> 本記事は<strong>Geminiの出力をプロンプト工学で整理した業務ドラフト（未検証）</strong>です。</p> <h1 class="wp-block-heading">SLSA Provenanceとサプライチェーンセキュリティの脅威と対策</h1> <p>ソフトウェアサプライチェーンセキュリティは、現代のデジタルエコシステムにおいて最も重要な課題の一つです。コードの開発からデプロイ、運用に至るまで、サプライチェーンのあらゆる段階で悪意ある攻撃者が脆弱性を狙っています。この脅威に対抗するため、SLSA (Supply-chain Levels for Software Artifacts) Provenanceが注目されています。本記事では、セキュリティエンジニアの視点から、SLSA Provenanceの脅威モデル、具体的な攻撃シナリオ、検出・緩和策、そして現場における運用上の落とし穴とベストプラクティスについて解説します。</p> <h2 class="wp-block-heading">脅威モデル：ソフトウェアサプライチェーンの多層的攻撃ベクトル</h2> <p>ソフトウェアサプライチェーン攻撃とは、ソフトウェアのライフサイクル（設計、開発、ビルド、パッケージング、配布、更新）のいずれかの段階で、悪意のあるコードの挿入、改ざん、または信頼性の不正な確立を試みる攻撃です。SLSA Provenanceは、特に「ビルドの整合性」と「成果物の信頼性」を確保することに主眼を置いています。</p> <p>主な攻撃ベクトルは多岐にわたり、OWASP Top 10 for Software Supply Chain Risks (2023年9月12日更新)[5]でも、未検証のコンポーネントの利用やセキュアでないビルドパイプラインが上位に挙げられています。SLSAは、ソースコードの出所、ビルドプロセスの透明性、成果物の真正性を示す「Provenance（来歴情報）」を生成・検証することで、これらの脅威に対処しようとします。具体的には、Provenanceは以下の情報を記録します[1,2]：</p> <ul class="wp-block-list"> <li><p><strong>誰が (Who)</strong>：ビルドを行ったエンティティ。</p></li> <li><p><strong>何を (What)</strong>：ビルドされた成果物と、その入力（ソースコード、依存関係）。</p></li> <li><p><strong>どこで (Where)</strong>：ビルドが実行された環境。</p></li> <li><p><strong>どのように (How)</strong>：ビルドのコマンドとプロセス。</p></li> </ul> <p>攻撃者は、このProvenance自体を偽装または改ざんすることで、不正な成果物に正当性があるかのように見せかけることが可能です。</p> <h2 class="wp-block-heading">攻撃シナリオ：偽造されたProvenanceによる信頼チェーンの破壊</h2> <p>SLSAが導入されていても、その実装に不備があれば、攻撃者は信頼されたサプライチェーンを悪用できます。ここでは、偽造されたProvenanceを利用した攻撃シナリオをMermaid Attack Chainとして可視化します。</p> <div class="wp-block-merpress-mermaidjs diagram-source-mermaid"><pre class="mermaid"> graph TD A["攻撃者"] --> |1. ビルドシステム脆弱性悪用| B("脆弱なCI/CDビルド環境") B --> |2. 悪意あるコード注入| C("改ざんされたソースコード/依存関係") C --> |3. 不正なビルド実行| D("改ざんされたビルドプロセス") D --> |4. 偽装Provenance生成| E("偽装Provenance付き悪意あるArtifact") E --> |5. 成果物リポジトリへプッシュ| F("信頼されたArtifact Registry") F --> |6. 正規Artifactとしてダウンロード| G("利用者/ダウンストリームシステム") G --> |7. 悪意のあるコード実行| H("システム侵害") subgraph 攻撃目標: Provenanceの信頼性破壊 E end </pre></div> <p><strong>攻撃シナリオの詳細:</strong></p> <ol class="wp-block-list"> <li><p><strong>ビルドシステム脆弱性悪用 (ステップ1)</strong>: 攻撃者は、CI/CDパイプラインやビルドシステム自体の脆弱性（例：設定ミス、パッチ未適用、不適切な認証情報管理）を突いて、不正アクセスを試みます。</p></li> <li><p><strong>悪意あるコード注入 (ステップ2)</strong>: アクセスに成功した攻撃者は、ビルド対象のソースコードや、使用される依存関係（ライブラリ、パッケージ）に悪意あるコードを注入します[5]。</p></li> <li><p><strong>不正なビルド実行 (ステップ3)</strong>: 攻撃者は、改ざんされたソースコードを使って、正規のビルドプロセスを模倣し、悪意あるコードを含むArtifactを生成させます。この際、ビルド環境も攻撃者の制御下にあるため、正規のビルドステップを回避したり、不正なステップを追加したりすることが可能です。</p></li> <li><p><strong>偽装Provenance生成 (ステップ4)</strong>: SLSA Provenanceの生成はビルド環境で行われるため、攻撃者はビルド環境を制御下におくことで、このProvenance情報自体を偽装します。例えば、悪意あるコードが注入されたにもかかわらず、ビルドが「クリーン」であったかのように偽の署名付きProvenanceを生成する可能性があります。NCC Groupの研究 (2022年11月10日)[6]でも、Provenance生成プロセス自体が攻撃対象となるリスクが指摘されています。</p></li> <li><p><strong>成果物リポジトリへプッシュ (ステップ5)</strong>: 偽装されたProvenanceを持つ悪意あるArtifactは、正規のArtifactとして信頼されたレジストリ（例：OCIレジストリ、Mavenリポジトリ）にアップロードされます。</p></li> <li><p><strong>正規Artifactとしてダウンロード (ステップ6)</strong>: ダウンストリームのシステムや利用者は、Artifactに添付されたProvenanceが「正当」であると判断し、これをダウンロード・利用します。</p></li> <li><p><strong>システム侵害 (ステップ7)</strong>: ダウンロードされた悪意あるArtifactが実行され、利用者のシステムが侵害されます。この時、Provenanceは「正規」のものであるため、攻撃の検出が困難になります。</p></li> </ol> <p>このシナリオでは、SLSA Provenanceが単に「存在すること」だけでなく、「そのProvenance自体が信頼できる環境で生成されたこと」が極めて重要であることが示唆されます。</p> <h2 class="wp-block-heading">検出と緩和策：SLSA Provenanceによる検証と保護</h2> <p>SLSA Provenanceは、上記のような脅威を緩和するための強力なツールですが、その導入と運用には細心の注意が必要です。</p> <h3 class="wp-block-heading">SLSAレベルの適用と自動化</h3> <p>SLSAは、セキュリティの厳格さに基づいて4つのレベル（L1～L4）を定義しています[1,2]。</p> <ul class="wp-block-list"> <li><p><strong>L1 (基本)</strong>: 非改ざんのProvenanceを生成。</p></li> <li><p><strong>L2 (強化)</strong>: バージョン管理されたソースとビルドサービスの利用。</p></li> <li><p><strong>L3 (堅牢)</strong>: テンポラリビルド、分離されたビルド、パラメーター化されたビルド、ビルドスクリプトによるビルド。</p></li> <li><p><strong>L4 (最高)</strong>: 2人によるレビュー、ソースとビルドの厳格な分離、最小特権のビルド。</p></li> </ul> <p>L3以上のSLSAレベルを目標とし、ビルドプロセスにProvenanceの自動生成と検証を組み込むことが重要です。Google Cloud BuildなどのCI/CDサービスは、SLSA Provenanceの自動生成機能を備えています (2024年5月14日更新)[1]。</p> <h3 class="wp-block-heading">暗号とプロトコルの誤用と安全な代替</h3> <p>Provenanceの信頼性を保証するためには、署名が不可欠です。鍵管理の誤用は、サプライチェーンセキュリティの致命的な弱点となります。</p> <h4 class="wp-block-heading">鍵/秘匿情報の取り扱い</h4> <p><strong>誤用例：ハードコードされた署名鍵や長期間利用される秘密鍵</strong></p> <div class="codehilite"> <pre data-enlighter-language="generic"># 誤用例1: 秘密鍵をリポジトリにコミット、または環境変数に平文で保存 # 攻撃者によって容易に窃取されるリスク echo "PRIVATE_SIGNING_KEY=-----BEGIN PRIVATE KEY-----..." > /etc/secrets/signing_key.env export GPG_SIGNING_KEY_ID="0xDEADBEEF" # 長期利用される鍵 # 誤用例2: 署名検証時に公開鍵を適切に検証しない # 攻撃者が偽の公開鍵と署名を用意した場合に素通りする可能性 gpg --verify artifact.sig artifact.tar.gz # -> 鍵のフィンガープリント、信頼パスなどを確認しないと危険 </pre> </div> <p><strong>問題点</strong>: 鍵の漏洩リスクが高く、一度漏洩すると全てのProvenanceが偽装され得る。長期鍵は攻撃者に悪用される時間が長く、定期的な交換も困難。</p> <p><strong>安全な代替：Sigstoreのキーレス署名とKMS連携</strong></p> <p>Sigstoreは、OpenID Connect (OIDC) と連携し、短期間のみ有効な「Ephemeral Key（一時的な鍵）」を発行する「キーレス署名」を提供します[4,7,8]。これにより、開発者やCI/CDシステムが秘密鍵を直接管理する必要がなくなり、鍵漏洩のリスクを大幅に低減します。</p> <div class="codehilite"> <pre data-enlighter-language="generic"># 安全な代替例1: Sigstore cosign を使用したキーレス署名 # OIDCプロバイダ（GitHub Actions, Google Cloud Buildなど）と連携し、 # 一時的な証明書と署名鍵を自動的に生成・破棄。 # 署名と同時にRekor透明性ログに記録される。 # 入力: イメージ名（例: my-registry/my-app:latest） # 出力: 署名付きイメージマニフェスト、Rekorエントリ # 前提: cosignがインストールされ、OIDC設定が完了している環境 # 計算量: ネットワーク通信によるOIDC認証とRekorへの書き込みに依存 # メモリ: 署名処理自体は軽微 cosign sign --yes my-registry/my-app:latest # 検証者側: 透明性ログ Rekor を参照してProvenanceを検証 # 入力: イメージ名 # 出力: 署名検証結果 # 前提: cosignがインストールされていること # 計算量: ネットワーク通信によるRekorへの問い合わせに依存 # メモリ: 署名検証処理自体は軽微 cosign verify my-registry/my-app:latest </pre> </div> <p><strong>補足</strong>: <code>cosign verify</code> は、Rekorに記録された証明書と署名、OIDC IDプロバイダからの身元情報を自動的に検証し、Provenanceの真正性を確認します。</p> <h4 class="wp-block-heading">ローテーション、最小権限、監査</h4> <ul class="wp-block-list"> <li><p><strong>鍵のローテーション</strong>: SigstoreのEphemeral Keyは、その性質上、署名ごとに新しい鍵が発行・破棄されるため、自動的に鍵ローテーションの要件を満たします。KMSを利用する場合も、定期的な鍵ローテーションポリシーを設定し、実施することが重要です。</p></li> <li><p><strong>最小権限の原則</strong>: Provenanceを生成・署名するCI/CDパイプラインやサービスアカウントには、そのタスクを遂行するために必要な最小限の権限のみを付与します。例えば、特定のリポジトリへのプッシュ権限と、特定のKMS鍵での署名権限のみを与えるなどです。</p></li> <li><p><strong>監査</strong>: 生成されたProvenanceと署名は、Rekorのような透明性ログに記録され、誰でも検証可能になります。これにより、不正なProvenanceの有無や、ビルドプロセスで何が起こったかの監査証跡が提供されます。定期的にこれらのログを監視し、異常を検出する体制を構築することが不可欠です。</p></li> </ul> <h2 class="wp-block-heading">運用対策：現場で考慮すべき落とし穴とベストプラクティス</h2> <p>SLSA Provenanceを実運用に乗せる際には、理論と実践の間でいくつかの「落とし穴」に遭遇する可能性があります。</p> <h3 class="wp-block-heading">現場の落とし穴</h3> <ul class="wp-block-list"> <li><p><strong>誤検知（False Positives）</strong>: 厳格すぎるProvenance検証ポリシーは、偶発的なビルド環境の差異や依存関係の更新によって、正当なArtifactを不正と判断してしまうことがあります。これにより、開発・デプロイパイプラインの停止や遅延が発生し、可用性が損なわれるトレードオフが生じます。</p></li> <li><p><strong>検出遅延（Detection Latency）</strong>: 攻撃者がProvenanceを巧妙に偽装した場合、その不正が発覚するまでに時間がかかる可能性があります。透明性ログのリアルタイム監視や、異常検知システムの導入が不十分だと、被害が拡大する恐れがあります。</p></li> <li><p><strong>可用性とのトレードオフ</strong>: 高いSLSAレベル（L3, L4）を達成するには、ビルドプロセスの分離、複数の承認者によるレビューなど、追加のプロセスとリソースが必要になります。これはビルド時間やデプロイ頻度に影響を与え、開発者の生産性やサービスの可用性との間でバランスを取る必要があります。</p></li> <li><p><strong>既存システムとの統合の複雑さ</strong>: 既存のレガシーなCI/CDパイプラインや独自のビルドツールにSLSA Provenanceの生成・検証機能を組み込むのは、大きな技術的負債となる場合があります。</p></li> <li><p><strong>Provenance生成者への信頼</strong>: Provenance自体が信頼できることを保証するには、Provenanceを生成するビルドシステム自体がセキュアである必要があります。もしビルドシステムが侵害されていれば、どんなに高いSLSAレベルのProvenanceを生成しても、その信頼性は揺らぎます。</p></li> </ul> <h3 class="wp-block-heading">ベストプラクティス</h3> <ol class="wp-block-list"> <li><p><strong>漸進的なSLSAレベルの導入</strong>: 最初からL4を目指すのではなく、まずはL1またはL2から導入し、段階的にセキュリティレベルを引き上げていくアプローチが現実的です。小規模なプロジェクトや重要度の低いコンポーネントから始め、経験を積んでいくことを推奨します。</p></li> <li><p><strong>SBOM (Software Bill of Materials) の活用</strong>: SLSA Provenanceと合わせてSBOM (Software Bill of Materials) を利用することで、使用されているオープンソースコンポーネントとそのバージョン、脆弱性情報を明確にし、サプライチェーン全体の可視性を高めることができます。</p></li> <li><p><strong>セキュリティ監査とペネトレーションテスト</strong>: 定期的にCI/CDパイプライン、ビルド環境、およびProvenance生成・検証プロセス全体に対してセキュリティ監査とペネトレーションテストを実施し、潜在的な脆弱性を特定・修正します。</p></li> <li><p><strong>開発者への教育とトレーニング</strong>: 開発チーム全体がSLSAの目的、仕組み、そしてセキュリティベストプラクティスを理解することが不可欠です。セキュアなコーディング習慣やツール利用のトレーニングを継続的に行います。</p></li> <li><p><strong>透明性ログの監視とアラート</strong>: Rekorのような透明性ログに記録されたProvenanceをリアルタイムで監視し、異常な署名活動や不整合なProvenanceが検出された場合には、即座にアラートを発するシステムを構築します。</p></li> </ol> <h2 class="wp-block-heading">まとめ：SLSA Provenanceで築く強固なサプライチェーン</h2> <p>SLSA Provenanceは、ソフトウェアサプライチェーンにおける信頼性を確立し、多層的な攻撃からシステムを保護するための不可欠なフレームワークです。単にProvenanceを生成するだけでなく、その<strong>生成環境のセキュリティ</strong>、<strong>鍵管理の堅牢性</strong>、そして<strong>検証プロセスの徹底</strong>が重要となります。Sigstoreのようなツールを活用し、キーレス署名と透明性ログを組み合わせることで、鍵管理の負担を軽減しつつ高いセキュリティを実現できます。</p> <p>しかし、SLSAの導入は一過性のものではなく、継続的な改善と運用が必要です。現場の落とし穴を理解し、漸進的なアプローチ、SBOMの活用、定期的な監査、そして開発者への教育を通じて、変化し続ける脅威に対抗し、強固で回復力のあるソフトウェアサプライチェーンを構築していくことが、セキュリティエンジニアに求められる責務です。</p> <hr/> <p><strong>参考文献:</strong> [1] Google Cloud Blog. “How SLSA helps improve supply chain security and compliance”. 2024年5月14日. <code>https://cloud.google.com/blog/products/identity-security/how-slsa-helps-improve-supply-chain-security-and-compliance</code> [2] SLSA Project Blog. “SLSA 1.0 is here!”. 2023年10月3日. <code>https://slsa.dev/blog/2023/10/slsa-1.0</code> [3] in-toto Project. “What is in-toto?”. (Accessed: 2024年7月29日). <code>https://in-toto.io/</code> [4] Sigstore Project. “About Sigstore”. (Accessed: 2024年7月29日). <code>https://www.sigstore.dev/about</code> [5] OWASP Foundation. “OWASP Top 10 for Software Supply Chain Risks”. 2023年9月12日. <code>https://owasp.org/www-project-top-10-software-supply-chain-risks/</code> [6] NCC Group Blog. “Attacking and Defending Supply Chains: A Case Study on SLSA”. 2022年11月10日. <code>https://research.nccgroup.com/2022/11/10/attacking-and-defending-supply-chains-a-case-study-on-slsa/</code> [7] Sigstore Blog. “Keyless Signing, How it Works and Why it’s Awesome”. 2022年4月26日. <code>https://www.sigstore.dev/blog/keyless-signing-how-it-works-and-why-its-awesome</code> [8] Google Cloud Blog. “How Sigstore works with Google Cloud Build and Artifact Registry”. 2022年5月10日. <code>https://cloud.google.com/blog/products/identity-security/how-sigstore-works-with-google-cloud-build-and-artifact-registry</code></p>

graph TD
    A["攻撃者"] --> |1. ビルドシステム脆弱性悪用| B("脆弱なCI/CDビルド環境")
    B --> |2. 悪意あるコード注入| C("改ざんされたソースコード/依存関係")
    C --> |3. 不正なビルド実行| D("改ざんされたビルドプロセス")
    D --> |4. 偽装Provenance生成| E("偽装Provenance付き悪意あるArtifact")
    E --> |5. 成果物リポジトリへプッシュ| F("信頼されたArtifact Registry")
    F --> |6. 正規Artifactとしてダウンロード| G("利用者/ダウンストリームシステム")
    G --> |7. 悪意のあるコード実行| H("システム侵害")

    subgraph 攻撃目標: Provenanceの信頼性破壊
        E
    end

# 誤用例1: 秘密鍵をリポジトリにコミット、または環境変数に平文で保存


# 攻撃者によって容易に窃取されるリスク

echo "PRIVATE_SIGNING_KEY=-----BEGIN PRIVATE KEY-----..." > /etc/secrets/signing_key.env
export GPG_SIGNING_KEY_ID="0xDEADBEEF" # 長期利用される鍵

# 誤用例2: 署名検証時に公開鍵を適切に検証しない


# 攻撃者が偽の公開鍵と署名を用意した場合に素通りする可能性

gpg --verify artifact.sig artifact.tar.gz

# -> 鍵のフィンガープリント、信頼パスなどを確認しないと危険

# 安全な代替例1: Sigstore cosign を使用したキーレス署名


# OIDCプロバイダ（GitHub Actions, Google Cloud Buildなど）と連携し、


# 一時的な証明書と署名鍵を自動的に生成・破棄。


# 署名と同時にRekor透明性ログに記録される。


# 入力: イメージ名（例: my-registry/my-app:latest）


# 出力: 署名付きイメージマニフェスト、Rekorエントリ


# 前提: cosignがインストールされ、OIDC設定が完了している環境


# 計算量: ネットワーク通信によるOIDC認証とRekorへの書き込みに依存


# メモリ: 署名処理自体は軽微

cosign sign --yes my-registry/my-app:latest

# 検証者側: 透明性ログ Rekor を参照してProvenanceを検証


# 入力: イメージ名


# 出力: 署名検証結果


# 前提: cosignがインストールされていること


# 計算量: ネットワーク通信によるRekorへの問い合わせに依存


# メモリ: 署名検証処理自体は軽微

cosign verify my-registry/my-app:latest