- OpenSSF says finding vulnerabilities helps only if they get fixed, and many projects struggle to keep pace with the volume of AI-generated reports.
- Its free guide advises separating finding from validating, running AI more than once, sandboxing it, and requiring tests and human review for AI-written patches.
- Leaders should ask whether teams can absorb a surge of findings and whether each fix leaves behind a permanent test.
A security report that nobody acts on protects no one. That plain point sits at the centre of a new guide from the Open Source Security Foundation (OpenSSF). The guide treats AI as a tool for finding flaws. It also warns that the finding only pays off when fixes follow.
What OpenSSF published
On October 20, two OpenSSF working groups released a free guide for developers on using AI to find and fix vulnerabilities. One group covers best practices. The other covers AI and machine learning.
The announcement was written by Dr. David A. Wheeler, a Linux Foundation director whose focus is open source supply chain security. He says the guide is for developers securing their own code. It is also for researchers who want to help them.
OpenSSF also intends to turn the material into a course, coded LFD126, that tests learners. It expects to release that in the coming months.
The guide sticks to general principles instead of named products. OpenSSF says tools change fast, and much of the advice online is tied to a single tool or service.
Reports are arriving faster than fixes
The announcement opens with a threat figure. It quotes CrowdStrike's 2026 Global Threat Report, which says attacks by AI-enabled adversaries rose 89% year over year. That number belongs to CrowdStrike. OpenSSF only relays it.
The defender's problem is different. OpenSSF says many projects cannot keep pace with the volume of AI-generated reports. It points to Chrome, where the team reported a sharp jump in 2026 bug fixes that it ties to defects AI uncovered. OpenSSF says Firefox had a similar experience. Mozilla fixed 423 security bugs in April 2026.
OpenSSF adds a caveat. It calls a web browser "something of a worst case." It still argues the lesson applies broadly. Its conclusion is that projects of every kind face a much larger volume of vulnerabilities to find and repair.
Here is WebPulse's interpretation. The pressure point may be moving from discovery to repair. OpenSSF does not make that claim in those words. Its guide still gives a lot of advice on finding well. But its own framing shows why a pile of confirmed findings is not a win by itself.
Think of a team with a fixed number of engineers. If AI hands them more reports, the same people must sort, fix and test more. That is an illustration, not a case from the guide. OpenSSF gives no figures on how report volumes changed for ordinary projects.
How the method works
The guide covers a full cycle. Teams gather findings, including those reported by others. They remove duplicates, check each one, rank them, fix them and test the fixes. Then they report, release, deploy and start again.
Three points explain the design.
First, keep finding and checking apart. One step proposes possible flaws. A separate step confirms them. OpenSSF says an AI agent given both jobs at once often talks itself out of real vulnerabilities.
Second, run the AI more than once. Today's AI is not deterministic, meaning the same input can give different answers. One pass is therefore likely to leave real flaws unfound. The guide says to keep going, with several approaches, until new runs stop turning up anything useful.
Third, begin simply. OpenSSF suggests a brief request to a decent model, naming the area to examine. It says this can work better than you would expect. Fancier setups find more, but you do not need one to start.
Why AI patches still need people
The guide is direct about AI-written fixes. It says AI often treats surface symptoms instead of root causes. It can break nearby features or add subtle new security flaws.
The remedy is process. OpenSSF says no AI patch should be merged until automated tests pass and a person has reviewed it.
The guide also asks teams to run the AI in a sandbox. That means a walled-off space where mistakes stay contained. It adds a human sign-off for risky actions and a kill switch.
Each fixed flaw should become a permanent check. The guide names regression tests, static analysis rules and fuzzing harnesses. A fuzzing harness feeds a program random inputs to expose crashes. The goal is that fixed bugs do not quietly return.
On prevention, the guide says to limit vibe coding, meaning loosely supervised AI code writing. It also says to review every pull request and to build in secure-by-design and secure-by-default practices.
Questions to put to your team
This is advice from a standards body. It is not a measurement of how many organisations are affected. Its questions are still practical.
Could we absorb a sudden jump in findings? Who sorts them, and how long does a confirmed flaw wait for a fix? Is checking a separate step from finding? Does every AI-written patch face tests and a human reviewer? Is our AI tooling sandboxed, with a way to stop it? Does each fix leave a permanent test behind?
OpenSSF's closing advice is to pick your most important project and get started. For leaders, the lesson is that finding flaws is not enough on its own. Budgets should also cover the slower work of fixing them.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: OpenSSF.
