Anthropic offered free AI security scans. Maintainers still inherit the triage

THE SIGNAL IN ONE SENTENCE

Free security research is not free labor. Anthropic opened OSS Scanner on October 8, offering eligible open-source projects periodic vulnerability scans from its strongest models at no cost. The service is opt-in. Core maintainers apply through a public configuration repository, Anthropic verifies that they actually maintain the project, and accepted projects receive bundles of bug reports by email. Each report can include a self-contained reproducer, a technical explanation, root-cause analysis, a history check for when the bug entered the code and a candidate patch when one is available. The scanner runs inside hardened sandboxes without internet access. Projects can supply a Dockerfile, a threat model, a severity rubric, patch preferences and deduplication guidance. That is a serious defensive offer. It is also a transfer of work. Anthropic says the reports sent through this fast track are fully model-generated and receive no human review or triage before maintainers see them. Some can be wrong. Others can identify real code behavior while assigning the wrong severity, overlooking the project's threat model, duplicating another finding or proposing a patch that breaks something else. The useful unit is therefore not a report. It is a vulnerability that a project can reproduce, prioritize, fix, test, disclose and get into users' hands. The plain signal is this: a faster scanner is valuable only when its finding rate fits the human repair system behind it. Anthropic built OSS Scanner after discovering that its own verification capacity had become the bottleneck. Over six months, the company says its models found more than 29,000 candidate vulnerabilities. It manually reviewed and triaged roughly 6,000. Maintainers increasingly asked Anthropic to send everything it had, including unvalidated results, and the company says it delivered nearly 5,000 such reports directly at their request. The public disclosure dashboard makes that funnel visible. As of October 2, it listed 29,439 candidates, 6,123 reviewed by outside security firms and 5,674 confirmed valid by those reviewers. It also listed 6,157 total reports sent to maintainers, 5,103 acknowledged, 516 patched upstream and 584 assigned CVE or GitHub Security Advisory identifiers. Those numbers should be read carefully. The dashboard itself says a reviewer-confirmed true positive may still duplicate a known issue, sit outside the maintainer's threat model or land in a category the project will not fix. A patch is a more useful signal of impact, but it arrives later and still does not prove that downstream users installed the repaired version. This is the gap between vulnerability discovery and security. Anthropic's early tests are encouraging. It asked penetration testers to review 97 critical or high-severity scanner findings across 48 projects. Eighty-five met the bar for its coordinated disclosure process. Eleven of the other twelve were real but duplicated known issues or other findings from the scan. One was invalid. The company also reports that wolfSSL received 74 findings, judged all but two valid and turned five into CVEs. That does not establish a universal accuracy rate. The test selected high and critical findings from an early version of the service. The projects, languages, build systems and threat models that enroll later may be different. Anthropic expects a true-positive rate above 90 percent, but an expectation is not a service-level guarantee. The denominator matters too. A scanner that is 95 percent right can still bury a two-person project if it sends 200 findings in a week. A scanner with a lower hit rate can be manageable if it produces a small, well-ranked queue and good reproducers. Accuracy is a property of the report stream. Workload is a property of the project receiving it. Anthropic knows this. Its FAQ says OSS Scanner is designed for projects already able to keep up with verified high and critical reports. Projects without that capacity can remain on the company's slower coordinated disclosure path, where people review findings before they are sent. The fast track has no 90-day public disclosure clock for unvalidated reports, and a project can pause or opt out by changing or removing its configuration. That choice should happen before enrollment, not after the inbox becomes an incident. Start by measuring the existing security queue. How many private reports arrive each month? How long does it take to acknowledge, reproduce and fix them? Who can evaluate memory-safety bugs, authentication failures, supply-chain issues and platform-specific behavior? When the primary maintainer is away, who holds the embargo and who can ship a release? If those answers live in one person's head, adding a faster scanner does not create capacity. It creates another dependency on the same tired person. Next, define the intake contract. Anthropic lets a project provide a threat-model file that describes in-scope code, adversarial inputs, severity rules, useful proof-of-concept formats, patch preferences and deduplication granularity. Treat that file as an operational specification, not optional decoration. Tell the scanner whether local command execution is expected behavior, whether a denial of service requires remote unauthenticated input, which branches are supported and which build flags matter. Explain when two crashes share one root cause. State whether a candidate patch should be minimal evidence or close to merge-ready. The model will otherwise make reasonable-looking guesses about unreasonable software. Then build a private triage board with stages that describe work, not vibes. New reports should enter quarantine. A maintainer or trusted security partner checks whether the report targets the correct revision, contains enough information to reproduce the behavior and exposes details that could help an attacker. Duplicates link to one root case. Invalid or out-of-scope findings close with a reason that can improve later scans. Reproducible findings move to severity review. That review should use the project's own threat model and affected deployment patterns, not simply inherit the scanner's label. A technically dramatic crash in unreachable test code may be low priority. A plain authorization bypass on a default route may deserve immediate attention. Patch candidates require the same suspicion as any untrusted code contribution. Read the diff. Add a regression test that fails before the fix and passes after it. Run the broader test suite, sanitizers and compatibility checks. Look for behavior changes, performance regressions and a repair that covers one input while leaving the underlying bug class open elsewhere. Keep the original reproducer away from public issue trackers until disclosure is safe. Anthropic offers GPG-encrypted report emails and says reports are stored in an isolated cloud project limited to security staff who need access. Maintainers still need their own access list, retention policy and backup contact. A forwarded inbox is not a vulnerability-management system. Disclosure comes last, not automatically. Decide whether the fix needs a private release branch, an embargo with downstream vendors, a CVE or advisory, and a coordinated release across package registries. Write a short impact statement that users can act on. Credit the report if appropriate, but do not let attribution delay the patch. Finally, count outcomes instead of celebrating volume. Track reports received, duplicates, invalid findings, out-of-scope cases, median time to reproduce, median time to patch, regressions caused by suggested fixes, advisories issued and repaired versions actually released. Add maintainer hours. A free scanner that consumes the project's entire weekend has a cost even if the cloud bill says zero. This accounting is not an argument against the service. It is how a project learns whether the service is helping. The strongest part of OSS Scanner may be the option to choose. Anthropic is not quietly spraying every repository with automated issues. Core maintainers opt in. The company checks their role. Projects can shape the threat model, encrypt reports, pause delivery and fall back to human-reviewed coordinated disclosure. The weakest part is the larger economic bargain. Open-source maintainers already carry a remarkable share of the software economy's security work, often with little money or institutional support. Finding more bugs does not fund a release manager, a specialist reviewer, a compatibility lab or the quiet week required to replace a dangerous subsystem. Anthropic says its broader Cyber Mission includes funding for organizations behind widely used open-source code and support for groups that coordinate vulnerability reports. It also offers qualifying maintainers free Claude subscriptions and access to an expanded cyber program. Those are useful ingredients. The open question is whether the repair capacity grows as quickly as the discovery capacity. That is the metric worth watching. The scanner can make the invisible visible. It can hand a maintainer a reproducer that turns a suspicious code path into a concrete failing test. It can propose a patch before an attacker turns the same weakness into an exploit. For projects with mature intake and enough people, this may compress months of defensive work into days. For everyone else, the machine at the loading dock is about to get faster while the repair bench stays the same size. Before switching it on, clear the bench.