The severity and frequency of software supply chain attacks have increased significantly. How should cybersecurity and enterprise risk management teams react to these new threats? Many are establishing or maturing cyber supply chain risk management (C-SCRM) programs.
C-SCRM is like all risk management in that it is fundamentally about information – because you cannot manage what you do not know. Motivated by recent incidents (e.g., Solarwinds or Log4j or by pending regulations (e.g., if you are a software supplier for the US Government), organizations are proactively assessing their C-SCRM practices to better manage their own supply chain risk. This seems obvious on its face, but software supply chains can be complex and many organizations do not have a robust understanding them.
When building a C-SCRM program, there are several frameworks that supply chain security practitioners can reference. At the behest of President Biden’s executive order (EO) issued last May, the National Institute of Standards and Technology (NIST) released on 4 Feb their Secure Software Development Framework (SSDF). The SSDF spells out minimum recommendations for US federal agencies to follow as they acquire software or a product containing software. Google has released the Supply chain Levels for Software Artifact (SLSA) framework for ensuring software supply chain and build integrity. And finally, OWASP has the Software Component Verification Standard (SCVS) which identifies activities, controls, and best practices, which can help in identifying and reducing risk in a software supply chain.
Which best practice framework should an organization use? The NIST SSDF tends to focus on the “what” and Google SLSA focuses on the “how.” The OWASP SCVS is designed to be implemented incrementally, and to allow organizations to phase in controls at different levels over time.
Honestly, I don’t think it matters which framework is used (unless, as a software supplier to the US government you will need to abide by the NIST SSDF in the future). Whether an organization uses one framework or a combination, all of them include requirements/guidance to test software for vulnerabilities and to analyze software’s composition. Requirements we can certainly support with the Fortify AppSec portfolio.
You may also wonder what Micro Focus is doing to mitigate our software supply chain risks. A new article, Securing your supply chain with value stream management, by Micro Focus Chief Technologist Yaniv Sayers outlines how our use of a Secure Development Lifecycle (SDL), Value Stream Management (VSM) and Digital Factory enables us to proactively detect, quickly evaluate and remediate vulnerabilities. We use a combination of best practices from various frameworks as opposed to strict compliance to a single one.
Are you establishing or maturing your C-SCRM program? Do you produce software for the US federal government and will they need to abide by the NIST SSDF? Learn more about securing the software supply chain:
- Web page: Securing the Software Supply chain
- Fortify Unplugged: Secure your software supply chain with Hacker Level Insights with Fortify
- Video: Enabling a Secure Software Supply Chain for Business Resiliency
- TechBeacon Article: The EO and SBOMs: What your security team can do to prepare
- Blog: How secure is your software supply chain?
- Fireside Chat: Securing The Software Supply Chain
- Reimagining Cyber Podcasts: episode 26 on Log4j vulnerabilities and episode 4 on SolarWinds
Join our Community | Fortify discussion forum | Tips & Info | What is Application Security