7 Ways to Use the SLSA Framework to Secure the SDLC

In a world where codebases are prime targets, the SLSA Framework hardens every link in the software supply chain. By establishing precise, tiered security requirements and actionable guidelines, SLSA can help your organization operationalize its security efforts and systematically strengthen the development process. The principle is simple: build integrity at every stage. 

High-profile breaches have shown just how fragile the software development lifecycle can be, as cybercriminals exploit vulnerabilities and introduce malicious code into trusted environments.  Despite 45% of organizations boosting security spending after incidents like SolarWinds, only 38% feel adequately resourced to combat these threats. There’s a clear gap between financial investment and steadfast commitment to securing the SDLC. 



What is the SLSA Framework?

The Software Development Lifecycle Assurance (SLSA) framework is a set of practices to secure software artifacts - like code, binaries, or container images- throughout the SDLC. Initially championed by Google, it was born from the growing need for a standardized approach to protecting the software supply chain. 

These practices are organized by levels, which set the standard these artifacts need to meet to ensure software integrity and security. Each level of SLSA builds on the previous one, providing increased protection against supply chain risks:

• SLSA Level 1: Basic Security Practices – Establishes a structured build process with basic logging. It suits teams starting their supply chain security efforts by capturing build steps and gaining process visibility. While simple, it’s crucial for creating a consistent build baseline, enabling teams to start tracking and identifying unexpected variations in the build process. 
• SLSA Level 2: Source Integrity—At this level, source code integrity becomes the focus through version control and cryptographic signatures. By ensuring that each code commit is traceable and securely signed, Level 2 helps prevent tampering and provides accountability. It is ideal for teams using open-source dependencies or collaborating across distributed environments. 
• SLSA Level 3: Auditable Build Pipelines—This requires isolated, tamper-proof build environments with full auditability. Builds must occur in secure, fully isolated environments to prevent dependency pollution and unauthorized changes. It is critical for regulated industries that need strict traceability of build artifacts and compliance with security standards.
• SLSA Level 4: Reproducible, Automated Builds—This level is centered around end-to-end consistency. Maximum security is achieved when builds are carefully reproducible and automated security checks are in place. High-risk sectors must guarantee consistent and verified software artifacts across builds, whether they are built today or rebuilt in the future.

SLSA is uniquely positioned to help you achieve scalable DevOps security.  Unlike general security frameworks, SLSA specifically addresses risks inherent to building pipelines and dependencies, which are frequent targets in DevOps workflows. SLSA’s tiered levels offer a clear roadmap for organizations at different maturity stages to harden their development processes. This flexibility, combined with its focus on automating critical security tasks, makes SLSA an emerging industry standard across finance and critical infrastructure sectors.



Benefits of Using SLSA in the SDLC

With SLSA, security gets baked into every step, making it easier to stay ahead of threats without slowing you down. Here’s how this framework takes the heavy lifting out of securing your software supply chain:

• Blocking Supply Chain Tampering: Controls are in place at every stage to detect and stop malicious changes, preventing threats like compromised components or unauthorized code from entering the process.
• Protecting Source Code Integrity: Cryptographic signing and strict access controls keep code unchanged from commit to deployment, avoiding unintended or unauthorized modifications.



• Verifying Artifact Authenticity: You can trace each software artifact back to its source, ensuring only trusted, verified components are used in production and minimizing risks from third-party dependencies.
• Automating Security Checks: Security tasks like static analysis and vulnerability scanning are seamlessly integrated into the pipeline, maintaining robust security without slowing development.
• Simplifying Compliance: The framework’s automated processes align with regulatory standards, streamlining audit trails and making meeting ISO 27001 or SOC2 compliance requirements easier.
• Building Trust in Releases: Transparent and auditable processes keep software releases secure, reducing the risk of tampering or hidden vulnerabilities and providing confidence in the reliability of the final product.

7 Ways to Use the SLSA Framework to Secure the SDLC

1. Enforce Source Code Integrity

With SLSA, you can require cryptographic signatures for commits, ensuring only approved changes make it into the codebase. You can implement this by requiring GPG-signed commits in Git and authenticating each contribution to the main branch. Jit can take this a step further by scanning for misconfigurations in GitHub pipelines, catching loose permissions or misaligned settings that could make your code more vulnerable.



Integrating static analysis tools like Semgrep or Gosec into your CI/CD pipeline helps detect insecure code patterns early. For instance, Semgrep scans for security issues like XSS and SQL injection, applying coding standards like OWASP Top 10 or CIS security controls. 

