GitLab CISOが示すAI時代のソフトウェア防御3つのレイヤー

私がGitLabに入社したのは、ソフトウェアの開発とセキュリティ確保のあり方が急速に変わりつつある時期でした。GitLab CEOのBill Staplesは先日、その変化をコードが量産できる時代の新たなボトルネックで論じています。コードがボトルネックでなくなれば、次に希少になるのは「信頼」。そして、その制約が最初に表れるのは本番環境に到達するものです。

同業のCISOと同じ種類の意思決定に責任を負う立場として、私の基本的な考え方はシンプルです。エージェント型ソフトウェア開発が信頼に足るものであり続けるには、計画から本番環境までの経路にセキュリティ、ガバナンス、ガードレールが組み込まれていなければなりません。リーダーに求められるのは、アタックサーフェス（攻撃対象領域）を常に把握し、実行を制約し、発見から検証済みの修正までのループをマシンスピードで閉じること。重要な指標はスキャンやチケット、レビューの件数ではなく、検出から検証済みの修正までにかかる時間です。

この指標は、攻撃の経済性が変わるにつれて重みを増しています。リスクそのものは、公開されたままのサーバー、権限範囲が広すぎる認証情報、露出したデプロイ経路など、目新しいものではありません。変わったのは、AIモデルによってこうした状態の発見、組み合わせ、悪用がより速く、より安価になったという点。私にとっては、未知のゼロデイ脆弱性よりもこちらのほうが不安です。脆弱性はもともと自社の環境に存在しており、それを見つけ出すことの難しさ自体が私たちを守っていたのですから。

AnthropicとOpenAIはいずれもこの変化について公に言及しており、今年私が話をしたセキュリティチームも、業界を問わず同じことを口にしていました。高度なモデルとエージェント型システムによって、弱点の発見と悪用に必要な時間とコストが圧縮されている、と。オープンウェイトモデルは現在利用可能な最も高性能なセキュリティシステムに急速に追いつきつつあります。つまり、少し前まで一部の研究機関の中にしかなかった能力が、はるかに多くの脅威アクターの手に渡ることになります。

この加速は、GitLabの内部でもはっきりと表れています。2026年はこれまでに317件のCVEを公開しており、2025年通年の181件、2024年の170件と比べて大幅な増加です。当社のバグバウンティプログラムに寄せられた報告も、直近90日間で3,600件強。2024年通年の1,440件を大きく上回る数字です。

業界全体で起きている同じ変化

GitLabが特殊なわけではありません。4月には、米国国立標準技術研究所（NIST）が、過去最多の処理件数を記録してもなお追いつかないと認め、大半のCVEについてエンリッチメント（付加情報の追加）を停止。今年のVerizonデータ侵害調査報告書（DBIR）でも、19回の発行で初めて、脆弱性の悪用が認証情報の悪用を上回って最も多い初期侵入経路となり、解決までの時間の中央値も32日から43日へと延びています。Forum of Incident Response and Security Teams（FIRST）もこの夏、同様の見解を示しました。

公開されるアドバイザリーと寄せられる報告は、それぞれ別のものを測っていますが、生み出す運用上のプレッシャーは同じです。重要なものを検証し、優先順位を付け、修正するチームの能力を上回るペースで、発見の件数が増え続けているのです。

重大度モデルが今も前提としているのは、個々の検出結果が単独で存在するという状況。ところがエージェントにかかれば、重大度の低い欠陥、過剰に広い権限、露出した経路をつなぎ合わせて深刻な攻撃に仕立てることも可能です。CVSSで並べ替えたキューはこうした文脈をますます見落とすようになり、その間にもバックログは、従来のツールやプロセスで処理できる速度を超えて膨らんでいきます。

攻撃の経済性が変われば、運用モデルも変わらなければなりません。セキュリティ管理は実行経路に組み込み、重要な検出結果にはすべて、修正までのループを閉じる仕組みを用意する必要があります。自社のガードレール、コンテキスト、ワークフローのもとでソフトウェア開発ライフサイクル（SDLC）全体を貫く、ガバナンスの効いた経路。それこそが、エンタープライズのソフトウェアファクトリーを支える基盤です。

