Emerging Software Supply Chain Security Best Practices

by Micro Focus Employee in CyberRes

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. 

Emerging Software Supply Chain Security Best PracticesC-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: 

 

Join our Community | Fortify discussion forum | Tips & Info | What is Application Security

Labels:

Application security
Anonymous
Parents
  • Enterprise software projects increasingly depend on third-party and open source components. These components are created and maintained by individuals who are not employed by the organization developing the primary software, and who do not necessarily use the same security policies as the organization. This poses a security risk, because differences or inconsistencies between these policies can create overlooked areas of vulnerability that attackers seek to exploit.

Comment
  • Enterprise software projects increasingly depend on third-party and open source components. These components are created and maintained by individuals who are not employed by the organization developing the primary software, and who do not necessarily use the same security policies as the organization. This poses a security risk, because differences or inconsistencies between these policies can create overlooked areas of vulnerability that attackers seek to exploit.

Children
No Data