KubeCon + CloudNativeCon Europe 2023, Amsterdam, Netherlands – Thanks to a succession of security disasters, such as the SolarWinds software supply chain attack, the ongoing Log4j vulnerability and the npm maintainer protest code gone wrong, developers now know that they must secure their software source-code supply chain.
To do this they are using new tools, including Software Bill of Materials (SBOM), pronounced “S-Bomb,” and Supply-chain Levels for Software Artifacts (SLSA), pronounced "Salsa.” But how does it all work in practice?
To find out, and enhance their security, two leading Cloud Native Computing Foundation (CNCF) projects, Argo and Prometheus, underwent software supply chain security audits.
The audits
Cloud-native security company Chainguard did the audits and built upon previous independent security audits using SBOMs.
SBOMs are a nested inventory, a list of ingredients that make up software components – like a detailed recipe for software programs.
SLSA describes the standards and technical controls needed to verify the code's sources, provenance and build. It provides a set of progressive levels, ranging from Level 1 to Level 4, which define specific requirements and practices. These levels serve as a roadmap for organizations to help them gradually enhance their software supply chain security.
A key SLSA component is the provenance document. This provides essential information on how a software artifact is built and its dependencies. Provenance documents not only go beyond artifact signatures but also play a pivotal role in preventing tampering and the use of tampered artifacts.
Put it all together, and the name of the audit game is to make sure that all the components are what they say they are, and they've been used together in a way to ensure the result is a safe program.
Argo results
During the audits, Chainguard discovered that Argo CD, the Argo GitOps continuous delivery Kubernetes tool achieved SLSA Level 3 for its source, build and provenance segments in the Argo CD supply chain. This indicates that the project's source and build platforms meet stringent standards for auditability and provenance integrity. The Argo maintainers are continuously working to improve their SLSA levels by incorporating provenance and signing throughout their release objects.
Prometheus results
Prometheus, a popular cloud-native monitoring system and time series database, also achieved SLSA Level 3 for its source and build sections.
However, the lack of provenance for published artifacts resulted in SLSA Level 0 for provenance. The audit team advised Prometheus maintainers to implement provenance generation within the project's build infrastructure and across all associated projects.
SLSA progress
Of course, SLSA is still a work in progress. The release of SLSA 1.0 is expected momentarily. It appears that SLSA, an Open Source Security Foundation (OpenSSF) project, will then be rapidly and broadly adopted.
To date, SLSA has garnered support from such major tech powers as Google, Microsoft, IBM, Intel and VMWare.
"SLSA has been instrumental in moving forward the security of open-source packages in a way that makes sense for users, open-source maintainers and vendors,” Zach Steindler, a GitHub Principal Security Engineer, explained to Silverlinings.
If developers are to secure their software, security mechanisms such as SBOM and SLSA aren't just a good idea, they're a necessity.