エージェント型の能力は防御側に優位をもたらす

セキュリティチームは常に人手不足で、当社でも受け付ける報告の件数は2025年のおよそ6倍のペースで推移しています。それでも、高性能なモデルは、まず防御側に有利な形で計算式を変えてくれます。

防御側は、コード、インフラストラクチャ、デプロイ経路、設定、アイデンティティシステム、運用のコンテキストにアクセスできます。同じ能力を同じ対象に向ければ、防御側のほうがはるかに多くを見通せるはずです。ただし、それは自社のアタックサーフェスに対して先に使った場合に限っての話。モデルはこうした幅広いコンテキストを、マシンスピードでの発見、優先順位付け、修正へと転換できます。これはかつてなかったことです。

ビルドプロセスも可観測になりつつあります。長年、イシューに関する作業の多くはセキュリティチームが確認できるシステムに記録されておらず、レビューの対象は、残された差分、ビルド、実行中のアプリケーションに限られていました。

エージェントがソフトウェアを構築する場合、その構築過程はイベントストリームとして記録できます。ファイルの読み取り、ツール呼び出し、コマンド、発行された認証情報、アクセスされたシステム、付与された承認。この記録があれば、ソフトウェアがどのように構築されるかそのものを統制できるようになります。

このアーキテクチャ上の優位性が生まれるのは、エージェントの行動を識別、制約、記録できる環境でエージェントを実行している場合です。必要なインフラストラクチャさえ整えば、モデルの能力が向上するたびに防御システムも強化されていきます。

マシンスピードの防御には、3つのレイヤーが必要だと私は考えています。いずれも、SDLC全体でモデルの能力とコミット量が増すほど強くなるレイヤーです。

レイヤー1. 自社の現状を把握する

これは、以降のすべての取り組みの出発点となる発見のプロセスです。高度な攻撃者はすでに自社と同じモデルを手にしていると想定し、コード、インフラストラクチャ、デプロイ経路にわたる自社のアタックサーフェスに対して、先回りしてそれらのモデルを活用すべきです。目指すのは、現時点での自社の状況を、検証済みの形で把握すること。

最先端のAIラボは、新しいAIモデルの能力が攻撃と防御の両面で最初に現れる、能力向上の最前線に最も近い位置にいます。こうしたラボの貢献によって、実際のシステムに向けたモデル支援型の発見や、エージェントが作成した修正案をチームが承認する仕組みなど、業界全体が土台にできる防御態勢の水準が引き上げられます。その取り組みのひとつが、Anthropicとともに進めているProject Glasswing。同社のモデルを当社の重要なシステムと製品全体に適用し、より高性能なモデルが登場するたびに同じ検査を繰り返しています。

そのうえで、GitLab Duo Agent Platformを使って検出結果のトリアージと修正を継続的に行い、新たな問題の混入を抑え、本番環境の前に検証を終えたソフトウェアをリリースしています。ソフトウェア業界に求める基準を自ら最初に満たす「カスタマーゼロ」として、その成果を、お客様がGitLabプラットフォーム上で構築するものへの信頼につなげることを目指しています。

レイヤー2. 基盤を強化する

ベースラインがわかれば、自社の現在地が見えてきます。より難しいのは、コード量、エージェントの能力、攻撃者の能力が増し続けるなかで、その水準を維持することです。

そのための基盤は、6つの要件を満たす必要があります。

