What is software supply chain security?

What is the software supply chain?

The software supply chain is everyone and everything involved in getting software from a developer's editor to production. Think of it in four stages, each with its own risks.

Stage	What is in it	What goes wrong
Source	Your code, repositories and developer accounts	Stolen credentials, malicious commits, leaked secrets
Dependencies	Open source packages, base images, third-party code	Vulnerable versions, malicious releases, typosquatting
Build	CI runners, GitHub Actions, build tools, caches	Compromised actions, poisoned caches, stolen pipeline secrets
Release	Artifacts, registries, deployments, updates	Swapped artifacts, tampered updates, no record of what shipped

Why it matters now

Most of what you ship, you did not write. A modern application is mostly open source, and each direct dependency brings others that nobody on your team chose. Those packages run with the same access as your own code, and their install scripts can run inside your CI pipeline, next to your secrets.

The record of the last few years shows how that gets used:

• SolarWinds: the build was compromised, so a clean source tree produced a poisoned release.
• Log4Shell: a flaw in one logging library reached products that never knew they used it.
• xz utils: a trusted contributor slipped a backdoor into a project found in Linux distributions.
• tj-actions: a hijacked GitHub Action ran attacker code in the pipelines that used it, with secrets in reach.
• Shai-Hulud: a worm spread through npm packages, stealing tokens from the machines and CI jobs that installed them.

For how these attacks work step by step, see what is a supply chain attack.

How software supply chain security works

A program needs four things. Everything else is detail.

1. Know what you ship. Keep an accurate SBOM for every release, from the build that produced it, including transitive dependencies.
2. Control what gets in. Pin versions, use a lockfile, limit where builds can fetch from and vet new packages.
3. Protect the build. Isolate jobs, limit secrets, pin actions by commit and restrict outbound traffic, so that a compromised package cannot send your tokens anywhere. See runner security and why supply chain security belongs in CI.
4. Keep watching what shipped. New vulnerabilities affect software already in production. Monitor it, trace which releases are affected and follow each fix through to a new release.

For the detailed checklist, see software supply chain security best practices.

Frameworks and regulations

Name	What it is	Best for
SLSA	Levels for build integrity and provenance	Hardening how software is built
NIST SSDF	Secure development practices, SP 800-218	A full secure development program
NIST SP 800-161	Cybersecurity supply chain risk management	Organization-wide risk management
OpenSSF Scorecard	Automated checks of open source project health	Vetting dependencies
Cyber Resilience Act	EU law for products with digital elements	Selling in the EU. See what is the CRA

What tools are involved?

No single product covers all of this. The category breaks down into SCA tools, SBOM tools, CI/CD and runner security, package firewalls, application security posture management and binary analysis. For what each does and who sells it, see software supply chain security tools compared and what they cost.

Where to start

1. Generate an SBOM for your most important product from its CI build, and read it.
2. Turn on dependency vulnerability alerts, and decide who owns them.
3. Pin your GitHub Actions by commit and review the secrets your workflows can reach.
4. Restrict outbound traffic from your builds to the hosts they actually need.
5. Set up monitoring for what you shipped, not just what you are building.

How CRACI approaches it

CRACI starts at the build, because the build is the one place that sees everything. It replaces your GitHub-hosted runners with faster, lower-cost ones that record every package each job fetches, at every depth of the tree and including packages restored from CI caches. The egress policy blocks connections your build does not need, so it protects you even against an attack nobody has seen before. CRACI then keeps checking what shipped against new vulnerabilities and follows each one from triage to a fixed release. See software supply chain security with CRACI.

Software supply chain security: frequently asked questions

What is software supply chain security?

It is the practice of protecting everything that goes into your software before it reaches users: open source dependencies, build systems, pipeline tools and releases.

What is an example of a software supply chain attack?

In the SolarWinds attack, the build was compromised, so customers received a poisoned update from a trusted vendor. In the Shai-Hulud attacks, a worm spread through npm packages and stole tokens from the machines that installed them.

What is the difference between supply chain security and application security?

Application security looks at flaws in the code you write. Supply chain security looks at what you did not write and how your software gets built and released. A program needs both.

Is an SBOM enough for supply chain security?

No. An SBOM tells you what you ship, which is the foundation. You also need to control what gets in, protect the build and keep monitoring what you released.

What are the main frameworks?

SLSA for build integrity, the NIST SSDF for secure development practices and NIST SP 800-161 for supply chain risk management. In the EU, the Cyber Resilience Act sets legal requirements for products with digital elements.

Who owns software supply chain security?

It usually sits with application or product security, working with platform and DevOps teams who run the pipelines. Fixes then go to the engineering teams that own each service.