How Sigstore Can Help You and Your Team Follow the NIST SSDF Recommendations

This is the third article in a five-part series on the recently published NIST 800-218 ‘The Secure Software Development Framework (SSDF): Recommendations for Mitigating the Risk of Software Vulnerabilities’ [PDF].

The recently published Version 1.1 of the SSDF Recommendations from NIST can seem intimidating — it has four main sections, and 42 tasks, which you can read more about in Dan Lorenc’s recent article “I Read NIST 800-218 So You Don’t Have To.” The good news is that the open source project Sigstore can readily help you and your team meet a number of the recommendations.

Sigstore offers a new standard for signing, verifying and protecting software. Through Sigstore, you can automate digitally signing and checking software artifacts, enabling your software to have a safer chain of custody that can be traced back to the source.

In this article, we’ll go into further detail on how Sigstore can help you satisfy a number of the different tasks across each section in the NIST SSDF.

Prepare the Organization

The Prepare the Organization (PO) section of the SSDF is about “people, processes, and tools,” focusing on the organizational dynamics in place to develop software. While one core piece of this section requires human decision-making and teams to design their approaches to security, Sigstore can be a well-suited choice for several examples in this section. When combined with the cloud native CI/CD framework Tekton — which features Tekton Chains for supply chain security — Sigstore can provide the solution for many of the tasks in this section.

PO.3 is Implement Supporting Toolchains, which calls for the use of automation to reduce human effort and improve accuracy, reproducibility, and comprehensiveness of security practices. Sigstore combines several different technologies that focus on automatic key management and transparency logs in order to reduce human intervention and to support a reproducible, accurate, and inclusive approach. PO.3.1 calls out specifying which tools should be included in each toolchain to mitigate risks, and example 4 in particular speaks to evaluating “tools’ signing capabilities to create immutable records/logs for auditability within the toolchain.” Sigstore offers signing through Cosign and an immutable, tamper-evident transparency log through Rekor, which can provide your team with what they need to fulfill this specification. Furthermore, the Rekor log can help with PO.3.3, with the example “Establish and enforce security and retention policies for artifact data,” as Rekor enables the use of retained logs that you and your users can access to verify security claims.

PO.4 is Define and Use Criteria for Software Security Checks, which is in place to ensure the software that is the product of your team’s development life cycle meets the organization’s expectations based on agreed upon criteria. Sigstore can provide answers for a robust rubric, as it signs artifacts generated throughout the development workflow through Cosign, offers a Certificate Authority through Fulcio, and provides the opportunity to verify those signatures through Rekor. Together, these tools enable one to review artifacts and determine the provenance of artifacts throughout a software development lifecycle.

As mentioned above, Tekton with its Tekton Chains feature can be coupled with Sigstore for added security. In particular, Tekton can be an ideal solution for PO.5: Implement and Maintain Secure Environments for Software Development. Here, Tekton can support your team in minimizing direct human access to build services, and also regularly log and audit trust relationships.

Though a key element in the PO section of NIST 800-218 is human decision making, Sigstore — especially when coupled with Tekton — can offer an integrated solution that you can explore and elect to use in order to meet these requirements.

Protect Software

The Protect Software (PS) section of the NIST SSDF is where Sigstore maps almost seamlessly to the recommendations.

PS.1, Protect All Forms of Code from Unauthorized Access and Tampering, speaks to signing not only code but also commits, and using cryptographic hashes to help protect file integrity. Cosign provides signing across all software artifacts from code to commits. In turn, Sigstore offers integrity of executables and protection against unauthorized access, as well as the ability to review access in case something goes awry. Signatures through Cosign contain the hash itself, a public key, signature content, and the time stamp — which can then all be queried through the Rekor transparency log, providing you with cryptographic hash protection.

