自動修正の現状と課題
既知の脆弱性（N-day脆弱性）への対策は重要です。過去の版に自動でセキュリティ修正を適用する技術が注目されています。これまでの仕組みは、80%以上の成功率を報告していました。しかし、これらの評価は特定のコード保管場所やプロジェクトの版に限定されていました。そのため、これらの仕組みがどれだけ広く使えるかは不明なままでした。
新しい評価基準「Porting Benchmark」
私たちはこの課題を解決するため、「Porting Benchmark」というデータ集を作りました。これは、異なる版、異なるブランチ、異なるコード保管場所をまたぐ1,234件のセキュリティ修正事例を含みます。このデータ集には、共通の評価枠組みも組み込まれています。私たちはこのベンチマークを使い、プログラムの解析技術、LLMへの指示出し、LLMを利用した自動処理を含む5つの仕組みを評価しました。評価は統一された設定で行っています。
評価結果から見えた現実
統一された評価の結果、仕組みの性能状況が大きく変わることが分かりました。PortGPTやTSBPortは比較的高い性能を維持しました。しかし、FixMorphやMystiqueといった仕組みは、共通の手順の下で大きく性能が低下しました。特に、構造が複雑な修正では性能が急激に落ちます。最も良い修正単位の成功率でも、簡単な修正（Type-I）では85.2%だったものが、複雑な修正（Type-IV）では24.0%まで下がりました。
根本原因と今後の方向性
私たちは、性能低下の主な原因を4つ特定しました。一つ目は、目標とするAPIの認識不足です。二つ目は、異なる版間での意味の不一致です。三つ目は、広範囲な依存関係の伝播失敗です。四つ目は、修正作成や場所特定失敗です。これらの原因から、次世代の仕組み設計に向けた具体的な方向性が見えてきました。さらに、45件の動的に検証された一部の事例では、実行による検証が重要だと分かりました。静的な参照の一致だけでは、現実世界の統合の失敗を見逃すことがあります。実行結果による改善は、最も難しい事例で測定可能な回復を示しました。
PR
文賢 →
ベンチマークはあくまで指標です。実運用で何が起きるか、自分で試すのが最速です。特に複雑な修正は、自動化の限界を肌で感じます。私はまず、特定のリポジトリで簡単な修正から試します。失敗込みで一次情報を取りに行きます。
