SLSAフレームワークによるソフトウェアサプライチェーン保護

Tech

本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

SLSAフレームワークによるソフトウェアサプライチェーン保護

ソフトウェアサプライチェーンの複雑化は、現代のソフトウェア開発における最も重大なセキュリティ課題の一つです。悪意のある攻撃者は、開発プロセスのあらゆる段階を標的とし、最終的なソフトウェア成果物に不正な変更を加えようとします。このような脅威に対抗するため、SLSA (Supply-chain Levels for Software Artifacts) フレームワークが開発されました。本記事では、セキュリティエンジニアの視点からSLSAの脅威モデル、攻撃シナリオ、具体的な検出・緩和策、そして運用上の注意点について解説します。

脅威モデル

ソフトウェアサプライチェーンにおける主要な脅威アクターとその動機は以下の通りです。

  1. 国家支援型アクター: 機密情報の窃取、重要インフラへの妨害、長期的な諜報活動を目的とし、高度な技術とリソースを投入します。

  2. サイバー犯罪組織: 金銭的利益（ランサムウェア、情報窃取、暗号資産マイニング）を目的とし、広く流通するソフトウェアの脆弱性や人気ライブラリを狙います。

  3. インサイダー脅威: 不満を抱いた従業員や契約者が、報復、金銭、または信念に基づき、意図的にシステムを侵害したり、悪意のあるコードを注入したりします。

  4. ハクティビスト: 政治的、社会的メッセージを伝えるために、ソフトウェアの改ざんやサービス停止を引き起こします。

これらのアクターは、ソースコード、ビルドシステム、パッケージリポジトリ、デプロイメントパイプラインなど、サプライチェーンの様々なポイントを標的にします。

攻撃シナリオ

以下に、ソフトウェアサプライチェーンに対する代表的な攻撃シナリオを挙げます。

  1. ソースコードリポジトリの侵害: 開発者の認証情報を窃取したり、リポジトリの脆弱性を悪用したりして、ソースコードに悪意のある変更をコミットします。

  2. ビルドシステムの改ざん: CI/CDパイプラインをホストするサーバーやコンテナイメージを侵害し、ビルドプロセス自体を操作して、正規のソースコードから悪意のある成果物を生成させます。

  3. 依存関係の悪用:

    • タイポスクワッティング: 有名なライブラリ名と似た名前で悪意のあるパッケージを公開し、開発者の入力ミスを誘います。

    • 依存関係のポイズニング: 脆弱性を持つ、あるいは悪意のあるコードを含むバージョンを正規のパッケージリポジトリにアップロードします。

    • 依存関係のなりすまし/Confused Deputy: プライベートパッケージとパブリックパッケージの名前解決順序を悪用し、悪意のあるパブリックパッケージをインストールさせます。

  4. 成果物の改ざん: ビルド後の成果物（コンテナイメージ、バイナリ、ライブラリ）がデプロイされる前に、途中で改ざんされます。

  5. 配布チャネルの侵害: 成果物を配布するレジストリやCDNが侵害され、悪意のある成果物が正規のものとして提供されます。

これらの攻撃は、単独で行われることもあれば、複数の段階を組み合わせて行われることもあります。

ソフトウェアサプライチェーン攻撃チェーンの可視化

graph TD
    A["攻撃者"] --> B{"初期アクセス"};
    B -- 認証情報窃取/リポジトリ脆弱性悪用 --> C["ソースコードリポジトリ侵害"];
    B -- CI/CDシステム脆弱性悪用/シークレット漏洩 --> D["ビルドシステム侵害"];
    B -- パッケージ名詐称/レジストリ脆弱性悪用 --> E["依存関係の悪用"];

    C -- 悪性コード注入 --> F["不正なソースコードをビルド"];
    D -- ビルドロジック改ざん/ツール改ざん --> G["悪性成果物の生成"];
    E -- 意図しない悪性依存関係の取り込み --> F;

    F --> H["成果物レジストリ/配布チャネルへのプッシュ"];
    G --> H;

    H -- レジストリ侵害/中間者攻撃 --> I["成果物改ざん"];

    I --> J["悪性成果物の流通"];
    J -- 組織内システム/ユーザー --> K["標的環境へのデプロイ/実行"];

    style A fill:#f9f,stroke:#333,stroke-width:2px
    style K fill:#faa,stroke:#333,stroke-width:2px

