DevSecOps Guide: Security in the Delivery Pipeline

Most DevSecOps programmes fail not for lack of scanners but because security checks are bolted onto pipelines without owners, thresholds or a way to measure whether risk is actually going down. DevSecOps means treating security requirements, tests and release integrity as part of the normal delivery flow, so the same automation that builds and deploys software also proves it is safe enough to ship. This guide covers the operating model, the toolchain and where each check belongs, how to set gates without stalling delivery, a phased rollout, metrics, and how the practice maps to NIST SSDF, SLSA, OWASP SAMM and NIST SP 800-53. It is written for application security leads, platform engineers and engineering managers who own a delivery pipeline. Hardening the pipeline platform itself and the identities inside it are covered in separate guides linked below.

Key takeaways

Start from a framework, not a tool list. NIST SSDF (SP 800-218) gives 19 practices across four groups; map every pipeline check to one so gaps and duplicates are visible.
Put each check where it is cheapest to act on. Secrets and fast static checks belong in the IDE and pull request; slow dynamic tests belong after deployment to a test environment.
Gates need written criteria. SSDF PO.4 asks you to define and use criteria for software security checks: block only on high-confidence, high-impact findings and track the rest as debt.
Release integrity is part of DevSecOps. Signed artefacts, build provenance (SLSA Build L2 or L3) and an SBOM per release turn "we scanned it" into evidence a consumer can verify.
Measure flow and outcomes together. Track time to remediate, escaped vulnerabilities and gate override rates next to deployment frequency, or security will be blamed for every delay.

What DevSecOps covers and what it does not

DevSecOps is an operating model, not a product category. It has three parts that must all be present for the term to mean anything:

Shared ownership: delivery teams own fixing their findings; security owns the standards, the tooling platform and the exceptions process. The NCSC's secure development and deployment guidance opens with the principle that secure development is everyone's concern.
Automated, repeatable checks: security tests run on every change through the same pipeline as unit tests, with results written back to the pull request or ticket where developers already work.
Verifiable releases: each release can be traced back to reviewed source, a known build and known components, which is what SSDF PS.2 (verifying release integrity) and PS.3 (archive and protect each release, including provenance data such as an SBOM) require.

It does not replace design work. Threat modelling and security requirements (SSDF PO.1, PW.1, PW.2) still happen before code exists, and penetration testing still finds what automation misses. See the Threat Modelling Guide. Securing the CI/CD platform, runners and their credentials is covered in the CI/CD Security Guide and the CI/CD Pipeline Identity Security Guide, and is not repeated here.

The DevSecOps lifecycle: where each check belongs

The table maps checks to stages of a typical trunk-based pipeline. The principle is to run the fastest, most precise checks earliest, and to reserve blocking for stages where the developer still has context.

Stage	Checks	Typical run time	Default action	SSDF practice
Plan and design	Security requirements, abuse cases, threat model for significant changes	Hours (human)	Required for new services and trust boundary changes	PO.1, PW.1, PW.2
IDE and pre-commit	Secret detection, linting with security rules, AI assistant output review	Seconds	Warn locally; never the only control	PW.5
Pull request	SAST on changed files, software composition analysis (SCA) of new dependencies, secret scan, IaC scan, peer review	1 to 10 minutes	Block on verified secrets and critical, reachable findings	PW.4, PW.5, PW.7
Build	Full SAST, compiler hardening flags, container image scan, SBOM generation, provenance and signing	5 to 20 minutes	Block on policy failures; fail closed if signing fails	PW.6, PS.2, PS.3
Test environment	DAST, API testing, fuzzing for parsers and protocol code	20 minutes to hours	Ticket by default; block high-confidence criticals before production	PW.8
Release and deploy	Signature and provenance verification at admission, configuration baseline checks	Seconds	Block unsigned or unverified artefacts	PS.2, PW.9
Operate	Continuous re-scan of deployed images and dependencies against new CVEs, runtime detection, vulnerability disclosure intake	Continuous	Feed remediation queue with SLA	RV.1, RV.2, RV.3

The "DevSecOps funnel" idea follows from this: many cheap checks early catch the bulk of issues, and fewer, slower, deeper checks later catch what remains. If the later stages find most of your issues, the early checks are mis-tuned or missing.

The DevSecOps toolchain by category

