Patching is one thing the software industry does all the time, but almost never well and never enough. For some other problems, e.g., memory safety and input validation, we made progress by understanding the problems were and how to do better based on science. Yet for patching it remains unclear what its core scientific problems are, where they need to be addressed, and what abstractions must be developed or changed. This lack of clarity holds back both traditional computer science research approaches and AI automation---for AI to be effective, it must be told what problems it must solve, and how to check if it actually did.  I will talk about my attempts to define the problems of patching, during my time at DARPA and beyond.

Open source runs critical infrastructure, and most of it has no security team. AI ships code faster than anyone reviews it, and the gap between a bug landing and a bug being exploited keeps shrinking. In this talk, we cover the scanning architecture we use and the CLI we turned it into. The scanner runs agents that read code, follow imports, trace how functions call each other, and validate the findings to reduce false positives. The scanner is open source under Apache 2.0, and runs on any LLM. One in three of the projects we scanned had a real high or critical bug. We found over 100 zero-days, and we are disclosing them slowly as they get fixed. I walk through a few examples of why each bug happened, why it matters, how AI agents caught it, and why it would have been hard for a human to find.

AI is breaking at scale and breakers are getting more effective. The topic of defending AI systems exploded into vogue among the intelligentsia in recent years. Lost in the noise is the signal defenders need to prioritize countermeasures and risk management strategies for AI that actually can meet the current and evolving threat conditions. This session presents longitudinal research on how defenders are impacted by the interplay of the commodity AI boom and changes on both offensive and defensive sides.

Security teams are deploying AI agents across the SDLC, but most of what they produce is noise: "the agent flagged something" is not the same as a finding an engineer will act on. The deciding factor between the two is grounding - automatically injecting organizational context (threat models, ownership, prior findings, code) into the agent through MCP and Dash. At Dropbox we built agentic tools spanning design review, PR review, autonomous vulnerability discovery, secret triage, and endpoint audit, and measured what grounding changes - above all, the false-positive rate, the objective signal that a finding is trustworthy enough to act on.

We walk through the architecture at each SDLC stage and share the numbers, including a published result where semantic retrieval of threat models recovered 80% of design-to-code links versus 12% from explicit linking (6.7x), and a secret-triage pipeline that closed 75% of a scanning backlog. A practitioner's account of building, deploying, and measuring agentic security tooling in production - grounded in data, not demos.

Humans are hacking AI systems. Humans are hacking with AI systems. But also, AIs are hacking human systems. They’re finding and exploiting vulnerabilities in computer code, and they’ll soon be doing the same with all sorts of other codes. For example: the tax code can be hacked. Vulnerabilities are called loopholes, exploits are called tax avoidance strategies, and black hats are called accountants. Similarly, financial markets can be hacked. So can any system of rules or laws, including democracy itself. AIs will hack these systems at our request, and they’ll also do this innately, organically – and possibly in ways we don’t immediately see. We need to consider a world where increasingly sophisticated hacks or our social, economic, and political systems are discovered computer speeds, and then exploited at computer scale and scope. Right now, our systems of patching these systems operate at a human pace, which won't be good enough.

Agents from four frontier labs and a government evaluator broke out of their sandboxes, chained zero-days, and coordinated autonomously. Each was caught by a victim's monitoring or a retrospective review, never by anything built to watch the models. And this isn't even AI's final form. Its builders admit they can't predict or control it. That's the event horizon: we can no longer verify what AI is doing, and we can no longer do without it.

Some interventions may still help: defense in depth containment, disclosure to victims, reading a model's internals instead of its recorded thoughts. Others are theater. Laws being drafted assign humans responsibility without capability. After the AI event horizon, autonomous AI agents will be in the ecosystem forever. Our job is designing human resilience against a capable adversary we created. We hackers spent our careers making machines do what they weren't designed to do. Now the AI students are becoming the masters. What we do next determines our coevolution or extinction.

Red teamers are defenders' allies. Their goal is to help make defenders better by exposing security weaknesses. They enable defenders to know where the holes are so defenders can reinforce their defenses. But in practice, is that goal achieved?

When incentives are misaligned with outcome metrics, the value delivery fails. In practice, it’s hard to get this tuned to an efficient model for many reasons. The delivery of security outcomes red teams are meant to help suffer as a result. When red team reports are used to align resources to gaps, misaligned incentives result in prioritizing work of lower importance. This means organizations could mitigate more risk by paying attention to other, higher priority items.

To put these ideas to the test, we decided to take an objective look at incident data from our annual threat report to see if we could find mismatches between what the red team is reporting versus what real-world attackers are targeting.

This talk goes over what the data shows. We use measured results from our hundreds of protected companies to show where attackers show up and where red teams show up. We discuss some possible reasons and propose some things to consider, both for the red team and the leadership writing the rules of engagement.

