SLSA (Supply-chain Levels for Software Artifacts)

SLSA (Supply-chain Levels for Software Artifacts) represents one of the most comprehensive approaches to securing modern software development pipelines. Created by Google and now maintained by the OpenSSF (Open Source Security Foundation), this framework addresses the growing threat of supply chain attacks by establishing clear, measurable security standards for software artifacts. For DevSecOps teams and security leaders managing complex development environments, understanding and implementing SLSA provides a structured path toward building more secure and trustworthy software delivery processes.

What is SLSA (Supply-chain Levels for Software Artifacts)?

SLSA is a security framework that provides organizations with a standardized approach to verifying and securing their software supply chain. The framework establishes four progressive maturity levels, each building upon the previous one to create increasingly robust security guarantees. Unlike many security frameworks that remain theoretical or difficult to implement, SLSA focuses on practical, actionable requirements that development teams can adopt incrementally.

The framework emerged from Google's internal "Binary Authorization for Borg" system, which the company developed after experiencing and observing various supply chain compromises. By sharing this knowledge with the broader software community, Google and the OpenSSF have created a standardized vocabulary and set of controls that organizations of any size can use to improve their software supply chain security posture.

At its core, SLSA addresses a fundamental question that every software organization faces: How can we trust that the software we're building, deploying, or consuming hasn't been tampered with during the development and delivery process? This question has become increasingly critical as supply chain attacks like SolarWinds, Codecov, and numerous npm package compromises have demonstrated the devastating impact of compromised build systems and artifact repositories.

‍

Understanding the Definition of SLSA Security Levels

The SLSA framework defines four distinct levels of supply chain security maturity, each representing a significant step toward complete supply chain integrity. These levels aren't just arbitrary checkpoints—they represent meaningful security improvements that directly address real-world attack vectors.

SLSA Level 1: Build Provenance Documentation

Level 1 establishes the foundation by requiring basic documentation of the build process. At this level, organizations must generate provenance metadata that describes how an artifact was built, including information about the build process, source repository, and build commands. This provenance must be stored separately from the artifact itself and should be available for verification.

Think of Level 1 as creating a receipt for your build process. Just as a receipt proves you purchased an item from a legitimate store, build provenance proves your artifact came from a documented, known build process. This level doesn't prevent attacks, but it creates visibility that makes tampering detectable and helps organizations respond more effectively when incidents occur.

For teams just starting their supply chain security journey, Level 1 represents an achievable first step that requires minimal infrastructure changes. Many modern CI/CD platforms now include built-in support for generating SLSA Level 1 provenance, making adoption relatively straightforward for organizations already using these tools.

SLSA Level 2: Tamper-Resistant Build Provenance

Level 2 increases security by requiring that provenance metadata be generated by the build service itself rather than by the build script. This distinction is critical because it prevents attackers who compromise the build script from forging provenance. The build service must sign the provenance cryptographically, and the signing must occur in a way that the build script cannot influence.

This level addresses scenarios where an attacker gains control of the source repository or build configuration. Even if they modify the build process, they cannot create valid provenance that claims the malicious artifact came from a legitimate build. The separation between the build execution environment and the provenance generation creates a trust boundary that's much harder to compromise.

Reaching Level 2 typically requires organizations to use build platforms that support service-generated provenance. Many enterprise CI/CD systems have added this capability specifically to support SLSA compliance, recognizing the growing demand for supply chain security controls.

SLSA Level 3: Hardened Build Platform with Provenance

Level 3 introduces significant platform hardening requirements. The build platform must provide isolation between different builds, preventing one build from accessing or modifying another. The platform must also be resistant to compromise, with security controls that prevent unauthorized changes to the build infrastructure itself.

At this level, the source and build platform must be strongly linked, meaning that provenance must accurately identify the exact source code that was built. This prevents "source substitution" attacks where an attacker tricks the build system into building malicious code while generating provenance that points to legitimate source code.

Organizations working toward Level 3 need to carefully evaluate their build infrastructure. Self-hosted CI/CD systems may require substantial hardening, while managed build services often provide Level 3 capabilities out of the box. This is where many organizations begin to see the value of using specialized secure build platforms or managed services that were designed with supply chain security in mind.

SLSA Level 4: Hermetic and Reproducible Builds with Two-Party Review

Level 4 represents the highest level of supply chain assurance. At this level, builds must be hermetic, meaning they're completely isolated from external influence during execution. All build dependencies must be explicitly declared and immutable, preventing attackers from injecting malicious code through dependency confusion or substitution attacks.

