Skip to content

Frameworks and Standards

No single framework covers all of DevSecOps. Strong programs combine several: one sets the baseline of required practices, another measures maturity, another drives engineering adoption inside the pipeline, and another secures the supply chain. This page maps the major frameworks and how they relate to this guideline.

The frameworks teams use together

NIST SSDF — Secure Software Development Framework (SP 800-218)

An outcome-focused baseline of secure-development practices, organized into four practice groups:

  • PO — Prepare the Organization: establish policies, roles, tools, and environments for secure development before writing a line of code.
  • PS — Protect the Software: maintain the integrity of source code, third-party components, build processes, and release artifacts. This maps directly to supply-chain security and repository hardening.
  • PW — Produce Well-Secured Software: apply secure design, coding, testing, and code review practices. The bulk of SAST, SCA, threat modeling, and testing activities live here.
  • RV — Respond to Vulnerabilities: identify, assess, and remediate vulnerabilities discovered after release, including through external disclosure programs.

SSDF says what outcomes to achieve, not how to build your pipeline — which makes it well suited to regulated environments and US federal procurement (Executive Order 14028 references SSDF directly). Teams use it as a compliance mapping layer over their existing pipeline. The current final version is SSDF 1.1 (February 2022); NIST published a draft SP 800-218 Rev. 1 (SSDF 1.2) for public comment in December 2025, so check for the final text when mapping controls.

OWASP SAMM — Software Assurance Maturity Model (owaspsamm.org)

Measures and improves security maturity across five business functions: Governance, Design, Implementation, Verification, Operations. Each function has practices that are scored at three maturity levels.

SAMM's primary use is the assessment: run SAMM against your organization to produce a benchmark, identify gaps, and build a prioritized roadmap. Teams typically run a SAMM assessment annually and use results to set quarterly security program goals. The SAMM toolbox provides a spreadsheet-based assessment tool as well as an online version.

OWASP DSOMM — DevSecOps Maturity Model (dsomm.owasp.org)

Zooms into concrete technical activities inside CI/CD and assigns them to maturity levels across dimensions like Build, Deploy, Test, and Culture. Where SAMM sets strategic direction, DSOMM drives day-to-day engineering adoption — it tells you which specific pipeline activity to implement next.

For example, DSOMM distinguishes between "secrets are scanned in CI" (level 1) and "secrets are scanned pre-commit with automatic block" (level 2) and "secret rotation is automated and verified" (level 3). This specificity makes it a useful benchmark for platform and AppSec teams.

SLSA — Supply-chain Levels for Software Artifacts (slsa.dev)

A graded framework for build integrity and verifiable provenance. SLSA v1.0 and later (the current specification is v1.2) is organized into tracks. The Build Track has Levels 1–3, where each level adds stronger guarantees about where an artifact came from and how it was built:

  • Level 1: provenance exists (basic build metadata).
  • Level 2: provenance is signed and generated by a hosted build platform.
  • Level 3: the build platform is hardened and provenance cannot be forged by the build's own tenants.

The former Level 4 (two-party review, hermetic and reproducible builds) was removed from the Build Track in v1.0; those properties are now addressed through separate practices and the Source Track introduced in v1.2, which covers how source revisions are produced and protected.

In practice, reaching Build Level 2 with GitHub Actions and Sigstore is achievable for most teams and satisfies most current regulatory and customer requirements. Level 3 is the target for critical infrastructure software.

OWASP Top 10 CI/CD Security Risks (owasp.org)

The canonical list of risks to the pipeline itself — an important complement to the application-focused OWASP Top 10. Key risks include:

  • CICD-SEC-1: Insufficient Flow Control Mechanisms (no approval gates, no separation of duties in the pipeline)
  • CICD-SEC-2: Inadequate Identity and Access Management (overly permissive tokens, no OIDC)
  • CICD-SEC-3: Dependency Chain Abuse (typosquatting, malicious packages)
  • CICD-SEC-4: Poisoned Pipeline Execution (PPE) — untrusted code running in a trusted context
  • CICD-SEC-6: Insufficient Credential Hygiene — long-lived tokens in environment variables or logs

