Security belongs in the software delivery pipeline. The harder question is where, how often and at what cost.
Many pipeline teams eventually add security scanning to CI/CD, and relatively few go back afterward to measure what it actually cost the delivery process. Security coverage went up. Something else changed too, and it is rarely measured with the same rigor.
“Shift left” gets treated as a free upgrade: catch problems earlier, at lower cost, with no real downside. That is true for the cost of fixing a vulnerability. It is not automatically true for the cost of running your pipeline. A security control can be worth adding and still change your delivery economics in ways worth naming honestly, rather than assuming they net out to zero.
What Changes When Security Enters the Pipeline
SAST, SCA, container scanning, secret scanning, and dependency analysis all do real work, and none of them are free to run. Each one is a pipeline stage with its own execution time, and many scale with codebase size or dependency count rather than staying flat. A scan that runs quickly on a small service can take meaningfully longer on a large monorepo, and image scanning in particular can grow with the number and size of layers in a container, not just the size of the application code itself.
Findings from new scanners also generate new work: triage, false-positive review, and in some cases blocked builds while a team decides whether a flagged issue is real. Blocked builds mean retries. Retries mean re-running earlier pipeline stages that had already passed, which is easy to overlook if you are only looking at how long the new scanning stage itself takes rather than its effect on the whole pipeline run.
None of this is a flaw in the tooling. It is the actual mechanics of adding a new, non-trivial stage to a pipeline that used to run without it. Running new stages in parallel where the pipeline architecture allows it can offset some of this, but parallelization has its own compute cost, and it does not eliminate the added triage and retry work downstream.
What I’ve Actually Seen
I’ve personally observed this pattern across pipelines I’ve worked on: adding security tooling increased overall pipeline workload, delayed artifact and binary production, and produced a noticeable increase in CI/CD infrastructure cost.
I want to be precise about what that is and is not. It is a practitioner observation from real pipelines, not a benchmark, not a percentage, and not a claim that every team will see the same magnitude of effect. The pattern is consistent enough to be worth naming. The number is not something I would generalize.
Ask What It Replaces
Before adding a control, it is worth asking a question teams skip: does this replace something we already do, or does it sit alongside it?
A new SCA tool that catches known-vulnerable dependencies does not automatically make an existing manual dependency review obsolete. Sometimes it should, sometimes the two catch genuinely different things, and sometimes they overlap almost entirely. The same question applies to container scanning layered on top of an existing manual image-review checklist, or secret scanning added alongside a code-review step that was already supposed to catch hardcoded credentials.
Overlap without a corresponding removal is duplicated engineering effort dressed up as added security. Nobody put it there on purpose. It accumulates one well-intentioned addition at a time, and it is rarely anyone’s job to go back and remove the process a new tool has quietly made redundant.
The Cost Most Teams Don’t Model
A more complete way to think about a new security control’s real cost looks something like this:
incremental DevSecOps cost = tool or service cost + additional CI/CD compute + additional execution time + retry and rebuild cost + engineering triage effort + delivery and release impact
Most cost conversations stop at the first term. The rest are real and they compound: more compute per run, more minutes per run, more reruns when a build fails a new gate, more engineer-hours spent triaging what the gate flags, and a measurable effect on how quickly artifacts actually ship.
For high-frequency pipelines, the useful comparison is not simply scan duration but the cumulative effect across builds: execution minutes, compute consumption, reruns, and time-to-artifact over a representative period. None of these need a specific number attached to be worth putting in the model. The point is that the model should include them at all.
Five Questions Worth Asking Before the Next Tool
- What security gap does this control actually close?
- What existing control, check, or manual process does it replace fully or partially?
- How much pipeline execution time does it add, end to end?
- How much additional compute does it consume, and how does that scale with the codebase?
- What effect does it have on artifact and release throughput?
None of these questions argue against adding the control. They argue for knowing the answer before you do.
Where This Leaves You
This is not an argument for fewer security controls in CI/CD, and it is not an argument that security tooling is a poor investment. Security coverage and delivery speed are not opposing goals; they are both outputs of the same system, and mature DevSecOps practice treats them that way instead of optimizing one while quietly absorbing the cost on the other.
The lesson is not simply “measure security ROI.” It is simpler: measure the whole delivery system, not just the part of it you were already tracking. A security control that closes a real gap can be worth the pipeline cost it introduces, but you need to understand that cost before making the trade-off.
