Two complaints show up together in nearly every engineering organisation that has scaled past a dozen developers. The first comes from product management: security review is where release dates go to die. The second arrives later, usually after an incident: the attacker never bothered with the application — entry came through the build system, a leaked credential, or a compromised dependency. Both complaints share one root cause, and DevSecOps is the discipline that treats it. This piece runs the diagnosis properly before prescribing anything.
Symptom one: the review queue that eats releases
Start with what a late-stage security review actually is: an inspection of finished work by people who were not in the room while it was built. Findings arrive weeks after the code was written, context has evaporated, and every fix competes with the next release. Product teams learn that security involvement means delay, so they route around it wherever possible. The review queue grows, the bypasses multiply, and the organisation concludes — wrongly — that speed and safety are a trade.
The evidence says the trade is false. DevOps research has tracked delivery performance against security practice for years, and the 2022 data found something inconvenient for the “security costs speed” camp: teams with weak security practices reported 1.4 times the odds of burnout, and culture predicted adoption of security work better than tooling budgets did. Slow, adversarial security does not buy protection; it buys attrition.
Symptom two: the breach that never touched the app
Now the second complaint. The machinery that assembles software — source control, CI runners, package registries, deployment credentials — has become a preferred target, because a single foothold there propagates into every customer at once. In March 2025 the popular tj-actions/changed-files GitHub Action was compromised and secret values from downstream builds were exposed; CISA’s advice to affected teams was to rotate credentials, not to patch an application, because there was no application defect. The weakness lived in the delivery chain.
A conventional security programme has almost nothing to say about that class of failure. Annual penetration tests examine the product. The pipeline that produces the product is infrastructure, and it historically escaped scrutiny. That gap is precisely where DevSecOps concentrates.
The pattern repeated within a year. On 19 March 2026, attackers force-pushed the tags of widely used Trivy scan actions and served a tampered Trivy release, v0.69.4, to unsuspecting builds; defenders contained it the same evening, but the episode taught an uncomfortable lesson — the “Immutable” badge on a package does not actually stop tag force-pushing. Trust in the delivery chain has to be engineered, not assumed from a UI label.
The DevSecOps diagnosis: controls left in the wrong decade
Put the two symptoms together and the underlying fault appears. The organisation’s security controls occupy positions the delivery process left behind years ago: reviews after completion, scans before major releases, attestation letters for auditors. Nothing positions a check at the moment a change enters the codebase, which is the cheapest possible moment to catch it. The fix is not more security spending; it is relocation. That is the core of DevSecOps as the Ops Atlas defines it: building security into the pipeline and its teams so every change is checked and traceable, with no separate phase.
Relocation has a grammar. Each control needs a position (commit, merge, build, deploy), a confidence level, an operating cost, and an action — blocking, warning, or recording. A pre-commit secret detector and a yearly audit occupy different points on that grid, and once the grid is explicit, teams stop debating abstractions and start assigning controls to slots. The seven control families involved line up with the NIST SSDF practices: design analysis sits at PW.1, dependency work at PW.4, credential handling at PW.7, build integrity at PW.8, the release activities across PS.1 to PS.3, and the audit trail at PO.5.
Scope matters as much as placement. Change-level threat modelling, scanning of source and dependencies and images and infrastructure definitions, credential hygiene, provenance records, and the hardening of the delivery machinery itself all belong in scope. Runtime incident response, portfolio-wide vulnerability ranking, cloud posture dashboards and formal audit programmes do not — each is its own operations discipline, and a programme that claims them all usually finishes none.
Prescription one: DevSecOps gates that only block what they should
The fastest way to ruin relocated controls is to let them all block. A pipeline that halts on every medium-severity warning trains engineers within days to disable it wholesale. The workable policy narrows blocking to the intersection of three properties: the defect is newly introduced by this change, it is rated serious, and the detector behind it has proven reliable. Everything else — style findings, low-confidence hunches, and the entire pre-existing backlog — converts into tracked work with a responsible name and a deadline, ninety days being the customary ceiling. Debt already in the codebase never seals the merge path, because a gate people must route around stops being a gate.
Numbers make the policy auditable. Consider a month in a mid-size organisation: 1,240 pull requests, 96 of them blocked by the gate, 22 of those overrides granted by exception. Divide it out and 22.9 percent of blocks were waved through — from that point on, engineers reasonably assume blocks are negotiable, and the gate has lost its authority. The same month might reveal a single rule producing a 43.6 percent effective false-positive rate; the response is demotion to advisory, not enforcement. Deployment evidence closes the loop: of 412 deploys, 398 carried verifiable provenance, and of nine escaped defects, three would have been caught by an earlier check that was switched off. Those four figures — override rate, rule accuracy, provenance coverage, escape rate — are the vital signs of the whole programme.
Prescription two: DevSecOps hardening for the build machinery
The OWASP project studying CI/CD security publishes a top-ten catalogue of pipeline failure modes, and the recurring hardening moves read like a checklist a business can commission without deep security expertise:
- Pin third-party build actions to an immutable commit hash instead of a movable tag, so a force-push upstream cannot alter your build.
- Grant each pipeline job the narrowest permissions that let it finish.
- Exchange stored cloud credentials for short-lived, workload-identity tokens wherever the platform supports it.
- Withhold secrets from builds triggered by untrusted forks.
- Treat workflow triggers that check out contributor-supplied code with privileged context as a design defect waiting to be exploited.
- Source gate configuration from the protected base branch, never from the change requesting entry.
Credentials deserve their own paragraph, because they are the currency of every pipeline compromise. Run a scanner in developers’ pre-commit hooks and enable server-side push protection, so a key is caught twice — once before it leaves the laptop, once at the remote. When something slips through anyway, rotate the credential first and scrub the history second; a live key in a rewritten repository is still live. Be equally careful with the emergency exit: on GitHub, by default any user with write access can bypass push protection, which is a sensible escape hatch only if someone reviews the bypass log.
Supply-chain provenance belongs in the same prescription. A software bill of materials, a signature, and a build attestation attached to each artefact turn “what is running in production?” from an archaeology project into a query — and the SLSA framework grades how strongly a build system can back those claims, from Build Level 0 to Level 3. Verifying those attestations at deploy time matters more than producing them, since a compromised builder can attest fiction as fluently as fact.
Prescription three: fund the humans on a schedule
Tooling without owners decays into shelfware — the most commonly reported failure pattern in the field is exactly that purchase. Durable programmes give security-minded engineers inside delivery teams ten to twenty percent of their week as protected champion time, review the vital-sign metrics monthly, retire the noisiest detection rules, and rehearse the compromise runbook before a real tj-actions-style morning arrives. Culture carried adoption in the research data; budgets did not.
For leaders mapping the surrounding disciplines, the platform layer is described in this piece on cloud, DevOps and platform engineering, the reliability counterpart in SRE essentials, and the skills ladder for the people who will own these controls in the DevOps career-path guide. The diagnosis is uncomfortable but the treatment is ordinary: move the controls to where the changes are, let the strong ones block and the rest keep records, and measure whether anyone is still overriding them.
