Managing software supply chain risk means knowing what software and suppliers you depend on, judging how much each one matters, controlling what enters your builds, asking suppliers for evidence, and planning for the day one fails. NIST's C-SCRM guidance frames it as identifying, assessing and mitigating risk at every level of the organization.
What are we actually worried about?
NIST SP 800-161 Rev. 1 describes products and services that may contain malicious functionality, are counterfeit, or are vulnerable because of poor development practices. It ties these risks to reduced visibility into how technology is developed, integrated and deployed, and into the practices a supplier uses to keep it secure. Notice the emphasis: visibility. You cannot assess what you cannot see.
For software, the risks sort into four buckets: a flaw in a component you use, a malicious or tampered component, a compromised build or delivery path, and a supplier whose own failure becomes yours.
How do you decide what matters most?
Tier your suppliers and components by what a failure would do to you. A logging library inside a payment service matters more than a charting library in an internal report. A vendor with admin access to production matters more than one that supplies stickers.
Constructed example: a company lists 180 software suppliers and 2,400 open source packages. It marks twelve suppliers as critical because they hold production access or customer data, and 150 packages as critical because they sit in internet-facing services. Those 12 and 150 get deep review, evidence requests and monitoring. The rest get automated checks.
What controls sit inside your own pipeline?
NIST's Secure Software Development Framework (SSDF), SP 800-218, is a core set of high-level practices that producers can integrate into any development lifecycle, and consumers can use as a common vocabulary with suppliers. OWASP's CICD-SEC-3 lists dependency confusion, hijacking, typosquatting and brandjacking, and recommends pulling packages through an internal proxy, preferring pre-vetted versions to latest, enabling checksum and signature verification, and registering private packages under your organization's scope. SLSA adds a way to describe build provenance: verifiable facts about where and how an artifact was produced.
What should you ask suppliers?
Ask for evidence rather than promises. Ask whether they follow a secure development framework, how they handle vulnerability reports, whether they can provide a software bill of materials, how quickly they notify customers, and what happens to your data if they are acquired or shut down. NIST SP 800-40 Rev. 4 notes some vendors can provide machine-consumable data on software composition, such as an SBOM, which can augment your own inventory.
How do you plan for failure?
Assume one critical dependency or supplier will fail. Know the substitute, the time it takes to swap, and the data you need to leave cleanly. Practice the unpleasant part: a malicious release of a package you use, found on a Tuesday. Who can freeze deployments, who checks which services pulled the version, and how fast can you pin back?
How to check or apply this
- Build the inventory: for each service, an SBOM listing direct and transitive dependencies, plus the list of external suppliers with access.
- Tier the list by blast radius and give each tier a review depth.
- Pull dependencies through an internal proxy or mirror, pin versions and commit lock files.
- Gate new dependencies: block known vulnerable or untrusted ones at pull request time, and review new maintainers or sudden ownership changes.
- Use reachability to separate vulnerabilities that your code can actually trigger from those it cannot.
- Collect supplier evidence on a calendar, and write down accepted risks with an owner and an expiry.
- Record build provenance so you can answer which commit and pipeline produced each release.
- Rehearse a malicious dependency incident once a year.
Safeguard's SBOM and dependency scanning, reachability analysis, and policies and gates cover steps one, four and five. The free in-browser scan at gold.safeguard.sh/scan checks up to 100 dependencies.
Quick check
Is an SBOM enough to manage supply chain risk?
No. It is an inventory, and a necessary start. You still need to assess components, control what enters builds, monitor for new problems and plan responses.
Where should a small team start?
Start with an inventory of dependencies for your most exposed service, pin versions and add a gate that blocks known vulnerable additions.
Sources
- NIST SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations
- NIST SP 800-218, Secure Software Development Framework
- NIST SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning
- OWASP CICD-SEC-3, Dependency Chain Abuse
- SLSA specification, About SLSA
Last reviewed: 18 October 2026.