Builds must also be reproducible, meaning that building the same source code with the same build configuration produces bit-for-bit identical outputs. Reproducibility provides a powerful verification mechanism—if two independent parties build the same source and get different results, it indicates potential tampering or non-determinism that could hide attacks.

Level 4 also requires two-party review of all changes before they're accepted into the source repository. This human element creates another layer of defense, making it much harder for a single malicious insider or compromised account to inject backdoors into the codebase. The combination of technical controls and process requirements at Level 4 creates an extremely robust security posture that even sophisticated nation-state attackers would struggle to compromise undetected.

‍

Explanation of SLSA's Technical Components

Understanding SLSA requires familiarity with several key technical concepts that form the foundation of the framework. These components work together to create a complete system for supply chain security.

Build Provenance and Attestations

Build provenance is structured metadata that describes how a software artifact was created. This metadata includes information about the build process, the source code that was built, the build commands executed, and the environment where the build occurred. Provenance is expressed as a signed attestation using the in-toto format, which provides a standardized way to represent supply chain metadata.

Attestations serve as unforgeable statements about the software supply chain. Because they're cryptographically signed, consumers can verify that the attestation came from a trusted builder and hasn't been modified. This signature chain creates a web of trust that extends from the source repository through the build process to the final deployed artifact.

For organizations implementing SLSA, generating and managing attestations represents one of the primary technical challenges. Teams need infrastructure to generate attestations during builds, store them securely, and make them available for verification during deployment. Many organizations integrate attestation generation directly into their CI/CD pipelines, treating it as a standard part of the build process rather than an afterthought.

Build Platforms and Isolation

The build platform plays a central role in SLSA, as it's responsible for executing builds and generating trustworthy provenance. A SLSA-compliant build platform must provide strong isolation guarantees, preventing builds from interfering with each other or with the platform infrastructure itself.

Platform isolation typically involves containerization, virtualization, or other sandboxing technologies that create boundaries between different build executions. The platform must also protect its own integrity, preventing unauthorized modifications to the build system that could compromise the trustworthness of generated provenance.

Organizations evaluating build platforms for SLSA compliance should assess both the technical isolation mechanisms and the operational security controls. A platform might provide strong technical isolation but still be vulnerable if administrators can easily modify its configuration or if its signing keys aren't properly protected.

Source Platform Requirements

The source repository represents the starting point of the software supply chain, and SLSA places specific requirements on source platforms at higher levels. These requirements ensure that the source code referenced in provenance is authentic and hasn't been tampered with after the fact.

Source platforms must provide strong authentication for contributors, maintain an immutable audit log of changes, and support access controls that prevent unauthorized modifications. At Level 4, the requirement for two-party review means the source platform must enforce policies that prevent any single individual from merging changes without approval from at least one other authorized reviewer.

Most modern version control systems like GitHub, GitLab, and Bitbucket provide the necessary capabilities to meet SLSA source platform requirements, though organizations need to configure them correctly and enforce appropriate policies through branch protection rules and required reviews.

‍

How to Implement SLSA in Your Organization

Implementing SLSA is a journey that organizations should approach incrementally. Attempting to jump directly to Level 4 is neither practical nor necessary for most teams. Instead, a phased approach allows organizations to realize security benefits quickly while building toward higher maturity over time.

Assessing Your Current State

Before implementing SLSA controls, organizations need to understand their current software supply chain security posture. This assessment should map out the entire path from source code to production deployment, identifying all the systems, processes, and people involved in building and delivering software.

Key questions to answer during assessment include: How do we currently build software? Where do our build dependencies come from? Who has access to modify build configurations? How do we verify that deployed artifacts match what was built? What existing security controls do we have in place? This assessment often reveals gaps and risks that organizations weren't previously aware of, making it valuable even before implementing any SLSA controls.

Starting with SLSA Level 1

Most organizations should begin their SLSA journey by working toward Level 1 compliance. This involves implementing basic provenance generation for software builds. Many CI/CD platforms now include built-in support for generating SLSA provenance, making Level 1 achievable with relatively minor changes to existing pipelines.

The key tasks for Level 1 implementation include:

• Selecting a provenance format and generation tool compatible with your build system
• Modifying build pipelines to generate provenance for each build
• Establishing storage for provenance metadata that keeps it associated with corresponding artifacts
• Creating processes for consuming and verifying provenance during deployment

Teams implementing Level 1 often start with a pilot project rather than attempting to convert all build pipelines at once. This approach allows them to work through technical challenges and refine their processes before scaling across the organization.

Progressing to Higher SLSA Levels

After achieving Level 1, organizations can evaluate whether progressing to higher levels makes sense for their security requirements and risk tolerance. Not every artifact needs to reach Level 4—organizations can apply higher levels selectively to their most critical components while maintaining lower levels for less sensitive code.

