For regulated industries, software supply chain security means knowing every component and supplier behind your systems, checking the integrity of what you install, and keeping evidence a regulator can read. Look for tools that produce component inventories, flag vulnerable or malicious packages, and record decisions. No tool replaces your own accountability.
What do regulators actually say about suppliers?
Different sectors use different words, and they converge.
NIST SP 800-161 Rev. 1 addresses the risk of products and services that may contain malicious functionality, be counterfeit, or be vulnerable through poor development practices, arising from reduced visibility into how technology is built and deployed. It gives guidance on strategy, policy, plans and risk assessments for products and services.
DORA's Article 28, for EU financial entities, says they remain fully responsible for compliance when they use ICT third-party services. It requires a register of information on all contractual arrangements with ICT providers, distinguishing arrangements that support critical or important functions, and regular reporting to competent authorities.
NERC CIP-013-2, for the North American bulk electric system, requires documented supply chain plans covering vendor incident notification, vulnerability disclosure, verification of software integrity and authenticity, and control of vendor remote access.
PCI's glossary defines third-party service providers as those offering shared services such as hosting and SaaS, which is a reminder that providers sit inside your scope.
The shared message: you cannot outsource accountability, and you need a list.
Which criteria should a buyer test?
Use these when comparing categories of tools in a trial. We do not rank vendors here.
Inventory depth. Does it cover direct and transitive dependencies, containers and build tooling? Ask for a sample bill of materials in a standard format. CycloneDX, now an ECMA standard (ECMA-424), and SPDX are the common ones.
Risk signal. Does it flag known vulnerabilities and malicious packages, and does it say which findings are reachable from your code? Reachability analysis reduces noise but is an input, not a verdict.
Integrity checks. Can it verify signatures or hashes on what enters the build, and show provenance where the ecosystem offers it?
Policy and gates. Can you set rules that block a build or a pull request, and record exceptions with an approver and an expiry?
Evidence. Can you export records an auditor can read, with dates and decisions? Ask how long they are kept.
Deployment fit. Regulated teams often need private deployment or controls over where code goes. Ask what leaves your network and whether AI features can be turned off.
Supplier coverage. Can you request and review bills of materials from your own vendors?
What are the honest limits?
- A bill of materials is a list, and it is only as accurate as the process that produced it.
- Tools cannot see components compiled in from outside the package manager unless they scan binaries or build output.
- Evidence supports your compliance program. No tool certifies you against a framework, and any vendor that says otherwise is overclaiming.
- Supplier questionnaires tell you what a vendor says, not what it does.
How does Safeguard fit?
Safeguard offers reachability analysis, a free in-browser scan of up to 100 dependencies through the Gold registry at gold.safeguard.sh/scan, Full AI, Zero AI or bring-your-own-model modes, and compliance automation. Test it against the criteria above like any other tool, using your own repositories.
What to do
- Map which regulations reach your suppliers and which suppliers touch critical functions.
- Build the supplier register first, even if it starts as a spreadsheet.
- Require a component list in a standard format from each important vendor.
- Write acceptance criteria for tools from the checklist above and run a time-boxed trial.
- Add integrity checks and gates to the build, with logged exceptions.
- Test one real scenario end to end: a disclosed vulnerability, where do we run it, who fixes it, how do we prove it.
- Review the register and the evidence on a fixed schedule.
Quick check
Does an SBOM satisfy supply chain regulation?
No single document does. An SBOM supports inventory and vulnerability response, which regulations such as DORA and CIP-013 expect, alongside contracts, verification and reporting.
Who is responsible when a supplier is compromised?
Under DORA Article 28, the financial entity remains fully responsible for its obligations when it uses ICT third-party services. Treat that as the working assumption in other sectors too.
Sources
- NIST, SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices
- DORA, Article 28 General principles
- NERC, CIP-013-2
- PCI SSC, Glossary
- CycloneDX, Specification Overview
- SPDX, Specifications
- CISA, Software Bill of Materials
Last reviewed: 18 October 2026.
