Anthropic OSS Scanner: Should Your Open-Source Project Enroll?

On October 8, 2026, Anthropic announced OSS Scanner, an opt-in service offering recurring AI vulnerability scans at no charge to eligible critical open-source projects. For maintainers, it opens a route to findings without waiting for Anthropic’s human validation—but leaves the project responsible for deciding which reports warrant a fix.

Anthropic says reports include a self-contained reproducer and an explanation, with analysis of when the bug was introduced where possible and a candidate patch when available. The reports are model-generated, without human review. This guide’s recommendation is to apply only when a named maintainer can own that additional review queue.

Decide whether your project is ready

Acceptance is case-by-case. Anthropic’s eligibility criteria emphasize established projects important to infrastructure and user security, exposure to remote attacks, and the number of users or dependent projects. Anthropic also verifies maintainer authority; an open-source license alone does not guarantee admission.

Use the following readiness comparison as editorial guidance, not an additional set of Anthropic admission rules.

The service is free, but maintainer labor remains a project cost. Scans recur, yet the FAQ sets no fixed interval: frequency depends on pipeline demand, project use and other factors. Do not plan a release gate that assumes every commit will be scanned.

Prepare configuration, build and threat model

Enrollment is a pull request to the OSS Scanner repository adding projects/<name>/project.yaml. The configuration template requires repo and primary_contact, plus a Dockerfile in exactly one location: your project repository, referenced by lowercase dockerfile, or beside the enrollment file, with that key omitted.

For the in-project option, this illustrative configuration uses placeholders; replace them and provide the referenced files:

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

Use lowercase dockerfile even though the FAQ labels the field differently. The validator rejects unknown keys and operator-only scheduling or budget fields; adding a cadence setting does not enable per-commit coverage.

Choose a security alias suitable for publication: configuration addresses are public. Optional OpenPGP delivery takes a public key and sends encrypted reports only to primary_contact; it cannot be combined with auto_ccs. Plan who can receive and handle those reports using the documented delivery options.

The Dockerfile template places the checkout at /src and installs dependencies with network access before an offline audit. Fetch needed test resources during setup. Importantly, the example lets its test command warn on failure without stopping the image build. Configuration validity, build success and passing tests are three separate checks.

Before submitting, follow the README’s local checks: tools/validate.py checks enrollment configuration; tools/check <name> builds the environment and opens an offline shell where you can run your tests. These require Git, Docker and Python 3 with PyYAML. The build phase has network access, including to local services, so use trusted project inputs and an appropriate build environment.

The optional threat-model file should describe untrusted inputs, relevant components, exclusions, test entry points and the project’s severity rubric. Our recommendation is to version it with the code and consult it when a report’s severity is disputed. Its example severity rules are prompts to adapt, not universal ratings.

Read the evaluation as a selected sample

Anthropic reports an early evaluation in which external penetration testers reviewed 97 high- or critical-severity findings across 48 projects. It says 85 met its coordinated vulnerability disclosure (CVD) bar, 11 were real but duplicated known issues or other scan findings, and one was invalid.

Calculation from those reported counts: 85 ÷ 97 = 87.6% met the CVD bar; 11 ÷ 97 = 11.3% were duplicates; 1 ÷ 97 = 1.0% was invalid, rounded to one decimal place.

These are distinct outcomes, not an overall accuracy score. The selected sample does not establish performance across all reports, how many vulnerabilities the scanner misses, or how much maintainer time it saves. A real duplicate may still consume review time without adding a new fix.

Keep findings separate from accepted fixes

Reports arrive without human review; maintainers decide which findings and candidate patches are ready to act on. The service terms warn that reports can miss issues or misjudge severity, and that suggested patches can break functionality. They require review before relying on a report or sharing it.

A proposed maintainer-led triage workflow:

1. Record and reproduce. Keep the report ID, affected revision and reproduction result in a private record. Use an isolated test environment you are authorized to assess. If reproduction fails, mark the finding unresolved pending investigation rather than automatically dismissing it.

2. Deduplicate and assess impact. Compare with existing reports and fixes. Check the claimed behavior against the project’s threat model, reachable inputs and supported deployment conditions. Record maintainer-assessed severity separately from the model’s label.

3. Review the candidate patch. When a finding is confirmed, establish a regression test and inspect the proposed change for behavior it could break. A supplied patch is a starting point, not a merge decision.

4. Assign remediation and track effort. Name a release owner; record time spent, duplicates, confirmed findings and unresolved backlog. Keep existing testing and review controls: a quiet report stream is not evidence that the code is secure.

For capacity planning, an advisory workload estimate is report count × average review time + patching time + release time, over the same reporting period. Populate it from your own records. Without those inputs, the launch evidence cannot tell you whether enrollment will fit your available hours.

Understand disclosure and how to pause

Automated, unvalidated findings do not start a 90-day disclosure clock. If Anthropic later human-validates a report and notifies the project, the scanner terms allow disclosure under its CVD policy starting 90 days after that notice. Future disclosure-rule changes require advance notice; this is not a promise of permanent nondisclosure.

The separate CVD policy describes human-reviewed findings and pacing submissions to maintainer capacity, with its own timing rules and exceptions. The scanner terms limit report use to assessing and fixing the enrolled project, permit sharing with authorized maintainers, and require secure handling. Do not treat raw report emails as ordinary public issues.

If the added workload becomes unsustainable, the documented controls are a pull request setting disabled: true to pause reports, or removal of the project’s enrollment directory to withdraw. These are enrollment changes, not a documented instant-stop guarantee.

The practical next step is to name the reviewer, prepare a usable offline environment and read the current service terms before opening an enrollment PR. If your goal is access to advanced models for your own security workflow instead of receiving hosted scan reports, that is a different decision covered in RohitAI’s Cyber Verification Program guide.

Methodology: This AI-assisted decision guide draws on Anthropic’s announcement, FAQ, service terms and repository documentation checked on October 8, 2026. The announcement date comes from Anthropic’s research index. Readiness and triage recommendations are analysis; percentages are calculations from vendor-reported counts. No enrollment, scan, build, reproducer or patch was tested.