Implementing Secure Software Supply Chain Security Controls: Understanding NIST SSDF & SLSA Frameworks

Cybersecurity fundamentals is a subject that is a mile wide and an inch deep. For this reason, security control frameworks exist to help guide us in creating a thorough and layered approach to implementing the recommended security controls. The numerous security frameworks can seem overwhelming. There are security control frameworks that are applicable to certain industries and security control frameworks that apply regionally and internationally. Fortunately, for the subject of “Secure Software Supply Chains” this discussion will focus on two related frameworks: the Supply Chain Levels for Software Artifacts (SLSA) and the Secure Software Development Framework (SSDF). Let’s start by looking into some background about security frameworks.

Who Creates these Frameworks and Why?

In the United States, the National Institute of Standards and Technology (NIST) provides “special publications” that offer guidance on security practices and the controls that should be implemented. These special publications (SPs) are intended to be implemented for U.S. federal information systems but are adopted by various organizations in various industries and academia. Other times private industry may take the lead in developing and adopting security practices to address security threats and trends. For example, the Payment Card Industry Data Security Standard (PCI-DSS) is neither a law nor a government standard: it was developed within the credit card industry as a security standard for self regulation. The standards are set by the Payment Card Industry Security Standards Council (PCI SSC) and all merchants and payment processing organizations are required to comply with PCI-DSS, which is then enforced by the main payment industry vendors.

Responding to the Rising Threat of Software Supply Chain Attacks

Recently the rising threat of software supply chain attacks has put the integrity of software development in the spotlight. As organizations improve the security posture of their network and compute resources, threat actors are increasingly attacking the development and deployment stages of the software development life cycle. This trend has prompted a response by both government and private industry leaders.

Introduction of NIST SSDF (SP800-218) and SLSA

On May 12th, 2021 Executive Order (EO) 14028 was issued by the Biden Administration with the intent of improving the nation’s cybersecurity posture. Section 4 of the order focuses specifically on “Enhancing Software Supply Chain Security”. NIST has responded to EO, specifically Section 4. (e), by releasing the “Secure Software Development Framework” (SSDF) (SP800-218) to help government organizations address these software supply chain threats. This special publication outlines a set of practices that are meant to be implemented in the Software Development Lifecycle (SDLC). The NIST SSDF organizes secure software development practices in four groups:

Prepare the Organization (PO)
Protect the Software (PS)
Produce Well-Secured Software (PW)
Respond to Vulnerabilities (RV)

These four practices are then supported by tasks that can be implemented to help build in the secure practice for an organization. For example, within the group of Respond to Vulnerabilities (RV), the practice “Identify and Confirm Vulnerabilities on an Ongoing Basis” (RV1.1) is supported by a task of (RV1.1) “Gather information from purchases, consumers, and public sources on potential vulnerabilities in the software and third-party components that the software uses, and investigate all credible reports.” Each practice may have multiple tasks prescribed.

Organizations in private industry lept into action as well. For example, Google and the Open Source Security Foundation (OpenSSF) responded to the growing threat of these attacks by creating a “Supply Chain Levels for Software Artifacts” (SLSA) framework; pronounced like the delicious topping we put on tacos and dip tortilla chips in. This framework introduces concepts and steps to help secure the Software Development Lifecycle (SLDC), focusing on source code, dependencies/packages, and build-pipelines. (Lewandowski & Lodato, 2021)

SLSA requirements can be categorized into four groups of requirements: source requirements, build requirements, provenance requirements, and common requirements. The degree of implementation of the requirements correspond with a SLSA summary level of compliance. Also, the individual requirements can have levels of implementation that affect the overall summary level.

Level	Description	Example
1	Documentation of the build process	Unsigned provenance
2	Tamper resistance of the build service	Hosted source/build, signed provenance
3	Extra resistance to specific threats	Security controls on host, non-falsifiable provenance
4	Highest levels of confidence and trust	Two-party review + hermetic builds
Source: https://slsa.dev/spec/v0.1/levels

Requirement	Description	L1	L2	L3	L4
Scripted Build	All build steps were fully defined in some sort of “build script”. The only manual command, if any, was to invoke the build script.	x	x	x	x

So how do SLSA and SSDF relate?

NIST SSDF provides guidance at the organization’s secure software development life cycle level covering practices such as documentation, communications, roles & responsibilities, and other practices, whereas SLSA has a focus on providing guidance for securing source, build and deployment by providing provenance through attestation. The “mapping” between the two frameworks requires understanding the scope of each and takes a bit of interpretation. This type of exercise is not uncommon for Governance, Risk, Compliance (GRC) professionals, cybersecurity professionals, and auditors. Often enterprises need to understand how multiple frameworks, industry standards and regulations overlap or present gaps.

In this case, SLSA can be mapped only to a subset of practices within the SSDF guidance. To add to this complexity, SLSA has variations of compliance levels so there are not necessarily one-to-one mappings between the controls. As an analogy, the relationship between the two frameworks can be visualized as nesting dolls, aka “Matryoshka Dolls”. Perhaps your organization has adopted the NIST Cybersecurity Framework, which would be the large doll, containing a smaller doll: the NIST SSDF practices that apply to your organization’s SDLC program. Finally, the smallest of the dolls: SLSA guidance being applied to your secure build, packaging and deployment processes.

Let’s take a look at an example, SLSA’s Source Integrity Requirement: Version Control. This control is described as, “Every change to the source is tracked in a version control system with change history & immutable reference enforced.” The following NIST SSDF practices can be mapped to the SLSA requirement:

PO.3 Implement Supporting Toolchains
PS.1 Protect All Forms of Code
PS.2 Verifying Software Release Integrity
PS.3 Archive & Protect Each Software Release

SLSA Framework (v0.1)
SLSA Requirement	Levels Required	Control Description	NIST SSDF Practice	NIST SSDF Task
Source Integrity: Version Control	2, 3, 4	Every change to the source is tracked in a version control system with change history & immutable reference enforced.	PO.3 Implement Supporting Toolchains PS.1 Protect All Forms of Code PS.2 Verifying Software Release Integrity PS.3 Archive & Protect Each Software Release	PO.3.2 Follow recommended security practices. PO.3.3 Configure tools to generate artifacts. PS.1.1 Store all forms of code. PS.2.1 Make software integrity verification. PS.3.1 Securely archive the necessary files and supporting data, retained for each software release. PS.3.2 Collect, safeguard, maintain and share provenance data for all components of each software release.

Controls Design & Implementation

We can see that achieving SLSA requirements helps to implement elements of the NIST SSDF guidance but without a one-to-one mapping. Following through with our example of the nesting dolls, implementing secure software development life cycle practices from the SSDF contributes to achieving organizational compliance requirements such as NIST Cybersecurity Framework.

Conclusion

Implementation of a cybersecurity program for the enterprise has always been a layered-approach in addition to ensuring compliance whether its internally developed security requirements and/or requirements prescribed by security frameworks. SLSA’s relationship to NIST SSDF’s is no different: one encompasses a higher level, while the other is much more scoped to specifics in build/deployment. If you are looking to implement secure development practices at the organizational level, you will want to adopt SSDF practices. If you are needing to ensure secure software at source, build and deploy, you will need to adopt SLSA and achieve the desired level of compliance. It is likely that you would want to ensure SLSA compliance levels as part of your SSDF implementation.

This is the fourth article in a five-part series on NIST 800-218 ‘The Secure Software Development Framework (SSDF): Recommendations for Mitigating the Risk of Software Vulnerabilities’The full series :