A compromise of any of the steps, as well as the underlying CI/CD environments and platforms can have a downstream impact on the integrity of the software artifacts that are produced and distributed.
Organizations must take security measures for both internally developed (first-party) code, as well as third-party components, such as open source software, which are increasingly making up the bulk of modern software, at least from a source code perspective.
Organizations are ultimately looking to ensure that attackers cannot tamper with the software production process, introduce malicious software updates, or compromise the integrity of CI/CD pipeline artifacts and activities. NIST provides the below table demonstrating the artifacts that need to be trusted in typical CI/CD environments, as well as the repository the artifacts generally reside in/depend on:
| Artifact | Repository |
| First-party code – source code or binary | SCM |
| Third-party code – open source or commercial | Artifact managers for language, container, etc. |
| Builds | Build Repository |
| Packages | Package repository |
Software supply chain security in CI/CD pipelines
Now that we’ve discussed some of the background, security goals and entities involved in trusted CI/CD pipelines, let’s take a look at some of the specific SSC security activities that NIST emphasizes in their guidance.
It should come as no surprise that NIST evangelizes zero-trust principles here as well, given their publication of 800-207 “Zero Trust Architecture”. The recommendations cited include defining roles for system operators, mapped to specific permissions and implementing least-privileged access aligned with the concept of role-based access control (RBAC). Activities like these mitigate the risk should a specific actor’s account or assets get compromised.
NIST also recommends automating the use of SAST and DAST, as well as declaratively defining the development and deployment of application code and CI/CD activities through techniques such as infrastructure-as-code (IaC) and policy/configuration-as-code, which can specify runtime settings for security and compliance purposes. The workflows of CI/CD pipelines must also be secure, including build, push/pull of artifacts from repositories and software updates or code commits.
NIST recommendations for builds
On the build front, recommendations include key activities such as specifying build policies and the use of isolated build platforms as well as permissions for those performing build activities. Organizations should also make use of policy enforcement engines and ensure that during the software build process evidence and attestations of secure build processes is produced.
These may include attestations for the environment, process, materials, and artifacts involved. NIST recommends the use of hashing to include the final build artifact, files, libraries, and events that produce the final artifacts.
There is then a recommendation to sign the attestation and securely store it where it can be used to demonstrate policy compliance. Doing so can help demonstrate that software was built by authorized entities, tools and with alignment to defined policies and compliance requirements.
In addition to the need for secure build activities NIST also recommends securing pull-push operations on SCM repositories. This includes the pull of code from repositories by developers, its modification and then the push of code back to the repository, each of which presents an opportunity for tampering. Recommendations include automated security checks on artifacts, ensuring confidence in the source code origin, and requiring explicit approval for all outside collaborators looking to push and pull from a repository.
Bad actors slip malicious code into repositories
The below image from Francois Proulx demonstrates how a malicious actor can take various actions to gain unauthorized access to a GitHub repository and submit malicious code to a repository.
NIST demonstrates how a malicious actor can take various actions to gain unauthorized access to a GitHub repository.
Among its other key recommendations, NIST advises maintaining the integrity of evidence generation during software updates, securing code commits, and securing workflows in CD pipelines. Attackers may look to erase or tamper with software update trails to mitigate investigation and detective controls.
In addition, to ensure code commits don’t introduce malicious code or vulnerable code, NIST recommends the use of SAST/DAST tooling in CI/CD pipelines with broad language coverage, and the use of SCA tooling to verify the security of OSS components and dependencies.
Since CD pipelines revolve around workflows and many modern environments are making use of technologies such as containerization, NIST recommends ensuring that containers being deployed were actually generated by the defined build process and that they have been scanned for vulnerabilities in alignment with an organization’s vulnerability management requirements.
Lastly, given the myriad of high-profile secret exposures the industry has seen lately, NIST recommends organizations scan for the presence of secrets in code, such as keys or access tokens, which can be abused by malicious actors for nefarious purposes.
