Markdown edition

# How open-source maintainers can enroll in Anthropic’s OSS Scanner and triage its reports

> A documentation-based guide to Anthropic OSS Scanner eligibility, enrollment, offline build setup, and safely validating model-generated reports that have not received human review.

By BIG CHANGE Editorial

Published: 2026-10-09T17:01:09.330Z
Updated: 2026-10-09T17:01:09.330Z
Canonical: https://bigchange.ai/blog/anthropic-oss-scanner-maintainer-enrollment-triage-guide

![A seated maintainer studies a blank report sheet beside a dark, unbranded monitor.](https://bigchange.ai/api/media/file/anthropic-oss-scanner-maintainer-triage-hero-v1.png)
Conceptual illustration of a maintainer reviewing an unverified scanner report; it does not depict a real report, finding or test. AI-generated illustration by BIG CHANGE.

Anthropic’s OSS Scanner is a free, opt-in service that periodically scans accepted open-source projects with its strongest models. Anthropic describes it as a fast-track for receiving reports as soon as projects are scanned, alongside its human-reviewed coordinated disclosure process. Reports are model-generated and sent without human review. That makes enrollment a capacity decision: the project needs maintainers who can independently validate security findings and decide what to fix.

This guide is for core maintainers of security-critical open-source projects. It walks through the documented enrollment path and a careful way to handle a report. The instructions are based on Anthropic’s documentation checked on 9 October 2026. BIG CHANGE did not enroll a project, run the scanner, or reproduce a vulnerability.

## First decide whether your project can handle the reports

Anthropic says it considers established projects with critical impact on infrastructure or user security. Its stated signals include exposure to remote attacks and how many users or other projects depend on the software. It reviews requests case by case and manually checks that the applicant is a core maintainer. Anthropic says the service is intended for projects already able to keep up with verified high- and critical-severity reports.

Before opening a pull request, answer these questions with your project’s own evidence:

1. Are you a core maintainer who can submit the enrollment request and receive confidential security reports?
2. Does the project meet the critical-impact criterion? Can you point to its role in infrastructure or user security, remote-input exposure, or downstream use?
3. Do you have people and a process to review additional unvalidated reports, reproduce findings safely, coordinate disclosure when needed, and maintain fixes?
4. Can you supply a repeatable build environment that includes the dependencies and tests needed for an offline audit?
5. Is the listed contact address suitable for receiving sensitive reports? The project configuration is public, so use a security alias or another address you are comfortable publishing.

If your team cannot review reports promptly, Anthropic says its existing coordinated vulnerability disclosure process will continue to provide human-verified reports for projects that need that route. OSS Scanner is an additional fast track, not a replacement for your security process.

## Prepare the enrollment request

The input is your repository and maintainer authority, a configuration file, and a build recipe. Enrollment is requested by a pull request to Anthropic’s [`oss-scanner` repository](https://github.com/anthropics/oss-scanner), adding `projects/<project>/project.yaml`. Start from Anthropic’s [project template](https://github.com/anthropics/oss-scanner/blob/main/templates/project.yaml) and read the live [OSS Scanner FAQ](https://red.anthropic.com/oss-scanner/) before submitting; repository instructions can change.

The documented required configuration fields are:

| Field | What to provide |
| --- | --- |
| `repo` | An HTTPS Git repository URL to clone. Anthropic’s template allows a `#branch` or `#tag` suffix to pin a revision. |
| `primary_contact` | One email address for reports and questions. It is public in the configuration. |
| Dockerfile location | A repo-relative Dockerfile path in `project.yaml`, or a file named `Dockerfile` alongside `project.yaml` in the enrollment repository. Supply exactly one of these options. |

Optional fields include `auto_ccs`, `homepage`, `threat_model`, `pgp`, and `disabled`. Anthropic says a PGP public key encrypts emailed reports and cannot be combined with `auto_ccs`; with PGP configured, reports go only to `primary_contact`. Treat all configured email addresses as public. `disabled: true` pauses reports while retaining enrollment; removing the project directory withdraws it.

### Make the build useful for an offline audit

The Dockerfile should set up the environment, install dependencies, and build the project. Anthropic says the initial build runs with network access, but the audit runs without internet access. Dependencies or test assets needed by the audit therefore must be fetched during that initial Dockerfile setup.

Anthropic recommends putting the Dockerfile in your own repository, where you can update it without another enrollment-repository change. A threat model is optional but strongly recommended. Use it to explain which code and inputs matter, what is out of scope, how your project rates severity, how findings should be deduplicated, and what a useful proof of concept or candidate patch looks like. This is guidance for the scanner, not proof that a report is correct.

Before submitting, Anthropic recommends two checks:

1. Run `tools/validate.py` to check the project configuration.
2. Build and test the Dockerfile locally. The repository’s `tools/check <name>` builds the image the way the scanner does and opens a shell in the finished image with networking disabled. Anthropic also documents `tools/check --qemu <name>` for its QEMU-based setup.

These checks are optional recommendations in the enrollment instructions, not proof that Anthropic will accept the project or that a later finding is valid. The repository says `tools/check` runs the project Dockerfile with network access during the build. Its security note warns that the build can reach services on your computer and local network; use a machine or isolated environment appropriate for a Docker build you trust. The standard local check requires Git, Docker, Python 3 and PyYAML. The `--qemu` variant instead uses x86-64 Linux and QEMU in place of Docker, alongside Git, Python 3 and PyYAML.

## Submit, then wait for the project decision

Open a pull request adding the project configuration and any required Dockerfile or optional threat model. Include a short explanation of the project’s critical security importance when it is not self-evident. Anthropic manually validates core-maintainer status and may contact the project through another route if it is uncertain.

Anthropic’s public enrollment materials describe case-by-case decisions; they do not state an acceptance guarantee or a response-time SLA. Do not interpret a submitted pull request as acceptance. If accepted, Anthropic says it first scans the project, then sends a bundle of reports by email to `primary_contact` and any configured CCs. It plans regular scans afterward, but scan frequency can depend on its project pipeline and how widely a project is used.

The service itself is no-cost. The project still supplies maintainer time for eligibility details, building and maintaining the container, report triage, reproduction, disclosure coordination, and any remediation.

## Triage every report as a lead, not a verdict

Anthropic says reports can include a self-contained reproducer, an explanation, a bisection to locate when a bug was introduced where possible, and a candidate patch where available. Reports are generated by models without human review or triage. The launch materials warn that reports can be wrong; Anthropic specifically notes that severity can be inflated or the scanner can misunderstand a project’s threat model. A suggested fix is not an approved fix.

Use your normal security process and keep each finding at the report’s actual evidence level:

1. **Preserve and scope the report.** Keep the original email and report identifier in the project’s restricted security workflow. Check that the affected repository, branch, commit, component, and claimed threat model match your project. Limit access to people who need it.
2. **Read the claim before running anything.** Identify the alleged flaw, affected code path, attacker-controlled input, required permissions or conditions, and claimed impact. Compare these with your own architecture and threat model. If the report provides no usable reproduction details, ask Anthropic for clarification rather than inventing missing steps.
3. **Reproduce in an isolated environment you control.** Use a disposable checkout or VM, a known revision, and the documented reproducer. Do not run a model-suggested patch or proof of concept against production, real user data, or a third-party system. Keep network access disabled unless your own test procedure requires it and you have deliberately bounded that access.
4. **Check the result independently.** Confirm the behavior with the project’s tests or a minimal regression test. Verify the claimed affected versions and whether the issue is reachable under the project’s actual trust boundaries. Distinguish “reproduced,” “plausible but not reproduced,” “duplicate,” and “not applicable” in your internal record.
5. **Review any bisection and patch as proposals.** Confirm the cited commits and code changes yourself. Apply a candidate patch only on a branch, inspect the diff, run relevant tests, and add a regression test where appropriate. Do not merge solely because the report labels a severity or supplies code.
6. **Coordinate disclosure and remediation.** Follow your existing security policy and the relevant ecosystem’s disclosure process. Anthropic says unvalidated OSS Scanner findings do not carry a 90-day coordinated-disclosure period and will not be made public by Anthropic. If Anthropic later validates a report manually through its CVD program, its FAQ says a 90-day period may start from notification of that human validation. That does not remove your own legal, contractual, or ecosystem responsibilities.
7. **Send bounded feedback.** Anthropic invites maintainers to reply to report emails with feedback. If a finding is invalid, duplicated, mis-prioritized, or misunderstood the threat model, identify the specific point and evidence so the report can be corrected.

If your capacity changes, the FAQ documents two controls: set `disabled: true` in a pull request to pause reports, or remove the project’s directory to withdraw. Confirm the change through the repository before assuming scanning has stopped.

## What Anthropic’s validation numbers do—and do not—show

Anthropic reports that expert penetration testers examined 97 critical- and high-severity findings from an early scanner version across 48 projects. It says 85 met its CVD bar; of the remaining 12, 11 were real but duplicates or otherwise overlapping findings, and one was invalid. Anthropic also cites maintainer feedback and says it expects a true-positive rate above 90%.

These are Anthropic’s reported validation results and expectation, not an independent replication or a guarantee for any new report. The tested set was selected from early scanner outputs and covered 48 projects; it does not establish that every future result, severity rating, or patch is correct. The useful operational conclusion is narrower: the system may surface reports faster, while maintainers still own validation, prioritization, and fixes.

## The big change

OSS Scanner creates an opt-in route for eligible open-source maintainers to receive periodic, no-cost, model-generated security reports before human review. The choice is not simply whether to accept a free scan: it is whether the project can safely absorb and validate a faster stream of unverified findings.

## Sources & further reading

- [Anthropic OSS Scanner FAQ and enrollment instructions](https://red.anthropic.com/oss-scanner/) — eligibility, maintainer verification, configuration fields, build requirements, report cadence, disclosure policy, and opt-out controls.
- [Anthropic’s `oss-scanner` repository](https://github.com/anthropics/oss-scanner) — enrollment pull request path, validation and local build-check tools, and security considerations.
- [Project configuration template](https://github.com/anthropics/oss-scanner/blob/main/templates/project.yaml) — current example fields for repository, contact, Dockerfile, threat model, encryption, and pausing reports.
- [Anthropic: “Launching an opt-in vulnerability-finding service for open-source software”](https://www.anthropic.com/research/launching-opt-in-vuln-finding-service-for-open-source) — launch-stage description, model-generated report contents, and Anthropic’s attributed early validation figures.
- [Anthropic: “Introducing the Anthropic Cyber Mission”](https://www.anthropic.com/news/anthropic-cyber-mission) — broader program context and distinction between OSS Scanner reports and human-reviewed disclosure.

*Documentation-based guide, checked 9 October 2026. BIG CHANGE did not enroll, run a scan, or reproduce a vulnerability.*

## Sources

- [Anthropic OSS Scanner FAQ and enrollment instructions](https://red.anthropic.com/oss-scanner/) — Official FAQ for eligibility, maintainer verification, enrollment fields, report contents and cadence, disclosure, pause, and withdrawal.
- [Anthropic OSS Scanner repository](https://github.com/anthropics/oss-scanner) — Official enrollment README describing config, build/offline audit boundary, local validation tools, prerequisites, and Docker security considerations.
- [Anthropic OSS Scanner project.yaml template](https://github.com/anthropics/oss-scanner/blob/main/templates/project.yaml) — Official example of required and optional enrollment configuration fields.
- [Launching an opt-in vulnerability-finding service for open-source software](https://www.anthropic.com/research/launching-opt-in-vuln-finding-service-for-open-source) — Anthropic launch account for model-generated reports, their contents, case-by-case enrollment, and vendor-reported early validation statistics.
- [Introducing the Anthropic Cyber Mission](https://www.anthropic.com/news/anthropic-cyber-mission) — Anthropic announcement describing OSS Scanner in the wider Cyber Mission and its distinction from human-reviewed CVD reporting.