Start with lockfile history, CI build logs, registry or proxy logs, stored inventories and cloud audit trails. Together they show what was resolved, what ran, and what it could reach. Collect them early, because many of these sources are deleted on a schedule.
The principle: three questions, three sources
To write the postmortem you must answer what arrived, what executed, and what it touched. Each question has its own best evidence.
| Question | Best sources | Common gap |
|---|---|---|
| What arrived? | Lockfile history in version control, package proxy logs, registry download records | Floating ranges leave no record of the resolved version |
| What executed? | CI job logs, runner records, developer machine history, container runtime logs | Short log retention on build systems |
| What did it touch? | Cloud audit logs, secret manager access logs, network egress logs | Logging not enabled for the relevant service |
Source by source
Version control history. Commit history of manifests and lockfiles shows when a version entered. Branches matter: check every branch that builds, not only the main one.
CI logs and metadata. Build logs show which version was installed in each run and which steps ran. Export the logs for the exposure window before the platform's retention removes them. Note that some platforms keep logs for a limited, configurable time, so check yours.
Package proxy or mirror logs. If you use an internal proxy, it can show who fetched the bad version and when. It also shows whether the proxy still serves it.
Stored inventories. An inventory taken at each build is faster than reading logs. If you only have a current inventory, you can say what is there now, not what was there then. That difference should be a finding.
Cloud and secret audit trails. For any environment that ran the code, review what its credentials did during and after the window. Compare against normal behaviour.
Network records. Egress logs may show connections to unexpected hosts from build runners.
Preserve before you clean up
Cleaning up destroys evidence. Before rebuilding runners or deleting caches, copy what you need to a restricted location. Record who collected it, when, and from where. This is useful for your own review and for any later request from customers, auditors or legal advisers. This post is not legal advice, so ask your adviser about evidence handling rules.
Timestamps
Use one time zone throughout, preferably UTC, and note clock differences between systems. A one hour mismatch between CI and cloud logs can produce a false story.
Write down the limits
For each source, write what period it covers and what it cannot show. "CI logs cover the last thirty days only" is a useful line. It tells the reader how much of the window is blind.
Fix the gaps afterward
The best output of this exercise is a list of missing evidence. Typical actions: extend retention for build logs, store a signed inventory per build, enable audit logging where it is off, and standardise on UTC.
Quick check
What is the first source to collect?
The one with the shortest retention. Usually that is CI logs or proxy logs.
Can a current inventory prove what was installed last month?
No. Only a record taken at the time can. Consider storing an inventory per build.
Last reviewed: 19 October 2026.