Tool categories overlap, and platform suites bundle several. Choose by what the check must prove, then by language coverage and how results reach developers. The Application Security Testing Buyer's Guide covers evaluation in depth.

Category	What it finds	Strengths	Limits
SAST	Injection, unsafe APIs, crypto misuse in first-party source	Runs before deployment; points to the line	False positives; weak on business logic and configuration
SCA	Known-vulnerable or disallowed-licence dependencies	High precision for known CVEs; feeds the SBOM	Misses unknown flaws; reachability often not assessed
Secret scanning	API keys, tokens, private keys in code, history, images and logs	Cheap, high impact; provider validation reduces noise	Finding is not fixing: the credential must be revoked
IaC scanning	Misconfigured Terraform, Kubernetes manifests, Helm charts, Dockerfiles	Stops cloud misconfiguration before it exists	Policy drift between scanner rules and cloud guardrails
Container image scanning	Vulnerable OS and language packages, embedded secrets, root user	Covers what SCA misses in base images	Results age quickly; needs continuous re-scan
DAST	Runtime issues: authentication, session handling, injection, headers	Language-agnostic; confirms exploitability	Needs a deployed target and authenticated crawling; slow
Fuzzing	Memory safety and parser crashes	Finds deep bugs other tools miss	Needs harnesses; best for libraries and protocol code
ASPM and dashboards	Correlated, de-duplicated findings across tools	One queue, ownership mapping, trend reporting	Only as good as the data feeding it

DAST in DevSecOps: run a baseline (passive) scan on every deployment to the test environment and a full authenticated scan nightly or per release. Give the scanner a dedicated test account with a known role, never a production credential. See the Web Application Security Testing Guide.
SBOM in DevSecOps: generate the SBOM in the build that produces the artefact, not from source afterwards, and store it with the release so SSDF PS.3.2 is met and re-scans against new CVEs are possible. See the SBOM Guide.
Dashboard: aggregate in an ASPM layer or vulnerability management platform keyed by service owner, not by scanner. See the Application Security Posture Management (ASPM) Guide.

Setting security gates that teams accept

SSDF PO.4 asks organisations to define and use criteria for software security checks. In practice that means a written gate policy per stage, versioned in a repository like any other code.

Block on precision, not volume: block merges for verified live secrets, critical SCA findings with a fix available, and SAST rules you have tuned to a low false-positive rate. Everything else creates a ticket with an SLA.
New code first: apply gates to findings introduced by the change ("diff-aware" or "new code" mode) so legacy debt does not block every merge. Track the legacy backlog separately with a burn-down target.
Exceptions are time-boxed: an override needs a named approver, a reason and an expiry date, and is reported. See the Remediation SLAs and Vulnerability Exceptions Guide.
Fail closed on integrity steps: if signing, provenance generation or SBOM generation fails, the release fails. These steps are cheap and their absence is a strong signal of tampering or misconfiguration.
Protect the gate itself: workflow files that define gates should be protected by CODEOWNERS review, as GitHub recommends for .github/workflows, so a developer cannot remove a check in the same pull request that would fail it.

Choosing between approaches

Decision	Option A	Option B	Choose A when
Tooling	Platform-native scanners (built into the source control or CI platform)	Best-of-breed tools per category	You have one main platform and a small AppSec team; choose B for many languages or regulated evidence needs
Gate placement	Blocking in pull request	Blocking only at release	Checks are fast and precise; choose B for slow DAST and fuzzing
Pipeline ownership	Central reusable pipeline templates	Each team writes its own	Almost always; B only for small organisations with one or two teams
Signing keys	Keyless signing tied to the CI workload identity	Long-lived keys in a KMS or HSM	Your CI platform issues OIDC tokens; choose B where offline or air-gapped verification is required

Small versus large organisations: a team of 20 engineers can get most of the value from platform-native SAST, SCA, secret scanning and a dependency update tool, plus one reusable pipeline template. Large organisations need a paved road: central templates that teams inherit, an ASPM layer to de-duplicate findings across dozens of tools, a security champions network and service ownership data to route findings. See the Security Champions Programme Guide.

Release integrity: provenance, signing and SLSA

Scanning tells you what is in an artefact; provenance tells you where it came from. SLSA v1.0 defines a Build track with four levels:

