From Theory to Practice: Navigating NIST’s CI/CD Security Strategies
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 to 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.
This blog post delves into the new NIST publication: SP 800-204D. As the document is still an Initial public draft (IPD), we’ll keep updating as the document evolves.
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:
-
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.
-
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.
-
Materials Attestation: Any raw data and can include configuration, source code, and other data.
-
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.
Secure Pull-Push Operations on Repositories:
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 sourcecode origin.
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.
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
Securing Workflows in CD Pipelines
DEPLOY-REQ-1: It should be possible to specify that the artifact being deployed must have been generated by a secure build environment and process in order to be cleared for deployment.
DEPLOY_REQ-2: check for evidence that the container image was scanned for vulnerabilities and attested vulnerability findings, and block image deployment based on organization-defined policies.
DEPLOY-REQ-3: 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-4: Before merging pull requests, it should be possible to view the details of any vulnerable versions through a form of dependency review.
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 a 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
While the SSDF is very broad and comprehensive, 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 assure the security of your software supply chain.
Stay One Step Ahead with Legit
While this document is still in its Initial Public Draft stage, it 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.
*** This is a Security Bloggers Network syndicated blog from Legit Security Blog authored by Neta Spektor. Read the original post at: https://www.legitsecurity.com/blog/navigating-nists-ci/cd-security-strategies