Reaching Level 2 typically requires upgrading to build platforms that support service-generated provenance. This might involve migrating from self-hosted CI/CD systems to managed services, or upgrading self-hosted systems with plugins or extensions that add SLSA support.

Level 3 and Level 4 represent more substantial undertakings that require significant platform hardening and process changes. Organizations pursuing these levels often do so because they're building particularly sensitive software, operating in highly regulated industries, or want to provide maximum assurance to their customers about software integrity.

‍

Benefits of Adopting SLSA Framework

Organizations that invest in SLSA implementation realize multiple benefits beyond just improved security. Understanding these benefits helps justify the investment required to adopt the framework and maintain compliance over time.

Protection Against Supply Chain Attacks

The most obvious benefit of SLSA is protection against various supply chain attack vectors. By implementing SLSA controls, organizations make it substantially harder for attackers to inject malicious code into software artifacts. Even if attackers compromise parts of the build infrastructure, SLSA's layered defenses prevent them from creating valid provenance for malicious artifacts or from tampering with builds without detection.

This protection extends to both external attacks and insider threats. The requirement for two-party review at Level 4 specifically addresses the risk of malicious insiders, while lower levels provide protection against compromised credentials or vulnerable build scripts that external attackers might exploit.

Improved Incident Response Capabilities

When security incidents occur, SLSA's provenance metadata becomes invaluable for investigation and response. Teams can quickly determine which artifacts might be affected by a compromise, trace artifacts back to specific source code versions, and verify whether deployed software was built through legitimate processes.

This visibility dramatically reduces the time required to respond to incidents. Rather than spending days or weeks trying to reconstruct what happened, teams can query provenance data to get immediate answers about which builds occurred when, what source code they used, and whether they followed expected processes.

Enhanced Trust and Transparency

Organizations that achieve SLSA compliance can demonstrate to customers, partners, and regulators that they take software supply chain security seriously. The framework provides an objective, measurable way to communicate security posture rather than relying on vague assurances.

For software vendors, SLSA compliance can become a competitive differentiator. Customers increasingly care about supply chain security, and being able to provide SLSA provenance with software builds demonstrates a commitment to security that can help win business, particularly in regulated industries or when selling to security-conscious enterprises.

‍

Challenges in SLSA Implementation

While SLSA provides substantial benefits, organizations should be aware of the challenges they'll face during implementation. Understanding these challenges helps teams plan appropriately and avoid common pitfalls.

Technical Complexity and Tool Maturity

The SLSA ecosystem is still evolving, and tool support varies significantly across different technology stacks. Organizations using popular platforms like GitHub Actions or Google Cloud Build may find good SLSA support, while those using less common build systems might need to build custom solutions or wait for vendor support to mature.

Generating provenance is only half the challenge—organizations also need infrastructure to store, distribute, and verify provenance. Building these capabilities requires expertise in cryptographic signatures, artifact management, and distributed systems that not all teams possess.

Operational Overhead

SLSA compliance introduces new operational requirements that teams must manage. Signing keys need to be protected and rotated. Provenance storage needs to be maintained and backed up. Verification processes need to be integrated into deployment pipelines. Each of these adds complexity to already complex development and deployment workflows.

Organizations need to account for this overhead when planning SLSA adoption. The framework isn't just a one-time implementation—it requires ongoing maintenance and attention to remain effective. Teams should ensure they have adequate resources and expertise to maintain SLSA infrastructure before committing to higher maturity levels.

Organizational Change Management

Implementing SLSA often requires changes to established development processes. Developers may need to adapt to new tools and workflows. Security teams need to learn new concepts and technologies. Operations teams must integrate provenance verification into deployment processes.

These changes can encounter resistance, particularly if teams perceive them as slowing down development or adding bureaucracy. Successful SLSA adoption requires clear communication about why the changes matter, training to help teams adapt, and executive support to drive the necessary organizational changes.

‍

SLSA and Related Security Frameworks

SLSA doesn't exist in isolation—it's part of a broader ecosystem of supply chain security frameworks and standards. Understanding how SLSA relates to other initiatives helps organizations build comprehensive security programs rather than implementing controls piecemeal.

Software Bill of Materials (SBOM)

SBOMs provide detailed inventories of software components, while SLSA provides assurance about how those components were built. These frameworks complement each other—an SBOM tells you what's in your software, while SLSA tells you that what's in your software is what you expected to build.

Organizations often implement both SBOM generation and SLSA provenance as part of comprehensive supply chain security programs. The provenance can reference an SBOM as one of the build outputs, creating a complete record of both the build process and the resulting artifact composition.

