When a software vendor ships a malicious update, on day one pause further updates, find which machines already took it, isolate the ones that did, ask the vendor for the version, time window and indicators, and rotate credentials the software could reach. Do not wait for a full vendor report before containing.
What is different from a bad package
An update from a vendor usually arrives through a trusted channel, often signed, and runs with high access on many machines. A valid signature does not prove the contents are safe, because the build or signing process itself may have been compromised. SLSA lists stolen signing keys and compromised build platforms among the build threats.
Day one plan
- Pause. Stop automatic rollout of that product through your management tools. Hold the update in any internal catalog.
- Scope. List devices and servers by product version. Mark those that updated in the vendor's window.
- Isolate. Take affected machines off sensitive networks. Do not reimage yet, so you can examine them.
- Ask the vendor. Request: affected versions, time window, what the code did, indicators, whether signing keys were exposed, and the clean version.
- Check indicators. Search endpoint and network logs for the vendor's indicators and for odd outbound traffic from that product.
- Rotate. Rotate credentials stored on or reachable from affected machines, powerful ones first.
- Plan the clean version. Stage it on a few machines first. Do not apply an unreviewed fix to everything.
- Record. Note times and decisions for the timeline.
Questions for the vendor
| Question | Why |
|---|---|
| Which versions and which dates? | Scopes your search |
| Was the signing key exposed? | Decides whether a signed file is trusted |
| What did the code do? | Decides rotation scope |
| What are the indicators? | Lets you hunt |
| When is the clean version ready? | Plans recovery |
If the vendor is slow, say so in your log and proceed on the cautious assumption.
Plan the staged return
When the vendor publishes a clean build, do not push it to everyone at once. Apply it to a small ring of machines, confirm that the indicators are gone and the product works, then widen in steps. Keep the pause on automatic rollout until you finish. Ask the vendor to confirm in writing what changed in their build and signing process, and keep that answer with your incident record.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how an image's components are listed, which is the sort of inventory you need to see which images embed an affected product.
Quick check
Should I turn off all automatic updates permanently?
Usually no. Pause during the incident, then consider staged rollouts. See the related guidance on automatic updates.
Is a signed update safe?
Not necessarily. A signature shows who signed, and signing keys or builds can be compromised.
Safeguard's container and dependency scanning and SBOM generation can help show which images and projects include an affected component. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
