CI/CDパイプライン攻撃とは？build環境侵害の危険性と対策方法を徹底解説

CI/CDパイプライン攻撃とは何か

ビルドと配布の中枢が攻撃面になります

CI/CD パイプライン攻撃は、ワークフロー、実行基盤、秘密情報、成果物保管先、公開用トークンなど、ソフトウェアをビルドして届ける中枢が攻撃面になる問題です。code が正しく見えても、pipeline が侵害されれば配布物や設定は汚染されます。

そのため、リポジトリ漏えいや悪意あるパッケージと違い、ここでは「誰がどうビルドし、どこへ公開したか」が主役になります。

総論記事と下位手口の中間にある記事です

本記事はソフトウェアサプライチェーン攻撃の下位論点です。一方で依存関係混乱や悪意ある npm / PyPI パッケージとは主役が違います。

依存関係やレジストリが安全でも、パイプラインの秘密情報や実行基盤が弱ければ成果物は汚染されます。だからビルドとリリースを独立した攻撃面として切り出す価値があります。

なぜ成立するのか、どこが盲点になるのか

DevOps threat matrix でも pipeline 自体が攻撃面です

Microsoft のDevOps Threat Matrix↗は、ソースコードだけでなくビルドパイプライン、秘密情報、成果物までを主要な攻撃面として整理しています。これは「コードがきれいなら安全」という発想が不十分だということです。

パイプラインはビルドと配布の中心なので、ここが汚れると下流全体へ影響が広がります。だから担当者も権限も、アプリケーションコードと同じかそれ以上に厳しく扱う必要があります。

専用実行基盤と共用実行基盤は特に注意が必要です

実行基盤は『ただの処理場所』に見えますが、パイプライン攻撃では非常に重要です。用途分離が弱い実行基盤は、別ジョブや別プロジェクトへの足場になりやすく、ビルドのための便利さがそのまま横展開の足場になります。

そのため、実行基盤はコードと同じくらいレビューと分離が必要です。長寿命の実行基盤や広すぎる権限は、事故後の復旧も難しくします。

被害の広がり方と企業側のリスク

パイプラインが壊れると、きれいなコードでも汚れた配布物になります

CI/CD パイプライン攻撃の怖さは、ソースコードレビューを通っていても、ビルドや成果物の段階で配布物が変わることです。これにより、開発チームは「なぜその成果物が出たのか」を追いにくくなります。

公開された開発関連導線の見直しも補助線になります

パイプライン事故の中心は内部ですが、成果物配布ポータル、古い管理画面、外部公開ログイン画面が残っていると、事故後の横移動や認証情報悪用と結びつきやすくなります。だから外部接続点の可視化も補助線として有効です。

実行基盤・秘密情報・成果物を別々に管理する理由

runner を『ただの作業場所』として扱うと事故が広がります

CI/CD の実行基盤は、単に build を回す場所ではありません。実行中の runner は repository への読み書き、artifact への登録、container registry への push、署名鍵への接続、cloud 環境への deploy など、複数の権限を束ねて持つことがあります。この束ね方が強すぎると、一つの job が侵害された時に影響が横へ広がります。

だから実務では、同じ CI サービスを使っていても、公開用 build、内部検証、署名付き release、運用バッチを同じ実行基盤で回さない方が安全です。攻撃者が欲しいのはコード本体だけではなく、ビルドして公開できる場所です。そこをまとめて渡してしまうと、ソースコードに触れなくても配布物だけを汚染できます。

秘密情報は数よりも、どこまで届くかで危険度が決まります

パイプライン内の秘密情報も、件数より到達範囲が重要です。artifact registry の token、container registry の publish 権限、署名処理のための鍵、クラウド配布先の deploy credential、通知連携の webhook などが一つの job へ集中していると、侵害後の自由度が一気に上がります。長期 token や共有 secret が危険なのは、盗まれた後も広い権限を維持し続けるからです。

そのため「secret は vault に入っているから安全」という言い方は半分しか正しくありません。どの job が、いつ、どの条件で、その secret を取り出せるのかまで制御できて初めて安全性が上がります。特に release job や本番 deploy job は、閲覧権限と実行権限を分けるだけでも事故の広がり方が変わります。

成果物と配布経路も、パイプラインの一部として扱います