NIST Secure Software Development Framework (SSDF)

The NIST SSDF provides high-level practices for secure software development, while SLSA provides specific technical controls for supply chain security. SLSA can be viewed as one way to implement several SSDF practices related to protecting software integrity and ensuring provenance.

Organizations working to comply with SSDF requirements, particularly those mandated by executive orders or regulations, often adopt SLSA as a concrete implementation approach for supply chain-related practices.

Sigstore and Code Signing

Sigstore is an open-source project that provides free code signing services, making it easier for developers to sign and verify software artifacts. Many SLSA implementations use Sigstore components like Cosign for signing provenance attestations, as Sigstore's keyless signing reduces the operational burden of managing signing keys.

The relationship between SLSA and Sigstore is symbiotic—SLSA defines what should be signed and attested, while Sigstore provides accessible tooling for performing those signatures. Together, they make supply chain security more achievable for organizations that lack sophisticated cryptographic infrastructure.

‍

Real-World Applications of SLSA

Understanding how organizations apply SLSA in practice helps clarify the framework's value and provides guidance for implementation. While each organization's journey is unique, common patterns have emerged as adoption has grown.

Open Source Projects and SLSA

Many high-profile open source projects have adopted SLSA to provide stronger security guarantees to their users. When maintainers of widely-used libraries implement SLSA, it creates a ripple effect that improves security for all downstream consumers of those projects.

Open source projects often start with Level 1 or Level 2, as these levels are achievable with free CI/CD services like GitHub Actions. Projects that reach higher levels typically do so with support from corporate sponsors who provide infrastructure and expertise. The OpenSSF provides resources and guidance specifically to help open source maintainers adopt SLSA without requiring significant financial investment.

Enterprise Software Development

Enterprise organizations use SLSA to secure internal software development and meet compliance requirements. For companies in regulated industries like finance or healthcare, SLSA provides a structured approach to demonstrating software supply chain controls to auditors and regulators.

Large enterprises often implement SLSA selectively, focusing first on critical systems like authentication services, payment processing, or systems that handle sensitive data. This risk-based approach allows them to achieve security benefits for high-priority systems while working toward broader adoption over time.

Cloud Native and Kubernetes Environments

Organizations building cloud-native applications increasingly incorporate SLSA into their container build and deployment pipelines. Container images represent a particularly important artifact to protect, as compromised images can lead to widespread security issues when deployed across Kubernetes clusters.

Tools like Kubernetes security platforms often integrate SLSA verification, allowing organizations to enforce policies that only permit deployment of containers with valid provenance. This integration of SLSA into cloud-native infrastructure creates automated enforcement of supply chain security controls.

‍

The Future of SLSA and Supply Chain Security

SLSA continues to evolve as the broader supply chain security landscape matures. Understanding where the framework is heading helps organizations plan their adoption strategies and prepare for upcoming changes.

Growing Adoption and Standardization

SLSA adoption is accelerating as supply chain attacks continue to make headlines and as tooling matures. The framework is becoming a de facto standard for supply chain security, with increasing support from major technology vendors and cloud providers. This growing adoption creates positive network effects—as more organizations implement SLSA, it becomes easier for everyone else to adopt because tools and expertise become more widely available.

Standards bodies and regulatory agencies are beginning to reference SLSA in their guidance and requirements. This trend will likely continue, potentially leading to mandatory SLSA compliance for certain types of software or organizations. Companies that adopt SLSA proactively will be better positioned when such requirements emerge.

Tooling Evolution and Integration

The SLSA tooling ecosystem is rapidly evolving. Build platforms are adding native SLSA support, making it easier to generate compliant provenance without custom scripting. Artifact repositories are adding support for storing and serving provenance alongside artifacts. Deployment tools are incorporating provenance verification to prevent deployment of unverified software.

This tooling maturation is reducing the technical barriers to SLSA adoption. Tasks that required custom development a year ago now have turnkey solutions available. This trend will continue, making SLSA accessible to increasingly smaller organizations and less sophisticated development teams.

Expansion Beyond Software Artifacts

While SLSA currently focuses on software artifacts, the principles could extend to other types of digital artifacts like machine learning models, infrastructure-as-code configurations, or data pipelines. The framework's core concepts of provenance, verification, and graduated maturity levels apply broadly to any scenario where you need to trust the integrity of digital artifacts.

Some organizations are already applying SLSA concepts to these adjacent domains, even though formal extensions to the specification haven't been finalized. This experimentation will likely inform future versions of SLSA that explicitly address these use cases.

‍

Securing Your Software Supply Chain with SLSA

