Security at Speed: Building DevSecOps Into the Delivery Pipeline

By DTMI Editorial · Endorsed by Dr Stephane Niango, Chief Executive Officer, DigitalQatalyst

Security at the Gate Is Both Slower and Less Secure

Every week, a development team somewhere in a large enterprise pushes code through a build pipeline and hits a security gate. The gate is staffed by a security team that has twelve other critical reviews queued. The code sits. The release date slips. The development team, under pressure from a product owner who is under pressure from a commercial deadline, asks whether they can get a waiver for this one. Sometimes they do. Sometimes they push without one. Either way, the outcome is the same: security is an obstacle rather than a property of the system being built, and the organisation is one step closer to the kind of incident that costs an average of USD 4.88 million to contain.

This scenario plays out thousands of times daily across enterprises that have invested heavily in security tooling, security talent, and security policy — and still have a fundamental architecture problem. Security is positioned at the end of the delivery pipeline, which means it arrives after the decisions have been made, after the code has been written, and after the vulnerabilities have been baked in. Moving the gate later does not make the organisation more secure. It makes security review more expensive, more adversarial, and more frequently bypassed under delivery pressure.

DevSecOps Acceleration is the discipline of moving security out of the gate and into the pipeline itself — embedding security as a continuous, automated property of the delivery process from the first commit to production deployment. This paper makes the case that technology architects and platform engineers who build security into the pipeline at every stage will not only reduce breach risk but will deliver faster, with more confidence, at lower total cost of ownership. Organisations that understand this are not choosing between moving fast and being secure. They are doing both.

Foreword

There is a version of the security conversation that we hear often, and it is the wrong conversation. It goes like this: security and speed are fundamentally in tension. Security requires caution, review, and control. Speed requires agility, autonomy, and rapid iteration. Therefore, the faster you move, the more security risk you take on, and the job of the security function is to manage how much risk the organisation is willing to accept in exchange for delivery velocity.

This framing is not only wrong. It is dangerous. It positions security as a cost of speed rather than a property of quality, and it creates the organisational dynamic that produces the Security Bottleneck — the late-stage review gate that simultaneously slows delivery and fails to catch the vulnerabilities that matter most. We have watched this dynamic cause significant harm: to organisations hit by breaches that originated in code that had passed security review, to security teams that are blamed for delays they were structurally set up to create, and to delivery teams that have learned to treat security as a bureaucratic obstacle rather than a technical discipline.

At DigitalQatalyst, our D6 dimension — Digital Accelerators — covers the enabling technologies and frameworks that compress time to value. DevSecOps is one of the most important of these because it resolves the false tension between security and speed by design. When security is embedded in the pipeline as an automated, continuous property, it does not slow delivery. It accelerates it — by catching vulnerabilities at the point where they are cheapest to fix, by eliminating the late-stage review bottleneck, and by building the kind of confidence in the delivery process that allows organisations to release more frequently and with less anxiety.

The organisations featured in this paper's evidence base are not choosing between security and speed. They are demonstrating that the choice itself was the problem.

Dr. Stephane Niango Chief Executive Officer, DigitalQatalyst

Five Design Moves Turn Security From Bottleneck Into Pipeline Property

Security architecture in most enterprises still treats the delivery pipeline as a production line with a quality control gate at the end. This model — inherited from waterfall-era software development and never fully retired even in organisations that have adopted agile delivery — produces a structural failure mode called the Security Bottleneck: late-stage security review that slows releases, creates adversarial dynamics between development and security teams, and ultimately incentivises teams to route around security controls rather than through them.

The evidence for the cost of this model is extensive. The average cost of a data breach has reached USD 4.88 million, with breaches identified and contained in under 200 days costing on average USD 1.02 million less — making early detection an unambiguously valuable capability (IBM Security, 2024). Research demonstrates that the cost of fixing a security flaw post-production is 30 times higher than fixing it at design time (NIST, 2022). Gartner (2024) projects that by 2026, organisations that fail to treat security as a platform capability will face three times higher remediation costs than those that do. Organisations with mature DevSecOps pipelines find and fix vulnerabilities four to six times faster than those using late-stage testing (Synopsys, 2023).

This paper presents five design moves that technology architects must make to shift from late-stage security gatekeeping to continuous pipeline security: shifting security left, adopting policy-as-code, designing for zero-trust, building security champion networks within delivery teams, and treating the software supply chain as attack surface. Together, these moves change security from a bottleneck into a property of the delivery system itself.

