The National Institute of Standards and Technology’s new proposed guidelines for integrating software supply chain security into CI/CD pipelines have arrived at an opportune time for security teams, with attacks on the software supply chain increasing in volume and sophistication.

With the proposed guidelines (NIST SP 800-204D) for continuous integration and continuous deployment (CI/CD) pipelines, NIST aims to help developers build more secure software by addressing risks in the supply chain, rather than just responding to vulnerabilities after the fact. The guidelines emphasize practices such as using secure component sources, validating third-party code, and monitoring for vulnerabilities.

Philip George, an executive technical strategist with Merlin Cyber, said that among the objectives of adopting DevOps and other modern development approaches are increases in coding efficiency and release frequency. However, organizations can be so focused on those performance boosts that they fail to incorporate security into their newly adopted CI/CD strategy, resulting in a net increase in potential vulnerabilities.

The NIST guidelines, expected to be finalized in 2024, are broadly welcomed, but putting them into practice may be challenging for some organizations. Here’s what your organization needs to know about the new NIST guidelines for supply chain security in CI/CD environments.

[ Analysis: Fed CI/CD security guidance: Been there, done that | Learn more: 8 CI/CD best practices: Secure your software development pipeline ]

A response to the evolution of software development

Justin Cappos, a professor in the computer science and engineering department at New York University’s Tandon School of Engineering, said guidance about how to do software supply chain security is needed, “especially guidance from a trusted source like NIST, guidance that is vendor-neutral, and guidance that is really putting achievable security at the forefront of recommendations.”

Cappos said the supply chain security problem is compounded by the increasing push to migrate from traditional application hosting environments to cloud environments, which puts even greater pressure on development teams to use cloud microservices while also supporting legacy codebases.

Tom Molden, CIO for global executive engagement at the security firm Tanium, said that with software development and architectures evolving — enabling much of the software to be built with standard components that can be reused — such guidelines are key. “[Today’s software] can be thought of like building a pre-fab house, where parts of the house that are standard can be built with far greater efficiency and quality in a factory setting, with the truly valuable and customized parts of the house left to the builder or craftsman on site.”

“As the software development world evolves at pace, the opportunities for security exposure multiply, so the controls frameworks that have been built to help companies safeguard the software they build and deploy need to evolve as well.”
—Tom Molden

John Gallagher, vice president of the IoT security firm Viakoo Labs, said the proposed NIST guidelines are timely because more organizations are focusing their development efforts on so-called MACH architectures (microservices-based, API-first, cloud-native, and headless), where DevSecOps is critical to building a secure product.

“While these guidelines on their own may not prevent software supply chain breaches, they will be part of preventing them in combination with SBOMs, digital signatures or attestation of components, and automated remediation methods.”
—John Gallagher

Merlin Cyber’s George noted that some of the notable software supply chain attacks of recent times, including SolarWinds, Codecov, and Kaseya, could have been foiled if organizations had been following the guidelines in NIST’s document, SP 800-204D.

“By incorporating the security principles posited by SP 800-204D, organizations can take a more structured approach to automating software supply chain products, like an SBOM and accompanying cryptographic bill of materials, to ensure both an accurate implementation of authentication mechanisms, trap for token/certificate re-use, and identify exposed shared secrets in code libraries.”
—Philip George

Who are the NIST guidelines for?

John Bambenek, a principal threat hunter with Netenrich, said the guidance as constructed may be more useful to security operations (SecOps) teams than development teams. “Threat actors have realized that some of the easiest ways to compromise many organizations is to attack the CI/CD pipeline for commonly used software and to take advantage of the DevOps development velocity to integrate malicious code,” he said.

“These guidelines are high level and really only useful for auditors who might want to check that various controls are in place. They seem to abstract away what has already been said in the wake of previous supply chain compromises.”
—John Bambenek

All together now on CI/CD security

The NIST guidelines discuss risk factors such as developer environments, threat actors, attack vectors, targeted assets, and exploit types and recommend mitigations such as patch management, access control, malware protection, secure SDLC practices, data protection, physical security, monitoring, and standards adherence.

NIST also provides background on CI/CD pipelines that automate the stages of transforming source code into deployable packages using workflows, and it states two security goals for integrating software supply chain security into CI/CD pipelines:

• Incorporate defensive measures so attackers cannot tamper with processes or introduce malicious updates
• Ensure the integrity of pipeline artifacts and activities through role definitions and authorizations

Strategies for securing workflows in CI pipelines in the NIST guidelines include: 

• Secure builds
• Secure pull/push operations on repositories
• Integrity of evidence generation during software updates
• Secure code commits

For CD pipelines, the guidelines cover controls including:

• Verifying that artifacts originate from a secure build process
• Scanning images for vulnerabilities before deployment
• Avoiding secrets in code ready for deployment

The document also maps its recommended security tasks to the high-level practices in NIST’s secure software development framework (SSDF). For example, specifying secure build policies maps to defining security requirements, and ensuring the integrity of evidence generation maps to providing mechanisms for verifying software release integrity.

Tanium’s Molden said that though they are long-winded, NIST’s frameworks are useful in that they take a very comprehensive approach to security controls. “They think things through thoroughly and develop a ton of detailed information,” he said.

“One way to think of it is, they have done the work for you, and thank goodness someone is doing that. A reference framework like NIST, which is so commonly adopted around the world, means that all stakeholders involved in protecting the environment are reading the same sheet of music.”
—Tom Molden

Netenrich’s Bambanek said the guidelines would help with getting SecOps in alignment on risk associated with the supply chain and CI/CD environments.

“Mapping to known frameworks provides the tools for auditors to begin to question aspects of the CI/CD pipeline and, unfortunately, one of my most useful tools as a security professional is relying on auditors to give me findings to justify change.”
—John Bambenek

Implementation may prove challenging

Viakoo Labs’ Gallagher said the new NIST guidelines are “a nice-to-have” for security teams, but implementation may be challenging for some organizations. “These guidelines should help to make teams more efficient, but there will always be pressure to push out code that is not fully verified as secure,” he said.

“At a high level, the sheer number of software artifacts used and how often they change conflicts with the time-to-market pressures all development teams face. In the race to push out new features and capabilities, many organizations accumulate technical security debt.”
—John Gallagher

Another challenge will be finding the tools and logging to provide the basic pieces to find supply chain failures, said Bambenek.

“It’s one thing to say only trusted developers should be able to commit code into the build process; it’s another to be able to detect, alert, and prevent unauthorized users from doing so, or to detect a malicious insider or someone whose taken over an authorized account from doing so.”
—John Bambenek

*** 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/nists-supply-chain-security-guidelines-for-ci/cd-what-you-need-to-know