NIST SSDF vs OWASP ASVS: How Process Practices and Testable Requirements Fit Together

Teams asked to "follow the SSDF" and "meet ASVS Level 2" often treat them as competing checklists, when one describes how an organisation builds software and the other describes what a finished application must do. NIST SP 800-218, the Secure Software Development Framework (SSDF), is a set of outcome-based practices for the development programme. The OWASP Application Security Verification Standard (ASVS) is a catalogue of pass or fail requirements for an individual web application or service. Used together, ASVS supplies the testable security requirements and release criteria that several SSDF tasks ask for, and SSDF covers the build, release and vulnerability response work that ASVS deliberately leaves out. This guide compares what each governs, maps ASVS levels into SSDF practices, explains what evidence each produces for supplier attestations, and lists the failure patterns seen when one is used without the other. It is for application security leads, DevSecOps engineers, product security teams and the buyers who assess them. For each standard on its own, see the NIST SSDF Guide and the OWASP ASVS Guide.

Key takeaways

• Different units of assessment. SSDF is assessed against an organisation or product team's development practices; ASVS is verified against one application at a chosen level.
• ASVS fills SSDF's requirement slots. Tasks such as PO.1.1 (identify and document security requirements), PO.4.1 (define criteria for software security checks) and PW.8.2 (scope and perform testing) need concrete content, and an ASVS level per application provides it.
• ASVS leaves out what SSDF covers. OWASP states that ASVS does not prescribe development lifecycle activities or how software is built through CI/CD, which is exactly where SSDF practices PO.5, PS.1 and PS.2 sit.
• Watch the version numbers. SSDF 1.1 (February 2022) cites ASVS requirement numbers from the 4.0 era, and ASVS 5.0.0 renumbered everything, so mappings and contracts must use the v5.0.0- prefix.
• Neither is a certification. NIST runs no SSDF certification scheme, and OWASP does not certify vendors, verifiers or software or endorse ASVS trust marks; buyers should ask for scope and evidence.

What each one governs

The OWASP chapter "What is the ASVS" states that ASVS specifies "the security outcomes that must be achieved within the product itself" and that, because there is no such thing as scope for attackers, its requirements should be evaluated alongside guidance for CI/CD, hosting and operations. That sentence is effectively an instruction to pair it with a lifecycle framework such as SSDF. For a wider comparison that also covers SAMM, BSIMM, ISO/IEC 27034 and IEC 62443-4-1, see Secure Development Frameworks Compared.

How ASVS slots into SSDF practices

SSDF already lists OWASP ASVS as an informative reference. In SP 800-218 version 1.1, ASVS is cited against PO.1.1, PO.3.2, PS.1.1, PW.1.1, PW.1.2, PW.1.3, PW.2.1, PW.4.1, PW.4.2, PW.4.4, PW.5.1, PW.6.2 and PW.7.2. Those citations use ASVS 4.0 requirement numbers such as 1.1.2 and chapter numbers such as 14, which do not match ASVS 5.0.0, so treat them as pointers to topics rather than as a live crosswalk. The table below maps current ASVS 5.0.0 content to the SSDF tasks where it provides the testable detail.

The reverse direction matters as much. These SSDF areas have no ASVS equivalent and must be evidenced separately: PO.2 roles and training, PO.3 toolchain specification and artefact generation, PO.5 separation and hardening of development environments, PS.2 release integrity verification, PS.3 archiving releases, RV.1.3 a vulnerability disclosure policy, and RV.2 risk responses for vulnerabilities in released software.

Where the gap bites: build and pipeline integrity

An application can pass every ASVS Level 3 requirement and still be shipped with a backdoor if the build system is compromised. In the SolarWinds supply chain compromise, attackers injected malicious code into Orion builds without altering the source repository, and the tampered builds were signed and shipped as normal updates. An application-level verification would have tested the source and the running product, neither of which revealed the problem. The relevant controls are SSDF PO.5.1 (separate and protect each environment involved in development), PS.1.1 (least-privilege access to all forms of code) and PS.2.1 (make software integrity verification information available to acquirers).

