Every Scanner Is a Pipeline Stage: The Delivery Cost Shift-Left Never Puts on the Invoice

A column published by devops.com makes an argument that security tooling pitches tend to skip: many pipeline teams add scanning to CI/CD, and relatively few go back afterward to measure what it cost the delivery process ^[1]. The consequence is not a rounding error. It is a change in delivery economics that nobody wrote down, made by teams who thought they were accepting a free upgrade.

The column's framing is precise about where the free-upgrade story holds. Shift-left is treated as pure gain: catch problems earlier, at lower cost, with no real downside. That is true for the cost of fixing a vulnerability, and it is not automatically true for the cost of running your pipeline ^[2].

The mechanics are unglamorous. SAST, SCA, container scanning, secret scanning and dependency analysis all do real work, and each is a pipeline stage with its own execution time. Many of them scale with codebase size or dependency count rather than staying flat, so a scan that is quick on a small service can take meaningfully longer on a large monorepo ^[3]. Image scanning grows with the number and size of container layers, not just the size of the application code ^[4]. That means the stage you benchmarked on a sample service is not the stage you will be paying for in eighteen months, because the input keeps growing.

The second-order cost is worse than the stage duration. New findings create triage, false-positive review, and in some cases blocked builds while a team decides whether a flagged issue is real ^[5]. Blocked builds mean retries, and retries mean re-running earlier stages that had already passed, which is easy to overlook if you are only watching how long the new scanning stage takes rather than its effect on the whole run ^[6]. Running stages in parallel can offset some of this where the pipeline architecture allows, but parallelization has its own compute cost and does not remove the triage and retry work downstream ^[7].

On magnitude, the author is careful, and it is worth repeating the caveat rather than the headline. The author writes that across pipelines they have worked on, adding security tooling increased overall pipeline workload, delayed artifact and binary production, and produced a noticeable increase in CI/CD infrastructure cost ^[8]. They also state plainly that this is a practitioner observation, not a benchmark, not a percentage, and not a claim that every team sees the same magnitude ^[9]. Treat it as a hypothesis to test on your own pipeline, not a number to quote.

The cheapest recovery the column offers is a question about replacement. A new SCA tool does not automatically make an existing manual dependency review obsolete; the same applies to container scanning layered over a manual image-review checklist, or secret scanning added alongside a code review that was already supposed to catch hardcoded credentials ^[10]. Overlap without a corresponding removal is duplicated engineering effort dressed up as added security, accumulating one well-intentioned addition at a time, because it is rarely anyone's job to retire the process a tool made redundant ^[11].

The proposed model is: tool or service cost, plus additional CI/CD compute, plus additional execution time, plus retry and rebuild cost, plus engineering triage effort, plus delivery and release impact. Most cost conversations stop at the first term ^[12]. Six terms, and only one of them arrives as a quote from a vendor ^[14].

What to watch is whether your own reporting can answer the question at all. For high-frequency pipelines, the column argues the useful comparison is not scan duration but the cumulative effect across builds: execution minutes, compute consumption, reruns and time-to-artifact over a representative period ^[13]. If you cannot pull those four numbers for the quarter before and the quarter after your last security control landed, you did not decide the trade-off. You inherited it.