After eleven sessions building a full DevSecOps pipeline with GitLab — from Software Composition Analysis to Container Scanning, SAST, Secret Detection, DAST, merge request integration, and scheduled pipelines — Patrick Steger and I close the series with our recommendations. What worked, what tripped us up, and what we would tell anyone setting out to build the same pipeline today.
What We Built and What Stuck#
Quick recap: we started with two introductory videos on GitLab and project setup, then layered in Software Composition Analysis to find vulnerabilities in dependencies, License Compliance to flag licensing issues, Static Application Security Testing for our own code, Container Scanning, Secret Detection to catch passwords accidentally committed, Dynamic Application Security Testing as an automated penetration test against the running app, merge request integration so the security impact of changes is visible before they land, and finally scheduled pipelines so production code keeps getting checked against newly disclosed vulnerabilities.
That is a lot of moving parts. Here is what we would actually recommend you focus on.
Define Your Default Branch#
The default branch is the branch GitLab uses for Vulnerability Management. It is where all the results from your security tools surface. Get this right at the start of the project, because everything else — merge request gates, scheduled scans, the vulnerability dashboard — keys off it.
Schedule Pipelines Against Production Code#
Your application sits in production long after the last commit. Vulnerabilities in dependencies, base images, and frameworks are disclosed every day. If your pipeline only runs when someone changes code, you will miss them. Scheduled pipelines run your security tests on a regular cadence against the production code so you find new vulnerabilities as they become known. This is not optional — it is the only way to stay current.
Use Merge Requests as Your Security Gate#
Whenever code is merged into the default branch, route it through a merge request. The pipeline runs, and any newly introduced security issues become visible alongside the change that introduced them. Define which approvers are allowed to accept new issues — security findings should not be silently waved through by whoever happens to be online. A clear approval rule keeps the bar honest.
Never Store Secrets in Source Code#
Secret Detection exists because every team eventually commits a credential by accident. Run it on every commit so that mistake is caught immediately, not weeks later when someone scrapes the public repo. And put your secrets in a vault. GitLab integrates well with HashiCorp Vault, and that is what we recommend. Source code is for code; secrets belong in a secret store.
Out-of-the-Box Tools Are Easier — Custom Tools Are Real Effort#
GitLab ships a default set of security scanners, and using them is the path of least resistance: easy integration, low maintenance, predictable upgrades. If you bring your own tools, expect significant integration and maintenance effort. The exception worth highlighting is DAST — even with the GitLab-provided scanner, you must customize it. An out-of-the-box DAST configuration produces very limited results because the scanner does not know how to authenticate, where to crawl, or which inputs to exercise. Plan time for that customization. It is the difference between a real penetration test and a checkbox.
Bring a Security Expert into the Team#
A DevSecOps pipeline is genuinely complex. Many tools, many configurations, many findings to triage. We strongly recommend including a security expert from the start — someone who can help you decide which tools to use, how to configure them, what to gate on, and how to manage the resulting vulnerability backlog. Without that expertise the pipeline will either be too noisy and ignored, or too lax and useless.
Key Takeaways#
Set the default branch deliberately. It anchors Vulnerability Management and every gate downstream of it. Get it right before you wire anything else up.
Scheduled pipelines protect production code. Vulnerabilities are disclosed daily; your pipeline cannot only run on commits. Schedule it.
Merge requests are where security gates belong. New code into the default branch goes through a merge request, the pipeline runs, and approvers decide what gets accepted.
Secrets never live in source code. Run Secret Detection on every commit, store secrets in a vault — HashiCorp Vault integrates cleanly with GitLab.
Out-of-the-box scanners save weeks. Custom tools are possible but expensive. The exception: even GitLab’s own DAST needs serious customization to produce useful results.
You need a security expert on the team. The tooling is the easy part. Knowing what to gate, what to ignore, and how to manage the vulnerability backlog requires real expertise — bring it in early.