The Perimeter Is Gone, and Late-Stage Review Cannot Keep Up

The threat environment that enterprise technology teams navigate in 2026 is qualitatively different from the one that shaped the security architectures most organisations currently operate. The perimeter is gone. Cloud-native architectures, microservices, containerised workloads, and distributed supply chains have replaced the discrete boundary that traditional security controls were designed to defend. The attack surface is not a firewall. It is every API endpoint, every third-party dependency, every container image, every infrastructure-as-code configuration, every developer credential, and every CI/CD pipeline itself.

Against this expanded and dynamic attack surface, the security review gate that many organisations still rely on is structurally inadequate. It was designed for a world where code was released infrequently, where the boundary between inside and outside was clear, and where the human reviewer had time to examine a bounded artefact and make a reasoned judgement. None of those conditions hold in a modern delivery environment. Organisations running continuous integration and continuous delivery pipelines may push dozens of changes per day per team. The sheer volume of code changes, dependency updates, infrastructure modifications, and configuration changes that a modern engineering organisation produces has made manual, late-stage security review a statistical impossibility at any meaningful coverage level.

The strategic stakes are correspondingly high. A significant breach is not merely a financial event — it is a trust event, a regulatory event, and increasingly a market valuation event. The reputational consequences of a breach that originates from a known vulnerability class — one that mature DevSecOps practices would have caught automatically — are compounding. Regulators in financial services, healthcare, critical infrastructure, and data privacy are requiring documented evidence that organisations have embedded security controls in their development and deployment processes, not merely conducted periodic reviews. The EU's NIS2 Directive, the US SEC's cybersecurity disclosure rules, and the UK's Product Security and Telecommunications Infrastructure Act are all moving in the same direction: security must be demonstrable, continuous, and embedded in the delivery process.

This paper is part of the DigitalQatalyst 6xD whitepaper series, which examines how organisations build durable competitive advantage across each of the six dimensions of digital transformation. This paper addresses D6 — Digital Accelerators — the dimension that covers the enabling technologies and architectural patterns that compress time to value. DevSecOps Acceleration is the D6 discipline that resolves the false tension between security and delivery velocity by embedding security as a continuous property of the delivery system.

The Security Bottleneck Is an Architecture Choice, Not a Resourcing Gap

The Introduction established that the threat environment has fundamentally changed and that conventional late-stage security review is structurally inadequate to address it. The D6 lens in this section explains why the Security Bottleneck is an architectural consequence of where security is positioned in the delivery process, not a resourcing or expertise problem.

DigitalQatalyst's 6xD model analyses digital transformation across six dimensions, each addressing a distinct layer of how organisations compete and change in a digital environment. D6 — Digital Accelerators — is the dimension that covers enabling technologies, frameworks, automation, cloud, AI tools, cybersecurity capability, and the architectural patterns that compress time to value. Where other dimensions address strategy, culture, or operating models, D6 addresses the technical and tooling layer that determines how fast and how reliably an organisation can build and deploy digital capability.

The D6 lens applied to DevSecOps reveals the core insight that the Security Bottleneck obscures: security and acceleration are not opposing forces. They are expressions of the same underlying discipline — building high-quality, reliable systems with confidence. Organisations that treat security as a separate, late-stage function are not just making a security architecture mistake. They are making an acceleration mistake. They are accepting a delivery model that is slower, less predictable, and more expensive than the alternative, because the alternative requires treating security as a platform capability rather than a review activity.

What the D6 lens exposes that a purely technical security frame misses is the organisational and architectural pattern that creates the Security Bottleneck in the first place. The bottleneck is not caused by insufficient security expertise or inadequate tooling. It is caused by architectural separation — by the decision to make security a function that operates on delivery outputs rather than a property of the delivery system itself. This is a design decision, and it can be reversed. DevSecOps Acceleration is the D6 pattern for reversing it.

The failure mode that D6 makes visible is this: organisations invest in security tools, hire security talent, and build security policies — and then wire all of that investment to a point in the delivery process that is too late to be effective and too slow to be sustainable. The result is the Security Bottleneck: a gate that delays releases without proportionate security benefit, creates adversarial dynamics that reduce the quality of security review, and trains delivery teams to treat security as an obstacle rather than a discipline.

The remainder of this paper follows the D6 lens through the evidence of what the Security Bottleneck costs, the five design moves that dissolve it, and the signals that will accelerate its obsolescence.

What Late-Stage Security Costs at Enterprise Scale

