The date that matters for scoping is when the bad version was published and became installable, through to when your own systems stopped serving it. The disclosure, advisory and edit dates in a write-up matter too, but they answer other questions. Learn to tell them apart, then read each one for what it says.
Why dates cause confusion
An incident write-up often contains four or five dates in two paragraphs. A reader scanning quickly may pick the first one and treat it as "when it happened". That is how teams scope the wrong window and either miss an exposure or raise a false alarm.
Each date is true. They simply describe different events. Reading them in order, with a label on each, removes most of the confusion.
The five dates
| Date | What it marks | Question it answers |
|---|---|---|
| Publish date | When the bad version appeared in the registry | When could anything have installed it? |
| Removal or fix date | When the registry or maintainer removed or replaced it | When did it stop being available upstream? |
| Discovery date | When someone noticed the problem | How long was it live before anyone knew? |
| Disclosure or advisory date | When a public notice or record appeared | When could scanners and the public learn of it? |
| Last edit date | When the write-up or record was changed | Is what I read still current? |
A sixth date belongs to you: the time your own mirror or cache stopped serving the version. It is often the latest of all.
Where to find each one
Do not rely on prose alone. Many dates can be read from the systems themselves.
- npm publish time. The npm documentation shows that
npm viewcan read a package'stimefield, including a single version's entry. Runnpm view some-package time --jsonand read the timestamps for the versions named in the write-up. - PyPI upload time. The PyPI JSON API documentation describes release file entries that include upload time fields. The route is
https://pypi.org/pypi/some-project/json. - Advisory creation and update dates. The GitHub Advisory Database documents search qualifiers for created and updated dates, in ISO 8601 form, with sorting by newest or most recently updated. That gives you the advisory side of the timeline.
- Download timing. The npm download counts documentation says daily data is processed soon after UTC midnight, so a given day's numbers reflect UTC days.
Registry timestamps are machine records and are generally more reliable than a date typed into a blog post. When the two disagree, note both and trust the registry for when the file existed.
A worked example
Imagine a write-up published Friday at 16:00 UTC. It says: "On Tuesday we noticed unusual behavior in version 6.1.0. The version was removed on Wednesday. An advisory was filed Thursday."
Read naively, you might think the problem began Tuesday. Check the registry and you find 6.1.0 was published the previous Friday at 22:10 UTC. Now the timeline looks like this.
- Friday 22:10 UTC (previous week): version 6.1.0 published.
- Tuesday: maintainer notices something odd. Discovery.
- Wednesday: version removed from the registry.
- Thursday: advisory filed. Scanners can begin to match.
- Friday 16:00 UTC: write-up published.
Your exposure window runs from the previous Friday night to Wednesday, plus any mirror lag. That is nearly a week, not the single day the first sentence suggests. A build that ran on Saturday, long before anyone noticed anything, falls inside it.
If you had used the discovery date as the start, you would have missed every build from the weekend and Monday. That is the mistake this post exists to prevent.
Steps to build the timeline
- Copy every date and time from the write-up into the ticket, each with a label for what it marks.
- Pull the registry timestamps for the versions named, and add them with their source.
- Convert everything to UTC. Mixed time zones cause errors of hours.
- Add your own dates: when your mirror stopped serving it, and when your last relevant build ran.
- Choose the window start from the publish time and the end from the latest of removal and your own cutoff.
- Note any dates that conflict and who you trust for each.
See the earlier post on building the exposure window for how to match builds to the result.
Mistakes to watch for
| Mistake | Effect | Fix |
|---|---|---|
| Starting the window at discovery | Misses builds before anyone noticed | Start at publish time |
| Ending at the write-up date | Misses mirror and cache lag | End at your own cutoff |
| Trusting a date typed in prose | May be rounded or in a local time zone | Check the registry timestamp |
| Ignoring edit dates | You may act on an outdated version of the page | Note when you read it and when it was last changed |
A short habit helps: whenever a date appears in a write-up, write a label next to it in your notes before you use it. If you cannot say what the date marks, it is not ready to use.
Try it yourself
Click through it at your own pace, or open it full screen. Use it to see how items for new issues appear over time, and practice labeling which date each timestamp represents.
Safeguard's zero-day discovery and SBOM inventory give you the package and version side of this question, so matching a named version against what you run is a lookup rather than a search.
Quick check
Which date should I use as the start of my exposure window?
The registry publish time of the bad version, not the discovery or disclosure date. Anything installed after publication could have pulled it.
What if the write-up and the registry disagree on a date?
Record both, trust the registry timestamp for when the file existed, and note the disagreement in the ticket.
Why convert everything to UTC?
Mixed time zones can move a build inside or outside the window by hours. UTC makes registry data, logs and write-ups comparable.
Sources
- npm view documentation
- PyPI JSON API documentation
- Browsing security advisories in the GitHub Advisory Database
- npm registry: package download counts
Last reviewed: 19 October 2026.
