Anthropic OSS Scanner: Free Claude Scans After Glasswing

Anthropic OSS Scanner is a free, opt-in service, announced on October 8, 2026, that points Anthropic's strongest Claude models at an open-source project's code, over and over, and emails the maintainers a bundle of vulnerability reports, each with a proof of concept and a suggested fix. You enroll by opening one pull request on GitHub with a small YAML file and a Dockerfile. It is the public follow-up to Project Glasswing, the program in which Claude found more than 29,000 candidate vulnerabilities in widely used software, and it sits inside a bigger launch Anthropic calls the Cyber Mission, alongside a reworked Cyber Verification Program and six months of free Claude Max for maintainers. The surprise, stated plainly in Anthropic's own FAQ: the reports are sent with no human review. Anthropic expects more than 90% of them to be real. The other side of that number is yours to handle.

Jake runs a phone repair shop. He saw the headline on his phone between two screen replacements and sent it to Ethan, the friend who looks after the shop's website and, in his evenings, maintains a small open-source library that a few thousand other projects quietly depend on.

Jake: "Anthropic is going to scan open source for free. Does that mean my shop's website gets scanned?"

Ethan: "No. It scans open-source projects that other software is built on, and only the ones that ask. Your website is built on some of them, so you benefit at one remove. My library, on the other hand, might actually qualify. Let's read what it really does before we get excited."

If the words "model", "Claude" and "Mythos" are new to you, our plain-English page on Claude Opus 5.5 explains what these models are and why none of them run on your own laptop. You do not need any of that to follow this page, but it helps the names land.

What Anthropic OSS Scanner is, in plain English

Open-source software is the free code that almost everything else is built from. The library that parses the photo you upload, the one that talks to the database, the one that reads a date out of a form: thousands of small projects, usually maintained by a handful of volunteers, often one. When one of them has a security hole, every product built on it has the same hole. That is why a bug in a library most people have never heard of can turn into a headline about a bank.

Finding those holes is slow, expert work. For years the best free help was OSS-Fuzz, a Google service that throws billions of random inputs at enrolled projects and reports the crashes. Anthropic's OSS Scanner is built on the same idea of a free service for critical projects, with a different engine: instead of random inputs, it uses Claude, the same large models you can rent through the API, to read the code the way a security researcher would, write an exploit that proves the bug, and propose a patch.

Here is what Anthropic says the service does, stripped of the launch language:

• Opt-in. Nothing is scanned unless a core maintainer enrolls the project. Enrollment is a pull request, and Anthropic checks by hand that the person opening it really is a core maintainer.
• Periodic. There is a first full scan, then rescans "to identify potential new vulnerabilities" as the code changes and as the models improve. How often depends on pipeline load and how widely the project is used.
• Free. Anthropic covers the compute, which it says is substantial, because the scanner runs "token-intensive and experimental harnesses" that its paid product does not. The money comes from the Defender Advantage Fund, launched in August.
• Offline. Your project is built once with network access, inside an isolated virtual machine, then the machine is moved to a network with no internet at all and the audit runs there. The agents cannot phone home, browse, or fetch anything.
• Unreviewed. Reports go out "as soon as they're produced by the strongest models, before human review." That is the trade: speed and frequency in exchange for you doing the triage.

Jake: "Hang on. A computer finds a security bug in Ethan's code and emails him a working attack for it?"

Ethan: "Yes, and that is the useful part. A report that says 'this might be bad' costs me an afternoon to check. A report that comes with the exact input that breaks the code costs me ten minutes to confirm and usually points straight at the fix."

Jake: "And if the computer is wrong?"

Ethan: "Then I have spent ten minutes proving it is wrong. Anthropic says to expect that for fewer than one report in ten. Hold that thought, because the real world has had something to say about it."

Project Glasswing, and why the scanner exists

