Do small companies need to worry about supply chain attacks?

Yes. Small companies use the same packages, updates and build tools as large ones, so the same weak links apply. Attackers often cast a wide net instead of picking a target. The good news is that small teams can lower their risk a lot with a few simple habits.

TL;DR

• Size does not protect you. What you depend on matters more.
• Several popular beliefs about supply chain attacks are only half true.
• You can size your own risk in an afternoon with three numbers.
• A short list of habits beats a long list of tools you do not use.

Definition: Supply chain risk is the chance that something you depend on, such as a package, an update or a build tool, causes harm to you. It depends on how much you depend on outside code and how well you notice changes.

What are the common myths, and what is the fact?

Here are seven beliefs we hear often. The table gives the short version. The sections after it explain.

Are we too small to be a target?

This myth is comforting and wrong. Picture someone leaving a bag of tempting goods on a busy sidewalk. They do not care who picks it up. A lookalike package works the same way: the attacker publishes it and waits. If your developer mistypes a name or trusts the wrong one, you are the victim, however small you are.

Small teams may have a harder time spotting the problem, because there is no security staff watching. They also tend to have tokens with wide access, because it is quicker. That makes a single incident hit harder.

Would our scanner catch it?

Scanners are valuable, but they work best on known problems. The SLSA project says this clearly in its introduction: security techniques for vulnerability detection and analysis of source code are essential, but not enough on their own, because code can change after scanning, whether by accident, by insider threats or by compromised accounts. A scan of last week does not describe what you install today.

Think of an airport check. It catches known bad items at a point in time. It does not prove that nobody tampered with the plane later. You need scans, plus habits that protect each step. See what is software supply chain security for the wider picture.

Is open source the risky part?

Not by itself. CISA's advisory on the SolarWinds related compromise describes a supply chain compromise of a library file in certain SolarWinds Orion products, which are commercial products. CISA's alert on XZ Utils describes malicious code in a widely used open source compression library. Both kinds of software have been used as a path.

The honest comparison is this: with open source you can see the code and the history, but you rely on volunteers. With commercial software you rely on a vendor's process and cannot inspect the code yourself. Either way, you want to know what you use and watch for changes.

Is a signed update always safe?

No. A digital signature shows who signed a file and that it was not changed afterward. It does not show that the build that created the file was clean. We go deeper in why a trusted software update can still carry an attack.

Is updating fast always safest?

Often, but not always. Fast updates are good for security fixes. But a brand new version has had the least time for others to notice a problem. A common compromise is a short waiting period for routine updates, with an exception for urgent fixes. Read about it in dependency cooldown periods.

How can a small company size its own risk?

You can do this in an afternoon. Count three things for your main product.

1. How many packages do we use in total? Include packages used by packages.
2. How many people and tokens can publish or deploy? Include old accounts.
3. How many outside build steps do we run? Count actions, plugins and scripts from others.

Write the three numbers down, and revisit them each quarter. If they grow quickly, your exposure is growing too.

Worked example

These numbers are invented to show the method. They are not from a real company.

A ten person company counts its numbers for one product.

The table gives the team a to do list that fits on a sticky note. Notice that the biggest issue is not any single package. It is that the number of packages rose by 110 without anyone looking at them.

What small habits give the most for the least effort?

NIST's Secure Software Development Framework, SP 800-218, offers a common vocabulary for secure development practices, and says that software buyers can use it to talk with suppliers. For small teams, a few of its ideas translate into plain habits:

1. Keep a list of what you use, such as an SBOM. See what an SBOM is.
2. Use lockfiles and install from them. See what a lockfile is.
3. Turn on two-factor authentication for accounts that publish or deploy. The npm documentation recommends it strongly.
4. Review new dependencies before adding them.
5. Plan what you will do on the day a package you use turns out to be bad. See what to do in the first day.

How can Safeguard help?

Safeguard is a software supply chain security platform. SBOM and dependency scanning builds the list of what you use. Reachability analysis helps separate flaws your code can reach from noise, which matters when you have no security staff to sort alerts. Policies and gates apply simple rules to pull requests. Asset discovery finds projects nobody listed, and zero-day discovery surfaces new problems.

Try the free scan at gold.safeguard.sh/scan to get the first of your three numbers.

Try it yourself

In the demo, walk through finding a vulnerability and then fixing it. Look for how much of the work is figuring out what you use before you change anything.

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

Quick check

Sources

• SLSA: About SLSA
• CISA advisory AA20-352A
• CISA alert on XZ Utils, CVE-2024-3094
• NIST SP 800-218, Secure Software Development Framework
• npm Docs: About two-factor authentication

Last reviewed: 19 October 2026.