Project Glasswing Patch Gap: 6,157 Disclosed, 516 Patched

The number that stopped me was not the big one. Secondhand reporting says Glasswing partners have verified at least 129,000 vulnerabilities. The number that mattered sat on Anthropic's disclosure dashboard: 6,157 disclosed, 516 patched, last updated 2 October 2026. Roughly 5,600 reports were still waiting on someone to fix them.

This post reads those figures against the primary sources: Anthropic's May update, its disclosure dashboard, an oss-security mailing list quote, and critics who think the numbers do not reconcile. I attribute every figure to the page I read it on, I include no exploit detail, and the second half is defender-focused: what a maintainer and what a team that depends on open source should change this week.

What the sources actually measure

Three different counts circulate under the Glasswing name, and mixing them is how bad arguments start. Anthropic's 22 May update says partners had found more than ten thousand high or critical severity vulnerabilities, that about 530 high or critical bugs had been disclosed to maintainers, and that 75 of those 530 had been patched. The disclosure dashboard counts something wider: every vulnerability Anthropic has reported to a maintainer, whatever the severity. And a third figure, the 129,000 verified vulnerabilities from partners between April and July, appears on the Software Improvement Group page, which attributes it to Anthropic and gives no independent check.

Definitions matter more than headlines here. The dashboard says disclosed means reported to maintainers, not published, and that patched upstream counts fixes maintainers have released, which it says does not guarantee those patches have been widely installed. It also says the disclosed count is a subset of everything Claude models have found, because independent human triage and review is the rate limiting step.

Disclosed versus patched, in three snapshots

I put the figures I could read side by side. The ratio column is my own arithmetic, patched divided by disclosed, and each row has a different denominator, so compare the trend and not the exact percentages.

Between the two dashboard snapshots, disclosures grew about fourfold while patches grew about fivefold, so the share moved only from 6.1 to 8.4 percent. That leaves 5,641 reports, by my subtraction, with no known fix. The dashboard qualifies its own patch count with the words to our knowledge, and the oss-security quote notes that some maintainers ship a fix without publishing an advisory, so the true patched number is probably somewhat higher. It does not close a gap this size.

Why the bottleneck is people, not scanners

Anthropic states the constraint directly in its May update: progress is limited by how quickly findings can be verified, disclosed and patched, and the bottleneck is the human capacity to triage, report, and design and deploy patches. It adds that several maintainers said they were severely capacity-constrained, and that some asked Anthropic to slow its disclosure rate. It reports that a high or critical bug takes about two weeks to patch on average.

That is the part worth internalising if you maintain a package. A tool that can generate reports faster than a volunteer can read them does not make the ecosystem safer by itself; it moves the queue. Anthropic's advice is aimed at both sides: software developers should shorten patch cycles and make security fixes available as quickly as possible, and network defenders should shorten patch testing and deployment timelines while relying on controls that do not wait for any single patch.

Where the numbers are contested

I would not repeat any of these figures without their qualifiers. VulnCheck, in a post dated 8 September 2026, argues that only 9.8 percent of Anthropic's findings had reached a maintainer, counts 202 findings as fixed in the ledger it examined, and says Claude rated 91.5 percent of findings critical or high against 51.3 percent by maintainers. It concludes that the receipts do not reconcile. Bruce Schneier, in June, called the low patch counts weird and said Anthropic asking people to trust it is a big problem because the details are not released.

These are critics reading public ledgers, and I could not verify their counts against the live dashboard, so treat them as a challenge to check rather than a rebuttal. Anthropic's own side has caveats too. Its dashboard hides project names and bug types until a fix ships, which is standard coordinated disclosure but also means outsiders cannot audit individual items. The 129,000 and 33,000 figures reached me through the Software Improvement Group page, not an Anthropic page I could open, so I cite them as reported, along with its statement that Anthropic expects the real figure to be at least five times higher.

My reading: both things can be true. The discovery side may be large, the verified side is smaller, and the fixed side is smaller again. Whichever number you pick for the top of the funnel, the bottom of it is the number your own risk depends on.

If you maintain an open source project

You cannot out-triage a machine, so make the front door cheap. GitHub's private vulnerability reporting, which a repository owner or administrator enables under Settings, then Advanced Security, gives reporters a Report a vulnerability button on the Advisories page and notifies administrators and security managers watching the repository. A short SECURITY.md then tells reporters what you need. This is the one I would start from, including the line asking whether an AI tool was used, because it lets you sort the queue by how much a human has already verified.

