[DevSecOps] ゼロトラスト・パイプライン: OIDCとSigstoreで守るサプライチェーンセキュリティ

「CI/CD パイプラインは、攻撃者にとっての『王国の鍵』である」。
現代のセキュリティ対策としてゼロトラストという考え方が注目されています。
2026年、サプライチェーン攻撃はもはや対岸の火事ではありません。
SolarWinds や Codecov の教訓から、
私たちは 「何も信頼しない」 パイプラインへの移行を余儀なくされました。
この記事では、固定の API キーを撤廃し、OIDC と Sigstore を用いて
「誰が、何を、いつビルドしたか」
を数学的に証明するセキュアなパイプライン構築法を解説します。
The “Keyless” Revolution

まず、今すぐリポジトリの Secrets 設定を開いてください。
もしそこに AWS_ACCESS_KEY_ID や GPG_PRIVATE_KEY が眠っているなら、それはセキュリティリスクです。漏洩した瞬間、あなたのインフラは乗っ取られます。
2026年の常識は 「Keyless」 です。
固定の鍵を持つ代わりに、クラウドプロバイダーや署名局に対して、
「私は今実行されている GitHub Actions の特定のワークフローです」
と身分証明(OIDC Token)を提示し、一時的な権限だけを借ります。
技術的詳細: GitHub Actions OIDC + AWS
AWS へのデプロイを例に、OIDC の設定がいかにシンプルかつ強力かを見てみましょう。
IAM ユーザー(固定キー)は不要です。必要なのは「IAM ロール」だけです。
# .github/workflows/deploy.yml
name: Secure Deploy
on: [push]
permissions:
id-token: write # これが重要。OIDCトークン要求に必須
contents: read
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- name: Git Checkout
uses: actions/checkout@v4
- name: Configure AWS Credentials (OIDC)
uses: aws-actions/configure-aws-credentials@v4
with:
role-to-assume: arn:aws:iam::123456789012:role/GitHubActionDeployRole
aws-region: ap-northeast-1
# 固定のKey/Secretは一切記述しない!
- name: Deploy to S3
run: aws s3 sync ./build s3://my-secure-bucketAWS 側の「信頼ポリシー」に token.actions.githubusercontent.com:sub を検証条件に入れることで、
「特定のリポジトリの、main ブランチからしかデプロイできない」
という強力なガードレールを設置できます。
Signing Containers with Sigstore (Cosign)

次に、ビルドした成果物(コンテナイメージ)の改ざん防止です。
ここでも鍵管理は不要です。Sigstore (Cosign) は OIDC トークンを使って
「使い捨ての証明書」
を発行し、透明性ログ(Rekor)に署名記録を残します。
- name: Install Cosign
uses: sigstore/cosign-installer@v3.5.0
- name: Build and Push Docker Image
id: build-and-push
uses: docker/build-push-action@v5
with:
push: true
tags: ghcr.io/my-org/my-app:latest
- name: Sign the images with GitHub OIDC Token
run: |
cosign sign --yes ghcr.io/my-org/my-app@${{ steps.build-and-push.outputs.digest }}
# --yes は「キーレス署名(OIDCモード)」を有効にするフラグこれにより、イメージには
「このイメージは GitHub Actions の Run ID xxx によってビルドされた」という署名が付与されます。
Trust Verification Flow
デプロイ時(Kubernetes Admission Controller など)にこの署名を検証することで、承認されたパイプラインを通っていない「野良イメージ」のデプロイを完全にブロックできます。
sequenceDiagram
participant Dev as Developer
participant GH as GitHub Actions
participant OIDC as OIDC Provider
participant Fulcio as Sigstore CA
participant Registry as Container Registry
participant K8s as Kubernetes (Policy Agent)
Dev->>GH: Git Push
GH->>OIDC: Request Token
OIDC-->>GH: ID Token (JWT)
GH->>GH: Build Image
GH->>Fulcio: Token + Public Key
Fulcio-->>GH: Ephemeral Certificate
GH->>Registry: Push Image + Signature
GH->>K8s: Deploy Request
K8s->>Registry: Pull Signature
K8s->>K8s: Verify Signature & OIDC Issuer
alt Verified
K8s-->>GH: Deploy Success
else Failed
K8s-->>GH: Blocked (Untrusted Artifact)
end推奨スタック (2026 Edition)

- Identity: GitHub Actions OIDC (または GitLab ID Token)
- Signing: Sigstore (Cosign) (コンテナ署名のデファクト)
- Policy: Kyverno または OPA Gatekeeper (K8s上での署名検証ポリシー)
- Secrets: なし (Keylessを目指す)
まとめ
Zero Trust とは「誰も信用しない」ことではなく、「暗号論的に証明されたものだけを信用する」 ことです。
OIDC と Sigstore の導入は、開発者の体験(DX)を損なうことなく、セキュリティレベルを劇的に向上させます。
まずは、AWS access_key_id を削除することから始めましょう。それが、真の DevSecOps への第一歩です。






