Eligible open-source maintainers can now request free, recurring Claude-powered security scans from Anthropic. Findings arrive as model output, without human review or triage, leaving maintainers responsible for deciding which reports deserve action.
Anthropic announced OSS Scanner on October 8, 2026. The opt-in service uses what the company describes as its strongest models to investigate vulnerabilities, produce reproducers and suggest fixes. Maintainers enroll through a GitHub pull request; no commercial subscription is required.
Projects with an established security response process gain another source of potentially actionable findings. An already overloaded maintainer could find that the service adds work faster than it removes it. Before enrolling, a project needs to assess whether it can support an offline scanning environment and absorb reports that Anthropic has deliberately chosen not to validate first.
OSS Scanner Is Separate From Claude Security
Anthropic describes OSS Scanner as a no-cost service for eligible open-source projects. It is distinct from Claude Security, the company’s commercial code-scanning and patching offering, which the announcement positions around enterprise defense.
Anthropic’s existing coordinated vulnerability disclosure, or CVD, process is separate, too. Under that process, human reviewers validate findings before disclosure. OSS Scanner provides an optional fast track that sends model-generated reports directly to participating maintainers.
The shared Claude branding can obscure that distinction. OSS Scanner’s pipeline includes agents that double-check bugs, propose patches and investigate root causes, but those automated checks do not constitute human review.
Signing up means accepting earlier access to findings and taking on their validation. Reported vulnerabilities have not necessarily cleared Anthropic’s human-reviewed disclosure standard, and suggested patches are not necessarily ready to merge.
Eligibility Depends on Impact and Maintainer Capacity
The OSS Scanner eligibility guidance follows criteria similar to OSS-Fuzz: established projects with a critical impact on infrastructure and user security. Anthropic assesses applications individually, paying particular attention to:
- Exposure to remote attacks, including libraries that process untrusted input.
- The number of users or other projects that depend on the software.
If your project’s significance is not obvious, Anthropic encourages a short explanation. A useful application would describe where the software is deployed, who depends on it and how it handles attacker-controlled input.
Only core maintainers can enroll a project. Anthropic says it will manually verify that status and may contact the project through another channel if necessary.
Acceptance is not guaranteed, and the company may adjust its criteria as demand becomes clearer. The service is explicitly aimed at projects already able to keep up with verified high- and critical-severity reports. It is not intended for those hoping automation will replace security triage.
Enrollment Starts With a Pull Request
The OSS Scanner repository contains the enrollment template and validation tools. A maintainer opens a pull request adding a directory at projects/<name>/, with a configuration file at projects/<name>/project.yaml.
The repository documents these core configuration fields:
repo: the Git repository to clone, optionally with a#branchsuffix. It does not have to be hosted on GitHub.primary_contact: one email address for reports, build failures and other communications.dockerfile: the repository-relative path to the Dockerfile that prepares the scanning environment.
You can omit the dockerfile field if you place a file named Dockerfile beside project.yaml in Anthropic’s enrollment repository. The README uses the lowercase configuration key dockerfile.
Optional fields include homepage, additional report recipients under auto_ccs, a threat_model path and disabled to pause reporting.
Choose contact addresses carefully: the configuration is public. A project security alias may be more appropriate than a personal mailbox. For encrypted reports, the pgp field accepts an armored OpenPGP public key. Anthropic says encryption cannot be combined with auto_ccs; encrypted reports go only to primary_contact.
Before submitting, review the linked service terms. The repository states that using OSS Scanner is subject to those terms, so the enrollment files are not the whole agreement.
The Dockerfile Must Support an Offline Audit
The Dockerfile prepares the environment, installs dependencies and builds the project. That setup runs with network access. The subsequent security audit runs without internet access.
Anything required by the build or tests therefore needs to be fetched during initial setup. A dependency that downloads itself only when a test runs could leave the scanner with an incomplete environment.
Anthropic recommends building the image locally and checking that tests pass inside it. Keeping the Dockerfile in your own repository is the preferred arrangement because you can update it without another pull request to Anthropic’s repository.
The README recommends two checks before enrollment:
- Run
tools/validate.pyto check the project configuration. - Run
tools/check <name>to build the environment and open a shell in the completed image without network access.
These tools require Git, Docker and Python 3 with PyYAML. An optional --qemu mode runs the check in virtual machines and requires Linux on x86-64 with QEMU.
Be careful where you run these checks. tools/check runs the Dockerfile with network access, and the repository warns that even the virtual-machine version can reach services on your computer and local network. Use trusted projects or an appropriately isolated machine.
After acceptance, Anthropic builds the project on its infrastructure and emails the primary contact if that build fails.
A Threat Model Can Prevent Misleading Reports
A threat-model file is optional, but it is one of the most useful ways to make reports fit your project’s security expectations. Without it, Anthropic says the scanner will make its own judgments about corner cases.
The file has no required format. It can explain:
- Which inputs are adversarial and which components are in scope.
- What behavior is intentionally trusted or outside the project’s security guarantees.
- How the project distinguishes critical, high, medium and low severity.
- What reproduction evidence and patch format maintainers find useful.
- How related findings should be grouped or deduplicated.
A scanner that misunderstands the trust boundary can identify real behavior while misclassifying its security significance. For example, whether an authenticated operation represents a privilege escalation depends on what that user was already authorized to do. Explicitly documenting those permissions gives the model a better basis for assessment, although it does not guarantee correct results.
Sources
- OSS Scanneranthropic.com
- OSS Scanner eligibility guidancered.anthropic.com
- OSS Scanner repositorygithub.com
