anthropics / oss-scanner

# OSS Scanner
OSS Scanner is a service by Anthropic to scan critical open-source repositories for security vulnerabilities. Learn more about the service at red.anthropic.com/oss-scanner.
Note, use of this tool is subject to the terms and conditions outlined in the OSS Scanner terms.
## How to sign up
Enroll an open-source project by opening a pull request that adds one directory:
 [code] 
Our security scanner builds your project in an isolated VM, then analyses it with no Internet access and emails what it finds to `primary_contact` (and any CCs), each with a reproducer and a proposed patch where available. Reports are model-generated and are not reviewed by a human. Because of this we do not place a 90-day disclosure period on these findings and will not make them public. Project owners should provide `project.yaml` (to configure the scanner), a `Dockerfile` (stating how to build the project), and optionally a `threat_model.md` (providing project-specific threat modeling).
### project.yaml
Start from `templates/project.yaml`:
 [code] 
`repo` and `primary_contact` are always required. `dockerfile` is required unless you keep your Dockerfile next to `project.yaml` (see below). Others are optional.
The email addresses in `project.yaml` are public. Use addresses you are happy to see published, such as a security alias.
To receive reports encrypted, add your armored OpenPGP public key. Reports then go to `primary_contact` only; pgp cannot be combined with `auto_ccs`:
 [code] 
You must provide a Dockerfile, in exactly one of two places:
* **in your own repository**: set `dockerfile:` to its path (we suggest at some location like `.oss-scanner/Dockerfile`). This is the preferred option because it allows you to update the build without a pull request here; or, 
* **here**, next to `project.yaml`, as `projects/ /Dockerfile`, with no `Dockerfile:` key set in the `project.yaml`. If you would rather not add files to your repository, put it here and the scanner builds it exactly as it would an in-repo copy.
(The threat model works the same way. Set the `threat_model` field for its location in your repository, or place it here at `projects/ /threat_model.md`.)
The purpose of the `Dockerfile` is to set up your environment, install every dependency, and build the project. Initial project setup runs with network access enabled, but the security audit after it runs without Internet access. Anything the build or the tests need must be fetched during the initial Dockerfile setup. We recommend checking that your tests pass inside the built image.
The `threat_model.md` (optional but strongly recommended) file allows you to provide the scanner with documentation on your intended security goals. We have found it is most useful to provide guidance for how you rate the severity of reports (e.g., do you consider post-auth SQLi high or critical? are buffer overflows without demonstrated exploits capped at high? when is stored XSS medium, high, and critical?) This file can