The first pipeline I ever inherited had a folder called security that nobody had opened in a year. Inside sat a scanner report from two summers earlier, a PDF nobody could open without a password, and a sticky note that said “ask Rahul”. Rahul had left. That little folder, and the quiet embarrassment of reading it, is why I now argue for a slow, deliberate walk when a team decides to bring DevSecOps into its delivery line — the practice of checking, tracing and proving every change as it travels toward production, with the people who build it doing the checking. Rushed rollouts produce folders like mine. The nine steps below are the unhurried version, and the reference behind them all is the DevSecOps page of the Ops Atlas, which collects the primary documents in one place.
Why DevSecOps arrives broken when it arrives all at once
Most failed attempts share a plot: somebody buys a stack of scanners on a Friday, turns every rule to “block” over the weekend, and by Wednesday the entire company is routing around the gates. The word DevSecOps is everywhere and the standards still decline to pin one definition on it, which leaves each team to invent its own version — and invention under deadline pressure always looks like that Friday. Walking in steps forces the useful arguments early: what may block, who decides, and what evidence we keep. It also suits Indian teams beautifully, because the habit of reviewing before scaling is one we already apply to everything from wedding guest lists to negotiating Mumbai’s busy streets — you look, then you move, then you look again.
Nine steps that hold up in practice
Step 1: Draw the line you actually have
Before adding anything, sketch every stage the change passes through — commit, review, build, test, package, deploy — and mark where an automated check could sit. This is the map you will annotate for the next year. Keep it honest; a map of the pipeline you wish you had will mislead every later decision.
Step 2: Write the gate policy before buying tools
One page, in plain language: what refuses a merge, what merely warns, what only gets recorded. The doctrine worth adopting says a gate may refuse only what is new, severe, and demonstrably fixable with high confidence; everything else becomes listed work with a person’s name and a ninety-day fuse attached. Debt you inherited at the start never blocks anybody.
Step 3: Give results a home
Pick a SARIF store on day zero, before the first scanner runs. Findings without a durable home get pasted into chat, lose their status, and eventually vanish; findings with a home can be triaged, assigned and retired on purpose. The work is unglamorous, and it separates a living practice from a folder of unread PDFs.
Step 4: Model your identities
Write down which humans, bots and workflows may act on the repository and the build system, and what each may do. Long-lived keys in CI configs are the classic leak, so plan to replace them with OIDC or workload identity as you go — the credential never sits in a config file at all, because the build platform mints a short-lived one at runtime and hands it straight to the job. When the day comes that a build tool is compromised — it happens across this industry regularly — this list is what lets you answer “what could the attacker reach?” in minutes.
Step 5: Turn on secrets scanning first
Secrets are the finding class where the earliest wins live. Run a scanner pre-commit, let the server-side push protection catch whatever slips past, and drill one reflex into the team: when a credential leaks, rotate it first, rewrite the history second. History rewriting without rotation just launders the same secret to a quieter location.
Step 6: Pilot code scanners in report-only mode
For the first month, every rule reports and nothing blocks. You are measuring, not policing: how often each rule is wrong — its effective false alarms — whether its comments stay under a tenth of review chatter, whether findings confine themselves to the lines a change touched. Google’s Tricorder experience is the yardstick — a rule earns blocking rights only when its false alarms effectively disappear, and only after a trial run on thirty sampled findings. If a rule cannot reach that bar, demote it to warning or retire it. Trust arrives with evidence; a gate the engineers do not believe in gets overridden, and the monthly override share should stay below five in a hundred.
Step 7: Emit evidence from the very first build
Provenance, signatures and a software bill of materials cost little to produce and nearly double to retrofit, so switch them on immediately. The SLSA framework grades builds L0 through L3, and a parallel Source ladder — L1 up to L4 — scores how much the repository itself deserves your trust; GitHub’s artifact attestations sit at Build L2 today, rising to L3 with pinned reusable workflows. One habit ties the layer together: verify the evidence when you deploy. A signature inspected only at signing time is a photo of a promise, not the promise.
Step 8: Threat-model the changes that matter
Not every feature needs a whiteboard day. The playbook that actually gets used gives a significant change about forty-five minutes: open with STRIDE to organize the threats, close by answering the Threat Modeling Manifesto’s four standing questions, write the decisions down, and move on. Frequency beats ceremony — a modest session on every sizeable change catches more than an annual offsite ever will. Run it in the same meeting where the team normally sketches the feature; the whiteboard is already there, and the people who know the answers are already in the room.
Step 9: Review monthly, and travel light
Once a month, look at the numbers together:
- the override share for the month, set against the five percent ceiling;
- noise per rule, and which rules get retired as a result;
- the age of the oldest exception still open;
- time from finding to fix, plus anything that escaped to production.
Retire the rules that cry wolf, re-justify every exception still open, and celebrate a gate that blocked little, because a quiet gate usually means upstream habits improved. Rushing between stages helps nobody here any more than it helps a tourist trying to avoid spending half a day in Mumbai traffic — the route matters more than the throttle.
Making DevSecOps stick after week one
Steps keep the machinery running; people keep the practice alive. The champions pattern works by naming one security-minded person per squad and protecting between ten and twenty percent of the week for the duty, marked as theirs on the calendar — not “when there’s time”, which in practice means never. DORA’s 2022 research explains why the soft part matters so much: teams practicing security weakly reported burnout at roughly 1.4 times the rate of others, and culture, not tooling, was the better predictor of adoption. Protect attention, or the practice will quietly spend it for you.
Verification habits belong to the whole team, not to a specialist who must be chased. The same instinct that sends a careful traveller to find reliable local travel information rather than trusting a random poster should send an engineer to the provenance record before deploying an artifact. Check the source, check the receipt, then move.
The part nobody puts on a slide
Nine steps, done slowly, will put checks in your pipeline. What makes them survive a reorg, a deadline or a replatform is smaller and harder: a team that has stopped arguing about whether security belongs in the room, because the room has had it for a year and the releases got faster, not slower. That outcome arrives on its own schedule — a monsoon arrives when it arrives — but every month of steady reviews, honest measurements and protected champions’ hours moves it closer. Start with step one this week. Draw the line you actually have, tape it to the wall beside the team board, and let the pipeline itself tell you where the next check belongs — it always knows before the roadmap does.