Since February’s release of the latest version of the Secure Software Development Framework’s (SSDF), software organizations have been poring over the dozens of best practices and tasks laid out by the National Institute of Standards and Technology (NIST) in response to last year’s Executive Order on Cybersecurity. Implementation is tough, though: the guidelines cover organizations of all sizes, cybersecurity sophistication, and operating environment. The descriptive requirements are not prioritized and explicitly not meant to be a checklist to follow. Each organization must find ways to interpret the recommendations for their particular needs.
Prioritization will be key. Though the open source community has created several freely available tools that will help address parts of the SSDF requirements (e.g. Sigstore for signing, Tekton Chains for attesting software build pipelines), would-be SSDF practitioners will need an organized plan for implementation: where should they start, what steps should they emphasize, and how can they adopt secure practices most efficiently?
We suggest Supply-chain Levels for Software Artifacts (SLSA, pronounced “salsa”) as an on-ramp for successful SSDF adoption. SLSA is a framework for supply chain security that is approachable, prescriptive, and prioritized. It offers an excellent starting point for any organization—regardless of current security maturity—to more easily achieve a number of SSDF requirements.
What is SLSA?
SLSA is a framework developed by the open source community for software supply chain security. At heart, SLSA is a checklist of controls and practices to prevent tampering, improve integrity, and secure software packages and infrastructure. Its main focus today is on the “source-to-production” segment of the software supply chain: it covers source, build, and provenance generation requirements, with room for expansion to other security areas covered by the SSDF.
SLSA and SSDF
Multiple aspects of SLSA make it an excellent adoption strategy for the SSDF:
SLSA is approachable
A key aspect of SLSA is its leveled structure. There are four ascending “SLSA levels,” with SLSA 4 indicating that an organization has very robust supply chain security practices. These levels were designed to make SLSA approachable: it’s easy to get a grip on the bottom of the SLSA ladder, and wherever you are on it, the next rung is always within reach. This makes SLSA beneficial for both organizations just starting out with SSDF requirements as well as those with more mature security postures. Just target your current SLSA level and start from there.
SLSA is prescriptive
The SLSA framework is like a checklist: it tells you what to do to achieve each SLSA level. This makes it a useful counterpart to the SSDF, which tells you the endpoint goals but not how to get there. For example, SSDF PS 3.2 asks organizations to “collect, safeguard, maintain, and share provenance data for all components of each software release,” but doesn’t specify how. SLSA, though, lays out the steps to generating attestations about the release process for an artifact, the materials used in production, and whether the artifact was protected from tampering — data collectively known as provenance. For organizations already generating provenance, the next SLSA levels go further to ensure the metadata is authenticated and tamper-proof.
SLSA is prioritized
The SSDF’s requirements are grouped into four areas: Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW), and Respond to Vulnerabilities (RV). Often there is overlap between these areas, so one well-chosen security improvement could fulfill multiple SSDF requirements in different areas — but it can be difficult to know which requirements fit together. SLSA helps you see where to direct your efforts for the maximum impact and efficiency.
Here are some examples of how SSDF requirements would be met by adopting SLSA:
| SSDF v1.1 Requirement | SLSA Coverage Today |
|---|---|
| Protect the Software (PS) | |
| §PS.1.1 "Store all forms of code based on the principle of least privilege so that only authorized personnel, tools, services, etc. have access." | SLSA requires that source code is retained indefinitely, version controlled, and has verified history. |
| §PS.2.1 "Make software integrity verification information available to software acquirers." | SLSA directly addresses integrity verification information through propagation of tamper-proof provenance information. |
| §PS.3.1
"Securely archive the necessary files and supporting data (e.g.,
integrity verification information, provenance data) to be retained
for each software release." §PS.3.2 "Collect, safeguard, maintain, and share provenance data for all components of each software release (e.g., in a software bill of materials [SBOM])." |
SLSA focuses on secure provenance creation and retention of source code, which also supports the generation of more complete SBOMs. |
| Produce Well-Secured Software (PW) | |
| §PW.4.1
"Acquire and maintain well-secured software components (e.g.,
software libraries, modules, middleware, frameworks) from commercial,
open-source, and other third-party developers for use by the
organization's software." §PW4.4 "Verify that acquired commercial, open-source, and all other third-party software components comply with the requirements, as defined by the organization, throughout their life cycles." |
SLSA provenance enables software acquirers to verify provenance of third-party software components, ensuring that the components were built from canonical sources and have not been tampered with. (See the supply chain threats that SLSA mitigates.) |
| §PW6.1"Use
compiler, interpreter, and build tools that offer features to improve
executable security." §PW6.2 "Determine which compiler, interpreter, and build tool features should be used and how each should be configured, then implement and use the approved configurations." |
SLSA defines expectations for isolated ephemeral build environments, trusted builders, repeatable builds, build config as code, and parameterless builds. This enables organizations to establish and follow best practices for build environments and configurations. |
| Prepare the Organization (PO) | |
| §PO.1.1 "Identify and document all security requirements for the organization's software development infrastructures and processes, and maintain the requirements over time." | SLSA helps in the codification of policies around upstream artifacts. |
Looking Ahead
Beyond the current mapping, the SLSA community is considering work to expand SLSA to include a set of automation tools and cover other SSDF practices. Though some requirements will remain out of scope, the community hopes an expanded SLSA will become a natural stepping stone toward achieving the security best practices outlined by the SSDF.
We believe that organizations with mature software engineering practices as well as organizations just starting out with SSDF’s guidelines will both benefit from SLSA adoption. Its approachable structure and progressive steps meet you where you are and ease the difficulty of identifying which SSDF areas to focus on next. We hope to see more organizations taking advantage of SLSA and becoming involved in the SLSA community. We also welcome discussion around the plans to expand SLSA: with more contributors, this framework can become even more valuable to the software community.