Why does security still get bolted on at the end of the development process, and how do we move it earlier without slowing teams down? In Part 1 of our GitLab DevSecOps series, Patrick Steger and I set the stage: what GitLab is, what shifting security left really means, and which CI/CD concepts you have to understand before you can build a DevSecOps pipeline that actually works.
The Problem: Security Found Too Late#
Patrick opens the session with a familiar story. He had to do a security review of an application, found issues, and got blamed for blocking the go-live. The point is not that the review was wrong. The point is that nobody checked security earlier in the process. The team had no idea how. That is exactly the gap a DevSecOps pipeline closes. You shift security testing left so that issues surface when they are still cheap to fix, and you automate the checks so that no developer has to remember to run them.
Why Products Need a Pipeline#
We build products, not projects, and products evolve continuously. The DevOps infinity symbol captures this: plan, code, build, test, deploy, release, operate, monitor, repeat. To support that loop, you need a CI/CD pipeline. And to talk about CI/CD without confusing each other, we have to be precise about three terms: continuous integration, continuous delivery, and continuous deployment.
Continuous Integration#
Continuous integration starts the moment a developer commits code. The CI server picks it up, builds it, runs static code analysis, runs static security analysis, and executes the unit tests and some of the integration tests. The output is a deployable artifact. Crucially, security checks are already part of this stage. You do not wait for a separate security gate at the end. You do them on every commit.
The other thing that matters here is feedback time. The developer should not wait hours or days. We are talking minutes. If the loop is slow, the developer has already moved on by the time the result comes back, and the cost of context switching wipes out everything else.
Continuous Delivery#
The deployable artifact from CI is automatically deployed to a staging environment. There you run additional automated tests, including penetration tests if you want them. The deployment is automated; the decision to release is not. Continuous delivery gives you a button. Press it when the business is ready.
Continuous Deployment#
Continuous deployment goes one step further. The artifact that passed CI and was deployed to staging is also deployed to production automatically, with another set of automated tests catching anything that slipped through. There is no manual gate. If you want a manual security checkpoint, that is fine — but then you are doing continuous delivery, not continuous deployment. Be honest about which one you actually run, because the trade-offs are different.
Release on Demand#
DevOps separates deployment from release. Deployment is putting the compiled code into production, behind a feature toggle. Release is enabling that toggle. With release on demand you decouple “the code is in production” from “the customer can see the new feature.” That is what makes continuous deployment safe even for high-impact changes.
The Pipeline We Will Build with GitLab#
There are many platforms that promise to cover the whole continuous delivery pipeline — GitLab, GitHub, Azure DevOps, and others. In this series we focus on GitLab. GitLab promises to cover everything, but in reality, your real-world pipeline will look more focused. For this series we leave out continuous exploration and release on demand, and we do continuous delivery (not full continuous deployment). The artifact gets automatically deployed to staging.
The pipeline we will build covers, on the CI side, static application security testing, secret detection, software composition analysis, and container scanning. On the CD side we add dynamic application security testing. Each topic gets its own session.
Key Takeaways#
Shift security left or pay for it later. The further to the right a security issue is found, the more expensive it is to fix. Build the checks into CI from day one.
Be precise about CI, CD, and continuous deployment. Continuous integration ends with a tested artifact. Continuous delivery deploys to staging. Continuous deployment deploys to production. Mixing them up leads to mismatched expectations.
Feedback in minutes, not hours. Developers context-switch fast. If the pipeline takes hours, the feedback lands on a developer who has already moved on, and the value of catching issues early is gone.
Separate deployment from release. Feature toggles let you ship code to production without exposing it to users. This is what makes aggressive deployment safe.
Vendor promises rarely match reality. GitLab claims to cover the entire pipeline; your real pipeline will be more focused and may need third-party pieces. Plan for that, do not fight it.
A DevSecOps pipeline is a series of small, automated decisions. SAST, secret detection, SCA, container scanning, DAST — none of them are exotic. The discipline is wiring them into every commit so they run without anyone remembering to ask.