Anthropic's OSS Scanner: Who Triages Unreviewed Vulnerability Reports?

In October 2026, Anthropic launched OSS Scanner, allowing eligible open-source projects that opt in to receive model-generated vulnerability reports directly. The fast track has no human review or triage before delivery, so reports may be wrong. Anthropic is also keeping its existing coordinated vulnerability disclosure (CVD) path, where external security researchers validate findings before maintainers are notified. The consequential change is not simply another scanner: once vulnerability discovery outpaces validation capacity, someone must take responsibility for the first review.

Candidate volume exceeds review capacity

Anthropic says that over the previous six months its models produced more than 29,000 candidate vulnerabilities while its team could manually review and triage only about 6,000. Anthropic also says some maintainers who received initial reports asked for a bulk submission of all unverified candidates and proposed patches; by launch, nearly 5,000 unvalidated reports had been sent directly at maintainers’ request. These are activity figures reported by Anthropic. They describe its workload and workflow choices, not an independent quality evaluation.

OSS Scanner formalizes that “send the candidates and let the project assess them” option. Anthropic says reports are generated by models and may include reproduction steps, an explanation, a possible bisection for when a bug was introduced, and a candidate patch when available. Projects must determine whether a report reproduces, fits their threat model, duplicates a known issue, and warrants action.

Two disclosure paths place responsibility differently

Anthropic is maintaining two paths that should not be conflated:

1. Standard CVD: Models produce candidates, then external security researchers reproduce issues, assess whether they are real vulnerabilities, and rate severity before validated reports go to maintainers. This path absorbs much of the verification work and is better suited to projects that cannot process a large stream of raw candidates themselves.
2. OSS Scanner fast track: Core maintainers of eligible projects opt in by submitting configuration. Model-generated reports go directly to them without prior human review. Projects can provide a threat model, severity rubric, and deduplication preferences, and they can pause or leave. They still own reproduction, classification, and scheduling after reports arrive.

This choice is not right for every open-source project. Anthropic’s FAQ says it will assess eligibility case by case and positions the service for projects already able to handle verified high or critical vulnerability reports. If maintainers cannot keep up with credible high-severity reports, adding unvalidated candidates may bury important signals in the queue.

How projects enroll in the fast track

This is not an instant scanner that anyone can start by pasting a Git URL. Core maintainers submit project configuration that specifies the repository, report recipients, and a Dockerfile. The Dockerfile prepares dependencies and the build process so the scanning agent can inspect the code offline in an isolated environment. A project can also provide a threat model to explain which inputs, trust boundaries, and deployment conditions it actually needs to defend.

An offline build can limit network access during scanning, but it does not remove every risk. Maintainers still need to review whether build commands run untrusted scripts, whether the supplied Dockerfile is safe, and whether more than one person monitors the report inbox. The service documentation also says enrollment details are public on GitHub. Use a security contact that the project is comfortable publishing, rather than a personal address. If a report includes a reproducer or patch, validate it in an isolated environment instead of running it against production.

Anthropic says fast-track reports do not follow the fixed public disclosure timeline used by its usual coordinated vulnerability disclosure process, and Anthropic will not publish these reports. The receiving project still decides how to remediate and disclose an issue. That gives maintainers earlier access to leads, while leaving them responsible for coordinating private reports, releases, and security advisories. Before enrolling, confirm owners for the security inbox, deduplication, patch branches, and communication with external researchers.

What the 97-finding sample does—and does not—show

Anthropic says it asked the expert penetration testers who review its CVD findings to check 97 high and critical findings from an early OSS Scanner version across 48 projects. Eighty-five met Anthropic’s CVD bar; 11 of the remaining findings were real but duplicated or otherwise not reportable, and one was invalid. This result is notable, but it is a severity-selected sample of 97 findings. It is not a random sample, an overall precision estimate for the 29,000-plus candidate pool, or a measure of all unreviewed direct reports.