1. アタックサーフェス全体を把握し、継続的にスキャンする。 静的アプリケーションセキュリティテスト（SAST）、依存関係、コンテナ、シークレット、API、動的アプリケーションセキュリティテスト（DAST）を、ひとつのカバレッジモデルとして運用し、サードパーティ製スキャナーの結果も共通の脆弱性管理システムに集約しなければなりません。識別子、重大度、攻撃経路、担当者、修正状況がばらばらな部分的なインベントリからでは、組織としてリスクを正しく判断できません。
2. 露出したシークレットや長期間有効なシークレットをなくす。 シークレットの一元管理、最小権限、ローテーション、失効、シークレット検出を、ソフトウェアを作成・デプロイする経路のデフォルトにする必要があります。すべての認証情報に、明確なアイデンティティ、スコープ、有効期間、失効手順を定めなければなりません。
3. 脆弱性の発見を継続的な修正につなげる。 誤検出を排除し、実際の脆弱性をコンテキストに即して優先順位付けし、エージェントを使って修正の生成、テスト、検証を行います。提案された変更が、関連するコード、設定、デプロイ経路に対して有効だと証明されるまで、検出結果はオープンのままにしておきます。
4. ポリシーを実行経路に組み込む。 スキャン、承認、職務分離（SoD）、デプロイ管理は、作業が実行される場所で一元的に適用しなければなりません。どのポリシーが適用されるかを覚えておくことや、正しい引き継ぎ手順をたどることを、開発者やエージェントの責任にすることはできません。
5. エージェントを特権アクターとして扱う。 すべてのエージェントには、明示的なアイデンティティ、最小限の権限、制約されたツールと認証情報、承認されたアクセス経路、監査可能な行動が必要です。特に、エージェントの役割がコードの提案から、リポジトリ、CI/CDシステム、クラウドインフラストラクチャ、本番環境にまたがる実際の操作へと広がりつつある今、リスクの高い操作には、誰が承認したかを追跡できる承認の境界が欠かせません。
6. 検出から検証済みの修正までの時間を測定する。 実際の脆弱性が、検出されてから関連する環境で修正の有効性が証明されるまでの間、どれだけ露出したままだったかを追跡し、重大度と攻撃経路ごとに分類したうえで、その時間を継続的に短縮していきます。マシンスピードの攻撃に対抗するうえで、これが最も重要な運用指標になります。

これらの要件は互いに連動して機能します。検出結果の行き先を確保する継続的なカバレッジ、リリース時と同じ経路でテストされた修正、作業が実行される場所に置かれたポリシー、そして開発者のアクセストークンではなく独自のアイデンティティを持つエージェントです。

レイヤー3. リリース済みのソフトウェアを守る

ソフトウェアとその環境は、本番環境に移行した後も変化し続けます。先月リリースしたアーティファクトが、来月公開される脆弱性情報によって危険にさらされることもあるでしょう。悪用は数日以内に始まり、パッチが提供される前に起きることさえあります。

そのため、一度追いつけば終わりではありません。マージ後もスキャンを続け、より高性能なモデルが登場したら本番環境を再評価し、変更を生み出したのと同じ開発者ワークフローの中で修正を反映させます。目指すのは、すべてのマージを統制し、すべての修正を完了させることで、新たな検出結果がひとつ残らず修正へと向かう状態をつくること。

運用モデルとして求められるのは、既存のセキュリティ対策を確実に適用すること、検出から検証済みの修正までの時間を測定すること、そして顧客体験のチェックをセキュリティと同じビルド経路に組み込むことです。

同業のリーダーたちの声

サイバーセキュリティの専門家や同業のCISOたちも、開発のスピードに合わせてガバナンスと修正を実現するために、同様の運用アプローチを語っています。

「マシンスケールで発見しても、ガバナンスの効いた修正までの経路が同じくらい速くなければ、進歩とはいえません。それはセキュリティの体裁をまとったインベントリの問題にすぎないのです。エージェント型開発の時代に持ちこたえられるのは、検出を閉じたループの出発点として扱い、すべての変更にポリシーを適用し、ビルド経路の中で修正し、モデルの進化に合わせて再検証できるベースラインを持つ組織です」Cloud Security Alliance AI担当CISO-in-Residence　Gadi Evron氏

