No products in the cart!
Please make your choice.View all catalog
The National Institute of Standards and Technology (NIST) published a new draft document that outlines strategies for integrating software supply chain security measures into CI/CD pipelines.
Cloud-native applications typically use a microservices architecture with a centralized infrastructure like a service mesh. These applications are often developed using DevSecOps, which uses CI/CD pipelines to guide software through stages like build, test, package, and deploy, akin to a software supply chain, according to the document.
“This breakdown is very helpful for development organizations, as it provides more concrete guidance on how to secure their environments and processes. One thing that stands out is the emphasis on the definition of roles and, closely related, the identification of granular authorizations for user and service accounts,” said Henrik Plate, security researcher at Endor Labs. “This is necessary to implement access controls for all activities and interactions in the context of CI/CD pipelines according to least-privilege and need-to-know principles. However, the management of all those authorizations across the numerous systems and services invoked during pipeline execution can be challenging.”
Recent analyses of software attacks and vulnerabilities have prompted governments and private-sector organizations in software development, deployment, and integration to prioritize the entire software development lifecycle (SDLC).
The security of the software supply chain (SSC) relies on the integrity of stages like build, test, package, and deploy, and threats can emerge from malicious actors’ attack vectors as well as from defects introduced when proper diligence is not followed during the SDLC, according to the NIST draft.
“It’s not surprising that the document acknowledges that the ‘extensive set of steps needed for SSC security cannot be implemented all at once in the SDLC of all enterprises without a great deal of disruption to underlying business processes and operations costs,” Plate explained.
This highlights the timeliness of providing guidance to organizations on implementing high-level recommendations like the Secure Software Development Framework (SSDF), which is a set of fundamental, sound, and secure software development practices based on established secure software development practice documents from organizations such as BSA, OWASP, and SAFECode, according to the NIST draft.
The NIST draft addresses the upcoming self-attestation requirement for software suppliers to declare adherence to SSDF secure development practices for federal agencies. The document aims to clarify expectations in the context of DevSecOps and CI/CD pipelines regarding what is considered necessary, according to Plate.
Plate added that one major concern with the draft is that tools that can improve the SSC like Sigstore and in-toto are not yet widely adopted with only a few open-source ecosystems including npm and select commercial services, having integrated it.
“It will require some time until those technologies are adopted more broadly in various open-source ecosystems and among open-source end users,” Plate added.
Organizations should go beyond simply detecting open-source software defects after they occur. They should also proactively manage open-source dependency risks by considering factors like code quality, project activity, and other risk indicators. A holistic approach to open-source risk management helps reduce both security and operational risks, as outlined in the Top 10 Open Source Dependency Risks, according to Plate.
This new draft by NIST is intended for a broad group of practitioners in the software industry, including site reliability engineers, software engineers, project and product managers, and security architects and engineers. The public comment period is open through Oct. 13, 2023. See the publication details for a copy of the draft and instructions for submitting comments.