# SECURITY.md  (repository root, or .github/SECURITY.md)
# Goal: a reporter, human or AI-assisted, knows in one screen where to go,
# what a good report contains, and what you will and will not promise.

## Reporting a vulnerability

Use "Report a vulnerability" on this repository's Security > Advisories tab.
Please do not open a public issue.

A report we can act on within days contains:
- the affected version or commit
- the smallest input or configuration that shows the problem
- what an attacker gains (read, write, crash, code execution)
- whether you used an automated or AI tool to find it, and what a human
  has verified by hand

## What to expect

- Acknowledgement: best effort, from a volunteer team.
- Duplicates and unverified machine output may be closed with a pointer
  to this file. That is not a judgement of you; it is triage capacity.
- We publish a GitHub Security Advisory when a fix ships.

## Supported versions

| Version | Receives security fixes |
| ------- | ----------------------- |
| 3.x     | yes                     |
| 2.x     | critical only           |
| < 2.0   | no                      |

Two honest limits. A file that says duplicates may be closed protects your time but will discourage some good reports, so word it kindly. And GitHub also lets you add a VULNERABILITY_REPORT.yml in the .github directory to customise the form and require a CWE on each report; I have not tested that file's schema, so read the docs before copying anyone's version.

If you depend on open source

Your job is to shrink the time between a fix existing and a fix running in production. Dependabot can group every security update into one pull request, and the docs say cooldown is available only for version updates, not security updates, so a delay setting cannot hold back a fix. Pair it with a lockfile scan so you know what you actually ship.

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "daily"
    # Security updates are subject to a separate, fixed limit of 10 open PRs.
    # This limit only governs ordinary version updates.
    open-pull-requests-limit: 10
    groups:
      # One PR per run for security updates instead of one PR per advisory.
      security-group:
        applies-to: "security-updates"
        patterns:
          - "*"
    # Cooldown delays ordinary version bumps only. It is documented as not
    # available for security updates, so a fix is never held back by it.
    cooldown:
      default-days: 5
      semver-major-days: 30

# Know what you ship, from the lockfile, with no network calls to your code.
osv-scanner scan -L package-lock.json --format json --output-file osv-report.json

# Several lockfiles in a monorepo:
osv-scanner scan -r ./services/

# Wrong: running "osv-scanner fix" on a dependency tree you do not trust.
# The tool's own docs warn that guided remediation can trigger the package
# manager to run scripts or follow external registries.
# Right: run fix only on your own repository, on a throwaway branch.
osv-scanner fix -M package.json -L package-lock.json

The grouping and the scan are mine to recommend, not Anthropic's. Anthropic's advice to defenders is to shorten patch testing and deployment timelines, and Software Improvement Group's page says taking three months to patch a critical vulnerability is now a much bigger liability. The config above is one way to act on that.

What goes wrong, and who owns which step

The expensive mistake is treating a released patch as a fixed system. The dashboard itself warns that patched upstream does not guarantee wide installation, and a grouped security pull request that fails one test can stall every fix inside it, which is my own caution about grouping, not a documented behaviour. Each of the four parties below owns a different step, and each has a failure mode.

The table is my synthesis of Anthropic's recommendations to developers and defenders, plus the maintainer-capacity reports in its May update. It is not a framework any of those sources published.

What to do on Monday

Five steps, in the order I would do them, each small enough for one working day.

1. Enable private vulnerability reporting on every public repository you own, and commit a SECURITY.md with a supported versions table.
2. Run osv-scanner against each lockfile and keep the JSON report as a baseline you can diff next week.
3. Turn on Dependabot security updates grouped into one pull request, and measure how many days a security pull request waits before someone merges it.
4. Find the slowest part of your own pipeline between merge and production, and write down the number. Anthropic and the Software Improvement Group page both point at deployment speed.
5. Check Anthropic's disclosure dashboard for the date it was last updated before quoting any figure, because it is a living page and these numbers will move.

The rule I take from this: a discovery number is a headline, a patched number is a queue, and an installed number is your risk. Discovery got dramatically cheaper in 2026, while triage, fixing and deploying are still human work. Build your process around the slowest of those three, because that is where the unpatched 5,641 are waiting.