CI/CD セキュリティ ベストプラクティス：チェックリスト2026
本ブログは「Harness」社で2026年9月25日に公開された「 CI/CD Security Best Practices: A 2026 Checklist 」の日本語翻訳です。
TL;DR
- ビルドシステムは、デプロイ先となるすべての環境の認証情報を保持しているため、より価値の高い標的となります。
- リスク対策の大部分を担うのは、マネージドシークレット、スコープを限定したアクセス、依存関係のスキャン、署名済みアーティファクト、監査ログといった統制です。
- コーディングワークフローを自動化している組織は51%である一方、CI およびビルドパイプラインを自動化している組織は43%にとどまります。
- 導入は「可視化 → ポリシー → 強制適用」の3段階で進め、マージがブロックされる前にチームが失敗を確認できるようにします。
CI/CDセキュリティのベストプラクティスとは？
CI/CD セキュリティのベストプラクティスとは、デリバリーパイプラインそのものを保護する統制のことです。エンジニアリングリーダーや実務者の86%が、こうしたチェックにはさらなる自動化が必要だと回答しています。
- シークレットはマネージドストアに保管し、実行時に注入する。
- アクセスは RBAC によって環境ごとにスコープを限定する。
- 依存関係はピン留めして SBOM で棚卸しし、アーティファクトには署名する。
基本データ：CI/CDセキュリティのベストプラクティス
| 項目 | 内容 |
|---|---|
| 対象範囲 | パイプラインそのものを保護する統制：シークレット、アクセス、依存関係、アーティファクト、ランナー、監査証跡 |
| 別名 | パイプラインセキュリティ、セキュアな CI/CD パイプライン、DevOps セキュリティのベストプラクティス |
| 含まれないもの | アプリケーションセキュリティテスト単体。AppSec は開発者が書いたコードをスキャンするものであり、パイプラインセキュリティはそのコードをビルド・デプロイするシステムを保護するものです |
| 核心的な盲点 | ビルドシステムは、デプロイ先の本番サービスよりも広範な認証情報を日常的に保持している |
| 担当 | 共同責任。パイプラインの統制はプラットフォームチームが、ポリシーは AppSec が担い、両者とも同じ監査に対して説明責任を負う |
| AIによるプレッシャー | 48%のチームが、AI コーディングアシスタントによってソフトウェアの脆弱性が増えていると懸念している（Harness『State of AI in Software Engineering 2025』） |
| 依存関係のベースライン | スキャンされたコードベースの87%に、少なくとも1つの脆弱性が含まれている（Black Duck『Open Source Security and Risk Analysis 2026』） |
| パラダイムシフト | オープン実行パイプライン（Open Execution Pipelines：サードパーティのプラグインが完全な権限で実行される）から、ガバナンス実行パイプライン（Governed Execution Pipelines：ポリシーゲート、イミュータブルな参照、分離によって統制される）への移行 |
ビルドシステムは、それがデプロイするサービスよりも多くのアクセス権を持っています。ステージング、本番、アーティファクトレジストリ、そしてそれらすべての基盤となるクラウドアカウントにアクセスできます。一方、本番環境からビルドシステムへ逆方向にアクセスすることはできません。
この非対称性こそが、CI/CD セキュリティのベストプラクティスが、パイプラインを流れるコードではなく、パイプラインそのものから始まる理由です。パイプラインが1つ侵害されれば、署名鍵、デプロイ用の認証情報、そしてあらゆる環境への信頼された経路が一度に奪われます。以下の統制は、チームが実際に導入していく順序、つまり「今週中に対応できること」から「四半期で取り組むこと」の順に並べています。
なぜCI/CDセキュリティは主要な攻撃対象領域なのか？
パイプラインには信頼が集中しているからです。パイプラインはクラウドの認証情報、レジストリのトークン、署名鍵を保持しており、そこから生成されるものは、定義上、下流で信頼されます。稼働中のサービスを侵害すれば、手に入るのはそのサービスだけです。しかしパイプラインを侵害すれば、正規の署名付きで、そのパイプラインのデプロイ先すべてが手に入ります。
OWASP Top 10 CI/CD Security Risksは、その結果として生じるリスクを列挙しています。過剰な権限を持つアイデンティティ、ポイズンド・パイプライン・エグゼキューション（Poisoned Pipeline Execution）、そして管理されていない依存関係です。いずれも新しいエクスプロイトを必要とせず、誰も権限を絞り込んでいないパイプラインさえあれば成立します。
AI は、この攻撃対象領域の形を変えることなく、その範囲を広げました。より多くの場所から、レビューが追いつかないほどの速さで、より多くのコードが流れ込んでいます。
AI コーディングツールを最も頻繁に利用しているチームのうち、50%がAI導入以降に脆弱性やセキュリティインシデントが増加したと報告しています（Harness『State of DevOps Modernization 2026』）。その大量のコードが安全にデプロイされるのか、それとも単にデプロイされるだけなのかを左右するのが、パイプラインセキュリティです。
組織が「オープン実行パイプライン」に依存している場合、この集中した信頼は大きな負債となります。オープンモデルでは、パイプライン内で何が実行されるかは、外部の参照、変更可能なバージョンタグ、検証されていないサードパーティのコードによって決まります。2026年3月に発生した TeamPCP による Trivy への深刻な攻撃に見られるように、オープン実行モデルでは、攻撃者が CI/CD のサプライチェーンを侵害し、認証情報を窃取する悪意あるコードを被害者のパイプラインに直接送り込むことが可能になります。
CI/CDセキュリティのベストプラクティスのチェックリストには何を含めるべきか？
リスクの大部分は、シークレット、アクセス、依存関係、アーティファクトの完全性、ランナー、監査証跡の6つの統制でカバーできます。まずはすでに保有しているスキャナーから始めましょう。多くのチームは、実際に運用している以上のツールに費用を払っているからです。実際に活用されるチェックリストと、Wikiに置かれたまま放置されるチェックリストを分けるのは、実施の順序です。半日で終わる項目もあれば、四半期かかる項目もあります。それを同列に扱おうとすると、バックログは停滞してしまいます。
今週中に実施できる概要は？
- シークレットをパイプライン設定から排除する：すべての認証情報をマネージドシークレットストアに移し、実行時に注入し、一度でもコミットされたものはすべてローテーションします。現在のファイルに残っているかどうかにかかわらず、それはGitの履歴に残っています。
- サードパーティの actions の使用を最小限にする： 可能な限り組み込みのステップに切り替え、侵害されたプラグインやアクションを介したサプライチェーン攻撃にさらされるリスクを減らします。
- サードパーティの actions をコミットSHAでピン留めする： タグはリポジトリの所有者であれば誰でも移動できます。2026年、TeamPCP の攻撃者が Trivy actions の77個のバージョンタグのうち76個に悪意あるコードを強制プッシュできたのも、この構造的な脆弱性によるものでした。SHAは改変できません。この1つの変更で、ビルドへの侵入経路として最も一般的なものを塞ぐことができます。
- パイプライン定義を本番コードと同様に保護する： 誰でも承認なしに編集できるパイプラインは、レビューを経ないデプロイ経路にほかなりません。
- 1つのランナーを1つの環境に限定する： 1つのビルドエージェントにステージングと本番の両方の認証情報を持たせるのはやめましょう。到達範囲を限定した権限委譲を使うことで、攻撃が拡大するリスクを抑えられます。
四半期の計画に組み込むべき構造的な対策は？
- すべてのビルドで SBOM を生成し、アテステーションを付与する： 次にレジストリの侵害が起きたとき、確実に答えを出せるのはリリース時点のインベントリだけです。Harnessは、パイプラインのステップとしてアーティファクトのSBOMを生成します。
- コミットとアーティファクトに署名し、デプロイ前に検証する： 来歴（Provenance）は、そのバイナリが他のどこかではなく自社のビルドから生成されたことを証明します。Sigstore により、署名はほぼコストをかけずに行えるようになりました。
- 監査証跡を1か所にまとめる： SOC 2の監査ではまさにこれが求められます。数か月後に6つのシステムから手作業でかき集めるのは、大きなコストがかかります。
パイプラインセキュリティで最も多く見られる設定ミスは？
そのほとんどは、高度な攻撃から始まるわけではありません。誰も変更しなかったデフォルト設定から始まるのです。
パイプライン設定へのハードコードされた認証情報： 金曜日のビルドを通すためにトークンが YAML ファイルに貼り付けられ、ビルドは成功し、トークンはそのまま残ります。こうしてトークンは、すべてのクローンとフォークに存在することになります。対処法はローテーションであり、すべてのコミットをスキャンすることで次の発生を防げます。
ビルドエージェントに付与された過度に広い IAM ロール： ビルド用のロールは、調整中に権限を絞るとパイプラインが壊れるため、広めにプロビジョニングされがちです。その結果、アカウント内のすべてのバケットを読み取れるエージェントが残ります。権限は、セットアップ時に誰かが要求した内容ではなく、パイプラインが先月実際に使用した内容に基づいて絞り込みましょう。
ピン留めされていない依存関係と、検証されていないサードパーティの actions： 浮動タグで actions を取得するワークフローは、そのタグがその日に指しているものを何であれ実行します。これは、最近のいくつかのレジストリ侵害の背後にある仕組みです。サードパーティのコードは、誰かに攻撃される前からリスクを抱えています。スキャンされたコードベースの87%には少なくとも1つの脆弱性が含まれています（Black Duck『Open Source Security and Risk Analysis 2026』）。OpenSSF Scorecardは、依存関係がピン留めされているかを自動的にチェックします。オープン実行パイプラインで浮動タグが乗っ取られると、攻撃者は専用のペイロードを展開し、プロセスメモリから復号済みのシークレットを抜き取り、ファイルシステムから .kube/config や .env ファイルを探し出し、クラウドのメタデータ（IMDS）を収集して、単純なビルドジョブから IAM ロールへの完全なアクセスへと足場を広げます。
いずれも、それ単体では理にかなった便宜的な措置でしたが、誰も見直さなくなった時点でリスクへと変わりました。パイプラインセキュリティは、ツールの問題である前に、レビューの問題なのです。
チームのスピードを落とさずにセキュアなCI/CDパイプラインを展開するには？
可視化、ポリシー、強制適用の3段階で進めます。
まずは可視化： すべてのパイプラインで、すべてのスキャナーをレポートのみのモードで実行します。何もブロックされず、2週間もあれば、推測ではなく実際の検出率を把握できます。ノイズが見つかるのもこの段階です。誤検知ばかりの統制は、3回目のスプリントまでに無効化されてしまうからです。
次にポリシー： ルールをコードとして記述し、稼働中のパイプラインに対して警告モードで実行します。チームは、何が失敗していたはずなのか、そしてその理由を確認でき、修正する時間も確保できます。
強制適用は最後に、かつ範囲を絞って： ブロック対象はクリティカルな重大度のみとし、文書化された例外プロセスと承認者を明確にしておきます。この段階にいきなり進んでしまうことこそが、「セキュリティはリリースを妨げるもの」という評判を生む原因です。
コーディングワークフローを自動化している組織は51%ですが、CIおよびビルドパイプラインを自動化している組織は43%にとどまります（Harness『State of AI in Software Engineering 2025』）。セキュアな CI/CD パイプラインは、その途中に依然として残る手作業のステップも考慮に入れる必要があります。
HarnessのCI/CDセキュリティへのアプローチ
Harnessは、ガバナンスの効いたパイプラインを重視し、サードパーティのプロバイダーに頼るのではなく、ステップ（actions）を標準機能として提供することから始めています。その目的は、デフォルトで侵害の可能性を低減し、さらに万が一侵害が発生した場合の影響範囲を小さくすることです。パイプライン基盤そのものに対するこうした多層防御が不可欠です。
次にコードの保護に目を向けると、多くのチームに不足しているのはスキャナーではないという点を認識することが重要です。不足しているのは、ビルド、テスト、セキュリティ、デプロイ、運用というデリバリーライフサイクル全体にわたって、各スキャナーの検出結果を突き合わせる手段です。4つのツールが1つの脆弱性を4通りに報告し、重大度の評価は食い違い、ポリシーはリリース中に誰も開かないドキュメントの中に眠っています。
Security Testing Orchestration は、商用およびオープンソースのスキャナーをパイプラインのステップとして実行し、その結果を正規化・重複排除して、1つの問題が1つの問題として読めるようにします。サプライチェーンセキュリティは、SBOM の生成、アテステーション、SLSA の来歴を扱います。ポリシーは OPA を通じてコードとして、チームごとではなくすべてのパイプラインにわたって適用され、RBAC が誰が何を変更できるかを制限し、プラットフォームの監査証跡が次の監査に備えてそれを記録します。
トリアージは、4つのダッシュボードを突き合わせる作業ではなくなります。チームは優先順位付けされた1つのリストと、すべてのパイプラインに同じように適用されるポリシー、そして承認者が明記された例外の記録を手にします。作業の中心は、どのアラートが本物かを議論することから、それを修正することへと移ります。
規制の厳しい業界のチームは、どのようにDevOpsセキュリティのベストプラクティスを大規模に適用しているのか
Deluxeは、チームによるセキュリティスキャンの回避をどのように防いだのか？
Deluxe 社は、どのチームも回避できないよう、スキャンを一元管理されたポリシーの下に置きました。同社のパイプラインは脆弱性を早期に検出し、クリティカルな問題が対処されるまでビルドをブロックします。また、再利用可能なテンプレートにより、コンプライアンスに準拠したパイプラインを30分以内に立ち上げられます。
「チェックインのたびにパイプラインを起動し、セキュリティスキャンが重大度の高い問題やクリティカルな問題をすべて検出するようにしています。一元管理されたポリシーにより、どのチームもそれを回避することはできません。」
Vikas Mehta 氏（Deluxe、Enterprise Architect Principal）
出典：Deluxe 社事例
Citiは、どのようにリリース時間を数日から7分に短縮したのか？
規制の厳しい金融業界では、標準的な統制を一貫して適用することが最大の制約となります。Citi 銀行は2万人のエンジニアのデリバリーを変革し、リリース時間を数日から7分へと短縮しました。テンプレートとポリシーを活用することで、標準からの逸脱を防ぎつつ、パイプライン設計の柔軟性を維持しています。
「Harness CD のテンプレートシステムと OPA フレームワークにより、アプリケーションチームは、自分たちが支える事業の要件に合わせて CD パイプラインを柔軟に設計できます。同時に、必須および推奨されるすべてのプラクティスに従っていることも確実にできます。エンジニアが実現できることを制限することなく、ポリシーを適用し、標準化を推進できるのです。」
Michael Freeman 氏（Citi、Lead Software Engineer for the Platform）
出典：Citi 銀行事例
パイプラインが到達できる範囲と、到達すべき範囲のギャップを埋める
パイプラインは、デプロイするどのサービスよりも多くのものに常に触れることになります。それがパイプラインの役割だからです。変えられるのは、その到達範囲のうち、どれだけが意図的で、スコープが限定され、監査人が読める形で文書化されているかという点です。
今週は認証情報と依存関係のピン留めから始め、SBOM、署名、ポリシーは四半期の計画に組み込みましょう。チェックリストはチームが定期的に見直す場所に置いておいてください。新しいデフォルト設定が見直されないまま放置された瞬間から、CI/CD セキュリティのベストプラクティスは形骸化していくからです。これらの統制を1か所で運用するには、ぜひデモをご予約ください。
