By David A. Wheeler, OpenSSF

AI has gotten good at finding software vulnerabilities, and attackers are already using it. For example, “AI-enabled adversaries increased attacks by 89% year-over-year” according to the CrowdStrike 2026 Global Threat Report. If you maintain or develop software, it is critical to find and fix vulnerabilities before attackers exploit them.

To help, the OpenSSF Best Practices and AI/ML working groups have co-developed and released a free guide, Finding and Fixing Software Vulnerabilities Using AI: A Guide for Developers. It’s for software developers who want to find and fix vulnerabilities in their own software and for security researchers who want to help them. We plan to release this information as an online course (LFD126) with quizzes and a final exam in the coming months.

Why we wrote this

Finding vulnerabilities doesn’t help unless they’re fixed. AI is producing reports faster than many projects can handle. The Chrome team reported a huge rise in bug fixes in 2026, caused by AI-discovered defect reports. Firefox had a similar experience: Mozilla fixed 423 security bugs in its April 2026. A web browser is something of a worst case, but the lesson applies broadly: software projects need to find and fix far more vulnerabilities than before.

There’s a lot of advice out there, but much of it is tied to a specific tool or service, and those can change quickly. We’ve developed a guide that focuses instead on general principles that we think will last, so you can apply them regardless of the tools you use.

What’s in the guide

After a short introduction to the AI concepts you need, the guide walks through the whole process:

Decide on approaches. Don’t ignore AI, don’t wait for access to the best models, and don’t presume AI can correctly fix every vulnerability. To get traction, do simple things first.
Prepare. Prepare the AI, its sandbox, and its logging, along with your threat model, code and documentation, CI/CD, and dependency updates. AI is a far more effective assistant if you prepare things first.
Find and fix. Identify findings, handle findings others report to you, deduplicate, validate, triage, fix, verify the fixes, report, release, and deploy. Then repeat.
Prevent. Limit vibe coding, evaluate every merge/pull request, apply secure by design and secure by default, and harden.

A few key points

Here are some points from the guide that I think people often miss:

Start simple. If you’ve never done this, a short prompt asking a reasonably good model to find a vulnerability, with a hint about where to look, can work surprisingly well. More sophisticated setups can find more, but you don’t need an elaborate setup to begin.
Separate finding from validating. Have one step identify possible vulnerabilities (“findings”) and a separate step confirm them. If an AI agent attempts both tasks simultaneously, it often convinces itself to dismiss actual vulnerabilities.
Run AI more than once. Today’s AI isn’t deterministic, so a single run will probably miss things that later runs would find. Keep going until repeated runs, using multiple approaches, stop finding anything useful.
Never trust AI patches blindly. AI frequently patches superficial symptoms rather than root causes, breaks adjacent features, or introduces subtle security regressions. Always require automated test suites and human peer review before merging.
Sandbox the AI. Run it in a sandbox, with a human gate on risky actions and a kill switch.
Build deterministic safety nets. Turn every fixed vulnerability into regression tests, static analysis rules, or CI/CD fuzzing harnesses so bugs won’t quietly reappear.

From guide to course

The field is changing quickly, so we’re releasing the material as a guide now instead of waiting for the course. We’ve already drafted quiz questions, and we plan to release the course once it’s ready. Meanwhile, if you want a broader introduction to AI and software security, see our course Secure AI/ML-Driven Software Development (LFEL1012). To learn how to write secure software in general, see our course Developing Secure Software (LFD121).

Please help

This guide will need to keep changing as AI changes. If you see something we got wrong, something that’s missing, or something that’s out of date, please tell us. You’re also welcome to join the OpenSSF Best Practices working group (WG) or the OpenSSF AI/ML WG, both of which supported this work.

Many thanks to everyone who contributed to and reviewed this guide, including Georg Kunz, Laura Guazzelli, Ryan Jennings, and Santosh Kumar Puppala.

AI is changing security. That doesn’t mean it’s time to panic; it means it’s time to get to work. Please learn from the guide, pick your most important project, and get started.

This image is being created by AI with prompt “A human and his robot companion relax with drinks on a high fortified wall, as its glowing shield easily deflects laser fire from attackers below.”

About the Author

Dr. David A. Wheeler is an expert on developing secure software and on open source software. He created the Open Source Security Foundation (OpenSSF) courses Developing Secure Software (LFD121), Understanding the EU Cyber Resilience Act (CRA) (LFEL1001), and Secure AI/ML-Driven Software Development (LFEL1012). His other contributions include Fully Countering Trusting Trust through Diverse Double-Compiling (DDC). He is the Director of Open Source Supply Chain Security at the Linux Foundation and teaches a graduate course in developing secure software at George Mason University (GMU).