論文の概要: What Happens When We Fuzz? Investigating OSS-Fuzz Bug History
- arxiv url: http://arxiv.org/abs/2305.11433v1
- Date: Fri, 19 May 2023 05:15:36 GMT
- ステータス: 処理完了
- システム内更新日: 2023-10-24 08:24:30.712641
- Title: What Happens When We Fuzz? Investigating OSS-Fuzz Bug History
- Title（参考訳）: ファズしたらどうなる?
OSS-Fuzzバグ履歴の調査
- Authors: Brandon Keller, Andrew Meneely, Benjamin Meyers
- Abstract要約: 我々は2022年3月12日までにOSS-Fuzzが公表した44,102件の問題を分析した。
コードを含むバグの発生時期を推定するために,バグ貢献のコミットを特定し,検出から修正までのタイムラインを測定した。
- 参考スコア（独自算出の注目度）: 0.9772968596463595
- License: http://creativecommons.org/licenses/by/4.0/
- Abstract: BACKGROUND: Software engineers must be vigilant in preventing and correcting
vulnerabilities and other critical bugs. In servicing this need, numerous tools
and techniques have been developed to assist developers. Fuzzers, by
autonomously generating inputs to test programs, promise to save time by
detecting memory corruption, input handling, exception cases, and other issues.
AIMS: The goal of this work is to empower developers to prioritize their
quality assurance by analyzing the history of bugs generated by OSS-Fuzz.
Specifically, we examined what has happened when a project adopts fuzzing as a
quality assurance practice by measuring bug lifespans, learning opportunities,
and bug types.
METHOD: We analyzed 44,102 reported issues made public by OSS-Fuzz prior to
March 12, 2022. We traced the Git commit ranges reported by repeated fuzz
testing to the source code repositories to identify how long fuzzing bugs
remained in the system, who fixes these bugs, and what types of problems
fuzzers historically have found. We identified the bug-contributing commits to
estimate when the bug containing code was introduced, and measure the timeline
from introduction to detection to fix.
RESULTS: We found that bugs detected in OSS-Fuzz have a median lifespan of
324 days, but that bugs, once detected, only remain unaddressed for a median of
2 days. Further, we found that of the 8,099 issues for which a source
committing author can be identified, less than half (45.9%) of issues were
fixed by the same author that introduced the bug.
CONCLUSIONS: The results show that fuzzing can be used to makes a positive
impact on a project that takes advantage in terms of their ability to address
bugs in a time frame conducive to fixing mistakes prior to a product release.
- Abstract（参考訳）: 背景: ソフトウェアエンジニアは、脆弱性やその他の重大なバグの予防と修正に警戒しなければならない。
このニーズを満たすために、多くのツールと技術が開発されている。
Fuzzersは、テストプログラムへのインプットを自律的に生成することによって、メモリの破損、入力ハンドリング、例外ケース、その他の問題を検出することで、時間の節約を約束する。
AIMS: この作業の目標は、OSS-Fuzzが生成したバグ履歴を分析して、開発者が品質保証を優先できるようにすることです。
具体的には,バグの寿命,学習機会,バグタイプを測定することによって,ファジィングを品質保証プラクティスとして採用した場合に何が起こったかを検討した。
方法:2022年3月12日までにOSS-Fuzzが公表した44,102件の問題を解析した。
繰り返しfuzzテストによって報告されたgitコミット範囲を、ソースコードリポジトリにトレースして、システム内にどれくらいのバグが残っているか、バグを修正した人、そして、fuzzersがこれまで見つけてきた問題の種類を特定しました。
コードを含むバグの発生時期を推定するために,バグ貢献のコミットを特定し,検出から修正までのタイムラインを測定した。
結果: oss-fuzz で検出されたバグは平均寿命が324日であったが,一度検出されたバグは,平均寿命が2日であった。
さらに、ソースコミットの著者が特定できる8,099件のうち、バグを導入した同じ著者によって、問題の半数以下(45.9%)が修正されていることがわかった。
結論: 結果から、ファジングは、製品のリリース前にミスを修正するための時間枠内のバグに対処する能力というメリットを生かしたプロジェクトに対して、ポジティブな影響を与えることができることが分かる。
関連論文リスト
- Understanding Code Understandability Improvements in Code Reviews [79.16476505761582]
GitHub上のJavaオープンソースプロジェクトからの2,401のコードレビューコメントを分析した。
改善提案の83.9%が承認され、統合され、1%未満が後に復活した。
論文 参考訳（メタデータ） (2024-10-29T12:21:23Z) - Leveraging Large Language Models for Efficient Failure Analysis in Game Development [47.618236610219554]
本稿では,テストの失敗の原因となるコードの変更を自動的に識別する手法を提案する。
このメソッドは、LLM(Large Language Models)を利用して、エラーメッセージと対応するコード変更を関連付ける。
当社のアプローチは新たに作成したデータセットで71%の精度に達しています。
論文 参考訳（メタデータ） (2024-06-11T09:21:50Z) - Leveraging Stack Traces for Spectrum-based Fault Localization in the Absence of Failing Tests [44.13331329339185]
我々は,スタックトレースデータをテストカバレッジと統合し,障害局所化を強化する新しいアプローチであるSBESTを導入する。
提案手法では,平均精度(MAP)が32.22%向上し,平均相互ランク(MRR)が17.43%向上した。
論文 参考訳（メタデータ） (2024-05-01T15:15:52Z) - Developers' Perception: Fixed Bugs Often Overlooked as Quality Contributions [0.0]
より高い品質を示すものとしてリポジトリで発見されたり修正されたりしたバグを認識しているのは、プログラマの3分の1に過ぎない。
この発見は、プログラマがテストとバグレポートの重要性を誤解することが多いという考えを裏付けるものだ。
論文 参考訳（メタデータ） (2024-03-16T04:40:19Z) - The Impact Of Bug Localization Based on Crash Report Mining: A Developers' Perspective [7.952391285456257]
事故報告をグループ化し,バグコードを見つけるためのアプローチを18ヶ月にわたって毎週実施した経験を報告する。
この調査で調査されたアプローチは、バギーファイルの大部分を正しく示唆していた。
論文 参考訳（メタデータ） (2024-03-16T01:23:01Z) - DebugBench: Evaluating Debugging Capability of Large Language Models [80.73121177868357]
DebugBench - LLM(Large Language Models)のベンチマーク。
C++、Java、Pythonの4つの主要なバグカテゴリと18のマイナータイプをカバーする。
ゼロショットシナリオで2つの商用および4つのオープンソースモデルを評価する。
論文 参考訳（メタデータ） (2024-01-09T15:46:38Z) - PreciseBugCollector: Extensible, Executable and Precise Bug-fix
Collection [8.79879909193717]
正確な多言語バグ収集手法であるPreciseBugCollectorを紹介する。
外部バグリポジトリでリポジトリをマップしてバグタイプ情報をトレースするバグトラッカと、プロジェクト固有のバグを生成するバグインジェクタの2つの新しいコンポーネントに基づいている。
現在、PreciseBugCollectorは2968のオープンソースプロジェクトから抽出された1057818のバグを含んでいる。
論文 参考訳（メタデータ） (2023-09-12T13:47:44Z) - Using Developer Discussions to Guide Fixing Bugs in Software [51.00904399653609]
我々は,タスク実行前に利用可能であり,また自然発生しているバグレポートの議論を,開発者による追加情報の必要性を回避して利用することを提案する。
このような議論から派生したさまざまな自然言語コンテキストがバグ修正に役立ち、オラクルのバグ修正コミットに対応するコミットメッセージの使用よりもパフォーマンスの向上につながることを実証する。
論文 参考訳（メタデータ） (2022-11-11T16:37:33Z) - ADPTriage: Approximate Dynamic Programming for Bug Triage [0.0]
オンラインバグトリアージタスクのためのマルコフ決定プロセス(MDP)モデルを開発した。
私たちはADPTriageと呼ばれるADPベースのバグトリアージソリューションを提供しています。
以上の結果から, 代入精度と固定時間の観点から, ミオピックアプローチよりも有意な改善が見られた。
論文 参考訳（メタデータ） (2022-11-02T04:42:21Z) - DapStep: Deep Assignee Prediction for Stack Trace Error rePresentation [61.99379022383108]
本稿では,バグトリアージ問題を解決するための新しいディープラーニングモデルを提案する。
モデルは、注目された双方向のリカレントニューラルネットワークと畳み込みニューラルネットワークに基づいている。
ランキングの質を向上させるために,バージョン管理システムのアノテーションから追加情報を利用することを提案する。
論文 参考訳（メタデータ） (2022-01-14T00:16:57Z) - Self-Supervised Bug Detection and Repair [27.46717890823656]
本稿では,バグ検出と修復の自己教師型学習手法であるBugLabを紹介する。
BugLabのPython実装では、2374の実際のバグのテストデータセットのベースラインメソッドで最大30%改善されている。
論文 参考訳（メタデータ） (2021-05-26T18:41:05Z)
関連論文リストは本サイト内にある論文のタイトル・アブストラクトから自動的に作成しています。
指定された論文の情報です。
本サイトの運営者は本サイト（すべての情報・翻訳含む）の品質を保証せず、本サイト（すべての情報・翻訳含む）を使用して発生したあらゆる結果について一切の責任を負いません。