OpenAIが報告した内容
OpenAIは11月4日、Linux kernelの脆弱性研究を行うprototype agent pipelineの結果を公開しました。同社によると、重複排除後のcandidate findingを2,308件生成し、1,724件の脆弱性を動的に再現し、948件のlocal privilege escalation exploitを作成しました。その後human researcherがoutputをreviewし、選別したfindingをcandidate patchとともにkernel maintainerおよびPatch the Planet partnerへ報告しました。
Pipelineは今後提供予定のcyber modelを用い、vulnerability discovery、dynamic validation、exploitability assessment、patch generationを実行し、最後にhuman reviewを行いました。OpenAIは、Scout agentがaudit対象をkernelの約7%に当たる約280万行、5,034 targetへ絞り、Analyst agentが12時間以内にcandidateを生成したと報告しています。10月のcampaign全体のAPI credit costは約121万ドルでした。
これらはOpenAIが公表した研究結果、cost、workflow上の観察であり、独立benchmarkでも、948件の別々のupstream fixが受理されたという主張でもありません。以下はIneezaの本番運用分析です。
成功した結果は割り当てた経路を証明しない
OpenAIは初期runについて、200件のexploit taskがroot shellを得た一方、human reviewにより20件は割り当てられた脆弱性ではなく、別のzero-dayを利用していたと説明しています。Terminal resultは本物でも、主張された因果説明は誤っていました。OpenAIはconstraintを強化し、各exploitが指定された脆弱性を使用したことを独立に確認するcheckを追加しました。
Ineezaの分析: 自律型researchの各結果にはsuccess flagだけでなく、因果関係を示すevidence bundleが必要です。Source commit、build configuration、VM image、seed、modelとharnessのversion、割り当てたfinding、実行input、sanitizer output、crash signature、権限遷移、生成patchを固定します。独立verifierが結果を再現し、指定された欠陥を無効化または修正すると観測経路が消えることを確認すべきです。生成agentを自身の証跡の唯一の判定者にしてはいけません。
ValidationはCapacity Planningの問題である
公表されたfunnelでは2,308件のcandidateが1,724件の再現結果へ、さらに948件のexploit結果へ絞られました。自動化後も、重複排除、severity判断、disclosure調整、patch review、regression test、maintainerの対応が必要です。そのためdiscovery throughputが、安全に処理するhuman systemの能力を上回り得ます。
Ineezaの分析: 各stageを明示的なadmission criteriaとservice-level objectiveを持つqueueとして扱います。Model confidenceだけでなく、到達可能なattack surface、影響configuration、再現性、越える権限境界、exploit reliability、patch readinessで優先順位を付けます。Subsystemごとのwork in progressを制限し、scan開始前にreviewer capacityを確保し、再現までの時間、duplicate率、evidence reject、patch acceptance、maintainer reworkを計測します。Finding数を最大化してreviewerを圧迫するpipelineは、防御価値を下げます。
FreshnessをEvidence Contractへ含める
OpenAIは、upstreamでの急速なpatch適用により一部findingが重複またはobsoleteになったと述べ、最新codeに対する再検証を推奨しています。変化の速いrepositoryでは、scanしたcommitで正しい結果でも、maintainerへ届く時点では修正済み、変更済み、または到達不能になっている可能性があります。
Ineezaの分析: 元のreproductionを保存した上で、履歴を書き換えずcurrent integration pointへvalidationをrebaseします。Findingが引き続き再現するか、同等の既存報告があるか、別変更で修正されたか、新しいbehaviorと競合するかを記録します。Disclosure前にminimal proof、関連regression test、patch評価を新しいsource snapshotで再実行します。Freshnessをevidence bundle内の署名付きfieldにし、古い結果が新規脆弱性として運用queueへ入らないようexpiryを設定すべきです。
Research Environment自体が本番Security Boundaryになる
Pipelineは意図的に動作するlocal privilege escalation exploitを生成し、OpenAIによると新しいexploitation techniqueも発見しました。TargetをVM内で動かしていても、orchestration、artifact、log、中間model contextはsensitiveになります。Isolationはtest対象kernelだけを囲めばよいものではありません。
Ineezaの分析: Production credentialを持たない使い捨てworker、default-denyのnetwork egress、task単位のartifact encryption、immutable audit log、proofとpatchのcontrolled promotion pathを使用します。Discover、exploit、verify、publishするagentを分離し、各stageの権限を狭くし、artifactがresearch boundaryを出る前にhuman approvalを必須にします。Escape、task間contamination、poisoned source tree、悪意あるcrash output、誤公開を第一級のincident scenarioとしてtestすべきです。
Ineezaの見解
重要なのはfrontier modelが数百件の動作するexploitを生成できることだけではありません。Discoveryが十分に低costになり、validation、causal attribution、disclosure、patch integrationが支配的なarchitectureになった点です。本番teamは自律型security pipelineをevidence systemとして設計すべきです。各結果を正確なtargetとexecution pathへ結び付け、独立に再現し、継続的にfreshnessを更新し、安全に隔離し、人とupstream maintainerが処理できるrateでadmitします。Findingが増えることに価値があるのは、pipelineがその正体を証明し、信頼できるfixへ進められる場合だけです。