Using ML filters to help automated vulnerability repairs: when it helps and when it doesn’t

要約

[コンテキスト：]自動プログラム修復における候補パッチの受け入れは、通常、オラクルのテストに基づいています。
テストには通常、アプリケーションを構築するための費用のかかるプロセスが必要ですが、MLモデルを使用してパッチをすばやく分類できるため、肯定的なフィードバックループでより多くの候補パッチを生成できるようにします。
[問題：]モデルの予測が信頼できない場合（脆弱性検出のように）、テストに基づいてより信頼性の高いオラクルをほとんど置き換えることができません。
[新しいアイデア：] MLモデルを、テストに基づいて従来のフィルターの前に置かれた候補パッチの予備フィルターとして使用することを提案します。
[予備的な結果：]そのような操作を実際に意味のあるMLアルゴリズムの精度とリコールに関するいくつかの理論的境界を特定します。
これらの境界と文献に掲載された結果により、テストに基づいてAPR4vulnなどの従来のAVRパイプラインよりも、最先端の脆弱性検出器がどれほど速く効果的であるかを計算します。

要約(オリジナル)

[Context:] The acceptance of candidate patches in automated program repair has been typically based on testing oracles. Testing requires typically a costly process of building the application while ML models can be used to quickly classify patches, thus allowing more candidate patches to be generated in a positive feedback loop. [Problem:] If the model predictions are unreliable (as in vulnerability detection) they can hardly replace the more reliable oracles based on testing. [New Idea:] We propose to use an ML model as a preliminary filter of candidate patches which is put in front of a traditional filter based on testing. [Preliminary Results:] We identify some theoretical bounds on the precision and recall of the ML algorithm that makes such operation meaningful in practice. With these bounds and the results published in the literature, we calculate how fast some of state-of-the art vulnerability detectors must be to be more effective over a traditional AVR pipeline such as APR4Vuln based just on testing.

arxiv情報

提供元, 利用サービス

arxiv.jp, Google