Security headlines are changing owners. They used to read "AI-made slop reports harass maintainers." Per Anthropic, it is now the reverse. Reports arrive with real exploits and patches attached, and maintainers ask for "everything, even unvalidated."

OSS Scanner, announced October 8, institutionalizes that shift. An opt-in service giving enrolled open-source projects regular free vulnerability scans from the strongest models. One catch runs through this whole post: reports ship with no human review.

What OSS Scanner is

As Google's OSS-Fuzz served the ecosystem with fuzzers, OSS Scanner does it with language models. While the paid Claude Security product defends enterprises, OSS Scanner donates security audits to open-source projects.

Target: opted-in open-source projects (OSS-Fuzz-like bar)
Method: periodic scans by the strongest models (incl. Claude Mythos)
Cost: free
Review: no human review or triage (fully model-generated)
Speed: fast, but incorrect or invalid reports are possible

Each report is practical. A self-contained reproducer, a vulnerability explanation (with bisection to when the bug landed, where possible), and a candidate patch when available. Not "a vuln exists" but "reproduce it like this, fix it like this" in one bundle.

The backdrop numbers came with the launch. Over six months the strongest models scanned flagship projects and found 29,000+ candidate vulnerabilities, of which humans could review and triage only about 6,000. Humans are the bottleneck. So the human-verified CVD (coordinated vulnerability disclosure) process stays, and a fast track opens for teams that want reports immediately. Nearly 5,000 reports have already gone out in bulk on maintainer request.

How to read the 88%

The most quotable figure is 88%. Expert penetration testers checked 97 critical and high findings across 48 projects from an early pipeline version: 85 met the CVD bar, 11 of the rest were real but duplicates, and only one was invalid.

Be precise here. That is an expert check on a small sample, not the scanner's general precision. The announcement itself notes inflated severity ratings and threat-model misunderstandings. For context, the academic CyberGym benchmark shows LLM vuln-finding rising from under 20% early last year to over 85% this year. Models improved, but your project's true-positive rate still needs its own measurement.

Maintainer reactions are specific enough to quote:

PostgreSQL: "an unusually high fraction were real defects, some fixes nearly as-is"
OpenSSL: "raw output as good as or better than human reports; a real exploit ends verification"
wolfSSL: "all but two of 74 valid, five became CVEs; patches slotted into our process"
curl: "several worthy issues despite state-of-the-art tooling, one among the worst in years"
HotCRP: "strong grasp of a complex permission model and good prioritization"

The fine print behind the praise: these are teams with verification processes. "Slotted into our process" means reproducers and patches met existing verify-prioritize-regression-test machinery.

How to enroll

Core maintainers apply by PR to the GitHub repo using the standard project template. The environment gets pinned with a Dockerfile so an offline agent can audit it, dependencies preinstalled. Verifying tests pass inside the container is recommended. Eligibility follows an OSS-Fuzz-like bar: critical impact on infrastructure and user security, judged case by case.

Apply: PR to github.com/anthropics/oss-scanner
Prepare: git URL to clone, contact email, Dockerfile with pinned build
Recommended: confirm tests pass inside the container
Alongside: Cyber Verification Program (advanced capabilities for pros),
           Claude for OSS (free subscriptions for fixing vulns)

Even if your repo never applies, the report shape is worth stealing. Reproducer, explanation, bisection, candidate patch is a fine bug-report template on its own.

CodeBridge Mini Lab: fix the five steps after detection

In an age of AI-found bugs, humans must design the five steps after:

Detect → reproduce → verify → patch → regression-test

[ ] Reproduce: run the reproducer as-is in an isolated container
[ ] Verify: does the severity fit our threat model? (suspect inflation)
[ ] Prioritize: order by exploitability and exposure
[ ] Patch: never merge candidate patches blindly; review with tests
[ ] Regress: leave same-family tests in the suite

This is the four-layer structure from the agent security guide (scope, approval, isolation, review) applied to scanning. Isolate the scanner's environment too, and fix pre-merge review gates for patches.

Conclusion: trusted fixing beats fast receiving

One line to summarize.

As finding gets faster, verification, prioritization, and patch reliability become the bottleneck.

OSS Scanner pulls the front of that bottleneck forward for free. 29,000 candidates, an 88% sample check, and strong maintainer quotes build expectations, but nobody measures your repo's true-positive rate or writes your regression tests for you. Fix the detect-to-regress five steps today. That is the ticket into the AI-scan era.

Further reading

References

Go deeper with a course

If you want practice controlling AI output with permissions, approvals, and verification, the real-project verification-loop path connects directly to this post's five-step workflow.