Anthropic’s OSS Scanner Is Free. The Triage Bill Is Not.
On 8 October 2026 Anthropic opened an opt-in model scanner for open-source projects. Indie maintainers should enroll only after they can verify a reproducer the same day.
On 8 October 2026 Anthropic opened an opt-in model scanner for open-source projects. Indie maintainers should enroll only after they can verify a reproducer the same day.
Anthropic’s OSS Scanner sends model-written vulnerability reports with reproducers and candidate patches at no charge. The 8 October launch still leaves indie maintainers with the review, the false severity, and the dependency clock.
On 8 October 2026 Anthropic opened OSS Scanner, an opt-in service that runs its strongest models, including Claude Mythos, against open-source projects and returns the findings with no human triage. The list price is zero. The operating cost is not. A report with a working reproducer still has to be reproduced, scored against your threat model, patched, and shipped before anyone else treats the same write-up as a recipe.
Indie founders sit on both sides of that bill. Some maintain a small library other products import. Almost all of them ship a product that imports libraries they do not maintain. Anthropic’s numbers show why the queue will outrun the review desk. Over the last six months the company says its models produced more than 29,000 candidate vulnerabilities, and staff manually reviewed about 6,000. Maintainers who asked for the unverified pile have already received nearly 5,000 reports. The scanner exists because that human bottleneck did not move.
OSS Scanner is not a public dump, and it does not replace Anthropic’s coordinated disclosure process. Core maintainers of eligible projects enroll by opening a pull request on the anthropics/oss-scanner repository, using the project template. Eligibility follows the same rough test as Google’s OSS-Fuzz: a critical impact on infrastructure and user security, decided case by case. Projects that cannot staff a raw queue stay on the older path, where reviewers still validate findings before disclosure.
Outputs are fully model-generated, without human review or triage, so incorrect or invalid reports are possible. Each report is meant to carry a self-contained reproducer, an explanation, a bisection to the introducing change where the model can find one, and a candidate patch when it has one. Early private runs included bugs Anthropic says it chained into unauthenticated remote code execution against the scanned projects.
Expert testers who already review coordinated disclosures looked at 97 critical and high-severity findings from an early scanner version, across 48 projects. Eighty-five, or 88 percent, met the bar for that process. Of the other 12, eleven were real but duplicated a known issue or another finding in the same scan. One was invalid. Maintainers have since said severity can still be inflated, and that the model sometimes misunderstands a project’s threat model.
Named projects described the early packets on the launch note. Noah Misch of PostgreSQL said several fixes were close to usable. Anton Arapov of the OpenSSL Corporation said a real exploit attached is enough for an engineer to verify immediately. Todd Ouska of wolfSSL said 74 reports arrived, all but two were valid, and five became CVEs. Eddie Kohler said the HotCRP reports understood a complex permission model. Those comments cover a selected early cohort, not a benchmark for your users.
The same week Anthropic pointed maintainers at a Cyber Verification Program for qualifying security professionals, and at Claude for OSS, which provides Claude Max 20x subscriptions to help fix vulnerabilities. The scanner is paid for out of the Defender Advantage Fund set up in August. If your project does not clear the infrastructure test, you do not get the feed.
Most indie products will never be eligible. The dependency tree will be. A PDF renderer, an auth library, or a queue client can sit three layers under a weekend product and still match the critical-impact test at the library, not at your app. When that library opts in, the gap between a model finding a bug and a public write-up shrinks. Anthropic’s case for the fast path is that exploits can now be developed in minutes, so defenders need the report first. A reproducer written for a maintainer is also a reproducer.
Founders often open-source a CLI or a plugin, then staff it with the person who also runs support. The scanner emails you, on a cadence, with packets that look finished. The failure mode is treating a candidate patch as safe to merge. If you publish a library and enroll, customers will ask whether the latest finding affects the hosted product. The answer has to be a commit, a version bound, or a note that the configuration was not reachable.
Consider a two-person invoicing app that depends on an OAuth helper popular enough to enroll. The maintainer posts that they opted in. The next morning token-refresh failures spike after a patch release whose notes mention scanner findings and do not name the routes that changed. Freezing every dependency is the wrong reply. So is applying every patch that mentions a model. Split three clocks. The library’s disclosure clock belongs to the maintainer. Your deploy clock moves only after you can name the function that changed and the request that proves refresh still works. Your customer-notice clock moves only if the vulnerable configuration was reachable in production.
The 88 percent figure does not make that call. It says a sampled set met a lab’s disclosure bar. Your bar is narrower: does this reproducer hit a route you expose, with the auth mode you run, on the version you shipped?
Name the on-call. One person owns scanner mail for the week, with a backup. If that person is also on a launch, do not enroll this month. The human-reviewed path remains for projects that cannot triage. Using it is a capacity choice.
Write the acceptance test before the first report. A finding is actionable only if the reproducer runs on a branch you control, the impact matches a threat you have, and the candidate patch does not weaken a check you added on purpose. Everything else is a note.
Split the inbox. Route scanner mail to a label that cannot page production. Page only after a person has re-run the reproducer and marked the finding reachable. Model severity is an input, not an alarm.
Pin the version you will test. For each critical dependency, record the release in production and the release you are willing to jump to. A scanner-driven release that also bumps an unrelated API is two changes. Review them apart.
Reproduce, then patch. Run the supplied reproducer on the previous release and on the candidate fix. If you cannot reproduce, do not merge the patch to be safe. A real exploit makes verification fast. A missing exploit is still an investigation.
Bound the blast radius in your app. Ask whether the vulnerable function is in the build you ship, whether the route is authenticated, and whether a flag already disables it. Five CVEs out of 74 wolfSSL reports show that valid does not mean urgent for every caller.
Close the loop with a version, not a vibe. Maintainers should say which findings they fixed, which they rejected as the wrong threat model, and which release contains the fix. Consumers should name a minimum safe version only after they have verified it. Do not paste the reproducer into a changelog.
Do not pipe scanner output into the agent that opens pull requests. Reports can be wrong, duplicated, or scored too high. An automated patch can also delete a security check to make a finding disappear. A person re-runs the reproducer. A second pass merges.
Do not enroll a repo that holds customer data, production secrets, or a private fork of a public library. The scanner is for open-source projects. A private monorepo belongs on a different product. Mixing those queues is how a test fixture becomes a disclosure.
Does OSS Scanner replace a normal review?
No. Coordinated disclosure remains for projects that want human-validated reports. The new service is an opt-in fast path with model-only output. Anthropic says it will keep refining severity and threat-model mistakes from maintainer feedback.
Will a typical indie app be eligible?
Probably not, if you only ship a hosted product with a small user base. Eligibility targets projects with critical impact on infrastructure and user security, judged case by case. Your dependencies are the more likely enrollees.
How good were the early reports?
On the check of 97 critical and high findings across 48 projects, 88 percent met the disclosure bar, 11 were real duplicates, and one was invalid. wolfSSL reported 72 of 74 early reports valid, five of them CVEs.
What does a report contain?
A self-contained reproducer, an explanation, a bisection where the model can produce one, and a candidate patch when it has one. Verify the reproducer, not the prose.
Should we wait for a CVE number?
No. The fast path can arrive before a public identifier exists. Check reachability first, then decide if the finding deserves a release.
What if we cannot read the queue?
Do not enroll. Stay on the human-reviewed path. For dependencies that enroll, read release notes and pin versions until you can run the reproducer yourself.
Indie founders need a named owner, a reproducer they can run, and a rule that a model patch does not merge itself.
Community
0 comments
React to this article
Trending now
Written by
Kirtesh Admute
Founder
Kirtesh Admute is the founder of IndieFounder, a platform for founders, builders, and people curious about technology. He writes about AI, startups, software, product building, and the lessons that come from building in public.
See an issue with this story?
Continue reading
Security
1 week ago · 8 min read
Security
5 days ago · 6 min read
Security
5 days ago · 6 min read
