A new draft from NIST, developed in collaboration with 14 industry partners, outlines how to build software with security baked in, not bolted on.
This is part of a broader push to protect the software supply chain, and it’s open for public comment until 12 September 2025.
The guidelines are a response to Executive Order 14306, issued in June, which called for sustained action to strengthen national cybersecurity. NIST’s National Cybersecurity Center of Excellence (NCCoE) is leading the work through a newly formed Software Supply Chain and DevOps Security Practices Consortium.
The goal is simple, if ambitious: help organizations build, test, and deploy software that’s more resilient, less exposed, and easier to trust.
Practical Guidance, Not Theory
The draft, NIST Special Publication 1800-44, offers a high-level overview for now. Future iterations will go deeper, with reference models and implementation guidelines tied to real-world use cases.
It expands on the Secure Software Development Framework (SSDF), which NIST released in 2022. That framework laid out what secure development should look like. This one starts to show how.
Alper Kerman from the NCCoE, who is one of the publication’s authors, said: “The SSDF looks at building software holistically, helping organizations figure out what needs to be done to make their development environment more secure, how to protect it and find deficiencies that make it vulnerable.”
He added that the draft guidelines being devloped will show how firms can use commercial, off-the-shelf technologies and AI capabilities, and apply zero trust principles and methodologies to drive “an efficient and secure development environment for producing fast and more reliable software.”
Security From the Ground Up
The consortium’s focus is on the full software development life cycle. Planning. Building. Testing. Releasing. Operating. At each stage, the surface area for attack grows. Left unchecked, vulnerabilities accumulate.
“You have to have an environment to write code in, where the whole team of developers can access it and update the code in an agile fashion,” Kerman added. “But when you are writing code, a team member might bring in code libraries from other parties, for example. We will outline best practices for minimizing the likelihood that vulnerabilities might creep in as a result, such as effective ways to scan the code for trouble spots.”
The draft will guide teams on setting up secure development environments that balance access with control. It includes advice on scanning for vulnerabilities, managing third-party components, and identifying weak links early, before they go live.
Open to Input
NIST is inviting public feedback and will release updated drafts as the project progresses. The team will hold a virtual event on 27 August at 1 p.m. EDT, during which they will walk through the project and answer questions.
Registration is open online.
Participation isn’t limited to the big players. NIST has opened a Community of Interest, welcoming any organization with a stake in secure software development. Input can also be sent directly to: [email protected].
Developing Secure Software
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.”
With this NCCoE effort, Mackey added that 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.”
Playing Catch-up with Industry Best Practices
Trey Ford, Chief Information Security Officer at Bugcrowd believes this is an instance of government workflows playing catch-up with industry best practices, and organizing a standardized framework reflecting how companies are operating in private industry.
“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,” he said.
“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.”
According to Ford, 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.
Information Security Buzz News Editor
Kirsten Doyle has been in the technology journalism and editing space for nearly 24 years, during which time she has developed a great love for all aspects of technology, as well as words themselves. Her experience spans B2B tech, with a lot of focus on cybersecurity, cloud, enterprise, digital transformation, and data centre. Her specialties are in news, thought leadership, features, white papers, and PR writing, and she is an experienced editor for both print and online publications.
The opinions expressed in this post belong to the individual contributors and do not necessarily reflect the views of Information Security Buzz.