Several kinds of evidence expire on their own: web pages get edited, npm per version download counts cover only seven days, GitHub inbox notifications last three months unless saved, and caches get purged. In the first hour of a security story, save these before you start the analysis.
Why the first hour
Analysis can be redone. Evidence that has rolled off cannot. A short, boring save step at the start costs minutes and protects your ability to explain what you knew later.
The list
| Evidence | Why it expires | How to save it |
|---|---|---|
| The source write-up | Authors edit or remove pages | Archive plus a PDF print, see archiving a write-up |
| Per version npm downloads | The per version API only covers the previous 7 days | Query it and store the JSON |
| Daily npm downloads | Data lands after UTC midnight and queries are limited by range | Pull the range for the window and store it |
| GitHub notifications | The inbox keeps them for 3 months unless marked Saved | Copy key items into the ticket or mark them Saved |
| Registry metadata | Versions can be removed or edited | Save the JSON for the package |
| CI logs | Retention is often short | Export the runs inside the window |
| Build caches and mirrors | Purged during cleanup | Note what they held before purging |
The seven day and three month figures come from the npm and GitHub documentation listed below. Check your own CI and logging retention settings, since those vary by setup.
Commands worth running right away
# registry facts for an npm package
npm view some-package versions --json > versions.json
npm view some-package time --json > time.json
# per version downloads, last 7 days only
curl -s https://api.npmjs.org/versions/some-package/last-week > versions-last-week.json
# PyPI project record
curl -s https://pypi.org/pypi/some-project/json > pypi-record.json
Store the files in the incident ticket with the date and time in UTC. They are small.
Save before you clean up
The most common mistake is cleaning first. Purging a cache, deleting a build or rolling back a lockfile feels responsible, and it also removes the proof of what was installed. Record what exists, then clean. The same goes for rebuilding a machine: capture the lockfile, the installed package list and the relevant logs first. See the post on preserving evidence before cleaning up.
Keep a short evidence index
In the ticket, keep a list: what it is, where it is stored, when you captured it and who captured it. A reviewer can then see in one place what you had at each point.
A worked example
Imagine that at 07:40 UTC a notice says two versions of an npm package were published by an attacker. You decide to run the save step before any analysis.
The routine takes about ten minutes.
- Page. You archive the notice, print it to PDF and paste the key sentence into the ticket, all stamped 07:41 UTC.
- Registry. You run the registry commands and save the versions and time data, 07:44 UTC.
- Downloads. You run the per version query for the last week. The bad version appears with its counts. You save the JSON, 07:46 UTC. Next week this query would no longer return that version's numbers.
- Notifications. You mark the two security alert notifications in your GitHub inbox as Saved, 07:48 UTC.
- CI. You export the logs of the last 20 builds of the two services and save them to the incident folder, 07:52 UTC. Your CI keeps logs for 30 days, so these would survive for now, but you export anyway.
- Index. You add a six line evidence index to the ticket: what, where, when, who.
Only then do you start your actual analysis. If you find nothing, the folder shows exactly what you looked at. If you find something, nothing that matters has disappeared.
How long does each thing last
Retention is the whole question, so write it down once for your own systems.
| Source | Typical retention question | Where to check |
|---|---|---|
| npm per version downloads | 7 days, per the npm documentation | Fixed by the registry |
| GitHub inbox | 3 months unless saved, per GitHub docs | Fixed unless you save |
| CI logs | Set by your CI configuration | Your CI settings |
| Application and proxy logs | Set by your logging setup | Your logging settings |
| Mirror and cache contents | Set by your cleanup policy | Your registry or mirror settings |
| Web archive copies | Persist, but only if the save worked | Open the archive link to verify |
The first two rows come from documentation. The rest depend on how you configured things, so look them up before an incident rather than during one.
What to do about short retention
If you discover that your CI or proxy logs expire quickly, you have two options. Lengthen the retention for the logs that matter, or add an export step to your incident routine. The cost of keeping build logs for longer is usually small compared with the cost of being unable to say whether a build ran during a bad window.
Make that decision on a quiet day. Under pressure, nobody wants to review retention settings.
Make the save step automatic
The more of this you can script, the less it depends on memory. A small script that takes a package name, runs the registry queries, downloads the JSON records and writes them into a dated folder turns a ten minute chore into thirty seconds. Keep the script in your incident repository next to the runbook.
Remember that saving is not analysis. It is insurance. You will often discard everything you saved, and that is a good outcome.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a project is watched over time, since a dependency can change status after you last checked.
Quick check
How long do npm per version download counts last?
The npm documentation says per version counts are only available for the previous 7 days.
Should I save evidence even if I think we are not affected?
Yes, it is cheap. It lets you show later why you reached that conclusion.
Is exporting CI logs worth it if they are kept for 30 days?
Often yes. Incidents sometimes surface late, and an export costs seconds. Check your own retention settings before relying on defaults.
Sources
- npm registry: package download counts
- Configuring notifications, GitHub Docs
- npm view documentation
- PyPI JSON API documentation
- Save Pages in the Wayback Machine, Internet Archive Help Center
Last reviewed: 19 October 2026.