Section 1 established that the Security Bottleneck is an architectural failure caused by positioning security after code is complete. The evidence below establishes the financial and operational cost of that architectural decision at enterprise scale.

The Cost of Late-Stage Security

The most comprehensive annual measurement of what security failures cost enterprises provides two relevant findings (IBM Security, 2024). First, the average cost of a data breach has reached USD 4.88 million — a 10% increase over the prior year and the highest figure since the report's inception. Second, breaches identified and contained in under 200 days cost on average USD 1.02 million less than those that take longer. The speed of detection and containment is directly correlated with cost outcome, which means that the architectural choices that enable faster detection — including embedded pipeline security that catches vulnerabilities before they reach production — have a directly quantifiable financial return.

Research on the relative cost of fixing security flaws at different stages of the development lifecycle is one of the most durable findings in software security (NIST, 2022). The ratio is approximately 30:1 — a flaw that costs one unit to fix at design time costs 30 units to fix in production, a finding that additional cost-of-quality research corroborates with comparable ratios. The implication is not subtle: late-stage security review is not a cost-effective use of security investment even on a pure cost-reduction basis, independent of the breach risk it fails to prevent.

The DevSecOps Maturity Advantage

The Building Security In Maturity Model research tracks security practices across hundreds of software-producing organisations and measures their outcomes (Synopsys, 2023). The consistent finding is that organisations with mature DevSecOps pipelines — those that have embedded automated security testing, secrets detection, software composition analysis, and continuous monitoring into their delivery process — find and fix vulnerabilities four to six times faster than organisations that rely on late-stage security testing. This is not a marginal advantage. It is a structural difference in the security economics of the delivery pipeline.

The mechanism is straightforward. Automated security testing in the pipeline catches vulnerabilities when the code is fresh, the context is clear, and the fix is contained to a small surface area. Late-stage testing catches vulnerabilities when the code has been integrated with dozens of other changes, the original developer may no longer be on the team, and the fix requires understanding a complex system state. The earlier the detection, the cheaper and faster the remediation.

The Security Bottleneck in Practice

The Security Bottleneck manifests in patterns that technology leaders will recognise. A financial services firm runs a security review process for every major release. The security team, staffed at a level appropriate for the release cadence of two years ago, is now receiving three times as many review requests. Reviews queue for two to three weeks. Development teams, facing product delivery commitments, request waivers. A meaningful proportion of waivers are granted. The vulnerabilities that the review process was designed to catch are making it to production in a significant share of waived releases.

A healthcare technology company adopts a microservices architecture to improve delivery velocity. Each microservice has its own release cycle. The central security team, built for monolithic application review, does not have the coverage to review each service independently. A policy is established requiring security review only for services above a certain complexity threshold. The threshold is set based on available capacity. Below-threshold services accumulate security debt without review. A third-party dependency vulnerability in a below-threshold service goes undetected for seven months.

A retail organisation's DevOps team builds a CI/CD pipeline that enables daily deployments. The security review process requires a two-week lead time and a manual approval from the security architecture team. The actual review cycle for the pipeline averages four to six weeks. Deployments that need to meet commercial windows are pushed through with documentation indicating that security review is in progress. The security review, when it eventually completes, reviews a version of the code that has already been superseded by subsequent changes.

The principle common to all three is architectural, not operational: when the security review function is positioned after code is complete, it will always be slower than the delivery cadence it is trying to review. Each organisation above invested in security expertise and tooling, yet the bottleneck persisted because the investment was wired to the wrong point in the process. A security function that reviews completed code is not preventing vulnerabilities — it is auditing them after the fact. The organisations that have dissolved the Security Bottleneck have done so not by hiring more reviewers or accelerating reviews, but by moving security to the point where it can actually prevent, rather than document, the vulnerabilities that reach production.

Supply Chain as the New Perimeter

The shift in attack methodology from direct intrusion to supply chain compromise has changed the architecture of the security problem. The SolarWinds compromise demonstrated that a trusted third-party component inserted into the delivery pipeline could propagate malicious code to thousands of downstream organisations without triggering conventional perimeter controls. Log4Shell demonstrated that a critical vulnerability in a widely used open-source library could affect hundreds of millions of systems globally, the majority of which had no inventory of their dependency tree sufficient to know whether they were affected.

