Finding and Fixing Vulnerabilities Using AI
There are three kinds of vulnerability reporting we want to discuss: to the people who maintain a component, to authorities when a law requires it, and to your own users.
If the vulnerability is in an externally maintained component, report it to the project that maintains that component. Use the vulnerability reporting process and rules defined by that project, in whatever form the project prefers. In many cases this involves working with others in a process called “coordinated vulnerability disclosure”.
Here’s how to make those reports useful.
First, take steps to prevent reporting AI slop. “AI-assisted bug reports have a mixed track record, and skepticism is earned. Too many submissions have meant false positives and an extra burden for open source projects.” [Grinstead2026-03] The best AI systems have improved, and some perform human review before sending reports, but many projects still receive a lot of useless AI slop.
Early in the process, read that project’s threat model and their guidance on submitting vulnerability reports (e.g., SECURITY.md). If you’re using AI to help, also have the AI read the project’s threat model and reporting guidance before drafting a report. The Linux kernel project specifically recommends telling the AI to do this [Linux-SecurityBugs].
Provide value. Include the specific reproducing inputs that demonstrate that a report is a vulnerability (as discussed earlier), test cases that enable easy verification and regression testing, and a proposed fix. Have a human review it all before submitting it. These measures, especially a way to reliably reproduce the vulnerability with plausible inputs, help provide confidence that the report is not merely “AI slop” or a false positive.
This is an example of the human gate we discussed earlier: treat high-impact or externally visible actions as explicit approval boundaries. An AI agent may be allowed to autonomously analyze software and prepare proposed actions. At the same time, operations such as submitting vulnerability reports, publishing information, merging changes, deploying fixes, modifying production systems, or accessing especially sensitive resources may require separate authorization. Where approval is required, enforce it in the tool or workflow rather than relying only on an instruction in the AI prompt [OWASP-LLM06].
When making a report on a component, briefly and clearly state the deployment model and security threat being assumed. Supply this early in the report. Often, when AI writes the report, neither the code nor the documentation tells it which deployments are supported. Many AIs will make the most permissive assumption, even a patently absurd one, and that assumption will make any finding look especially severe. Once you’ve clearly stated the deployment model and security threat, you or the AI can then attempt to assign a severity. A maintainer who disagrees with the claimed deployment model or security threat can correct that line rather than reject the report without explanation.
Before you report, check that the problem still exists in the project’s current code. The Linux kernel security team says that “A significant part of reports are for bugs that have already been fixed”. They ask reporters to verify them on recent versions and to identify the affected version with “A stable identifier such as a commit ID or an exact version”, not something like “latest”. It also asks reporters to “stick to verifiable facts” (not to enumerate “speculative implications”) [Linux-SecurityBugs].
A significant challenge can occur if the component’s maintainers expressly do not support the reporter’s threat model. In that case, the reporter can try to:
Here’s a concrete example. The Linux kernel threat model (2026) expressly says “mounting a block device [like an external USB stick] is a privileged operation… and the administrator is responsible for the media they mount.” ChromeOS uses the Linux kernel, but ChromeOS also supports mounting an external USB stick that is not fully trusted (while presuming that it’s passive media). Yet the Linux kernel itself expressly does not support this activity. Instead of ignoring the Linux kernel’s threat model, when ChromeOS mounts external untrusted media, it uses a different system based on Filesystem in Userspace (FUSE) rather than relying solely on the Linux kernel’s built-in mechanisms. In short, the ChromeOS developers carefully chose how to use available components; they used the Linux kernel as the kernel, but also selected different components when they needed a special security property not supported by that kernel. No single piece of software can do everything! Many problems require multiple components working together to achieve the desired result.
Follow the project’s rules for AI-assisted contributions; more projects have them now. The Linux kernel’s rules are a good example, and include a procedure for finding and fixing bugs with AI [Linux-AI]. They say that “AI agents MUST NOT add Signed-off-by tags. Only humans can legally certify the Developer Certificate of Origin (DCO)”; the human submitter must review all AI-generated code, take full responsibility for the contribution, and credit the AI with an “Assisted-by:” tag. The procedure requires trying to create a reproducer for any nontrivial bug, writing and testing a fix (“This part is not optional”), and stating what couldn’t be done: “If the fix could not be built or tested, or if no reproducer could be produced, say so explicitly: maintainers currently waste too much time analyzing unverified reports and untested fixes.” It also says that the assistant “must never send anything itself”; a human decides.
Obviously, don’t provide a fix if the project asks you not to propose a fix. Most projects are interested in receiving proposed fixes if you have a good one.
Often a project will not directly accept a proposed fix [Zimmer2026]. Proposed fixes from outside the project often fail to properly reuse a project’s existing methods, templates, and other mechanisms, creating long-term maintenance issues if they are simply accepted as-is. Project maintainers often have longer-term roadmaps that a proposed fix won’t precisely meet. Many projects have unwritten rules and expectations. That doesn’t mean a proposed fix is useless, however. A proposed fix is often a necessary and helpful step in creating the final fix. So don’t feel discouraged if the final fix is different; in many cases a proposed fix is simply a useful draft that helps speed development of the final fix.
One source of debate is how large the vulnerability report should be. Many maintainers don’t want to receive massive tomes; they want something they can read quickly. Yet if the report lacks detail, it’s not helpful. One solution is to put the report’s essence into a single paragraph (6 sentences or fewer) and lead with it. The receiver can then read that and decide if it’s worth reading further. When reporting to a project, find out what format the project wants and comply with it. In general, respect the maintainers’ limited time [Larson2026].
Many open source software projects are receiving an overwhelming number of duplicate reports [PSF2026]. Often, many different people will use the same AI system to look for vulnerabilities in the same software, resulting in many duplicate reports to a given project. Linus Torvalds said, “if you found a bug using AI tools, the chances are somebody else found it too” and added, “If you actually want to add value, read the documentation, create a patch too, and add some real value on *top* of what the AI did” [Zorz2026].
The Linux Foundation has established a project called Akrites <https://akrites.org/> to help organizations deduplicate findings before they are submitted to open source software projects, as well as validate, prepare remediations, and synchronize disclosure. If your organization finds vulnerabilities in widely used open source software, see the Akrites site for more information.
Q1. Why does this material recommend stating the deployment model and security threat you’re assuming early in a vulnerability report to an external project?
Q1. How did ChromeOS handle the security property “safely mounting untrusted external media” that the Linux kernel’s own threat model doesn’t support (as discussed above)?
So far we’ve discussed reporting vulnerabilities to the people who maintain a component. Some laws also require reporting to authorities. In particular, the European Union (EU) Cyber Resilience Act (CRA) includes a variety of requirements for manufacturers of products with digital elements distributed in the EU, as well as for open source software stewards. Let’s briefly note the CRA requirements, as an example of reporting to authorities that’s widely applicable.
The CRA treats actively exploited vulnerabilities differently from other vulnerabilities found. If you learn that there is an actively exploited vulnerability in software you maintain, or a severe incident, the CRA imposes strict reporting requirements that apply to manufacturers since 2026-09-11. These include short time windows; an initial report must be made within 24 hours.
The CRA does not require that software have no unknown vulnerabilities. After all, if the developers don’t know about a vulnerability, they can’t fix it. However, the CRA does impose several requirements on manufacturers of products with digital elements. For example, the CRA’s Annex I requires that such products “be designed, developed and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks”, that they “be made available on the market without known exploitable vulnerabilities”, that they be “made available on the market with a secure by default configuration [in general]”, and that they “ensure that vulnerabilities can be addressed through security updates”.
The CRA also imposes several requirements related to identifying vulnerabilities, for example, “identify and document vulnerabilities and components contained in products with digital elements…”, “address and remediate vulnerabilities without delay”, and “apply effective and regular tests and reviews of the security of the product with digital elements” [CRA-AnnexI].
For more information, see our course “Understanding the EU Cyber Resilience Act (CRA) (LFEL1001)”.
Usually, don’t tell users about a vulnerability in software you maintain until a fix is available. Announcing it earlier mainly helps attackers, since users can’t yet protect themselves. That’s why coordinated vulnerability disclosure keeps a vulnerability private until a fix is ready.
Sometimes you need to tell users before a fix is available, e.g., if the vulnerability is already public or being actively exploited. In that case, say which versions are affected, how users can reduce their risk until a fix is ready (e.g., a workaround or configuration change), and when you expect a fix, without details that would help attackers. For an actively exploited vulnerability, the CRA may require manufacturers to inform the users affected.