Supply-chain Levels for Software Artifacts (SLSA) ( pronounced “salsa”) was proposed in 2021 by Google as a structured, multi-level approach for securing supply chains throughout the software development lifecycle. Its goals are to prevent tampering during the build process, maintain the integrity of package distribution systems, and safeguard build environments.
In the last few years, major attacks have demonstrated the importance of software supply chain security:
In 2021, malicious actors created a backdoor (codenamed Sunburst) into software updates for SolarWinds’ Orion platform, which then were distributed to more than 18,000 organizations, including U.S. government agencies and critical infrastructure providers.
In 2023, hackers attacked Okta, which provides authentication and identity verification services. By targeting Okta’s support management system, the hackers managed to access customer session tokens for Okta’s platform.
In the same year, an attack against popular IDE company JetBrains allowed hackers to gain administrative control over companies’ CI/CD servers.
These three attacks share a key similarity: They all targeted critical vulnerabilities in the software supply chain or in support infrastructure. Simply put, they exploited the growing interdependence among software libraries, build tools, and infrastructure. The widespread reuse of shared dependencies and components means that a single vulnerability can impact thousands of companies’ cloud native applications and lead to substantial losses. Effective incident response and prevention requires a standardized approach to securing the supply chain at every stage. This is precisely why SLSA is so important.
In this article, we’ll discuss how DevOps teams can take advantage of this framework to create reliable build pipelines and, more generally, secure the entire software development lifecycle.
The Secure Coding Best Practices [Cheat Sheet]
With curated insights and easy-to-follow code snippets, this 11-page cheat sheet simplifies complex security concepts, empowering every developer to build secure, reliable applications.
Download cheat sheet
The four SLSA security levels
The SLSA framework introduces four levels of software supply chain security, and each offers guidelines and best practices. (One quick note: SLSA Level 0 is a base level indicating that no SLSA requirements have been implemented.)
Levels 1–4 are applied to various areas of the supply chain, including the source code, build systems, packaging, and dependencies. Still, as of SLSA version 1.0 (released in April 2023 by OpenSSF) , the primary focus is on the build track. Here’s a closer look at each level.
SLSA Level 1
Level 1’s main emphasis is on provenance—the who, what, and how of the build process. Provenance should be provided by the build platform to show how the package was built. Its key elements include:
Digest/hash of the output artifact
Dependencies used during the build
Build metadata (source repository, commit hash, etc.)
Level 1 is designed to promote secure coding and prevent common mistakes, such as distributing incorrect packages (e.g., wrong release versions). The downside? It can be easily bypassed and forged. Since the provenance data is not signed, attackers with access to artifact metadata can modify it to point to malicious artifacts, making it impossible to detect the forgery.
In other words, Level 1 provenance assumes the integrity of the build platform but does not validate it. If the build platform is compromised, the security of the artifacts may be at risk as well.
There’s another issue too: While the build dependencies are specified in Level 1 provenance, it does not verify that these dependencies are secure. Attackers could inject malicious dependencies into the software without the software producer or end user’s awareness. And downstream users have no way to confirm whether the metadata matches the artifact. To address these vulnerabilities, advancing to SLSA Level 2 is crucial.
SLSA Level 2
At SLSA Level 2, provenance is digitally signed by the build platform. The requirement of a valid digital signature that links the build platform to the artifact makes it significantly harder to forge or tamper with the artifact metadata without detection.
Another requirement of Level 2 is that the build platform itself must run on dedicated/protected infrastructure rather than on private developer workstations. This makes it harder to breach the software build process and reduces the attack surface.
In general, SLSA Level 2 is a big step towards a secure software supply chain, but it has several critical limitations. While provenance is digitally signed, SLSA Level 2 doesn’t address threats from insiders. And metadata integrity doesn’t guarantee that the build process itself is not compromised as a result of compromised credentials. (SLSA Level 2 prevents tampering after the build but not during the build itself.)
Also, SLSA Level 2 doesn’t enforce isolation of software builds, which leaves them vulnerable to contamination and/or interference from other processes on shared infrastructure. Finally, Level 2 does not provide any reproducibility guarantees: Given the same inputs, you are not guaranteed to get the same outputs.
SLSA Level 3
The next SLSA level addresses the risks of insider threats, compromised credentials, and tampering during the build process. At this level, the software supply chain can be considered significantly hardened, considering it requires all parties involved to adhere to strict security practices.
How are these improvements achieved? Level 3 requires better isolation of build runs. In practice, this means that each run should be independent from one another, even within the same project—each run should be executed in an isolated environment not affected by other processes.
Similarly, Level 3 prevents access to secrets from user-defined build steps. (These secrets are used to sign the provenance data.) This requirement minimizes the risk of insiders interfering with and altering the build process, enhancing the overall security of the software supply chain.
Companies who implement SLSA Level 3 can expect:
Reproducible builds: Identical inputs always produce the same outputs, increasing confidence in the integrity of artifacts.
Tamper-resistant builds: SLSA Level 3 protects the build process from unauthorized changes, ensuring a more secure and controlled environment.
More trust in artifacts: Downstream consumers of software can be more confident in the security and integrity of their own products.
SLSA Framework Use Cases in Real-World Scenarios
The SLSA framework can be applied across a variety of industries and software development practices to enhance supply chain security. Here are some specific examples of how organizations can implement SLSA to protect their software pipelines:
1. Securing CI/CD Pipelines in Enterprise Software Development
Modern software development relies heavily on CI/CD pipelines to automate builds, tests, and deployments. However, these pipelines are often vulnerable to attacks, such as malicious code injection or dependency confusion. For example, a financial services company developing internal tools for handling sensitive customer data needs to ensure that its software supply chain is secure from development to deployment.
By adopting SLSA Level 2, the company can enforce build integrity through its CI/CD pipelines, generate provenance metadata, and sign all artifacts cryptographically. This ensures that only verified and untampered code is deployed to production. Additionally, provenance metadata provides a clear audit trail, making it easier to detect and respond to potential compromises. This approach not only reduces the risk of supply chain attacks but also helps the company meet compliance requirements for data security.
2. Ensuring Trust in Open Source Software
Open source software is the backbone of modern applications, but its distributed nature makes it a prime target for supply chain attacks. For instance, a large open-source project like Kubernetes or Linux needs to ensure that its build process is secure and that users can trust the integrity of its artifacts.
By implementing SLSA Level 3, the project can use a trusted build service (e.g., GitHub Actions or Google Cloud Build) with tamper-proof logs and sign all artifacts with cryptographic keys. This allows users to verify the provenance of the software and confirm that it hasn’t been compromised. For open-source maintainers, SLSA provides a structured way to demonstrate the security of their build processes, fostering greater trust among users and contributors.
3. Securing Cloud-Native Applications
Cloud-native applications, often built using microservices and containerized workloads, are a cornerstone of modern software development. However, the complexity of these environments makes them vulnerable to supply chain attacks, such as compromised container images or unauthorized changes during deployment. For example, a SaaS provider wants to ensure that its container images are secure and haven’t been tampered with during the build and deployment process.
By adopting SLSA Level 3, the provider can use a secure build environment (e.g., Tekton or Google Cloud Build) to generate provenance metadata and sign container images. They can also enforce policy checks at deployment time using tools like Sigstore or Kyverno. This ensures that only verified and trusted images are deployed, reducing the risk of supply chain attacks. Additionally, provenance metadata provides transparency into the build process, enabling faster incident response and compliance with security standards.
Limitations of the SLSA Framework
While SLSA offers a powerful framework for improving software supply chain security, it also has limitations that organizations should be aware of before implementation.
1. Complexity and Cost of High-Level Implementation
Achieving SLSA Levels 3 and 4 can be resource-intensive and complex, requiring significant changes to CI/CD pipelines, build environments, and internal processes. Not all organizations have the infrastructure or technical maturity to implement these advanced security practices.
2. Focus on Build Security, Not Full Lifecycle
SLSA primarily addresses build integrity and source provenance but doesn’t cover other critical areas of software security, such as runtime protection, vulnerability management, and incident response. Organizations must adopt complementary tools and frameworks to secure the entire software lifecycle.
3. Limited Support for Third-Party Dependencies
Verifying the security of third-party components and external dependencies remains a challenge. SLSA’s provenance requirements reduce risks, but the framework doesn’t guarantee full visibility into third-party software or ensure its integrity.
4. Generalized Approach Requires Customization
SLSA is a broad framework that may not address industry-specific needs. For highly regulated industries such as finance or healthcare, additional security measures and customizations are often necessary to meet compliance requirements.
5. Evolving Framework with Limited Automation
Since SLSA is a relatively new and evolving standard, its guidelines are still being refined. Automation tools for implementing SLSA are improving but are not yet widespread, making manual processes and verification common, especially at higher security levels.
CI/CD Pipeline Security Best Practices [Cheat Sheet]
In this 13 page cheat sheet we'll cover best practices in the following areas of the CI/CD pipeline: Infrastructure security, code security, secrets management, access and authentication, monitoring and response
Download cheat sheet
SLSA Implementation Best Practices
Implementing the SLSA framework doesn’t require a full overhaul all at once. Follow these practical steps to gradually improve your software supply chain security, based on the level of protection your organization needs.
1.Assess and Choose the Right SLSA Level
Start by evaluating your current security posture and resources to determine the appropriate SLSA level.
Level 1: Ideal for early-stage security improvements with basic provenance tracking.
Level 2: Offers stronger protections with signed provenance and dedicated build infrastructure.
Level 3 and 4: Suitable for organizations with mature security practices, focusing on tamper-proof builds and reproducibility.
Don’t aim for the highest level right away. Instead, build incrementally to avoid disruption while achieving meaningful security improvements.
2. Secure Your Build Environment
Ensure your build environment follows SLSA standards and is protected from unauthorized access.
Use dedicated build infrastructure—avoid builds on developer workstations.
Regularly audit and update your build tools to prevent vulnerabilities.
Implement isolation for build runs to avoid cross-contamination between processes.
3. Standardize and Reproduce Build Processes
Consistency is key for secure builds. Ensure that your build pipelines are standardized and reproducible.
Adopt reproducible builds to guarantee the same output for identical inputs, increasing artifact integrity.
Monitor and manage dependencies with a Software Bill of Materials (SBOM) solution.
4. Harden and Manage Build Credentials
Protecting credentials used in the build process is crucial to avoid insider threats and compromised builds.
Store all build credentials in encrypted vaults—never hardcode secrets in your build configuration.
Use a Key Management System (KMS) to manage and rotate secrets regularly.
Implement Multi-Factor Authentication (MFA) and role-based access control (RBAC) for all build systems.
5. Monitor and Audit Build Activity Continuously
Continuous monitoring can help detect unusual activity and respond before threats escalate.
Use tools that provide real-time visibility into build processes and artifact integrity.
Conduct regular security audits of your CI/CD pipelines and build environments.
Hell’s Keychain: Supply-chain vulnerability in IBM Cloud Databases for PostgreSQL allows potential unauthorized database access
Read more
Wiz Code and SLSA
Wiz supports organizations in aligning with the SLSA framework by enhancing software supply chain security across cloud environments. Wiz provides agentless, continuous visibility and security for cloud-native infrastructure, helping organizations meet SLSA requirements from code to runtime.
1. SLSA Level 1 & 2: Visibility and Transparency
Software Composition Analysis (SCA): Wiz detects open-source vulnerabilities and dependencies in cloud workloads, IaC templates, and container images, giving visibility into the components of your software supply chain.
Code Scanning (Wiz Code): Wiz integrates with CI/CD pipelines and performs real-time scanning for vulnerabilities, misconfigurations, and secrets in code, aligning with early-stage supply chain security requirements.
2. SLSA Level 3: Strengthening Build Integrity
CI/CD Security: Wiz monitors CI/CD environments for misconfigurations and risks, such as exposed secrets, insecure pipelines, and untrusted artifacts.
Artifact Verification: Wiz ensures that only verified and secure artifacts are deployed in cloud environments by continuously monitoring runtime and infrastructure for deviations.
3. SLSA Level 4: End-to-End Supply Chain Security
Shift-Left Security: Wiz supports shift-left practices by detecting vulnerabilities and compliance risks early in the development lifecycle.
Policy-as-Code: Helps enforce security and compliance policies across the software development lifecycle, reducing the risk of supply chain attacks.
Runtime Security: With Wiz Runtime Protection, organizations can monitor live environments to detect and respond to malicious activity or anomalies.
Secure Every Stage of the SDLC
Learn how Wiz is solving security challenges of Developer and DevSecOps team.