「エージェント型ソフトウェア開発に対応した持続可能なセキュリティプログラムは、すべてのエージェントを正しいレールの上で動かします。明示的なアイデンティティ、制約された権限、そして計画から本番環境までの承認された経路。そのレールの外で動くエージェントは無法状態で、アイデンティティも記録もなく、何に触れたのかを統制する手段もありません。モデルが進化し、エージェントの数が増えても、この規律は維持されなければなりません」Workday CISO　Bill Shields氏

「リリースするものへの信頼は、自社が土台とするモデルと開発プラットフォームの継続的な強化、そしてソフトウェアライフサイクルにおけるすべての変更のガバナンスにかかっています。これらのレイヤーは互いを補強し合うものであり、どちらか一方で他方を代替することはできません」Zscaler 最高セキュリティ責任者（CSO）　Sam Curry氏

シャドーソフトウェアファクトリーはアーキテクチャの問題

エージェントが生み出すコードの割合が増えるにつれ、SDLCは2つに分かれつつあります。ひとつは、ガバナンスの効いたリポジトリ、CI/CDシステム、アイデンティティ管理、承認、セキュリティツールを通る経路。もうひとつが、個人のノートPC、ローカルの認証情報、管理されていないツール、そうした管理の外にあるエージェントセッションを通るシャドー経路です。シャドー経路でも有効なコードは生まれるかもしれませんが、そのコードや関連するインフラストラクチャの変更がどのように行われたかについて、信頼できる記録は残りません。

コミットからわかるのは誰の認証情報が使われたかであり、変更の背後にあるエージェント、ツール、権限、コマンド、外部システムについてはほとんど何もわかりません。その証跡を残すには、アイデンティティ、権限、ツール、ポリシー、承認をつなぐ、ガバナンスの効いた実行環境が必要です。それがなければ、セキュリティチームは重要な操作がすでに行われた後で、成果物を調べるしかなくなるでしょう。

イベントを記録することは出発点にすぎず、エージェント型開発の規模になると、完全なトランスクリプトもまた新たなバックログになってしまいます。セキュリティシステムは、そうしたイベントを、適用可能なポリシー、責任の所在が明確な判断、検証済みの結果へと変換しなければなりません。重視すべき証拠はツール呼び出しであり、エージェント自身による推論の説明は二次的なもの。

実践ではどうなるのか

GitLabでは、こうしたアーキテクチャが具体的な形になりつつあります。ポリシーの組み込み先は、実行経路そのもの。スキャンは開発者やエージェントがすでに作業している場所で、修正コストが低く済む早い段階で実行されます。サードパーティの検出結果はひとつの脆弱性管理システムに集約され、エージェントは検証済みの検出結果を、修正に必要なアプリケーションのコンテキストを含むテスト済みのマージリクエストに変換します。シークレットはデフォルトで短期間のみ有効、スコープも限定され、いつでも失効可能。リスクの高いエージェントの操作は、誰が承認したかを追跡できる承認の境界で一旦停止します。「パイプラインで証明できないものは、リリースしない」。これが原則です。

コードを書く能力は柔軟に拡張できるようになりましたが、人間がレビューできる量には依然として限りがあります。最近のあるリリースでは、対象となる997件のマージリクエストのうち969件（97%）にエージェント型セキュリティレビューを実施しました。1年前には考えられなかった水準のカバレッジ。今では、これを当然と考えています。

GitLabはこうした管理機能をプラットフォーム全体で統合しており、GitLab Duo Agent Platformは、ソースコード、セキュリティ、CI/CD、マージと同じガバナンスの効いた経路の上で、エージェント型のトリアージと修正のループを完結させます。GitLabをご利用のお客様にとっての機会は、こうした管理を実行経路に組み込み、検出から検証済みの修正までの露出時間が短縮されているかを測定することにあります。

より本質的なアーキテクチャ上の問いは、エージェントによる作業が、ソフトウェアファクトリーを支える同じガバナンスの基盤を通っているかどうか。通っていれば、チームとエージェントは共通のコントロールプレーンを共有できます。通っていなければ、下流のパイプラインをどれだけ多くのセキュリティツールで囲んでも、シャドーソフトウェアファクトリーはなくなりません。