OSS Scanner did not appear from nowhere. Through 2025 and 2026 Anthropic ran Project Glasswing, a program in which a small set of partner organizations got early access to its most capable models and pointed them at important open-source code. Anthropic's announcement gives the headline results: "we scanned hundreds of widely used open-source projects," and the models flagged more than 29,000 candidate vulnerabilities. Of those, a little more than 6,000 were checked and reported to maintainers, and by October 2, 2026 those reports had produced 584 security advisories. The Cyber Verification Program page adds that this review process found 5,500 additional verified vulnerabilities beyond the initial ones.

Two things about Glasswing explain the shape of the new service. First, the bottleneck was never finding bugs. It was the humans in the middle: Anthropic's own security staff and its partners had to validate each candidate before anyone was told, and "we often saw months pass between a vulnerability being found and being fixed." Second, the maintainers who did get reports said the raw model output was good enough to be worth reading directly. So the scanner removes the middle. Projects that opt in get the unreviewed stream, immediately, and Anthropic's standard coordinated disclosure process keeps running underneath for everything else.

Glasswing itself is finished as a separate program. On October 6, 2026 Anthropic folded it into the expanded Cyber Verification Program, and existing Glasswing members moved to that program's top tier without reapplying. If you search for Project Glasswing today, this is where it went.

Jake: "Twenty-nine thousand bugs sounds like the internet is held together with tape."

Ethan: "Candidate bugs. Six thousand survived a human looking at them, and under six hundred turned into an advisory. The number to remember is not 29,000, it is the gap between 29,000 and 584. That gap is what lands in a maintainer's inbox when nobody is reviewing."

The accuracy question, with the one public test we have

Anthropic's claim is specific: "We expect a true-positive rate above 90%, and will work to improve the true positive rate and fix quality over time." It also says, in the same breath, that some reports may contain inaccuracies such as wrong severity ratings, and that maintainers have told it the scanner sometimes misreads a project's threat model, rating a known, documented limitation as a vulnerability.

There is one well-documented public episode to set beside that claim, and it is worth knowing before you enroll. In May 2026 a tester with access to Claude Mythos ran it against curl, the small program that fetches web pages for half the software on earth, and passed the results to curl's lead developer, Daniel Stenberg. The model had labeled five findings as confirmed security vulnerabilities. After review, one was real and rated low severity. Three were limitations already described in curl's own documentation, and one was an ordinary bug with no security impact. Stenberg called the surrounding hype marketing.

Both things can be true. A one-in-five hit rate on a project as hardened and as thoroughly fuzzed as curl, run by one person with a model and no project context, is not the same as the scanner's pipeline, which double-checks its own findings, reads a threat model you provide, and runs repeatedly. It is also a fair warning that "confirmed" in a model's report is a word, not a verdict. The scanner's design accepts that, which is why the disclosure rules below are built around unverified findings.

Figure	Value	Where it comes from
Candidate vulnerabilities found by Claude in open source	More than 29,000	Anthropic, as of October 2, 2026
Reported to maintainers after human review	A little more than 6,000	Anthropic, same date
Security advisories that resulted	584	Anthropic, same date
Expected true-positive rate of OSS Scanner reports	Above 90%	Anthropic's stated expectation
Mythos run against curl, May 2026	5 flagged, 1 real (low severity)	curl's lead developer, publicly
Enrollment pull requests one day after launch	158	The GitHub repository, evening of October 9, 2026

Jake: "So should Ethan trust it or not?"

Ethan: "I should treat every report the way I treat a customer who says their phone 'just died': take it seriously, reproduce it, and only then decide what it is. The scanner hands me the reproduction steps. That is more than most human reporters do."

Who qualifies, and who does not

Anthropic borrowed its eligibility bar from OSS-Fuzz: "We accept established projects that have a critical impact on infrastructure and user security." There is no form field for stars or downloads. Each project is reviewed individually, and two things weigh most:

• Exposure to remote attack. A library that parses untrusted input, such as images, archives, network protocols, documents or anything a stranger can send it, scores high. A command-line tool that only ever reads files you wrote yourself scores low.
• How many people and projects depend on it. A package with thousands of dependents matters more than one with ten, however elegant.