検出と緩和

SLSAフレームワークは、これらの攻撃シナリオに対する多層防御を提供します。2023年2月15日にSLSA v1.0が発表されて以来、その採用が加速しています [1, 3]。

SLSAの主要な対策

SLSAは、ソフトウェアサプライチェーンの各段階で特定のセキュリティ要件を満たすことで、信頼性と完全性を向上させることを目的としています。SLSAはレベル1から4までの段階があり、レベルが上がるにつれて要件は厳しくなります [1]。

  1. ソースの完全性 (Source Integrity):

    • 目的: ソースコードが開発者によって正しくコミットされ、改ざんされていないことを保証します。

    • SLSA要件: SLSA Level 1から始まり、すべての変更がバージョン管理システムに記録されていること、レビューされていること（SLSA Level 3+）などが求められます。

    • 緩和策:

      • Gitのコミット署名: 開発者がGPGキーでコミットに署名し、その署名を検証することで、コードの出所を保証します。

        # 不適切な例: コミット署名なし

git commit -m "feat: 新機能追加"

# 安全な代替: GPGキーでコミットに署名


# まずGPGキーを生成・設定


# git config --global user.signingkey <GPG_KEY_ID>

git commit -S -m "feat: 新機能追加"

# GitHub等で署名検証が成功したことを確認

      • PRレビューと保護されたブランチ: 複数のレビュアーによる承認なしに主要ブランチへのコミットを禁止します。

  2. ビルドの完全性 (Build Integrity):

    • 目的: ソフトウェアが信頼できる環境で、再現性のある方法でビルドされ、ビルドプロセス中に改ざんされていないことを保証します。

    • SLSA要件: ビルドスクリプトがバージョン管理されていること、ビルドが短命な（エフェメラルな）環境で行われること、ビルドの分離（他のプロセスからの影響を受けない）などが求められます。SLSA Level 3からは、ビルド環境が隔離され、ビルド手順が完全に定義されている「ハーメチックビルド」が推奨されます [1]。

    • 緩和策:

      • Ephemeral Build Environments: クラウド上のCI/CDサービス（例: GitHub Actions、Cloud Build）で、ビルドごとに新しい使い捨てのコンテナやVMインスタンスを利用します。これにより、ビルド環境への永続的なマルウェア注入を防ぎます。

        # 不適切な例: 永続的なビルドエージェントを利用、環境汚染のリスク


# self-hosted runnersなどを使用する際は、厳格な管理と隔離が必要


# 例: GitHub Actionsの自己ホストランナー（適切に管理されない場合）


# runs-on: self-hosted

# 安全な代替: Ephemeralな環境（GitHub Actionsのマネージドランナー）


# ビルドごとに新しいクリーンなVMがプロビジョニングされる

name: Secure Build with Ephemeral Environment
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest # 新しいVMインスタンスで実行
    steps:

      - uses: actions/checkout@v4

      - name: Build project
        run: |
          npm ci
          npm run build

      • ビルドツールの検証: ビルドに使用されるツールやコンパイラが正規のものであることを確認します。

  3. Provenance (来歴情報):

    • 目的: ソフトウェア成果物がどのように、どこで、誰によってビルドされたかという詳細な記録（メタデータ）を提供します。これにより、成果物の完全性を検証できます。

    • SLSA要件: ビルドプロセスがビルド成果物に関する来歴情報（Provenance）を生成すること。SLSA Level 3+では、この来歴情報が改ざん防止され、信頼できるエンティティによって署名されている必要があります [1, 5]。

    • 緩和策:

      • 自動生成されたProvenance: GitHub Actionsは、SLSAに準拠したProvenanceを自動的に生成し、OpenID ConnectとSigstoreを使って署名できます [6]。

        # GitHub ActionsでのSLSA Provenance自動生成の有効化 (一部抜粋)


# GitHub ActionsのReleasesまたはOIDC/Sigstore連携で自動的にProvenanceが生成される

name: Generate SLSA Provenance
on:
  workflow_dispatch:
  release:
    types: [published]