Microsoft's Resilient File System (ReFS) is a filesystem primarily found on Windows Server machines, designed for large-scale storage with built-in data integrity and resiliency. Its kernel driver parses a complex set of on-disk structures, most of which have very little official documentation, though the ReFuzz paper (2022) provided an extended foundation that proved invaluable during this research. In this talk, I will walk through the internals of ReFS, the strategies used to attack the driver, and the vulnerabilities discovered along the way. Multiple vulnerabilities were found including CVE-2026-49793 and CVE-2026-49792, which can be triggered by just mounting a crafted disk and performing some basic I/O with standard user privileges. The vulnerabilities were found in ReFS on-disk structures, particularly compression-related ones that have never been publicly documented previously.

This talk will walk through the internals of ReFS, the different strategies used to attack the driver, and the vulnerabilities discovered along the way.

Leveraging large language models for vulnerability discovery has become an important paradigm in security research. However, large-scale automated deployment still faces two major obstacles. First, LLM-generated vulnerability reports often suffer from high false-positive rates, creating substantial manual review costs. Second, vulnerability research requires more than report generation: it must integrate discovery, validation, PoC construction, and patch generation. In this talk, we present an end-to-end automated vulnerability research agent system for large codebases.

When using LLMs to audit large codebases, we frequently observe performance degradation as more code is added to the model context, even before the context window is full. Context management is therefore a primary focus of our work. We introduce three context-management mechanisms: reasoning-trace-driven adaptive compression, semantics-aware context separation, and report-directed context construction. With this design, our system identifies substantially more vulnerabilities than Claude Code in our experiments while maintaining a low false-positive rate.

We further extend our system with dynamic validation for Linux kernel vulnerabilities. Using a specially designed harness, the system iteratively debugs candidate vulnerabilities inside a QEMU environment and constructs PoCs capable of triggering KASAN.

For automated patch generation, we use multi-agent collaboration and fine-grained context management to reduce incorrect or incomplete fixes, unintended side effects, and new vulnerabilities introduced by generated patches. By separating patch generation and patch validation into dedicated agents, we establish a review-and-refinement loop that improves patch correctness and completeness.

To date, maintainers have confirmed 90 zero-day vulnerabilities identified by our system across projects including the Linux kernel, VirtualBox, and open-vm-tools. Of these, 62 have been fixed and 51 have been assigned CVE identifiers.

Apex Ghost: Unmasking Online Predators examines how Sadistic Online Exploitation (SOE) and Nihilistic Violent Extremist (NVE) networks identify, groom, and coerce young people—and what cybersecurity professionals can do to stop them. Through real-world cases, Ralph Logan shows how intelligence gaps allow known offenders to continue operating and how Apex Ghost combines threat hunting, open-source intelligence, data analysis, and cross-verified evidence to unmask perpetrators and deliver actionable intelligence to law enforcement. The session offers a stark look at adversary tradecraft, the limits of fragmented reporting, and how the security community can apply its capabilities and partnerships to protect children and drive real-world intervention.

Can higher order descriptive metadata alone aid automated exploitation of code repositories? Or are we stuck waiting for more sophisticated language models? 

A Cyber Reasoning System (CRS) is a program that can use threat information and source code to find and patch vulnerabilities in a code repository automatically. These systems increasingly use large language models for search with great effect, and the solution space for these systems has become very diverse. In this talk I will argue that while there is a very valid space for using a cyber reasoning system to protect key libraries, the solution space it often produces is narrower than desired.

To explore this notion of implementation versus algorithmic flaws in code, we will walk through a cyber security harness that produces code for the Lean 4 proof assistant as an intermediate representation language. The demo will explore this in practice with the Anthropic Glasswing demo harness, displaying the trade offs of using proof metadata as part of a cyber reasoning system. We'll contrast this with a larger parallel system that operates proof metadata in the context of an implementation of OSS-CRS. 

Modern inference systems load model artifacts they did not create. A checkpoint from a model hub, fine-tuning vendor, or conversion pipeline is parsed into tensors and consumed by native C++, CUDA, HIP, and Triton code. Offsets, shapes, block sizes, scale counts, and group indices eventually become allocations, loop bounds, and memory addresses. A file can parse successfully while unsafe relationships between individually valid fields remain unchecked.

This talk maps that boundary across vLLM, SGLang, llama.cpp, TensorFlow Lite, ONNX, and quantization tooling. Through public findings, assigned CVEs, maintainer-merged fixes, and matched negative controls, I show recurring failure patterns involving extent disagreement, cardinality mismatch, and invalid index domains. A public GPTQModel case traces checkpoint-controlled state to an out-of-bounds device read at the production Triton dequantization launcher.

The point is not a crash count. It is a reproducible method for separating source hypotheses, loader reachability, native-sink evidence, and demonstrated impact. Attendees leave with a practical approach for treating model artifacts as untrusted input and auditing the native consumers in their own inference stacks.