The surge of hacker attacks on software supply chains gave impetus to increasing the transparency of the IT infrastructure and accountability of software vendors. One instrument for this purpose is a software bill of materials (SBOM), which provides essential data on all libraries used to develop a software product. But an SBOM is a collection of data, which should ideally be integrated into higher-level security processes represented by the Supply-chain Levels for Software Artifacts (SLSA) framework.
The article overviews this novel cybersecurity technique and its advantages for organizations looking for industry-standard ways to identify and mitigate security risks.
Table of Contents
What is Supply-chain Levels for Software Artifacts (SLSA)?
SLSA is a framework providing specifications and common language that enable software users to ensure the code is trustworthy and wasn’t tampered with. Google proposed it in cooperation with OpenSSF in 2021 in answer to the concerns about the integrity of software supply chains, which are related to the ever-increasing number of supply chain attacks.
SLSA is beneficial for everyone involved in producing or utilizing software:
- Software developers and vendors writing open-source or proprietary software can ensure that the product they produce reaches their users untouched and as intended;
- Infrastructure providers can provide a reliable SLSA-compliant build platform that connects software vendors to consumers;
- Consumers (both developers using software libraries and tools for their applications and organizations integrating a software product) can make an informed decision about the integrity and trustworthiness of the software package.
How SLSA complements an SBOM
A software bill of materials and SLSA are two complementary tools that help to increase the transparency of a supply chain and guarantee the integrity of software packages. An SBOM is often compared to a list of ingredients because it provides a list of dependencies used for software development. In this regard, SLSA is a set of guidelines that help software manufacturers ensure and prove that the contents of a package correspond to the ingredient list. By following and attesting to the SLSA requirements, developers confirm that
- No malicious code was introduced into their product at any development stage;
- The packages are built with the expected build platform;
- The list of dependencies wasn’t tampered with.
As a result, end-users receive the list of dependencies with the data on their provenance and existing vulnerabilities. They can decide whether they can trust the supplier by judging their SLSA compliance.
SLSA requirements
SLSA consists of requirements for producing artifacts (immutable data blobs, such as container images, files, git commits, etc.) at various levels, discussed in more detail in the section below. The requirements are split between
- Producers — organizations, teams, or individual developers who own and release software, who must
- Choose a build platform satisfying the requirement for a necessary SLSA level;
- Consistently build artifacts;
- Distribute provenance to consumers in the form of attestations.
- Build platforms — infrastructures transforming code into packages, which must
- Generate provenance describing how the package was produced;
- Isolate between builds to guarantee that the build was executed without external influence.
SLSA Levels
The SLSA framework is divided into tracks and levels. Current version 1.0 defines only the Build track (describing the artifact’s provenance), with more tracks covering the whole supply chain planned for future releases. Each level represents a higher degree of software security, with Level 0 assigned to a system without any implemented security measures. For instance, security levels for the Build track are described as follows:
- On Level 1, the provenance exists. The build system can automatically generate provenance; developers follow a consistent build procedure and provide customers with provenance data.
- On Level 2, the builds run on a hosted platform that generates and signs the provenance, and the authenticity of provenance is validated by downstream verification.
- On Level 3, builds run on a hardened build platform with extra protection against tampering (preventing runs from influencing one another and making secret material used for provenance signing unavailable to user-defined build steps.)
Each level builds upon the previous one, gradually enabling the developers to fortify their systems based on specific requirements.
Getting started with SLSA
Let’s look at the process of integrating SLSA into your workflow:
- The first step is to select and implement a SLSA-compliant build platform if you aren’t using one already. Different platforms correspond to different SLSA Levels (for instance, GitHub Actions is suitable for Level 3.)
- Secondly, generate provenance data. A simple build configuration file is enough for Level 1. Some platforms, such as FRSCA or GitHub Actions, provide tools for generating signed provenance and can be applied at higher SLSA levels.
- The next step is to make the provenance metadata available to users in the form of SLSA attestations. There are several ways to distribute the attestations. For instance, some repositories support publishing provenance files together with the artifact. Another option is to include provenance in source repository releases (for example, GitHub or GitLab.)
Conclusion
As you can see, implementing the basic SLSA Level is not complicated, but you get the benefits of a more transparent and reliable software production cycle.
So, the first step towards greater transparency and credibility of a software supply chain is to generate an SBOM for your software supply chain and then gradually implement measures to reach SLSA compliance. To aid Java developers in this task, BellSoft provides Alpaquita Cloud Native Platform, a comprehensive solution for developing and deploying cloud-native Java applications with
- Liberica JDK, an OpenJDK distribution with a wide range of supported platforms and versions,
- Alpaquita Linux, a lightweight Linux distribution with enhanced flexibility and security,
- Liberica Native Image Kit for converting Java applications into native images and
- Enterprise support from one vendor.
All products are developed per the Secure Development Lifecycle (SDL) practices and receive regular security patches. We will also provide a software bill of materials, helping you to keep your infrastructure transparent and integrate modern cybersecurity solutions. Contact us, and we will be happy to answer any questions.
