DevSecOps Rollout
Security into the pipeline, not around it: commit- and build-time gates first, severity-based SLAs second, secrets vaulted and access reviewed, threat modeling where designs are cheap to change.
Every step is executable work: what, why, prerequisites, implementation, validation you can check, and the failure modes to avoid. Dependencies make the order explicit — a step marked Requires waits on those steps completing first.
Phase 1
Pipeline gates
Checks at the moment defects are cheapest: push, build, and image stages failing on what matters.
Scan every push for secrets — and rotate what already leaked
P0SFull step — what, why, how, failure modes
WHAT. Secret scanning on every commit and PR, blocking merges on new findings, plus a one-time sweep-and-rotate of anything already in history. WHY. Assume the repo history is public: a key in git is a compromised key regardless of repo visibility, and rotation — not history deletion — is the fix (history deletion breaks every clone and rarely catches mirrors). PREREQUISITES. None — this is the highest-leverage first gate. IMPLEMENTATION. Enable push-protection secret scanning at the org level (native in major forges or a CI hook), triage existing alerts, and rotate every credential ever committed. Treat historical findings as live incidents: rotate first, suppress second. TOOLS. GitHub push protection / GitLab secret detection; trufflehog or gitleaks in CI. COMMON FAILURE MODES. Deleting the offending commit and calling it handled — the leaked key stays valid in every clone and cache; rotation is the only close. EXPECTED IMPACT. The most common repo-born compromise stops at the push. EVIDENCE. The blocked-merge screenshot and the rotation log.Validation — before you call it done
A test commit containing a fake AWS key is blocked before merge, and the backlog of historical secret findings is 0 or all-rotated with dated records.
Fail builds on vulnerable dependencies
P0SRequires: Scan every push for secrets — and rotate what already leakedFull step — what, why, how, failure modes
WHAT. Software-composition analysis on every build, with build-breaking thresholds for critical severity in runtime dependencies and ticket-filed flow for the rest. WHY. Your attack surface includes every package you import; a gate at build time catches the next log4j-style disclosure in hours, in the same pipeline that can fix it. PREREQUISITES. Secret scanning in place so the pipeline-gate pattern is established and trusted by the team. IMPLEMENTATION. Add SCA to the CI config scanning the lockfiles of every service, fail builds on critical-with-fix-available in production dependencies, auto-file tickets for high, and pin the policy in code (thresholds in a reviewed file, not a console). TOOLS. Trivy, Snyk, Dependabot, or OSV-scanner against the lockfile. COMMON FAILURE MODES. Failing on all severities including dev-only noise — the team gets alert-blind in a month and someone disables the gate entirely. EXPECTED IMPACT. Vulnerable dependencies become build failures the team fixes in the ordinary flow of work. EVIDENCE. The pipeline config and the fixture test's failed-run log.Validation — before you call it done
A planted critical-vulnerability fixture fails a branch build, and the last 90 days show every critical build break resolved within the SLA set later in this roadmap.
Scan and minimize container images
P1MRequires: Fail builds on vulnerable dependenciesFull step — what, why, how, failure modes
WHAT. Every image built in CI is scanned (OS packages plus library CVEs) against a minimal, maintained base image, with a severity gate mirroring the dependency gate. WHY. The image is the unit that ships to production; a 1.2GB inherited-everything base carries years of CVEs your app never needed, and distroless-or-slim bases delete most of that surface for free. PREREQUISITES. Dependency gate working — same thresholds, same trust. IMPLEMENTATION. Rebase services onto a minimal base (distroless, alpine, or wolfi as compatibility allows), scan images at build with the same critical-gates-fix-available policy, and set a scheduled rescan of running images so new disclosures find the fleet, not just new builds. TOOLS. Trivy in CI; your registry's scan/rescan; a minimal base image line. COMMON FAILURE MODES. Minimizing the base but pinning it by mutable tag — :slim silently changes under you; pin digests. EXPECTED IMPACT. The shipped artifact's vulnerability surface shrinks by an order of magnitude and stays current. EVIDENCE. The registry's scan dashboard and the base-image update history.Validation — before you call it done
All production images report 0 known critical CVEs with available fixes, base images update at least monthly, and the rescan job has flagged a newly-disclosed CVE within its last scheduled run.
Phase 2
Vulnerability management as a process
Gates catch; the process resolves — SLAs, patch cadence, and vaulted runtime secrets.
Agree severity-based remediation SLAs — while nobody is on fire
P0MRequires: Fail builds on vulnerable dependenciesFull step — what, why, how, failure modes
WHAT. A one-page matrix mapping severity to fix-by window (e.g., critical: 7 days, high: 30) and to who owns the fix in each service team. WHY. SLAs decided during a critical disclosure are decided badly and relitigated forever; agreed calmly, they turn the next disclosure from a crisis into a schedule. PREREQUISITES. The gates are producing findings, so the SLA has real volume to govern. IMPLEMENTATION. Draft the matrix from your compliance needs and reality (NIST's SSDF calls for exactly this risk-based response), review with service-team leads, publish it, and wire the gates' ticket output to carry the SLA dates automatically. TOOLS. The ticket tracker; the gates from phase one feeding it. COMMON FAILURE MODES. SLAs without an owner-per-severity — an SLA nobody is accountable for is a suggestion with a date. EXPECTED IMPACT. Remediation speed becomes a managed, measured number instead of a heroic variable. EVIDENCE. The matrix doc plus a quarterly attainment report pulled from the tracker.Validation — before you call it done
The published matrix exists, tickets generated by the gates carry SLA due dates matching it, and the last quarter's remediation data shows 80 percent-plus SLA attainment with exceptions documented.
Run a monthly patch cadence with named owners
P1MRequires: Agree severity-based remediation SLAs — while nobody is on fireFull step — what, why, how, failure modes
WHAT. A recurring monthly window for dependency and base-image updates across services, each service with a named patch owner and the window on the calendar. WHY. Patch-SLAs only work when patching is routine; a monthly cadence makes the critical case an acceleration of normal work rather than an exception process nobody has rehearsed. PREREQUISITES. SLA matrix published, so the cadence has targets to hit. IMPLEMENTATION. Schedule the window (first week, monthly), generate the update PRs automatically where possible (Dependabot et al.), require owners to merge-or-defer with a reason inside the window, and report attainment per service in the security review. TOOLS. Dependabot/Renovate; the tracker; the calendar series. COMMON FAILURE MODES. Bulk-updating 40 dependencies in one PR — unreviewable, unattributable, and un-revertable; keep PRs scoped. EXPECTED IMPACT. The estate's patch level stops depending on individual diligence and starts depending on the calendar. EVIDENCE. The monthly attainment report and the PR history.Validation — before you call it done
Three consecutive months show 90 percent-plus of automated update PRs merged or explicitly deferred with reasons inside their window.
Move runtime secrets into a manager with rotation
P1LRequires: Scan every push for secrets — and rotate what already leakedFull step — what, why, how, failure modes
WHAT. All runtime credentials (DB passwords, API keys, tokens) live in a secrets manager with audited access and automated or procedural rotation — never in env files, manifests, or images. WHY. The push-scan catches secrets entering git; the vault makes git the wrong place to look — with rotation, a leaked value has a shelf life, which no plaintext config file ever offered. PREREQUISITES. Push scanning done (so the old habit is caught) — the vault is the replacement path. IMPLEMENTATION. Stand up or adopt the manager (Vault, or the platform-native store), migrate one service's runtime secrets as the pattern (injection at deploy, not baked images), enable audit logging, set rotation periods per secret class, and delete the plaintext originals. TOOLS. Vault, AWS Secrets Manager, or platform equivalent; the deployment system's secret injection. COMMON FAILURE MODES. Migrating secrets but leaving the old env file in place 'just in case' — the fallback becomes the leak. EXPECTED IMPACT. Credential theft acquires an expiry date, and access to secrets becomes an audited event. EVIDENCE. The manager's audit log excerpt (paths and dates only) and the clean scan report.Validation — before you call it done
0 production secrets appear in repo scans or image layers (verified by a fresh scan), and every migrated secret shows a rotation date within its policy period in the manager's audit log.
Phase 3
Security as design input
The shift that prevents rather than detects: reviewed access and threat modeling while changes are still cheap.
Quarterly access reviews with last-used evidence
P2SRequires: Agree severity-based remediation SLAs — while nobody is on fireFull step — what, why, how, failure modes
WHAT. Every quarter: enumerate who and what can touch production ( humans via SSO groups, automation via roles), attach last-used data, revoke what is unused. WHY. Access is the other accumulating credential — the March contractor, the June-ex-decommissioned pipeline; last-used evidence converts the review from ritual to decision (CIS Control 5 territory). PREREQUISITES. Roles-not-users access model helps; the review works with whatever exists today. IMPLEMENTATION. Generate the access inventory with last-used stamps (IdP groups, deploy keys, service roles), distribute to owners with a deadline, auto-revoke non-responses, and file the review record as audit evidence. TOOLS. IdP group export; cloud IAM last-used data; the tracker. COMMON FAILURE MODES. Reviewing accounts but not deploy keys and service roles — the non-human paths are exactly the stale ones. EXPECTED IMPACT. Standing production access decays between reviews instead of accumulating through them. EVIDENCE. The four review records with owner verdicts.Validation — before you call it done
Four consecutive quarterly records exist covering 100 percent of production-access paths, each with a nonzero revocation or an explicit all-justified attestation.
Threat model the one service that hurts most
P2LRequires: Scan and minimize container images, Agree severity-based remediation SLAs — while nobody is on fireFull step — what, why, how, failure modes
WHAT. A structured threat model (STRIDE or attack-tree lite) for the most business-critical service, producing a ranked set of design changes — not a document shelf-piece. WHY. All the previous gates find weaknesses in what you built; the threat model asks what you should never have built that way — the cheapest moment to fix a design flaw is before code exists (SSDF group PS: protect the software's design). PREREQUISITES. The pipeline and process disciplines stable, so design findings get fixed in an environment that can ship them. IMPLEMENTATION. Book two 90-minute sessions with the service team plus a security facilitator: diagram trust boundaries in hour one, enumerate threats against them in hour two, rank by impact times plausibility, and convert the top findings into tracked engineering work with owners. TOOLS. A whiteboard; STRIDE prompts; the tracker. COMMON FAILURE MODES. The 40-page threat-model report — if it does not end in tickets, it was theater with diagrams. EXPECTED IMPACT. Security starts shaping architecture at the moment changes cost days instead of quarters. EVIDENCE. The diagram (photo of the whiteboard is fine), the ranked list, and the ticket links.Validation — before you call it done
The model exists for the chosen service with trust boundaries diagrammed, and the top-5 ranked findings each carry a tracked ticket whose status is reviewable one quarter later.
Sources
- Tier 1 — PrimaryNIST SP 800-218 — Secure Software Development Framework ↗— NIST(verified 2026-09-19)
- Tier 2 — AuthoritativeOWASP DevSecOps Guideline ↗— OWASP(verified 2026-09-19)
- Tier 1 — PrimaryCIS Critical Security Controls ↗— CIS(verified 2026-09-19)
Start from where YOU are
This roadmap is the general path. An assessment tells you which steps you can skip and which are critical — then generates a version of this plan from your actual findings, tracked to done in your workspace.