GitLab DevSecOps Part 7: Finding Secrets in Your Code with Secret Detection

Hard-coded passwords and API keys are still one of the most common ways credentials leak. They get committed by accident, stay in the git history forever, and only show up when someone is already exploiting them. In Part 7 of our GitLab DevSecOps series, Patrick Steger and I add Secret Detection to the same pipeline we have been growing — one line of YAML — and then look at what GitLeaks actually finds, what it quietly misses, and what to do about it.

What Secret Detection Is For

#

Secret Detection scans every source and configuration file you committed to the Git repository and looks for things that should not be in source control: passwords, API keys, tokens — anything you would consider confidential. If it finds one, you do not “fix” it by editing the file. The secret is compromised the moment it lands in the repo, so the only real remediation is to revoke it everywhere it is used and rotate it. The GitLab implementation is built on the open-source GitLeaks project.

Patrick makes the obvious follow-up: if secrets do not belong in source code, where do they belong? In an external secret store. GitLab supports HashiCorp Vault for this — but you have to host and manage Vault yourself. GitLab does not currently provide an integrated, secure place to store secrets.

One Line of YAML

#

Adding Secret Detection to the pipeline is the same pattern we used for the previous tools: include the GitLab template. We open .gitlab-ci.yml in the web editor and add the Secret-Detection.gitlab-ci.yml template. Commit, and GitLab kicks off the pipeline. Everything stays green and a new secret_detection job appears in the pipeline view.

“It Did Not Find Anything”

#

The first run of the GitLeaks tool reports zero leaks. That is suspicious, because in the previous SAST session we had deliberately added hard-coded passwords on lines 19 and 20 of the controller. We expected those to show up.

They did not. Looking at the GitLeaks pattern file, the regex for “password” is very specific — it only matches lowercase letters, for example. Whether that is a bug or by design, the consequence is that ordinary password literals in code do not get detected.

So if Secret Detection misses obvious passwords, why bother? Because SAST already catches them — when we go into the Vulnerability Report and filter by the SAST tool, the same hard-coded password is right there. Secret Detection and SAST overlap, and that is fine. They cover different patterns.

What Secret Detection Is Actually Good At

#

The real value of Secret Detection is the curated list of well-known secret formats: AWS access tokens, cloud provider keys, and dozens of other tokens with predictable structure. To prove it, I add an AWS-style access key to the controller and commit. The pipeline runs, the secret_detection job opens, and the finding is right there: an AWS access token that should be revoked.

You can see the same finding in two places in the GitLab UI: the Security tab on the pipeline run (filter by Secret Detection) and the Security & Compliance → Vulnerability Report. The report tells you exactly which file and line — in this case, line 22 — and that the access key was detected.

Why It Reports the ID, Not the Secret Value

#

Patrick points out something subtle: the tool reports the AWS access key ID, not the secret value next to it. That is because the ID has a well-defined structure GitLeaks can match. The secret value itself is random — there is no pattern to match against. So GitLeaks flags the ID as a marker that a credential is probably nearby, and leaves you to decide whether the value is also exposed or being pulled in safely from a vault.

This is also why Secret Detection generates false positives. If your code retrieves a credential securely from Vault but the variable name or surrounding code matches a known pattern, GitLeaks will still flag it. Plan for that — a real Secret Detection workflow includes triaging findings, marking false positives, and tracking the genuine ones in the vulnerability management process. We will get to that workflow in a later session.

Key Takeaways

#

1. One line of YAML enables Secret Detection. Including Secret-Detection.gitlab-ci.yml is all it takes. The cost of turning it on is essentially zero — there is no excuse not to.

2. GitLeaks is pattern-based, and the patterns are conservative. Hard-coded passwords in your own code can slip past it. Do not rely on Secret Detection alone — make sure SAST is running so you have overlapping coverage.

3. Secret Detection is best at well-known token formats. AWS access keys, cloud provider tokens, structured credentials — anything with a predictable shape. That is where the tool earns its keep.

4. A detected secret is a compromised secret. You do not patch it out of the file. You revoke it in the system it belongs to and rotate it everywhere. Build that response into your process before the first finding lands.

5. GitLab gives you the scanner, not the vault. Secrets belong in an external store like HashiCorp Vault. GitLab supports Vault, but you host and operate it. There is no built-in secure secret store yet.

6. Expect false positives — plan the triage. Pattern matching flags anything that looks like a credential, including legitimate references to vault-stored secrets. Define how findings get reviewed, marked, and managed before you turn it on at scale.