Blockはセキュリティ修正案を18分で作成。デプロイの判断は人間が握る

OpenAIが公開した事例紹介によると、BlockはOpenAI Daybreakなどを使い、セキュリティalertの調査、証拠の関連付け、修正案の作成を進めている。最近のred team演習では、概要レベルの脆弱性を入力してから自動patch案が出るまで18分だった。これは本番環境への自動デプロイを意味しない。

7か月分のテレメトリを1時間未満で再検証する

チームは各調査の元のqueryと証拠を保存している。そのため、検知ルールの変更案を7か月分の本番テレメトリに対して1時間未満で再実行できる。以前は数百件の過去事例に手作業でqueryをかけ直す必要があり、時間がかかるため実施されないことも多かったという。

Blockは、triageの処理量が50％増え、情報収集と調査も50％増えたと報告する。自動調査は四半期あたり約1,100 analyst-hoursに相当する。誤検知の手動triageを減らしたことで、さらに四半期あたり約600時間が戻ったとしている。

agentが変えるのは精査のコストであり責任の所在ではない

速度そのものより重要なのは、検証の採算が変わることだ。過去事例を1時間で再確認できれば、深い分析を少数のalertだけに限定する必要がない。システムは各alertを詳しく調べ、孤立した通知の列ではなく、関連付けた証拠を人間へ渡せる。

セキュリティチームには実務上の条件も生まれる。agentには、保存された証拠、明確なcode owner、人間のreviewへ渡す経路が必要だ。これらがなければ、提案を速く量産するだけになる。揃っていれば、時間不足で省かれていた精査を現実的なコストにできる。

顧客が示した数字は提案までを測り、本番修正までは測らない

結果はOpenAIが顧客事例として公開したもので、独立したbenchmarkではない。元データもanalyst-hoursの算出方法も示されていない。18分という計測もpatch案が出た時点で終わる。Blockのチームはその後も悪用可能性を確認し、修正を検証し、人間がデプロイを指揮する。

約2時間でSQL injectionから権限昇格、別システムへの移動まで攻撃経路を組み立てたred team事例も同様に読むべきだ。強い社内結果ではあるが、別の環境におけるDaybreakの性能を一律に示す数字ではない。

回帰とreviewerの介入回数が成果を決める

次に必要なのは、patchの却下率、見逃した脆弱性の数、デプロイ前に人間が介入した頻度だ。長期的な結果が出て初めて、処理量の増加が防御を改善したのか、review対象を増やしただけなのか判断できる。

他社へ移せるかどうかも重要だ。Blockは自社のテレメトリ、内部benchmark、複数モデルへ作業を振り分けるsecurity harnessを土台にしている。promptを一つコピーしても、この運用は再現できない。

Lilithの判定

18分でできたpatchも、reviewerが欠陥を見つけて本番への入口を閉じればそこで止まる。Blockがデプロイボタンの最後の指を人間に残した判断は正しい。