Anthropic OSS Scanner: Free AI Security Scans, Real Fixes, and the Maintainer Workload

Anthropic is offering free AI security scans to critical open-source projects. A serious curl fix shows the potential. Maintainers still need to decide how much unreviewed work they can absorb.

One of the strongest reasons to take Anthropic’s OSS Scanner seriously comes from curl. On October 14, 2026, curl maintainer Daniel Stenberg credited the service with finding a use-after-free vulnerability fixed in curl 8.23.0. His explanation describes a flaw that could become remote code execution under demanding conditions. The project rated it High. Stenberg’s account gives the service something more useful than a launch promise: a named maintainer, a public advisory, and a shipped fix.

That makes the next question practical. If AI can produce useful vulnerability reports faster than security specialists can review them, who should receive the unreviewed findings, and who has time to turn them into safe releases?

OSS Scanner gives eligible maintainers a choice. Our assessment is that it deserves consideration from projects with an established security response process. A team already struggling to process confirmed vulnerabilities should be more cautious about volunteering for another intake channel.

Research checked October 19, 2026. This is a source-based analysis, not a Kingy.ai hands-on scanner test. We did not enroll a project, inspect private reports, or reproduce the vulnerabilities discussed below. Provider results, maintainer evidence, calculations, and our recommendations are identified separately.

What Anthropic’s OSS Scanner does

Anthropic launched OSS Scanner on October 8 as part of its broader Cyber Mission. The company pays for periodic vulnerability scans of accepted open-source projects. It positions the service as a way to get findings to maintainers faster, while continuing human-verified disclosure for projects that need it.

Reports arrive without human review, and repeat-scan frequency varies. The official FAQ gives no weekly commitment. Plan release checks around a schedule your project controls.

The launch describes reports with a reproducer, an explanation, bisection where possible, and a candidate patch where available. It says the service uses Anthropic’s strongest models, including Claude Mythos. That is a description of the service’s capabilities, rather than a promise that every report will include a usable fix. Source: Anthropic’s launch report.

For a maintainer, these are different deliverables. A convincing explanation helps locate a problem. A reproducer helps establish that the problem exists. A patch is a proposal about how to change the software. Acceptance of one should not automatically imply acceptance of the others.

A useful security workflow preserves those distinctions. Record whether the failure reproduced, whether it crosses a supported security boundary, and whether the proposed fix survives regression tests. A single “AI report accepted” checkbox loses information the project will need later.

What the early results establish

Anthropic reports an early expert review of 97 High or Critical findings across 48 projects. Of those, 85 met its coordinated-disclosure standard, 11 were real but duplicated known issues or other findings, and one was invalid. These are results reported by the provider for a selected early sample. They do not measure all severities, all future scans, or the share of existing vulnerabilities the scanner missed. Source: launch evaluation.

Calculated from those counts, about 87.6% met the stated disclosure bar and about 99.0% were real issues when duplicates are included. Either percentage can look impressive in a headline. Neither answers how many new, relevant fixes a particular maintainer will get for an afternoon of triage.

Duplicates illustrate the difference. They are evidence that a scanner detected a real defect, but they can still consume time without improving a release. A finding outside the project’s supported threat model can present a similar problem: the code behavior may be real while the claimed security impact is disputed.

Anthropic’s broader CVD dashboard, dated October 2, reinforces the need to inspect denominators. It lists 29,439 candidates, 6,123 external reviews, and a 92.7% true-positive rate within that reviewed group. Its definition includes duplicates and findings maintainers may not fix. That dashboard predates OSS Scanner’s public launch and covers a broader program. It cannot serve as a production accuracy score for the new service.

The dashboard also distinguishes reporting, acknowledgment, patching, and advisory assignment. Those stages matter because a discovered issue only reduces exposure after an effective remedy reaches the systems that need it. An upstream patch count cannot tell us how many downstream installations are protected.

