Most guides to DevSecOps begin with philosophy and end with a diagram. This one begins on a Monday and ends thirty days later, with a list of actions in the order they should happen. The plan assumes a working pipeline, a small team, and no new budget. It follows the adoption arc the field has converged on: decide before you deploy, watch before you block, and build the operating rhythm before month two arrives to test it. Nothing here is clever; all of it is sequenced.
Before day one: the three DevSecOps decisions
Three artefacts must exist before any tooling changes hands, because every later step reads from them. The field calls these the day-zero items, and skipping them is the most reliable way to produce shelfware.
First, the gate policy. One page. Which findings stop a merge: only those that are newly introduced, rated severe, and produced by a check with a near-zero false alarm rate. What happens to everything else: logged follow-up with an assignee and a deadline no further than ninety days out. Who grants exceptions and where they are recorded. Sign it, date it, store it where the pipeline can link to it. Half a day, and it does more than any purchase.
Second, the findings store. Scanner output needs a standard home — SARIF is the accepted format — so results accumulate as trends rather than evaporating as build logs. Whatever storage you pick must answer, months later, “how often did this rule fire and how often was it right?”
Third, the identity model. Draw on one page who and what authenticates to the pipeline: which humans, which service accounts, which cloud credentials, and which of those are long-lived static keys. Do not fix anything yet. The list itself is the deliverable, and week three will consume it.
Days 1–7: visibility only
The first week adds eyes and removes nothing. Every check runs in report-only mode; no merge is blocked by anything new, and the team is told so explicitly, in writing, or trust dies on contact.
- Turn on secret scanning in developers’ pre-commit hooks, and enable push protection server-side. Two layers, because each catches what the other misses. Note who may bypass the server-side layer; on many platforms the default answer is “anyone with write access”, which deserves a change.
- Start source analysis in report-only mode against changed lines. Do not scan the whole repository into a wall of inherited noise — the backlog is not the point of this exercise.
- Produce the first software bill of materials from the build. Read it. Most teams meeting their dependency list for the first time find something they did not expect, and that surprise is free tuition.
- Write down, daily, how many findings each rule produced and how many looked real. By Friday you will know which two or three rules are sharp and which are noise generators.
Days 8–14: the evidence layer
Week two attaches paper to every build, even though nobody downstream consumes it yet. Three artefacts per release: the component inventory (already running from week one), a signature applied by the build’s signing key, and a statement of provenance recording which pipeline produced the artefact and how. SLSA grades the strength of these guarantees — builds sit on levels from zero to three, source platforms on one to four — and knowing your current rung matters less than knowing there is a ladder. One rule is not negotiable at any rung: verification happens at deploy, not at signing. A signature produced on a Tuesday describes the artefact built on that Tuesday; it says nothing about what actually reaches production on Friday, and a compromised builder will produce convincing paperwork for the wrong artefact all day long.
The same week, pick the low-cost hardening from the pipeline-hygiene catalogue: replace tag references on third-party actions with immutable commit hashes, set job permissions to read-only by default, and forbid secrets in builds triggered by untrusted forks. Each is an hour or two, and together they close the doors most pipeline incidents actually walk through.
Days 15–21: DevSecOps enforcement, calibrated
Week three switches the gate on — narrowly. Only the rules that survived the week-one data earn blocking power, and only for findings that meet all three policy conditions from the decision page. Expect a handful of blocks in the first days. Every one should land on an author who can see the reason and the fix in the same interface, because a block that requires a meeting to understand trains people to route around it.
Two numbers now become monthly fixtures. The override rate: what fraction of blocks were waved through, and is it under five percent a month? A rate above that line means the gate is losing authority and the remedy is retiring rules, not disciplining engineers. The false-positive rate per rule: Google’s long operational experience with fleet-wide analysis is blunt about the threshold — a rule blocks only when its effective false alarm rate is essentially zero, thirty findings is the minimum sample before trusting it, and reviewer comments should stay under a tenth of the code changed. Rules failing those tests are demoted to advisory, not argued with.
Handle the social side as deliberately as the technical one. Announce the enforcement date a week ahead. Put the gate policy link inside every blocking message. And hold a brief public post-mortem on the first override: the exception was granted, here is why, here is its expiry. Teams that treat the first override as a normal calibration event end up with a gate people argue with honestly; teams that treat it as a failure get a gate people route around quietly, which is worse than no gate at all.
Days 22–30: the rhythm that outlives the month
The final week installs the maintenance habits, because week four is where programmes usually die quietly. Put three recurring events on the calendar and let the plan end.
- Monthly metric review, thirty minutes: override rate, false-positive rates, fix times for new findings, escapes that reached production and which check should have caught them, and the share of deploys carrying verifiable provenance.
- Quarterly rule retirement: the two noisiest rules get fixed or switched off, deliberately, in daylight.
- One rehearsal: pick a documented pipeline compromise — a hijacked build action leaking credentials, for instance, of the kind that forced CISA to advise rotation in 2025 — and walk your response out loud: what rotates first, who talks to whom, where the evidence lives.
Name one or two champions while you are at it: engineers inside the team who get 10–20 percent of their working time reserved for this, in writing, to keep all of the above alive. Unowned rhythm is just a document.
Expect the first metrics review to look unimpressive. Provenance coverage might read four deploys out of five; fix times might run in days rather than hours. That is fine — the numbers exist to move, and a modest baseline honestly measured beats a flattering one invented. What matters at the first review is that every number has an owner who can explain its trend in one sentence, and that at least one rule was retired since the month began. A programme that never kills a rule is not improving; it is accumulating.
That is the month. Day zero decisions, a week of seeing, a week of proving, a week of calibrated enforcement, and a rhythm to carry it. Nobody who completes this sequence has a certificate to show for it — nothing in this field issues one — but they have something rarer: a pipeline that can answer, with evidence, what it builds and why each change was allowed through. The full set of practices behind each step, with dates and sources, is collected in the Ops Atlas DevSecOps reference. Keep the plan pinned somewhere visible; the second month is easier than the first, but only for teams who can see what they promised. Print the page, tick the boxes as you go, and let the calendar do the rest.
