How do I know if a supply chain attack affects my software?

To know if a supply chain attack affects you, answer four questions: do we use the package, did we use the bad version, where did that version run, and what could it reach? You need an up to date list of your software parts to answer the first two quickly.

TL;DR

• Do not panic and do not ignore the story. Check.
• Four questions: package, version, location, reach.
• The list of what you use is the thing that makes this take minutes instead of days.
• Write down what you find, even if the answer is "we are not affected."

Definition: Exposure is the overlap between what an attack touched and what you run. If the bad package version never entered your builds, your exposure is zero. If it did, your exposure depends on where it ran and what secrets or systems that place could reach.

Why does this feel so hard in the moment?

A news story says a popular package was compromised. Your chat fills up. Someone asks, "Are we affected?" and nobody knows how to find out. People start searching code by hand, and each person looks in a different place.

CISA's guidance after Log4Shell describes the same trouble. It says that early efforts may have been scoped to a limited number of assets, and that for long term mitigation you should account for the library in all assets, including internally developed software and technology that is not facing the internet. It also notes that you may lack insight into some applications, such as software as a service and other cloud resources. In short: the places you forgot are the places that bite you.

What are the four questions, step by step?

1. Do we use the package at all? Search your list of software parts, called a software bill of materials (SBOM), for the package name. Check direct and indirect use. An indirect dependency is a package you never chose, pulled in by one you did.
2. Which version did we use, and when? Bad releases usually exist for a window of time. Compare your version and the date you installed it with the dates in the alert.
3. Where did it run? Think of each stage: developer laptops, test machines, build servers, containers, production. A package can be harmless in one place and dangerous in another.
4. What could it reach? If the code ran on a build server, what passwords, keys or tokens did that server hold? That is the real size of the problem.

Where do I look for the answers?

Different places hold different clues. This table shows the common ones.

The npm documentation says a lockfile describes the exact tree that was generated, which is why it is the first place to look. But a lockfile only shows what you intended. Build logs show what really happened.

What does a worked example look like?

These numbers and names are invented for illustration. They are not from a real company.

On Tuesday, an alert says version 3.2.1 of a fictional package called "fastparse" was malicious and was live between 09:00 and 15:00 on Monday.

• The team searches its SBOMs. Fastparse appears in 4 of 15 projects, all as an indirect dependency.
• Lockfiles for all 4 pin version 3.2.0, which is the clean one. Good sign, but the team does not stop there.
• Build logs show that 1 of the 4 projects had a build at 11:20 on Monday that used no lockfile, because an old script ran a plain install. That build pulled version 3.2.1.
• That build ran on a server that held a token for the company's test database.

Result: 3 projects are not affected. 1 project is exposed, and its build server's token needs to be replaced. The team also finds and fixes the old script. Total time with a searchable list: about 40 minutes. Without it, they would still be grepping on Thursday.

Notice what saved them: the lockfile for 3 projects, and the log check for the 4th. Checking only one source would have given the wrong answer.

What if the answer is "we are exposed"?

Switch from checking to responding. CISA's alert on XZ Utils is a good model of what an official recommendation looks like: it advised downgrading to an uncompromised version, hunting for malicious activity and reporting positive findings. The same shape works for almost any attack:

1. Move to a known clean version and block the bad one.
2. Replace any secrets the affected machines could see.
3. Look for unusual behavior in the time window.
4. Tell the people who need to know.

Our post on malicious package quarantine procedures covers this in more depth.

How do I get ready before the next story?

You cannot predict the next attack, but you can prepare for the question. Three habits make the biggest difference:

• Keep SBOMs for every release and store them somewhere searchable. See what an SBOM is and why it matters.
• Commit lockfiles and install from them in your pipeline.
• Keep a list of every project, including old ones. Old projects hold old versions.

The SLSA project points out why this matters in a wider sense: risk exists at each link from source to build to distribution, so you need confidence that the code you run is the code you scanned.

How can Safeguard help?

Safeguard is a software supply chain security platform. SBOM and dependency scanning keeps a searchable list of what each project uses, including indirect packages. Asset discovery helps find projects and services that were not on anyone's list. Zero-day discovery surfaces new problems, and reachability analysis helps you judge which ones your code can actually trigger. Policies and gates can then block a bad version from merging.

You can try the free scan at gold.safeguard.sh/scan. The Safeguard CLI, installed with a curl or PowerShell command, lets you search and run scans from a terminal.

Try it yourself

In the demo, look at how a search over past runs finds where a package appeared. Try it with a package name and notice what the results tell you about version and location.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• CISA: Apache Log4j vulnerability guidance
• CISA alert on XZ Utils, CVE-2024-3094
• npm Docs: package-lock.json
• SLSA: About SLSA

Last reviewed: 19 October 2026.