What is the SLSA Framework?

“SLSA (Supply-chain Levels for Software Artifacts) Framework helps secure software supply chains by attesting to four progressive levels of security maturity. Check out how it works and best practices for ensuring artifact integrity and preventing tampering.”

SLSA (Supply-chain Levels for Software Artifacts), pronounced “salsa”, is a security framework designed to standardize the protection of software supply chains.

It helps safeguard against software tampering, improve the integrity of software artifacts (components) and ensure that software is as secure as possible.

SLSA was developed by OpenSSF and Google to address the issue of software supply chain security. Currently, SLSA’s focus is on securing the Build process. However, it plans to evolve to additional areas and domains in the near future, enhancing its importance in application security (AppSec).

SLSA defines four progressive levels, each with its own set of requirements. Each level builds upon the previous one, adding more security and assurance.

• Level 0 – No SLSA; builds and runs occur on the same machine.
• Level 1 – Basic protection with provenance; does not include tamper protection.
• Level 2 – Attack surface of the build process is reduced and resistant to certain tampering and threats.
• Level 3 – A high degree of confidence in the integrity and provenance of software artifacts.

With SLSA, AppSec teams and developers incorporate security practices into the enterprise’s build processes, so they have more confidence in the supply chain software artifacts they consume. From a business perspective, companies that prioritize and implement SLSA’s supply chain security practices can differentiate themselves in the market, providing an edge over competitors.

What is the Supply Chain Security Challenge and Why is the SLSA Framework Important?

The software supply chain, which includes the development, distribution and deployment of software, is vulnerable to many threats.

This is due to various factors, including vulnerable or malicious open-source components, the ability to compromise build environments, compromised packages and package managers, and more.

2024: 100% of organizations have fallen victim to SSCS attacks!

Supply Chain August Checkmarx Security Research Summary

August was a peak month in the number of open source supply chain attacks keeping the SCS team working relentlessly. Watch to learn more about: First-ever Phishing attack targeting PyPI contributors. Multi-stage highly sophisticated backdoors hiding in code packages. More the 1000 packages with Ransomware and crypto miners. Attack on GitHub that created more than 35000 fake Repos with malicious code hiding inside.

Latest from Checkmarx Security Research

The SLSA framework can help secure against these risks by providing:

• Prevention of Supply Chain Attacks – By adhering to SLSA levels, organizations can mitigate the risk of various types of supply chain attacks. This includes identifying and mitigating risks associated with third-party dependencies and the build environment, preventing tampering during the build and distribution processes, and ensuring the integrity of software components.
• Standardization of Best Practices – SLSA provides a set of industry-standard best practices that organizations can adopt to secure their software supply chains. This standardization helps in creating a common understanding and approach towards supply chain security. As more organizations adopt SLSA practices, the overall software ecosystem becomes more secure, making it more difficult for attackers to exploit supply chain vulnerabilities.
• Incremental Security Improvements – SLSA defines a roadmap of four levels of security maturity, from Level 0 (basic security requirements) to Level 3 (high assurance). This allows organizations to progressively improve their security posture over time, aligning with their specific risk profiles and resource availability.
• Incident Response – In the event of a supply chain attack, SLSA’s emphasis on provenance and build integrity can aid in faster incident response and impact assessment.
• Provenance and Transparency – One of the core tenets of SLSA is to ensure the provenance of software artifacts. This means having verifiable metadata about where software components come from, how they were built, and how they were distributed. This transparency builds trust and accountability in the software supply chain.
• Compliance and Assurance – An organization that adopts SLSA can demonstrate to their customers and stakeholders that it is following rigorous security practices. This is increasingly important as expectations around software security continue to rise.

How SLSA Works

The SLSA framework provides a structured and standardized framework with four defined levels of security to protect and ensure the integrity of software supply chains. Each level specifies requirements and best practices that must be met to ensure software artifacts are trustworthy and tamper-proof. Here’s how it works:

Level 0: No protection (prior to adoption of SLSA)

Level 1: Adding provenance

Provenance is added to provide information about the build process: how the artifact was built, the build platform and process, etc. This enables the software producer and its consumers to patch, debug and rebuild software, and helps prevent mistakes in the release process.

Level 2: Using a hosted build platform

