What was wrong?
Nothing dramatic, which is the point. Security was reviewed by hand at the end of each release. The findings arrived after the code was finished, so releases waited, and the same rework came back sprint after sprint. The delay was only the visible part. Underneath it, audit findings piled up, old code carried debt nobody had time for, third-party parts went into production unchecked, and a small security team was permanently behind. Everyone was doing their job. The job was in the wrong place. The red marks are the exit gates. The dots under the road are where each phase is measured.
What did I do?
I started with people, not tools. An executive agreed to sponsor the change, a DevSecOps forum began to meet, and every development team named a security champion, someone who would carry the questions in both directions. Only then did I draw the roadmap: guidelines, standards and the tools that would plug into the pipeline, measured with the OWASP DevSecOps Maturity Model. The target was plain. Level 2 everywhere within twelve months, and level 3 in the two places that matter most, build and deployment, test and verification.
The year was cut into four phases, each with a gate you had to pass to leave it. The first three months were foundation: an assessment, a policy, and code and dependency scanning in one or two pilot applications, no more. Months three to six were automation: policy gates, secret scanning, dynamic testing. Months six to twelve were expansion: pipeline templates so new teams started safe, scanning for infrastructure and containers. After month twelve comes optimisation, which never ends: runtime monitoring and a quarterly look at the numbers.
Every step of the lifecycle got its control. Threat modelling when planning. Secret scanning when coding. Code, dependency and bill-of-materials scanning when building. Dynamic testing when testing. Signed artifacts and a policy gate at release. Infrastructure and container scanning, with a vault for secrets, at deploy. Monitoring in operation. And because tools without owners decay, I rewrote the rules of ownership as a RACI for policy, pipeline operation, fixing and triage, mapped to NIST SSDF, OWASP SAMM and ISO/IEC 27001:2022, so the evidence an auditor asks for builds up on its own.
What changed?
Security stopped being an event and became a habit. Four numbers say whether the habit holds, each with a baseline taken in the first phase: how fast a critical flaw is fixed, the share of findings caught before production, how many applications run through a secure pipeline, and how long a release takes. Every control was piloted first, then automated, and only became a release gate once the teams trusted it. That order kept the two risks that sink these programmes, developer resistance and alert fatigue, from ever taking hold.