Skip to content
atlas

DevSecOps

Also known as: secure DevOps

Building security checks into the everyday work of the teams that write and run software, rather than adding them at the end.

Draft - this entry has not been reviewed yet.

Formal

A way of working in which development, security and operations share responsibility for security, and checks such as code review, vulnerability scanning, SBOM creation and secrets checks run automatically in the pipeline on every change.

In plain English

Like building a house with the fire inspector on site from day one, instead of calling them in when the keys are about to be handed over.

In practice

A developer on a ministry's digital team opens a change request; an automatic check flags a password left in the code, and she removes it before review, so it never reaches production.

Why it matters

Flaws found while code is being written cost far less to fix than flaws found by attackers, and automatic checks keep pace with teams that release many times a day.

How to put it into practice

The usual steps, in order. Adapt them to your organisation.

  1. Get management to agree that development, security and operations share responsibility for security, and adopt a reference framework such as the NIST SSDF (SP 800-218) to describe what the teams must do.
  2. Assess where you stand with a maturity model such as OWASP SAMM or DSOMM, and pick the few practices to improve first.
  3. Add fast checks close to the developer - linters in the IDE and pre-commit hooks that catch secrets.
  4. Run SAST, software composition analysis, IaC scanning and licence checks on every pull request, and require peer review before merge.
  5. At build time scan container images, generate an SBOM, sign the artefact and record provenance; around deployment run DAST and enforce policy as code in admission control.
  6. Tune the gates so the build fails only on high-confidence, high-severity findings, and use a baseline so only new findings block.
  7. Send every finding to the owning team's backlog, prioritise with CISA's KEV catalogue, EPSS and reachability, and track mean time to remediate.
  8. Appoint security champions in each team, offer hardened templates and reusable pipeline steps, and keep threat modelling and architecture review for new features.
  9. Review the metrics and the maturity assessment every six months and choose the next improvements.

Common pitfalls

  • Buying scanners and switching them all on as blocking gates, so developers drown in false positives and route around the pipeline.
  • Measuring success by the number of findings rather than by how fast the important ones are fixed.
  • Believing automation replaces threat modelling, design review and monitoring in production.
  • Keeping security as a separate team that only signs off at the end, which is the old model with new tools.

Good guides

Technical deep dive

The idea was popularised around 2012, when Gartner's Neil MacDonald argued for "DevOpsSec" - making security a participant in DevOps rather than a gate in front of it. It is not a standard but a set of practices, and its concrete content is usually described with reference frameworks: NIST SP 800-218, the Secure Software Development Framework (SSDF v1.1, 2022), groups secure development practices into Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW) and Respond to Vulnerabilities (RV); NIST SP 800-204D maps supply-chain controls onto CI/CD pipelines; OWASP SAMM and the OWASP DevSecOps Maturity Model (DSOMM) provide maturity levels for assessing a programme.

In practice the pipeline is instrumented at each stage. Before commit: IDE linters and pre-commit hooks for secrets (gitleaks, detect-secrets). On pull request: SAST (CodeQL, Semgrep, SonarQube), software composition analysis of manifests and lockfiles, IaC scanning (Checkov, tfsec/Trivy, KICS), licence checks and mandatory peer review. On build: container image scanning, SBOM generation, signing and SLSA provenance. Before or after deployment: DAST against a running test environment (OWASP ZAP), API fuzzing, and policy-as-code admission control (OPA Gatekeeper, Kyverno). In production: runtime detection, cloud security posture management and a vulnerability-management loop that feeds findings back to the owning team's backlog.

The hard part is signal-to-noise. SAST and SCA produce many findings that are unreachable, disputed or low-impact, and a pipeline that fails on every medium finding is quickly bypassed. Mature programmes break the build only on high-confidence, high-severity issues, use baselines or ratchets so that only new findings block, triage with reachability or exploitability data (EPSS, CISA's Known Exploited Vulnerabilities catalogue, VEX statements), and measure mean time to remediate rather than number of findings. "Shift left" does not mean "shift everything left": threat modelling, architecture review and runtime monitoring cannot be replaced by scanners. Organisationally, security champions embedded in teams and security-owned paved roads (hardened templates, reusable pipeline steps) scale better than a central team reviewing every change.

DevSecOps relates to a secure development lifecycle (SDL) as automation relates to process: Microsoft's SDL, introduced in 2004, defined phase-based security activities for comparatively long release cycles, whereas DevSecOps executes the automatable subset continuously on every change and relies on humans for the rest. In an EU context the same evidence - reviewed changes, scan results, SBOMs, vulnerability handling records - supports NIS2 Article 21(2)(e) on security in network and information system acquisition, development and maintenance, and the Cyber Resilience Act's essential requirements for manufacturers.

What to learn first

Everything this builds on, foundations first.

  1. Version control
  2. →CI/CD
  3. →DevSecOps

Relationships

Requires
CI/CD

Sources & further reading

Standards & official texts

Where this data comes from

This entry was drafted by an AI from the sources above and has not yet been checked by a person. Treat it as a starting point, and check anything important against the sources.

See the review queueSuggest a correction on GitHubThis term as JSON

Check yourself

Loading…

Atlas is in beta.