Vulnerability management · News & analysis
AI can find more vulnerabilities. Who is going to close them?
Anthropic’s disclosure dashboard shows the work between finding a vulnerability and getting it patched. How teams can build a useful triage process.
Anthropic’s disclosure dashboard, updated August 26, reports 2,300 vulnerabilities disclosed across 392 open-source projects and 421 known upstream fixes. It separates discovery, review, disclosure and remediation, and identifies human triage as a constraint on the process.
Those are the publisher’s figures for its own program at that date. They are not a measure of every open-source project’s security, and an upstream fix does not establish that downstream users have installed it. The distinction between those stages is the useful lesson for a development team.
Treat a finding as the beginning of a workflow
Our analysis is that expanding discovery capacity also expands the need for a disciplined intake process. A report should name the affected component, explain the impact and provide enough evidence for an authorized reviewer to reproduce the issue. A convincing description without a clear affected version is difficult to prioritize.
Consider a dependency alert in an application that has several deployed environments. The team needs to connect the report to the dependency version actually running, the reachable feature and the person responsible for the service. Without that connection, the finding can remain in a queue while everyone assumes somebody else is handling it.
Use separate states for separate evidence
Distinguish an unconfirmed report from a validated vulnerability, and a proposed patch from a deployed repair. Record why a report is considered in scope or not applicable. The explanation should survive a change of owner or a second report of the same issue.
For a fix, retain the change, the relevant test and a deployment reference. Where the issue comes from an external project, track both the upstream advisory and your own rollout. This allows a review to answer two different questions: has a repair become available, and are our affected systems now running it?
- Require an owner and an affected component for actionable findings.
- Separate duplicate detection from the decision to accept a risk.
- Review exploitability and business impact in the actual deployment context.
- Close remediation with deployment evidence, not only a merged pull request.
Measure throughput beyond discovery
Count validated findings, time to an assigned owner and verified repairs alongside the number of reports received. If discovery rises while the unresolved queue grows, the next investment may be triage capacity or clearer ownership rather than another scanner.
AI-assisted review can be valuable inside this process, especially when it helps explain unfamiliar code or prepare a reproducible report. Its output still needs a place in the same evidence chain. A vulnerability is not resolved because a tool has stopped mentioning it.
Put your security work in motion.
Book a meeting