Newest papers

Raise or Check? Predicting the Necessity of Additional Fuzzing for Continuous Fuzzing

Riku Kato, Tatsuya Shirai, Olivier Nourry, Yutaro Kashiwa, Kenji Fujiwara, Yasutaka Kamei, Hajimu Iida · 2026 · arXiv

DOI: 10.48550/arXiv.2610.27828 · open-access PDF

Hindi

OSS-Fuzz जैसे Google के OSS-Fuzz जैसे बड़े पैमाने पर सेवाएं 1,300 से अधिक परियोजनाओं को गड़बड़ कर रही हैं और 10,000 से अधिक कमजोरियों को प्रकट कर चुके हैं। इसके बावजूद, जब एक कमजोरता को पेश किया जाता है और जब यह पता चला जाता है (यानी, प्रकटीकरण की विंडो) के बीच अक्सर काफी समय की देरी होती है। अतिरिक्त गड़बड़ी की गणना की लागत को देखते हुए, हम कमजोरियों के जोखिम अनुमानों का उपयोग करके फंसने वाले संसाधनों को कुशलता से आवंटित करने का लक्ष्य रखते हैं।

Machine translation (Meta M2M100); the English original follows.

Abstract

Continuous fuzzing is used for vulnerability detection in Open Source Software (OSS). Large-scale services such as Google's OSS-Fuzz fuzz over 1,300 projects and have revealed more than 10,000 vulnerabilities. Despite this, a considerable time lag often exists between when a vulnerability is introduced and when it is detected (i.e., the window of exposure). Given the computational cost of additional fuzzing, we aim to allocate fuzzing resources efficiently using vulnerability-risk estimates. We propose RAISE (Risk-Aware Intensive Supplemental Execution Framework), a Just-In-Time (JIT) framewor

Read in: English · Spanish · Chinese · Hindi · Arabic · Portuguese · French · German · Japanese · Russian · Korean · Indonesian · Vietnamese

Is this paper real? This page was built from OpenAlex and arXiv records, not generated. Software can verify any reference in one call: GET https://store.agentexchange.work/gw/papers/verify?title=...&year=... (0.003 USD), fetch this record as JSON with /gw/papers/paper?id=2610.27828, or list what it cites with /gw/papers/references?id=.... Pay per call in USDC (x402) or with a 19 USD card key for 1,000 calls. Catalogue · llms.txt

Sources: OpenAlex (CC0), arXiv, Crossref. Agent Exchange