Software supply chain risk management

Risk management vs security

Software supply chain security is the set of technical controls: SBOMs, pinned dependencies, restricted builds. Risk management sits above that. It asks which suppliers and components your business depends on, what happens if one fails, and whether you have spent your effort in the right place.

What are the risks?

Risk	Example	Main control
Vulnerable components	A flaw in a widely used library	SBOMs and continuous monitoring
Malicious components	A hijacked package, or typosquatting	Vetting, delayed adoption, outbound traffic limits
Abandoned projects	A dependency with a single maintainer who has moved on	Health checks and a replacement plan
License risk	A copyleft component in a proprietary product	License policy
Build compromise	A hijacked GitHub Action reaches your secrets	Pinning, isolation, least privilege
Supplier risk	A vendor's product or update is compromised	Assessment, contracts, SBOMs from suppliers
Regulatory risk	A customer or law requires evidence you cannot produce	Records kept per release

A six-step process

1. Build the inventory. List the products you make and the software you buy. For what you build, keep an SBOM per release. You cannot assess what you cannot see.
2. Rank by what matters. A library in your payment service is not the same as one in an internal tool. Rate products by exposure, data and business impact.
3. Assess the risks. Look at vulnerabilities, project health, licenses and how each supplier handles security. Do it deeply for the top tier and lightly for everything else.
4. Treat them. For each risk, decide to fix, replace, add a control or accept. An accepted risk needs an owner and a review date.
5. Monitor continuously. Risk changes without any change on your side, for example when an advisory is published or a maintainer leaves. Annual reviews miss this.
6. Report. Give leadership a short view: top risks, exposure over time and what was accepted. Customers and auditors will ask for the detail.

Assessing suppliers

Questionnaires alone tell you what a supplier says. Ask for things that show what they do:

• An SBOM for the product, with a stated format and a way to get updates
• How they handle vulnerabilities, and how fast they tell customers
• A security contact and a disclosure policy
• How they build releases, and whether they can show where a release came from
• How long a version receives security fixes
• Certifications and audit reports that cover the product you are buying

Build the expectations into contracts. It is much easier to require an SBOM or a notification time at signing than after an incident.

Frameworks to follow

• NIST SP 800-161 is the main reference for cybersecurity supply chain risk management, or C-SCRM. It works at every level of an organization and builds supply chain risk into wider risk management.
• The NIST SSDF covers secure development practices, which makes it a good basis for what you ask of suppliers, and of yourself.
• SLSA gives you a shared language for how trustworthy a build is.
• ISO/IEC 27001:2022 includes controls for ICT supply chain security (Annex A 5.21) and technical vulnerabilities (8.8). It does not require an SBOM, but SBOMs make good evidence for those controls.
• NIS2 names supply chain security as a required measure for entities in scope, in Article 21(2)(d).

How to measure it

Pick a few measures that lead to decisions:

• Share of products with an SBOM for the current release
• Time to answer "are we affected?" for a new critical vulnerability
• Exposure window: how long a vulnerable version was in production
• Share of top-tier suppliers assessed in the last year
• Number of accepted risks past their review date

Where CRACI helps

CRACI gives a risk program the data it usually lacks for software you build. It records what each GitHub Actions build pulled in, including declared licenses, into SBOMs you can keep per release and share in CycloneDX or SPDX. It monitors what shipped, shows which builds contained a vulnerable package so you can see the period you were affected, and can enforce license policy and block builds with policy gates. See software supply chain security with CRACI and how the tools compare.

Supplier assessment and your risk register stay with your governance tools and your team.

Software supply chain risk management: frequently asked questions

What is software supply chain risk management?

It is how an organization identifies, assesses and reduces the risk from software it did not write, including open source packages, commercial products, SaaS suppliers and build tools.

What is C-SCRM?

C-SCRM stands for cybersecurity supply chain risk management, the term NIST uses. NIST SP 800-161 is its main guidance, covering how to find, evaluate and reduce cyber risks across the supply chain at every level of an organization.

What are the biggest software supply chain risks?

Vulnerable and malicious open source components, compromised build systems and CI tools, abandoned projects, license problems and suppliers who get breached.

How is it different from third-party risk management?

Third-party risk management usually looks at vendors as companies. Software supply chain risk management goes down to the components and build processes, including open source projects with no vendor behind them.

Who is responsible for it?

Typically security or risk leadership sets the program, product security owns what the company builds, and procurement or vendor management owns what it buys. Engineering teams fix what is found.