The Open Source Security Foundation (OpenSSF) recently announced the stable release of version 1.0 of Supply-chain Levels for Software Artifacts (SLSA, pronounced "salsa"). This framework provides specifications for software supply chain security, offering a standardized language to discuss, evaluate, and improve security posture. The release of SLSA 1.0 marks an important milestone in mitigating supply chain attacks and improving software security.
Advantages of SLSA Adoption
Adopting SLSA offers several benefits for software producers, consumers, and infrastructure providers. For producers, SLSA provides protection against tampering and increases consumer confidence. Open source projects can use SLSA to demonstrate the security of their releases. For consumers, SLSA helps assess the security practices of the software they rely on. Infrastructure providers benefit from SLSA by providing a secure bridge between producers and consumers.
The SLSA 1.0 Build Track offers a foundation for future framework expansion, lowering the barrier of entry for improvements and reducing the chances of tampering.
Limitations and Future Directions
Despite the many advantages of SLSA, it is important to acknowledge its limitations. The framework, while comprehensive, is not a one-size-fits-all solution. Adoption can be challenging for smaller organizations, particularly those without dedicated security teams. Additionally, while SLSA aims to prevent source code and build system tampering, it cannot address all possible attack vectors. Organizations must remain vigilant and invest in continuous improvement to ensure software security.
As SLSA matures, it will be crucial to address these limitations and broaden the framework to encompass all critical aspects of the Software Delivery Lifecycle. The introduction of multiple tracks, focusing on areas like build, source, and dependencies, is a promising start. However, further work is needed to ensure the framework is accessible, practical, and effective for all users.
Further work is needed to ensure the framework is accessible, practical, and effective for all users.
SLSA and SBOMs
Under SLSA 1.0, software suppliers are expected to provide an SBOM that identifies all the components of their software product, along with relevant metadata such as version numbers, licensing information, and known vulnerabilities. The SBOM can help downstream consumers of the software understand the composition of the product and assess its security posture.
While SLSA (Supply-chain Levels for Software Artifacts) is a framework focused on improving the integrity and security of software artifacts throughout the software supply chain, SBOMs (Software Bill of Materials) are an important aspect of that software supply chain security. SBOMs help track components, licenses, copyrights, and security references.
While SLSA (Supply-chain Levels for Software Artifacts) is a framework focused on improving the integrity and security of software artifacts throughout the software supply chain, SBOMs (Software Bill of Materials) are an important aspect of that software supply chain security.
Both SPDX and CycloneDX are formats for creating and sharing SBOMs.In the context of the SLSA framework, SPDX and CycloneDX SBOMs can play a role in providing transparency and traceability of the components and dependencies within a software artifact. They can help meet the requirements set out by the SLSA levels and be utilized in various parts of the software supply chain.
To make SPDX and CycloneDX more effective in supporting SLSA 1.0, consider the following:
- Ensure compatibility with SLSA requirements: SPDX and CycloneDX should be able to express the necessary data and metadata required by the SLSA framework. This may include information about provenance, build process, testing, and more.
- Integration with build and CI/CD tools: Both SPDX and CycloneDX should be easily integrable with common build systems, continuous integration, and continuous deployment tools. This will help automate the generation and sharing of SBOMs throughout the supply chain.
- Verification and validation: Both SPDX and CycloneDX should support mechanisms for verifying and validating the integrity and authenticity of the data and metadata they contain. This could be achieved through digital signatures, checksums, or other methods.
- Collaboration with SLSA working group: To ensure compatibility and alignment, SPDX and CycloneDX maintainers and stakeholders should actively collaborate with the SLSA working group, participating in discussions and contributing to the development of the SLSA framework.
By addressing these aspects, the SPDX and CycloneDX SBOM formats can be made more effective in supporting the SLSA framework, contributing to the overall goal of improving the integrity and security of software artifacts across the supply chain.
SBOMs and SLSA are fundamentally different, but SLSA principles can guide the generation of high-quality SBOMs ultimately helping developers, consumers, and providers (those using 3rd party binaries) respond to supply chain attacks.
SLSA and SBOMs: Working Together
SBOMs and SLSA work in tandem, with certain SLSA principles facilitating the creation of SBOMs. One key SLSA principle is the generation of tamper-resistant provenance data, which refers to metadata that verifies the individual responsible for an artifact's release process, the materials employed during production, and the security measures in place to prevent tampering. As SBOMs rely on precision, comprehensiveness, and reliability, incorporating SLSA provenance for an artifact enhances both the quality and integrity of the associated SBOM.
There are still some areas where SBOMs fail to complete SLSA requirements:
- SBOMs currently don’t include or require enough information to help users respond to build tampering and attacks like Solarwinds and Codecov: Specifically SBOMs lack much of the required metadata to support these types of signed, verifiable attestations, but both SBOMs and SLSA are able to evolve to be more compatible.
- There’s no well-established ecosystem to easily distribute and verify SBOM documents: With the need for SBOMs to support EO 14028, "Improving the Nation's Cybersecurity” the industry is going to see a very quick shift in the need to transfer and manage SBOMs, above and beyond the current "I'll email you the SBOM..." model.
- The most common method of generating SBOMs using only audit tools after the software’s creation can result in less accurate SBOMs: This is an important distinction. The most accurate SBOM generation comes from shifting both left and right: gathering data at time of development and after compilation.
Conclusion
In conclusion, the SLSA 1.0 framework represents a significant step forward in improving software supply chain security, providing standardized language and practices to assess and enhance security posture. While SBOMs, in formats like SPDX and CycloneDX, play an important role in achieving supply chain transparency and traceability, it is vital to address their current limitations and enhance their compatibility with SLSA requirements. By improving the generation, distribution, and verification of SBOMs, the industry can better leverage the potential of SLSA and SBOMs working together. Moving forward, the collaboration between the SLSA working group, SPDX, and CycloneDX stakeholders will be crucial in ensuring an accessible, practical, and effective framework that enhances the overall security and integrity of software artifacts across the supply chain.