In its Cyber Mission announcement, Anthropic says it expects a true-positive rate above 90%. Readers should treat that as an expectation. A project evaluating the service should measure its own experience, including disputed severity, duplicates, reproduction failures, and patch quality.

wolfSSL provides a maintainer-side data point

In an October 16 post on its own website, wolfSSL reports that 72 of 74 findings were valid and five became CVEs. That is approximately 97.3% valid, calculated from the maintainer’s figures. wolfSSL also describes an engineering team equipped to process substantial report volume and an existing stack of security testing.

This is useful evidence of fit for that team. It is a poor basis for promising the same experience to a small project without dedicated security reviewers. The maintainers’ capacity is part of the result.

The five CVEs should not be interpreted as five confirmed issues and 69 failures. A CVE identifier, a valid defect, a unique security issue, and a merged fix are separate measurements. The public account does not give enough detail to assign every report to all four categories.

The curl case shows why severity needs context

The official CVE-2026-92392 advisory describes an HTTP/2 upload use-after-free. The affected mainline range is curl 8.12.0 through 8.22.0; 8.23.0 contains the fix. The advisory also lists fixed maintenance-branch versions. Anyone checking a deployed package should consult those exceptions and their distributor’s patch information rather than compare version numbers alone.

Stenberg’s technical account explains the constraint behind the High rating: successful code execution requires a particular combination of circumstances, and he considers a crash the more likely outcome of an attempted attack. He also says the report prompted the team to shorten its release cycle by two weeks.

The result matters without exaggeration. It demonstrates a reported issue that reached a maintainer, survived assessment, and received a release fix. It does not show that every curl deployment was remotely exploitable or that the scanner independently completed remediation.

There is another useful lesson here. A maintainer’s account can explain consequences that a numerical score misses: supported configurations, realistic attacker control, release timing, and the engineering approach used to reduce recurrence. A scanner should supply evidence for that assessment. The project still needs to own the decision.

That responsibility also protects users from rushed fixes. If a report arrives with a plausible patch, reviewers should still ask whether it removes the underlying lifetime error, introduces a new failure path, changes compatibility, or only blocks the supplied reproducer. A regression test should express the intended safety property as clearly as the project can manage.

Free scans still consume maintainer time

The intake problem has a history. In July 2025, Stenberg described the strain of low-quality security submissions, with individual reports involving several curl team members for substantial periods. That older account concerns the project’s wider reporting experience. It is not an assessment of OSS Scanner.

Read alongside the later curl result, it supports a more useful position than either blanket enthusiasm or blanket dismissal. AI-assisted reports can be valuable. The value depends on evidence quality, scope, and the work needed to reach a decision.

Consider two hypothetical batches. One contains ten unique, reproducible defects with narrow patches. Another contains ten genuine defects that the project already fixed last month. Both might earn a high “real bug” percentage. Their value to the current release is very different.

For our assessment, the strongest operational metric is maintainer hours per unique, relevant issue resolved. Track the hours spent rejecting reports as well as the hours spent fixing them. Record regressions discovered during patch review. Otherwise a team may celebrate intake accuracy while quietly losing development time.

Capacity should affect enrollment timing. A release freeze, a maintainer absence, or an unresolved security backlog may make a technically excellent service difficult to absorb. A team can prepare its build and threat model first, then enroll when someone can reliably handle the reports.

OSS Scanner, OSS-Fuzz, and Claude Security have different jobs

Google’s OSS-Fuzz documentation describes continuous fuzzing with distributed execution, fuzzing engines, and sanitizers. That approach repeatedly exercises software to expose failures. An AI audit can investigate code relationships and propose hypotheses to test. These approaches can complement each other; there is no public evidence here that replacing an established fuzzing setup with OSS Scanner would improve coverage.

The current Claude Security product page describes an Enterprise public beta using Claude Mythos 5.1, with verification passes, suggested patches, and workflow integrations. Those product-specific details should not be assumed to apply to OSS Scanner. The open-source program’s model mix and operating process are described separately.