PS.2 is Provide a Mechanism for Verifying Software Release Integrity, which specifically is in place to help software acquirers ensure that the software they acquire is legitimate and has not been otherwise modified. Sigstore uses Fulcio as a free code signing Certificate Authority that binds public keys to emails using Open ID Connect tokens, essentially notarizing a particular login with a short-lived key pair to help software developers and acquirers validate provenance of a given artifact. Additionally, Rekor’s transparency log provides the ability for all stakeholders in the software development lifecycle to verify a given software artifact against its immutable, tamper-proof ledger.

PS.3 is Archive and Protect Each Software Release, which calls to preserve software releases so that developers and consumers can identify, analyze, and eliminate vulnerabilities. Rekor will offer support throughout the examples given in PS.3.1, as Rekor provides an archive of data about each software artifact added to its log. Data that is signed and stored on a Rekor server will keep this separate from the rest of a given software project, supporting the protection of integrity verification and provenance data across artifacts. Additionally, PS.3.2 calls for stakeholders to collect, safeguard, maintain, and share provenance data for all components of each software release. Across the Sigstore tools, provenance data can be made available and verified by all members of a team, and as software components are updated, they can continue to be signed for updated provenance data throughout a development or build process.

Across PS.1, PS.2, and PS.3, Sigstore can provide the solutions your team is looking for to meet these specifications in order to protect, verify, and archive software.

Produce Well-Secured Software

The Produce Well-Secured Software (PW) section focuses on techniques around code review, design review, and component selection. This section is more people-focused, like the first section, but again Sigstore can be a tool that your team can depend on in order to fulfill these recommendations.

PW.4 deals with Reuse Existing, Well-Secured Software When Feasible Instead of Duplicating Functionality, which calls to implement trusted solutions rather than rewrite them yourself. Sigstore can help by enabling you to verify that existing software is well secured, and Sigstore is also beginning to partner with package managers in order to help you identify that software libraries are trustworthy with a verified provenance.

PW.9 calls for software being secure by default. Sigstore alleviates the friction that many developers may experience when trying to implement security as part of their development process. If your organization can structure Sigstore into your development life cycle, your developers will be able to build securely by default.

PW9.2 also calls out configuration-as-code as a default approach in its Example 4. Configuration files — and commits associated with them — can be signed with Cosign just like any other software artifact.

Sigstore can help your organization produce well-secured software through providing you with the data you need to identify safe dependencies and libraries that you can leverage in your own software, and in supporting your developers in building secure software by default.

Respond to Vulnerabilities

The final section — Respond to Vulnerabilities (RV) — also has a human element, and again Sigstore can help. Getting information about software and all its dependencies and components can be challenging, and continuing to monitor breaking changes is even more difficult. Sigstore’s transparency log, Rekor, offers auditable logged data for future monitors and integrations that you build into your security workflow. This provides you with a safer chain of custody that you can trace and validate automatically and frequently.

In turn, the data that Sigstore provides your team can provide not only timestamped provenance data, but the context you need to analyze root causes and eradicate vulnerabilities in your software going forward. Being able to monitor effectively and trust the provenance of software artifacts can support your team in responding to vulnerabilities in a timely and accurate way.

While Sigstore shines most in the PS tasks, it plays an integral role in automation and supporting your team in identifying and finding the root cause of vulnerabilities. As Sigstore becomes more adopted across open source software libraries, it will become an increasingly important security tool to have as part of your software development life cycle.

Further Reading

This is the third 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:

1. Goodbye SDLC, Hello SSDF! What is the Secure Software Development Framework?

2. I Read NIST 800-218 So You Don’t Have To - Here’s What to Watch Out For

3. How Sigstore Can Help You and Your Team Follow the NIST SSDF Recommendations

4. How SLSA maps to the SSDF

5. How to make NIST’s SSDF work for Open Source Projects

You can access the NIST 800-218 ‘The Secure Software Development Framework (SSDF): Recommendations for Mitigating the Risk of Software Vulnerabilities’ PDF via the NIST website.