How can a small team protect against supply chain attacks?

A small team can protect against supply chain attacks with five low cost habits: know what you use, lock exact versions, turn on two-factor authentication, pin your build tools, and review changes before they merge. You can set all five up in one working week without a security specialist.

TL;DR

• Day 1: make a list of what your software uses.
• Day 2: lock versions so installs are repeatable.
• Day 3: secure the accounts that can publish or deploy.
• Day 4: pin the helper tools in your build pipeline.
• Day 5: add a check that runs before code is merged.

Definition: A supply chain attack hides bad code in something you depend on, such as a package, an update or a build tool. Protecting against it means making those dependencies visible, repeatable and checked, so a surprise change gets noticed instead of silently accepted.

Why can a small team still do this?

Big companies have whole teams for this. You probably do not. But attackers go after small teams for the same reason burglars try unlocked cars: it is quick. The good news is that the biggest improvements are boring settings, not expensive tools.

Before you start, set one rule for yourself. Aim for steady progress, not perfection. If you do two of the five days this month, you are safer than last month.

What is the five day plan?

Here is the plan as a table, then the steps.

Day 1: What do we use?

Start by building a list of every package your software uses, including the packages those packages use. A software bill of materials (SBOM) is exactly this list, like the ingredient label on a food package. Many package managers can already print one, and a scanner can build it for you. Save it where the team can find it.

Why first? Because every later step, and every future news story, begins with the question "do we use this?" Our post on direct versus transitive dependencies explains why the second layer matters.

Day 2: Are our installs repeatable?

A lockfile records the exact version of every package you installed. The npm documentation says the lockfile describes the exact tree that was generated, so later installs can produce identical trees regardless of newer releases, and it is meant to be committed to your repository.

Then make your build use it. The npm documentation says that npm ci installs from the lockfile, never writes to it, and exits with an error if the lockfile and package.json do not match. That is what you want in your pipeline: no surprises.

For Python, pip has a hash checking mode. When you add a hash for each package to your requirements file and use it, pip checks the downloaded files against those hashes, which the documentation says protects against remote tampering. Note that the documentation calls it all or nothing: adding a hash to one requirement turns the mode on for all of them.

For more on this, read what is dependency pinning.

Day 3: Who can publish or deploy?

List every account that can publish a package, deploy to production or change your build settings. Turn on two-factor authentication on each one. npm's documentation says publishing requires either two-factor authentication on the account or a granular token with bypass enabled, so check that none of your tokens skip the second step without a good reason.

Then remove people who no longer need access. Old accounts are a favorite target because nobody is watching them.

Day 4: Can our build tools change under us?

Your pipeline probably uses shared steps from other people, such as a ready-made action that checks out code or uploads a file. GitHub's hardening guide says to pin actions to a full-length commit identifier, because an attacker would then need to produce a collision in the identifier to slip in a backdoor. It also says to verify the identifier comes from the action's own repository and not a copy. If you must use a tag, trust only creators you have reason to trust. Our GitHub Actions hardening checklist has more.

Also consider turning off install scripts where you can. The npm configuration documentation says that when ignore-scripts is true, npm does not run scripts specified in package files. Some packages need their scripts, so test this on a branch first. See how to audit npm postinstall scripts safely.

Day 5: Who checks changes before they merge?

A gate is an automatic check that runs on a pull request, which is a proposed code change waiting for review. Set one up so that a change adding or updating a dependency is flagged. Even a simple rule helps: any new package needs a second person to look at its name and publisher.

Also consider a short delay for brand new versions. Some bad releases are caught quickly once people notice them. Our post on dependency cooldown periods explains the trade off.

What does this look like in practice?

These numbers are invented for illustration. They are not from a real team.

A five person team runs one web app with 480 packages in its dependency tree.

• Before: installs use whatever is newest, 7 accounts can publish or deploy, 3 of them have no two-factor authentication, 9 pipeline steps use floating tags, and nobody reviews new packages.
• After the week: a list of 480 packages is saved, installs use the lockfile, all 7 accounts use two-factor authentication (and 2 stale accounts are removed, leaving 5), all 9 steps are pinned, and new packages need a second look.

Nothing here prevents every attack. But when a bad version is published, the team's exposure shrinks: the lockfile means their next build does not silently pull it, the pinned steps mean a changed tool is not loaded, and the list means they can answer "are we affected?" in minutes.

What should you not skip?

Two things get skipped most often. The first is writing down who owns each step, because a habit nobody owns fades by next quarter. The second is a monthly 30 minute review: look at new packages added, accounts with access, and any warnings. Put it in the calendar.

How can Safeguard help?

Safeguard is a software supply chain security platform. SBOM and dependency scanning covers Day 1 and keeps the list current. Policies and gates cover Day 5, checking pull requests against rules you set. Reachability analysis helps you sort real risk from noise. Asset discovery helps find projects you forgot about. Autonomous remediation with fix pull requests is available but off by default, with every category set to Manual.

The Safeguard CLI, which installs with a curl or PowerShell command, can scan from your terminal or in CI, and it can also write code, so a person can ask it for a fix and review the change. Try the free scan at gold.safeguard.sh/scan to get your first list today.

Try it yourself

In the demo, watch how a pull request is checked against a rule before it merges. Click through and look for the moment the gate blocks or allows a change.

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

Quick check

Sources

• npm Docs: package-lock.json
• npm Docs: npm ci
• npm Docs: config (ignore-scripts)
• npm Docs: About two-factor authentication
• pip documentation: Secure installs
• GitHub Docs: Security hardening for GitHub Actions

Last reviewed: 19 October 2026.