Anthropic's free OSS Scanner sends maintainers unreviewed vulnerability reports

Anthropic launched [OSS Scanner](https://www.anthropic.com/research/launching‑opt‑in‑vuln‑finding‑service‑for‑open‑source) on October 8 as an opt‑in service for established open‑source projects with a critical impact on infrastructure or user security. Enrolled projects receive recurring scans from Anthropic's strongest models at no cost. The practical distinction is speed: the reports go directly to maintainers without Anthropic first performing human review or triage. Each report is intended to include an explanation, a reproducer and a proposed patch when one is available. Anthropic says the model may still be wrong, inflate severity, misunderstand a project's threat model or suggest a patch that breaks functionality. Its launch post says the company expects a true‑positive rate above 90%, but that is a provider expectation rather than a published independent measurement of the live service. That makes enrollment a capacity decision as much as a security decision. A project that cannot promptly reproduce, prioritize and contain sensitive findings may be better served by Anthropic's slower coordinated‑vulnerability‑disclosure path, where humans verify reports before maintainers receive them. The [Cyber Mission announcement](https://www.anthropic.com/news/anthropic‑cyber‑mission) says the fast track was created because some maintainers explicitly asked for raw findings and had enough capacity to triage them.

The [current FAQ](https://red.anthropic.com/oss‑scanner/) says Anthropic decides eligibility case by case using criteria similar to Google's OSS‑Fuzz: exposure to remote attacks and the number of users or downstream projects are among the factors. The service is aimed at established projects that matter to infrastructure or user security. A popular repository is not automatically eligible, and Anthropic says it may adjust the criteria as enrollment grows. The applicant must be a core maintainer or be authorized by the lead maintainer. If the project is maintained through an employer or other organization, the applicant must also have that organization's permission. Anthropic manually validates maintainer status and can contact project leadership through another channel before accepting an enrollment. Those checks matter because enrollment authorizes a third party to build and analyze the project's source and send sensitive security findings to named contacts. A contributor who can open a pull request does not necessarily have authority to make that decision for the project.

A maintainer enrolls by opening a pull request to Anthropic's public [OSS Scanner repository](https://github.com/anthropics/oss‑scanner). The project directory contains a `project.yaml` file with the repository URL, the primary contact email and a repository‑relative path to a Dockerfile. A project can optionally include a threat‑model document to tell the scanner which assets and trust boundaries matter. The Dockerfile is the operational contract. It must install dependencies and build the target so the audit agent can work fully offline. Anthropic says scanning agents run in hardened sandboxes with internet access disabled. Maintainers should therefore test the image from a clean environment, pin dependencies where practical and ensure the build does not rely on credentials, private package endpoints or network downloads at scan time. The contact field is equally consequential. Findings are emailed to the primary contact and optional copied recipients. Projects should use a monitored security address with a documented handoff rather than a personal inbox that can become stale when a maintainer leaves.

Anthropic's [service terms](https://red.anthropic.com/oss‑scanner/terms/) classify reports and related material as confidential. Participants may use them to identify, assess and fix problems in the enrolled project and may share them with authorized maintainers. The reports cannot be used to attack or gain access to another system. Because the fast‑track reports have not been human‑validated, Anthropic says it will not automatically publish them and does not initially impose a 90‑day disclosure deadline. If Anthropic later validates a report through its existing coordinated‑disclosure program, its FAQ says disclosure may begin 90 days after the maintainer is notified of that validation. Anthropic also reserves the possibility of adding a deadline for some high‑severity reports later, with notice and an opt‑out. Maintainers should keep those two states separate in their tracker: `model‑reported` means a confidential lead awaiting project triage; `human‑validated/CVD` means Anthropic has moved it into a separate disclosure process. Treating every raw result as a confirmed vulnerability can create unnecessary emergency work, while treating it as disposable model output can leave a real flaw unaddressed.

Before enrolling, a project should name the people who will receive reports, reproduce them in an isolated environment, judge severity against the project's actual deployment model and review proposed patches. The queue should preserve the report identifier, affected revision, reproducer result, severity decision, patch review and disclosure state without copying sensitive details into public issues. A patch suggestion is evidence to inspect, not a trusted fix. Run the project's normal tests, add a regression test for the reproduced flaw and have a maintainer review the security boundary the patch changes. If a report cannot be reproduced, record the environment and assumptions tested rather than closing it solely because the model's severity label seems wrong. Enrollment is reversible. The FAQ says a project can pause automated reports by setting `disabled: true` in its configuration or opt out by deleting its project directory through a pull request. Paused projects return to Anthropic's standard human‑reviewed disclosure path. That provides a practical stop rule: pause when the untriaged queue exceeds the team's capacity or when report quality causes verified work to be delayed. *Figure: The four gates between an OSS Scanner enrollment and a maintainer shipping a verified fix. Sources: [Anthropic's launch post](https://www.anthropic.com/research/launching‑opt‑in‑vuln‑finding‑service‑for‑open‑source), [OSS Scanner FAQ](https://red.anthropic.com/oss‑scanner/), [enrollment repository](https://github.com/anthropics/oss‑scanner) and [service terms](https://red.anthropic.com/oss‑scanner/terms/). Figure by OpenTools Team; no third‑party expressive material used.*