Advisories are living records. In OSV exports from 19 October 2026, between 59.9 percent (npm) and 89.6 percent (RubyGems) of advisories carry a modified date more than 30 days after their published date. A scan result from last quarter can be wrong today, in either direction.
Method
We downloaded eight OSV exports on 19 October 2026 and kept vulnerability advisories (excluding MAL- and withdrawn records). For each we compared the modified and published timestamps. We also counted records modified in the 30 days before 19 October.
Limits matter here. A modified date changes for any edit, including a typo fix, a new reference or a bulk metadata update. It does not tell you what changed, and it cannot tell a fix of the affected range from a cosmetic edit. We report the timestamps only.
What the numbers say
| Ecosystem | Modified more than 30 days after publication | More than 365 days after | Median gap in days | Modified in the last 30 days |
|---|---|---|---|---|
| RubyGems | 89.6% | 73.4% | 930 | 1.1% |
| Maven | 86.8% | 65.2% | 588 | 1.7% |
| Packagist | 78.0% | 52.7% | 460 | 2.9% |
| crates.io | 69.1% | 48.0% | 308 | 10.4% |
| PyPI | 65.1% | 46.5% | 212 | 5.3% |
| NuGet | 65.0% | 51.1% | 408 | 5.7% |
| Go | 61.7% | 37.1% | 105 | 6.2% |
| npm | 59.9% | 41.1% | 114 | 5.6% |
In every ecosystem, a majority of records were touched well after publication, and in four a majority were touched more than a year later.
Recent activity is also uneven. 10.4 percent of crates.io records were modified in the last 30 days, against about 1 to 6 percent elsewhere. Among records published more than a year ago, 5.5 percent of crates.io records changed in that window, against 0.0 to 1.3 percent in the other seven ecosystems.
What changes in a record
We did not inspect edits, but the fields most likely to move are the ones you rely on. Affected ranges get corrected as maintainers find the true first or last affected version. A fixed version is added once a patch ships. Severity is added or revised. An alias to a CVE appears once a CVE is assigned.
Each of those can flip a finding: a version you were told was vulnerable is cleared, a package with no fix gets one, or a rating moves above your gate threshold.
What to do with it
Rescan on a schedule, not once. Daily is reasonable for production dependencies, and it costs little because the matching is automated.
Keep the date of the data. When you record a decision such as "not affected" or "accepted risk", note when you made it and review it, because the record behind it can change.
Alert on changes to findings you already triaged. A record that moves from "no fix" to "fixed in a later version" is a task. A record that moves up in severity deserves a second look.
Safeguard's SBOM and dependency scanning can be rerun against updated advisory data, and the free scan at https://gold.safeguard.sh/scan shows a current result for one repository.
Try it yourself
Open the demo and look at how monitoring turns a change in advisory data into a new finding on an inventory you already scanned.
Click through it at your own pace, or open it full screen.
Quick check
Does a modified date mean the advisory changed in a way that matters?
Not necessarily. Any edit changes it, including minor ones. It does show that records are not static.
How often should I rescan?
Daily for production dependencies is a reasonable default, with a rescan whenever a large advisory batch lands.
Sources
- OSV data sources and per-ecosystem downloads, fetched 19 October 2026
- OSV schema, fetched 19 October 2026
Last reviewed: 19 October 2026.