Keep existing tests, fuzzers, dependency review, and human security review in place while evaluating the new channel. When a scanner finds a defect, use the finding to improve the relevant regression test or fuzz target where possible. That converts a one-time discovery into a continuing check the project controls.

Who qualifies, and how enrollment works

The eligibility FAQ targets established, security-critical projects, assessed case by case. New projects and ordinary forks generally do not qualify. Teams should already be able to process verified High and Critical reports.

Enrollment happens through a pull request to the official anthropics/oss-scanner repository. Its public code provides enrollment configuration and supporting tools; the existence of that repository should not be read as a release of the full hosted scanning pipeline.

A maintainer adds a directory at projects/<name>/, a configuration file, and a Dockerfile that prepares the project. Anthropic builds with network access, then conducts the audit without internet access. Tests that fetch dependencies on first execution can therefore fail unless their requirements were installed during setup. The repository recommends validating the configuration and testing the resulting environment before applying.

The current project template uses lowercase dockerfile. Follow that template and its validator when preparing an application. An illustrative configuration looks like this; the addresses and repository below are placeholders.

repo: https://github.com/example/project#main
primary_contact: security@example.org
homepage: https://example.org
dockerfile: .oss-scanner/Dockerfile
threat_model: .oss-scanner/threat_model.md
disabled: false

The template also supports additional report recipients or an armored PGP public key. PGP delivery cannot be combined with the additional-recipient list. A Dockerfile can instead sit beside the enrollment configuration, in which case the corresponding path field is omitted. Consult the live template before submitting; this example has not been run against a real project.

The repository README warns that enrollment email addresses are public. Use a project security alias suitable for publication. Its local environment check also builds with network access, so only run Dockerfiles you trust. An offline audit phase does not make the preceding build phase offline.

A good threat model can save hours of disagreement

Anthropic’s threat-model template asks projects to identify untrusted inputs, important components, ways to exercise the software, severity rules, and exclusions. These are useful prompts for a maintainer even before enrolling.

Write this file for someone who knows programming but has never maintained your project. Identify which actors are already trusted, which operations require privileges, and which boundaries are intended to resist hostile input. A vague instruction such as “find important security bugs” leaves too much room for incompatible assumptions.

For example, a hypothetical document parser might treat every uploaded file as adversarial while excluding a developer-only corpus generator. An administrative tool might intentionally allow privileged users to execute commands. A report claiming command execution in that tool needs to explain how an unprivileged actor gains authority they should not have.

Those examples are our recommendations, rather than reports about any enrolled project. The aim is to make reviewers’ assumptions explicit enough that a scanner can challenge them and a maintainer can evaluate the challenge.

Describe supported configurations precisely. If a feature is optional, say how it is enabled and who normally controls it. If an exclusion reflects a real deployment assumption, explain why. Avoid broad exclusions that silence entire classes of input without documenting the trust boundary.

Also specify the evidence that helps your team decide quickly: the commit tested, a minimal reproducer, required build flags, expected versus observed behavior, and a candidate regression test. Ask for the narrowest patch that fixes the root cause. This gives reviewers something concrete to accept, revise, or reject.

Disclosure, confidentiality, and who receives reports

Unvalidated reports have no 90-day disclosure clock. If Anthropic subsequently validates one manually, its FAQ starts that period at notification of human validation. It may change policy with notice.

The wider CVD policy has its own timing rules, including a default disclosure target and different treatment for actively exploited critical flaws. Maintainers should distinguish receiving an automated candidate from receiving a subsequent human-validation notice, and record the latter in their security tracker.

The OSS Scanner agreement requires enrollment authority, restricts reports to defensive work on the project, and puts review of findings and patches on the participant. It also requires reasonable protection of sensitive reports until the vulnerability is fixed or publicly disclosed. The service is provided as is; proposed patches may be incomplete or break functionality.

Read those terms before sharing a report outside the authorized maintainer group. In particular, a public issue tracker is a poor default destination for a message that may describe an unpatched vulnerability. Decide who receives reports, who can access their attachments, and how the project coordinates an advisory before the first bundle arrives.

