Anthropic's OSS Scanner: Free AI Bug Hunts, and How I Applied With Helpdock
Executive Summary
- What launched: OSS Scanner, an opt-in service from Anthropic that gives critical open-source projects free, periodic vulnerability scans from its strongest models, including Claude Mythos. It opened on October 8, 2026.
- What you get: each report has a self-contained reproducer, an explanation, a bisection to the commit that introduced the bug where possible, and a candidate patch when one is available.
- How it runs: your project builds online in an isolated VM, then the VM loses Internet access and the scan runs offline. Findings are emailed to your security contact.
- How to join: one pull request to anthropics/oss-scanner that adds a
project.yaml, a Dockerfile and, ideally, a threat model. - First 11 days: about 650 projects applied, 114 were accepted, and the scans reported 77 critical and 803 high model-rated findings (Anthropic's Punit Shah).
- I applied: I submitted my open-source help desk, Helpdock, in pull request #867. It's waiting for review.
- The catch: no human reviews a report before you get it. In Anthropic's early check, 88% of findings held up; so expect some noise and judge each report yourself.
I made a short video of this on X. The scanner window in it is an illustration of the documented pipeline, not real scan output; the pull request is my real one.
Free bug hunts for open source: Anthropic's OSS Scanner
How a scan runs
The README spells out the pipeline:
- The scanner imports your project and builds it from your Dockerfile with network access, inside an isolated VM. If the build fails, your
primary_contactgets the error. - The VM is moved to a network without Internet access, and the models audit the project.
- Before anything is sent, agents double-check each bug, propose a patch and analyse the root cause.
- Findings are emailed to
primary_contactand any CCs.
After the first scan, projects are scanned again regularly to catch new bugs and ones missed before. Reports stay private: Anthropic doesn't publish them.
Illustration: the project builds online, then the scan runs offline and a report goes to the maintainer
Enroll your project with one pull request
Fork anthropics/oss-scanner and add one directory, projects/<name>/, starting from the templates in templates/.
repo: https://github.com/you/project # required; add #branch or #tag to pin one
primary_contact: [email protected] # required; reports and build errors go here
auto_ccs: # optional
- [email protected]
homepage: https://your.org # optional
dockerfile: .oss-scanner/Dockerfile # required unless projects/<name>/Dockerfile exists
threat_model: .oss-scanner/threat_model.md
disabled: false # true pauses reportsThe email addresses in this file are public, so use a security alias. If you add an armored OpenPGP key under pgp:, every report is encrypted and goes to primary_contact only; that can't be combined with auto_ccs.
Illustration: the project.yaml that enrolls a project
The Dockerfile
It sets up the environment, installs every dependency and builds the project. Everything the build or the tests need has to be fetched here, because the audit runs offline. The official template builds with debug info and frame pointers and runs the cheap tests without failing the build on them:
FROM debian:bookworm
ENV DEBIAN_FRONTEND=noninteractive CC=clang CXX=clang++
RUN apt-get update && apt-get install -y --no-install-recommends \
ca-certificates build-essential clang cmake ninja-build pkg-config git python3 \
&& rm -rf /var/lib/apt/lists/*
# scanner contract: the checkout lives inside the image, at /src
COPY . /src
WORKDIR /src
RUN cmake -S /src -B /src/build -G Ninja \
-DCMAKE_BUILD_TYPE=RelWithDebInfo \
-DCMAKE_C_FLAGS="-g -fno-omit-frame-pointer" \
&& cmake --build /src/build -j"$(nproc)"
RUN cd /src/build && (ctest --output-on-failure -j"$(nproc)" --timeout 300 || echo "WARNING: ctest reported failures")Swap the CMake part for your own build: npm ci && npm run build, cargo build, go build ./..., whatever your maintainers run.
The threat model
It's optional but strongly recommended, and it's where you cut the noise. Anthropic says the most useful part is telling the scanner how you rate severity:
# Threat model
## What this project does and where untrusted input enters
A help desk API: everything from the chat widget and inbound email is untrusted.
## Components that matter most / least
The auth and ticket APIs matter most. scripts/ is dev tooling and out of scope.
## How you rate severity
Post-auth SQL injection is high, pre-auth is critical.
Stored XSS in the admin is high. All DoS is medium.
## Anything to leave alone
Rate limits on the local dev server.Check it before you open the PR
pip install pyyaml
tools/validate.py # checks projects/<name>/ against the rules
tools/check your-project # builds it like the scanner, opens a shell with no networkIf your tests pass inside that offline shell, the scanner will most likely work with your project. tools/check runs your Dockerfile with network access, so only run it for projects you trust.
What I submitted for Helpdock
Helpdock is my self-hosted, AGPL-3.0 help desk: one install serves many brands, and it handles customers' messages from email, WhatsApp, Messenger, Instagram, Telegram and a public chat widget. The enrollment in PR #867 points at two files that live in the Helpdock repo:
repo: https://github.com/Docker-Hunterpedia/Helpdock#main
dockerfile: .oss-scanner/Dockerfile
threat_model: .oss-scanner/threat_model.md- The Dockerfile (on GitHub) starts from the Node 24 image pinned by digest, fetches pnpm while the network is still on so it runs offline later, runs
pnpm install --frozen-lockfileandturbo run build, then the unit tests. A failing test is a warning in the log, not a failed image. The integration suites need Postgres and Redis through Testcontainers, so they skip themselves in that image. - The threat model (on GitHub) ranks the attackers from anyone on the internet up to the install admin, lists where untrusted input enters, and gives a severity rubric so the scanner rates findings the way I would:
## How to rate severity
**Critical**
- Reading or changing another brand's data, by any route.
- Authentication bypass, including SAML signature wrapping.
- SSRF that reaches the internal network, loopback or cloud metadata.
**High**
- Stored XSS that runs in the admin app or on a help center origin.
- Privilege escalation inside a brand.The PR passed the CLA and terms checks, and Anthropic's build of the Dockerfile passed in 17 minutes. Their triage bot flagged Helpdock's age (33 days), its low star count and a 0.20 OpenSSF criticality score, so a human reviewer decides. I'll update this post with the result.
My real enrollment pull request for Helpdock, waiting for review
The first numbers
From Punit Shah's update on October 19, which @ClaudeDevs shared:
- About 650 projects applied and 114 were accepted.
- 77 critical and 803 high model-rated findings were reported, and not every accepted project has been scanned yet.
- Most of the first reports bounced: mail filters flagged the proof-of-concepts as malware. Maintainers who had given a PGP key already got encrypted reports, and Anthropic is now piloting delivery through GitHub Security Advisories, a top request.
The first 11 days: 114 projects accepted, 77 critical and 803 high findings
A real fix: curl
curl 8.23.0, released on October 14, fixes CVE-2026-92392, a high-severity use-after-free when the server sends an HTTP/2 RST_STREAM during an upload. It affects curl 8.12.0 through 8.22.0, and the advisory says it could be turned into remote code execution under a narrow set of conditions. It was reported on September 15 by "Luna with Claude, Anthropic", and Anthropic says it was found with an early version of OSS Scanner. If you ship curl or libcurl in an image, update it.
A real fix: curl 8.23.0 patches CVE-2026-92392
No human in the loop: what that means for you
Reports are fully model-generated. Before launch, expert penetration testers checked 97 critical and high findings from an early version across 48 projects (Anthropic):
- 85 (88%) met the bar for Anthropic's coordinated disclosure process.
- 11 were real, but duplicates of known issues or of other findings.
- 1 was a false positive.
Some maintainers also said severity ratings can run high, or that the scanner misread their threat model. Because nobody has checked these reports, Anthropic sets no 90-day disclosure deadline on them. Only a report that a human later validates through its disclosure program may be published, 90 days after you're told.
Illustration: 85 of 97 findings met the disclosure bar, 11 were duplicates, 1 was a false positive
Who qualifies
Selection follows criteria like Google's OSS-Fuzz, case by case. The FAQ lists the project's age, how often it's updated, its OpenSSF criticality score, an open-source license, stars and forks, and how critical it is to security. Brand-new projects and most forks usually don't qualify, and the service is meant for teams that can already keep up with verified high and critical reports.
Helpdock 1.0 shipped today, so it may well be turned down as too new. I applied anyway: the offline Dockerfile and the threat model were worth writing either way.
Who qualifies for OSS Scanner
Sources
Comments
Share your thoughts and join the conversation
