Free Security Scans Still Need a Triage Budget

Anthropic's OSS Scanner offers eligible open-source projects recurring vulnerability scans at no charge, with reports delivered without human review. Its documentation describes an optional fast track alongside the company's existing process for sending human-reviewed findings. Maintainers receive reports that may include proposed patches and root-cause analysis.

That distinction matters. A vulnerability report claims that software permits an unsafe action. Triage means deciding whether that claim is valid, how urgently it matters and who should handle it. Receiving the report starts that work. It doesn't establish that your project has the flaw, that the proposed fix is sound or that users need an emergency release.

The service's eligibility guidance says it is intended for projects already able to handle verified high or critical reports. Gunner Technology's recommendation follows that boundary: establish a working response path before adding an unreviewed feed. More discovery helps when the project can turn a credible finding into a tested repair.

Before enrolling, name the person responsible for the private inbox and define what happens when a report arrives. The owner needs a backup, somewhere restricted to store the evidence and a route for urgent decisions. A shared address without responsibility attached leaves everyone free to assume somebody else is reading it.

Write down which code and attack conditions matter. A threat model is a description of what you protect, who might attack it and which actions should be impossible. The scanner's configuration supports a threat model covering scope, severity and useful evidence. Use it to reduce guesses about your project's boundaries.

Then budget verification work. Decide what routine triage the factory may perform, how much isolated test capacity it can use and when a maintainer must decide. As we argued in Popularity Does Not Pay the Maintainers, the work behind a dependency needs support. Free access to another tool doesn't supply that support.

Reproduce the claimed failure against the affected version before treating the suggested patch as a solution. Preserve the report, code revision, setup and observed result. Record the attacker's starting access and the boundary they allegedly crossed. That gives the verifier a claim it can test rather than a confident explanation it can repeat.

Run supplied demonstrations in an isolated environment without production credentials or access to private systems. Let an agent assemble the environment and collect results within those limits. A failed reproduction needs a reason: missing conditions, a mismatched version or evidence against the claim. It should remain unresolved when the available setup cannot answer the question.

For a confirmed issue, require a separate check that exposes the original failure and rejects it after the repair. Test the legitimate behavior the patch could break as well. Security Has to Run at Generation Speed makes the broader case for independent proof. Here, the concrete job is to establish both that the vulnerability existed and that the repair preserves the product's contract.

Pause new unreviewed reports when the existing backlog exceeds your agreed response capacity. Base that decision on unresolved findings, their age and the effort needed to verify them. Keep a separate urgent route for credible threats so pausing routine intake doesn't bury an immediate exposure.

Anthropic's pause and disclosure policies distinguish these unvalidated findings from its human-reviewed disclosure process. Projects can disable the automated feed and return to the standard process. Keep that distinction in your own records too: an unverified report, a confirmed vulnerability and an approved release are different states.

Our position is that the pause control belongs in the operating plan before enrollment. Agents can group duplicates, gather missing evidence and show where work is stuck. People decide which risk deserves attention and whether the result is right. An inbox that keeps growing while maintainers repeatedly defer judgment needs less intake or more funded response capacity.

Start with a project whose maintainers can inspect the full path from receipt to resolution. Track which reports were reproducible, which required clarification, which repeated known issues and which led to a repair. Include the time spent dismissing unsupported claims. That work is part of the service's operating cost even when the scanning bill is empty.

Use those results to adjust scope, evidence requirements and capacity. Keep the feed when it helps the project address meaningful weaknesses without displacing more urgent work. Pause it when verification falls behind, and name what must change before restarting. Neither a busy inbox nor an impressive patch proposal settles that decision.

The factory should carry the repeatable work: intake records, isolated runs, duplicate checks and preserved results. Maintainers should spend their judgment on consequences and release decisions. Enable the scan when that route exists. Expand it when completed repairs show that the project can carry the additional work.