In light of recent, multi-billion-dollar cyber attacks, Google has introduced a framework to help developers improve software supply chain security. This proposed solution is supply chain levels for software artifacts (SLSA, pronounced “salsa”), an end-to-end framework for ensuring the integrity throughout the entire development process.
This framework provides recommendations for organizations to help achieve a more secure software development and deployment process; the key to this improvement is identifying and mitigating issues in CI/CD pipelines with the takeaways from the Google SLSA framework.
In this blog, we will discuss how SLSA works, its different security levels, and main categories of requirements.
Key highlights:
- SLSA 4 Compliance: Leverage the highest SLSA levels to enforce multilateral change approval and hermetic builds for maximum software integrity.
- Software Supply Chain Security: Implement the framework to defend against major attacks by ensuring all artifacts are auditable and securely traceable.
- Automated SBOMs: Automatically generate verified Software Provenance to provide transparency and simplify vulnerability management throughout the supply chain.
What Is SLSA in Supply Chain Cybersecurity?
SLSA (Supply Chain Levels for Software Artifacts) is a security framework designed to prevent tampering, improve integrity, and secure software artifacts throughout the development and distribution process. It works by providing a set of standardized, incremental security levels (1 through 4) that guide organizations on hardening their software supply chain against increasingly sophisticated threats.
How the SLSA Framework is Applied
Organizations apply the SLSA framework by adopting its measurable and achievable requirements across five core categories: Source, Build, Provenance Generation, Provenance Content, and Common Requirements.
- Establishing Trust: SLSA centers on proving provenance, which is tamper-evident metadata that verifies where, how, and by whom a piece of software was built.
- Incremental Adoption: Companies typically start by automating their build processes to achieve SLSA 1 or 2, then progress to requiring stronger controls like isolated build environments and multi-party code review for SLSA 3 and 4.
Automated Enforcement: The ultimate goal is for the entire development pipeline to be automatically audited and enforced by policy engines, ensuring that software integrity standards are consistently met before artifacts are deployed.
Who Governs the SLSA Framework for CI/CD Pipelines?
The Open Source Security Foundation (OpenSSF) governs the SLSA Framework for CI/CD pipelines, stewarding it as a vendor-neutral standard for the industry.
How SLSA Governance Works
While SLSA (Supply-chain Levels for Software Artifacts) was initially developed by Google based on their internal security practices, it was contributed to and is now led by the OpenSSF, a neutral foundation focused on improving open-source software security.
- Consensus-Driven: The SLSA framework is governed by an industry-wide steering committee with representatives from various companies and organizations (including Google, Microsoft, and Red Hat), ensuring its development is guided by industry consensus rather than a single vendor.
- Community Specification: SLSA operates as an open-source project under a Community Specification License, which promotes collaboration, public development, and widespread adoption across the ecosystem of software producers, consumers, and infrastructure providers.
- Continuous Improvement: The OpenSSF continuously refines the specification and provides tooling (such as generators for attestation) to help organizations meet the framework’s incremental security levels (SLSA 1 through SLSA 4).
Google SLSA Explained
The SLSA framework is inspired by Google’s internal “Binary Authorization for Borg,” which has been in use for the past 8+ years and is mandatory for all of Google’s production workloads. The goal is to defend against threats to the software supply chain, fill a gap in cybersecurity guidance, and help all consumers, from grandmas to CISOs, make informed choices about the security of the software they use.
Based on SLSA principles, software artifacts should be both:
- Multilateral: Software artifacts cannot be modified by one person without explicit approval from at least one other trusted person. This helps prevent, deter, and detect nefarious changes within the software supply chain.
- Auditable: Software artifacts can be traced back to their original, human-readable sources and dependencies both securely and transparently.
When combined, these two principles provide significant protection from tampering, confusion, and other supply chain attacks.
Why Implement SLSA Standards?
Achieving the highest level of SLSA security for most projects may be difficult, but incremental improvements recognized by lower levels will go a long way toward improving the security of the open source ecosystem. This proposed solution from Alphabet is designed to protect against common supply chain attacks. To those less familiar with the structure of the software supply chain, an example of such a pipeline is depicted below:
The software supply chain creates and releases a software artifact based on a sequence of steps. Each utilizes dependencies that are ultimately a combination of its sources and builds. With an increase in attack surface area, supply chain attacks have become more attractive because of both a high return on investment and a lower detection risk compared to direct breaches.
Attacks on the software supply chain have increased dramatically over the last year and this rate of increase is projected to further increase. It’s better for organizations to implement protections now rather than after a breach has occured.
The 4 Levels of SLSA Security Recognized by Google
Currently, SLSA is a set of incrementally adoptable guidelines with four levels. Each level has a well-defined set of guidelines, which ideally should help companies gradually improve security without getting too much dip on their chip. Each level of SLSA acts as a milestone towards the eventual goal of achieving SLSA 4. What makes SLSA different and bigger than another set of best practices guidelines is the eventual goal of making this framework automatically enforceable.
This final form of SLSA will be functionally designed to automatically give certification to a particular package or build platform based on results from policy engines. In a way, this represents a zero-trust method of rating the implementation of zero-trust development paradigms.
Broadly speaking, the different levels of requirements may be described as:
- SLSA 1: The build process is fully scripted/automated and generates provenance, including metadata regarding how an artifact was built. This metadata is derived from the build process, top-level source, and dependencies. The generated provenance offers a basic level of source code identification but does not protect against code tampering.
- SLSA 2: The build utilizes version control and a hosted build service that generates authenticated provenance, which provides tamper resistance to the extent that the build service is trusted
- SLSA 3: The source and build platforms adhere to standards that guarantee both the integrity of the provenance and the auditability of the source code. Significantly stronger protections against build tampering versus the lower SLSA levels are provided by preventing specific classes of threats, such as cross-build contamination.
- SLSA 4: Two-person review of all changes is required as it is an industry best practice for identifying issues, and the build process is hermetic, ensuring the provenance list of dependencies is complete. Reproducible builds are not strictly required, but are recommended as they provide many auditability and reliability benefits. This gives end-users a high degree of confidence that the software has not been compromised.
Categories of SLSA Requirements and Key Takeaways from Google’s Framework
More details on the specific requirements may be found within the SLSA requirements documentation, but the boiled-down requirements may be expressed within five main categories: source requirements, build process requirements, provenance generation requirements, provenance content requirements, and common requirements for every trusted system in the supply chain.
Let’s break these down and look at the Google SLSA framework takeaways for each:
Source Requirements
Source requirements are designed to ensure the integrity of the source code. This aids in reducing the chances of code tampering and nefarious actions from going unnoticed.
| Source Requirements | Description | SLSA |
| Version controlled | Every change to the source is tracked | 2 |
| Verified history | Every change in the revision’s history has at least one strongly authenticated actor identity (author, uploader, reviewer, etc.) and timestamp. | 3 |
| Retained indefinitely | The revision and its change history are preserved indefinitely and cannot be deleted | 4 |
| Two-person reviewed | Every change in the revision’s history was agreed to by two trusted persons prior to submission, and both of these trusted persons were strongly authenticated. | 4 |
In order to meet the source requirements, best practices for source code management should be employed. The highest levels of SLSA necessitate that requirements for changes to the source code should be well reviewed and trackable. This helps negate the risk of both insider threats and outsider attacks by making it less likely that nefarious commits go undetected.
For more information on fulfilling SLSA source requirements, please read our article detailing how Cycode’s platform can help your SCM achieve SLSA level 4.
Build Requirements
Build requirements are meant to improve the safety of the build ecosystem and prevent compromises to the build platform.
| Build Requirement | Description | SLSA |
| Scripted build | All build steps are fully defined without manual commands. | 1 |
| Build service | All build steps ran using a dedicated build service. | 2 |
| Ephemeral environment | The build steps run in an ephemeral environment, such as a container or VM, provisioned solely for this build. | 3 |
| Isolated | The build steps run in an isolated environment free of influence from other build instances. | 3 |
| Parameterless | The build is fully defined through the build script and nothing else, taking no user parameters. | 4 |
| Hermetic | All transitive build steps, sources, and dependencies fully declared with immutable references, and the build steps ran with no network access. | 4 |
| Reproducible | Running the build steps with identical input artifacts results in bit-for-bit identical output. | O |
The same best security practices applied to the source should also be applied to infrastructure as code (IaC) and pipelines. As issues with the build increase with increased touchpoints with developers, the build process should be fully automated and not depend on any outside parameters. This helps ensure the build is predictable and complete to demonstrate its safety.
Provenance Generation Requirements
Provenance generation requirements are designed to make downstream verification available.
| Provenance Generation Requirements | Description | SLSA |
| Available | The provenance is available to the consumer in a format that the consumer accepts, eg, SLSA Provenance. | 1 |
| Authenticated | The provenance’s authenticity and integrity can be verified by the consumer. | 2 |
| Service generated | The data in the provenance MUST be generated from the build service. | 2 |
| Non-falsifiable | Provenance cannot be falsified by the build service’s users. | 3 |
| Dependencies complete | Provenance records all build dependencies that were available while running the build steps. | 4 |
The requirements at the highest SLSA level entail creating a software bill of materials (SBOM), which conveys an inventory of all dependencies used by an application and build pipeline. This provides visibility into the dependencies used and can also be used to determine the potential vulnerabilities hidden within the application. Such a vulnerability example includes the Log4J exploit, which affected so many organizations because of its prevalence as a logging library.
The key to provenance generation is trust. This means that provenance generation should be verifiable, accessible, and complete. Any users who wish to use this software should be able to see, without reasonable doubt, that the provenance may be trusted.
Provenance Content Requirements
Provenance content requirements identify the artifact, builder, and build restrictions used when executing a build. At higher SLSA levels, more identifiers are used to track other details of the build.
| Provenance Content Requirements | Description | SLSA |
| Identifies artifact | The provenance MUST identify the output artifact via at least one cryptographic hash. | 1 |
| Identifies builder | The provenance identifies the entity that performed the build and generated the provenance. | 1 |
| Identifies source | The provenance identifies the source containing the top-level build script, via an immutable reference. Example: git URL + branch/tag/ref + commit ID. | 1 |
| Identifies entry point | The provenance identifies the “entry point” or command that was used to invoke the build script. | 1 |
| Includes all build parameters | The provenance includes all build parameters under a user’s control. | 3 |
| Includes all transitive dependencies | The provenance includes all transitive dependencies listed in Dependencies Complete. | 4 |
| Includes reproducible info | The provenance includes a boolean indicating whether the build is intended to be reproducible and, if so, all information necessary to reproduce the build. | 4 |
| Includes metadata | The provenance includes metadata to aid debugging and investigations. This should include start and end timestamps and a permalink to debug logs. | O |
Provenance is only as valuable as the information it communicates, so care should be taken to include all relevant, outlined pieces in the provenance. In addition, every piece involved in generating the provenance of the build should be non-falsifiable to improve user confidence in the software and build security.
Common Requirements
Common requirements are prescribed for every trusted system in the software supply chain. This includes the source, build, distribution, and other systems.
| Common Requirements | Description | SLSA |
| Security | The system meets some TBD baseline security standard to prevent compromise. | 4 |
| Access | All physical and remote access must be rare, logged, and gated behind multi-party approval. | 4 |
| Superusers | Only a small number of platform admins may override the guarantees listed here. Doing so MUST require approval of a second platform admin. | 4 |
Mitigating the risk of unauthorized changes through SLSA’s common requirements may be likened to designing a bank vault that takes multiple people to unlock; every system involved in the software supply chain should be secure, with no one user having access to change the system without additional oversight. All administrative access to the system should be highly visible and retained for regular audits–logs are only useful if they are read.
Benefits of SLSA for Organizations and Consumers
These incrementally adoptable security guidelines established by industry consensus provide clearly defined guiding principles, standardization if you will. Both organizations and consumers can benefit from the standards that the Google SLSA framework establishes:
| Stakeholders | How They Benefit |
| Software Producers (Enterprises, Open-Source Projects) |
|
| Software Consumers (Developers, CISOs, Procurement) |
|
The guidelines set by Google SLSA will undoubtedly have an effect on increasing the resiliency of software against supply chain attacks, and we eagerly await the next phase of SLSA’s life.
How Cycode Can Help Implement Google SLSA
Can’t wait for the Google SLSA framework to be fully unveiled? Cycode can help improve your supply chain integrity by providing complete visibility into enterprise DevOps tools and infrastructure. Our IaC capabilities include comprehensive security scanning, helping prevent:
- Escaped secrets,
- Environmental drift,
- Code leaks
Once integrated into developer workflows, each commit and pull request (PR) is scanned for issues, including hardcoded secrets or potential misconfiguration, and alerts are issued appropriately. Remediation is available both through a GUI and within the PR.
Cycode helps establish strong governance over all points of the IaC lifecycle by providing a cross-SCM inventory of all users, contributors, teams, organizations, and repositories in your organization; this governance extends into providing more oversight into changes made to code as a means of further protecting key code. The platform also helps you automatically audit access privileges to identify and reduce excessive, unused privileges and implement separation of duties.
Also, Cycode ensures that strong authentication and secure development practices are in place. This helps apply security best practices for IaC code when using Terraform, Kubernetes, YAML, ARM, and CloudFormation.
Want to Learn More? Book a demo today and get a free assessment of the security of your DevOps pipeline.
