NIST 800-218 SSDF gap analysis: what development teams actually get wrong
Sienna VanceApril 29, 2026
Key takeaways
SSDF gap analysis consistently finds enforcement failures rather than tool absences: security gates that run in CI/CD pipelines but do not block deployment when they produce findings are not implemented controls under NIST 800-218.
EO 14028 and OMB M-22-18 require software vendors selling to federal agencies to attest that their development practices conform to SSDF. An attestation submitted without evidence of RV.1 vulnerability tracking or PS.3 SBOM currency carries the same legal exposure as an inaccurate NIST 800-171 SPRS score.
SBOM generation at build initiation and SBOM generation at artifact finalization are not equivalent. Dependency updates between the two points produce SBOMs that do not reflect the delivered component inventory -- the gap that regulators and procurement reviewers are examining.
The Respond to Vulnerabilities practice group (RV) is the SSDF area most frequently found unimplemented in Vulnox assessments: vulnerability identification processes exist; remediation tracking through to closure verification does not.
Transitive dependency coverage is the SBOM gap that creates the most supply chain exposure. Most development teams can produce a direct dependency inventory. Few maintain accurate transitive dependency tracking through dependency updates.
SSDF does not prescribe specific tools. It prescribes outcomes. A gap analysis that inventories tools rather than verifying that those tools produce the outcomes SSDF requires will consistently undercount the actual gap.
TL;DR
SSDF compliance programs tend to be tool-complete and process-incomplete. The SAST scanner is installed. The dependency checker runs. The SBOM gets generated. None of these facts mean the controls are implemented if builds proceed despite findings, SBOMs drift from the actual component inventory, and vulnerability remediation timelines are tracked in a spreadsheet nobody updates. The gap analysis that finds the tools and marks the controls implemented is not an SSDF gap analysis.
The pipeline that looked secure and wasn't
A SaaS company selling to federal agencies submitted their SSDF attestation under OMB M-22-18 based on an internal assessment conducted by their engineering team. The assessment confirmed that SAST scanning ran on every pull request, SBOM generation was integrated into their build process, and they had a documented vulnerability response policy. All three points were accurate. The SAST scanner was configured in warn mode -- findings were logged but did not block merges. The SBOM was generated at the start of the build, not at artifact finalization, meaning dependency updates that occurred between build initiation and release were not captured. The vulnerability response policy documented a 30-day remediation SLA for high-severity findings; the engineering team had no system for tracking whether findings were actually closed within that window.
A federal procurement review twelve months after the attestation submission requested SSDF evidence artifacts. The agency asked for build logs demonstrating that security gate failures had blocked deployments in the prior quarter. There were none. They asked for an SBOM for the most recent release that matched the artifact hash. The submitted SBOM was from build initiation and did not match. They asked for closure verification records for high-severity findings identified in the prior six months. Three findings had exceeded the 30-day SLA with no documented remediation status. The attestation was accurate about what processes existed. It was not accurate about whether those processes functioned.
What the four SSDF practice groups require as evidence, not intention
NIST 800-218 organizes the SSDF into four practice groups, each with specific practices and tasks. The practice groups are: Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW), and Respond to Vulnerabilities (RV). Each practice has associated tasks, and each task has example implementations and notional implementation examples that describe what functioning implementation looks like.
The evidence standard is operational. SSDF does not require specific tools. It requires specific outcomes, demonstrated through consistent operational behavior. PW.2.2 -- which covers code review for security -- is implemented when code review processes consistently check for security issues and findings are addressed before code merges. It is not implemented when code review guidelines exist as a policy document. The distinction matters for gap analysis: evaluating documentation versus evaluating system behavior produces different gap counts.
The practice group that produces the largest gap in organizations with established DevSecOps programs is RV -- Respond to Vulnerabilities. Most organizations have vulnerability identification processes: SAST runs in the pipeline, SCA checks dependencies, penetration tests run periodically. The RV gap is in the back half: tracking identified vulnerabilities through to verified remediation, maintaining coordinated disclosure processes for externally reported issues, and feeding vulnerability data back into development process improvements. Identification without tracked remediation is not an implemented RV control.
Example
In a Vulnox SSDF assessment of a software company with a three-year-old DevSecOps program, the pipeline included SAST, DAST, SCA, and container scanning. Every scan ran on every build. The gap analysis found that 73% of high-severity findings identified in the prior six months had no recorded remediation status -- they had been identified, logged in the scanning tool, and never tracked to resolution. The vulnerability response policy documented an SLA. The engineering workflow had no mechanism for enforcing it. The SSDF RV.1.2 practice -- which requires tracking the resolution status of identified vulnerabilities -- was not implemented despite the scanning tools running continuously.
SSDF tasks include 'example implementations' that are illustrative rather than prescriptive. The SSDF does not require any specific tool. It does require that whatever process the organization uses produces consistent, verifiable outcomes. A gap analysis that accepts the presence of a scanning tool as evidence of a RV.1.2 implementation is accepting the example implementation as a substitute for the practice itself. The correct question is: can the organization demonstrate, with records, that identified vulnerabilities are tracked to closure within documented timelines?
What SSDF gap analyses find in mature DevSecOps programs
Assessment base: Vulnox SSDF assessment data, 2024-2025, across SaaS companies, federal contractors, and software vendors with established DevSecOps programs under EO 14028 compliance obligations.
Security gate enforcement configured for visibility rather than blockage
In Vulnox SSDF assessments, the most consistent PW-group finding in organizations with established CI/CD pipelines is security scanning configured in warn mode. SAST runs on every pull request and produces findings. The pipeline continues regardless of finding severity. The rationale is typically developer experience: blocking merges on SAST findings produced too many false positives, so the gate was downgraded to advisory. The findings are visible. They are not addressed before code merges. PW.2.1 requires that security testing findings are addressed -- not that security testing runs. An advisory-mode gate satisfies the tool presence check and fails the practice implementation check.
The gap between a blocking security gate and an advisory one is not a tool configuration question -- it is a process maturity question. Organizations that downgraded blocking gates due to false positive rates have an underlying problem with tuning scan configurations, not with gate enforcement. The correct remediation is tuning the scanner to reduce false positives and restoring block-on-failure behavior, not accepting advisory mode as equivalent.
SBOMs generated at build initiation rather than at artifact finalization
SBOM generation is present in most DevSecOps pipelines that have addressed EO 14028 compliance. The consistent finding is timing: SBOMs are generated early in the build process, before dependency resolution is complete. Dependency updates, lock file regeneration, and transitive dependency resolution that occur between SBOM generation and artifact finalization produce a delivered artifact whose component inventory differs from the SBOM submitted for compliance. In one Vulnox assessment, the SBOM for a delivered software release listed 847 components. A post-delivery SBOM generated from the release artifact identified 923. The 76-component difference was entirely in transitive dependencies updated during the build.
An SBOM that does not accurately reflect the delivered artifact's component inventory does not satisfy the supply chain transparency purpose of EO 14028 SBOM requirements. It also does not provide accurate input to vulnerability scanning tools that use SBOM data to check for known-vulnerable components. The fix is generating SBOMs from the finalized artifact rather than from the build environment -- a pipeline sequencing change, not a tool change.
Third-party dependency additions with no documented security review
SSDF Practice PS.3 requires tracking provenance of software components and verifying their integrity. In Vulnox assessments, the implementation gap for PS.3 is almost always the same: the organization has a process for verifying existing dependencies but not for reviewing new ones at the point of introduction. Developers add dependencies through package managers without triggering any review of the component's maintenance status, known vulnerability history, or provenance. An npm package added to a project last Tuesday has the same absence of review process as one added three years ago. The gap analysis finds 40 to 60 new dependency introductions per quarter with no recorded review against PS.3 criteria.
Supply chain attacks targeting development environments specifically exploit the window between dependency introduction and security review -- or the absence of any review. XZ Utils was maintained by a malicious actor for two years before the compromise was discovered. A PS.3 implementation that reviews existing dependencies but not new ones provides no protection against the threat category it was designed to address.
The mature DevSecOps program that had more SSDF gaps than the immature one
Common belief
Organizations with established DevSecOps programs -- multiple scanning tools, automated pipelines, dedicated security engineering teams -- typically expect their SSDF gap analysis to be a confirmation exercise. The tools are in place. The processes are documented. The gaps, if any, should be minor.
What we found
In one assessment of a company with a five-year DevSecOps program, the gap analysis found 14 separate security gate enforcement behaviors that had been downgraded from block to warn over the prior 36 months. Each downgrade was documented in an engineering decision record. None had been reviewed against SSDF practice requirements. The cumulative effect was a pipeline that ran security scanning comprehensively and enforced none of it.
In Vulnox SSDF assessments, organizations with mature DevSecOps programs consistently produce larger gap counts on operational enforcement criteria than organizations with younger programs. The reason is configuration drift and exception accumulation.
A young DevSecOps program with one SAST tool configured in block mode and a manual dependency review process for new package additions implements PW.2.1 and PS.3 more completely than a mature program with four scanning tools, all configured in advisory mode, and a dependency review process that was waived for the last 18 months due to developer velocity concerns.
Mature programs accumulate exceptions. Each exception made sense when it was made. Aggregated over years, they produce pipelines where security gates run continuously and enforce nothing. The gap analysis of a mature program is often an accounting exercise for how many enforcement behaviors were gradually removed to reduce developer friction, and how many of those removals were never formally approved as policy changes.
SSDF gaps that documentation-focused assessments miss
Coordinated vulnerability disclosure with no intake mechanism
SSDF Practice RV.1.3 requires organizations to have a process for receiving reports of potential vulnerabilities in their software from external parties. In Vulnox assessments, the most common RV.1.3 finding is not that organizations are hostile to disclosure -- it is that there is no functional intake mechanism. A security.txt file pointing to a generic support email address is not a coordinated disclosure process. Disclosure reports sent to support email are routinely not routed to the engineering team. In several assessments, we found disclosure reports that had been submitted by security researchers, acknowledged by support staff as a general support inquiry, and closed without being reviewed by anyone with authority to act on them.
Developer security training that covers awareness but not SSDF-relevant skills
SSDF PO.2 requires organizations to ensure that people performing secure software development tasks have the skills to do so. Most organizations satisfy this with annual security awareness training. SSDF PO.2 is not an awareness requirement -- it is a competency requirement. The gap analysis question is whether developers writing code that processes sensitive data can demonstrate understanding of the specific secure coding practices relevant to that code: parameterized queries, input validation patterns, cryptographic library selection. Annual phishing awareness training satisfies a different requirement than PO.2.
Open source component selection with no maintainer viability assessment
SSDF PS.3 includes verifying the integrity and provenance of third-party software components. Most implementations focus on known vulnerability status via CVE databases. The XZ Utils attack vector -- a malicious actor gradually taking over maintenance of a legitimate open source component -- is not a CVE-detectable threat at the time of introduction. The component has no known vulnerabilities. The maintainer is new. The maintainer's contributions include changes that are not clearly explained by the stated functionality. A PS.3 implementation that checks CVE databases but does not assess maintainer viability and contribution pattern is implementing half the practice.
Where SSDF enforcement is heading
Within 18 months, at least one federal contract will be terminated or suspended following discovery that the vendor's SSDF attestation under OMB M-22-18 was inaccurate in a material way -- specifically that security gate enforcement behaviors described in the attestation were configured in advisory mode and had not blocked any deployment in the prior 12 months, producing a factual record directly contradicting the attestation.
The attestation framework under OMB M-22-18 creates the same legal exposure structure as the NIST 800-171 SPRS score under the False Claims Act. Federal agencies are beginning to request evidence artifacts to support attestations. The gap between what organizations attested and what their build logs show is, based on current Vulnox assessment data, large enough that a material discrepancy will surface in a procurement review. The first visible enforcement action will establish precedent for what 'SSDF conformance' requires as evidence.
Confidence: mediumA published federal contract action, OIG finding, or DOJ civil matter citing SSDF attestation inaccuracy as a contributing factor, specifically naming enforcement configuration rather than tool absence.SBOM tooling vendors will face pressure from federal procurement requirements to produce evidence-of-generation timestamps and artifact hash linkage in SBOM output by 2027, because the current gap between SBOM generation timing and artifact finalization timing will produce enough procurement review failures that agencies will require cryptographic binding of SBOM to artifact as a contract condition.
The EO 14028 SBOM requirement assumes that submitted SBOMs accurately represent the delivered artifact. Current SBOM generation practices, which generate at build initiation rather than artifact finalization, produce SBOMs that frequently do not match the delivered artifact. This will become visible in procurement reviews as agencies build technical capacity to verify SBOM accuracy. The policy response -- requiring artifact-bound SBOMs -- is technically straightforward and aligns with the provenance tracking intent of SSDF PS.3.
Confidence: mediumA federal procurement policy update or CISA guidance document requiring cryptographic binding of SBOM to software artifact hash as a condition of EO 14028 compliance attestation.
Why SSDF attestations are following the same path as NIST 800-171 SPRS scores
The SSDF attestation framework under OMB M-22-18 has the same structural weakness as the NIST 800-171 self-assessment framework: it asks organizations to evaluate their own compliance against criteria that require operational verification to assess accurately, without requiring that the evaluation include operational verification. An organization that reviews its DevSecOps documentation, confirms that the relevant tools are installed, and submits an attestation will produce a materially different result than an organization that runs build logs against SSDF task requirements and confirms enforcement behavior.
The legal consequence structure is also similar. Submitting a materially inaccurate attestation to obtain or retain a federal contract creates False Claims Act exposure. The question of what 'materially inaccurate' means in an SSDF context has not been tested in court. It will be. When it is, the organizations whose attestations described security gates that ran continuously and enforced nothing will discover that the distinction between advisory mode and block mode is exactly the kind of factual question that materiality determinations turn on.
The right response is not to avoid attestation -- it is to conduct the gap analysis against operational criteria rather than documentation criteria before submitting it. The attestation that survives a federal procurement review is the one where the evidence artifacts match what the attestation claims.
Counterargument
The counterargument is that applying False Claims Act standards to SSDF attestations will chill participation by vendors who conduct honest assessments and discover genuine gaps, because the legal exposure for honest disclosure of a gap exceeds the exposure for not assessing it carefully. That concern is legitimate and it applies with equal force to the NIST 800-171 SPRS score regime. The answer to that concern is a safe harbor for organizations that conduct thorough assessments, identify gaps, document remediation plans, and attest based on actual posture rather than desired posture -- not a lower evidentiary standard for attestation in general.
One thing to verify before your next SSDF attestation
Pull the last 90 days of build logs for your primary production software and count the number of times a security gate finding blocked a deployment. If the number is zero, either your software had no security findings -- which is unlikely -- or your security gates are configured in advisory mode. That single data point tells you whether your SSDF PW-group controls are implemented or installed. If the answer is installed, you have remediation work to do before the attestation reflects operational reality. Start with the gate enforcement configuration, not the policy documentation.
Further Reading
Gap Analysis
NIST 800-218 SSDF gap analysisDigital Footprint
vulnerability and digital footprint analysisNIST security and privacy framework group: all 34 publications mapped
NIST 800-218 SSDF gap analysis and secure software development requirementsNational Vulnerability Database Home
National Vulnerability DatabaseNIST Cybersecurity Framework 2.0
NIST Cybersecurity FrameworkOWASP Web Security Testing Guide
OWASP security testing guide
Frequently Asked Questions
What does a NIST 800-218 SSDF gap analysis actually evaluate and what evidence does it require?
An SSDF gap analysis evaluates whether an organization's software development processes implement the practices and tasks defined across the four SSDF practice groups: Prepare the Organization, Protect the Software, Produce Well-Secured Software, and Respond to Vulnerabilities. The evidence standard is operational, not documentary -- it requires demonstrating that controls execute consistently during normal development activity, not that policies describing those controls exist. A SAST tool installed in the pipeline but configured to allow failed builds to proceed is not an implemented PS.3.1 control. An SBOM generated once at initial release and never updated does not satisfy ongoing supply chain transparency requirements.
What SSDF gap findings appear most consistently in development teams that believe their DevSecOps program is mature?
In Vulnox SSDF assessments, the most consistent finding in organizations with established DevSecOps programs is enforcement gaps: security gates that exist in the pipeline but do not block deployment when they find issues. The SAST scan runs. The results are logged. The build continues. A second consistent finding is SBOM drift: SBOMs generated at one point in the development cycle that do not reflect the component inventory at the point of release, because dependency updates between generation and deployment are not captured. Both findings represent tools that are present and processes that are absent.
What does EO 14028 require under SSDF and which organizations does it apply to?
Executive Order 14028 requires federal agencies and organizations providing software to the federal government to implement the SSDF practices. OMB M-22-18 operationalized this requirement, directing federal agencies to obtain attestations from software producers that their development practices conform to SSDF. For software producers selling to the federal government, this creates a compliance obligation that is validated through self-attestation or, for critical software, third-party assessment. SBOM generation is a specific sub-requirement: producers must be able to provide a machine-readable SBOM listing all components in delivered software. The obligation extends to transitive dependencies, not just direct ones.
What is an SBOM and what does SSDF require organizations to do with it?
A Software Bill of Materials is a machine-readable inventory of all components in a software artifact, including direct and transitive dependencies, their versions, and their licensing terms. SSDF Practice PS.3 requires that organizations track the provenance of all software components and maintain this inventory through the software lifecycle. The practical gap in most implementations is currency: SBOMs generated during build are accurate at that moment and outdated by the next dependency update. EO 14028 compliance requires SBOMs that reflect the component inventory of the specific artifact delivered, which means generation must occur at the point of artifact finalization, not at the beginning of the build cycle.
How does SSDF gap analysis differ from a standard SDLC security maturity assessment?
Standard SDLC security maturity assessments typically evaluate capability presence and process consistency across a defined maturity scale. SSDF gap analysis evaluates specific practice and task implementation against the NIST 800-218 control text. The difference is precision: a maturity model tells you that vulnerability management is at level 3 on a 5-point scale; an SSDF gap analysis tells you that RV.1.3 is not implemented because the organization does not have a documented process for tracking the remediation status of identified vulnerabilities through to closure verification. For organizations under EO 14028 compliance obligations, the SSDF gap analysis format is the relevant one because the attestation requirement maps to specific SSDF practices, not to maturity levels.
What are the most common SSDF compliance failures that create regulatory exposure for software vendors selling to federal agencies?
For vendors under OMB M-22-18 attestation requirements, the three highest-risk gaps are: first, no documented and enforced vulnerability response SLA that maps to the RV.1 practice group -- the attest-and-forget pattern where vulnerabilities are identified but remediation timelines are not tracked; second, SBOM generation that covers direct dependencies but not transitive ones, which creates an incomplete picture of supply chain risk; third, no third-party dependency vetting process for the PS.1 practice group, where new dependencies are added to projects without security review of the component's maintenance status, known vulnerabilities, or provenance. Any of these gaps, if discovered during a federal procurement review, can void a previously submitted SSDF attestation.
Related Articles
GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard
GovRAMP Moderate is the first tier where you need a government sponsor, annual 3PAO reassessment, and a Significant Change Request process that can pause normal product releases for months. Most providers who stall post-authorization were not prepared for what maintaining Moderate status actually costs operationally.
GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong
GovRAMP Low+ is where providers handling limited Controlled Unclassified Information land — or discover they should not be there. The defining failure is not a missing control. It is a CUI boundary that was drawn before anyone asked what data the government actually sends through the system.
GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard
GovRAMP High is where cloud providers discover that having strong encryption is not the same as having FIPS 140-2 validated encryption — and that distinction alone has derailed authorizations from vendors who passed every other control family. The architectural constraints at High are qualitatively different from every lower tier.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.