OpenSSF Adds Software Supply Chain Tracks to SLSA Framework
The Open Source Security Foundation (OpenSSF) has released v1.0 of Supply-chain Levels for Software Artifacts (SLSA) with specific provisions for the software supply chain.
Modern application development teams regularly reuse code from other applications and pull code components and developer tools from myriad sources. Research from Snyk and the Linux Foundation last year found that 41% of organizations didn’t have high confidence in open source software security. With supply chain attacks posing an ever-present and ever-evolving threat, both software development teams and security teams now recognize that open source components and frameworks need to be secured.
SLSA is a community-driven supply chain security standards project backed by major technology companies, such as Google, Intel, Microsoft, VMware, and IBM. SLSA focuses on increasing security rigor within the software development process. Developers can follow SLSA’s guidelines to make their software supply chain more secure, and enterprises can use SLSA to make decisions about whether to trust a software package, according to the Open Source Security Foundation.
SLSA provides a common vocabulary to talk about software supply chain security; a way for developers to assess upstream dependencies by evaluating the trustworthiness of source code, builds, and container images used in the application; an actionable security checklist; and a way to measure compliance with the forthcoming Secure Software Development Framework (SSDF).
The SLSA v1.0 release divides SLSA’s level requirements into multiple tracks, each one measuring a particular aspect of software supply chain security. The new tracks will help users better understand and mitigate the risks associated with software supply chains and ultimately develop, demonstrate, and use more secure and reliable software, the OpenSSF says. SLSA v1.0 also provides more explicit guidance on how to verify provenance, along with making corresponding changes to the specification and provenance format.
The Build Track Levels 1-3, which roughly correspond to Levels 1-3 in earlier SLSA versions, describes levels of protection against tampering during or after software build. The Build Track requirements reflect the tasks required: producing artifacts, verifying build systems, and verifying artifacts. Future versions of the framework will build on requirements to address other aspects of the software delivery life cycle.
Build L1 indicates provenance, showing how the package was built; Build L2 indicates signed provenance, generated by a hosted build service; and Build L3 indicates the build service has been hardened.
The higher the level, the higher the confidence that a package can be traced back to its source and has not been tampered with, OpenSSF said.
Software supply chain security is a key component of the Biden administration’s US National Cybersecurity Strategy, as it pushes software providers to assume greater responsibility for the security of their products. And recently, 10 government agencies from seven countries (Australia, Canada, Germany, the Netherlands, New Zealand, the United Kingdom, and the United States) released new guidelines, “Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Security-by-Design and -Default,” to urge software developers to take necessary steps to ensure they are shipping products that are both secure by design and by default. That means removing default passwords, writing in safer programming languages, and establishing vulnerability disclosure programs for reporting flaws.
As part of securing the software supply chain, security teams should be engaging with developers to educate them about secure coding practices and tailoring security awareness training to include the risks surrounding the software development life cycle.
Read More HERE