Is SLSA the Best Standard for CI/CD Pipelines?

Quick Answer: SLSA (Supply-chain Levels for Software Artifacts) is a security framework that helps protect CI/CD pipelines by creating build processes that can be verified and also tracks the software’s authenticity. Whether or not it's the "best" depends on your situation.  

CI/CD pipelines are right at the center of modern software development and DevOps. They automate everything from code commits to deploying apps into production. But, as expected, they've become targets for attackers who try to inject malicious code into the software supply chain.

And that's where SLSA comes in. This framework aims to secure your CI/CD pipelines and enhance the security of your software supply chain. This is a great idea, but is SLSA the best standard for CI/CD pipelines? Like most solutions, it will depend on what you're trying to protect and how complicated you want your deployment setup to be.

Let’s find out what SLSA actually does, and if it's the right fit for your software development tasks.

What is SLSA?

SLSA stands for Supply-chain Levels for Software Artifacts. It was originally developed by Google and is based on their internal "Binary Authorization for Borg" system. SLSA has evolved over time and is now governed by the Open Source Security Foundation (OpenSSF). It’s a vendor-neutral standard recognized across the industry.

SLSA is like a chain of custody for your code. Every step, from source code to the final compiled artifact, is documented and verified through something called cryptographically signed attestations. This means that if someone tries to slip malicious code into your build process, SLSA will help you catch it before it makes it to production.

Understanding SLSA's Architecture: Tracks and Provenance

SLSA uses a concept called "Tracks" to separate different parts of the supply chain security. The current stable version (v1.0/v1.1) focuses on the Build Track, which is the Track that keeps the build process secure. Future versions will add a Source Track for source code management and possibly other specialized tracks as well.

The primary feature of SLSA is provenance, which essentially records the origin of something. This provenance is verifiable metadata that acts like a birth certificate for your software. This data gets packaged into those cryptographically signed attestations that we mentioned earlier, and it uses the in-toto format. This creates records that can tell if they have been changed or tampered with, and how your artifacts were built.

How SLSA Build Track Levels Actually Work

The current SLSA specification has a three-level Build Track system, which consists of:

• SLSA Build Level 1: Focuses on documentation and transparency. To pass, your build process must be fully scripted, and you need to generate provenance metadata for all of your artifacts. The provenance doesn’t have to be signed at this level, so it isn’t the most secure measure against tampering; however, it provides good documentation.

