Review pipeline code even when GitLab variables are masked and protected

Masking changes log display; it does not make untrusted job code safe to execute with a secret.

Source facts

GitLab warns that malicious CI/CD code can compromise both masked and protected variables. Masking replaces matching values in job logs, but transformed output may evade that replacement. Hidden variables additionally prevent later revelation through the settings page; they do not remove a job’s ability to use the value. Protected variables limit availability to protected branches or tags. GitLab also notes that running a parent-project merge-request pipeline for a fork can make the parent project’s variables available to that pipeline.

Source: GitLab — CI/CD variables.

Applicability

This concerns GitLab CI/CD variable visibility and availability controls. Exact options depend on the GitLab version and pipeline type; separately review the current rules for merge-request and fork pipelines.

DSE recommendation

DSE recommends reviewing every pipeline change before running it with production credentials, including included configuration and scripts it invokes. Keep secret availability narrow by environment, project, and protected execution path. Use an approved external secret integration where appropriate, but still review the code receiving the secret. Treat debugging output and service logs as potential exposure paths. If a job is suspected of disclosure, follow the credential-rotation process rather than relying on a masked log as evidence that the secret never left the runner.

Verification

Use a harmless synthetic value in a test pipeline to compare normal masked output with transformed output. Check protected and unprotected execution paths and the intended fork workflow. Confirm the reviewer can identify which code executes before any real secret is made available.

Official reference

GitLab — CI/CD variables. Reviewed October 15, 2026.