TNS
VOXPOP
Should IBM Open Source Terraform?
Should IBM donate the soon-to-be-acquired HashiCorp Terraform to the Linux Foundation?
Yes, a vendor-neutral group like the Linux Foundation is the way to go.
0%
Yes, but to Apache, FSF or another less corporate-friendly open source governing body.
0%
No, IBM just spent $6.4 billion on HashiCorp. Why give away the code for free?
0%
No, The Linux Foundation already has the code ("OpenTofu")
0%
I don’t use Terraform. It’s none of my business where the code goes.
0%
Security / Software Development

OpenSSF Boosts Software Supply Chain Security with SLSA 1.0

Supply-chain Levels for Software Artifacts (SLSA) Version 1.0 will help protect software code from tampering and facilitate secure development practices.
Apr 19th, 2023 6:00am by
Featued image for: OpenSSF Boosts Software Supply Chain Security with SLSA 1.0

Developers who are serious about securing their code have cause to rejoice. The Open Source Security Foundation (OpenSSF) is releasing Supply-chain Levels for Software Artifacts (SLSA, pronounced Salsa) version 1.0. This comprehensive framework is designed to improve software supply chain security for programmers. Established by community expert consensus, SLSA offers a series of security levels that provide increasing rigor to ensure the software remains tamper-proof and can be securely traced to its source.

Software Bill of Materials (SBOM, pronounced S-Bomb) are great as far as they go. As President Joe Biden’s Executive Order on Improving the Nation’s Cybersecurity, issued on July 12, 2021, stated SBOMs are “a formal record containing the details and supply chain relationships of various components used in building software.” But, to safeguard the integrity of open source software artifacts, you need more. That’s where SLSA comes in.

SLSA Tracks

SLSA levels are split into tracks. Each track has its own set of levels that measure a particular aspect of supply chain security. The purpose of tracks is to recognize progress made in one aspect of security without blocking on an unrelated aspect. Tracks also allow the SLSA spec to evolve: more tracks can be added without invalidating previous levels.

I like to think of SBOMs as the recipe, and SLSA as the cooking instructions for a program. The end goal is to safely and securely automate software builds while validating everything going into the build.

Specifically, SLSA 1.0 provides:

  • A common vocabulary to talk about software supply chain security.
  • A way to assess your upstream dependencies by evaluating the trustworthiness of the artifacts you consume, such as source code, builds, and container images.
  • An actionable checklist to improve your own software’s security.
  • A way to measure your efforts toward compliance with forthcoming Executive Order standards in the Secure Software Development Framework (SSDF).

Key Milestone

Brian Behlendorf, the OpenSSF’s General Manager, emphasized that the stable release of SLSA v1.0 is a significant milestone in bolstering software supply chain security. By providing organizations with essential tools, SLSA enhances the software development process and protects it from supply chain attacks. It provides developers with “the tools they need to protect their software.”

That’s because SLSA offers a common vocabulary to discuss software supply chain security, assess upstream dependencies, provide an actionable checklist to improve software security, and measure compliance efforts in line with the forthcoming SSDF standards.

The release of SLSA v1.0 introduces a significant change in the framework’s structure, dividing its level requirements into multiple tracks that focus on specific areas of the software supply chain, such as build, source, and dependencies. This division simplifies SLSA adoption for users and allows the framework to address other critical aspects of the Software Delivery Lifecycle more effectively.

Adopting SLSA benefits software producers, consumers, and infrastructure providers by offering protection against tampering, increasing confidence in software integrity, and facilitating a secure software supply chain between all parties.

Lower Barrier to Entry

As Scott Robertson, CTO at cloud development and security company ActiveState, explained, “In development, you can’t optimize what you can’t measure, and this is why SLSA is exciting; it provides auditable data, in machine-readable form. This validates the chain of custody from code authors to the binaries deployed in production systems. It gives us the provenance of binaries used in sensitive operating environments, so we can make informed decisions on whether or not to trust and incorporate certain packages into builds. These are foundational concepts to actually achieving what has largely been a buzz phrase; supply chain security.”

The stable release of the SLSA 1.0 Build Track lowers the entry barrier for security improvements. It also helps programmers to focus their efforts on enhancing their build while reducing the risk of tampering across a wide range of the supply chain. As Kim Lewandowski, cloud security company Chainguard co-founder, said, “The release of SLSA v1.0 represents a significant step forward in building trust between software consumers and producers, as it provides a well-established framework that outlines how software is protected and developed based on software supply chain security principles.”

With support from Google, IBM, Microsoft, and Intel, I expect SLSA to become one of the defining software supply chain security standards. You can start using SLSA yourself today to get a head start on adopting it for your own programs.

Group Created with Sketch.
TNS DAILY NEWSLETTER Receive a free roundup of the most recent TNS articles in your inbox each day.