Guide to Secure Your CI/CD Pipelines by NIST

UPDATE: On December 20, 2023, the final version of SP 800-204D, “Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines“, was published by NIST. The changes from the draft to the final form were added to this blog (in italics), and the most prominent of them include the definition of requirements for attestation and its storage and the rearrangement of requirements in CD pipelines.

On August 30, 2023, NIST published SP 800-204D, an Initial Public Draft (IPD) Named: “Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines.” The publication takes the SSDF's high-level policies and sets a guideline for how to comply with them using CI/CD pipelines. With this, you can automate the process of compliance, guarantee that all artifacts that went through the pipelines are compliant, and make the process as zero-trust as possible.

SSDF In Legit

As part of our mission for secure application delivery and to protect your software supply chain, we at Legit Security have been closely following the SSDF and all its related publications. The Legit Security platform provides customers with a comprehensive compliance coverage map that implements policies into every part of their SDLC. That is precisely what this publication aims to do for CI/CD pipelines.

The SSDF Breakdown

Introduction

The IPD starts with a quick introduction to Software Supply Chain (SSC) security, breaking down risk factors and mitigation measures. It also gives us a quick rundown of CI/CD pipelines, which are the main focus of this publication.

In the next section, the document defines secure methods for CI workflows and CD workflows. For some of the methods, it sets numbered requirements that establish a practical standard for secure pipelines. We hope as the work on the document progresses, it will do so for all methods.

Securing Workflows in CI Pipelines

Secure Build

A secure build is defined by 3 things: you need to specify policies regarding the build, enforce those policies, and provide evidence for it. The answer NIST provides for these tasks is the Build Attestation, comprised of the following elements:

1. Environment Attestation: Generally refers to the platform on which the build process is run. The components of the platform (compiler, interpreter, etc.) must be hardened, isolated, and secure.

2. Process Attestation: The computer programs that transformed the original source code or materials into an artifact (compilers, packaging tools, etc.) and/or the programs that performed testing on that software.

3. Materials Attestation: Any raw data and can include configuration, source code, and other data.

4. Artifacts Attestation: An artifact is the result or outcome of a CI process. An attestation pertaining to this newly generated product falls under the category of artifacts attestation.

The requirements for an attestation and its storage must include the following:

• The attestations must be cryptographically signed using a secure key.

• The storage location must be tamper-proof and protected using robust access control.

Secure Pull-Push Operations on Repositories

Code is hosted in repositories and is extracted by authorized developers using a PULL operation, modified, and then put back using a PUSH operation. To authorize these operations, two forms of checks are to be verified:

1. The type of authentication required to authorize developers for PULL-PUSH operations and the change pushed are consistent with the developer's role. In addition, the changes cannot be approved by the same developer who submitted them.

2. The integrity of the code in the repository can be trusted such that it can be used for further updates.

PULL-PUSH_REQ-1: The project maintainer should run automated checks on all artifacts covered in the pull request, such as unit tests, linters, integrity tests, security checks, and more.

PULL-PUSH-REQ-2: Running CI pipelines using external tools (e.g., Jenkins) should be performed only when confidence is established in the trustworthiness of the source code origin. The document emphasizes the source code mentioned in this requirement refers to the external tool’s source code, which needs to be verified before running.

PULL-PUSH-REQ-3: CI workflow runs should have the option to delay until approved by a maintainer with write access. This should be used when an outside contributor submits a pull request to a public repository.

PULL-PUSH_REQ-4: Evaluate and enhance the security posture of the SCM systems with or without a policy (e.g., OPA), detect and remediate misconfigurations, security vulnerabilities, and compliance issues.

Integrity of Evidence Generation During Software Updates

Even if you use cryptographic signing, the process of signature generation may be vulnerable to known attacks, so software update systems require many other security measures related to signatures generation and verification. The evolving framework should provide protection against all known attacks on the tasks performed by the software update systems.

Secure Code Commits

SAST, DAST and SCA scanners should be integrated in you CI workflows. Code coverage reports should be provided to developers and security personnel. SCA tools should detect all dependencies, including transitive dependencies.

COMMIT-REQ-1: If the committed code has an embedded secret, there should be a feature to generate an alert that contains information on the secret type (e.g., personal access token) and location, as well as the methodology to remediate the exposure. 

COMMIT-REQ-2: Push protection features should be enabled for all repositories assigned to an administrator. The features should include the enforcement of authentication, signed commits, and file name verification.

Securing Workflows in CD Pipelines

DEPLOY-REQ-1: Code that is already in the repository and ready to be deployed should be scanned for secrets such as keys and access tokens.

DEPLOY_REQ-2: Before merging pull requests, it should be possible to view the details of any vulnerable versions through a form of dependency review.

DEPLOY-REQ-3: If a secure build environment and associated process have been established, It should be possible to specify that the artifact being deployed was generated by that build process to be cleared for deployment.

DEPLOY-REQ-4: Check for evidence that the container image was scanned for vulnerabilities and attested vulnerability findings, and block image deployment based on organization-defined policies. Consider the time of the scanning, as tools are continuously updated to detect new vulnerabilities, so more recent scans are more likely to be accurate.

DEPLOY-REQ-5: The release build scripts should be periodically checked for malicious code. Specific tasks to be performed include:

• A container image should be scanned for vulnerabilities as soon as it is built, even before it is pushed to a registry. The early scanning feature can also be built into local workflows.

• The tools used to interact with repositories store container images, and language packages should be capable of integration with the CD system, so they become part of automated CD pipelines.

Secure CD Pipelines - Case Study

GitOps automates deployment processes through tools like Argo CD and Flux, covering infrastructure and application code management. The document takes GitOps as a case study and defines security requirements that should be met to promise secure deployment.

GitOps-REQ-1: The process should rely on automation rather than manual operations. For example, manually configuring hundreds of YAML files to roll back a deployment on a cluster in Git should be avoided.

GitOps-REQ-2: Package managers that facilitate GitOps should preserve all data on the packages that were released, including version numbers of all modules, all associated configuration files, and other metadata as appropriate for the software operational environment.

GitOps-REQ-3: Another situation that should be avoided is manually applying changes directly into the nodes with a kubectl edit during runtime. This is to ensure that Git commits remain the single source of truth for what runs in the cluster.

GitOps-REQ-4: (Monitoring and Remediation for Drift) — Since the Git repository contains the application definitions and configuration as code, it should be pulled automatically and compared with the specified state of these configurations.

Streamlining SSDF Policies

The SSDF is very broad and comprehensive, and its high-level policies can take time to implement. NIST took it one step forward and delivered a more practical document that lays down the guidelines for building CI/CD pipelines that ensure the security of your software supply chain.

Stay One Step Ahead With Legit

This document offers valuable insights into enhancing software supply chain security and the future of secure software development. At Legit Security, we are dedicated to keeping you informed and secure in this ever-evolving landscape, providing solutions that seamlessly integrate these practices into your SDLC.

Ready to learn more? Schedule a product demo or check out the Legit Security Platform.