The final version of guidelines to help organizations secure their software supply chain has been released by the National Institute of Standards and Technology (NIST). The document, “Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines (NIST SP 800-204D),” delivers actionable measures software development organizations can use to integrate the various building blocks of software supply chain security assurance into their continuous integration/continuous delivery (CI/CD) pipelines.

NIST outlines strategies for integrating software supply chain security assurance measures into CI/CD pipelines to protect the integrity of the underlying activities. The overall goal is to ensure that CI/CD pipeline activities are secure through the build, test, package, and deployment stages.

Chris Hughes, co-founder and CISO of Aquia, said NIST wanted to update its guidance to be applicable to modern software development build and release processes.

“The guidelines blend together the trend of DevOps turning into DevSecOps with software supply chain security. It brings the value of both of those domains together to talk about how to bolster software supply chain security.”
—Chris Hughes

Hughes said the new guidance also talks about something that hasn’t got a lot of attention in software supply chain security discussions: the need for attestation, to have assurances throughout the entire software development lifecycle (SDLC) about what was done, when it was done, during what phase, by whom, and on what machine.

Here are three key considerations derived from the NIST guidance for securing CI/CD environments. 

[ See related: A definitive guide: Federal software supply chain security initiatives | Key takeaways: The State of Software Supply Chain 2024 | Download the full report ]

1. Secure your builds with software attestation

Several areas of attestation during the build stage of software are highlighted in the document. They include:

• Environment attestation, which involves an inventory of the system when the CI process happens and generally refers to the platform on which the build process is run. NIST recommends that the components of the platform be hardened, isolated, and secure.
• Process attestation, which focuses on the computer programs that transform source code or materials into an artifact or the programs that perform testing on that code.
• Materials attestation, which refers to any raw data and can include configuration, source code, and other data, such as dependencies.
• Artifacts attestation, which includes the result or outcome of a CI process, such as running a compiler or SAST tool. In the case of the compiler, the artifact would be the binary from the source code crunched by the compiler. In the SAST case, the artifact would be the results of scanning the code.

NIST recommends that all attestations be cryptographically signed using a secure key and that the keys be stored in a secure location that is tamper-proof and protected with robust access control.

2. Use zero trust to secure the complete software supply chain

Developers can be a source of risk to a software supply chain, the NIST document stresses. Developer workstations and their environments present a fundamental risk to the security of a software supply chain and should not be trusted as part of the build process since they are at risk of compromise. Mature SDLC processes should accept code and assets into their software configuration management mainline and version branches only after code reviews and scanners are in place.

The document also supported the use of zero-trust architectures to secure software supply chains. Zero-trust architectures focus on protecting resources such as hardware systems, services, and the application itself, NIST explained. Zero trust assumes that all entities that access these resources are not to be trusted; the primary goal of zero-trust architecture is to establish trust.

In the context of CI/CD pipelines, NIST continued, the scope of trust is much larger and requires, at a minimum, the following steps:

• The entities involved in performing various software supply chain activities, such as building, packaging, and deployment, should be authenticated through the verification of credentials. Based on this authentication, appropriate permissions or access rights should be assigned to those entities based on enterprise business policies through a process called authorization.
• The integrity of artifacts and the repositories where they are stored should be ensured through the verification of the digital signatures associated with them. Through that integrity assurance, trust can be established.
• The establishment of trust should be a recurring process throughout the CI/CD system, since artifacts travel through various repositories to ultimately become the final product.
• The inputs and outputs of each build step should be verified to ensure that the correct steps have been executed by the expected component or entity.

3. Cloud-native is key — with a DevSecOps emphasis

The NIST guidelines are written for teams using DevSecOps, so they will be more valuable to some organizations than others, said Hughes.

“If you’re not using DevOps or DevSecOps development methodologies, then you’re looking at quite a bit of change to get to this level of maturity.”
-Chris Hughes

The same goes for cloud-native environments, which will find it easier to implement the NIST guidance. “[Adding] some of the techniques and methodologies that NIST is advocating shouldn’t be quite as cumbersome or challenging as it would be for a legacy on-premises environment where you might have to do a major re-architecting of your entire software development process,” Hughes said.

Philip George, an executive technical strategist at Merlin Cyber, said the guidelines are welcome because they do something that security practitioners have struggled with for years:

“They present cybersecurity objectives as a development task and not just a cyber-outcome. Developers understand coding processes and methods better than cyber-risk ratings and outcomes. As such, effectively communicating supply chain security requirements in a manner best understood by the development community should prove to be more effective than prior methods.”
—Philip George

Upgrading CI/CD security demands modern tooling

The automation and complexity of CI/CD pipelines and processes can introduce significant security risks to the development process if organizations don’t plan carefully. Not only do organizations need to ensure that security checks are built into the fast-paced workflow of CI/CD processes, but the tools and integrations of the CI/CD pipeline itself must also be protected.

A critical flaw in the CI/CD tool JetBrains Team City came to light in September of 2023 and was being actively exploited by October. This highlights the importance of securing your CI/CD pipeline.

Matt Rose, field CISO at ReversingLabs, wrote recently that the complexity of modern development calls for modern tools to manage risk across the SDLC.

“While legacy AppSec testing (technologies such as SAST, DAST, RASP, and SCA) focuses on application source code, packages, and an application at runtime, what you receive from vendors is binaries — which is why binary analysis of the compiled packages is where you should be looking to identify risks.”
—Matt Rose

Rose said that enhancing CI/CD security require a final exam for your software packages before release. Such final checks can be delivered by modern tools including complex binary analysis, which the Enduring Security Framework (ESF), a public-private working group led by the National Security Agency (NSA) and CISA, has called for in its guidance.

*** This is a Security Bloggers Network syndicated blog from ReversingLabs Blog authored by John P. Mello Jr.. Read the original post at: https://www.reversinglabs.com/blog/nist-supply-chain-security-guidance-for-ci/cd-3-ways-to-pump-up-your-program