The National Institute of Standards and Technology (NIST) published SP 800-218 — the Secure Software Development Framework (SSDF) — in 2022 alongside Executive Order 14028. At the time, it introduced a shared vocabulary for talking about secure software development and software supply chain risk, particularly for organizations building or selling software into government environments.
Since then, SSDF has settled into its role as a baseline reference for secure software development practices. While it isn’t a checklist or a certification, it provides a common structure for describing how software is built, protected, and maintained over time. That structure has made SSDF useful well beyond its original audience.
Today, organizations most often encounter SSDF either directly — through government requirements — or indirectly, through customer expectations around secure development, provenance, and vulnerability response. In both cases, SSDF serves as a practical framework for organizing those conversations.
What is NIST’s Secure Software Development Framework (SSDF)?
The Secure Software Development Framework (SSDF) is NIST’s guidance for reducing risk in the software lifecycle, from initial design through development, release, and post-release maintenance. It focuses on practices rather than tools, recognizing that organizations vary widely in size, architecture, and delivery models.
SSDF is intentionally flexible. It defines what needs to happen to support secure development without prescribing how to do it. That makes it adaptable, but it also means organizations need to interpret and apply it in ways that fit their existing processes and risk tolerance.
Rather than treating security as a one-time gate, SSDF frames secure software development as an ongoing effort that evolves alongside the software itself.
Four Core Practices of SSDF
SSDF organizes its guidance into four practice areas that map to how software is actually built and maintained over time. Instead of treating security as a single phase or gate, these practices reflect the reality that secure software development spans people, process, technology, and ongoing operations.
Each practice groups related tasks together so organizations can reason about where security responsibilities live across the lifecycle and how different activities support one another. The goal isn’t to force a rigid workflow, but to provide a structure that scales across teams, projects, and levels of maturity.
- Prepare the Organization (PO): This practice is about setting expectations before development begins. It focuses on defining security requirements, assigning responsibility, and making sure teams understand what “secure development” means in practice. When this groundwork is missing, security tends to become reactive and inconsistent.
- Protect the Software (PS): Protect the Software centers on safeguarding software and its related artifacts — source code, build outputs, and provenance data — from unauthorized access or modification. These controls help preserve integrity throughout development and release, especially as software moves through automated pipelines and shared environments.
- Produce Well-Secured Software (PW): This is where most people expect secure development to live. PW covers the day-to-day practices used while designing, building, and testing software, including secure coding, dependency management, and build system controls. The emphasis here is on reducing vulnerabilities early, when they’re cheapest to fix.
- Respond to Vulnerabilities (RV): No matter how strong your development practices are, issues will still surface after release. RV focuses on identifying vulnerabilities, prioritizing remediation, and communicating clearly with users and customers. This practice reinforces the idea that security doesn’t stop at deployment.
NIST then breaks out each of these practice areas further into specific tasks, along with example implementations and references. NIST captures this detail in a structured SSDF spreadsheet, which makes it easier to understand how individual tasks roll up into the broader framework.
It looks a little scary the first time you load it up, but it’s really not that bad. There are 42 controls. That’s actually a REALLY small number as far as NIST standards go. Usually you will see hundreds or even thousands.
An Overview of the NIST SSDF Spreadsheet
There are 4 columns: Practices, Tasks, Notional Implementation Examples, References
If we break it down further we see there are 19 practices and 42 Tasks. While this all can be intimidating, we can work with 19 practices and 42 tasks. The practices are the logical groupings of tasks, and the tasks are the actual controls we have to meet. The SSDF document covers all this in greater detail, but the spreadsheet makes everything more approachable and easy to group together.
The Examples Column
The examples column is where the spreadsheet really shines. The examples are how we can better understand the intent of a given control. Every control has multiple examples and they are written in a way anyone can understand. The idea here isn’t to force a rigid policy on anyone, but to show there are many ways to accomplish these tasks. Most of us learn better from examples than we do from technical control text, so be sure to refer to the examples often.
The References Section
The references sections are scary looking. Those are a lot of references and anyone who tries to read them all will be stuck for weeks or months. It’s OK though, they aren’t something you have to actively read, it’s to help give us additional guidance if something isn’t clear. There’s already a lot of security guidance out there, it can be easier to cross reference work that already exists than it is to make up all new content. This is how you can get clarifying guidance on the tasks. It’s also possible you already are following one or more of these standards which means you’ve already started your SSDF journey.
The Tasks
Every task has a certain theme. There’s no product you can buy that will solve all of these requirements. Some themes can only be met with policy. Some are secure software development processes. Most will have multiple ways to meet them. Some can be met with commercial tools, some can be met with open source tools.
Interpreting the Requirements
Let’s cover a very brief example: PO 1.3. 3rd party requirements. The text of this reads
Communicate requirements to all third parties who will provide commercial software components to the organization for reuse by the organization’s own software.
At first glance, this requirement revolves around communicating your security requirements to your suppliers. But today, the definition of “supplier” isn’t always obvious. You might be working directly with a company, but what if you’re relying on open source? Or a vendor that itself depends on open source? This is where the examples included in SSDF help clarify intent, such as requiring third parties to attest that their software complies with your security requirements.
Proving compliance can be difficult, even in the best situations, and it’s not something you can do in a single step. In practice, you first need to know what you have before you can define expectations for others. Once you understand your components — SBOMs are a practical way to establish that visibility — you can begin setting requirements and, eventually, supporting attestations. This is a good example of how SSDF often requires a combination of policy, process, and technology working together, rather than a single control or tool solving the problem on its own.
Where SSDF Fits in Today’s Compliance Landscape
SSDF isn’t a standalone compliance exercise. It’s best understood as the common reference point behind many of the secure software requirements organizations are already being asked to meet. If you’ve seen questions about secure development practices, provenance, or supplier attestations, you’re probably already brushing up against SSDF, whether it’s named explicitly or not.
- Executive Order 14028 (Improving the Nation’s Cybersecurity): SSDF provides the practical framework behind the secure software development expectations outlined in EO 14028, particularly for federal agencies and their software suppliers.
- Secure Software Attestation: The attestation requirements for federal software suppliers map directly to SSDF practices, making SSDF the clearest reference point for demonstrating secure development processes.
- FedRAMP: While FedRAMP focuses on cloud service authorization, SSDF supports the secure development controls and evidence expectations that FedRAMP assessors increasingly look for in software components.
- DoD & National Security Programs: SSDF aligns closely with DoD expectations for secure software supply chains, particularly around provenance, vulnerability management, and secure build practices, all of which are foundational to modern DoD software factory models.
- NIST SP 800-53: SSDF complements 800-53 by focusing specifically on how software is built, rather than broader system and organizational controls.
In practice, most organizations don’t “adopt SSDF” in isolation. They use it as the baseline for aligning secure software development with a growing set of overlapping security and compliance expectations.
Even outside of government work, SSDF often shows up indirectly, and it looks a lot like the questions enterprises already ask about secure development and software supply chain risk.
Tips for implementing across the software development life cycle (SDLC)
If this is your first time trying to comply with a NIST standard, keep in mind this will be a marathon. Nobody starts following the entire compliance standard on day one. Make sure to set expectations with yourself and your organization appropriately. Complying with a standard will often take months. There’s also no end state, these standards need to be thought about as continuous projects, not one and done.
- Make SBOMs the operational backbone of your SDLC: If you take only one thing away from SSDF, it should be this: you can’t secure what you don’t know you have. SBOMs are the most practical way to establish that baseline. They give you a concrete inventory of components and dependencies and become the connective tissue across multiple SSDF practices — from defining third-party requirements to responding to vulnerabilities. Treat SBOMs as living artifacts generated as part of your build and release process, not something you scramble to assemble when someone asks for proof.
- Start by preparing the organization before touching tooling: It’s tempting to jump straight to tools and automation, but SSDF doesn’t work unless the organization is ready for it. That means writing down security requirements, deciding who owns them, and making sure the right teams know they exist. This isn’t about perfect documentation — it’s about making expectations explicit. When security requirements are clear and shared early, everything downstream becomes easier to implement and easier to defend.
- Assume your build systems are part of your attack surface: Build systems, compilers, and interpreters tend to get treated as plumbing — something that “just works.” SSDF pushes back on that assumption, and for good reason. If your build environment is compromised, it doesn’t matter how clean your source code is. Keeping build tools up to date, running clean and repeatable builds, and isolating build environments helps reduce entire classes of risk that are otherwise very difficult to detect later.
- Protect provenance data as carefully as the software itself: Generating SBOMs and other provenance data is only half the job. You also need to store and distribute that information securely so it remains trustworthy over time. If provenance data can be altered, lost, or inconsistently generated, it stops being useful. Treat this data as evidence — because that’s what it is — and apply the same access controls and integrity checks you would to other critical artifacts.
- Integrate SSDF requirements into existing workflows instead of inventing new ones: One of the fastest ways to fail at SSDF is to create a parallel “security process” that developers have to remember to follow. The better approach is to embed SSDF practices into the workflows teams already use — CI/CD pipelines, build jobs, release processes, and ticketing systems. When security happens automatically as part of normal development work, it’s more consistent and far less fragile.
- Plan for incremental progress, not full compliance on day one: SSDF is intentionally flexible because no two organizations look the same. Trying to meet every task immediately usually leads to frustration and burnout. A more realistic approach is to prioritize based on risk, start with visibility and inventory, and build maturity over time. This isn’t a one-time project — it’s an ongoing effort that improves as your processes improve.
Learn More About the Secure Software Development Framework
Practice Group Deep Dives
- Spotlight on P0.1 – Prepare the Organization
- Spotlight on PW.6 – Build Systems
- Spotlight on PW.6 Compilers and Interpreter Security
- Spotlight on PS.3.2
Attestation & Compliance
- SSDF Attestation Template: Battle-tested Compliance Guidance
- Using the Common Form for SSDF Attestation: What Software Producers Need to Know
- Solutions for Automating NIST Compliance
Your Next Steps
SSDF is intentionally flexible, which means moving forward looks different for every organization. The common thread is turning intent into practice — establishing visibility, automating where it makes sense, and building repeatable processes that hold up as software and teams scale.
Anchore helps teams do exactly that, whether you’re experimenting and learning through open source tools like Syft and Grype, engaging with the community on Anchore’s community Discourse, or implementing enterprise solutions to manage SBOMs, scan for vulnerabilities, and automate compliance across the SDLC. However you approach it, the goal is the same: make secure software development something that works in practice, not just on paper.
Josh Bressers
Josh Bressers is vice president of security at Anchore where he guides security feature development for the company’s commercial and open source solutions. He serves on the Open Source Security Foundation technical advisory council and is a co-founder of the Global Security Database project, which is a Cloud Security Alliance working group that is defining the future of security vulnerability identifiers.
