この9か月で、私たちのPR処理速度は5倍に向上しました。静的解析や厳格なコードオーナーシップに基づくセキュリティツールは依然として有用ですが、この規模ではそれだけでは不十分です。Cursor Automationsを活用することで、コードベース内の脆弱性を継続的に特定して修復するセキュリティエージェント群を、すばやく構築できるようになりました。

本日、私たちが最も役立つと考えているセキュリティエージェントの設計をそのまま反映した、4つの新しい自動化テンプレートをリリースします。ほかのセキュリティチームもこれらのテンプレートをカスタマイズして、幅広いセキュリティIssueを自動的に解決するエージェントを構築できます。

#自動化のアーキテクチャ

エージェントがセキュリティのために役立つには、2つの機能が必要です。そのどちらも Cursor Automations が提供します。

1つ目は、Webhook の受信、GitHub の PR への応答、コードベースの変更の監視を行うための、すぐに使える統合です。これにより、バックグラウンドで動作するエージェントは、いつ動き出してアクションを取るべきかを把握できます。

2つ目は、充実したエージェント実行基盤と環境です。Automations は クラウドエージェント を基盤としており、クラウドエージェントが利用できるすべてのツール、スキル、オブザーバビリティを活用できます。

Automations をセキュリティ固有のユースケースでさらに強力にするために、私たちはセキュリティ MCP ツールを構築し、必要なときだけ利用でき、それ以外は動作しないサーバーレスの Lambda 関数としてデプロイしました。

参照コードを こちら で公開しているこの MCP は、3つの目的を果たします。

1. 永続データの保持。 エージェントは MCP を使ってデータを保存するため、セキュリティへの影響を長期的に追跡し、測定できます。私たちはそのデータを使って、自動化をいつどのようにトリガーするかを継続的に改善しています。

2. 重複排除。 私たちはあらゆる変更に対して複数のレビューエージェントを実行しており、その指摘は LLM によって生成されるため、異なるエージェントが同じ根本原因を別々の言葉で説明してしまうことがあります。重複した作業を避けるために、MCP によってエージェントは Gemini Flash 2.5 を利用した分類器を使い、表現は異なっていても2つの指摘が同じ問題を説明しているかどうかを判断できます。

3. 一貫した出力。 エージェントは見つけたすべての脆弱性を MCP 経由で報告し、MCP は統一フォーマットの Slack メッセージを送信するとともに、指摘の却下やスヌーズといった後続アクションも処理します。

この基盤が整ったことで、以下で詳しく説明する4つのセキュリティ自動化は、それぞれ独自のワークフローとトリガーロジックをその上に重ねています。私たちは Terraform を使って、セキュリティツールへのすべての変更が標準的なレビューおよびデプロイのプロセスを通るようにしています。

#エージェント型セキュリティレビュー

社内ではすでに、コード品質や一般的な Issue を確認するために Bugbot を使って PR をレビューしており、その中には一部のセキュリティ上の指摘も含まれていました。しかし、汎用のレビューツールはセキュリティ用途には理想的ではありません。というのも、私たち固有の脅威モデルに合わせてプロンプトを調整できず、また、一般的なコード品質の Issue すべてで止めることなく、セキュリティ上の指摘があった場合に限って CI をブロックできる必要があったからです。

そこで私たちは、エージェント型セキュリティレビューと呼ぶ専用の自動化を構築しました。最初は、その指摘をセキュリティチームが監視する非公開の Slack チャンネルに転送していました。

実際に有効な Issue を特定できているという確信が持てた段階で、PR へのコメントを有効にし、その後、ブロック用のゲートチェックを実装しました。直近 2 か月で、エージェント型セキュリティレビューは数千件の PR で実行され、数百件の Issue が本番環境に到達するのを防ぎました。

#Vuln Hunter

新しいコードに対するエージェント型セキュリティレビューの成功を受けて、既存のコードベースにもエージェントを向けました。Vuln Hunter は、コードを論理的なセグメントに分割し、それぞれについて脆弱性を探索する自動化です。私たちのチームは指摘をトリアージし、通常はそれらを修正します。その際、Slack の @Cursor を使って PR を生成することもよくあります。

#Anybump

依存関係へのパッチ適用は非常に時間がかかるため、多くのセキュリティチームは最終的に対応を断念し、エンジニアリング側に任せるようになります。すると、それはバックログに積まれたままになりがちです。そこで私たちは、そのほぼすべてを完全に自動化した Anybump という自動化を作りました。

Anybump は到達可能性分析を実行して、実際に影響のある脆弱性に絞り込みます。その後、関連するコードパスをたどり、テストを実行し、不具合が発生していないかを確認し、テストに通過すると PR を作成します。PR がマージされた後は、Cursor のカナリアデプロイパイプラインが、本番環境に到達する前の最後の安全ゲートとして機能します。

#Invariant Sentinel

Invariant Sentinel は毎日実行され、セキュリティおよびコンプライアンスに関する一連の要件に対するドリフトを監視します。リポジトリを論理的なセグメントに分割し、不変条件のリストに照らしてコードを検証するサブエージェントを立ち上げます。

分析後、エージェントは Automations のメモリ機能を使って、現在の状態を過去の実行結果と比較します。ドリフトを検出した場合は、正確性を確保するために再検証を行い、その後メモリを更新し、変更内容の説明と証拠となる具体的なコード箇所を含む Slack レポートをセキュリティチームに送信します。

この自動化はフルの開発環境で実行されるため、エージェントは自身の前提を検証するコードを作成して実行でき、従来の機能テスト、単体テスト、統合テストを補完します。

#今後もさらに自動化を拡大予定

セキュリティには自動化を適用できる機会が数多くあり、この4つは、私たちが進めていく取り組みのほんの始まりにすぎません。すでにこれらの適用範囲を、脆弱性レポートの受け付け、プライバシーコンプライアンスの監視、オンコールアラートのトリアージ、アクセス権のプロビジョニングにまで広げています。

いずれのケースでも、エージェントは、人手では実現できない規模での網羅性と一貫性をもたらします。