Secure your GitLab surface
Approval rules with self-approval loopholes, CI variables exposed to forks, and runners shared too widely. We don’t connect to GitLab to collect evidence for its own sake — we connect to secure it, and the compliance artefacts follow from that work.
Book a Demo[01] What This Surface Exposes
Where GitLab goes wrong
GitLab goes wrong through approval loopholes and CI variables: rules that let authors approve themselves, and variables reachable from forks.
- Merge request approval rules permitting authors to approve their own changes
- CI/CD variables not marked protected or masked, exposed to non-protected branches
- Shared runners executing untrusted fork pipelines with access to project secrets
- Project and group access tokens with broad scope and no expiry
- Protected branch settings that allow force push for maintainers
[02] What We Secure
What we watch, catch and fix on GitLab
On GitLab we test approval rules against real merge behaviour rather than reading them from configuration.
- Approval rule effectiveness tested against real merge behaviour rather than read from configuration
- CI variable protection audited per variable, since one unprotected value undermines the rest
- Runner assignment reviewed as a trust boundary between projects
- Access token inventory with scope and expiry
- Force push permissions surfaced, because they erase the audit trail your change control depends on
[03] Where It Lands
Where GitLab lands in your registers
Repositories and pipelines become asset register entries with their own criticality, because a build system that can deploy to production is a production system. Access reviews cover repository and pipeline permissions alongside your other entitlements, and the risk register carries supply chain exposure — the dependencies you pull, the actions you run, and who can push without review.
[04] How We Engage
On GitLab specifically
On GitLab, we correct approval rules, mark variables protected, and revoke stale tokens. Runner topology changes and separating fork pipeline execution we plan with your platform team.
Platform licence
Everything you need to find and fix it yourself, with no ceiling on the depth of the answer.
- Every connected tool monitored for misconfiguration and drift, with findings mapped to the assets and risks they affect
- Remediation guidance that tells you what is wrong and exactly how to fix it — however deep or awkward the issue is. We are engineers running a security company, so the answer is the real one, not a link to vendor documentation
- Assets, access reviews, and risk register populated from the tools themselves rather than from spreadsheets
- Unlimited integrations and unlimited users, with anything missing built within two weeks
Managed service
Every tool you connect through Konfirmity comes under our care, with our team doing the work.
- Continuous misconfiguration and drift monitoring across every connected tool, watched by our analysts rather than by a dashboard waiting for you
- Incident response led by us, with containment coordinated with your team
- Remediation performed directly wherever you have granted us the authority to act — and where we cannot act, we project-manage the fix to completion rather than handing you a ticket
- Decision support on the tools themselves: where something is failing you on capability or costing more than it returns, we will tell you, and help you replace it
[05] GitLab FAQs
What GitLab access does Konfirmity need?
Konfirmity needs a group access token with the Reporter role plus read_api scope, sufficient for project settings, approval rules, CI configuration and membership. Self-managed and GitLab.com are both supported through the same API.
Why do shared runners matter for security?
Because a shared runner is a trust boundary between projects. If it executes pipelines from untrusted forks while holding access to protected variables, a merge request from outside your organisation becomes a path to your secrets. We review runner assignment with that in mind.