Anthropic verifies contacts and project scope and reviews Dockerfile changes. This is a separate check from confirming individual findings.

Pause and withdrawal use configuration pull requests. Assign an owner to outstanding findings and record their disposition separately; stopping intake does not resolve earlier reports.

A practical first-cycle evaluation for maintainers

We recommend evaluating the first scan as a bounded engineering exercise. The plan below is an editorial recommendation, not an Anthropic service guarantee. Set a review budget and name a primary reviewer plus a backup before enrollment. Decide what would justify continuing before the results arrive.

1. Establish a baseline

Record the current security backlog, supported release branches, existing scanner coverage, and available review hours. Capture the repository commit and container build used for the scan. Without that context, a later reproduction failure may be hard to distinguish from a defect that was fixed between scan and review.

2. Classify each report on separate axes

Track reproducibility, uniqueness, supported scope, security impact, and patch status separately. Allow “insufficient evidence” as an outcome. A report can describe a real crash while exaggerating attacker reach; a duplicate can be technically correct while adding little new work worth doing.

3. Reproduce in an isolated test environment

Use the reported revision and build conditions first. Preserve the failure output and enough environment detail for another reviewer to repeat the check. Then investigate whether the issue affects supported versions and realistic configurations. Keep any sensitive artifacts within the project’s established security process.

4. Review the fix independently

Check root cause, affected branches, compatibility, error handling, and regression coverage. Measure how much of the candidate patch survives review. A patch that requires rewriting can still save investigation time, but record that benefit honestly rather than label it merge-ready.

5. Measure cost and outcome together

For each batch, count unique in-scope findings, fixes shipped, duplicate reports, invalid reports, unresolved cases, and reviewer hours. Note severity changes and regressions caught during review. Compare the work with the baseline established before enrollment.

As an illustrative calculation, 20 actionable findings requiring 40 reviewer hours work out to two hours per finding before any additional release work. Ten actionable findings requiring 80 hours work out to eight. These are hypothetical figures, not measured OSS Scanner results. They show why report validity alone cannot answer whether a service fits a team.

6. Decide whether the project can sustain the channel

Continue if the reports reveal relevant defects at a review cost the project can support. Refine the threat model when disagreements repeat. Pause if intake pushes confirmed urgent issues further down the queue. A successful evaluation can end in a decision to wait until the project has more capacity.

Our assessment

OSS Scanner has credible early evidence behind it. The public curl fix and wolfSSL’s account justify a serious evaluation by maintainers who can process the output. Anthropic’s selected validation sample supports optimism about finding quality, while leaving coverage, project-to-project variation, and long-term remediation costs unresolved.

Our recommendation is to enroll when your project has a reproducible build, a written threat model, a private reporting process, and named reviewers with time available. Keep your existing security testing. Judge the first cycle by unique relevant issues resolved and maintainer hours consumed.

For teams that need help with remediation, Claude for Open Source separately advertises six months of Claude Max 20x for qualifying contributors. That program has its own application criteria; participation should not be assumed from scanner enrollment.

Start with the official FAQ, read the agreement, and test your build against the current enrollment tools. Before opening the pull request, put the first review session on someone’s calendar.

The Kingy Brief

Get The Kingy Brief.

AI changes, original tests and one practical thing to try. Fridays at 09:00 Vancouver time.

Free · Double opt-in · Unsubscribe anytime

Privacy policy

Sign up for The Kingy Brief on Beehiiv.

Signup help and newsletter schedule

Signup form provided by Beehiiv. After submitting, check your inbox for "Confirm your subscription to The Kingy Brief" and open its confirmation link. Check Spam or Promotions if you cannot find it.

Fridays at 09:00 Vancouver time: source-checked AI changes, original tests and one practical thing to try. We skip a week when there is not enough verified material. Free. Unsubscribe anytime.

Sign up free