CI/CD 攻撃の議論で抜けやすいのが、成果物と配布経路です。build に成功した時点で安心しがちですが、実際には artifact storage、container image registry、release note、download portal、update manifest のどれかが変えられると、利用者には正規更新のように見えてしまいます。つまり安全に見える配布物でも、どこで生成され、どこで保管され、どこへ公開されたかを追えなければ十分ではありません。

ここはソフトウェアサプライチェーン攻撃とつながる部分です。package や code の review を通っていても、成果物の差し替えや manifest 改ざんがあれば下流影響は起きます。だから CI/CD の話では、runner と secrets だけでなく、artifact と distribution まで含めて一つの trust chain として見る必要があります。

どこで pipeline の trust が崩れるのか

workflow 変更は、実行権限の変更として扱います

CI/CD パイプライン攻撃で最も見落とされやすいのは、workflow 定義や build template の変更です。アプリケーションコードの差分は丁寧に review していても、workflow の trigger 条件、利用 image、呼び出す action、secret 注入条件、approval の省略などは軽く扱われがちです。しかし実際には、ここが変わると「誰が、どの条件で、何を実行できるか」が変わります。

つまり pipeline 攻撃で見るべき trust の崩れ方とは、exploit の有無だけではありません。小さな workflow 変更、action version の更新、runner label の変更、self-hosted runner の利用追加といった、運用差分が実行権限の差分に変わる瞬間を review できるかが重要です。

共用基盤と self-hosted runner は、それぞれ別の危険があります

共用基盤は、他 job や他用途との境界が弱いと、汚染や credential 残置が広がりやすい点が危険です。逆に self-hosted runner は、自社ネットワークや内部管理面へ近いことが多く、侵害された時に横移動の足場になりやすい点が危険です。どちらが安全かではなく、どこへ到達できるかを把握しないまま使うこと自体が問題です。

特に self-hosted runner では、運用の便利さから long-lived credential、共有 cache、永続ディスク、広い outbound 通信許可が残りやすくなります。これらは build を楽にしますが、事故後は侵害調査の範囲を一気に広げます。したがって runner の種類を選ぶ時は性能だけでなく、事故時の隔離しやすさまで見ておく必要があります。

外部 action・plugin・template の更新も supply chain です

pipeline は code repository 内の YAML だけで閉じていません。外部 action、shared template、container image、build plugin、社内共通 library のどれかが変われば、CI/CD の動きも変わります。つまり pipeline の trust は、自社 repository の外にも伸びています。ここを忘れると、review はしているのに実際には外部変更で動作が変わる状態になります。

したがって CI/CD 攻撃の対策では、workflow file のレビューだけでは不十分です。参照している action の pinning、template の配布元、base image の更新ルール、plugin の取得元までまとめて見なければ、pipeline 全体の trust は説明できません。

変更 review と incident review をどう作るか

コード review と同じ重さで pipeline change を扱います

再発防止で効くのは、CI/CD 変更をコード review と同等の change とみなすことです。workflow file、runner 設定、deploy 手順、secret の参照条件、artifact の公開先、approval の条件が変わる時は、アプリケーションコードの major change と同じように差分理由と影響範囲を説明させるべきです。ここを軽く扱うと、便利さを理由に危険な近道が積み上がります。

review の観点も、「動くかどうか」では足りません。どの secret が必要か、どの runner で動くか、どの artifact が作られるか、失敗した時に何が残るか、どこへ公開されるかまで確認して初めて、pipeline の review になります。

incident review は、汚れた commit より先に汚れた配布物を探します

事故後にまず見るべきなのは、「どの commit が悪かったか」だけではありません。どの build が生成され、どの artifact が保管され、どの release や container image が公開され、どの利用者へ届いた可能性があるかを先に押さえる必要があります。CI/CD 攻撃では、配布物の追跡が遅れるほど顧客影響の判断も遅れます。

そのため incident review では、workflow 差分、runner 利用履歴、secret access log、artifact hash、配布履歴、rollback 手順を一つの時系列へ戻せるようにしておくべきです。ここができていると、復旧は「怪しい build を止める」から「安全な配布状態へ戻す」へ変わります。

平時から rollback 条件と停止条件を決めておきます

実務で最も困るのは、事故時に pipeline を止める判断、release を引っ込める判断、deploy を継続する判断の基準が決まっていないことです。CI/CD は継続 delivery を前提にしているため、止めること自体が大きな意思決定になります。だからこそ、どんな兆候が出たら release を保留し、どの artifact を破棄し、どの secret を rotate するかを平時から決める必要があります。

