New from NIST: Securing the Software Supply Chain

For cybersecurity professionals, the software supply chain has become a primary attack surface, making secure software development a critical imperative. In response to this escalating threat and a June 2025 executive order to strengthen national cybersecurity, the U.S. National Institute of Standards and Technology (NIST) has released a significant new preliminary draft: NIST Special Publication (SP) 1800-44A, "Secure Software Development, Security, and Operations (DevSecOps) Practices."

DevOps, a modern approach to software development, focuses on shortening development cycles and boosting efficiency through collaboration, automation, and continuous improvement. However, as cyber threats grow in complexity and volume, the integration of security from the outset—DevSecOps—becomes non-negotiable.

NIST highlights several compelling reasons for the growing adoption of DevSecOps practices:

• Mitigating cyber threats: Software development environments are prime targets. DevSecOps helps organizations build more resilient systems against attacks preying on overlooked security practices, cloud misconfigurations, and weak access controls.

• Addressing third-party component vulnerabilities: Modern software heavily relies on third-party components, often with little visibility into their development or security practices. DevSecOps tools can scan, identify, and eliminate vulnerabilities in these components early in the development lifecycle.

• Leveraging AI responsibly: Artificial intelligence (AI) is increasingly used for threat detection, security testing, and automation within DevSecOps, improving efficiency and quality. However, the guide also emphasizes the need for human oversight and verifiable processes to ensure the accuracy and trustworthiness of AI-generated content.

"With software supply chain attacks skyrocketing, having practical DevSecOps implementation detail, not just theory, is gold for cybersecurity teams," said Kip Boyle, vCISO, Cyber Risk Opportunities LLC. "The Zero Trust integration and real-world examples will finally help organizations move beyond security theater to actually building resilient development pipelines. Every CISO should be reviewing this draft."

Boyle is teaching a PLUS Course on the NIST Cybersecurity Framework v2.0 as part of SecureWorld Detroit on Sept. 10, the day before the Sept. 11 conference (now in its 23rd year) at the Suburban Collection Showplace in Novi.

The document outlines several core challenges in producing software more securely:

• Integration: Orchestrating diverse tools, automations, and services in modern software development to enforce security requirements is complex and time-consuming.

• Attestation: Generating consistent and well-defined evidence that security requirements have been met remains a challenge.

• Visibility of third-party components: Managing cybersecurity risk from commercial or open-source third-party components (a crucial aspect of Cybersecurity Supply Chain Risk Management, C-SCRM) is difficult due to often opaque development practices.

• Emergence of AI tools: While AI offers significant potential, defining the security requirements for its employment in software development is still evolving.

"Securely developing software in 2025 is much more than hiring a bunch of developers and giving them requirements," said Tim Mackey, Head of Software Supply Chain Risk Strategy at Black Duck. "Modern applications are a combination of code from many sources; some that a development team might have direct control over, while others like open-source libraries or AI coding assistants represent code whose quality or security testing might be suspect. While development teams are quite comfortable with agile development pipelines where code is assembled, built, and tested, if those environments aren't properly secured or trusted, then applications built in those pipelines are also suspect."

Mackey added, "In this NCCoE effort, a DevSecOps model is defined that starts with a foundation created using Zero Trust Architecture (ZTA) principles onto which a fully formed Software Development Life Cycle (SDLC) is added. The effort recognizes that modern software development occurs in a heterogeneous environment consisting of technologies from many vendors—and that a holistic view of cybersecurity is needed."  

"This is a case of government workflows playing catch-up with industry best practices, and organizing a standardized framework reflecting how companies are operating in private industry," said Trey Ford, CISO at Bugcrowd. "There is a solid list of contributing organizations from security-minded software firms in this working group—AWS, Google, and Oracle are notably missing—as well as some of the folks from Travis, CircleCI, Spinnaker, and other cloud-native platforms."

Ford continued, "In the reference model, we need to see VDP and Bounty feedback explicitly named in support of CISA's Binding Operational Directive 20-01 VDP requirements. Zero Trust has a strong reference point in the initial draft, leaning heavily on configuration or environmental variables and establishing hard-coded secrets hygiene should be called out."

NIST's project aims to address these challenges by documenting example implementations.

The SP 1800-44A introduces a Notional Reference Model for DevSecOps. This model guides the construction of software development processes that embed security continuously. It defines seven phases, each with integrated security considerations:

1. Plan: Collaborative definition of requirements and secure practices.

2. Develop: Proactive code review and use of approved tools for quality and security.

3. Build: Automated pipelines transforming code into deployable artifacts with integrated analysis.

4. Test: Automated testing in ephemeral environments to evaluate functional and security requirements.

5. Release: Automated packaging and transfer to production, with coordination and documentation.

6. Deploy: Automated installation and configuration, with continuous monitoring.

7. Operate: Continuous monitoring and evidence collection to ensure integrity, security, and reliability.

A crucial element is the Feedback Cycle, ensuring that events or signals from "control gates" (technical or organizational controls enforcing checks) or external events (like new attack patterns) inform earlier phases of the lifecycle.

A significant aspect of this guidance is the integration of Zero Trust principles. The project explores how a Zero Trust security strategy can strengthen DevSecOps environments by:

• Shrinking implicit trust zones

• Mitigating breach risks through rigorous authentication and authorization for every access request

• Employing continuous monitoring, vulnerability scanning, integrity verification of artifacts, and code commit/signature verification throughout the development lifecycle

The project will showcase a practical Zero Trust Architecture (ZTA) implementation to manage policy-driven access throughout DevSecOps.

This publication is a "First Preliminary Draft," and NIST is actively seeking feedback from the cybersecurity community. Comments on this draft can be submitted to nccoe-devsecops@list.nist.gov by September 14, 2025. A virtual event to discuss the project and gather further feedback is also planned for August 27, 2025.

For cybersecurity professionals, SP 1800-44A offers vital, practical details concerning DevSecOps implementations that can help evaluate existing "software factories," identify gaps, and enhance cybersecurity for both software producers and consumers. This initiative is a proactive step towards building a more secure software ecosystem for everyone.