サプライチェーンセキュリティ

ストーリー

田

田中VPoE

SAST、SCA、DASTでアプリケーション自体のセキュリティは守れる。だが、もう一つ重要な攻撃ベクトルがある。サプライチェーンだ

あなた

SolarWindsの事件のようなものですか？

あ

田

田中VPoE

まさにそれだ。あの事件では、ビルドパイプライン自体が侵害され、正規のアップデートにマルウェアが混入した。CI/CDパイプラインは攻撃者にとって格好の標的だ。一つのパイプラインを侵害すれば、組織全体のソフトウェアに影響を与えられる

あなた

パイプライン自体のセキュリティ…考えたことがありませんでした

あ

田

田中VPoE

多くのエンジニアがそうだ。だからこそ、L4では組織の基盤としてサプライチェーンセキュリティを設計に組み込む

ソフトウェアサプライチェーンとは

ソフトウェアが開発されてユーザーに届くまでのすべてのプロセスと依存関係をサプライチェーンと呼びます。

ソフトウェアサプライチェーン:

ソースコード → 依存ライブラリ → ビルドシステム → アーティファクト → レジストリ → デプロイ
     ↑              ↑              ↑              ↑             ↑          ↑
   攻撃点1        攻撃点2        攻撃点3        攻撃点4       攻撃点5    攻撃点6

主要な攻撃パターン

攻撃パターン	事例	対策
依存関係の汚染	event-stream事件、ua-parser-js	SCA、ロックファイルの検証
ビルドシステムの侵害	SolarWinds	ビルドの再現性、来歴証明
レジストリの汚染	タイポスクワッティング	プライベートレジストリ、署名検証
CI設定の改ざん	GitHub Actionsの権限昇格	ワークフロー承認、最小権限

SLSA（Supply chain Levels for Software Artifacts）

SLSAはGoogleが提唱するサプライチェーンセキュリティのフレームワークです。

SLSAレベル

レベル	要件	組織目標
SLSA 1	ビルドプロセスの文書化	全チーム即時
SLSA 2	ホスト型ビルドサービスの使用、来歴証明の生成	全チーム3ヶ月以内
SLSA 3	ビルド環境の隔離、来歴証明の改ざん防止	重要サービス6ヶ月以内
SLSA 4	完全な再現性、Hermetic Build	長期目標

来歴証明（Provenance）

アーティファクトがどのように生成されたかを証明するメタデータです。

{
  "_type": "https://in-toto.io/Statement/v1",
  "subject": [
    {
      "name": "ghcr.io/org/service",
      "digest": { "sha256": "abc123..." }
    }
  ],
  "predicateType": "https://slsa.dev/provenance/v1",
  "predicate": {
    "buildDefinition": {
      "buildType": "https://github.com/actions/runner",
      "externalParameters": {
        "workflow": ".github/workflows/build.yml",
        "ref": "refs/heads/main"
      }
    },
    "runDetails": {
      "builder": {
        "id": "https://github.com/actions/runner"
      }
    }
  }
}

SBOM（Software Bill of Materials）

SBOMはソフトウェアに含まれるすべてのコンポーネントの一覧です。

SBOMの生成と管理

フォーマット	標準化団体	用途
SPDX	Linux Foundation	ライセンスコンプライアンス
CycloneDX	OWASP	セキュリティ脆弱性管理

# GitHub Actions: SBOM生成
- name: Generate SBOM
  uses: anchore/sbom-action@v0
  with:
    image: ${{ env.IMAGE }}
    format: cyclonedx-json
    output-file: sbom.json

- name: Attest SBOM
  uses: actions/attest-sbom@v1
  with:
    subject-name: ${{ env.IMAGE }}
    sbom-path: sbom.json

CI/CDパイプライン自体のセキュリティ

GitHub Actions のセキュリティベストプラクティス

対策	説明
アクションのバージョン固定	`@v3` ではなく `@sha256:abc...` でピン止め
最小権限のトークン	`permissions` で必要最小限を指定
サードパーティアクションの監査	信頼できるアクションのみ使用
シークレットの最小露出	必要なジョブにのみシークレットを渡す
ワークフローの承認	fork からのPRのワークフロー実行に承認を要求

# セキュアなワークフロー設定例
name: Secure Pipeline
on: [push]

permissions:
  contents: read        # 最小権限
  packages: write       # イメージpushに必要
  security-events: write # SARIF アップロードに必要

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      # SHA固定でアクションを参照
      - uses: actions/checkout@ee0669bd1cc54295c223e0bb666b733df41de1c5

まとめ

ポイント	内容
サプライチェーン	ソースからデプロイまでの全プロセスをセキュアに
SLSA	4段階のフレームワークでビルドの信頼性を確保
SBOM	ソフトウェア構成の透明性を確保
パイプラインセキュリティ	CI/CD自体を攻撃対象として防御

チェックリスト

ソフトウェアサプライチェーンの攻撃パターンを理解した
SLSAフレームワークのレベルを理解した
SBOMの役割と生成方法を理解した
CI/CDパイプライン自体のセキュリティ対策を理解した

次のステップへ

次は演習です。ここまで学んだシフトレフトセキュリティ、SAST/DAST/SCA、コンプライアンスゲート、サプライチェーンセキュリティを統合して、セキュリティパイプラインを構築してみましょう。

推定読了時間: 30分