Almost every security and engineering leader now agrees that security should shift left. Almost none of their organisations have actually moved it.<\/p>\n
The principle has won the argument. After years of advocacy, it is hard to find a leader who will defend leaving security to a gate at the end of the pipeline. What is easy to find is an organisation that accepts the principle and has changed nothing about how it works, where security still arrives at the end, still blocks releases under deadline, and still gets routed around when it matters most. The message landed. The process did not follow it, and the gap between the two is where most enterprises actually live.<\/p>\n
The reason the gap persists is that agreeing with a principle costs nothing and changing a process costs a great deal. Shift-left as a stated policy is a slide and a good intention. Shift-left as an operational reality is a redesign of how delivery works, touching sprint planning, the pipeline, training budgets, and team scorecards. One is an announcement. The other is a programme, and most organisations made the announcement and skipped the programme.<\/p>\n
So security gets relabelled rather than relocated. The same end-of-pipeline review acquires a new name and a diagram with an arrow pointing left, while the actual work still happens exactly where it always did. The organisation can point to a shift-left initiative and a shift-left lead, and a developer’s day-to-day experience of security is unchanged: it is still something that happens to their code later, done by someone else, usually as an obstacle.<\/p>\n
The organisations that genuinely shifted security left share four process changes, and the ones that only relabelled have none of them. The first is security requirements in sprint planning. Security enters the work when it is scoped, as a requirement alongside the functional ones, rather than as a review after the fact. If security is not in the planning, it has not shifted left, whatever the policy says.<\/p>\n
The second is security testing in the delivery pipeline. Automated security checks run as part of continuous integration and delivery, so issues surface as code is written rather than weeks later in a separate scan. Security testing that still runs as a discrete late stage has not moved, regardless of where the diagram puts the arrow.<\/p>\n
The third is developer security training as a continuous programme. Shifting security into the teams that write the code means those teams need the capability to handle it, which is a sustained investment in skills, not a one-off awareness session. Without it, you have moved the responsibility without moving the ability, which fails predictably.<\/p>\n
The fourth is security metrics in delivery team scorecards. What a team is measured on is what it actually prioritises, and a team whose scorecard contains no security metric will treat security as someone else’s concern no matter where the process diagram places it. Putting security on the scorecard is what makes the ownership real rather than rhetorical.<\/p>\n
These four changes are skipped for the same reason most operating model changes are skipped: they are harder than the alternative and they touch the organisation rather than the tooling. Relabelling the existing gate is cheap, fast, and visible. Redesigning sprint planning, the pipeline, the training programme, and the scorecards is slow, disruptive, and largely invisible to anyone outside the teams. Faced with a choice between a change that looks like progress and one that is progress, organisations under delivery pressure reliably choose the one that looks like it.<\/p>\n
The cost of that choice is a security posture exactly as weak as it was, dressed in the language of a modern practice. The vulnerability that shift-left was meant to prevent still ships, because the gate it was meant to replace is still the only thing actually happening.<\/p>\n
There is also a measurement problem hiding inside the choice. Relabelling produces something to report: a launched initiative, a named owner, a slide for the board. The real changes produce nothing reportable for months, because process change is slow and its payoff is the absence of a future incident, which is invisible by definition. An organisation that rewards visible initiative over invisible progress will keep choosing the relabel, and keep being surprised when the posture does not improve.<\/p>\n
Shift-left security has won the argument and lost the implementation, and the distance between the two is measured in process change, not in policy statements. The test of whether an organisation has shifted security left is not whether it says so. It is whether security requirements are in the planning, security tests are in the pipeline, developers have the training to own it, and the scorecards measure it. An organisation with none of those has not shifted security left. It has moved the label and left the work where it always was, and the next vulnerability will find the gap exactly where the old gate used to be.<\/p>\n","protected":false},"excerpt":{"rendered":"
Shift-left security is now widely accepted in principle and rarely implemented in practice. Four process changes separate organisations that genuinely moved security left from those that relabelled the gate at the end.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[],"class_list":["post-52","post","type-post","status-publish","format-standard","hentry","category-operating-models"],"_links":{"self":[{"href":"https:\/\/baecke.io\/index.php?rest_route=\/wp\/v2\/posts\/52","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/baecke.io\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/baecke.io\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/baecke.io\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/baecke.io\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=52"}],"version-history":[{"count":0,"href":"https:\/\/baecke.io\/index.php?rest_route=\/wp\/v2\/posts\/52\/revisions"}],"wp:attachment":[{"href":"https:\/\/baecke.io\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=52"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/baecke.io\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=52"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/baecke.io\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=52"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}