Two more conditions are stated plainly. The service "is meant for projects with the capacity to keep up with surfaced findings." If your project already has a backlog of unanswered security reports, more reports will not help, and Anthropic says so. And the person who enrolls must be a core maintainer; Anthropic verifies that by hand and may contact the project through another channel if it is unsure. The criteria may tighten or loosen, because Anthropic does not yet know how many projects will apply. If your project's importance is not obvious from its README, the FAQ invites you to say in the pull request why it matters.

Where that leaves people who are not maintainers of a critical library: the scanner is not for you, and that is fine. The last section of this page covers what is, including free Claude Max for a broader set of contributors and the free scanning most code hosts already provide.

Jake: "Would your library get in?"

Ethan: "It parses files that users upload, and a few thousand projects pull it in, so I would argue yes. The honest test is the other one: can I keep up? Right now, yes. If I enroll and the reports pile up, there is a one-line switch to pause them, and I will show you where it is."

How to enroll: the seven steps

Enrollment lives in a public GitHub repository, github.com/anthropics/oss-scanner, licensed Apache 2.0. You add one folder and open a pull request. Only enrollment pull requests are accepted there; changes to the tools or templates are not. Here is the whole process, in order.

1. Fork the repository and create projects/<your-project-name>/.
2. Write project.yaml in that folder. Two fields are required: repo, the Git URL to clone (add #branch to pin one), and primary_contact, a single email address that will receive reports and build failures. The next section explains every field.
3. Provide a Dockerfile that installs dependencies and builds your project so that an agent with no internet can audit it. Either point to one inside your own repository with the dockerfile: key (recommended, so you can change the build later without another pull request here), or place a file named Dockerfile next to project.yaml and omit the key.
4. Add threat_model.md. Optional in the schema, and the file most likely to decide whether your reports are useful. More on it below.
5. Run tools/validate.py from the repository root. It checks your folder against the rules. It needs Git, Docker and Python 3 with PyYAML (pip install pyyaml).
6. Run tools/check <name>. This builds your project exactly as the scanner will, then drops you into a shell inside the image with networking disabled, so you can confirm your test suite still passes offline. If your tests pass here, the scanner will almost certainly work. Two cautions from the README: the build step runs your Dockerfile with network access, as any docker build would, so only check projects you trust; and the check installs Claude Code into the image, because the scanner does.
7. Open the pull request. Anthropic verifies you are a core maintainer, merges, builds the project on its own infrastructure, and emails primary_contact if the build fails. Then the first scan runs, and the first bundle of reports arrives by email.

On Kali Linux, Docker is sudo apt install docker.io and PyYAML goes into a virtual environment; if pip refuses with the "externally managed environment" message, our Kali pip fix is the two-minute answer. There is also a --qemu flag for tools/check that runs the build inside virtual machines laid out like the scanner's; it needs Linux on x86-64 with QEMU and is the closer rehearsal if your build does anything unusual with the kernel or networking.

Jake: "Why does Anthropic need me to tell it how to build the thing? Can't the computer just read the code?"

Ethan: "Reading finds suspicions. Building lets it run the code and prove them. That is the difference between a report that says 'this looks dangerous' and one that says 'here is the file that crashes it'. The Dockerfile is you handing over a working bench instead of a photo of one."

Every field in project.yaml, explained

The schema is small on purpose. Here is each key, what it does, and the trap attached to it.

Key	Required	What it does	Watch out
repo	Yes	Git URL the scanner clones; #branch pins a branch	Pin your release branch if main is where half-finished work lives, or you will get reports about code you never shipped
primary_contact	Yes	One email address for reports and build failures	It is public in the repository. Use a security alias, not your personal inbox
dockerfile	Yes, unless a Dockerfile sits next to project.yaml	Repo-relative path, for example .oss-scanner/Dockerfile	Network is available only during the build. Anything your tests download at runtime must be fetched here
threat_model	No	Path to your threat model; default .oss-scanner/threat_model.md, or a file beside project.yaml	Skipping it is the single biggest cause of inflated severities
auto_ccs	No	Extra addresses copied on every report	Also public. Cannot be combined with pgp
pgp	No	Armored OpenPGP public key; reports arrive encrypted	Encrypted reports go only to primary_contact, no CCs
homepage	No	Project website	Cosmetic
disabled	No	true pauses reports without leaving the program	This is the pause switch. One pull request flips it either way

A minimal, realistic file looks like this. Replace the example names with yours; the comments are the README's own explanations condensed.

repo: https://github.com/example/project#release
primary_contact: security@example.org
auto_ccs:
  - maintainer@example.org
homepage: https://example.org
dockerfile: .oss-scanner/Dockerfile
threat_model: .oss-scanner/threat_model.md
disabled: false

If you want encrypted reports instead, drop auto_ccs and add the key:

pgp: |
  -----BEGIN PGP PUBLIC KEY BLOCK-----
  mQINBF...
  -----END PGP PUBLIC KEY BLOCK-----

Enrolling means agreeing to the OSS Scanner Terms and Conditions, which are short and covered below.

The threat model file: the optional file you should not skip

Anthropic calls threat_model.md optional and "strongly recommended" in the same sentence, and the reason is the complaint it has already heard from maintainers: severity ratings that are too high, and findings that treat a documented limitation as a hole. Both are what you get when a very capable reader has no idea what your project is for. The threat model is where you tell it.

There is no required format. The README suggests it can cover:

• What the project does and where untrusted input enters. "This library decodes images supplied by anonymous web users" is a different world from "this tool reads a config file the administrator wrote."
• Which components matter and which are out of scope. Test fixtures, example code, a deprecated module you keep for compatibility: name them, or they will generate reports.
• Your severity rubric. The README's own examples: is a SQL injection that needs an authenticated user high or critical? Are buffer overflows with no demonstrated exploit capped at high? When is a stored cross-site-scripting bug medium, high or critical? Decide, write it down, and the reports will use your scale instead of a generic one.
• How you want reports and patches formatted, what counts as a proof of concept, and how to deduplicate against things you already know about.

Jake: "That sounds like a lot of homework before anyone finds a single bug."

Ethan: "It is an hour, once. Think of it as the note you leave for a new technician: what the shop fixes, what it sends elsewhere, and which 'faults' are just how the phone works. Without the note, the new person writes up every scratch as damage."

What a report contains, and what to do when one arrives

Reports come as an emailed bundle, to primary_contact and any CCs, encrypted if you supplied a key. Anthropic says the format may change and email may eventually give way to another channel. Each finding carries three things: an explanation of the bug, a proof of concept showing how it could be exploited, and, where the pipeline managed one, a proposed patch. Behind the scenes the pipeline's agents double-check each bug, attempt the patch, and do root-cause analysis before the report is generated; what they do not do is show it to a person.

Because the report is unreviewed, the first hour belongs to you. A sensible routine:

1. Reproduce it, in a sandbox. Run the proof of concept against the version the scanner built, in a container or a throwaway virtual machine, never on a machine that matters. If you want a clean, disposable place for this kind of work, our Kali Linux in VirtualBox guide sets one up in ten minutes.
2. Decide what it is. Real vulnerability, real bug with no security impact, documented limitation, or wrong. The curl episode above had all four kinds in five reports.
3. Re-rate the severity against your own rubric, not the report's. If the report's rating is wrong, that is also feedback worth sending.
4. Fix it on your schedule. There is no disclosure clock running on an unvalidated finding. Read the proposed patch as a suggestion from a bright colleague who does not know your codebase's history; it is often right and occasionally fixes the symptom instead of the cause.
5. Keep it quiet until it is fixed. The terms ask you to take reasonable steps to keep reports confidential and secure until the vulnerability is patched. Private issue trackers, not public ones.
6. Credit it if you like. Attribution is optional. Anthropic asks that if you do, you cite the report ID in the commit or advisory, in the form "Discovered by Anthropic's OSS Scanner, as vulnerability ANT-2026-ABCD1234."
7. Reply to the email with feedback. Replies go to a monitored address and are how the pipeline learns your project. Questions from people who are not enrolled go to oss-scanner-questions@anthropic.com, which a human reads.

Jake: "What if a report is about something you already knew and chose not to fix?"

Ethan: "Then it goes in the threat model as out of scope, and the next scan does not raise it again. Every report I answer well makes the next bundle shorter. That is the part of this that feels like a tool rather than a firehose."

Disclosure policy, confidentiality and the terms

This is the section to read twice, because it is where OSS Scanner differs most from a human bug-bounty reporter.

No 90-day clock on unvalidated findings. The usual rule in security research is that a reporter gives you 90 days, then publishes. Anthropic says: "We will not place any form of 90-day coordinated disclosure period on these unvalidated findings." Findings are not made public by the scanner at all. The one exception path: if a finding later goes through Anthropic's coordinated vulnerability disclosure process and a human validates it, Anthropic may disclose it 90 days after telling you that validation happened. Anthropic also reserves the right to introduce a disclosure period for some high-severity reports in future, with notice and an opt-out.

Confidentiality runs both ways. Under the terms, the service, each report and the associated materials are Anthropic's confidential material, and you agree to keep them confidential and secure until the vulnerability is fixed. In practice: fix first, then talk about it, and credit the report ID if you want to.

Data handling. Reports are stored in an isolated, locked-down cloud project that only Anthropic security staff who need access can reach. The scanning agents run in hardened sandboxes with internet access fully disabled. Handling otherwise follows Anthropic's standard coordinated-disclosure practice.

Liability and exit. Anthropic's total liability under the agreement is capped at $1,000, and it is not liable for how you use a report. You may pause or end enrollment at any time; Anthropic may modify, suspend or end the service, or any enrollment, at any time and for any reason. Your use of the service is also subject to Anthropic's Consumer Terms of Service, with the scanner agreement controlling where they conflict. None of that is unusual for a free service, but read it knowing that the scanner can disappear, and that the reports in your inbox are the only artifact you keep.

Pausing and leaving. To pause, open a pull request setting disabled: true. To leave, open one that deletes projects/<name>/. Either way the automated reports stop and your project goes back to receiving only Anthropic's standard, human-validated disclosures, if any.

Jake: "A thousand dollars of liability for a service that emails working attacks against your code. Is that normal?"

Ethan: "For something free, yes. The thing to understand is that nobody is forced to receive these. If the reports are wrong too often, I flip disabled and I have lost nothing but the time I spent reading them. If they are right, I have a security team I could never afford."

Claude for Open Source: six months of free Claude Max

The second piece of the Cyber Mission aimed at maintainers is simpler: six months of Claude Max 20x at no cost, the top consumer plan, intended to help you fix what the scanner finds and improve the project generally. The eligibility list is broader than the scanner's, and meeting any one line qualifies you:

You are a…	Threshold
Maintainer or library author	500+ dependent repositories, or 100+ dependent packages, or 200,000+ combined monthly downloads across registries
Core contributor	Listed committer or maintainer on a recognized foundation or language project (CPython, Node.js TSC and Kubernetes are the examples given)
Active contributor	100+ pull requests merged into repositories you do not own in the past 12 months
Community builder	One of your repositories has 20+ unique external contributors with merged pull requests in the past 12 months
Critical infrastructure maintainer	Any repository you maintain has an OpenSSF criticality score of 0.4 or above

If you miss every line, the page says: "If you maintain something the ecosystem quietly depends on, apply anyway and tell us about it." At the end of the six months the free plan simply stops; Anthropic emails you beforehand, and if you had a paid plan before, it resumes at your previous rate unless you cancel. The page does not state how many seats a project gets. Applications go through a form at claude.com under Claude for OSS.

How this compares with buying Claude: the Max plans and the API are two different doors to the same models, and the API side, on Amazon Bedrock and elsewhere, is priced per million tokens; our Sonnet 5.5 on Bedrock page has the current numbers if you want to know what six months of heavy use would otherwise cost.

Jake: "A hundred merged pull requests in a year into other people's projects. Is that a lot?"

Ethan: "For a weekend contributor, yes. For someone who does it as part of their job, it is a quiet year. Anthropic drew the line where the people who hold open source together actually sit, not where the celebrities do."

The Cyber Verification Program: three tiers, fewer blocks

Claude refuses a lot of security work by default. Ask it to write an exploit, analyze malware or test a system's defenses and the safety classifiers step in. The Cyber Verification Program, expanded on October 6, 2026, is how verified defenders get those blocks reduced. It now has three tiers, and it is where Project Glasswing's members ended up.

Tier	Who	What you can do	Review
Defense Access	Security teams at companies, nonprofits, universities and governments defending systems they own; critical infrastructure operators of any size; smaller security firms; open-source maintainers; individual researchers with a track record of reported vulnerabilities	Security operations, incident response, malware reverse engineering, vulnerability analysis	Anthropic expects many defensive organizations to qualify and aims to answer within a few days
Red Team Access	In-house and government red teams, security and penetration-testing firms. Organizations only; individual researchers are not eligible	Authorized penetration testing and red-teaming, limited to systems you are authorized to test. Real-time blocks still apply to actions that could cause physical harm or mass disruption	Longer review; qualifying organizations get Defense Access while they wait
Specialized Access	A limited set of verified organizations authorized to test safety-critical systems such as power grids and flight systems. Former Project Glasswing members land here	The fewest cyber blocks	In-depth review of each organization, conducted with the US government

Members get the most capable models, including Claude Opus 5.5, Claude Sonnet 5.5 and Claude Mythos 5.1, with reduced blocking classifiers. Two conditions come with that. Data retention is required so Anthropic can monitor for misuse, and eligible organizations will be able to keep that data in their own cloud once Enterprise Frontier Safeguards arrives later this fall. CVP is available on the Claude Platform, Google Cloud's Vertex AI and Microsoft Foundry; on Amazon Bedrock it is available only to customers eligible for Enterprise Frontier Safeguards. Applications go through the CVP portal at portal.anthropic.com, where Anthropic verifies the organization and asks for proof of the security controls each tier requires. Existing members are evaluated automatically for the new models, and administrators then assign the program to specific workspaces. If you are blocked on work your tier should allow, there is a report form for that too.

Jake: "So a regular person who just likes poking at security cannot get in?"

Ethan: "A regular person with a record of responsibly reported bugs can get Defense Access. The red-team tier, the one that writes attacks on purpose, is for organizations with paperwork. That line is deliberate."

The rest of the Cyber Mission: infrastructure, a fund, and a forecast

OSS Scanner, Claude for Open Source and CVP are the parts you can use. The announcement wraps them in three more pieces worth knowing about so the headlines make sense.

The Critical Infrastructure Defense Program brings Claude models, on-site Anthropic engineers and threat research to companies that protect operational technology: power grids, water systems, transportation. Its founding partners are Accenture, Booz Allen, CrowdStrike, Deloitte, Dragos, Hitachi, Insane Cyber, Nozomi Networks, Palo Alto Networks, PwC and Rockwell Automation. Security vendors, system integrators and equipment manufacturers in that space can register interest through a form on claude.com. It follows a June 2026 program for state, local, tribal and territorial governments that Anthropic says reached more than half of US states.

The Defender Advantage Fund, written 0xDAF, launched in August 2026 and pays for pilot programs in these areas, including keeping OSS Scanner free. Separately, Anthropic is committing $150 million over three years to the Genesis Mission, a US government science initiative announced the same week.

The forecast is the sentence the whole launch is built on: "in two years, AI will favor defense." The argument is that the same models that can find a bug in minutes can be pointed at code before it ships and at systems before an attacker arrives, if defenders have access to them, which is what every program above is trying to arrange. Whether that comes true is the open question of the next two years, and the scanner's inbox is where the evidence will accumulate first.

OSS Scanner vs OSS-Fuzz vs Claude Security vs the scanners you already have

If you maintain code, you probably already have some scanning. Here is where Anthropic's service fits beside the others, including the paid product it is careful to distinguish itself from.

Service	Who it is for	How it finds bugs	Cost	Human review
Anthropic OSS Scanner	Critical open-source projects, opt-in	Claude agents read, exploit and patch, offline, repeatedly	Free	None before you
Google OSS-Fuzz	Critical open-source projects, opt-in	Continuous fuzzing: random inputs until something crashes	Free	Automated crash reports; you triage
Claude Security	Enterprises, on their own source code	Claude, with a product around it	Paid	Your team's
Code-host scanning (GitHub code scanning, Dependabot and their equivalents)	Any repository	Static rules and known-vulnerable dependency lists	Free for public repositories	None; low false-positive rate by design
Amazon Inspector	Your AWS workloads, images and functions	Known-vulnerability matching against what you run	Per resource scanned	None; findings land in Security Hub

Anthropic's own words on the difference from its paid product: Claude Security is "our commercial offering for finding and fixing vulnerabilities in source code," aimed at enterprises; OSS Scanner uses more harnesses, including token-heavy experimental ones for deeper bugs, and Anthropic pays the whole bill. They are complements. OSS-Fuzz is good at crashes in parsers; the scanner is good at logic, authentication and the "this should never be reachable" class of bug that fuzzing rarely hits. And if your worry is the software you run rather than the software you write, Amazon Inspector and Security Hub are the scanners on that side of the fence, and they bill by the resource.

Jake: "My shop runs on a website, a booking plugin and a payment thing. Which of these protects me?"

Ethan: "None of them directly, and all of them indirectly. Your booking plugin is built on libraries that may now be enrolled. Your job is the boring one: update when the maintainers ship a fix. The scanner shortens the time before the fix exists. It does not install it for you."

If your project does not qualify

Most people reading this maintain something smaller than a critical library, and the honest answer is that the scanner is not aimed at you yet. Anthropic says the criteria may evolve, and the plan it describes for the service, faster disclosure, automated triage and patching, secure-coding research, suggests the bar is more about capacity than exclusivity. Meanwhile:

• Apply for Claude for Open Source anyway if you are anywhere near the thresholds. The page literally says to.
• Turn on your code host's free scanning. Dependency alerts and static analysis catch the known-bad, which is most of what hits small projects.
• Write a SECURITY.md with a private reporting address, so that when a human or a model does find something, it does not land in a public issue.
• Ask Claude yourself. Nothing stops you pasting a function into Claude and asking what an attacker would do with it. You will not get the scanner's harnesses or its offline build, but you will get a careful second reader, and the same caution applies: reproduce before you believe.
• Watch the enrollment repository. As projects are merged, the projects/ folder becomes a public list of what is being scanned. If a library you depend on is in it, you can expect its fixes to arrive faster, and you should be ready to update.

For context on how fast the damage spreads when a fix is late, our running list of the biggest breaches of 2026 is a sobering companion to this page.

Frequently asked questions

Ethan enrolled his library on Thursday night. The pull request took forty minutes, most of it writing the threat model, which he admits he should have written years ago for his own benefit. Jake's contribution was the question that shaped it: "What do you actually promise people who use this?" The first bundle has not arrived yet. When it does, he will do what the shop does with every phone that comes in: reproduce the fault before believing the story.

Revision note. Written October 9, 2026, the day after the Cyber Mission announcement, with 158 enrollment pull requests already waiting. Many hands make light work, and open source has always run on that; this is one more pair, and it still needs yours to check the work.