Trail of Bits、1PasswordのAIパッチングベンチマークは防御側を誤らせると指摘
Trail of Bitsは、1PasswordのAIパッチングベンチマークの公開から6週間後、その見出しとなった26%のクリーン修正率は誤解を招くと異議を唱えた。
この論争は、単にAIが安全なコードを書けるかどうかを巡るものではない。エージェントに不適切な指示、制限されたツール、不整合な採点が与えられた場合、ベンチマークが何を測定しているのかという問題に関わる。
1PasswordのOff-by-1 Labsは、6件の難易度が高い脆弱性を対象に6,080件のパッチをテストした。その報告書では、アプリケーションの挙動を実質的に変えずに脆弱性を完全修正したものは26%だった。
さらに20.1%は、挙動を変更しながら報告された脆弱性を修正した。残る53.9%は問題を修正できなかったか、別の脆弱性を導入したか、あるいはその両方だった。
Trail of Bitsは、これらの失敗が無害だとは主張していない。むしろ同社の研究者は、集計結果が本質的に異なるパッチング作業を表す実験条件を混在させていると論じている。
同社によれば、データセットの22%はエージェントを誤った修正へ導くプロンプトから得られた。さらに36%は、エージェントがコードをコンパイルまたはテストできなかった試行によるものだという。
Trail of Bitsは批判と同時に、2つのエージェントスキルも公開した。1つは元のバグ、関連するバリエーション、リグレッションに対してパッチを検証する。もう1つは、エンジニア向けの対話型レビューガイドを作成する。
この対応は、ベンチマークを巡る意見の相違を、AI支援セキュリティに関するより大きな論点へと転換する。中心的な問いは、チームがエージェントを孤立したパッチ生成器として評価すべきか、それとも検証されたエンジニアリングプロセスの参加者として評価すべきかだ。
1PasswordのAIパッチングベンチマークは大きく異なる実験を統合していた
Trail of Bitsは、26%という結果は通常の開発ツールを用いる典型的なエージェントではなく、混在した実験を表していると主張している。
Off-by-1 Labsは2026年8月6日、FLAWED研究を公開した。FLAWEDはFix-Like Artifacts With Embedded Defectsの略称だ。
この研究は、最近開示された6件の脆弱性について、ChatGPT-5.5とOpus 4.8を検証した。対象にはLinux、ActiveMQ、Chrome、Exim、Spring AI、Gemini CLIが含まれた。
研究者らは、アップストリームの修正が複数のファイル、関数、またはコードパスにまたがる脆弱性を選定した。また、最近の脆弱性を選ぶことで、モデルが完成済みのパッチを記憶している可能性も低減した。
この設計には正当な目的があった。難しく未知の脆弱性は、一般的なコーディングベンチマークでは見えにくい不完全な推論を明らかにできる。
しかし同時に、読者が平均値を広く適用できる範囲も制限する。Trail of Bitsの分析によると、クリーン修正率は6つの対象で3%から60%まで幅があった。
したがって、6対象の平均値は対象選定に大きく依存する。日常的なパッチ、より単純な脆弱性、あるいは代表的なソフトウェアバックログにおける失敗率を確立することはできない。
実験では、エージェントの作業方法も変化させた。ワンショット実行ではシェルアクセスを認めず、モデルが影響を受けるソフトウェアをビルドまたは実行することも禁じた。
反復実行では再現スクリプトを提供し、複数回の試行を許可した。探索的実行では開発アクセスを提供した一方、エージェント自身に作業の検証方法を判断させた。
これらのモードは異なる問いに答える。ワンショット応答は、厳しい制約下でのコード生成を測る。反復型エージェントは、実行可能なフィードバックを用いたパッチングを測る。
両者を単一の見出しにまとめると、この違いが見えなくなる。コンパイルへのアクセスがないパッチングエージェントは、人間の開発者が基本的なエンジニアリング実践とみなすフィードバックループを利用できない。
Trail of Bitsによれば、テストなしモードは報告データの36%を占めた。この割合は、ツール制限が全体結果の主要な入力要因であることを示す。
プロンプトの構成も別の差異を加えた。FLAWED研究では、誤った、または不完全なガイダンスを含むプロンプトを含め、脆弱性ごとに9つの構造化プロンプトテンプレートを用いた。
モデルが不適切な助言に抵抗できるかをテストすることには価値がある。自動化バイアスを明らかにし、エージェントが誤った診断にどれほど容易に従うかを示せるためだ。
ただしTrail of Bitsによると、2つのプロンプトはエージェントに明示的に誤った修正を指示していた。これらのプロンプトはデータセットの22%を占めた。
自律的なパッチングを評価する組織にとって、この失敗モードは重要だろう。一方、正確な脆弱性報告書を用いてエージェントを評価する開発者が置かれる状況は異なる。
そのため争点は、実験の存在自体ではなく集計にある。Trail of Bitsは、誤解を招くプロンプトを通常の修正試行とは分けて報告すべきだと考えている。
同社の再分析では、エージェントがコードを実行でき、誤った修正へ誘導されなかった試行を残した。また、アップストリームのパッチを参照したと判定された試行を除外した。
その条件下で、3,067件のパッチのうち2,634件が提供されたエクスプロイトを阻止した。これはフィルタリング後の試行の86%に相当する。
1つのエクスプロイトを阻止できたからといって、完全なセキュリティ修正が成立するわけではない。Trail of Bitsもこの限界を明確に認めている。
狭いガードは、提供された入力を阻止できても、別の経路から根本的な弱点に到達できる状態を残す可能性がある。86%という結果は即時のエクスプロイト阻止を測るものであり、クリーンな是正を測るものではない。
それでも、フィルタリング後の結果は、実験条件が重要である理由を示している。同じデータセットでも、悲観的なクリーン修正率の見出しと、より楽観的なエクスプロイト阻止結果を支えることができる。
どちらの割合も、それだけでAIエージェントが信頼できるパッチ作成者かどうかを決めるものではない。両者を合わせると、ベンチマークのラベルはテストしたワークフローを正確に記述しなければならないことが分かる。
プロンプト設計とテストへのアクセスが答えを変える理由
このベンチマーク論争は、エージェント評価の基本原則を浮き彫りにしている。すなわち、作業条件も測定対象システムの一部である。
コーディングエージェントは、単なる言語モデルではない。指示、ツール、実行環境、コンテキスト、停止ルール、検証プロセスも含まれる。
どの要素を変えても結果は変わりうる。再現手順を実行できるモデルは、静的なテキストから一度だけ応答するモデルには得られない証拠を受け取る。
元のFLAWED報告書は、3つの運用モードを説明している。それぞれは、隔離、反復、エージェントの自律性の異なるバランスを表す。
ワンショットモードでは、シェルとインターネットへのアクセスを禁じた。モデルには、1回の応答で完全なパッチを作成するよう求めた。
この設定は、アクセスが大きく制限された環境を表すことができる。しかし、コンパイル、テスト、サニタイザー、デバッグ、検査コマンドが修正ループから除かれる。
反復モードでは、再現スクリプトを提供し、複数回の試行を許可した。エージェントはメモリファイルを通じ、以前の実行からのフィードバックを利用できた。
探索モードでは、あらかじめ用意された再現手順をモデルに与えず、同様のアクセスを許可した。エージェントは完了を報告する前に、自ら検証経路を選ばなければならなかった。
これらのモードの違いは利便性だけではない。テストする能力が異なる。
ワンショット生成は、モデルがソースコードと文章から完全な修正を推論できるかを問う。反復パッチングは、実行を通じて失敗を診断し改善できるかを問う。
探索的パッチングには、さらに別の負担が加わる。エージェントは、タスクの一部として証拠を受け取るのではなく、自身の変更が機能する証拠を構築しなければならない。
Trail of Bitsは、ベンチマークはこうした条件の影響を開示すべきだと主張する。それらの合算平均を、一般的な能力スコアとして扱うべきではない。
プロンプトの品質も同様の問題を生む。セキュリティ報告書には、エクスプロイト、推定される根本原因、影響を受けるパス、緩和策のガイダンスが含まれることが多い。
これらの入力は不完全だったり誤っていたりする可能性がある。各条件下でのモデルの挙動を測定すれば、チームはより安全なワークフローを設計しやすくなる。
しかし、意図的に誤ったガイダンスは、敵対的または誤認に基づくタスク設定を表す。通常のAIパッチングを表す数値に、目立たない形で影響させるべきではない。
有用な報告書なら、正確なガイダンス、不完全なガイダンス、誤ったガイダンス、誘導なしの探索について、クリーン修正率をそれぞれ示すだろう。読者はその結果を自らの環境に対応付けられる。
推論設定は3つ目の変数を生む。実験では、各モデルのデフォルトに従い、ChatGPT-5.5を中程度の推論努力、Opus 4.8を高い推論努力で実行した。
Trail of Bitsは、どちらのモデルも利用可能な最高設定を使っていなかったと指摘する。また実験は、推論努力が修正品質に与える影響を切り分けていない。
この欠落は、観測されたパッチを無効にするものではない。ただし、各モデルが到達可能な性能についての主張は制限される。
モデルに不均等な設定が与えられる場合、この問題はより重要になる。そうでなければ読者は、差異を設定の効果ではなくモデル能力として解釈してしまう可能性がある。
採点はさらに別の層を加える。FLAWEDは、他方のモデルによるクロスレビューを含め、パッチの評価にモデルを使用した。
Trail of Bitsによると、モデルによる採点は、レビュー済み事例における完全な5分類の結果で、人間のレビュー担当者と65.9%一致した。
レビュー担当者が元の脆弱性が修正されたかだけを問う場合、一致率は87.7%に上昇した。新たなバグが現れたかについては70.5%まで低下した。
Trail of Bitsの報告によれば、2つのモデル採点者は同じパッチの36.8%に異なる結果を割り当てた。これらの判断を平均しても、その不一致は解消されない。
これは、クリーン修正のステータスが複数の判定を組み合わせるため重要だ。採点者は、古い脆弱性が残っているか、挙動が変わったか、別の弱点が現れたかを判断しなければならない。
正しいパッチであっても、採点者が意図された挙動変更をリグレッションとして扱えば不利なラベルを受けることがある。不完全なパッチは、テストが別の脆弱な経路を見落とせば合格する可能性がある。
Trail of Bitsは、ActiveMQの判定の8%が意図された変更をリグレッションとして減点したと述べている。また、Chromiumの採点経路が不完全なuse-after-free修正を受け入れた可能性があるとも指摘している。
この批判はさらに、off-by-one脆弱性を含むLinuxの参照パッチについて言及している。モデルは生成された248件のパッチでその誤りを繰り返した一方、自動採点者が検出したのは24件だった。
これらの主張はTrail of Bitsの再分析に基づくものであり、現在進行中の方法論上の論争の一部である。Off-by-1 Labsが記録した失敗パッチを消し去るものではない。
これらは、AIベンチマークが自らの評価器も検証する必要がある理由を示している。採点パイプラインも、パッチングパイプラインと同様に偽陽性と偽陰性を導入しうる。
本当の争点はAIによるパッチ生成と検証済み修正の対比にある
1Passwordは生成されたパッチがどの程度クリーンと認定されるかを測定する一方、Trail of Bitsは提案を受け入れられる修正へと変えるエンジニアリングプロセスを重視している。
元の1Passwordの調査結果には重要な警告がある。もっともらしいコードは、脆弱性の根本原因を解決せずに概念実証を阻止できてしまう。
Off-by-1 Labsは、成功として分類されたパッチの3分の1超に、セキュリティ上脆弱な要素が含まれていたとした。これらのパッチは完全な是正ではなく、狭いチェックに依存していた。
Spring AIは有用な例を示した。モデルは、根本にある式言語の露出に対処するのではなく、提供された悪意のある入力の文字をエスケープすることが多かった。
このようなパッチは、1つのペイロードを防げても、代替入力を利用可能なまま残しうる。その結果、1つのテストに対する機能的成功が誤った安心感を生む。
Trail of Bitsはこの教訓を否定していない。同社の新しい検証スキルも、同じ失敗に至る第2の経路を要求することで、同様の懸念を組み込んでいる。
この意見の食い違いは、生成前後に何が起きるかに関するものだ。ベンチマークは生のモデル出力を評価することも、エージェント支援による開発プロセスを評価することもできる。
この分析単位の違いは、異なる結論を生む。生の生成結果はモデルの失敗モードを明らかにする。完成したワークフローは、エンジニアがエージェント支援によって正しい結果に到達できるかを測る。
Trail of Bitsは、Patch the Planetイニシアチブを通じて後者の見方を支持している。エンジニアはエージェントに指示を与え、その作業をレビューし、オープンソースのメンテナーにパッチを提出した。
同社は、9月14日までにメンテナーがマージまたはクローズした186件の公開プルリクエストを調査した。メンテナーは126件をマージし、受け入れ率は67.7%となった。
マージされた提出のうち91件は、セキュリティに関連する修正が確認されないまま、当初提案されたセキュリティ修正が維持された。さらに33件は、受け入れ前にセキュリティ関連の変更を受けた。
この数字は正しさを証明するものではない。メンテナーが欠陥のあるコードをマージする可能性もあり、公開レビューの結果から後に発生するすべての回帰を把握できるわけでもない。
Trail of Bitsもこの限界を認めている。同社は受け入れを、完全なセキュリティの証明ではなく、実用的な有用性と修正負荷に関する証拠として提示している。
同社はまた、Patch the Planetの対象プロジェクトで後続する約33,500件のコミットをレビューした。自社のパッチが導入した問題を修正する変更を探した。
この調査では、少なくとも10件の機能バグ、4件のビルド・テスト・リリース自動化に関するバグ、そして1件の性能問題が見つかった。悪用可能なセキュリティ脆弱性は報告されなかった。
脆弱性が発見されなかったことは、脆弱性が存在しない証明ではない。Trail of Bitsは、より広範なレビューを継続中だとしている。
ある事例は、人間対エージェントという枠組みが誤解を招きうる理由を示している。エージェントは、freenginxの組み込みPerlモジュールにあるメモリ安全性の問題に対するパッチを提案した。
このパッチは脆弱な経路を1つ残し、さらにクリーンアップ時のクラッシュを導入した。Off-by-1 Labsはこれを正しく批判した。
メンテナーは、脆弱な3つの経路すべてをカバーする別の修正を作成した。この人間が作成した変更にも、同じクリーンアップ時のクラッシュが導入された。
両者ともコールバックをより長く保持し、リクエストが使用不能になった後で解放した。クリーンアップでは、無効なリクエストにアクセスするPerlコードが実行される可能性があった。
この例は、人とエージェントの能力が同等であることを示すものではない。両者とも、目先の悪用経路の外側にある影響を見落としうることを示している。
Trail of Bitsはこの事例を自社のコンサルティング記録と比較した。2024年から2026年に実施した236件のセキュリティ評価で見つかった2,265件の脆弱性について、最初の修正をレビューした。
開発者は最初の試行で283件の問題を完全には解決できなかった。これは12.5%に相当し、報告された95%信頼区間は10.5%から14.5%だった。
これらの開発者は自社ソフトウェアを理解しており、詳細な脆弱性レポートを受け取っていた。また、Trail of Bitsが変更をレビューすることも認識していた。
この比較は依然として完全ではない。人間の開発者とベンチマークのエージェントは、同一条件下で同一のタスクを解いたわけではない。
それでも、このデータは人間によるパッチが自動的に正しいとする非現実的な基準に疑問を投げかける。セキュリティ修正は常に、レビュー、テスト、改訂に依存してきた。
この文脈は実務上の問いを変える。チームに必要なのは、最初のパッチが絶対に誤らないエージェントではない。
許容可能な限度を超えて残存リスクを増やすことなく、エージェントがスループットを改善するという証拠が必要だ。それを測定するには、比較可能なチーム、タスク、検証ゲートが求められる。
Trail of Bitsのパッチ適用イニシアチブは、このワークフロー中心の見方を反映している。エージェントが生成と調査を担う一方で、エンジニアとメンテナーが受け入れの責任を持ち続ける。
1Passwordのレポートは別の懸念を反映している。高速な生成は、完成しているように見えても微妙な欠陥を含むパッチで、レビュー担当者を圧倒する可能性がある。
両方の懸念は成り立ちうる。エージェント支援は修正可能な脆弱性の数を増やしうる一方、強力な検証の重要性も高める。
2つのエージェントスキルが批判を検証可能なワークフローへ変える
Trail of Bitsは、データをより好意的に解釈するだけでなく、運用上の統制によってベンチマークに応答している。
同社は、提出前にセキュリティ修正を検証するpost-patch-validationを公開した。これは脆弱性レポートと、脆弱なコードおよびパッチ適用済みコードのリビジョンを受け取る。
最初のタスクは、元のバグを再現することだ。このスキルは、脆弱なコードでは失敗し、パッチ適用後には成功するチェックを要求する。
この条件は、よくあるテストの誤りを防ぐ。両方のリビジョンで成功するテストでは、その変更が脆弱性を除去したことを示せない。
2つ目のタスクは、同じ失敗につながる別経路を対象とする。その経路は、元の概念実証を繰り返すのではなく、根本原因に従うべきだ。
たとえば、エージェントは別の呼び出し元、代替入力、エラー経路、またはクリーンアップ手順を調査できる。freenginxのクラッシュは、クリーンアップに注意を払うべき理由を示している。
3つ目のタスクでは、変更されたコード周辺の回帰と新たな脆弱性を確認する。両リビジョンで安定して維持されるべき動作を比較する。
検証計画には、より広範な証拠も含めなければならない。Trail of Bitsは、プロジェクトテスト、サニタイザーチェック、または範囲を限定したファジングを候補として挙げている。
サニタイザーは、無効なメモリアクセスなどの実行時エラーの種類を検出する。範囲を限定したファジングは、定義された時間または範囲の中で生成入力を探索する。
4つ目のタスクでは、インフラ障害を結論不能として扱う。ビルドの失敗や依存関係の欠落は、脆弱性が再現された証拠にはならない。
このルールは当然に聞こえるが、自動化パイプラインでは実行エラーが合格・不合格のラベルにまとめられがちだ。無効な証拠を切り分けることが、最終判断を守る。
このスキルは、メンテナー向けにチェックと結果を保存する。これにより、レビュー担当者に文章上の保証を信頼するよう求めるのではなく、エージェントの結論を検査可能にする。
2つ目のリリースであるreview-walkthroughは、ワークフローの人間側に対応する。完成したブランチのdiffを、対話的で順序付けられたレビューへ変換する。
変更は生のファイル順ではなく、論理的な閲覧順で表示される。指摘は関連するコードの横に配置され、エンジニアが確認して対応できる。
このウォークスルーはGitHubレビューの準備を支援できるが、提出するコメントの責任はレビュー担当者に残る。この境界は説明責任にとって重要だ。
両ツールは、公開されているsecurity skills repositoryから利用できる。これらは、バリアント分析、プロパティベーステスト、ミューテーションテストの既存スキルに加わる。
バリアント分析は、コードベース全体で欠陥に関連する事例を探す。プロパティベーステストは、少数の手作業で選んだケースではなく、生成入力全体にわたって動作を確認する。
ミューテーションテストは、テストスイートが誤った動作を検出できるかを確認するため、意図的にコードを改変する。生き残ったミューテーションは、欠落したアサーションや弱いカバレッジを露呈させる可能性がある。
これらの技術は組み合わさって、検証のはしごを作る。再現テストは報告されたエクスプロイトを確認し、バリアントテストはパッチの根本原因に対するカバレッジを試す。
回帰テストは意図された動作を保護する。サニタイザーとファザーは、想定例を超える失敗を探す。
その後、ミューテーションテストは、それらのテストが意味のあるエラーを検出できるかを評価する。人間によるレビューは、設計、保守性、自動化カバレッジの外側にあるリスクを評価する。
このワークフローは安全なパッチを保証しない。有限のテストスイートで、あらゆる脆弱性が存在しないことを立証することはできない。
しかし、より強い判断を支える成果物は作り出せる。レビュー担当者は、以前に何が失敗し、現在何が成功し、どの経路が未テストのままなのかを確認できる。
これがTrail of Bitsの応答における最も強い部分だ。同社は方法論上の異議を、他チームが評価できる実践へ変換している。
これらのスキルは、批判の潜在的な弱点も示している。その価値は、合理的な手順を組み込んでいるからといって前提にされるのではなく、測定されなければならない。
post-patch-validationは、ブログ投稿で分析されたPatch the Planetの作業には使われていなかった。したがって、欠陥率への影響は依然として不明だ。
チームは、既知の不完全な修正、新たに埋め込まれた回帰、提供された概念実証の範囲外にある欠陥を検出できるかをテストすべきだ。
誤警報とレビュー時間も測定すべきである。過剰なノイズを生む検証ツールは、成果を改善せずにボトルネックを移動させる可能性がある。
同じ基準はreview-walkthroughにも当てはまる。より良い提示は理解を促進できるが、説明が誤っていれば不当な確信を生み出すこともある。
対話的な説明は検査を支援すべきであり、それに取って代わるべきではない。レビュー担当者には依然として、完全なdiff、テスト、ビルド出力、プロジェクトの文脈へのアクセスが必要だ。
Trail of Bitsは反証可能な方向性を確立した。次の段階は、各スキルがパッチ品質とレビュー効率をどの程度改善するかを示す比較証拠である。
セキュリティチームが次に注視すべきこと
この論争は、より魅力的な見出しの割合を選ぶことではなく、統制された比較と再現可能な成果物によって決着する。
最初の兆候は、1Passwordまたは独立した研究者が条件別に分けた結果を公表するかどうかだ。読者には、プロンプト品質、ツールへのアクセス、運用モード、推論努力ごとに分類された結果が必要である。
その分析により、現実的な開発条件下でも26%のクリーンフィックス率が低いままなのかが分かる。また、どの制約が最も大きな低下を引き起こすかも明らかになる。
6つの対象は大きく異なっていたため、脆弱性ごとの結果も重要だ。平均値は、エージェントが特定の言語、アーキテクチャ、脆弱性クラスで苦戦しているかを隠しうる。
研究者は、エクスプロイトの阻止と根本原因の修正の両方を報告すべきだ。前者は即時的な有用性を測り、後者は修正の完全性を測る。
2つ目の兆候は、異議のある評価に対する専門家による再現検証だ。レビュー担当者は、公開された基準の下で同一のパッチを調べ、判断がどこで分かれるのかを記録すべきである。
その作業には、Linuxのoff-by-one事例、Chromiumのコールバック経路、Trail of Bitsが特定したActiveMQの動作変更を含めるべきだ。
広範な採点ミスを確認する再現検証は、ベンチマークの見出し数値を弱める。元のラベルとの強い一致は、Trail of Bitsの批判を弱める。
3つ目の兆候は、2つの新スキルに対する統制された評価である。エージェントは、検証ワークフローあり・なしで同じ脆弱性にパッチを適用すべきだ。
比較では、クリーンフィックス、未解決のバリアント、導入された回帰、レビュー担当者の時間、受け入れ前に必要となった改訂を測定すべきである。
また、比較可能な条件下で人間のみのチームとエージェント支援チームも含めるべきだ。この基準線がなければ、開発者の代替や上回る能力に関する主張は裏付けられない。
組織は、あらゆる研究を待たずに方針を定められる。すでにパッチ生成とパッチ承認を分離できる。
AIが作成したパッチは、見慣れないコントリビューターによる変更と同じレビューシステムに入れるべきだ。その出所は信頼を与える理由にも、自動的な却下を引き起こす理由にもならない。
チームは、脆弱性レポート、再現手順、エージェントのトランスクリプト、パッチ、検証コマンド、結果を保存すべきだ。これらの成果物により、失敗の診断と後続の監査が可能になる。
承認前には根本原因の説明を要求すべきだ。提供されたペイロードをフィルタリングするだけのパッチには、より慎重な検証が必要である。
高リスクな変更には、認証、メモリ安全性、暗号技術、パーサー、アクセス制御、ライフサイクルのクリーンアップ周辺で、より広範なチェックが必要となる。これらの領域は狭い修正を許容しない。
社内レビューシステムを構築する組織は、過去の脆弱性、却下されたパッチ、繰り返される失敗パターンに対応する、検索可能なエンジニアリングナレッジベースも維持できる。
その記録は、レビュアーがリポジトリをまたいで繰り返されるミスを特定する助けになります。また、一見単純に見える修正案がなぜ却下されたのかを残すこともできます。
1PasswordのAIパッチ適用ベンチマークを、「エージェントは4分の3の確率で失敗する」という主張に矮小化すべきではありません。そのデータは、実際に重大な影響をもたらす修復失敗を記録しています。
Trail of Bitsの批評も、「エージェントは86%の確率で成功する」という主張に矮小化すべきではありません。提供されたエクスプロイトを阻止することは、安全な修復を完了することよりも弱い基準です。
有用な結論は、この二つの数字の間にあります。AIエージェントは価値あるパッチを生み出せますが、そのパッチが何を意味するかは、ベンチマークの設計と検証によって決まります。
セキュリティリーダーにとって、直ちに取るべき行動は具体的です。すべてのパッチ適用指標の前提条件を監査し、実際に利用するワークフローの中でエージェントをテストしてください。
エージェントがコンパイル、再現、派生ケースの探索、回帰の検出を行えたかを確認してください。次に、見た目が整ったdiffを信用するのではなく、専門家が証拠をレビューしたかを確認してください。
このプロセスは、どちらか一方の見出しだけに依拠するよりも優れた判断をもたらします。1PasswordのAIパッチ適用ベンチマークに対する真の評価基準は、防御可能な自動化を妨げずに、その知見が検証の改善につながるかどうかです。
