On October 20, 2026, the Open Source Security Foundation (OpenSSF) published a guide on finding and fixing software vulnerabilities using AI.
The guide itself, Finding and Fixing Software Vulnerabilities Using AI: A Guide for Developers, is a joint effort of the OpenSSF Best Practices and AI/ML working groups. David A. Wheeler and the contributors cover the full process, from preparing an analysis environment through discovery, validation, remediation, and prevention.
I participated in the review of the collaborative draft. In September, I submitted suggested text on the security of AI analysis environments and the evidence needed to trust their results. Wheeler accepted several of those suggestions, and I was acknowledged among the guide’s contributors and reviewers.
What interested me most was not whether an AI model can find a plausible bug. It was what must happen between a model’s claim and a security decision or an authorized action.
A finding is a hypothesis, not a vulnerability
AI-generated findings can sound definitive while overlooking an existing guard, an unreachable code path, or a mismatch with the system’s actual deployment model.
One of my suggestions emphasized independent reproduction rather than self-review. A discovery agent asked to assess its own output may carry forward the same assumptions that produced the finding. A verifier should instead try to disprove the claim and establish reproducible evidence.
This does not require one universal verifier architecture. Fresh context, separate execution environments, adversarial prompts, and human review can all help in different circumstances. What matters is that confirmation is not merely agreement.
The same distinction applies to patches. A proposed fix is not accepted simply because it compiles, passes a narrow test, or receives a favorable model-generated explanation. Its security property needs to be tested against the failure mode that motivated the change.
There are two systems to threat-model
The software under examination has its own trust boundaries and security requirements. The AI system conducting the examination also has a threat model. Conflating the two makes it easier to misplace controls.
This distinction came up directly during review. An early suggestion about agent identities belonged more naturally with the analysis environment than with the threat model of the target application. That editorial exchange helped clarify the scope of the controls.
The analysis environment consumes material that may be attacker controlled: repository comments, documentation, issue text, dependency metadata, generated files, and external references. Those inputs can be useful evidence without becoming instructions that grant new permissions or alter the agent’s mission.
I also suggested treating persistent AI memory as an input, not an authority. Memories may be stale, incorrect, sensitive, or contaminated by earlier untrusted material. For security decisions, current code, configuration, and reproducible observations should take precedence over remembered conclusions.
Isolation should follow capability
An agent reading source files and an agent running a proof-of-concept exploit do not present the same operational risk.
I proposed matching sandbox isolation to capability: reading, building, executing, fuzzing, and exploit validation involve progressively more powerful operations and different exposure to untrusted code.
A sandbox is not an absolute security boundary just because it is called one. In an earlier review comment, I pointed to Trail of Bits’ analysis of VM containment for cyber-capable agents and discussed layered restrictions alongside rootless containers and an immutable Nix-based operating environment.
There are practical trade-offs. A read-only analysis may work with relatively modest isolation. Executing unknown workloads or developing exploits deserves stronger containment and more carefully limited filesystem, network, credential, and process access. Resource bounds also matter: timeouts, tool budgets, parallelism, and execution limits must produce observable outcomes rather than quietly ending a run.
Verifiers become part of the trust boundary
If a workflow delegates acceptance to a verifier, the verifier becomes part of its trusted computing base.
A broken test harness, compromised build environment, or check that asserts the wrong property can confidently approve an incorrect result. One accepted suggestion described making verification properties explicit, keeping checks deterministic where practical, and exercising verifiers against known-good and known-bad cases.
This is a different question from whether the model’s reasoning looks persuasive. It asks what the surrounding system can actually prove.
Another contribution concerned provenance. An actionable finding should retain enough context to interpret and reproduce it: the source revision, relevant environment and configuration, analysis invocation, evidence, and threat-model assumptions.
Just as importantly, a completed analysis with no findings is not the same as an incomplete analysis. A timeout, denied permission, failed tool call, or crashed environment must not be converted into a clean result. Automated pipelines need distinct outcome states.
Proposal is not authority
AI agents should not automatically inherit a human operator’s full credentials or privileges. Discovery, validation, patching, and reporting can be separate roles with distinct identities and permissions.
I suggested placing high-impact actions behind explicit approval boundaries: publishing a vulnerability report, merging a change, deploying a fix, or modifying a production system should require the authority appropriate to that operation.
Those boundaries should be enforced by tools and workflows, not only by prompts that ask a model to behave.
This is the same distinction I explore in my work on threat-modeling AI as an engineering coprocessor and governed software delivery: an agent can propose an operation without acquiring permission to perform it.
Why this contribution matters to me
AI can increase the volume of potential findings and patches. That makes the quality of evidence, verification, and authorization more important, not less.
I appreciate Wheeler’s careful review and the broader OpenSSF collaboration. Some suggestions needed rewording or belonged in different sections; that is part of producing useful shared guidance. My contributions were a small part of a much larger effort.
The guide is free and tool-agnostic. If you are integrating AI into vulnerability discovery or remediation, it is worth reading in full.
- OpenSSF announcement (October 20, 2026)
- Finding and Fixing Software Vulnerabilities Using AI: A Guide for Developers
These are my own reflections on the review and engineering implications, not an official statement on behalf of OpenSSF or the Linux Foundation.