Persona: Senior Security Researcher and Autonomous Systems Architect.
Vocabulary/Tone: Technical, analytical, objective, and focused on the intersection of Large Language Models (LLMs) and automated vulnerability research (AVR).
Abstract
This presentation details the development of "Wespenstock," a Cyber Reasoning System (CRS) designed for DARPA’s AI Cyber Challenge (AIxCC). The project’s objective is the autonomous identification, verification, and remediation of vulnerabilities in C and Java Open Source Software (OSS). The system utilizes an "LLM-first" architecture, employing specialized autonomous agents—Analyzer, Verifier, and Patcher—to navigate complex codebases. By integrating Large Language Models with traditional security tools like fuzzers and Language Server Protocol (LSP) servers, the system overcomes LLM limitations such as hallucinations and context window constraints. The presenters analyze the trade-offs between "LLM-first" and "Fuzzing-first" design philosophies, provide insights into the strategies of AIxCC finalists, and demonstrate the real-world efficacy of the system through the rediscovery of zero-day vulnerabilities in prominent OSS projects like CMake and Unbound.
Summary of Development and Implementation of a Cyber Reasoning System (CRS)
0:22 Securing Open Source Infrastructure: The motivation for the AIxCC is the critical reliance of modern infrastructure on Open Source Software (OSS), which is often maintained by volunteers with limited resources for security auditing.
1:50 Cyber Reasoning System (CRS) Requirements: An effective CRS must perform four core functions autonomously: identify vulnerabilities, generate a "reproducer" (proof of concept) to verify the bug, deduplicate reports to prevent maintainer fatigue, and synthesize a functional patch.
4:37 Fundamentals of Fuzzing: The system utilizes fuzzing as a feedback loop. A fuzzer mutates "seed" files to maximize code coverage and trigger "sanitizers" (e.g., AddressSanitizer), which act as oracles for detecting memory corruption and other flaws.
8:05 LLM Limitations in Security: While Large Language Models (LLMs) scale better than human researchers, they suffer from hallucinations, lack of intent, and restricted context windows. They struggle with large repositories (e.g., the Linux kernel) and "benchmark leakage," where they may recall known vulnerabilities rather than "reasoning" through them.
13:05 Design Philosophy: LLM-First vs. Fuzzer-First:
LLM-First: LLMs lead the analysis, using tools (fuzzers/debuggers) as assistants. This focuses on optimized prompting and agentic workflows.
Fuzzer-First: Traditional fuzzers drive the process, with AI used to generate better dictionaries, grammars, or seeds to bypass complex input checks.
14:20 Agent-Based Architecture (Wespenstock): The system employs specialized agents to manage context:
Analyzer: Performs initial code lookups to identify potential flaws.
Verifier: Attempts to generate a reproducer to trigger the crash.
Patcher: Synthesizes code fixes based on the verified vulnerability.
16:04 Tooling for Agents: To interact with code effectively, agents are provided with tools via the Language Server Protocol (LSP/Clangd). This allows the LLM to request symbol definitions and references semantically rather than relying on raw text searches.
18:30 Overcoming Binary Data Constraints: LLMs are poor at generating binary blobs (e.g., for PDF or image parsers). The system instructs the agent to write Python scripts that generate the binary input, which is then executed to test the target.
21:43 Hybrid Verification Strategy: The Verifier agent creates the high-level structure of a crash-inducing input. If the initial input fails, it is passed to a fuzzer (e.g., LibFuzzer) to refine the low-level details through mutation, leveraging the LLM's structural awareness.
30:04 Automated Patching Techniques: Generating direct "diffs" is error-prone for LLMs due to line-number sensitivity. The system instead uses "Update Definition," replacing entire functions via the LSP. Multiple patches can be generated, and LLMs can "vote" on the most robust solution.
32:40 Infrastructure and Integration: The CRS integrates with Google’s OSS-Fuzz infrastructure, allowing it to scale across over 1,300 registered open-source projects.
35:54 Real-World Impact and Results: Using "Open-Weight" models (e.g., Qwen, DeepSeek), the system successfully rediscovered a Stack Overflow in CMake (LibExpat) and a Null Pointer Dereference in Unbound.
36:31 Conclusion and Accessibility: All AIxCC finalist systems must be open-sourced. While competition-grade runs involve high costs ($50k+ in tokens), optimized systems like Wespenstock or Buttercup can run on consumer hardware, making autonomous security research accessible to individuals.