2. Automate Security in the Build Pipeline

SLSA Level 3 mandates a fully traceable build process, where security checks are integrated at every stage. Automating these checks with tools like Trivy for container security allows you to catch vulnerabilities during the build phase.

Jit’s Open ASPM platform seamlessly embeds security practices into the DevOps workflow, automating checks across code, CI/CD pipelines, cloud infrastructure, and APIs using over 15 integrated tools (including Trivy, Semgrep and Gosec). Automating security scanning and remediation across the SSDLC helps you speed up development cycles while steadily improving security in real-time.



3. Implement Dependency Scanning

Modern software projects often rely on dozens, if not hundreds, of external dependencies. These dependencies are common attack vectors. SLSA helps manage third-party code by requiring continuous monitoring of these dependencies.

Use tools that allow you to scan for vulnerabilities in package managers like npm and opt for tools with context awareness. Rather than overwhelming you with every CVE alert, a context engine filters and prioritizes alerts based on your application’s context. For example, if a critical CVE is found in one of your npm packages, Jit’s Context Engine assesses whether that specific code path is accessible in your app. This approach reduces alert fatigue so you can prioritize fixes for high-profile exploits like Text4Shell (CVE-2022-42889).

4. Verify Artifact Provenance

Ensuring the integrity of your software artifacts is critical to maintaining trust in your deployments. Artifact provenance helps verify that all components come from trusted sources, preventing the introduction of unauthorized or malicious software. SLSA Level 3 mandates full traceability of every artifact to its origin, protecting against tampering and ensuring the reliability of your software supply chain.

You can achieve this by establishing an internal system for artifact tracking, where each artifact is associated with metadata detailing its origin, build environment, and verification steps. Use a checksum validation process at every stage of your pipeline to confirm that your artifacts remain unchanged and traceable to their source. 

5. Enforce Reproducible Builds

SLSA Level 4 requires that builds produce identical outputs given the same inputs, eliminating variations that could lead to security risks.

To achieve reproducibility, your build process must control for environmental differences like timestamps, file ordering, or machine-specific configurations. Tools like Bazel or Nix provide deterministic build systems that lock down these variables. For instance, Bazel uses a content-addressable cache, meaning the same source code and dependencies always result in the same build outputs, even when run on different machines.



With these tools, you can automate the verification of build outputs by comparing hashes of the resulting binaries across different environments. If the outputs differ, it immediately flags a potential issue, whether it’s a configuration mismatch or tampering attempt.

6. Control Access to Build Infrastructure

Controlling access to your build infrastructure helps prevent insider threats and unauthorized changes. By implementing role-based access control (RBAC) with AWS IAM or Google Cloud IAM, you can tightly regulate who can modify your build environments. Adding tools like HashiCorp Vault for secrets management enhances security. These tools enable you to provide dynamic credentials to authorized users, reducing the risk of credential exposure or misuse.



Track all access and modifications through audit logs with tools like AWS CloudTrail or Google Cloud Audit Logs for complete visibility.

7. Automate Continuous Verification

Security isn’t just a one-time check but an ongoing process throughout the software lifecycle. You want to catch new vulnerabilities as they emerge and continuously validate your code, infrastructure, and application security as your application grows and changes.

You can set up automated security checks by implementing scripts or custom policies that regularly scan your codebase, infrastructure, and configuration files. For example, automate checks to confirm IAM roles remain scope appropriately, with no open-ended access permissions. Or set up scripts to detect and alert on any unauthorized changes to critical configurations, like security groups. 

Secure Smarter, Not Harder With SLSA and Jit

Adopting the SLSA framework is a smart move for securing your software development lifecycle and fortifying your supply chain. It gives you a structured way to lock down source code integrity, automate security in your build pipeline, and verify artifact provenance- all crucial for keeping threats at bay.

But let’s face it – implementing SLSA manually can be a heavy lift. That’s where Jit comes in.  With its Security as Code (SaC) approach, the ASPM platform seamlessly embeds security into your CI/CD pipelines, orchestrating automated checks across every layer. Tools like Semgrep, Gosec, and Trivy are ready to use, making adopting and maintaining the SLSA framework easier. 

Jit turns security from a slow, manual task into an automated, high-velocity process, allowing your team to ship secure, high-quality software faster without sacrificing speed. Learn more here.