Securing the Software Supply Chain: SLSA (SALSA) Framework

The SLSA Framework (pronounced “salsa”) stands for Supply Chain Levels for Software Artifacts. It is a security framework designed to ensure the integrity of software artifacts throughout the software supply chain. Originating from Google in collaboration with other industry partners, SLSA helps to prevent tampering, improve integrity, and secure packages and infrastructure in software development and distribution.

1. Advantages of the SLSA Framework

 

Securing the Software Supply ChainThe above image illustrate potential attacks across the supply chain and demonstrate how the SLSA framework can offer protection.

1.1 Prevention of Unauthorized Tampering

SLSA’s structured levels ensure that every phase of the software development and deployment process is secured against unauthorized access and tampering. By requiring things like provenance (metadata providing a verifiable history of the software and its components), the framework makes it difficult for malicious actors to introduce vulnerabilities without being detected.

1.2 Enhanced Traceability

The framework mandates detailed logging and tracking of the origin of software components and the processes by which they are assembled and deployed. This traceability allows organizations to quickly identify and isolate components that may be compromised, reducing the potential impact of an attack.

1.3 Improved Reproducibility

At its higher levels, SLSA requires that builds be reproducible, meaning that the same source should lead to bit-for-bit identical results if the build process is repeated. This helps in verifying the integrity of the software and ensuring that the build process itself hasn’t been tampered with.

1.4  Mitigation of Specific Threat Vectors

By adhering to the SLSA framework, organizations can mitigate various threat vectors, including:

  • Supply Chain Poisoning: Where attackers inject malicious code into libraries or components expected to be trusted.
  • Insider Threats: Reducing risks associated with malicious or negligent insiders by enforcing two-factor authentication, code reviews, and logging.
  • Build Infrastructure Attacks: By securing the environments where software is built and ensuring that metadata about the build process is immutable and auditable.

1.5 Standardization of Security Practices

SLSA provides a clear, tiered structure for implementing security practices. This standardization helps organizations benchmark their security posture against an industry-standard framework, promoting a uniform approach to securing the software supply chain.

1.6. Regulatory Compliance

With increased regulatory focus on software supply chain security (such as the U.S. Executive Order on Improving the Nation’s Cybersecurity), SLSA provides a framework that can help organizations meet these regulatory requirements, ensuring that they are not only secure but also compliant.

1.7. Enhanced Consumer Confidence

Organizations that implement the SLSA framework can provide assurance to customers and partners about the security and integrity of their software products. This transparency builds trust and can be a competitive advantage in markets where security is a top concern.

 

2. Main Concepts of SLSA

2.1 Artifact

An artifact refers to any file or set of files that are produced and consumed by software tools during the software development process. This includes source code, binaries, configuration files, and packages.

2.2 Software Supply Chain

This involves all the steps, processes, and entities involved in the creation, modification, and delivery of software. It extends from the initial development of code to the management of its deployment in various environments.

2.3 Integrity

In the context of SLSA, integrity means ensuring that the artifacts remain unchanged and unmanipulated from their original state as they move through the supply chain.

2.4 Provenance

Provenance is the metadata associated with artifacts that describes their origin and the process through which they were built. This information is critical for verifying the security and integrity of the artifacts.

 

 

3. SLSA Security Levels

SLSA defines four progressive levels of security standards, each designed to provide incrementally stronger guarantees about the integrity and security of the software supply chain.

Level 1: Documentation

  • Objective: Establish basic security standards and processes.
  • Key Requirements:
    • Version control of source code.
    • Automated build process.

Level 2: Tamper Resistance

  • Objective: Ensure that the build processes are free from tampering.
  • Key Requirements:
    • Immutable and auditable source and build metadata.
    • Use of a build service that generates provenance.

Level 3: Extra Protection

  • Objective: Protect the supply chain from malicious changes.
  • Key Requirements:
    • Source and build metadata must be stored in a tamper-resistant location.
    • The build service must use two-factor authentication for operations.

Level 4: Highest Assurance

  • Objective: Provide the highest level of security and assurance.
  • Key Requirements:
    • Reproducible builds.
    • Full traceability from source to binary with corresponding metadata.

 

 

4. Some Real-world implementations

  1. GitHub’s npm Provenance Initiative: GitHub has utilized SLSA principles to implement package provenance for npm. This allows package consumers to trace the packages back to their sources and the build commands used, improving the auditability and security of the npm ecosystem. This successful implementation serves as a model for other programming language ecosystems aiming to enhance their package security​ (OpenSSDF)​.
  2. Google’s Internal Security Practices: Google has incorporated SLSA-based principles into its internal security practices, notably through its “Binary Authorization for Borg” process. This method ensures that only approved binaries are included in builds, which is a key practice adopted and promoted under the SLSA initiative. The company has worked to generalize these practices into the SLSA framework, aiming to elevate security standards across the industry by making it easier to achieve higher SLSA levels through automated provenance generation and integration with popular CI/CD systems​ (ActiveState)​.
  3. Government and Industry-Wide Adoption: Following significant supply chain attacks like SolarWinds and Kaseya, there has been a broad recognition of the need for stringent security measures in software supply chains. The U.S. government, among others, has pushed for the adoption of frameworks like SLSA. This governmental endorsement underlines the necessity for such frameworks to ensure the integrity and security of software supply chains across various sectors​ (ActiveState)​.

 

5. References

6. Conclusive Summary

In conclusion, SLSA is a critical framework for securing the software supply chain. It provides a stepping stone approach, with each level introducing additional security measures. The SLSA framework aids in ensuring that software artifacts are verifiable, resistant to tampering, and maintain provenance throughout the development lifecycle. By adopting SLSA, organizations can significantly reduce the risk associated with software supply chain threats, making it a cornerstone of modern software security practices.