This is also where identity work sits. Build service accounts, CI/CD tokens, deploy keys and signing keys are the non-human identities that decide whether PO.5 and PS.1 can be claimed honestly. ASVS v5.0.0-13.3.1 covers how the application stores its own backend secrets; it does not cover who or what can push to the repository or trigger a release. See the CISA Secure Software Attestation Form Guide for how pipeline identities affect attestation.

Evidence for attestations and buyer questionnaires

OMB memorandum M-26-05 (23 January 2026) rescinded M-22-18 and M-23-16, the memoranda that made the CISA Secure Software Development Attestation Form mandatory for federal software suppliers. Agencies may still choose to use the form, M-26-05 points agencies to SP 800-218 for further information, and it allows contract terms requiring a software bill of materials on request. Agencies are told to validate provider security using secure development principles based on a risk assessment. Commercial buyers increasingly ask for the same content. The practical effect is that suppliers still need evidence, and both frameworks contribute different parts of it.

A supplier that can show an ASVS Level 2 verification report for its product and SSDF evidence for its pipeline answers both the "how do you build it" and the "what does it do" questions a buyer asks. One without the other leaves an obvious follow-up question.

Decision guidance

• Start with SSDF when: the pressure comes from supplier assurance, federal or regulated customers, or a supply chain incident, and the question is about the organisation's development process across many products.
• Start with ASVS when: the pressure comes from a specific application (a penetration test, a customer security review, a new internet-facing service) and developers need concrete requirements they can build and test against.
• Use both when: you ship web applications or APIs to customers who ask for attestations. SSDF becomes the programme; ASVS becomes the requirement set inside PO.1, PO.4 and PW.8.
• Small organisations: adopt ASVS Level 1 for every application as the minimum, Level 2 for the customer-facing product, and evidence the SSDF tasks that buyers ask about most (PO.5, PS.1, PW.4, RV.1) before the rest.
• Large organisations: publish a tiering rule that assigns the ASVS level automatically when an application is registered, maintain one tailored ASVS fork with version-prefixed IDs, and map SSDF tasks to owners across platform, AppSec and product teams.
• Non-web software: ASVS covers web applications and services. For mobile apps use the OWASP MASVS; for embedded or firmware products, SSDF still applies but the requirement set comes from elsewhere.

Worked scenario: a SaaS supplier facing two asks

A B2B SaaS provider is told by a bank customer to "meet ASVS Level 2" and by a public sector prospect to "align with the SSDF and provide an attestation". The AppSec lead runs one programme rather than two projects.

1. Scope: the customer-facing application and its public API are in scope for ASVS Level 2; the internal admin console is Level 2 with v5.0.0-8.4.2 (layered protection for administrative interfaces) pulled forward from Level 3. The whole engineering organisation is in scope for SSDF.
2. Requirements (PO.1): a tailored ASVS 5.0.0 fork drops the WebRTC chapter, which the product does not use, and records each documented security decision required at Level 1 and Level 2.
3. Gates (PO.4, PW.8): automated tests cover the requirements that can be tested in the pipeline; the rest are checked in a hybrid penetration test with source access before each major release.
4. Pipeline (PO.5, PS.1, PS.2): separate CI/CD identities per environment, short-lived credentials for build jobs, signed releases and provenance records. None of this appears in the ASVS report, so it gets its own evidence pack.
5. Response (RV): each confirmed vulnerability is tagged with the ASVS requirement it violates, which turns root cause analysis into a list of tests to add.
6. Outputs: the bank receives the ASVS verification report with scope and exceptions; the public sector prospect receives the SSDF evidence pack and, if requested, the attestation form.

Implementing a combined programme