OWASP Proactive Controls / ASVS / Top 10

Developer-facing security controls, verification requirements, and the best-known web risk list:

  • OWASP Top 10 — the ten most critical web application risks (2025 edition, which adds Software Supply Chain Failures and Mishandling of Exceptional Conditions). Use it to prioritize training and testing.
  • OWASP ASVS — a catalog of roughly 350 verifiable security requirements (ASVS 5.0, May 2025) organized into 17 chapters and three levels. Use it to define what "done" means for security in your backlog.
  • OWASP Proactive Controls — ten defensive techniques every developer should apply (2024 edition). Use it as a quick-start guide for secure coding.

How they fit together

Concern Framework
Baseline and compliance NIST SSDF, ISO/IEC 27001, PCI DSS
Maturity measurement and roadmap OWASP SAMM, BSIMM
Pipeline engineering adoption OWASP DSOMM
Supply-chain integrity SLSA, in-toto
Pipeline-specific risk OWASP Top 10 CI/CD
Developer controls OWASP ASVS, Proactive Controls, Top 10
AI/ML risk OWASP Top 10 for LLM Applications, OWASP Top 10 for Agentic Applications, NIST AI RMF, ISO/IEC 42001

In short: SSDF = compliance baseline, SAMM = strategic maturity, DSOMM = engineering adoption, SLSA = supply-chain integrity. This OWASP DevSecOps Guideline sits in the middle — translating these frameworks into concrete, stage-by-stage pipeline controls.

Regulatory drivers

Several regulations have turned these practices from optional to expected:

  • US Executive Order 14028 and its successors — EO 14028 (2021) and OMB memo M-22-18 required federal software suppliers to attest to SSDF compliance, and drove rapid adoption of SBOMs and supply-chain tooling in commercial software. EO 14306 (June 2025) amended the order and directed NIST to update SSDF guidance, and OMB memo M-26-05 (January 2026) rescinded M-22-18 and its common-form attestation requirement in favor of agency-specific, risk-based requirements (which may still request SBOMs). SSDF remains the reference baseline in contracts and procurement.
  • EU Cyber Resilience Act (CRA) — security requirements, vulnerability handling obligations, and incident reporting for products with digital elements sold in the EU. Entered into force in December 2024; manufacturers must report actively exploited vulnerabilities and severe incidents (24-hour early warning, 72-hour notification) from 11 September 2026, and the essential security requirements apply from 11 December 2027. Open-source stewards have lighter, separate obligations.
  • EU NIS2 Directive — requires in-scope essential and important entities to manage supply-chain security and secure acquisition and development as part of their cybersecurity risk-management measures (Article 21).
  • PCI DSS v4.0.1 — requires continuous vulnerability management, penetration testing, and secure development practices. v4.0.1 is the only active version (v4.0 was retired on 31 December 2024), and its future-dated requirements, including script and payment-page controls (6.4.3, 11.6.1), have been mandatory since 31 March 2025.
  • SOC 2 Type II — audited against your SDLC for security, availability, and confidentiality. Reviewers examine change management, SAST/DAST evidence, access controls, and incident response.
  • ISO/IEC 27001:2022 — adds supply-chain security (A.5.19–5.22) and secure development lifecycle (A.8.25–8.31) as explicit control objectives.

Using frameworks without drowning in them

A common failure mode is treating frameworks as compliance exercises to be completed rather than tools to improve outcomes. Practical advice:

  • Pick one maturity model (SAMM or DSOMM) and run a genuine assessment before shopping for tools. The assessment reveals real gaps; the tools address them.
  • Map your existing controls to SSDF only if you have a regulatory reason. For most organizations, building a good program first and mapping it to SSDF afterward is more efficient.
  • Use SLSA as an engineering target, not a compliance checkbox. Start at Level 1, move to Level 2, and measure the journey.
  • Do not maintain parallel compliance artifacts if you can make your pipeline produce evidence natively (signed build logs, immutable artifact records, policy-as-code reports).

Further reading