Software supply chain security is the practice of protecting everything your software is built from and delivered through: open source packages, build tools, container images and vendors. The aim is to know what you depend on, spot tampering or known flaws early, and fix problems before customers feel them.
Key takeaways
- Modern software is mostly other people's code, so your risk includes theirs.
- The core questions are what is in our software, is any of it dangerous, and who can change it.
- The basics are an inventory (an SBOM), version locking, vetted dependencies and a protected build.
- Regulators are starting to ask for it, for example under the EU Cyber Resilience Act.
Why does the software supply chain matter?
Think of a restaurant. Even a great chef can make people ill if a supplier delivers bad ingredients. Software works the same way: your team writes a small part, and the rest comes from libraries, frameworks, base images and services written by others.
If one of those parts is flawed or tampered with, your product inherits the problem. NIST's glossary defines a supply chain attack as "an incident where an adversary exploits vulnerabilities in the product or service supply network of the intended target."
What does software supply chain security include?
Four areas, each with a plain question behind it:
- Dependencies: what open source code do we use, and is it known to be vulnerable or malicious?
- Build and delivery: can someone alter our software between the developer and the customer?
- Vendors and tools: which suppliers can reach our systems or code?
- Evidence: can we prove to a customer or auditor what is in each release?
What is an SBOM, in one sentence?
An SBOM is an ingredient list for software. CISA calls it "a nested inventory, a list of ingredients that make up software components." Our guide on how to create an SBOM step by step covers the how.
What should a manager ask the engineering team?
- Can you list every open source component in our main product today?
- How fast could you tell me whether a newly announced vulnerability affects us?
- Who approves a new dependency?
- Do we produce an SBOM for each release?
- If a package we use turned malicious, how would we find out?
If the answers are vague, that is the finding. Engineers can start with the free dependency scan at gold.safeguard.sh/scan, which needs no login and keeps the file on their machine.
How is this different from regular application security?
Application security looks at the code you wrote. Supply chain security looks at the code you bring in and the path it takes to production. You need both, because a perfect first party codebase can still ship a bad library.
Why are regulators interested?
Because incidents spread through shared components. The EU Cyber Resilience Act, for one, requires manufacturers to keep an SBOM and to report actively exploited vulnerabilities, with reporting applying from 11 September 2026. See what software companies must do under the CRA.
Frequently asked questions
What is the difference between supply chain security and supply chain risk management?
Security is the set of technical controls. Risk management also covers vendor selection, contracts and business decisions. Most programs need both.
Is this only about open source?
No. It also covers commercial components, build systems, container images and the vendors who touch your code or data.
Where should a small team start?
Start with an inventory of dependencies, committed lockfiles and a rule that new dependencies get reviewed. These are cheap and cover a lot.
Does a tool solve this?
Tools automate inventory and monitoring. People still own the decisions about what to trust and how fast to respond.
Sources
- NIST CSRC glossary: supply chain attack
- CISA: Software Bill of Materials
- European Commission: Cyber Resilience Act
- Safeguard Gold dependency scan
Last reviewed: 19 October 2026.