1. Inventory and tier applications: list every application and API, assign a risk tier, and map tiers to ASVS levels.
2. Map SSDF tasks to owners: platform engineering owns PO.5 and PS; AppSec owns PO.1, PO.4 and PW.7 to PW.8; product security owns RV.
3. Load ASVS 5.0.0 as data: import the CSV or JSON export into the backlog or test management tool, keeping the v5.0.0- prefix on every ID.
4. Pilot on one application: run a gap assessment against its target level, write the documented security decisions, and agree the exception process before applying gates.
5. Turn on gates in audit mode: report failing requirements for two or three release cycles without blocking, then enforce. Roll back to audit mode if false positives stall releases.
6. Build the SSDF evidence pack: collect toolchain artefacts (PO.3.3), environment and access records, signing and provenance, and vulnerability records, refreshed per release.
7. Track version changes: watch for a final SSDF 1.2 and ASVS patch releases, and re-map when either changes. Do not write draft SSDF 1.2 task IDs into contracts.

Measuring whether it works

• Level coverage: percentage of applications with an assigned ASVS level and a current verification against it.
• Requirement pass rate at target level: per application, with open exceptions counted and aged.
• Automated requirement coverage: share of applicable ASVS requirements tested in the pipeline rather than manually.
• SSDF task evidence coverage: percentage of SSDF tasks with a named owner and evidence less than one release old.
• Recurrence rate: vulnerabilities that map to an ASVS requirement already marked as passing, which shows weak verification.
• Component remediation within time frames: compliance with the time frames set under v5.0.0-15.1.1.

Framework mapping

Common failure patterns

• Checkbox ASVS: a spreadsheet marked "pass" with no test evidence, often produced by running an off-the-shelf scanner. OWASP is explicit that testable using automation is not the same as running an off-the-shelf tool, and that scanners cannot fully verify business logic or access control requirements.
• SSDF without testing: policies, roles and toolchain diagrams exist, but PW.7 and PW.8 produce no application-level results, so the programme cannot show any application is actually secure.
• Stale requirement numbers: contracts or mappings that copy ASVS references from SSDF 1.1 or from ASVS 4.0.3 without a version prefix, which point to different requirements in 5.0.0.
• "ASVS certified" claims: buyers accept a trust mark instead of the verification report; OWASP does not endorse such certifications.
• Black-box only verification: a traditional penetration test reported by exception is presented as ASVS compliance, although OWASP says Level 2 and 3 verification needs documentation, source code, configuration and access to developers.
• Pipeline identities left out: ASVS results are used to answer attestation questions about secure environments and provenance, which ASVS does not test, while CI/CD tokens and signing keys stay long-lived and broadly scoped.

Practitioner checklist

• Record which version of each framework you follow: SSDF 1.1 (final) and ASVS 5.0.0, with the date checked.
• Assign an ASVS level to every web application and API from a written risk tiering rule.
• Write the ASVS level into PO.1 requirements and supplier contracts using v5.0.0- prefixed IDs.
• Use the target level as a release criterion under PO.4, starting in audit mode.
• Require hybrid, source-assisted verification for Level 2 and 3 applications and a report that lists every requirement checked.
• Evidence PO.5, PS.1 and PS.2 separately, including CI/CD identities, short-lived build credentials and signed releases.
• Tag every confirmed vulnerability with the ASVS requirement it breaks and add a regression test.
• Keep an evidence pack that can answer an attestation form or buyer questionnaire without new work.

Standards and references

• NIST: SP 800-218 Secure Software Development Framework (SSDF) Version 1.1
• NIST: SP 800-218 Rev. 1 (SSDF Version 1.2) Initial Public Draft
• NIST: Secure Software Development Framework project
• OWASP: Application Security Verification Standard 5.0
• OWASP: ASVS 5.0 What is the ASVS
• OWASP: ASVS 5.0 Assessment and Certification
• OMB: M-26-05 Adopting a Risk-based Approach to Software and Hardware Security
• CISA: Secure Software Development Attestation Form

Related NHI Mgmt Group resources: Secure Development Frameworks Compared · Security Requirements and Abuse Cases Guide · Application Security Guide · CISA Secure Software Attestation Form Guide