この考え方はランサムウェア初動対応と同じで、事故が起きてから役割分担を決めるのでは遅いです。CI/CD でも、止める条件、戻す条件、再開条件を明文化し、platform team、security team、product owner が同じ言葉で判断できる状態にしておくと、被害を小さくできます。

平時の運用で build integrity をどう守るか

daily operation を軽くしすぎると、攻撃者の変更も紛れます

CI/CD の現場では、開発速度を落とさないために workflow の簡略化や権限共有が進みがちです。しかし daily operation を軽くしすぎると、攻撃者が混ぜた変更も同じ流れで通ります。たとえば temporary な debug step、手動 deploy の近道、共有 publish token、review を省略した emergency fix は、平時は便利でも incident 時には真っ先に疑うべき導線になります。

だから build integrity を守るとは、強いツールを足すことだけではありません。例外運用をどこまで認めるか、緊急時の bypass を誰が承認するか、手動 release をどの記録に残すかを決めることでもあります。こうした日常運用が整っていると、怪しい change は「技術的に危険だから」だけでなく「いつもの運用から外れているから」という観点でも拾えます。

監査証跡は security team だけでなく release 担当にも読める形にします

build integrity の維持には証跡が必要ですが、security team しか読めないログでは実務に乗りません。どの commit から build されたか、どの runner で動いたか、どの secret を参照したか、どの artifact を出し、どこへ配布したかが、release 担当や product owner にも読める形で整理されていると、異常時の停止判断が速くなります。

つまり CI/CD 攻撃への備えは、単なる監視強化ではなく、build integrity を運用の共通言語にすることです。誰が見ても「この build は正規の経路を通った」と言える状態を作れば、逆に言えない build も見つけやすくなります。ここまでできると、パイプライン攻撃は漠然と怖いテーマではなく、止めるべき change と戻すべき artifact を判断できる実務テーマへ変わります。

そのため平時の運用では、成功した build の数だけを見るのではなく、どれだけ説明可能な build を積み上げられているかを見る視点が欠かせません。説明できない例外 build、手動 release、review なしの workflow 変更を減らすこと自体が、CI/CD パイプライン攻撃への強い防御になります。

検知・防御・運用で押さえるべき対策

実務では、まず実行基盤、秘密情報、公開用トークンの棚卸し、その次に来歴証明と審査ゲート、最後に実行基盤の分離と短命化の順で整えると、影響を抑えやすくなります。

開発関連の公開導線や管理面の棚卸しなら ASM診断 PRO

ASM診断 PRO は CI/CD を直接守る製品ではありませんが、公開された成果物配布ポータル、古いログイン画面、委託先導線、開発関連管理 URL を洗い出す入口として使えます。

パイプライン事故後はビルド基盤だけでなく、外部へ露出した周辺導線の点検も必要です。公開面を先に見える化しておくと、事故後の確認範囲を狭めやすくなります。

とくに CI/CD 事故では、artifact 配布ポータル、古い release 管理画面、停止済みの build host、委託先が使う login、昔の検証用サブドメインなど、内部では忘れられていても外から見える導線が incident review の対象になります。これらが整理されていないと、どこまで外部から触れられた可能性があるのかを確認するだけで時間を失います。

ASM診断 PRO は runner や workflow file そのものを保護する製品ではありませんが、外部公開された周辺管理面を減らし、事故後に確認すべき範囲を明確にする補助線になります。たとえば成果物配布面、古い download host、委託先向け portal、未廃止の開発 URL を平時から見える化しておくと、pipeline compromise 後の波及確認が速くなります。

つまりここでの価値は、「パイプラインを直接守る」ことではなく、「パイプライン事故の後に外部からたどれる周辺導線を減らしておく」ことです。内部の build 統制と外部露出整理を同じ改善テーマへ戻すと、incident review と再発防止をつなぎやすくなります。

よくある質問

まとめ

CI/CDパイプライン攻撃の本質は、コードそのものよりビルドと配布の中枢が侵害されることにあります。実行基盤、秘密情報、公開用トークン、成果物の来歴証明をまとめて守らなければ、きれいなコードでも汚れた配布物が出ます。

まずは台帳化と権限縮小、その次に来歴証明と審査ゲート、最後に実行基盤の分離と短命化を進めるのが現実的です。