# Anthropic OSS Scanner: How to Triage Reports Without Losing a Week The scanner can find more candidate bugs than a small team can review, so its configuration needs to reflect the work maintainers can actually absorb. By Paras Madan | 2026-11-11 Anthropic OSS Scanner sends participating open-source maintainers AI-generated security reports without human review. To keep the service useful, define the project's threat model, choose report channels deliberately and require a reproducible path from untrusted input to impact before accepting a finding or patch. That distinction matters after [VulnCheck's November 9 critique](https://www.vulncheck.com/blog/anthropic-glasswing-november-update) of Project Glasswing and the burden of reviewing scanner reports. More findings can mean more defensive coverage, but they also create work for the same maintainers who need to ship the fixes. A free scan still consumes someone's engineering time. ## Understand which reports you are receiving [Anthropic's service description](https://red.anthropic.com/oss-scanner/) separates OSS Scanner's unreviewed reports from its human-reviewed coordinated vulnerability disclosure process. OSS Scanner is an opt-in service for eligible open-source projects, with acceptance assessed case by case. It is intended for teams that already have capacity to handle verified high- and critical-severity reports. The unvalidated findings do not currently carry the standard 90-day disclosure deadline. If Anthropic later validates one through its separate CVD process, the policy allows a disclosure period beginning when the maintainer is notified of that human validation. This is why a headline true-positive rate or a count from the broader Glasswing ledger cannot tell you how much work your next OSS Scanner batch will create. Different review stages and report populations answer different questions. For your project, measure how many reports survive your own reproduction and scope checks. ## Put scope and severity in the threat model The [current repository instructions](https://github.com/anthropics/oss-scanner) distinguish three useful files. The threat model describes security boundaries and severity. Report guidelines describe the evidence and format you want. Patch guidelines describe the shape of a proposed fix. Mixing these together makes the configuration harder to maintain. Consider a hypothetical image-processing library used by a web service. A useful threat-model note might say: ```text Remote users can supply image bytes but cannot choose server startup flags or edit the filesystem. The upload handler is an exposed entry point. Administrative command-line tools have a different trust model. For each claimed impact, distinguish a process crash from data access, data modification or code execution. Explain the deployed configuration needed to reach the affected code. Do not assume a demonstration against an internal helper proves reachability through the upload handler. ``` This is a suggested starting point, not a tested configuration. Replace those assumptions with the real deployment. If the command-line tool processes untrusted files in your actual product, excluding it would hide a genuine attack surface. **A threat model should describe reality, even when that produces more work.** Its purpose is to prevent the scanner from reasoning about an imaginary deployment, not to make the report count look better. ## Choose channels without confusing filtering with validation The official [project configuration template](https://github.com/anthropics/oss-scanner/blob/main/templates/project.yaml) supports a minimum severity for email and GitHub private security reports. The defaults are low for email and none for GitHub. Available thresholds are low, medium, high, critical and none; a report can qualify for both channels. For example, the following fragment asks for high-or-above reports by email while leaving GitHub reporting off: ```yaml output_format: email: min_severity: high github_security_advisory: min_severity: none ``` That reduces incoming volume by accepting a visibility tradeoff. It does not independently establish that the remaining reports are high severity, and it can keep a misclassified lower-severity report out of that channel. A team trying the service should make this decision explicitly rather than copying the fragment as a universal recommendation. For many maintainers, a better first experiment is keeping lower-severity email but routing it into a dedicated review queue. Give that queue an owner and a fixed review budget, then see whether the useful findings justify the time. ## Ask for a report you can verify quickly Anthropic's [report-guidelines template](https://github.com/anthropics/oss-scanner/blob/main/templates/report_guidelines.md) allows projects to specify report structure and required facts. Use that space to request evidence in the order a reviewer needs it. A long explanation of why a bug class is dangerous rarely helps establish whether this instance exists. A useful local checklist is: 1. Identify the affected revision and the necessary build or runtime settings. 2. State what an attacker controls before the problem occurs. 3. Show the supported entry point and the path to the alleged failure. 4. Provide a minimal reproducer, expected result and observed result. 5. Explain the security boundary crossed, with uncertainty left visible. 6. Check whether an existing issue or patch already covers the same root cause. Do not run an unfamiliar reproducer against production or a developer machine containing credentials. Use a disposable test environment with the access it actually needs. The report is an input to your investigation, not permission to trust its commands. ## A worked triage example Suppose the image-library report claims that a crafted file can crash the service. The reproducer invokes a private decoding helper directly. Before debating its suggested severity, check whether the public upload path accepts that file and reaches the same helper with equivalent settings. If the service rejects the file before decoding, record that boundary and keep the reproducer as evidence for the narrower condition it does demonstrate. If the public path does crash, determine whether the failure kills one isolated worker or the whole service. Those outcomes deserve different operational priorities even though both can be described as a crash. Only then review the patch. A change that prevents this sample from failing may also reject valid files or leave another route to the same root cause. Add a regression test for the confirmed problem and run the surrounding compatibility tests before merging. ## Measure the work saved, not reports received Keep a small record of each batch: reports received, duplicates, reproducible in-scope findings, unresolved cases, fixes merged and review time. Do not count an unresolved report as a false positive just because the allotted review session ended. If the queue keeps growing, reduce scope only where the threat model supports it, change routing, or pause automated reports with the documented `disabled: true` configuration. Clearing the queue gives you a cleaner basis for deciding whether to resume. The useful outcome is a security defect fixed with less total effort than it would otherwise have taken. A scanner that finds something real is valuable. A scanner that helps a maintainer reach a safe fix without drowning the next release is considerably more valuable. I’m Paras. I work at the intersection of AI, engineering and distribution. I help technical teams explain how their products work, including the limitations developers need to understand before using them. [Book a 30-minute call](https://cal.com/paras-madan/30min).