Rethinking SCRM for Modern Software Dependencies
- Giuliana Bruni
- 5 days ago
- 2 min read
We’ve previously written about the strategic value of Software Bills of Materials (SBOMs): how they improve visibility, support due diligence, and form the backbone of secure software delivery. But a term now gaining traction in both regulatory and executive circles is Supply Chain Risk Management (SCRM). Unlike SBOMs, which describe what’s in a software artefact, SCRM demands a broader view: one that considers how software is sourced, assembled, and validated across its entire lifecycle.
According to NIST, SCRM refers to the identification, assessment and mitigation of risks across globally distributed supply chains. While this has long applied to hardware, its application to software is newer and more complex. Software is not manufactured; it is composed. And modern composition practices introduce risks that traditional supplier management processes were never designed to address.
Most software SCRM efforts still focus on generating SBOMs, running vulnerability scans, and mapping declared packages to known CVEs. These steps are important, but they rely heavily on declared metadata. When that metadata goes unverified, critical blind spots remain.
The Cisco overview highlights a key shift: attackers are increasingly targeting the software build process itself, where small changes can go unnoticed. An SBOM remains essential, but its effectiveness depends on what it’s validated against. Without a complete and up-to-date reference of open source code, down to the snippet level, there’s no way to reliably detect tampering, undeclared components, or reused logic. SCRM today depends not just on building inventories, but on verifying them against everything that’s published, reused or repackaged.
This shift reveals that SCRM, as applied to software, must evolve to go beyond inventory and towards inspection. AI-assisted development makes it easier to introduce unattributed code, developers rarely review upstream dependency trees in depth. Provenance is often inferred, not established. And regulatory requirements, such as those outlined in the EU’s Cyber Resilience Act and U.S. Executive Orders, are beginning to reflect this reality.
To remain effective, software SCRM must be treated as a verification practice. It must include the ability to analyse artefacts post-build, trace origins beyond declared metadata, and surface evidence of policy violations at the code level.
This isn’t a call to replace SBOMs, they remain a vital part of modern software supply chain management. Their usefulness depends on how they’re generated and what they’re verified against. An SBOM built without inspecting the actual code may miss what’s been copied, altered, or omitted. SCRM treats the SBOM not as the end product, but as a starting point. With the right detection engine and a complete open source reference organisations can enrich their SBOMs, uncover hidden components, and build an auditable trail of what truly exists in their software.
Ready to validate your code against the largest open source knowledge base available?