jobs:
  build:
    permissions:
      contents: write # 成果物への書き込み
      id-token: write # OIDCトークンの取得
    uses: slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml@main # SLSAジェネレータを使用
    with:
      go-version: 1.22
      compile-builder: . # ビルド対象

      # provenance-name: my-artifact-provenance

      • Sigstore: 生成された来歴情報と成果物自体を短期的なキーで署名し、その署名を透過的に検証するフレームワークです。これによって、改ざんされていないことをユーザーが確認できます。

  4. 依存関係の保護:

    • 目的: 使用されるサードパーティ製ライブラリやコンポーネントが安全であり、脆弱性がないことを保証します。

    • SLSA要件: 直接的および推移的な依存関係を認識し、そのセキュリティ状態を評価すること（SBOMの活用）。

    • 緩和策:

      • 依存関係のピン留めとハッシュ検証: package.json や requirements.txt でバージョンを固定し、ハッシュ値を用いて改ざんを検知します。

        # 不適切な例: バージョン指定が曖昧で、不意のアップデートや改ざんのリスク


# pip install some-library


# npm install some-package

# 安全な代替: バージョンとハッシュ値を厳密に指定


# requirements.txt


# some-library==1.2.3 --hash=sha256:abcdef...

# package.json (npm lockfileが生成するintegrityハッシュ)


# "dependencies": {


#   "some-package": "1.0.0"


# }


# package-lock.json / yarn.lock にintegrityハッシュが記録される

# 例: npm install --no-fund --no-audit


# 例: pip install -r requirements.txt --require-hashes

      • SBOM (Software Bill of Materials) の生成と分析: ソフトウェアに含まれるすべてのコンポーネントとそのバージョン、ライセンス情報をリストアップし、脆弱性スキャナーで継続的に監視します。

      • 脆弱性スキャン: SAST (Static Application Security Testing) と DAST (Dynamic Application Security Testing) をCI/CDパイプラインに統合し、コードや依存関係の脆弱性を早期に特定します。

運用対策

SLSAフレームワークの実装は、単なる技術的な導入にとどまらず、組織全体の運用プロセスの変更を伴います。

鍵/秘匿情報の取り扱い

ソフトウェアサプライチェーン保護の要は、鍵や秘匿情報の適切な管理です。

  • 鍵管理システム (KMS) の活用: AWS KMS、Azure Key Vault、Google Cloud Key Management などの専用サービスを利用し、鍵の生成、保存、アクセス制御、監査を一元的に行います。

  • 最小権限の原則: ビルドシステムやCI/CDパイプラインが必要とする権限は最小限に限定します。例えば、成果物に署名するための鍵へのアクセスは、署名プロセスが実行される特定のビルドジョブにのみ許可します。

  • 鍵のローテーション: 署名鍵やAPIキーは定期的に（例: 3ヶ月に一度）ローテーションします。Sigstoreは短期的なエフェメラルキーを使用するため、ローテーションがより容易になります。

  • シークレット管理: APIキー、データベース接続文字列などのシークレットは、GitHub Secrets、Vault by HashiCorp、Kubernetes Secretsなどの専用ツールで管理し、コードリポジトリに直接コミットすることを厳禁します。

    # 不適切な例: シークレットをハードコードまたは環境変数に平文で保存


# $API_KEY = "sk_xxxxxxxxxxxxxxxx"


# New-Item -Path "C:\secrets\config.txt" -Value "API_KEY=sk_xxxxxxxxxxxxxxxx"

# 安全な代替: シークレット管理システムから取得


# PowerShell (例: Azure Key Vaultから取得)


# Connect-AzAccount


# $secret = Get-AzKeyVaultSecret -VaultName "MyKeyVault" -Name "MyApplicationApiKey"


# $API_KEY = $secret.SecretValue | ConvertTo-SecureString -AsPlainText -Force


# Write-Host "API Key loaded securely."

# Python (例: 環境変数から読み込み、CI/CDで環境変数にシークレットマネージャーの値を渡す)


# import os


# api_key = os.environ.get("MY_APP_API_KEY")


# if not api_key:


#    raise ValueError("API Key not found in environment variables.")


# print("API Key loaded securely.")

  • 監査: 鍵やシークレットへのアクセスログを常時監視し、不正アクセスや異常な利用パターンを検出します。

