Safeguarding software that relies on third-party components and services has heightened vulnerabilities. It is advantageous for software teams to embrace a comprehensive framework created for the specific needs of supply chain software. Supply chain attacks are an ever-increasing threat. The Supply chain Levels for Software Artifacts (SLSA) framework offers a clear, consensus-based standard that prescribes compliance requirements.
What is the SLSA framework?
Supply chain Levels for Software Artifacts is an end-to-end security framework that includes a set of standards and controls to prevent software tampering throughout the software development life cycle. SLSA focuses on enhancing software integrity while securing artifacts and infrastructure across the supply chain. The SLSA framework not only defines the requirement and goal for each control but establishes three trust boundaries around standards, attestation, and technical controls, as well as four certification levels.
SLSA Addresses Growing Software Supply Chain Security Risks
All software contains potential vulnerabilities and introduces supply chain risk. In recent years, multi-billion-dollar attacks like SolarWinds and Codecov stressed the urgent need for rigorous standards for supply chain security.
The software supply chain includes a host of contributors from third-party code imported from open sources. These include third-party vendors participating in the SDLC and distribution systems, making software accessible to internal and external customers.
The software supply chain has become more complicated. Enterprise decision-makers are looking for a methodology that provides greater confidence in the security of software. SLSA addresses concerns that a software bill of materials (SBOM) doesn’t flag.
SLSA is Maintained by Industry Collaborative
The SLSA framework is a maintained by a vendor-neutral steering group. It was developed in collaboration with the Linux Foundation and released in June 2021 by Google’s security team. The Linux Foundation’s website for SLSA touts it as “focused on protecting software from source through its deployment by allowing users to make automated decisions about the integrity of the artifacts they are using, thereby preventing many possible attacks throughout the supply chain.”
Purpose and Value of the SLSA framework
The topline goals for creating and promoting SLSA are to enhance overall software supply chain security, particularly open source, and to harden against increasing integrity threats. The framework provides standards for stakeholders to vet the security posture of the software they consider and purchase. Any organization can also use the SLSA framework as a rubric for securing its internal supply chain.
Adopting the SLSA framework provides practical requirements that can strengthen an organization’s software supply chain and protect against common attacks. The SLSA framework is created to phase in and build up improvements enabling teams to bolster security incrementally over time.
An SLSA framework “certification” can generate automatic, auditable metadata files that can integrate with policy engines. The SLSA level provides confidence to internal and external customers and enables security verification across the supply chain.
SLSA Requirements Built Across Four Levels
As more teams attest their software using SLSA, the framework will grow to become the trusted industry standard.
SLSA framework requirements are divided into four categories:
- Source requirements
- Build requirements
- Provenance requirements
- Common requirements
These requirements comprise four levels, meeting increasing security standards and controls. Each level builds on achievements from prior levels. The build service starts at level two, and the source control service starts at level three, culminating at level four, where all requirements are met.
Four SLSA Requirement Levels
The SLSA framework defines four levels. The levels start with demonstrating growth from baseline visibility and generating provenance. Then move on to providing build integrity assurances and high-level measures indicating robust dependency management.
Figure 1 provides a quick overview of the four levels from the SLSA collaboration. Security guidelines build from level to level, addressing more significant threat complexities. Level 0 includes any system that cannot guarantee software supply chain security.
Level 1: This level indicates that the build process is fully scripted or automated. It generates provenance via metadata. This includes how an artifact was built. This includes the build process, top-level source, and dependencies. Provenance at this level offers basic code source identification and vulnerability management but not tamper protection.
Level 2: This level requires version control and an authenticated provenance generated by the hosted build service. Now, provenance provides a level of trust in tamper prevention.
Level 3: This level requires that source and build platforms conform to specific standards, guaranteeing source audits and provenance integrity. This level protects against tampering by preventing specific threats like cross-build contamination.
Level 4: This level serves as a best practice for uncovering mistakes and deterring errant behavior. Level four requires a two-person review of all changes, including a hermetic, reproducible build process.
Each SLSA framework level is not “transitive,” meaning that each artifact’s SLSA rating is independent of the others. This nature allows parallel progress and prioritization based on the unique risk of each software, team, or organization. According to SLSA, “Each level describes the integrity protections of an artifact’s build process and top-level source, but nothing about the artifact’s dependencies. Dependencies have their own SLSA ratings, and it is possible for an SLSA 4 artifact to be built from SLSA 0 dependencies.”
SLSA Framework Use Cases
Similar to the transitive and incrementally-building nature of the levels, SLSA prevents tampering by deploying different approaches. The chosen method depends on the intended use case. SLSA provides three use cases:
- The first party focuses on reducing organizational risk from internal users and compromised accounts. A case study to consider is Google’s Binary Authorization for Borg.
- Open source focuses on reducing risk from third-party open-source software. Mapping built packages back to their canonical sources and dependencies lessens the number of secure build systems users must trust. A case study to consider is SUSE.
- Vendors focus on reducing risk from third-party or vendor-provided software and services. Here, the focus is on the trustworthiness of a vendor’s claims.
SLSA Framework Supports Iterative, Standards-Based Software Supply Chain Security
The SLSA framework offers a pathway to software supply chain integrity and market confidence. It is useful for organizations looking for an iterative approach to building robust software supply chain security competency. Whether for internal use or vetting third-party software or sources, SLSA provides a straightforward, vendor-agnostic approach.
Software Supply Chain Security Starts with Panoptica
Cisco’s Emerging Technologies and Incubation (ET&I) team is paving the way with “DevOps-friendly” cloud-native security solutions that fundamentally simplify conventional offerings. Our Panoptica solution simplifies cloud-native application security, making it easy to embed into the software development lifecycle. Panoptica protects the full application stack from code to runtime by scanning for security vulnerabilities in the cloud infrastructure, microservices (Containers or Serverless), the software bill of materials, and the interconnecting APIs. And best of all, it integrates with the tools that your application development and SecOps teams are already using. Try Panoptica for free!
