Autonomous Security
脆弱性は、
群れで狩る時代へ。
脆弱性診断は専門チームの手作業が前提でした。Cognitionが公開した「Security Swarm」は、複数の Devin エージェントを並列に動かして、検知・検証・修正PRまでを自動でつなぎます。ひとりの熟練者が一晩かけて追っていた欠陥を、群れが数十分で拾い上げる。診断は、体制ではなく台数で決まる時代に入りました。
Recap — これまで
診断は、いつも「人が足りない」ところから始まっていた。
脆弱性トリアージは長らく、少数精鋭のセキュリティエンジニアが、コードを一行ずつ読み、動作を頭で組み立てて発見する仕事でした。属人化と待ち時間の塊で、多くの現場が「診断は年1回、あとは祈る」に落ち着いていました。
典型的なプロダクトチームは、四半期ごとに外部診断ベンダーへ依頼し、レポートが返ってくるまで2〜4週間待ちます。指摘は数十件、優先度の判断はまた別の会議、修正PRの作成はプロダクト側、確認は再度ベンダー——という往復で、実際にコードが直るまで数ヶ月かかることも珍しくありません。
その間にも新機能はマージされ、依存ライブラリは更新され、攻撃面は日々広がります。守り手の数は増えない一方で、守るべき面積だけが膨らむ。これがセキュリティ人材難と呼ばれてきた不均衡の実体です。「もっと頻繁にスキャンすべき」だと誰もが知っていて、それでも回らないのは、単純に手が足りなかったからでした。
What Changed — 発表
群れが、コードを覗きにくる。
Cognition は、複数の Devin エージェントを並列に走らせて脆弱性を検知・検証・修正PR作成までつなぐ「Security Swarm」を発表しました。従来のように「一人の Devin が順に見ていく」のではなく、役割の違うエージェントが同時多発的にコードベースへ入り、疑わしい経路を洗い出しては sandbox で再現し、パッチをコミット、PR を起票します。人間のトリアージは、原則、通知が届いたあとの承認だけです。
Cognition の内部評価では、50 件の実世界 CVE のうち 36 件を発見、1 スキャンあたり約 $90 と、競合比でおよそ 3 割安い結果が報告されています。数字自体はまだ「万能検出器」の域ではありませんが、注目すべきは「頻度」の方です。$90 なら毎回のリリース、あるいは毎日回してもよい。単発の高精度診断ではなく、継続的な低精度診断を積み重ねる設計へと、費用対効果の分岐点が動きました。
How It Works — 工程
群れは、4つの局面を分業する。
Security Swarm の内部は、ロール別に分かれた Devin が非同期に協調しています。ひとつひとつは既存の Devin と同じ機能単位ですが、まとめると「小さなセキュリティ部門」に近い動きになります。
検知 — 経路を洗う
スキャナー役の Devin が静的解析と LLM 推論を組み合わせ、危険な入力経路・信頼境界・過剰権限を洗い出す。ここではノイズを許容し、疑わしい候補をとにかく列挙する段階。
検証 — sandbox で再現
候補ごとに検証役の Devin が起動し、実行環境を隔離した sandbox で PoC を組み立てる。再現できたものだけを「本物」として次の工程に渡すため、幻覚報告が絞られる。
修正 — PR を起票
修正役の Devin が該当箇所へパッチを当て、テストを差分実行し、根拠と再現手順を添えて PR を起票する。既存の PR フローに載るため、レビュー側は「もう一つの外部貢献者」を扱う要領で受けられる。
レビュー — 人が承認
人間の役割は、PR を読み、業務要件と照らしてマージするかを判断すること。トリアージそのものは不要になり、可否判断だけが残る。ここで初めて「セキュリティチームが本業に集中できる」形になる。
手で回すには多すぎ、
止めるには惜しすぎる脆弱性。
Who Feels It — 効き目
誰にとって、いちばん軽くなるか。
効果が大きいのは「守り手の数が足りていない」ところです。逆に、成熟した SOC を持つ大企業では、Swarm は既存の検出パイプラインを補強する副次的な位置づけに留まるでしょう。
薄いセキュリティチーム
兼任1〜2名で全社を見ている中規模企業。今まで「診断を頼む予算がない、けれど無視できない」だった層に、$90 スキャンは現実的な選択肢を差し出す。
DevSecOps 実装中
CI/CD に静的解析は入れたものの誤検知に埋もれているチーム。Swarm は sandbox 実証で「本物だけ」を通すので、開発者が読む PR の質が上がり、シフトレフトが息を吹き返す。
OSS メンテナ
本業の合間で守るのがつらい OSS プロジェクト。定期的に Swarm を回して、修正PRを直接受け取れれば、コミュニティのセキュリティ寿命が伸びる。上流の脆弱性が減れば下流の被害も減る。
Frontier — 次の風景
「自律型セキュリティ」は、体制図を作り直す。
エージェントの群れがコードを覗きにくるようになると、セキュリティの仕事はレポート読解から設計判断へと重心を移していきます。何を検知させ、何を承認するか、群れの手綱を握るポジションが要になります。
これまでのセキュリティ組織は「見つける人」と「直す人」に大きく分かれていました。Swarm 型の運用ではそのどちらも自動化され、残るのは「方針を決める人」と「境界を承認する人」です。役職名は変わらなくても、日々の作業は入れ替わっていくでしょう。
同時に、群れが動くほど「群れを止める理由」も重くなります。誤検知が業務を止める、修正PRが仕様を壊す、といった副作用は今後も残ります。だからこそ、Swarm の運用は自動化率を最大化する競争ではなく、信頼できる自動化率をどこまで押し上げられるかの調整になるはずです。守り手の数を増やせない現実に対して、群れは静かに、しかし確かに一つの答えを差し出しました。