Anthropic's oss-scanner enrolls critical open-source projects via pull request, builds them in isolated offline VMs, and emails maintainers model-generated vulnerability reports with reproducers and proposed patches.
| Tool | anthropics/oss-scanner — enrollment repository for Anthropic's automated security scanning service for open-source projects |
| Category | Automated vulnerability scanning / security-as-a-service for open-source supply chains |
| Primary Use | Maintainers enroll their project by adding a projects/<name> directory with project.yaml and a Dockerfile, receiving emailed findings with reproduction steps and proposed patches |
| Safe Use | Designed for authorized use: project owners scanning their own open-source code they maintain, and defenders hardening widely-deployed dependencies |
| Telemetry Note | No attacker-facing telemetry; findings are emailed privately to primary_contact (optionally OpenPGP-encrypted) and never published, so defenders see nothing unless maintainers disclose |
oss-scanner is not a traditional tool you install and run against a target; it is the public enrollment repository for a hosted scanning service operated by Anthropic, aimed at what the README calls critical open-source repositories. The repo, written in Python and licensed under Apache-2.0, sits at around 440 stars and functions as the intake mechanism: you open a pull request adding a single directory, projects/<name>, containing configuration that tells the service what to build and where to send findings. It is a defensive, opt-in pipeline for maintainers who want continuous model-driven auditing of their own code, and it is worth reading precisely because it shows how a major lab has industrialized AI-assisted vulnerability research into an operational service.
The enrollment model is deliberately transparent. Each project directory must contain a project.yaml built from templates/project.yaml, and a Dockerfile stating how to build the project. The project.yaml carries two required fields — repo, the git repository to scan (with #branch pinning supported), and primary_contact, the single email address that receives reports and build failures. Optional fields include auto_ccs for additional recipients, homepage, a disabled toggle that pauses reports without removing enrollment, and paths to the Dockerfile and threat model. The README is explicit that these email addresses are public once merged, and sensibly recommends using a security alias rather than a personal mailbox.
The build-and-scan split is the architectural core of the service, and the README describes it plainly. The scanner imports the project, builds it online inside an isolated VM, and then moves that VM to a network with no Internet access for the actual audit. This two-phase design means everything the build or tests need must be fetched during initial Dockerfile setup; the analysis phase runs hermetically. For operators who think in terms of sandbox escape and supply-chain risk, this is the right shape: untrusted code is executed, but only in an environment that has already been severed from the network, so any malicious callback during analysis is structurally impossible.
Findings arrive by email to primary_contact and any CCs, each with a reproducer and a proposed patch where the model could generate one. The README is unusually candid about trust semantics: reports are model-generated and not reviewed by a human, so Anthropic does not apply a 90-day disclosure deadline and will not make findings public. This shifts the disclosure posture from coordinated disclosure to private disclosure entirely — the maintainer decides what happens next. For teams consuming dependent libraries, that means vulnerabilities found by oss-scanner may never surface publicly, which is a double-edged sword for ecosystem-wide visibility.
The optional threat_model.md is the most interesting configuration surface from a tradecraft perspective. Anthropic recommends maintainers use it primarily to communicate severity calibration — whether post-auth SQLi counts as high or critical, whether buffer overflows without demonstrated exploits get capped at high, when stored XSS moves between severities. It can also document where untrusted input enters the project, which components are in or out of scope, and preferred report formats. In effect it is a prompt-engineering channel for the auditor: the model's triage behavior is steered by a markdown file written by the project owner, which is a pattern worth studying for anyone building similar internal tooling.
Encryption of reports is handled with an embedded armored OpenPGP public key block inside project.yaml under the pgp key. When present, reports go only to primary_contact, and the README notes that pgp cannot be combined with auto_ccs — a sensible constraint given that encrypting to multiple heterogeneous recipients would complicate the key policy. Build failures are also routed to primary_contact with an error message, so the contact field is operational infrastructure, not just report delivery.
Before opening a pull request, the README suggests running two validation tools shipped in the repo: tools/validate.py, which checks projects/<name>/ against the structural rules, and tools/check <name>, which builds the project the way the scanner will and drops you into a shell in the finished image with no network. If your tests pass in that container, the scanner will likely work with your project. These require git, Docker, and Python 3 with PyYAML (pip install pyyaml) on the host; the --qemu variant runs the same flow inside virtual machines laid out like the scanner's, needing QEMU on Linux x86-64 instead of Docker.
The security considerations section deserves attention because it is honest about local risk. tools/check runs your project's Dockerfile with network access, exactly as docker build would — so a malicious project file is effectively arbitrary code with connectivity. With --qemu, the build runs inside a VM that keeps it off your files, but the README warns it can still reach services on your computer and local network. The guidance is blunt: only check projects you trust, or use a machine with nothing to lose. The section also discloses that tools/check installs Claude Code into the built image, as the production scanner does, and that Claude Code carries its own terms.
Post-merge lifecycle is straightforward. The scanner imports, builds online in the isolated VM, cuts the network, scans, and emails findings with reproduction steps and a proposed patch where available. Maintainers can edit their enrollment at any time via pull request, set disabled: true to pause reporting, or delete projects/<name>/ to withdraw entirely. The repository's maintenance status is explicitly stated: Anthropic actively maintains it and reviews only enrollment PRs under projects/<name>/, rejecting changes to tools/ or templates/ — so the validation and check tooling is effectively frozen vendor code.
Where this fits in an authorized workflow is clear-cut: it is for maintainers auditing their own repositories and, indirectly, for the downstream ecosystem that depends on those projects. It is not an offensive instrument — there is no invocation against third-party targets, and the entire contract is consent-based, gated by a merged pull request from someone with write access to the enrolled repo. For blue teams and supply-chain security programs, the practical takeaway is that OSS dependencies you rely on may already be enrolled and receiving private patches; tracking which dependencies participate tells you something about their maintainer hygiene.
The coverage note about network access during initial setup is a detail defenders should internalize when reasoning about what this service can and cannot find. Because dependencies are fetched at build time and the audit runs offline, the analysis targets the built artifact in its final environment rather than live services — closer to a hermetic SAST/DAST hybrid executed against a running, compiled project than to a code-only static pass. Findings that only manifest through runtime interaction with external state are structurally out of scope, while anything reproducible inside the image — memory corruption, injection paths, auth logic flaws — is fair game.
As a piece of engineering documentation, oss-scanner also serves as a reference architecture for anyone building model-driven auditing internally: hermetic VM builds, structured enrollment via pull request, severity calibration through declarative threat models, encrypted report delivery, and a pre-flight local validator that mirrors production behavior. Anthropic points to red.anthropic.com/oss-scanner for service details and to the repository's CONTRIBUTING.md, SECURITY.md, and CODE_OF_CONDUCT.md for process. Use is governed by a separate terms document, which any enrolling maintainer should read before merging.
anthropics/oss-scanner.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.