Build L0: no guarantees.
Build L1: a consistent build process that generates provenance describing the build platform, process and top-level inputs, distributed to consumers. SLSA notes this is trivial to bypass or forge; it mainly catches mistakes.
Build L2: builds run on a hosted build platform and provenance is signed by that platform, so consumers can detect tampering after the build.
Build L3: hardened builds: runs cannot influence one another, and the provenance signing secret is not accessible to user-defined build steps, which protects against tampering during the build and limits the impact of stolen upload credentials.

A realistic target for most organisations is L2 for every production artefact and L3 for anything you distribute to customers. Verify provenance and signatures at deployment, not only at build, or the evidence is never used. The Codecov breach shows why: a modified uploader script ran in thousands of customer pipelines until one customer compared it with the published checksum. See the Software Supply Chain Security Guide for consumer-side verification, and the Container Registry Security Guide for storing and enforcing signatures.

AI and mobile DevSecOps

AI coding assistants: code suggested by an assistant goes through the same pull request checks as human code; do not exempt it. Add secret scanning on prompts or context files where the tooling allows, and restrict which repositories agents with write access can push to. See the AI-Generated Code Review Guide and the GitHub Copilot Security Guide.
AI features in the product: treat model and dataset components as supply chain inputs with their own inventory. See the AI Supply Chain and AI-BOM Guide.
Mobile DevSecOps: mobile builds add signing keys for app stores, binary analysis of the packaged app and checks against the OWASP MASVS control groups (MASVS-STORAGE, MASVS-CRYPTO, MASVS-AUTH, MASVS-NETWORK, MASVS-PLATFORM, MASVS-CODE, MASVS-RESILIENCE, MASVS-PRIVACY). Keep the store signing key out of general-purpose runners and restrict which jobs can use it.

Where identity fits

Every DevSecOps tool is a non-human identity with privileged access: scanners read all source code, dependency bots open pull requests, and release jobs hold publishing and signing credentials. The Checkmarx KICS supply chain attack turned a security scanner image into a collector of secrets inside customer pipelines, and the tj-actions/changed-files compromise (CVE-2025-30066) used a stolen bot token to repoint version tags so that every workflow referencing them ran malicious code.

Least privilege for workflow tokens: GitHub recommends defaulting GITHUB_TOKEN to read-only contents and granting more per job; the OpenSSF Scorecard Token-Permissions check tests for this.
Federate rather than store: use OIDC from CI to cloud and registries for short-lived credentials. See the Workload Identity Federation Guide.
Pin third-party actions and images: by full commit SHA or digest; GitHub notes that workflow dependency lockfiles supersede SHA pinning where they can be adopted.
Owners for tool identities: every scanner, bot and release identity needs an owner, scope and rotation record. See the NHI Ownership Guide.

Implementing DevSecOps: a phased rollout

Baseline (weeks 1 to 4): inventory repositories, pipelines and owners; run the OpenSSF Scorecard checks (Branch-Protection, Code-Review, Token-Permissions, Pinned-Dependencies, Dangerous-Workflow, SAST, Signed-Releases, SBOM) or equivalent across repositories to get a measured starting point; map current checks to SSDF practices.
Quick wins (weeks 4 to 8): enable secret scanning with push protection, a dependency update tool and SCA on all repositories in report-only mode; revoke and replace every live secret found.
Templates (months 2 to 4): publish a reusable pipeline template with SAST, SCA, IaC and image scanning, SBOM generation and signing; migrate a pilot ring of three to five willing teams first.
Tune in audit mode: run each new rule non-blocking for two to four weeks, measure false positives with the pilot teams, disable or rewrite noisy rules, then switch the precise ones to blocking for new code only.
Enforce at deployment (months 4 to 6): require signature and provenance verification at admission for production, starting in warn mode, then enforce per environment.
Add depth (months 6 to 12): authenticated DAST for internet-facing services, fuzzing for parsers, SLSA Build L3 for distributed software, and a vulnerability disclosure process feeding RV.1.
Rollback plan: every gate is controlled by a versioned policy flag in the shared template, so a broken rule can be returned to warn mode across all pipelines in one change, with the change itself reviewed and logged. Never roll back by letting teams delete the step from their own pipelines.

Detection and measurement

Log and monitor the pipeline as a production system:

Events to log: gate overrides and who approved them, changes to workflow and gate policy files, changes to branch protection, failed signature or provenance verification at deployment, new tokens created for pipeline identities, and secret scanner alerts with their revocation status.
Coverage checks: repositories without the standard template, production artefacts without an SBOM or signature, and services without an owner in the findings platform.

