DevSecOps

WHAT IT IS. DevSecOps moves security from a gate at the end of delivery into the delivery system itself. The pipeline scans secrets at commit, dependencies and containers at build, infrastructure plans before apply, and running workloads continuously — failing the build on what matters and filing tickets with severity-based SLAs for the rest. NIST's Secure Software Development Framework (SP 800-218) organizes the work into four groups — prepare the organization, protect the software, produce well-secured software, and respond to vulnerabilities — and is the citable backbone of this page. WHY IT EXISTS. A security review after three months of development finds problems at the most expensive possible moment, so it gets waived. The same check at pull-request time costs minutes and actually lands. DevSecOps also fixes the accounting: when security work is invisible, it is unfunded; when the pipeline makes it automatic, the cost is mostly fixed and the coverage is provable — which is exactly what a customer's security questionnaire or a SOC 2 auditor is really asking for. WHEN TO USE IT. From the first line of code. Retrofitting security into a delivered system is an archaeology project; starting with a scanned pipeline, a hardened base image, and vaulted secrets is nearly free by comparison. The moment there is a compliance driver (SOC 2, ISO 27001, customer security reviews) the pipeline evidence becomes the answer instead of a scramble. WHO OWNS IT. Security is a center of excellence, not a queue: a small security group owns the scanners, the standards, and the severity rubric; every service team owns the vulnerabilities in its dependencies and its code, the same way it owns its bugs. Security champions — engineers with extra training embedded in product teams — translate between the two. WHAT GOOD LOOKS LIKE. Every merge request is scanned for secrets, known vulnerable dependencies, and container CVEs before a human reviews it; a critical finding in a shipped dependency is remediated within a defined SLA (days, not quarters) because the SLA was agreed when nobody was on fire; secrets live in a manager with rotation and audit, never in git — and a leaked credential is rotated, not deleted from history; access follows least privilege with periodic reviews backed by last-used evidence (CIS Controls, linked below, is the checklist-grade source). HOW TO IMPLEMENT. In order of leverage: (1) secret scanning on every push — assume exposure, rotate what has ever been committed; (2) dependency scanning (SCA) with build-breaking severity thresholds; (3) a minimal, hardened base image and image scanning; (4) infrastructure plan scanning before apply; (5) patch SLAs with owners, reported monthly. Each step is days, and each makes the next audit cheaper. HOW TO ASSESS YOURSELF. The production readiness assessment scores secrets management, access control, patching, and vulnerability handling with citations — see /assess. Related: /devops owns the pipeline these checks ride, /cloudops owns the guardrails that keep misconfigured infrastructure from deploying at all.