Claudeの新機能「Agent Skills」が従来のAIチャットと決定的に違う点
swiftwand swiftwand.ai
[DevSecOps] ゼロトラスト・パイプライン: OIDCとSigstoreで守るサプライチェーンセキュリティ
swiftwand-api
「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）を提示し、一時的な権限だけを借ります。
created by Rinker
¥2,750 (2026/02/19 00:18:48時点 楽天市場調べ-詳細)
技術的詳細: 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 ブランチからしかデプロイできない」
という強力なガードレールを設置できます。
created by Rinker
¥2,970 (2026/02/19 00:18:48時点 楽天市場調べ-詳細)
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 によってビルドされた」という署名が付与されます。
created by Rinker
¥1,469 (2026/02/19 00:18:49時点 楽天市場調べ-詳細)
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を目指す)
SLSAフレームワークとの連携
SLSA（Supply-chain Levels for Software Artifacts）は、ソフトウェアサプライチェーンの完全性を段階的に強化するフレームワークです。2025年にはSLSA v1.1（ビルドトラックの明確化）、続いてv1.2（11月）でソーストラックが追加されました。
SLSAレベル1ではビルドの来歴（Provenance）を生成するだけで達成できますが、署名なしではレベル1止まりです。Sigstoreによるキーレス署名を組み合わせることで、レベル2以上の完全性保証が可能になります。
具体的には、GitHub Actionsのアーティファクト証明（Attestation）機能でSLSA来歴を自動生成し、Cosignで署名を付与します。これにより「誰が・どのリポジトリから・どのワークフローでビルドしたか」が暗号学的に検証可能になります。
サプライチェーン防御の実践ベストプラクティス
アクションのSHAピン留め
サードパーティのGitHub Actionsは、フローティングタグ（v1等）ではなく、特定のコミットSHAに固定してください。タグは上書き可能なため、攻撃者がタグを差し替えるサプライチェーン攻撃のリスクがあります。Dependabotを有効にすれば、ピン留めしたSHAの更新も自動化できます。
最小権限の徹底
ワークフローのpermissionsはデフォルトで最小権限に設定し、必要なスコープだけを明示的に付与します。id-token: writeはOIDC認証に必須ですが、contents: writeなどは本当に必要な場合のみ追加してください。
環境保護ルールの活用
GitHub Environmentsのデプロイ保護ルールを設定し、本番環境へのデプロイにはレビュー承認を必須化します。OIDCの信頼ポリシーでも環境名をsub条件に含めることで、特定の環境からのみアクセスを許可できます。
DevSecOpsスキルで収益化する4つの方法
1. セキュリティコンサルティング：企業のCI/CDパイプラインをゼロトラスト化する支援を行います。OIDC移行だけでも1案件30〜100万円が相場です。特にスタートアップはセキュリティ人材が不足しており、需要は増加傾向です。
2. 技術記事・登壇：DevSecOpsの知見をブログや技術カンファレンスで発信します。Zennやnoteでの有料記事、企業スポンサード記事で月5〜20万円の副収入が見込めます。
3. 監査・認証取得支援：SOC2やISO 27001の取得を目指す企業に対し、SLSAフレームワーク準拠のパイプライン構築を支援します。認証取得プロジェクトは長期契約になりやすく安定収入源です。
4. OSS貢献からの転職・副業：SigstoreやKyvernoなどのOSSに貢献することで、セキュリティ分野での知名度を上げられます。GitHubプロフィールが実質的なポートフォリオとなり、高単価案件の獲得につながります。
よくある質啎（FAQ）
Q1. OIDCとは何ですか？
OpenID Connectの略で、認証プロトコルの一つです。GitHub ActionsなどのCI/CDサービスが、AWSなどのクラウドプロバイダーに対して「自分は正当なワークフローである」と短期トークンで証明する仕組みです。固定のAPIキーが不要になります。
Q2. Sigstoreとは何ですか？
ソフトウェアの署名と検証を行うオープンソースプロジェクトです。Cosignというツールでコンテナイメージに電子署名を付与し、Rekor透明性ログに記録します。キーレス署名により、秘密鍵の管理が不要になります。
Q3. ゼロトラストの導入にはどれくらいのコストがかかりますか？
GitHub ActionsのOIDCとSigstoreは無料で利用できます。AWS側のIAMロール設定も追加費用はありません。最大のコストは学習時間と既存パイプラインの移行工数で、小規模なプロジェクトなら1〜2日で完了できます。
Q4. 既存のAPIキーをすぐに削除しても大丈夫ですか？
いいえ。まずOIDCによる認証を並行して設定・テストし、問題なく動作することを確認してから旧キーを削除してください。段階的な移行が安全です。
Q5. GitLab CIでもキーレス署名は使えますか？
はい。GitLab CI/CDもOIDCトークンの発行に対応しており、Cosignと組み合わせたキーレス署名が可能です。設定方法はGitHubとは異なりますが、原理は同じです。
Q6. SLSAレベルはどこまで目指すべきですか？
まずはレベル1（来歴の生成）から始め、Sigstore署名でレベル2を達成することを目標にしてください。レベル3以上はビルド環境の隔離が必要で、大規模組織向けです。
Q7. Kubernetesを使っていない場合でもSigstoreは必要ですか？
コンテナイメージを利用するなら、Kubernetes以外でも署名検証は有効です。ECSやCloud Runなどでも、デプロイ前にcosign verifyを実行するステップを追加できます。
Q8. 今後のトレンドはどうなりますか？
2026年以降、SLSAフレームワークの採用が加速し、主要なパッケージマネージャー（npm、PyPI、Maven Central等）がSigstore署名を標準サポートする流れが進んでいます。サプライチェーンセキュリティは「あると良い」から「必須」へと変化しています。
まとめ：ゼロトラストパイプラインへの移行ロードマップ
ゼロトラストとは「誰も信用しない」ことではなく、「暗号論的に証明されたものだけを信用する」ことです。OIDCとSigstoreの導入は、開発者体験を損なうことなく、セキュリティレベルを劇的に向上させます。
導入ステップとしては、まず1つのワークフローでOIDC認証に切り替え、次にCosignでコンテナ署名を追加、その後Kyvernoなどで検証ポリシーを適用する順序がおすすめです。最初の一歩として、リポジトリのSecrets設定からAWSアクセスキーを削除することから始めましょう。それが真のDevSecOpsへの第一歩です。
あわせて読みたい
- 3Dプリンターの未来を変える2つの新技術【2026年版】Image-to-3D AIとベルトプリンター
- 3万円の炉で「鉄」を錬成する：デスクトップメタルプリントの民主化
- Bambu Lab P2Sとは：次世代3Dプリンターの位置づけ
ABOUT ME
AIを使って、毎日の生活をもっと快適にするアイデアや将来像を発信しています。
初心者にもわかりやすく、すぐに取り入れられる実践的な情報をお届けします。 Sharing ideas and visions for a better daily life with AI.
Practical tips that anyone can start using right away.