For organizations serious about protecting their software supply chain, SLSA provides a practical, proven framework that addresses real security risks. The graduated approach allows teams to start small and build toward higher maturity as their capabilities and needs evolve. While implementation requires investment in tooling, process changes, and skills development, the security benefits and improved incident response capabilities justify this investment for most organizations.

Success with SLSA requires commitment from leadership, collaboration across development and security teams, and patience to work through technical challenges as you build new capabilities. Organizations that approach SLSA adoption strategically—starting with high-priority systems, learning from early implementations, and scaling gradually—tend to achieve better outcomes than those that attempt wholesale transformation.

The framework's growing adoption means that organizations implementing SLSA today are positioning themselves well for a future where supply chain security controls become standard expectations from customers, partners, and regulators. Getting started now, even at Level 1, creates momentum and builds organizational knowledge that will prove valuable as requirements evolve.

Ready to strengthen your software supply chain security? Request a demo to see how Kusari can help your organization implement SLSA controls and achieve supply chain security at scale.

‍

What Are the Key Differences Between SLSA Levels?

The key differences between SLSA levels relate to the strength of security guarantees each provides. SLSA Level 1 requires basic provenance documentation but doesn't prevent tampering—it simply creates visibility into the build process. Level 2 prevents tampering with provenance itself by requiring the build service to generate and sign attestations rather than relying on build scripts. Level 3 adds platform hardening requirements that prevent cross-build tampering and ensure strong source-to-build linkage. Level 4 introduces hermetic builds, reproducibility, and two-party review to create the highest level of assurance against sophisticated attacks. Each level builds incrementally on previous levels, creating progressively stronger supply chain security guarantees.

How Long Does It Take to Implement SLSA?

The time required to implement SLSA varies significantly based on your starting point, target level, and organizational complexity. Achieving SLSA Level 1 for a small number of builds can take just a few days if you're using a build platform with native provenance support. Scaling Level 1 across an entire organization typically takes several months as teams work through technical integration challenges and process changes. Reaching Level 2 or Level 3 usually requires several months to a year, depending on whether your build infrastructure already meets platform requirements or needs substantial modification. Level 4 implementation typically takes a year or more, as it requires significant changes to build infrastructure, development processes, and organizational practices. Organizations should plan for phased rollouts rather than attempting to achieve high SLSA levels immediately.

Does SLSA Replace Other Security Practices?

SLSA does not replace other security practices—it complements them by specifically addressing supply chain integrity. Organizations still need practices like code review, vulnerability scanning, penetration testing, and security monitoring. What SLSA provides is assurance that the software you built is the software you intended to build and that it hasn't been tampered with during the build and delivery process. This fills a critical gap that traditional security practices don't address. For example, code review ensures the source code is secure, but doesn't prevent an attacker from modifying binaries after the code review occurs. SLSA's provenance and verification mechanisms protect against such post-review tampering. The most effective security programs combine SLSA with traditional security practices to create defense in depth.

What Tools Support SLSA Implementation?

A growing ecosystem of tools supports SLSA implementation across different parts of the supply chain. Build platforms like GitHub Actions, GitLab CI, and Google Cloud Build now include native support for generating SLSA provenance. The SLSA GitHub Generator provides reusable workflows that make it easier to achieve Level 3 builds on GitHub. Sigstore's Cosign tool handles signing and verification of provenance attestations. The in-toto framework provides the underlying attestation format that SLSA uses. For artifact storage, container registries like Google Artifact Registry and GitHub Container Registry support storing provenance alongside artifacts. Build tools like Bazel and go build have added features to support reproducible builds required for Level 4. Organizations can also use supply chain security platforms that provide integrated SLSA implementation and verification across their entire development pipeline. The tool landscape continues evolving rapidly as SLSA adoption grows.

Building Resilient Software Supply Chains with SLSA

Software supply chain security has emerged as one of the most critical challenges facing development organizations today. Attackers have recognized that compromising the software supply chain often provides easier access to targets than attacking production systems directly. SLSA (Supply-chain Levels for Software Artifacts) offers a pragmatic, well-defined path toward addressing these risks through graduated levels of security controls that organizations can implement incrementally. By providing verifiable provenance, preventing tampering, and creating transparency throughout the build process, SLSA enables organizations to build and deliver software with confidence that it hasn't been compromised. The framework's growing adoption, improving tool support, and recognition from standards bodies make it an increasingly important part of modern security programs. Organizations that invest in SLSA today are not just improving their current security posture—they're preparing for a future where supply chain security assurance will be expected by customers and required by regulations, making SLSA (Supply-chain Levels for Software Artifacts) an essential capability for any organization that builds or distributes software.