Requests to “add security” to delivery pipelines land on support and managed-services teams with no budget line, no extra headcount and a deadline measured in sprints. It can be done, but only as an ordered procedure \u2014 improvisation in this territory produces blocked releases and angry clients in equal measure. The runbook below compresses the DevSecOps adoption lifecycle into three phases: Day 0 for decisions taken on paper, Day 1 for a pilot that observes without obstructing, and Day 2 for the operating rhythm that keeps the whole arrangement honest. Every step is deliberately small, every document fits on a page or a screen, and nothing requires a purchase order before the pilot proves its worth. The failure mode this sequence avoids is the familiar one: a tool switched to blocking mode on day one, a flood of findings, and an override culture that takes quarters to undo.<\/p>\n
Run these four checks before any phase begins; each one invalidates later steps if it fails:<\/p>\n
Clients who ask how this differs from the runbooks their platform teams already follow can be pointed at the comparison of DevOps, SysOps and DevSecOps operating models<\/a> \u2014 the short version is that the security layer adds decisions, not servers.<\/p>\n Day 0 buys nothing and installs nothing. It produces three documents, each small enough to read in one sitting:<\/p>\n Day 0 ends with sign-off from the client’s engineering lead. Without that signature, Day 1 has no authority and will be relitigated the first time a scan embarrasses someone senior. The common Day 0 failures are all abbreviations of these documents: a gate policy that says “block criticals” without defining confidence, a findings store that never got an owner, an identity model that lists credentials but not their blast radii. Each abbreviation resurfaces within a quarter as an argument, and arguments cost more than the hours that would have prevented them.<\/p>\n Day 1 turns the scanners on with the blocking switches off. The order of installation matters less than the discipline of observation:<\/p>\n During this phase the support team’s job is measurement, not enforcement. Dynamic and API testing can join the pilot in its second week once the static side has settled \u2014 they answer a different question, about the running surface rather than the code, and bolting them on early muddies both. The strategies for protecting cloud-native ecosystems and their supply chains<\/a> give the wider context for why build-level evidence matters as much as code-level scanning.<\/p>\n Day 2 is not a date but a steady state, and it runs on a monthly heartbeat:<\/p>\n The operational backbone these phases attach to \u2014 builds, deploys, environment promotion \u2014 should already be stable; where it is not, the complete guide to cloud-native operations and CI\/CD automation<\/a> covers the foundation work first. Security phases stacked on an unstable delivery base collapse with it.<\/p>\n A note on client reporting, since managed engagements live or die by it. Convert the monthly metrics into two sentences per phase: what improved, and what the client must decide before the next review. Keep the raw tables in an appendix for the engineers and keep the front page readable by a budget holder. Support contracts that report security as a trend line \u2014 with the override ceiling, the exception count and the rehearsal dates visible \u2014 renew at noticeably higher rates than contracts that report security as a ticket queue, because trend lines are the only form a non-specialist buyer can defend in their own meetings.<\/p>\nDevSecOps Day 0: Decisions on Paper<\/h2>\n
\n
DevSecOps Day 1: The Report-Only Pilot<\/h2>\n
\n
DevSecOps Day 2 and Beyond: The Operating Rhythm<\/h2>\n
\n
The Runbook in Short<\/h2>\n
\n