GitLab CI carries a meaningful share of the world's build pipelines, particularly in enterprises that self-host. The platform has shipped a steady stream of supply chain features, ID tokens, SLSA provenance, protected environments, but the defaults are still permissive enough that a fresh project is not safe to point at production. The hardening work is mostly settings discipline, not engineering, and it pays back disproportionately.
This checklist walks through the controls that materially reduce risk in 2026, with a bias toward the ones that integrate cleanly with the platform rather than fighting it. We assume you have basic discipline already, code review, encrypted secrets, and are looking to close the supply-chain-specific gaps.
How should you structure includes and templates?
Every non-trivial GitLab CI setup uses include to compose jobs from shared templates. Pin every include to a specific commit SHA, not to a branch name and not to a tag. The include keyword supports ref with a SHA, and that is the only safe option for templates fetched from a separate project or an external location. A template fetched from main on a shared platform repo will silently shift under you the moment that repo accepts an unreviewed change, and any compromise of the platform repo becomes a compromise of every project that includes it.
For included files from the broader ecosystem, GitLab's component catalog and the built-in security templates, pin to a tagged version and review the diff on upgrades. Treat template upgrades as code changes, route them through merge requests, and require security review for any template that runs in a protected environment or has access to deployment credentials.
How should you use ID tokens for cloud credentials?
GitLab's ID tokens are the equivalent of GitHub's OIDC tokens: a short-lived JWT minted per job, with claims that bind the token to a specific project, pipeline, branch, and environment. Configure your cloud providers to trust GitLab as an OIDC issuer, write trust policies that match on the specific sub claims your jobs use, and stop storing long-lived AWS, GCP, or Azure credentials in CI/CD variables.
The trust policy is where the security actually lives. A trust policy that accepts any token from your GitLab instance gives an attacker who lands in any job the ability to assume the role; a trust policy that requires the specific project_path, the specific ref, and the specific environment narrows the blast radius to the exact pipeline that needs the role. Audit your trust policies the way you audit IAM roles, because a permissive sub match defeats the entire point of switching to OIDC.
How do protected branches and environments compose?
Protected branches restrict who can push and who can merge. Protected environments restrict which branches and which users can trigger deploy jobs that target the environment. The two together form the choke point through which production deploys flow. Configure protected environments with required approvals, with deployment access limited to a small role, and with the allowed branches restricted to main or your release branches.
The setting that closes the most failure modes is "protected variables." A CI/CD variable marked protected is only available to jobs running on protected branches and in protected environments, which means a developer who runs a pipeline on a feature branch cannot accidentally leak production credentials through a misconfigured job. Combine protected variables with environment-scoped variables, where production secrets are only available in the production environment, and you have meaningful defense in depth.
How should runners be isolated?
GitLab runners come in several flavors, shared, group, project, and the security profile of each is different. Shared runners on GitLab.com are managed by GitLab and run jobs in ephemeral containers, which is the safest profile. Self-hosted runners require operational discipline that many teams underinvest in.
Run self-hosted runners in ephemeral mode using the Kubernetes or Docker Machine executor, with a fresh pod or VM per job. Tag runners explicitly and require jobs to declare which runner tags they need, so that high-trust jobs run on isolated runners and not on shared infrastructure. Never run a self-hosted runner with privileged Docker access unless absolutely required, and when you must, isolate that runner from the rest of the fleet. The standard incident pattern is a build job that escalates into the runner host, which then has network access to internal systems; ephemeral runners with minimal network policies break that chain.
What about SLSA provenance and signing?
GitLab has built-in SLSA provenance generation as of the 16.x series, and the 2026 releases have matured it to SLSA Level 3 with the hosted runner trust boundary. Enable provenance generation on every job that produces a release artifact, configure cosign to sign the resulting artifact with the GitLab OIDC identity via Fulcio, and store the signed bundle in the GitLab package registry or in a sigstore-aware artifact store.
The verification side is just as important. The CD pipeline that pulls an artifact for deployment should verify the SLSA provenance and the cosign signature before allowing the deploy to proceed. GitLab's environment protection rules can be wired to a custom check that runs slsa-verifier, and a failed verification should block the deploy. Producing provenance that nobody verifies is theater; the round trip is where the value lives.
How Safeguard Helps
Safeguard ingests GitLab CI provenance via the built-in SLSA exporter and treats every pipeline run as evidence in the supply chain inventory. Griffin AI correlates pipeline identity with the artifacts produced and the CVEs found, so a regression in pipeline hygiene, a job that lost its protected environment binding, an include that drifted off a pinned SHA, surfaces as a posture finding. Policy gates verify SLSA level, signing identity, and SBOM completeness before allowing deploys, integrating with cosign and slsa-verifier so you do not have to rebuild the verification stack. TPRM scoring covers vendors who ship via GitLab, and zero-CVE base images come with full GitLab-built provenance for downstream verification.