Home / Knowledge hub / Software supply chain security
Knowledge hub
Software supply chain security
Protecting the code, tools and people that go into building your software.
What it means
Software supply chain security is the work of protecting everything that goes into your software before it runs: open source libraries, build tools, source repositories, container images, and the accounts and pipelines that assemble them. NIST treats it as managing the risk in how software is built and delivered, not just in what it does. That includes the dependencies of your dependencies, which few teams ever read.
The shift in thinking is that your product is partly code you did not write. An attacker who cannot get into your application may get into something it depends on, and arrive inside your build with trusted status. Treat your suppliers as part of your own attack surface.
Why it matters
Supply chain compromises scale. One poisoned package or hijacked build step can reach many customers at once, and each of them did nothing wrong. Your customers now ask about this in security questionnaires, and some regulations and procurement rules require a list of components. Customers are an affected party in every case, and they will ask you what happened and how you knew.
It is also hard to see. A tampered dependency passes your tests, because the tests are not checking for it. The name for this is a supply chain attack, where trust in a supplier becomes the way in. Detection often depends on someone outside noticing and telling you.
How it shows up
You meet it as vulnerable dependencies, look-alike package names, stolen publisher credentials, unpinned versions, tampered build pipelines and unsigned artefacts. The usual controls are a software bill of materials, pinned and reviewed dependencies, protected build systems and signed releases. Each of these is a place where trust is given without being checked.
Common mistakes are trusting a package because it is popular, giving the build system broad permissions, and never checking where your container images come from. Start small: know what you depend on, lock the versions, limit who can change the pipeline, and watch for new advisories.
Questions people ask
Software supply chain security, answered
Is supply chain security the same as vendor risk?
They overlap. Vendor risk looks at the companies you buy from. Supply chain security also covers open source code and your own build tools, which have no contract and no account manager.
Both belong in one picture of what you rely on.
What is the first thing a small team should do?
Make an inventory of your dependencies and lock their versions. You cannot respond to a new advisory for something you do not know you use.
Then restrict who can change the build pipeline and turn on multi-factor sign-in for those accounts.
Does an SBOM make us secure?
No. It is a list. It lets you answer quickly when a flaw is announced in a component, but it does not remove the flaw or tell you whether you can be exploited through it.
Pair it with scanning and a process for updating.
Can penetration testing find supply chain risk?
It can find the effects: an outdated library with an exploitable flaw, or a secret in a build log. It will not audit your suppliers' own practices.
A test of the running app shows which dependency flaws are really reachable.
What frameworks describe this?
NIST's Secure Software Development Framework and the SLSA framework both set out practices for protecting the build. SLSA focuses on proof of where an artefact came from.
Neither replaces a plain list of what you use and how it is updated.
Sources
Where this comes from
Related
Terms that sit next to this one
Supply chain attack
Reaching you through a library, a build tool or a vendor you trust.
SBOM
A list of every component your application includes, with versions.
Dependency confusion
Tricking a build into fetching a public package that shares a private package's name.
SLSA
A framework of levels for how trustworthy a software build and its output are.
Vendor risk management
Judging and monitoring the security of the suppliers your business relies on.
Which dependency can really be reached?
A component list shows what you use. We test the running app and report the vulnerable library only where we exploited it, with the request and response as proof. Ask us to run it on one of your applications.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.