The projection that by 2026, organisations that fail to treat security as a platform capability will face three times higher remediation costs (Gartner, 2024) reflects this supply chain dimension directly. The organisations that will face the highest remediation costs are those that have not automated dependency scanning, container image verification, and software bill of materials (SBOM) generation as continuous pipeline properties. They will discover supply chain vulnerabilities reactively, after compromise, at the highest possible remediation cost.

Five Design Moves That Dissolve the Security Bottleneck

The evidence in Section 2 establishes what the Security Bottleneck costs enterprises in breach exposure, remediation spend, and delivery delay. The five design moves below replace that architecture with a continuous security model that operates at delivery velocity.

Design Move 1: Shift Security Left — Embed Automated Scanning at Every Pipeline Stage

The foundational move is architectural: security testing must be present at every stage of the delivery pipeline, from the first commit to production deployment. This means integrating static application security testing (SAST) into the IDE and the commit hook, so developers receive security feedback before code reaches the shared repository. It means running dynamic application security testing (DAST) against every build in a staging environment, not only against pre-production releases. It means deploying secrets detection tools that prevent credentials, API keys, and certificates from being committed to source control under any circumstances.

The practical implementation of this move requires that security tooling be integrated into the pipeline as first-class citizens, with the same standing as build tools and test runners. Failed security scans must break the build with the same authority as failed unit tests. Security findings must be routed to the developer who introduced them, not to a central security team queue. The accountability for fixing security issues must sit with the team that created them, at the moment they are created. This is the operational expression of shifting security left: not moving the security team's location in the org chart, but moving security feedback to the earliest possible point in the development process.

Design Move 2: Adopt Policy-as-Code — Express All Security Requirements as Machine-Readable Rules

Security policies written in prose and enforced through human review are incompatible with continuous delivery pipelines at any meaningful scale. Policy-as-code is the practice of expressing all security and compliance requirements as machine-readable rules that can be evaluated automatically against every build, every infrastructure change, and every deployment. Tools such as Open Policy Agent, Checkov, and cloud-native policy engines enable this practice across cloud infrastructure, application configuration, and container orchestration.

The enterprise implication of policy-as-code extends beyond efficiency. When security policies are expressed as code, they are version-controlled, auditable, and testable. Changes to security policy are traceable. Compliance with specific regulatory requirements can be demonstrated automatically, with evidence that is generated by the pipeline rather than assembled manually for auditors. Exceptions to policy can be documented, time-limited, and automatically expired. The shift from human-reviewed policy to machine-enforced policy does not reduce security governance — it makes security governance legible, consistent, and scalable in a way that human review cannot be.

Design Move 3: Design for Zero-Trust — Enforce Continuous Verification Across Every Service and Credential

Zero-trust architecture is the security model appropriate for an environment in which the perimeter does not exist. The foundational principle is that no service, token, credential, or network request is trusted by default, regardless of where it originates. Every interaction is authenticated, authorised, and verified on each request. No implicit trust is extended based on network location, service identity, or prior authentication.

For technology architects building or rebuilding platform architecture, zero-trust is not an optional enhancement. It is the correct baseline for any system designed to operate in a cloud-native, distributed, or multi-tenant environment. Implementation priorities are: mutual TLS between all services, short-lived credentials with automated rotation, least-privilege access for all service accounts, and network microsegmentation that limits blast radius when a component is compromised. The operational investment required to implement zero-trust at scale is significant. The operational investment required to respond to a breach enabled by implicit trust is larger.

Design Move 4: Build a Security Champion Network Within Every Delivery Team

The Security Bottleneck is partly a staffing model problem. Central security teams cannot scale to review the output of modern delivery organisations. Distributed security champions — engineers within delivery teams who have received security training, have access to security tooling, and serve as the first point of contact for security questions and reviews within their team — are the staffing model that scales with continuous delivery.

The security champion model does not replace the central security function. It extends it. Champions handle first-line security review, tool configuration, and developer education within their team. They escalate to the central security function for architectural questions, novel threat patterns, and compliance interpretation. The central security function shifts from a review gatekeeping role to a standards, training, tooling, and threat intelligence role. The security workload is distributed to the point where it is most efficiently addressed — within the team writing the code — and the central function focuses on the high-complexity, high-stakes work that genuinely requires specialist expertise.

Design Move 5: Treat the Software Supply Chain as Attack Surface — Verify at Every Pull

