AI security and open-source maintenance

Anthropic OSS Scanner: free security scans, real triage work

•Make Better Editorial

Anthropic offers eligible open-source maintainers free recurring AI security scans. Here is how enrollment works, why findings need verification, and what the workflow costs maintainers.

On October 8, 2026, Anthropic launched OSS Scanner, an opt-in service that periodically scans eligible open-source projects for potential security vulnerabilities using its strongest AI models. The scans are offered at no cost to accepted projects. The key practical detail is not the price, however: reports from this fast-track service are model-generated and are not reviewed by a human before reaching project maintainers. That changes the amount of verification and prioritization the recipient must do.

What Anthropic actually launched

Anthropic says the service builds on its work finding vulnerabilities in open-source software, including Project Glasswing. It is intended for projects with substantial infrastructure or user-security importance. Enrollment is not a blanket promise that any public GitHub repository can receive a scan: eligibility resembles criteria used by OSS-Fuzz, and Anthropic decides case by case. The company describes the output as a way to receive potential findings sooner, rather than waiting for the conventional human-reviewed disclosure process.

Important distinction

An AI-generated vulnerability report is not the same as a validated security issue. Anthropic explicitly warns that its unreviewed reports can contain mistakes or findings that do not fit a project's actual threat model.

How project enrollment and scans work

  1. Confirm that the project is likely eligible and that the core maintainers want to opt in. Start with Anthropic's official eligibility guidance rather than assuming acceptance.
  2. Open a pull request to Anthropic's oss-scanner repository adding a projects/<name>/ directory. Supply project.yaml with the repository URL and primary security-contact address.
  3. Provide a Dockerfile that can build the project and, preferably, a threat_model.md describing security boundaries, realistic severity levels and out-of-scope components.
  4. Run the repository's validation and build-check commands before enrollment. Check that the build is reproducible and works without Internet after dependency setup.
  5. After approval, review emailed findings. Each report is intended to include a reproducer, explanation and candidate patch when available; verify these independently before labeling or disclosing a vulnerability.

The published configuration examples show why onboarding is more than clicking a button. The scanner must be able to build and analyze the actual software. Its setup phase may use network access to obtain dependencies; the subsequent scan runs without Internet access in an isolated environment. Anthropic also notes that contact email addresses in project.yaml are public, so maintainers should use an appropriate security alias rather than a private address.

Free scanning does not mean zero operational cost

Scanner output versus maintainer responsibility

OSS Scanner providesMaintainers still need to do
Periodic AI-generated vulnerability candidatesDecide whether each report applies to the supported branch and threat model
Reproduction steps and technical explanationReproduce the behavior in a safe test environment
A proposed patch where availableReview patch safety, regression risk and test coverage
Earlier delivery of unreviewed reportsTriage priority, coordinate fixes and disclosure as appropriate
Make Better analysis

For a small open-source team, the limiting factor may be triage capacity rather than scan frequency. A useful way to evaluate the service is to track the number of reports received, the share independently reproduced, the time needed to investigate them, and the number of accepted fixes. These are suggested maintainer metrics, not performance results claimed by Anthropic. A free tool can create a real workload if every unverified alert interrupts the release process.

A practical review workflow

  • Use a dedicated security inbox or issue queue for scanner reports; restrict access before the finding is verified.
  • Record each report's affected version, proposed severity, reproduction status, owner and remediation decision.
  • Check whether the finding is reachable in the application's actual deployment and matches the project's threat model.
  • Test the proposed fix and watch for regressions; never deploy a suggested patch solely because it came from a scanner.
  • Measure triage effort for several scan cycles before expanding the process. Keep public disclosure decisions under the project's normal security policy.

The OSS Scanner documentation also suggests optional threat-model instructions to help align findings with the maintainers' definition of high or critical severity. That is particularly important for software where a vulnerability in an authenticated, administrator-only component has a very different impact from a remotely reachable defect. An AI assessment should support, not replace, that context.

Who should consider it?

The strongest fit is a qualifying, security-sensitive open-source project with maintainers able to reproduce reports and handle patches. Teams without a clear build process, security contact or triage ownership should establish those basics first. The service is an optional early-report channel, not an endorsement that every finding is exploitable or that production systems are secure after a scan.

Bottom line

Anthropic OSS Scanner could give eligible maintainers useful early security signals at no financial charge. The responsible workflow is still build, scan, reproduce, prioritize, test and fix. Success depends on what the maintainers validate and remediate—not how many AI-generated reports arrive.

Explore related Make Better resources

Sources & useful resources