Metric	What it shows	Healthy direction
Mean time to remediate critical and high findings, by team	Whether findings are acted on	Falling and within SLA
Escaped vulnerabilities (found in production or by external report) per release	Whether early checks work	Falling
Gate override rate and expired exceptions	Whether gates are trusted or bypassed	Low and stable; zero expired
Template coverage: share of repositories and production deployments using the standard pipeline	Reach of the programme	Rising towards 100%
Share of production artefacts with verified signature, provenance and SBOM	Release integrity	Rising towards 100%
Time from secret detection to revocation	Whether leaked credentials are actually neutralised	Hours, not days

Report these next to delivery measures such as deployment frequency and change failure rate, so improvements in security are not bought with slower delivery unnoticed. See the Board Cyber Risk Reporting Guide for executive reporting.

Framework mapping

DevSecOps capability	NIST SSDF 1.1	NIST SP 800-53 Rev. 5	NIST CSF 2.0	OWASP SAMM
Security requirements and threat modelling	PO.1, PW.1, PW.2	SA-8, SA-15	PR.PS-06	Threat Assessment, Security Requirements
Toolchain and secure environments	PO.3, PO.5	SA-15, CM-2	PR.PS-01	Secure Build
Code review and static analysis	PW.5, PW.7	SA-11	PR.PS-06	Security Testing
Dynamic testing and fuzzing	PW.8	SA-11	ID.IM-02	Requirements-driven Testing, Security Testing
Third-party components and SBOM	PW.4, PS.3	SR-3, SR-4, SA-4	GV.SC-05, ID.AM-02	Secure Build
Source protection and change control	PS.1	SA-10, CM-3	PR.PS-01	Secure Build
Signing and release integrity	PS.2	CM-14, SI-7, SI-7(15)	PR.PS-06	Secure Deployment
Vulnerability response	RV.1, RV.2, RV.3	RA-5, SI-2	ID.RA-01	Defect Management

Relevant ATT&CK techniques for threat-informed testing of the pipeline include T1195.002 Compromise Software Supply Chain, T1552.001 Credentials In Files and T1528 Steal Application Access Token. CIS Controls v8.1 Control 16 (Application Software Security) covers the same ground at safeguard level. NIST published an initial public draft of SSDF version 1.2 (SP 800-218 Rev. 1) in December 2025; check the NIST CSRC page for its current status before mapping to the new version. See the NIST Secure Software Development Framework (SSDF, SP 800-218) Guide.

Common failure patterns

Every scanner switched on, blocking, on day one: thousands of legacy findings block merges, teams get blanket exceptions, and the gates are never trusted again. Start with new code and report-only.
Secrets found but not revoked: deleting the line or the image leaves the credential valid in history and copies. Detection without revocation is the most common gap; measure time to revocation.
Mutable references to third-party code: referencing actions, images or packages by tag let the tj-actions and KICS attackers reach downstream pipelines by moving a tag. Pin by SHA or digest and let a dependency bot update the pins.
Signing without verification: artefacts are signed in the build but nothing checks signatures at deployment, so a substituted artefact deploys anyway.
Security tools with unlimited access: scanners and bots run with organisation-wide admin tokens because it was easier to set up. They become the highest-value target in the pipeline.
Findings with no owner: results land in a central dashboard that no delivery team reads. Route each finding to the team that owns the service, in the tool they already use.

Practitioner checklist

Map every existing pipeline check to an SSDF practice and list the practices with no check.
Write and version a gate policy per stage, with block criteria, ticket criteria and an exceptions process with expiry dates.
Enable secret scanning with push protection on all repositories and track time from detection to revocation.
Publish a reusable pipeline template with SAST, SCA, IaC and image scanning, SBOM generation and signing, and measure template coverage.
Run new rules in audit mode with a pilot ring before blocking, and keep a one-change rollback to warn mode.
Protect workflow and gate policy files with code owner review and branch protection.
Reach SLSA Build L2 for production artefacts and verify signatures and provenance at deployment.
Pin third-party actions and images by commit SHA or digest and keep pins updated automatically.
Give every scanner, bot and release identity an owner, least-privilege scope and short-lived credentials.
Report remediation time, escaped vulnerabilities, override rate and release integrity coverage monthly.

DevSecOps Guide: Building Security into the Delivery Pipeline