The DevSecOps bullshit bingo
Why CI-Based Security Scanning Is a Broken Architecture
Introduction
For the past decade, application security has been built around a simple assumption:
Security scanning should run inside CI pipelines
This idea became so widespread that most security tools are now designed around CI/CD integrations.
Just find a tool and put it into your dev’s pipeline
- SAST runs in pipelines.
- Dependency scanners run in pipelines.
- Secret scanners run in pipelines.
- Container scanners run in pipelines.
At first glance, this seems logical.
But in practice, it created one of the most fragile and expensive architectures in modern engineering.
The industry normalized a system where security requires constant DevOps maintenance.
And that is the real problem.
Read this article and see how many bad practices you almost put into practice just because they seem logical 🙂
Security was never supposed to depend on DevOps
Security should answer simple questions:
- What vulnerabilities exist?
- Where are they located? How critical are they?
- Are they fixed?
Instead, organizations now maintain a complex infrastructure just to run the scanners themselves. And all marketing materials from scanner vendors are not far away from it.
|
A typical DevSecOps setup looks like this:
|
And each tool requires:
|
The result is predictable:
security becomes operational overhead instead of risk management.
Does it sound familiar to you?
The hidden cost of DevSecOps pipelines
Most companies underestimate the real cost of CI-based security.
The tool license is only a fraction of the cost.
The real expenses include:
- DevOps engineering time
- pipeline maintenance
- false positive triage
- integration complexity
- tool overlap (duplicates)
- broken scans
In many companies, security pipelines silently consume hundreds of engineering hours every year + CI minutes for public runners.
And ironically, the more tools are added and repositories are covered, the worse the situation becomes.
Security stacks slowly turn into glue architecture.
Fragmented security stacks
|
A typical modern company may run:
These tools often come from different vendors, which teams choose for a long time. |
Each has:
Security becomes fragmented across dashboards, contracts, and workflows. |
This fragmentation creates another problem: security visibility disappears.
The DevSecOps movement popularized the idea of shifting security left.
The promise was simple:
run security earlier in the development lifecycle.
In practice, many organizations ended up shifting complexity left to DevOps pipelines instead.
Developers now face:
- broken pipelines
- slow builds
- false positives
- Duplicates (say hello to AI scans)
- failing security jobs
Security tools started interfering with development velocity.
And developers quickly learned how to bypass/avoid them.
Shift left != just put scans into developers pipelines.
There is always a better place: IDE/External systems.
Shift-left architectural problem for security
The fundamental flaw of CI-based security scanning is simple:
Security depends on build execution.
If a pipeline doesn’t run If a repo is forgotten => security silently stops If an integration breaks
In other words, visibility depends on operational reliability.
That is a dangerous dependency and it’s better to find another place to execute scans.
Security should be autonomous
Security scanning should not rely on CI pipelines.
It should not depend on developers triggering builds.
It should not require constant DevOps babysitting.
Instead, security should function as an autonomous layer that continuously observes the attack surface.
This includes:
- repositories
- dependencies
- containers
- domains
- exposed services
- cloud environments
Security should simply operate without operational friction.
The next model: security control planes
The future of application security looks very different.
Instead of fragmented tools glued together through pipelines, organizations move toward security control planes such as ASOC and ASPM platforms.
Such a control plane:
- runs checks
- continuously observes assets
- correlates findings
- removes false positives and duplicates
- eliminates tool fragmentation
- removes pipeline dependency
Most importantly, it removes security from the operational burden of DevOps.
Security becomes infrastructure, not tooling.
The next generation security platforms follow several principles:
- No pipeline dependency
- No dependency from cloud and GIT vendors
- No per-repository licensing
- Unified visibility across assets
- Continuous autonomous scanning
- Minimal operational overhead
The goal is not to add more tools, but to remove complexity from the security stack. You can use just one or two scanners, but finally answer to main questions:
- What vulnerabilities exist?
- Where are they located?
- How critical are they?
- Are they fixed?
Conclusion
DevSecOps pipelines were an important step in the evolution of application security.
But they were never the final architecture.
As engineering organizations scale, the pipeline-based model starts to break under its own complexity.
Security cannot depend on fragile operational glue.
It must become an autonomous layer of the engineering infrastructure.
The companies that adopt this model will not just improve their security posture.
They will also eliminate one of the largest hidden costs in modern DevOps.
