Most open source advisories do not name a safe earlier version. In OSV exports from 19 October 2026, between 67.1 percent (Packagist) and 82.8 percent (Go) of advisories start the affected range at the first release. Rolling back is rarely a fix. The only safe move is usually forward.
Method
We downloaded eight OSV exports on 19 October 2026 and kept vulnerability advisories (excluding MAL- and withdrawn records). For each advisory we looked at the events in every affected range and flagged it if any introduced event was "0", which OSV uses to mean the beginning of the version history.
One trap: crates.io records also use "0.0.0-0" as a starting point. Counting only "0" gives 40.3 percent for crates.io. Counting both gives 77.9 percent. The other ecosystems are unchanged by the second value. We report the combined figure for crates.io.
Limit: an advisory with several ranges is flagged if any one starts at zero, so the figure is "at least one range from the start", not "every range".
What the numbers say
| Ecosystem | Advisories | At least one range from the first release |
|---|---|---|
| Go | 9,464 | 82.8% |
| PyPI | 13,941 | 81.6% |
| crates.io | 2,799 | 77.9% |
| npm | 7,447 | 76.0% |
| NuGet | 1,142 | 72.4% |
| Maven | 7,077 | 71.2% |
| RubyGems | 1,091 | 68.0% |
| Packagist | 7,147 | 67.1% |
So in every ecosystem a clear majority of advisories mark everything before the fix as affected.
The rest usually name a first affected version, because a feature or change introduced the flaw at a known point. Those are the advisories where moving back one or two releases may help, though you give up fixes along the way.
What to do with it
For most findings the question "can I roll back?" has the answer no. Older versions are likely to have the same flaw and to be missing other fixes. Plan the upgrade instead.
Where the affected range starts later than zero, check how far back the safe versions go before you consider a pin. Compare the cost of an old version (missing patches, incompatibility with other updates) with the cost of moving forward.
For tooling, avoid logic that assumes "introduced" is a version number. Treat the zero values as sentinels meaning "since the beginning", and handle both forms. A check that misses "0.0.0-0" will undercount in crates.io by almost half, as our own first pass did.
Finally, when a vendor says "versions before X are affected", ask what "before" means in the record, and whether the range is open at the low end.
Safeguard's autonomous remediation can propose fix pull requests for upgrades. It is off by default and every category starts on Manual, so a person decides what lands.
Quick check
What does introduced "0" mean in an OSV record?
It means the affected range starts at the beginning of the version history, so all earlier releases are affected.
Why did a naive count give 40 percent for crates.io?
Records there often use "0.0.0-0" as the starting value. Counting only "0" misses them.
Sources
- OSV schema, fetched 19 October 2026
- OSV data sources and per-ecosystem downloads, fetched 19 October 2026
Last reviewed: 19 October 2026.