Anthropic’s public CVD dashboard and disclosure ledger cover a separate, broader coordinated disclosure program. As of October 2, 2026, the dashboard lists 6,123 findings reviewed by external security firms and 5,674 confirmed as valid, alongside direct reports to maintainers that may contain false positives. Those totals span multiple models and CVD workflows; they cannot be used as an accuracy estimate for projects newly enrolling in OSS Scanner. The dashboard and ledger document the broader program’s review sources and disclosure states, but do not independently evaluate the new service’s full candidate stream.

Independent evidence is still missing on the new service’s overall candidate precision, false-positive rates by severity or project type, whether maintainer time is reduced, and whether reports ultimately lead to fixes or fewer recurring vulnerabilities. Those gaps matter when deciding whether to enroll; a report that includes a reproducer or a high model-assigned severity is not itself a verified conclusion.

Anthropic also published feedback from some participating maintainers. For example, a wolfSSL maintainer said all but two of 74 received reports were valid and that five later became CVEs; the curl maintainer said OSS Scanner found several issues worth addressing. These accounts show that some projects have incorporated reports into their existing workflows. They remain examples published by the service provider, however: they do not include a control group, the full intake population, or aggregate data that outside reviewers can independently reproduce. They cannot stand in for an overall quality evaluation.

Candidate quality and maintainer workload are separate questions. Even if most reports are reproducible, duplicates, inflated severity, or patches that need extensive review can still add triage work. A useful operational evaluation would report reports per project per week, time to first review and reproduction, duplicate and invalid rates, fix completion after confirmation, and response times before public disclosure. The public data available so far do not answer these workload questions.

Maintainers need a triage contract they can sustain

Before enrolling, a project can make the workflow explicit:

• Assign an owner and backup. A monitored security address needs a responsible reviewer and a fallback for absences or overdue reports. Do not route reports only to an unattended personal inbox.
• Define the threat model and severity rubric. State which inputs, deployment conditions, and trust boundaries are in scope, as well as which issues do not constitute an exploitable risk in this project. This can guide model reports, but it does not replace verification.
• Preserve an evidence trail. Record the report ID, version or commit, reproduction environment, preconditions, impact, deduplication result, remediation decision, and disclosure state. Keep “model asserted,” “maintainer reproduced,” and “patched” as separate statuses.
• Set capacity and exit conditions. Estimate how many reports the team can review each week, and pause intake if the queue ages, false-positive costs become too high, or remediation capacity is unavailable. Receiving more leads does not guarantee faster fixes.

After a report arrives, a small set of explicit states can prevent “delivered” from being mistaken for “fixed”: awaiting triage, reproduction needed, confirmed and scheduled, duplicate or out of scope, patched and awaiting release, and publicly disclosed. Record the tested commit, reproduction environment, affected versions, external dependencies, and patch verification for each report. This is a suggested maintainer workflow, not a feature Anthropic says the service automatically tracks for projects.

The point is not to treat the model’s judgment as a new authority. Every additional lead needs an owner, a verification step, and a terminal status. For a deeper look at reproducible evidence, see how MobileCybench uses executable probes to validate vulnerability claims. For the broader boundaries around agent identity, tools, and threats, read Enterprise AI Agent Security and the AI Agent guide.

OSS Scanner turns a request that some maintainers had made individually into an opt-in delivery model. For critical infrastructure projects with capacity to validate reports, it may shorten the path from candidate to maintainer. For projects with limited triage resources, unreviewed reports may become another burden. The outcomes worth tracking therefore extend beyond candidate counts: reproducibility, deduplication cost, maintainer response time, fixes completed, and the share of projects that pause intake.

Sources

• Anthropic: Launching an opt-in vulnerability-finding service for open-source software — launch details, Anthropic-reported activity figures, and the 97-finding early validation sample.
• OSS Scanner repository — enrollment configuration, build and offline scanning approach, and report delivery.
• OSS Scanner FAQ — project eligibility, threat models, pausing, and unvalidated-report policy.
• CVD dashboard and disclosure ledger — broader CVD program statistics and public disclosure records as of 2026-10-02.