DevSecOps

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.