Use the published and modified timestamps for when the public learned of a flaw, and the fixed event in the affected ranges for the first version that resolves it. Together with your own PR, merge and deploy times, they let you draw a complete exposure timeline with no guesswork.
Why the advisory side matters
An exposure window has an outside half you do not control and an inside half you do. To report honestly, you need to separate them. If a fix was published a week before you shipped it, that week is yours. If the advisory appeared an hour before your alert, the delay is not.
What the OSV schema provides
The Open Source Vulnerability schema describes a common record format. Each record includes an id, a modified timestamp, a published timestamp, an optional withdrawn timestamp, aliases, a summary and details, severity entries, and a list of affected packages. Each affected entry has an ecosystem, name and ranges, and ranges contain events such as introduced, fixed, last_affected and limit. The record also has references and credits.
| Field | What it tells you |
|---|---|
| published | When this record was first published by its source |
| modified | When the record last changed |
| withdrawn | If set, the record was retracted |
| aliases | Other IDs for the same flaw, such as a CVE |
| events with introduced | The first affected version |
| events with fixed | The first version containing the fix |
| references | Links to advisories, patches and commits |
Treat published as the timestamp of that record, from that source. Another database might have published earlier or later. When you build a timeline, note which source your timestamp came from.
Putting it into a timeline
- Advisory published. Use the earliest reliable source you can cite.
- Fix available. Find the version in the fixed event, then check the release date in the package registry.
- Your alert. The timestamp from your tooling.
- PR opened, merged, deployed. From your repository and pipeline.
- Verified. The time you confirmed the running version.
Each interval is a stage with a different owner.
| Interval | Owner |
|---|---|
| Advisory to fix released | Upstream |
| Fix released to your alert | Your tooling |
| Alert to PR | Your bot or triage |
| PR to merge | Review |
| Merge to deploy | Pipeline |
Cautions
- Records can be modified after the fact, so capture the timestamps when you build the timeline rather than rereading them months later.
- A withdrawn record should be marked, not silently dropped.
- Aliases mean one flaw can have several records. Deduplicate before counting.
- The fixed event is a version, not a date. Look up the release date separately.
Keep it simple
You do not need all of this for every finding. Capture the advisory published time, fix release time and your own four timestamps for each high priority finding. That is enough to answer what stage cost the most.
Try it yourself
Open the zero-day watch demo and look at how a newly published flaw is matched against your inventory. That match is the point where the inside half of your timeline begins.
Click through it at your own pace, or open it full screen.
Safeguard offers zero-day discovery and dependency scanning. A free scan is available at gold.safeguard.sh/scan.
Quick check
Is the published timestamp the date the flaw was found?
No. It is when that record was published by its source. The flaw may have been known privately earlier.
Where do I get the fix date?
The fixed event gives a version. Check the registry for when that version was released.
Sources
Last reviewed: 19 October 2026.