運用モデルを具体化する

信頼できるプログラムであれば、次の問いに運用データから答えられるはずです。

• アタックサーフェスの全体像はどうなっているか、それぞれの領域が最後にスキャンされたのはいつか
• どの検出結果が本物で、どれが誤検出か、その判断を下したのは誰（または何）か
• 実際の検出結果はそれぞれ、関連する環境で修正が検証されるまでどれだけの期間露出していたか
• どのシークレットが、誰（または何）に、どのスコープで、どれだけの期間発行され、どのように失効されたか
• 各操作を実行したのはどのエージェントか、どの承認済み経路を通り、どのツールと権限を使ったか
• どのポリシー、承認、職務分離チェック、デプロイ管理がその操作を停止または許可したか
• 第三者のレビュー担当者が証拠を再現し、同じ結論に至るか

理想は、こうした問いへの答えがますます自動的に得られるようになること。うまく機能しているプログラムでは、アタックサーフェス全体で継続的なカバレッジが保たれ、重要な検出結果にはすべて、責任を負う担当者とテスト済みの修正経路が紐づいています。露出したシークレットや長期間有効なシークレットはなくすか、正当性を説明できる補完的な管理策とともに期間を限定しています。エージェントが動くのは、承認されたアイデンティティと制約された権限のもと。リスクの高い操作には承認の記録が残ります。そして、検出から検証済みの修正までの時間を重大度別、攻撃経路別に継続的に測定し、マシンスピードに近づけていきます。

何が必要なのか、私たち自身もこのモデルを実践しながら学んでいる最中。今後数か月のうちに、GitLabはこれらの原則を運用ガイダンスに落とし込み、ベースラインを確立するための管理策、アーキテクチャ、指標、プラクティスをまとめたブループリントを公開する予定です。このブループリントは、エージェント型ソフトウェア開発をガバナンスの効いた経路にとどめ、シャドー経路での本番作業をなくし、検出結果を継続的に検証済みの修正へと進めていくための一助となることを目指しています。

目標は実践的なものです。セキュリティとエンジニアリングのリーダーが、どこから始めるにせよ、実装して測定できるものを提供することにあります。

変化したセキュリティの基準

私はこの記事を、皆さんと同じ種類の意思決定に責任を負う同業者として書いています。コード生成が潤沢になり、信頼が希少になった今、エージェント型ソフトウェア開発にはマシンスピードでの検証と修正が求められます。求められるのは、セキュリティ、ガバナンス、ガードレールを、基盤を取り囲むゲートの集まりとしてではなく、基盤そのものの一部として組み込むこと。

攻撃能力を高めているのと同じモデルが防御能力を広げることもできるという意味で、今はまたとない好機でもあります。サイバーセキュリティに携わる私たちは、攻撃者よりも多くのコンテキストと、自社システムへのより深いアクセス権を持ち、ソフトウェアの構築過程そのものを可観測にし、統制可能にするチャンスも手にしています。この優位性を、生かさない手はないでしょう。

自社が土台とするプラットフォームには、継続的な強化を求めてください。何を発見したのか、どれだけ速く修正したのか、次にモデルの能力が向上したときにも管理策が有効であり続けるのか。その証拠を示すよう求めるべきです。そして、自社のソフトウェア開発にも同じ基準を当てはめてください。GitLabをご利用のお客様は、Duo Agent Platformを使うことで、ソースコード管理、CI/CD、その他のSDLCと同じガバナンスの効いた経路にエージェント型のトリアージと修正を取り込めます。

これからの新たな基準は、「検出から検証済みの修正まで」をマシンスピードで進めることです。

10月6日にライブ配信されるTranscendにぜひご参加ください。このテーマをさらに掘り下げるとともに、エージェント型ソフトウェア開発の安全性確保を支援する最新のイノベーションをご紹介します。