• SLSA Build Level 2: This track adds tamper resistance. Your builds must run on a hosted platform (not a developer's laptop), and the build service must cryptographically sign the provenance. This stops attackers from forging provenance after the build is finished.

• SLSA Build Level 3: The highest level in the latest SLSA standard. It requires a "hardened" build platform that separates different builds from each other and keeps signing keys separate from certain user build steps. This prevents attacks from happening during the build process.

The best part of this system is that you can start small and work your way up. You don't need to jump straight to Level 3 and freak your team out. 

Why Do CI/CD Pipelines Need Security Standards?

Your CI/CD pipeline is basically a highway that connects your source code to your production systems. Without proper security, that highway has on-ramps for attackers to access your data on.

Common pipeline vulnerabilities include:

• Dependency Poisoning: When attackers manage to compromise the libraries that your code uses when it is compiled. If your app builds with a malicious package, then it can infect everything downstream from or allow access to your application through a potential backdoor.

• Build Environment Compromise: Occurs when attackers get access to your build servers. They can inject code, steal secrets, or change your final artifacts and not leave any traces.

• Supply Chain Attacks: These target the tools and services that your development processes use. Think of the infamous SolarWinds hack from a few years ago. That all started with a compromised build system.

• Weak Access Controls: These can allow unauthorized individuals to modify build configurations or deploy code to production systems with incorrect settings or compromised security.

Why Standards Matter

Standards like SLSA provide a roadmap to work towards, helping you avoid vulnerabilities. Instead of guessing what security measures you need, you get a list of specific requirements and best practices for deploying your software.

There are also other frameworks out there, like OWASP SAMM. It also focuses on secure development practices, but has a few differences when compared to SLSA. Another standard is ISO/IEC 27001, which covers information security management more broadly. What makes SLSA different is that it specifically targets the software supply chain, so it’s more focused than these other alternatives.

What are the Key Benefits of Using SLSA for CI/CD Pipelines?

SLSA has advantages that can make your development process more secure and trustworthy than other frameworks.

Enhanced Integrity and Traceability

Every artifact created by your pipeline comes with a detailed provenance statement. This tells you exactly what source code, dependencies, and build tools you used to create that artifact. If something goes wrong, you can trace the problem back to its source.

This means that you'll know if someone changed your code after it left your repo. You'll also catch unauthorized changes to your build environment or dependencies before the software is even deployed.

Transparency That Builds Trust

SLSA generates detailed logs that encompass your entire build process. Your security team can audit these logs to make sure that everything went according to plan. Customers and partners can also verify that your software meets their security standards if they have special requirements.

This transparency is really valuable when you're working with regulated industries or customers that require rigorous security and provide proof that your software is safe from start to finish.

Scalability Across Different Pipeline Types

SLSA isn’t a fixed and rigid standard; it can be adapted to work as you need it to. You can use it if you're running a basic CI/CD setup or a complex multi-service architecture. Levels lets you choose the security that suits your approach without overcomplicating your pipelines if they don’t need it.

Small teams can start with Level 1 and add more security as needed. Bigger organizations can use higher levels for live systems and use lower levels for internal tools that aren’t exposed to the internet.

Industry Recognition and Platform Support Reality Check

SLSA is used quite widely, but native platform support isn’t a given. Here are some platforms that implement SLSA in different ways:

• GitHub Actions: Provides native support for SLSA, featuring reusable workflows that can automatically generate SLSA Build Level 3 attestations. They also handle the signing infrastructure through Sigstore. The OpenSSF maintains the official tooling like the slsa-github-generator so implementation is relatively straightforward.

• Google Cloud Build: Offers excellent native support (no surprise since Google had a major part in making SLSA in the first place). Their platform can automatically generate verifiable SLSA Level 3 provenance for container images with minimal configuration.

• Microsoft Azure DevOps: Not as SLSA-friendly. Azure doesn’t currently have native first-party support for generating SLSA attestations. There is a proof-of-concept demo repo though, but it's marked as "not intended for production", and it only gets to Level 1. If you need SLSA on Azure right now, then it needs third-party tools like Cimon, or you’ll have to build a custom solution.

If you're using GitHub or Google Cloud, achieving SLSA Level 3 is simply a matter of configuring a few key features. If you're on Azure, then things can get quite complicated.

What Problems Might You Run Into with SLSA?

As good as SLSA is, it isn't perfect. It has some issues that you should consider before entering the fray.

SLSA Hurdles

SLSA has many moving parts, and its complexity changes depending on your target Level and the platform you’re on. A 2024 academic analysis of over 1,500 SLSA-related GitHub issues found two main ones: confusion over implementation requirements and hazy details about the specifications themselves.

Higher SLSA levels require more changes to your development workflow, such as incorporating new tools and adopting different build techniques to make it work. Level 3 implementations can take months to develop properly, especially if you're building something custom, due to the extra security controls that need to be implemented.

Resource and Needed Skills

SLSA requires individuals with expertise in security and software development. Maintenance can also get complicated when there are version updates or changes to your packages and software. You'll need to monitor compliance, update security controls, and deal with new threats when they arrive. This all takes time and can get expensive if you need to hire specialised staff to help maintain your solution.

Focused but Limited Scope

SLSA is great at supply chain security, but it doesn't cover everything related to your pipeline security. You'll still need separate solutions for secrets management and runtime security, and additional steps are required for tasks such as infrastructure protection and code quality scanning.

SLSA focuses on the artifacts themselves, so external frameworks will need to handle network security, access management, and other infrastructure issues.

What are the Alternatives to SLSA for CI/CD Pipeline Security?

We looked at some SLSA alternatives a little earlier, so we know that it isn't your only option for securing CI/CD pipelines. The important thing is that frameworks like these work together and don’t really compete with each other.

NIST Secure Software Development Framework (SSDF)

The NIST SSDF provides highly detailed governance guidance to secure the entire software development lifecycle. It tells you what you should do (like "collect and safeguard provenance data") but doesn't tell you how to go about implementing it. SLSA is the piece of the puzzle that gives the specific technical controls to accomplish SSDF's requirements for build and artifact integrity.

OWASP SAMM (Software Assurance Maturity Model)

OWASP SAMM helps organizations assess and improve their overall software security posture throughout the entire development process. It covers practices like threat modeling, security testing, and strategy, so it’s much broader than SLSA. If you implemented SLSA, then it would actually help you increase your SAMM maturity score in certain areas.

DevSecOps Principles and Practices

DevSecOps integrates security at every step of development. SLSA fits perfectly because of its controls that automate and apply supply chain security.

The Real Relationship is Complementary, Not Competitive

These frameworks work best when they are combined. An example of a well-developed security program could use NIST SSDF for governance, OWASP SAMM for maturity assessments, and SLSA for technical artifact integrity controls. And they would do all of this while adhering to DevSecOps culture, providing you with different features from various components throughout the software development life cycle.

How to Decide if SLSA is Right for Your CI/CD Pipeline

Like most complicated technical processes, your specific situation and goals will help you decide whether SLSA is right for you. Here's how to decide: 

Look at Your Platform's Native Capabilities First

This is the most important step. Your CI/CD platform will be the component that determines the cost and complexity of achieving higher SLSA levels—and whether it is even feasible. If you're using GitHub or Google Cloud, then Level 3 is doable with their built-in features. If you're on Azure DevOps, then you'll need to use third-party tools or develop something custom, which has costs.

Start Small with Level 1

Level 1 is technically possible for almost any organization if you focus on scripting your build process completely and generating basic provenance metadata. This step has instant benefits, such as better documentation and software inventory tracking.

Plan Your Level 2/3 Strategy Based on Platform

• For GitHub and Google Cloud users: Utilize the native builders and reusable workflows that these platforms offer. Think about implementing Level 3 for important software projects using the built-in signing infrastructure, where this type of security really counts.

• For Azure DevOps users: Look at those third-party tools very carefully. Think about the total cost of ownership, including things like ongoing maintenance. You might also need to think about whether migrating critical builds to a platform with native support would make more business sense than trying to shoehorn a third-party solution into the mix.

Don't Forget Verification

Creating provenance for your software is only half the battle. The real security benefits come from validating those attestations in your deployment pipelines. Use tools like the official SLSA-verifier and configure your deployments to fail if verification fails. Another reminder of our earlier example: the 2020 SolarWinds attack, where attackers injected malicious code through the build system, could have been prevented by SLSA Level 3's hardened build requirements if they had been in place.

Conclusion

SLSA brings real benefits to CI/CD pipeline security, especially for preventing supply chain attacks and build tampering. It's one of the leading technical standards for keeping artifact integrity, and it fills an important gap that most security programs have.

But we need to remember that SLSA isn't an entire CI/CD security solution. It doesn't handle secrets management, runtime security, or protect your infrastructure. The smartest approach is a combination of SLSA's technical controls with governance frameworks, like NIST SSDF, and other security best practices. Start by assessing your current platform's native features and let that help determine your implementation path.

If you're serious about supply chain security and have the platform support to implement it effectively, then SLSA should be part of your security toolkit. Just remember that it's one piece of a bigger puzzle, and not a complete solution.

Ready to learn more about securing your development pipeline? The DevOps Tools Engineer training covers the practical skills you need to implement security frameworks like SLSA in real-world environments.