In the first day after a malicious package is found, do five things in order: stop new installs of it, find where it ran, replace any secrets those places could see, move to a clean version, and write down a timeline. Containment comes first. Investigation continues after the immediate risk is reduced.
TL;DR
- Do not wait for perfect information. Block, then investigate.
- Find where the package ran, not just where it is listed.
- Replace secrets that the affected machines could read.
- Go back to a known clean version.
- Keep notes as you go. You will need them later.
Definition: A malicious package is a software package that contains code written to do harm, such as stealing passwords or opening a back door. Containment means limiting the damage right now, before you have the full story.
Why does the first day matter so much?
The bad code may already be running. Every hour it stays in your builds, it may collect more. Attackers who plant code in a package often want secrets, such as login tokens and keys, because those open the next door.
CISA's alert on the XZ Utils compromise shows the shape of official advice. For versions 5.6.0 and 5.6.1, it recommended downgrading to an uncompromised version such as 5.4.6, hunting for malicious activity and reporting positive findings. That is three jobs: undo, look, tell. Your own first day follows the same shape with a few extra steps for your situation.
CISA also warned in the SolarWinds advisory that removing a patient attacker from compromised environments would be highly complex. A one day plan will not finish every case. Its job is to stop the bleeding and put you on a clear path.
What is the plan, hour by hour?
The timeline below is a guide, not a rule. Adjust it to your team's size.
| When | What to do | Who |
|---|---|---|
| Hour 0 to 1 | Confirm the report, name one person in charge, stop new installs | Incident lead and a developer |
| Hour 1 to 3 | Scope: which projects, which versions, which dates | Developers |
| Hour 3 to 5 | Find where it ran and what those places could see | Developers and IT |
| Hour 5 to 8 | Replace secrets and move to a clean version | Developers and IT |
| Hour 8 to 12 | Look for signs of what the code did | Whoever owns logs |
| Hour 12 to 24 | Write the timeline, tell stakeholders, plan follow ups | Incident lead |
Step 1: Confirm and contain (hour 0 to 1)
Read the original report yourself, from a trusted source, instead of relying on a chat message. Pick one person to lead, so decisions do not stall. Then block the bad version: pin to the last known good one, or add a rule that rejects the bad version in your pipeline. Pause deployments of affected projects if you can.
Step 2: Scope (hour 1 to 3)
Search your list of software parts, called a software bill of materials (SBOM), for the package. Check direct use and indirect use, meaning packages pulled in by packages you chose. CISA's Log4j guidance says to account for the library in all assets, including internally developed software and technology that is not facing the internet. Apply that thinking here: old projects and forgotten services count. See how to know if a supply chain attack affects you.
Step 3: Find where it ran (hour 3 to 5)
A package listed in a file is not the same as a package that ran. Look at build logs and installation records for the time window the bad version was live. Make a short list: laptops, build servers, test environments, production. For each, note what it could see: tokens, keys, databases, cloud accounts.
Step 4: Replace secrets and clean up (hour 5 to 8)
Treat every secret on an affected machine as possibly read. A secret is any password, token, key or certificate. Replace them. Start with the ones that open the most doors, such as cloud and deployment credentials. Then rebuild affected projects from a clean version and redeploy.
Step 5: Look for traces (hour 8 to 12)
Check whether the code did anything unusual. Look for outbound network calls you do not recognize, new accounts or keys created during the window, and unexpected changes to files or build settings. If the package targets a specific kind of secret, search for use of that secret from places you do not expect.
Step 6: Write it down (hour 12 to 24)
Record the timeline: when the bad version was published, when you learned, when you blocked it, when you replaced secrets, and what you found. If customers or partners might be affected, tell them what you know and what you do not yet know. Then plan the follow ups. Our post on malicious package quarantine procedures goes deeper.
What does this look like with numbers?
All numbers below are invented for illustration. They are not from a real incident.
A team of 8 learns at 09:00 that a package called "logwrap" had a malicious version live from 06:00 to 10:30 that morning.
- 09:20: the lead pins the previous version in the shared build settings.
- 10:00: an SBOM search finds logwrap in 6 of 22 projects.
- 11:00: build logs show 2 of the 6 projects built during the window. Both built on the same shared server.
- 11:30: the shared server held 5 secrets: a cloud key, a deploy token, a registry token and two test passwords.
- 13:00: all 5 are replaced. The 2 projects are rebuilt from the clean version.
- 15:00: network logs show one unknown outbound connection from the shared server at 07:45.
- 17:00: a written timeline goes to the leadership group. A follow up is added: stop sharing one build server across projects.
Exposure: 2 of 22 projects, 1 server, 5 secrets. Because the team knew where to look, it took about eight hours of work, not days.
What mistakes should you avoid?
- Skipping the secrets step because "nothing looks wrong." Quiet does not mean safe.
- Updating to the newest version as the fix. The newest version might be the bad one. Go to a version you know is clean.
- Deleting evidence. Keep logs and copies of the bad package for investigators, in a safe place.
- Going silent. People nearby need to know, even if the news is "we are checking."
How can Safeguard help?
Safeguard is a software supply chain security platform. SBOM and dependency scanning supports the scoping step by showing which projects use a package, including indirect use. Asset discovery helps find projects you did not list. Policies and gates can block a bad version from entering new changes while you clean up, and reachability analysis helps with the follow up work on ordinary flaws. Autonomous remediation with fix pull requests is available, off by default and set to Manual in every category, so you decide what is applied.
The Safeguard CLI can also write code, so a fix can be drafted for review. Start with the free scan at gold.safeguard.sh/scan.
Try it yourself
In the demo, compare the remediation options for a problem package and look at what each choice trades off. Click through and note which one fits a fast first day response.
Click through it at your own pace, or open it full screen.
Quick check
Should I delete the malicious package from my machine right away?
Block it first, then keep a copy in a safe place for investigation before cleaning up. Deleting everything at once can erase the evidence you need to learn what it did.
Do I really need to replace secrets if I see no harm?
Yes, if the code ran somewhere those secrets were available. Replacing a secret is cheap compared with finding out later that it leaked.
Who should I tell?
Your own leadership, anyone whose data might be touched, and the registry or maintainers if the report is new. CISA's XZ alert asked people to report positive findings to CISA.
Sources
- CISA alert on XZ Utils, CVE-2024-3094
- CISA advisory AA20-352A
- CISA: Apache Log4j vulnerability guidance
Last reviewed: 19 October 2026.