The hosted platform runs on dedicated infrastructure and signs the provenance with a digital signature for authenticity. This helps prevent tampering, deters insider threats, and reduces the attack surface.

Level 3: Hardened builds

Using a hardened build platform with strong tamper protection. This requires changes to the build platform but prevents tampering, reduces the impact of compromised packages, and provides confidence in packages.

Who Owns SLSA in the SDLC?

SLSA is a shared responsibility that involves executive leadership, security teams, development teams, QA, operations, and compliance professionals. By working together and adhering to the SLSA framework, organizations can significantly enhance the security and integrity of their software supply chains.

Executive Leadership – CISO, CTO, CIO

• Set strategic goals for software supply chain security.
• Allocate resources and budgets for implementing SLSA.
• Ensure organization-wide adherence to security policies and frameworks.

Security Team – Security Architects, Security Engineers, Compliance Officers

• Develop and enforce security policies and best practices related to SLSA.
• Conduct threat modeling and risk assessments.
• Implement security controls and monitoring solutions.
• Ensure compliance with relevant regulations and standards (e.g., GDPR, HIPAA, NIST).

Engineering Team – Developers, DevOps, QA

• Integrate SLSA practices into the CI/CD pipeline.
• Ensure secure coding practices and proper dependency management.
• Maintain the integrity of the build environment and tooling.
• Perform security testing, including static and dynamic analysis.
• Manage the infrastructure and environments where software is built, tested, and deployed.
• Ensure secure configurations and patch management.
• Monitor and respond to security incidents related to the software supply chain.

Best Practices for Using SLSA in Software Supply Chain Security

Implementing the SLSA framework effectively requires adherence to best practices that align with the framework’s requirements and goals.

Since SLSA is evolving and attempts to remain a framework and not a guide, this list is constantly evolving and should be accompanied with research of additional practices required for your security needs.

Here are some best practices for using SLSA in software supply chain security:

1. Use a robust version control system like Git. Ensure all changes are tracked, and the history is immutable.
2. Require developers to sign their commits to verify the authenticity of code changes.
3. Implement branch protection rules to prevent unauthorized changes, such as requiring pull requests for all changes and enforcing code reviews.
4. Use isolated and ephemeral build environments to ensure that each build is independent and cannot be influenced by previous builds or external factors.
5. Prevent secret credentials and other sensitive information from being included in files or repositories where they might be exposed.
6. Aim for reproducible builds, where the same source code always produces the same binary. This helps detect tampering and inconsistencies.
7. Use vetted and controlled dependencies, and ensure they come from trusted sources. Scan with SCA tools and regularly update dependencies to patch vulnerabilities.
8. Automatically generate detailed provenance metadata for each build, including information about the source code, build environment, and dependencies. You can use an automated SBOM solution for this.
9. Sign all provenance metadata and build artifacts using cryptographic keys. Ensure these keys are securely managed and rotated regularly.
10. Store provenance metadata in a secure, immutable, and accessible manner, such as in a blockchain or trusted database.
11. Conduct regular security scans and audits of your build and supply chain processes to detect vulnerabilities and malicious packages and ensure compliance with SLSA requirements.
12. Have a clear incident response plan in place for handling supply chain security incidents, including steps for containment, investigation, and remediation.
13. Integrate SLSA best practices into your CI/CD pipelines to automate compliance and reduce manual errors.
14. Use security tools that support SLSA practices, such as those for static analysis, dependency scanning, and secret management.
15. Provide regular training for developers on secure coding practices, SLSA requirements, and the importance of software supply chain security.

Secure Your Software Supply Chain with Checkmarx

Vulnerabilities and malicious threats in third-party components, libraries, and development processes can lead to data theft, operational disruption, compliance violations, and reputation damage. This makes software supply chain security key to any enterprise security strategy. A secure software supply chain ensures that every component, from source code to final application, is protected against tampering, unauthorized access, and supply chain attacks.

SLSA helps organizations maintain the integrity and security of their software development processes by establishing standards for secure software builds. By adopting SLSA, organizations can ensure that software is built, distributed and deployed securely, reducing the risk of introducing vulnerabilities and malicious code into their environments.

At Checkmarx, we offer comprehensive solutions to enhance your software supply chain security. Discover how Checkmarx can help you build a more secure, resilient, and trustworthy software supply chain. Contact us for a demo today.