In OSV exports downloaded on 19 October 2026, 47.1 percent of PyPI advisories and 42.9 percent of npm advisories carry a 2026 publication date, even though the year is not over. One PyPI month holds 2,995 records. Publication dates reflect when records were filed, so do not chart them as a trend in flaws.
Method
We downloaded eight OSV exports on 19 October 2026 and kept vulnerability advisories (excluding MAL- and withdrawn records). We counted by the year and month of the published field. We did not check the underlying disclosure dates.
What the numbers say
Share of each ecosystem's current advisories with a 2026 publication date (to mid October):
| Ecosystem | Advisories | Published in 2026 | Share |
|---|---|---|---|
| PyPI | 13,941 | 6,562 | 47.1% |
| Go | 9,464 | 4,234 | 44.7% |
| npm | 7,447 | 3,196 | 42.9% |
| NuGet | 1,142 | 397 | 34.8% |
| crates.io | 2,799 | 844 | 30.2% |
| Packagist | 7,147 | 1,641 | 23.0% |
| RubyGems | 1,091 | 188 | 17.2% |
| Maven | 7,077 | 991 | 14.0% |
Monthly counts show lumps. PyPI had 120 to 803 records in most 2026 months, then 2,995 in July. Other examples from earlier years: Maven has 2,977 in 2022 against 390 in 2021 and 936 in 2023, and Packagist has 2,313 in 2022 against 422 in 2021 and 744 in 2023.
Those jumps look like backfills or bulk imports. We do not know the cause for any of them. A real surge in new flaws would not usually arrive in a single month in one ecosystem only.
How to read advisory counts
Treat an advisory feed as an event log of record publication, not a clock of discovery. Three rules help.
- Do not draw a trend line from
publishedalone. A record can describe a flaw found years earlier. - Use a second date where you can. A CVE's published date, a fix release date or the commit that fixed it each answer a different question.
- Compare within a feed, not across. A larger count in one ecosystem may come from how its advisories are filed and who files them.
For your own reporting, the useful series are counts about your estate: new findings per week against your lockfiles, and time from record to fix. Those do not depend on how an upstream feed batches its work.
If a feed suddenly adds thousands of records, rescan. New matches against your inventory are the part that matters, and the rescan finds them.
Whatever tool you use, rescan on a schedule. Safeguard's SBOM and dependency scanning supports that, so a bulk import shows up as new matches against your estate, not as a headline number.
Try it yourself
Open the demo and watch how a monitored inventory surfaces a new match when advisory data changes.
Click through it at your own pace, or open it full screen.
Quick check
Does a 2026 spike mean more vulnerabilities were found?
Not necessarily. The date is when the record was published in the feed, and large single month jumps often come from batches.
What should I chart instead?
New findings against your own inventory and time to fix them.
Sources
- OSV data sources and per-ecosystem downloads, fetched 19 October 2026
- OSV schema, fetched 19 October 2026
Last reviewed: 19 October 2026.
