🦊 GitLab Top 10 Misconfigurations
Intro: GitLab becomes risky when the instance, runners, and deployment model are trusted too broadly. Most failures are not about missing one setting. They are about mixing trust zones carelessly.
| # | Misconfiguration | Why it is dangerous | Short fix |
|---|---|---|---|
| 1 | Shared runners with weak isolation | Untrusted job code reaches sensitive context | Isolate runners by trust boundary |
| 2 | Broad runner registration or management rights | Attackers can plant infrastructure in the release path | Restrict runner admin workflows |
| 3 | Protected variables reachable from unsafe pipelines | Secret exfiltration path | Align protected variables with protected refs and environments |
| 4 | Weak environment protection | Deployments happen without clear control | Use protected environments and approvals |
| 5 | No release evidence discipline | Hard to prove what was shipped | Attach evidence artifacts consistently |
| 6 | Unreviewed includes and pipeline inheritance | Hidden control drift | Centralize and version shared components |
| 7 | No pipeline or secret detection policies | Prevention remains inconsistent | Use group-level templates and scan policies |
| 8 | Self-managed instance hardening ignored | Platform itself becomes the weak point | Apply GitLab hardening guidance deliberately |
| 9 | Broad project or group admin access | Weak separation of duties | Minimize administrative roles |
| 10 | Security gates based on noisy signals | Teams bypass the system | Tune rules and block only on meaningful conditions |
How to use this page
Use this page as a fast review sheet during:
- self-managed GitLab security reviews;
- CI/CD control workshops;
- runner trust-boundary design sessions;
- backlog prioritization when too many GitLab issues appear at once.