Before you clean up a supply chain incident, save five things: CI and build logs, the lockfiles and manifests at the affected commits, the suspect artifacts and image digests, audit log exports, and a copy of the malicious package itself. Cleanup destroys evidence, and logs expire on their own schedule.
Why save first
Cleaning is satisfying and urgent, but a deleted cache, a rotated token or a rebuilt image removes the facts you need to scope the incident, answer customers and learn from it. NIST SP 800-61 Rev. 3, published in April 2025, frames incident response as part of cybersecurity risk management, with detection, response and recovery activities. Preserving what you found is part of doing recovery well.
What to save
| Evidence | Why | Watch for |
|---|---|---|
| Build and CI logs | Show what ran and when | Retention limits |
| Lockfiles and manifests at affected commits | Show what would install | Branch deletion |
| Suspect artifacts and image digests | Show what shipped | Registry cleanup rules |
| Audit log exports | Show who did what | GitHub shows 180 days of audit events |
| The malicious package files | Support analysis and reports | Registry removal |
| Network and DNS logs | Show outbound calls | Short default retention |
GitHub's organization audit log covers the last 180 days and can be exported as JSON or CSV, with limits on export size, so narrow your filters first.
Steps
- Name an evidence owner so exactly one person is saving things.
- Export audit logs for the window, with a margin before and after.
- Copy CI logs and run metadata for every job that touched the package.
- Download the malicious package tarball from your proxy or cache if still present, and store it read only, away from build systems. Never run it.
- Note the digest of each suspect image rather than only tags.
- Hash each saved file and record who saved it and when. This is a light chain of custody, enough for a later review.
- Only then start cleanup.
Do not delay containment
If an active attacker is using a credential, revoke it now and capture what you can in parallel. Evidence matters, but not at the price of ongoing damage. See investigating a CI/CD compromise.
Where to keep it
Store evidence in a restricted location that the compromised systems cannot write to, ideally in an account separate from the affected build tooling. Limit access to the incident team. Keep a simple index listing each item, its hash, its source system, the time it was captured and who captured it. Decide a retention period with legal, since some evidence may be needed later for contract or regulatory questions, and some may contain personal data that should not be kept forever.
Quick check
Do I need forensic grade chain of custody?
Usually a lightweight record of who saved what, when, with hashes, is enough. If legal action is likely, ask counsel early.
Is it safe to keep the malicious package?
Yes if stored as an inert file in restricted storage and never installed or executed.
Safeguard can record SBOMs and scan results over time, which helps show what a build contained. You can try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
