CI/CD資格情報の流出とは？
CI/CD資格情報の流出とは、ソフトウェア開発・配信の自動化システムである「CI/CD（継続的インテグレーション/継続的デリバリー）パイプライン」で使用される認証情報（APIキー、アクセストークン、パスワード、暗号鍵など）が、誤って外部に公開されたり、攻撃者に盗まれたりするサイバー攻撃の一種です。
CI/CDパイプラインとは、プログラマーがソースコードを書いてから、そのコードが自動的にテスト・ビルドされ、最終的に本番環境へ配信されるまでの一連の流れを自動化する仕組みです。このパイプラインは、GitHubやGitLabなどのコードリポジトリ、Jenkins・CircleCI・GitHub Actionsなどのビルドツール、AWS・Azure・Google Cloudなどのクラウド環境など、多数のシステムと連携します。これらのシステム間で認証を行うため、APIキーやアクセストークンといった資格情報が大量に使用されます。
問題は、これらの資格情報が非常に強力な権限を持っていることです。CI/CDパイプラインは本番環境へのデプロイ権限を持つため、攻撃者が資格情報を入手すると、本番システムへの不正アクセス、悪意のあるコードの注入、機密データの窃取など、甚大な被害を引き起こす可能性があります。特に、資格情報が誤ってGitHubなどの公開リポジトリにコミットされたり、ビルドログに出力されたり、コンテナイメージに埋め込まれたりすることで漏洩するケースが後を絶ちません。
近年では、サプライチェーン攻撃の一環として、CI/CDパイプライン自体が標的にされるケースが増加しています。攻撃者は、広く使用されているGitHub Actionやライブラリを侵害し、そこから数千から数万のプロジェクトの資格情報を一度に窃取する手法を確立しています。
CI/CD資格情報の流出を簡単に言うと？
CI/CD資格情報の流出を日常生活で例えるなら、「自動配送システムのマスターキーを落としてしまう」ようなものです。
例えば、あなたが大規模なオンラインショッピングサイトを運営していて、倉庫から顧客の家まで商品を自動で配送する最新のシステムを導入したとします。このシステムは、在庫管理、配送ルート計算、ドアの解錠、商品の配置まで、すべて自動で行います。そのため、システムには「倉庫のマスターキー」「配送車両の鍵」「顧客の家のドア解錠コード」など、あらゆる場所にアクセスできる強力な権限が与えられています。
ところが、ある日、システムの設定ファイルを公開のウェブサイトに誤ってアップロードしてしまい、その中に「倉庫のマスターキー」のコピーが含まれていたらどうなるでしょうか。悪意のある人物がそのキーを見つけると、倉庫に侵入して商品を盗んだり、偽物の商品を混入させたり、さらには配送システムを乗っ取って顧客の家に不正な荷物を送りつけたりできてしまいます。
CI/CD資格情報の流出も、これと同じです。ソフトウェア開発の「自動配送システム」であるCI/CDパイプラインが使う「マスターキー」（資格情報）が漏れると、攻撃者は本番環境に侵入し、悪意のあるコードを混入させたり、顧客データを盗んだりできてしまうのです。
CI/CD資格情報の流出の現状
CI/CD資格情報の流出は、2024年から2025年にかけて急速に深刻化しているクラウド・ソフトの供給リスクの一つです。最新の調査によると、資格情報の漏洩は2025年に前年比160%増加し、2024年に発生したセキュリティ侵害の22%がこの問題に起因しています。
2025年3月には、CI/CDセキュリティにおいて過去最大級のインシデントが発生しました。広く使用されているGitHub Action「tj-actions/changed-files」が侵害され、CVE-2025-30066（CVSS 8.6、重大）として追跡されています。このアクションは23,000以上のリポジトリで使用されており、攻撃者はコードを改ざんして複数のバージョンタグを遡及的に更新し、悪意のあるコミットを参照させました。侵害されたアクションは、CI/CDワークフローログにシークレット（APIキー、アクセストークンなど）を出力する機能を持っており、ワークフローログが公開されている場合、機密情報が無許可で公開されてしまいます。
さらに詳細な調査により、この攻撃は2024年11月にまで遡ることが判明しています。攻撃者はまず、SpotBugsプロジェクトのメンテナーのPAT（Personal Access Token）を窃取し、そのトークンを使ってreviewdogプロジェクトに横展開し、最終的にCoinbaseの「agentkit」リポジトリまで侵害しました。このサプライチェーン攻撃では、pull_request_targetトリガーの脆弱性が悪用され、攻撃者が提出した悪意のあるプルリクエストにより、ワークフロー内の全てのシークレットがAES暗号化された上で攻撃者のサーバーへ送信されました。
同じく2025年には、「ArtiPACKED」という新たな攻撃手法が発見されました。これは、GitHub ActionsのアーティファクトからGITHUB_TOKENやACTIONS_RUNTIME_TOKENなどのトークンが漏洩する問題で、リポジトリへの読み取りアクセス権を持つ攻撃者が、これらのトークンを使ってリポジトリを乗っ取り、組織のクラウド環境にアクセスできてしまいます。
過去の大規模インシデントとしては、2020年に発覚したSolarWindsのサプライチェーン攻撃があります。攻撃者はSolarWindsのCI/CDパイプラインに侵入し、18,000以上の顧客に悪意のあるコードを含むアップデートを配信しました。この攻撃は14ヶ月以上検出されず、米国政府機関や大企業に甚大な被害をもたらしました。
2023年には、CircleCIのシステムが侵害され、同社は全ての顧客に対して「あらゆるシークレット」をローテーション（更新）するよう緊急通知を発出しました。また、Codecov侵害では数千の資格情報が盗まれ、Samsungの事例ではSmartThingsアプリのソースコードとシークレットキーが流出しました。
2025年の160億件の資格情報漏洩（これは新しい侵害ではなく、過去の漏洩の集約ですが）には、開発者の資格情報、CI/CDシステムへのアクセストークン、クラウドログインなどが大量に含まれており、これらの資格情報が悪用されれば、コード、設定、デプロイメントパイプラインが露出し、攻撃者に中核システムへのショートカットを提供することになります。
日本国内では、デジタル庁が2024年3月に「CI/CD パイプラインにおけるセキュリティの留意点に関する技術レポート」を発行し、政府情報システムにおけるCI/CDパイプラインのセキュリティ対策の重要性を強調しています。また、米国のCISA（Cybersecurity and Infrastructure Security Agency）とNSAは2023年6月に「Defending Continuous Integration/Continuous Delivery (CI/CD) Environments」を発行し、CI/CDセキュリティの脅威と緩和策について包括的なガイダンスを提供しています。
CI/CD資格情報の流出で発生する被害は？
CI/CD資格情報の流出が発生すると、その影響は単なるデータ漏洩にとどまらず、組織全体のソフトウェア開発プロセス、本番環境、さらには顧客にまで及ぶ可能性があります。CI/CDパイプラインは本番環境への直接アクセス権限を持つため、資格情報の漏洩は組織にとって最も危険なセキュリティインシデントの一つとなります。
CI/CD資格情報の流出で発生する直接的被害
-
本番環境への不正アクセスとデータ窃取: 漏洩したCI/CD資格情報を使用すると、攻撃者は本番環境のデータベース、ストレージ、APIに直接アクセスできます。例えば、AWS S3のアクセスキーやAzureのサービスプリンシパルが漏洩すると、顧客の個人情報、決済情報、機密ビジネスデータなど、あらゆるデータを窃取できてしまいます。2024年初頭のある事例では、クラウドストレージの設定ミスと漏洩したS3アクセスキーにより、中堅SaaSプロバイダーの内部ビルドが露出し、ステージングアカウントのキーであったにもかかわらず、本番環境へのアクセスが可能でした。
-
悪意のあるコードの注入とサプライチェーン汚染: CI/CDパイプラインへのアクセス権を持つ攻撃者は、ソースコードリポジトリに悪意のあるコードを挿入し、それが自動的にビルド・テストされて本番環境にデプロイされるようにできます。2023年の事例では、攻撃者が漏洩したGitHubトークンを悪用して開発者のリポジトリに侵入し、CI/CDパイプラインに侵入してマルウェアを広く使用されているオープンソースパッケージに注入しました。このようなサプライチェーン汚染は、そのパッケージを使用する全ての下流顧客に影響を及ぼし、被害が指数関数的に拡大します。
-
システム全体の乗っ取りとランサムウェア展開: CI/CD資格情報は、しばしば管理者レベルの権限を持つため、攻撃者はこれを使ってシステム全体を乗っ取ることができます。権限昇格、横展開により、攻撃者は企業ネットワーク内の複数のシステムに侵入し、最終的にランサムウェアを展開して全システムを暗号化することも可能です。CI/CDパイプラインからの侵入は、通常のエンドポイント攻撃よりも検出が困難であり、攻撃者はより長期間にわたってシステム内に潜伏できます。
CI/CD資格情報の流出で発生する間接的被害
-
開発プロセスの停止と生産性の大幅低下: CI/CD資格情報の漏洩が発覚すると、組織はすべてのシークレットをローテーション（更新）し、パイプライン全体を再構築する必要があります。CircleCIの2023年の侵害では、全顧客が「あらゆるシークレット」のローテーションを強いられ、数週間にわたって開発・デプロイメントプロセスが停止しました。このようなインシデント対応中は、新機能のリリースができず、顧客への価値提供が滞り、競争力の低下につながります。
-
顧客信頼の喪失とビジネス機会の損失: CI/CDパイプラインの侵害により顧客データが漏洩したり、悪意のあるコードが配信されたりすると、顧客は「このサービスは安全ではない」と判断し、契約を解除する可能性があります。特にSaaS企業や金融サービス企業など、セキュリティが重要視される業種では、一度失った信頼を回復することは極めて困難です。また、セキュリティインシデントがニュースで報道されると、新規顧客獲得も困難になり、長期的な収益減少につながります。
-
法的責任と規制違反による罰金: CI/CD資格情報の流出により個人情報が漏洩した場合、個人情報保護法、GDPR、CCPA、HIPAAなどの規制に違反する可能性があります。規制違反には重い罰金が科され、GDPRでは最大で全世界年間売上高の4%または2,000万ユーロのいずれか高い方の罰金が科される可能性があります。また、顧客や株主からの訴訟リスクも高まり、弁護士費用や和解金などの法的コストが膨大になります。
CI/CD資格情報の流出の対策方法
CI/CD資格情報の流出を防ぐためには、開発プロセスの各段階でセキュリティ対策を組み込み、多層防御のアプローチを取ることが重要です。完全に防ぐことは難しいものの、リスクを大幅に低減できる対策が存在します。
開発者・個人としての対策では、まずシークレットをコードに直接埋め込まないことが最も重要です。APIキー、パスワード、アクセストークンなどを絶対にソースコードファイルや設定ファイルにハードコーディングしないでください。代わりに、環境変数やシークレット管理サービスを使用します。Gitにコミットする前に、pre-commitフックを設定して、シークレットが含まれていないか自動チェックすることも有効です。ただし、--no-verifyオプションでフックをバイパスできるため、これだけでは不十分です。
コミット前のセルフレビューも欠かせません。git diffコマンドでコミット内容を確認し、意図しないファイルや機密情報が含まれていないか目視チェックしてください。特に、.envファイル、config.json、credentials.yamlなどの設定ファイルは要注意です。
ブラウザに保存された認証情報の管理も重要です。GitHubやGitLab、クラウドプロバイダーのコンソールに自動ログインできるようブラウザに認証情報を保存していると、InfoStealerマルウェアに感染した際に一括で盗まれる危険があります。2025年の160億件の資格情報漏洩の多くは、ブラウザに保存された認証情報がInfoStealerマルウェアによって窃取されたものでした。
個人アクセストークン（PAT）の適切な管理も不可欠です。GitHubやGitLabで発行したPATには必ず有効期限を設定し（推奨は90日以内）、必要最小限のスコープ（権限）のみを付与してください。また、PATを複数のプロジェクトや用途で使い回さず、プロジェクトごとに個別のトークンを発行することで、万が一の漏洩時の影響範囲を限定できます。
企業・組織としての対策では、シークレット管理サービスの導入が最優先事項です。HashiCorp Vault、AWS Secrets Manager、Azure Key Vault、Google Secret Managerなどの専用サービスを使用して、全てのシークレットを一元管理します。これらのサービスは、シークレットの暗号化保存、アクセス制御、ローテーション（定期的な更新）、監査ログなどの機能を提供します。シークレットをCI/CD環境変数として直接保存するのではなく、パイプライン実行時にシークレット管理サービスから動的に取得する方式を採用してください。
継続的なシークレットスキャンの実装も重要です。GitGuardian、TruffleHog、Gitleaksなどのツールを使用して、コードリポジトリ全体（過去のコミット履歴を含む）を定期的にスキャンし、シークレットが含まれていないか確認します。スキャンで発見されたシークレットは、直ちにローテーションし、悪用の履歴がないかログを確認してください。CI/CDパイプラインにもシークレットスキャンを組み込み、シークレットを含むコミットが検出された場合、ビルドを自動的に失敗させる設定にします。
最小権限の原則の徹底も必須です。CI/CDパイプラインの各段階（ビルド、テスト、デプロイ）に与える権限を、その段階で必要最小限のものに制限します。例えば、ビルドフェーズでは本番環境へのアクセス権限は不要なので、付与しないでください。また、サービスアカウントやトークンは用途ごとに分離し、一つの資格情報が侵害されても、他の環境やリソースへの影響を最小限に抑えます。
短命な一時的資格情報の使用も効果的です。長期間有効な静的APIキーではなく、1時間〜24時間程度で自動失効する一時的なトークンを使用することで、万が一漏洩しても悪用できる期間を大幅に短縮できます。AWSのAssumeRoleやAzureのManaged Identitiesなど、クラウドプロバイダーが提供する一時的資格情報の仕組みを活用してください。
CI/CDログの適切な管理も見落とせません。ビルドログ、コンソール出力、テスト結果などに、シークレットが出力されないよう適切に設定します。GitHub ActionsやGitLab CIなどのCI/CDプラットフォームには、シークレットマスキング機能（シークレットを自動的に「***」で隠す機能）がありますが、シークレットが別の文字列と連結されたり、エンコードされたりすると、マスキングが機能しない場合があります。そのため、ログ出力前にシークレットが含まれていないか確認するロジックを実装してください。
コンテナイメージとアーティファクトのセキュリティも重要です。Dockerイメージのレイヤーやビルドアーティファクトにシークレットが含まれていないか、専用スキャンツールで確認します。特に、マルチステージビルドを使用していても、前段階でシークレットを使用した場合、イメージ履歴に残ってしまうことがあるため注意が必要です。公開リポジトリ（Docker Hubなど）にイメージをプッシュする前に、必ずシークレットスキャンを実施してください。
アクセス制御とブランチ保護ルールの設定も不可欠です。本番環境へのデプロイをトリガーするブランチ（mainやproductionなど）には、厳格なブランチ保護ルールを設定し、承認されたレビュアーによるコードレビューと承認を必須にします。また、CI/CDパイプラインの設定ファイル（.github/workflows、.gitlab-ci.ymlなど）への変更も同様に保護し、悪意のある変更が紛れ込まないようにします。
CI/CD資格情報の流出の対策を簡単に言うと？
CI/CD資格情報の流出対策を日常生活で例えるなら、「重要な鍵を金庫に保管し、使うときだけ取り出して、定期的に鍵を交換する」ようなものです。
先ほどの「自動配送システムのマスターキー」の例で言えば、対策とは、キーを誰もが見られる場所（公開のウェブサイトやソースコード）に置かないことです。まず、全てのキーを専用の金庫（シークレット管理サービス）に保管します。配送システムがキーを必要とするときだけ、金庫から一時的にキーを取り出し、使い終わったら返却します。このキーは「1日だけ有効なコピー」なので、万が一誰かに盗まれても、翌日には使えなくなります（一時的資格情報）。
また、定期的にキーを交換する習慣をつけます（ローテーション）。毎月1回、全ての鍵を新しいものに交換すれば、古いキーを誰かが持っていても無効になります。さらに、倉庫のキーは倉庫専用、配送車のキーは配送車専用というように、キーの用途を分けておけば（最小権限の原則）、一つのキーが盗まれても、全てのシステムが危険にさらされることはありません。
そして、システムの動作記録（ログ）にキーの情報が記録されないよう注意します。配送記録に「今日使ったキーは12345です」と書いてしまったら、その記録を見た人がキーをコピーできてしまいます。記録にはキーの情報を含めず、「キーを使ってアクセスしました」とだけ記録します（ログのシークレットマスキング）。
CI/CD資格情報の流出に関連した攻撃手法
CI/CD資格情報の流出は、単独で発生するよりも、他のクラウド・ソフトの供給リスクと組み合わせて使用されることが多い攻撃手法です。ここでは、CI/CD資格情報の流出と密接に関連する3つの攻撃手法について解説します。
サプライチェーン攻撃
サプライチェーン攻撃は、ソフトウェアの開発・配信過程に侵入し、正規のソフトウェアやアップデートに悪意のあるコードを埋め込む攻撃手法です。CI/CD資格情報の流出は、このサプライチェーン攻撃を実行するための最も効果的な手段の一つとなっています。
現代のソフトウェア開発では、多数のサードパーティライブラリ、オープンソースコンポーネント、CI/CDツールに依存しています。攻撃者は、これらのサプライチェーンの中で最も脆弱な部分、すなわちCI/CDパイプラインを標的にします。CI/CDパイプラインの資格情報を入手できれば、攻撃者は正規のビルドプロセスに悪意のあるコードを注入し、そのコードが自動的にビルド・テストされて本番環境にデプロイされるようにできます。
2025年3月のtj-actions/changed-filesの侵害は、まさにこのパターンでした。攻撃者は、広く使用されているGitHub Action（CI/CDパイプラインで使用される再利用可能なワークフローコンポーネント）を侵害し、そのアクションを使用している23,000以上のリポジトリから資格情報を窃取しました。このような攻撃は、一度成功すれば、数千から数万のダウンストリーム顧客に連鎖的に影響を及ぼすため、攻撃者にとって非常に効率的です。
2020年のSolarWinds攻撃も、CI/CDパイプラインへの侵入から始まりました。攻撃者はSolarWindsの開発環境に侵入し、CI/CDパイプラインを操作して、正規のソフトウェアアップデートにバックドアを埋め込みました。その結果、18,000以上の顧客組織（米国政府機関や大企業を含む）に悪意のあるコードが配信され、攻撃者は14ヶ月以上にわたって検出されることなく、これらの組織のネットワーク内で活動を続けました。
対策としては、ソフトウェア部品表（SBOM）の作成と管理が重要です。SBOMは、ソフトウェアに含まれる全てのコンポーネント（ライブラリ、依存関係、ツールなど）のリストであり、サプライチェーン攻撃の影響範囲を特定するために不可欠です。また、依存関係の署名検証（例：npm package signatureやDocker Content Trust）を実装し、使用するコンポーネントが改ざんされていないことを確認してください。CI/CDパイプライン自体のセキュリティ強化として、パイプライン設定ファイルへの変更を厳格に管理し、サードパーティのGitHub ActionsやGitLab CIコンポーネントを使用する際は、バージョンをハッシュ値で固定することで、遡及的な改ざんから保護できます。
シークレット漏洩
シークレット漏洩は、APIキー、パスワード、証明書、暗号鍵などの機密情報が、意図せず公開されたり、不適切に保存されたりすることで発生します。CI/CD資格情報の流出の多くは、このシークレット漏洩の一形態です。
シークレット漏洩の最も一般的な経路は、パブリックなGitHubリポジトリへのコミットです。開発者が設定ファイルやテストコードに含まれるAPIキーやパスワードに気づかずにコミットし、そのリポジトリが公開されている場合、数分以内に自動スキャンボットによって発見され、悪用されます。GitHubの調査によると、公開リポジトリに機密情報がコミットされると、平均してわずか数分でボットにスキャンされ、悪用が始まることが報告されています。
また、CI/CDパイプラインのビルドログやコンソール出力からのシークレット漏洩も深刻な問題です。パイプライン実行中にデバッグ情報として出力されたシークレットが、ログに記録されてしまうケースがあります。多くのCI/CDプラットフォームにはシークレットマスキング機能がありますが、シークレットがbase64エンコードされていたり、別の文字列と連結されていたりすると、マスキングが機能しないことがあります。
コンテナイメージからのシークレット漏洩も見落とせません。Dockerイメージをビルドする際、マルチステージビルドを使用していても、前段階で使用したシークレットがイメージ履歴に残ってしまうことがあります。このようなイメージをDocker Hubなどの公開レジストリにプッシュすると、誰でもイメージ履歴を調べてシークレットを抽出できてしまいます。
対策としては、CI/CD資格情報の流出対策で述べたシークレット管理サービスの導入が基本となりますが、加えて、Gitリポジトリの過去のコミット履歴の定期的なスキャンも重要です。git-secretsやgit-leaksなどのツールを使用して、過去のコミットにシークレットが含まれていないか確認し、発見された場合は直ちにローテーションします。また、機密情報が含まれる可能性のある.envファイルや.credentialsファイルを.gitignoreに追加し、誤ってコミットされないようにします。シークレットが誤ってコミットされた場合の対応手順を事前に文書化しておき、迅速なインシデント対応ができる体制を整えてください。
アップデートの乗っ取り
アップデートの乗っ取りは、ソフトウェアのアップデートメカニズムを悪用し、正規のアップデートプロセスを通じてマルウェアや悪意のあるコードを配信する攻撃手法です。CI/CD資格情報の流出は、この攻撃を実行する際の重要な足がかりとなります。
多くのソフトウェアは、自動アップデート機能を持っており、定期的に開発者のサーバーから最新バージョンをダウンロード・インストールします。攻撃者がCI/CD資格情報を入手してビルド・デプロイプロセスを乗っ取ると、正規のアップデートチャネルを通じて悪意のあるコードを配信できます。利用者は信頼できる開発者からの正規のアップデートだと信じてインストールするため、このタイプの攻撃は極めて効果的です。
SolarWinds攻撃では、まさにこの手法が使われました。攻撃者はCI/CDパイプラインを侵害し、Orionプラットフォームのアップデートにバックドアを埋め込みました。このアップデートは正規の署名が付与され、通常のアップデートチャネルを通じて配信されたため、18,000以上の組織が疑うことなくインストールし、結果として攻撃者のバックドアを自らのネットワークに招き入れることになりました。
アップデートの乗っ取りは、ソフトウェア以外にも、ファームウェア、OSパッチ、モバイルアプリなど、あらゆる種類のアップデートで発生する可能性があります。特に、IoTデバイスや組み込みシステムのファームウェアアップデートは、セキュリティが脆弱なことが多く、攻撃の標的となりやすいです。
対策としては、コード署名と署名検証の徹底が最も重要です。リリースされる全てのソフトウェア・アップデートに開発者の秘密鍵で署名を付与し、利用者側では公開鍵で署名を検証してからインストールします。署名に使用する秘密鍵は、オフラインの安全な場所に保管し、CI/CDパイプラインから直接アクセスできないようにします。また、リリースプロセスの多要素認証（MFA）と人間による承認を必須にし、完全に自動化されたリリースを避けることで、攻撃者がパイプラインを侵害しても、勝手にアップデートをリリースできないようにします。さらに、Software Bill of Materials（SBOM）とアップデート履歴の公開により、透明性を高め、利用者が配信されたアップデートの正当性を検証できるようにすることも効果的です。
CI/CD資格情報の流出のよくある質問
Q1. 自社のCI/CDパイプラインに資格情報の漏洩リスクがあるか確認する方法はありますか？
自社のCI/CDパイプラインに資格情報の漏洩リスクがあるかを確認するには、体系的なセキュリティ評価を実施する必要があります。以下の手順で確認してください。
まず、コードリポジトリの全履歴スキャンを実施します。TruffleHog、GitLeaks、GitGuardianなどのツールを使用して、Gitリポジトリの全コミット履歴（過去のコミットを含む）をスキャンし、APIキー、パスワード、アクセストークンなどのシークレットが含まれていないか確認します。特に、公開リポジトリは優先的にスキャンしてください。スキャンでシークレットが発見された場合は、直ちにローテーションが必要です。
次に、CI/CDパイプライン設定の監査を行います。GitHub Actions、GitLab CI、Jenkins、CircleCIなどのCI/CD設定ファイル（.github/workflows/、.gitlab-ci.yml、Jenkinsfileなど）を確認し、環境変数やシークレットがハードコードされていないかチェックします。また、ビルドログやコンソール出力にシークレットが出力されていないか、過去のビルド履歴を確認してください。
シークレット管理の実態調査も重要です。組織内で使用されている全てのAPIキー、アクセストークン、サービスアカウントをリストアップし、それぞれがどこに保存されているか（シークレット管理サービス、環境変数、コード内など）、誰がアクセスできるか、最後にローテーションされたのはいつかを確認します。特に、長期間ローテーションされていない資格情報や、広範な権限を持つ資格情報は高リスクです。
コンテナイメージとアーティファクトのスキャンも忘れずに実施してください。DockerイメージやJARファイルなどのビルドアーティファクトを専用スキャンツール（Trivy、Grypeなど）で分析し、シークレットが埋め込まれていないか確認します。特に、公開レジストリにプッシュされているイメージは優先的にスキャンしてください。
定期的な脆弱性診断とペネトレーションテストの実施も効果的です。外部のセキュリティ専門家に依頼して、CI/CDパイプライン全体のセキュリティ評価を行ってもらいましょう。OWASP Top 10 CI/CD Security Risksに基づいた評価を依頼すると、体系的な診断が可能です。また、社内でレッドチーム演習を実施し、攻撃者の視点からパイプラインの脆弱性を探すことも有効です。
Q2. CI/CD資格情報が漏洩した疑いがある場合、どのような初動対応をすべきですか？
CI/CD資格情報が漏洩した疑いがある場合、迅速かつ組織的な初動対応が被害の拡大を防ぐ鍵となります。以下の手順で対応してください。
まず、即座のシークレット無効化を実施します。漏洩の疑いがあるシークレット（APIキー、アクセストークン、パスワードなど）を直ちに無効化または削除します。AWS、Azure、Google Cloudなどのクラウドプロバイダーの管理コンソールで、該当する資格情報を見つけて無効化してください。GitHubやGitLabのPersonal Access Tokenも同様に取り消します。この段階では、「疑わしきは無効化する」という原則で、過剰反応を恐れずに対応することが重要です。
並行して、影響範囲の特定を行います。漏洩した資格情報がアクセスできるリソースを特定し、どのシステム、データベース、APIが影響を受ける可能性があるかリストアップします。また、資格情報がいつから漏洩していた可能性があるかを特定し（例：GitHubへのコミット日時、ログへの出力日時など）、その期間中の不審なアクセスがないかログを確認します。
不正アクセスの痕跡調査も迅速に実施してください。クラウドプロバイダーのアクセスログ（AWS CloudTrail、Azure Activity Log、Google Cloud Audit Logsなど）、アプリケーションログ、CI/CDビルドログを分析し、漏洩した資格情報を使用した不審なアクティビティがないか確認します。特に、通常と異なる時間帯のアクセス、異常な地理的位置からのアクセス、大量のデータダウンロード、リソースの作成・削除などは要注意です。
関係者への通知と協力要請を行います。セキュリティインシデント対応チーム、開発チームリーダー、経営陣に状況を報告し、組織全体で対応する体制を整えます。必要に応じて、外部のセキュリティ専門家やフォレンジック調査会社に支援を依頼してください。
シークレットの完全なローテーションを実施します。影響を受ける可能性のある全てのシークレットを新しいものに置き換えます。これには、直接漏洩したシークレットだけでなく、それに関連するシークレット（同じサービスアカウントで発行された他のトークンなど）も含まれます。ローテーション後は、新しいシークレットを安全に配布し、CI/CDパイプラインや関連システムを更新してください。
インシデントの根本原因分析も重要です。なぜ資格情報が漏洩したのか（コミットミス、ログ出力、設定不備など）、どのプロセスが不十分だったのかを分析し、再発防止策を策定します。また、今回のインシデントで学んだ教訓を文書化し、組織全体で共有してください。
Q3. CI/CDパイプラインで使用するシークレットのローテーション頻度はどのくらいが適切ですか？
CI/CDパイプラインで使用するシークレットのローテーション頻度は、シークレットの種類、重要度、使用状況によって異なりますが、一般的なガイドラインとして以下を推奨します。
高権限のシークレット（本番環境への書き込み権限、管理者権限を持つトークンなど）は、30日〜90日ごとのローテーションが推奨されます。これには、AWS IAMアクセスキー、Azureサービスプリンシパル、Google Cloudサービスアカウントキーなどが含まれます。特に、本番データベースへのアクセス権限を持つ資格情報は、最短でも30日ごとにローテーションすべきです。
中程度の権限のシークレット（開発環境やステージング環境へのアクセス、読み取り専用権限など）は、90日〜180日ごとのローテーションが一般的です。これには、テスト用APIキー、ステージング環境のデータベース接続文字列などが含まれます。
Personal Access Token（PAT）やGitHubトークンは、90日以内のローテーションを強く推奨します。GitHubやGitLabでは、PATに有効期限を設定できるため、新規発行時に必ず有効期限を設定し、期限切れ前に更新する運用を確立してください。
ただし、これらは「最大でも」この頻度でローテーションすべきという目安であり、以下のような状況では、定期スケジュールにかかわらず即座にローテーションが必要です。まず、セキュリティインシデント発生時や漏洩の疑いがある場合は即座にローテーションしてください。また、従業員の退職や役割変更時も、その従業員がアクセスできた全てのシークレットをローテーションします。さらに、第三者ベンダーとの契約終了時や、使用しているツール・サービスで重大な脆弱性が公開された場合も、予防的にローテーションを実施すべきです。
実用的なローテーション戦略としては、自動ローテーションの実装が理想的です。AWS Secrets ManagerやAzure Key Vaultには、自動ローテーション機能があり、スケジュールに基づいて自動的にシークレットを更新できます。手動ローテーションの負担を減らすため、できる限り自動化を進めてください。
また、短命な一時的資格情報の使用も検討してください。可能な場合は、長期間有効な静的シークレットではなく、1時間〜24時間程度で自動失効する一時的トークンを使用することで、定期的なローテーションの必要性を減らせます。AWSのAssumeRole、AzureのManaged Identities、Google CloudのWorkload Identityなどを活用してください。
Q4. GitHub ActionsなどのCI/CDサービスを使用する際の最低限のセキュリティ設定は何ですか？
GitHub ActionsやGitLab CI、CircleCIなどのCI/CDサービスを安全に使用するには、以下の最低限のセキュリティ設定を実施してください。
まず、リポジトリのシークレット管理を適切に設定します。GitHub Actionsの場合、Settings > Secrets and variables > Actionsから、環境変数としてシークレットを登録します。シークレットは絶対にワークフローファイル内にハードコードせず、必ずこの機能を使用してください。また、シークレットのスコープを適切に設定し、特定の環境（ProductionやStagingなど）でのみ使用できるように制限します。
ブランチ保護ルールの設定も必須です。本番環境へのデプロイをトリガーするブランチ（mainやproductionなど）に、以下のルールを設定してください。プルリクエストのレビューと承認を必須にする（最低でも1名以上の承認が必要）、ステータスチェックの合格を必須にする（CI/CDテストが全て成功しないとマージできない）、管理者も含めた全員にルールを適用する（Allow force pushesを無効にする）、そして、ブランチの削除を禁止します。
ワークフロー権限の最小化も重要です。GitHub Actionsのワークフローには、GITHUB_TOKENという自動発行されるトークンがあり、リポジトリへのアクセス権限を持ちます。Settings > Actions > General > Workflow permissionsで、デフォルトを「Read repository contents and packages permissions」（読み取り専用）に設定し、書き込み権限が必要なワークフローでのみ、明示的に権限を付与してください。
pull_request_targetトリガーの使用制限も必須です。pull_request_targetは、フォークからのプルリクエストでもワークフローを実行できる便利な機能ですが、攻撃者が悪意のあるコードを含むプルリクエストを送信し、シークレットを窃取する攻撃に悪用されます。可能な限りpull_requestトリガーを使用し、pull_request_targetは絶対に必要な場合のみ、厳格な検証ロジックと組み合わせて使用してください。
サードパーティアクションの使用を慎重に行うことも重要です。GitHub Marketplace などから取得したサードパーティのアクションは、バージョンをコミットハッシュで固定してください（例：uses: actions/checkout@a12b3c4d...）。タグ（@v2など）ではなくハッシュを使用することで、遡及的な改ざんから保護できます。また、使用する前にアクションのソースコードを確認し、信頼できる開発者が管理しているか、最近も更新されているか、多くのユーザーに使用されているかをチェックしてください。
定期的な監査とログレビューも欠かせません。GitHub Actionsのワークフロー実行履歴を定期的に確認し、不審な実行がないかチェックします。特に、通常と異なる時間帯の実行、失敗が続いているワークフロー、シークレットを使用しているワークフローは重点的に確認してください。
Q5. 小規模スタートアップや個人開発者でも、CI/CD資格情報のセキュリティ対策は必要ですか？
はい、小規模スタートアップや個人開発者であっても、CI/CD資格情報のセキュリティ対策は絶対に必要です。むしろ、リソースが限られている小規模組織こそ、セキュリティインシデントの影響が致命的になる可能性が高いため、基本的な対策を早期に実装することが重要です。
小規模組織が特に標的にされやすい理由があります。まず、攻撃者は大企業よりも小規模組織の方がセキュリティ対策が脆弱だと認識しており、侵入しやすい標的として狙われやすいです。また、小規模スタートアップは、顧客データや知的財産（独自の技術、アルゴリズムなど）を保有しているため、攻撃の価値があります。さらに、大企業のサプライチェーンの一部として機能している場合、小規模組織を経由して大企業に侵入する「踏み台攻撃」のターゲットにもなります。
小規模組織でも実装可能な基本対策として、まず無料のシークレット管理ツールを活用してください。AWS Secrets Manager（無料枠あり）、Google Secret Manager（無料枠あり）、GitHub Secrets（無料）、GitLab CI/CD Variables（無料）など、無料または低コストで利用できるシークレット管理機能を活用し、シークレットをコードから分離します。
次に、GitHubやGitLabの無料機能を最大限活用します。ブランチ保護ルール、必須レビュー、ステータスチェックなどの基本的なセキュリティ機能は、無料プランでも利用可能です。また、Dependabotなどの自動依存関係アップデート機能も活用してください。
無料のシークレットスキャンツールの導入も効果的です。TruffleHog（オープンソース）、GitLeaks（オープンソース）、GitGuardian（個人開発者向け無料プラン）などを使用して、リポジトリを定期的にスキャンします。pre-commitフックを設定し、コミット前に自動チェックを実行することも忘れずに。
チーム全体でのセキュリティ意識の向上も重要です。小規模チームでは、全員がセキュリティ責任を共有する文化を作ることが重要です。定期的な社内勉強会（月1回、30分程度でも効果的）を開催し、最新のセキュリティ脅威や対策を共有してください。また、セキュリティインシデントが発生した際の対応手順を事前に文書化しておくことで、パニックにならずに対応できます。
小規模だからこそ、早期投資の効果が高いという利点もあります。組織が小さいうちにセキュリティベストプラクティスを確立しておけば、組織が成長しても、そのまま拡張できます。後からセキュリティ対策を導入するよりも、初期段階から組み込む方がはるかに容易です。
Q6. CI/CD資格情報の流出とシークレット漏洩の違いは何ですか？
CI/CD資格情報の流出とシークレット漏洩は、密接に関連していますが、厳密には以下のような違いがあります。
CI/CD資格情報の流出は、CI/CDパイプライン（継続的インテグレーション/継続的デリバリーのプロセス）で特に使用される資格情報が漏洩することを指します。これには、GitHub Actions secrets、GitLab CI/CD variables、Jenkins credentials、クラウドプロバイダーのサービスアカウントキー、コンテナレジストリの認証情報など、CI/CDプロセスの自動化に必要な認証情報が含まれます。この用語は、CI/CDパイプラインという特定のコンテキストに焦点を当てており、そのパイプラインを経由した攻撃や、パイプライン固有の脆弱性（ArtiPACKED攻撃、pull_request_target悪用など）を強調しています。
一方、シークレット漏洩は、より広範な概念です。あらゆる種類の機密情報（APIキー、パスワード、OAuth トークン、証明書、暗号鍵、データベース接続文字列など）が、意図せず公開されたり、不適切に保存されたりすることを指します。この用語は、CI/CDパイプラインに限定されず、Webアプリケーション、モバイルアプリ、設定ファイル、ドキュメントなど、あらゆる場所でのシークレット漏洩を含みます。
両者の関係は、包含関係にあると言えます。CI/CD資格情報の流出は、シークレット漏洩の一種であり、特にCI/CDパイプラインに関連するシークレット漏洩を指します。逆に言えば、シークレット漏洩は、CI/CD資格情報の流出を含む、より広範なセキュリティ問題です。
重要なのは、CI/CD資格情報の流出が特に深刻な理由です。CI/CD資格情報は、本番環境への直接アクセス、コードリポジトリへの書き込み、自動デプロイのトリガーなど、非常に強力な権限を持つことが多いため、漏洩時の影響が甚大です。また、CI/CDパイプラインは組織のソフトウェアサプライチェーンの中核にあるため、ここが侵害されると、連鎖的に多数のシステムや顧客に影響が及びます。
実務的には、両方の用語を適切に使い分けることが重要です。組織内でセキュリティポリシーを策定する際は、「シークレット漏洩」という広範な方針の下に、「CI/CD資格情報の流出」という特定のリスクに対する詳細な対策を含めることで、包括的かつ具体的な対策が可能になります。
更新履歴
- 初稿公開