The software supply chain — the third-party libraries, container base images, infrastructure-as-code modules, and SaaS integrations that every modern application depends on — is attack surface. It must be treated as such. Concretely, this means: automated software composition analysis (SCA) on every dependency update, with automatic blocking of packages with known critical vulnerabilities. It means maintaining a software bill of materials (SBOM) for every deployed artefact, so that when a new vulnerability is disclosed against a dependency, the organisation can determine affected systems within hours rather than weeks. It means verifying container base images against known-good signatures and scanning them for vulnerabilities before they are pulled into any pipeline. It means applying the same scrutiny to infrastructure-as-code modules from public registries as to application code from unknown sources.

Supply chain security is the highest-growth attack vector in the current threat landscape. It is also the dimension of the attack surface most often left unaddressed by organisations that have invested in application security and perimeter security. Building supply chain verification into the pipeline as an automated, continuous property is the move that closes this gap.

Three Forces Make Embedded Pipeline Security Mandatory Within 24 Months

Section 3 presented the five design moves required to dissolve the Security Bottleneck. This section identifies the three external pressures that will make embedded pipeline security an operational requirement — not an architectural preference — within 24 months.

Forcing Function 1: Regulatory Enforcement of Secure Development Practice

The regulatory environment for secure software development is hardening rapidly. The EU's NIS2 Directive, which came into force in October 2024, requires organisations in critical sectors to demonstrate that their development and deployment practices include security testing and vulnerability management as continuous activities. The US Executive Order on Improving the Nation's Cybersecurity (EO 14028) established SBOM requirements for software sold to the federal government. The UK's Product Security and Telecommunications Infrastructure Act applies security requirements to connected products. Within 24 months, organisations that cannot demonstrate embedded pipeline security to auditors and regulators will face compliance gaps that carry material financial and reputational consequences. Security as a gate will not satisfy these requirements. Security as a pipeline property will.

Forcing Function 2: AI-Assisted Vulnerability Discovery

Offensive security capabilities are being accelerated by AI in the same way that defensive capabilities are. AI-assisted fuzzing, automated exploit generation, and large language model-assisted vulnerability discovery are compressing the time between vulnerability disclosure and active exploitation. The window between a CVE being published and a working exploit being deployed in the wild has been shrinking for years and is now measured in days in many cases. Organisations that rely on scheduled security reviews — weekly scans, quarterly penetration tests, annual compliance assessments — will find that the threat moves faster than their review cadence. Continuous, automated security testing that runs on every code change is the only detection architecture that operates at the speed of the threat.

Forcing Function 3: Platform Engineering as Security Infrastructure

The rise of platform engineering as a discipline — in which a dedicated platform team builds internal developer platforms (IDPs) that abstract infrastructure complexity from application teams — creates a structural opportunity to embed security at the platform layer. When security controls are built into the platform that all delivery teams use, they are not optional. Developers do not choose whether to run a secrets scanner. The platform runs it on every commit, automatically. This platform-level security embedding is the architectural expression of the DevSecOps acceleration model, and it is being adopted by leading engineering organisations at scale. Within 24 months, the gap between organisations with security-embedded platforms and those without will be visible not only in breach rates but in delivery velocity, talent attraction, and compliance posture.

Conclusion and Recommendations

The Security Bottleneck is not a security problem. It is a design problem, and design problems have design solutions. Organisations that have embedded security into the delivery pipeline are not more security-conscious than those that have not. They have simply made different architectural decisions — decisions that align security controls with the point in the development process where they are most effective, most efficient, and least disruptive.

The numbers are unambiguous. A 30:1 cost ratio between design-time and production-time vulnerability remediation (NIST, 2022). A USD 1.02 million average cost reduction for early breach detection (IBM Security, 2024). A four to six times speed advantage in finding and fixing vulnerabilities in mature DevSecOps pipelines (Synopsys, 2023). These are not arguments for a more cautious approach to security. They are arguments for a more intelligent architecture of security — one in which the investment in security capability produces a return in both risk reduction and delivery acceleration.

Accountability for this shift sits with three roles. The enterprise architect must treat security embedding as an architectural requirement, not an optional enhancement, in every platform and pipeline design decision. The CISO must reorient the security function from gate-keeping to platform-building — shifting from reviewing code to building the tooling and standards that make secure code the default output of the delivery process. The platform engineer must build security controls into the internal developer platform as first-class capabilities, not add-ons.

The single action test for leaders: open your current deployment pipeline and identify the earliest point at which a security vulnerability introduced today would be detected. If that point is post-build, post-integration, or post-deployment, your organisation is operating a Security Bottleneck. The fix begins not with a new security tool but with a new architectural decision: security belongs in the pipeline, not after it.