GitLab secret detection runs in three modes. Push protection blocks a push that contains a secret. Pipeline secret detection scans commits in CI. Client side detection checks issue and merge request text before it is saved. They act at different moments, so most teams want more than one.
The three modes at a glance
| Mode | When it acts | What it scans | Result |
|---|---|---|---|
| Push protection | At git push | Commits in the push | Push is blocked unless the check is skipped |
| Pipeline | In CI | Default branch commits, and development branch commits if enabled in merge request pipelines | Finding recorded in the vulnerability report |
| Client side | Before saving | Issue and merge request descriptions and comments | You can edit, or save anyway for a false positive |
The GitLab page lists all three as available on Free, Premium and Ultimate, across GitLab.com, Self-Managed and Dedicated.
Why timing matters
A secret that never reaches the server is the cheapest outcome. That is the argument for push protection: it intervenes before the commit is shared. Pipeline detection is a safety net for what slips through, and it gives you a record. Client side detection covers a spot developers forget, which is the text box where someone pastes a log or a token to explain a bug.
What happens after a secret is found
Committed secrets are recorded in the vulnerability report, which includes secret specific remediation guidance. For some secret types, GitLab can automatically revoke the exposed secret. Whatever the tool does, the safe default is the same: treat any exposed credential as compromised, revoke it, issue a new one, and then clean up.
What the page does not tell you
The documentation page we reviewed does not list limitations, and it does not say whether existing git history is scanned when you first turn a mode on. If you have an older repository, ask that question before you assume the past is clean, and test with a known dummy secret in a scratch repo.
A rollout order that works
- Turn on pipeline detection first, so you learn what already exists.
- Triage the findings and revoke anything live.
- Enable push protection so new secrets stop at the door.
- Tell developers how to handle a block, and who approves a skip.
- Review skips monthly. A skip that is common is a sign of false positives or a missing secrets workflow.
Where a dedicated scanner fits
If you want one secret findings queue across several source hosts, or a policy gate that applies the same rule everywhere, a separate tool can sit beside the built-in ones. Safeguard supports policies, gates and SBOM and dependency scanning, and offers a free scan at gold.safeguard.sh/scan.
Quick check
Can I rely on push protection alone?
It is a strong first layer, but the documentation lists pipeline detection separately because secrets can still reach a repository by other routes, so layering is sensible.
Does GitLab scan the text of merge request comments?
Yes. Client side secret detection checks issue and merge request descriptions and comments before they are saved.
Sources
Last reviewed: 19 October 2026.