監査と監視

  • ログの一元管理と相関分析: ビルドログ、デプロイログ、VCSログ、監査ログなどを一元的に集約し、SIEM (Security Information and Event Management) システムと連携して相関分析を行います。

  • 異常検知: ビルド時間の急激な変化、予期しないビルドの失敗、普段と異なるIPアドレスからのアクセス、成果物ハッシュの不一致などを異常として検知する仕組みを構築します。

  • 変更管理: ソフトウェアサプライチェーンの構成（CI/CDパイプライン定義、ビルドスクリプト、依存関係の更新など）に対する変更は、厳格なレビューと承認プロセスを経る必要があります。

テストと検証

  • 継続的な脆弱性スキャン: SAST、DAST、SCA (Software Composition Analysis) をCI/CDパイプラインに組み込み、コードと依存関係の脆弱性を継続的にテストします。

  • SBOM (Software Bill of Materials) の活用: ビルドされた成果物に含まれる全てのコンポーネントのSBOMを生成し、既知の脆弱性データベース（NVD, OSVなど）と照合して、潜在的なリスクを評価します。

現場の落とし穴

SLSAフレームワークを導入する際に直面しがちな課題と注意点を以下に示します。

  • 過剰な複雑性: SLSAレベルを上げるほど要件が厳しくなり、既存のCI/CDパイプラインに大きな変更が必要になる場合があります。目標とするレベル設定は、組織のリスク許容度とリソースに合わせて段階的に行うべきです。

  • 誤検知と運用負荷: 厳格なポリシーや署名検証を導入すると、正当な変更や依存関係の更新でも誤検知が発生し、開発や運用の手戻りや遅延を招くことがあります。適切な閾値設定や自動化によるフィルタリングが必要です。

  • 検出遅延: 異常検知システムが構築されていても、アラートのノイズが多く、重要な脅威が見過ごされる可能性があります。効果的なアラート設定と迅速な対応体制が不可欠です。

  • パフォーマンスのトレードオフ: ハーメチックビルドやProvenanceの生成、署名検証などは、ビルド時間やデプロイ時間にオーバーヘッドを追加します。セキュリティと開発速度のバランスを見極める必要があります。

  • 既存システムとの統合課題: 特にレガシーシステムやオンプレミスのビルド環境では、SLSAの要件を満たすためのツール導入や環境変更が困難な場合があります。段階的な移行計画と、クラウドネイティブなツールへの移行を検討することが有効です。

  • 教育と意識: 開発者や運用チームがSLSAの重要性とその要件を理解していないと、形骸化したり、誤った運用につながったりします。定期的なセキュリティトレーニングとガイドラインの周知が重要です。

まとめ

SLSAフレームワークは、ソフトウェアサプライチェーンの信頼性と完全性を確立するための実践的なガイドラインを提供します。脅威モデルと攻撃シナリオを理解し、ソースの完全性、ビルドの完全性、Provenance、そして依存関係の保護を組織のCI/CDパイプラインに組み込むことで、重大なセキュリティリスクを軽減できます。2024年7月26日現在、多くのツールやサービスがSLSAへの対応を進めており、今後もその重要性は増すばかりです。鍵管理の徹底、継続的な監査、そして現場の落とし穴を認識した上で、段階的にSLSAの導入を進めることが、現代のソフトウェア開発において不可欠なセキュリティ対策となります。

参照情報: [1] SLSA.dev. “SLSA v1.0 Specification.” 最終更新日: 2023年2月15日. https://slsa.dev/spec/v1.0/ [2] SLSA.dev. “Why SLSA?” 最終更新日: 2023年9月26日. https://slsa.dev/why [3] OpenSSF Blog. “SLSA v1.0 Released!” 2023年2月15日. https://openssf.org/blog/2023/02/15/slsa-v1-0-released/ [4] OpenSSF. “Software Supply Chain Security Guide.” 最終更新日: 2024年4月11日. https://openssf.org/resources/guides/supply-chain-security-guide/ [5] Google Cloud Blog. “Software supply chain security with SLSA and Cloud Build.” 2023年5月22日. https://cloud.google.com/blog/products/identity-security/software-supply-chain-security-with-slsa-and-cloud-build [6] GitHub Blog. “Automatically secure your software supply chain with SLSA on GitHub.” 2024年3月5日. https://github.blog/2024-03-05-automatically-secure-your-software-supply-chain-with-slsa-on-github/

ライセンス：本記事のテキスト/コードは特記なき限り CC BY 4.0 です。引用の際は出典URL（本ページ）を明記してください。
利用ポリシー もご参照ください。

コメント

タイトルとURLをコピーしました