Yes. Setting CI_DEBUG_TRACE to true makes a job log every command and expanded value, and GitLab states that it exposes all variables and secrets available to the job. Turn it on briefly, with logs restricted to your team, then delete the log. Never leave it enabled in a project with public logs.
What GitLab says
GitLab's troubleshooting page calls debug logging a serious security risk. It tells you to make sure only team members can view job logs before you enable it, and to delete job logs containing debug output before making logs public again. Access to the debug output is limited to users with the Developer, Maintainer or Owner role when the variable is set in .gitlab-ci.yml or in the CI/CD settings. Users with lower roles cannot see those logs.
The runner variable trap
The same page flags a difference. If you set CI_DEBUG_TRACE as a local variable on the runner, the runner does not check permission levels, so everyone who can see job logs sees the debug output. GitLab recommends setting it only in GitLab, not on the runner.
| Where set | Who sees debug logs |
|---|---|
.gitlab-ci.yml or CI/CD settings | Developer, Maintainer, Owner |
| Local runner variable | Everyone with job log access |
Why masking does not save you
Masking replaces known values with a placeholder in the log, but it matches exact strings. GitLab's variables page notes masking can fail when output is changed, for example when shell escaping adds backslashes, and says it is not a guaranteed way to stop a malicious user. A trace prints transformed and partial values, which is exactly where masking is weakest.
Safer ways to debug a failing job
- Re-run with a small extra step that prints non-secret facts, such as tool versions and file lists.
- Keep secrets in protected, hidden or file type variables where you can, and avoid commands that dump the environment.
- If you must trace, set the variable on a single manual run, from a private project, with logs not public.
- Delete the job log afterwards. Deletion is permanent and needs the job owner or a Maintainer.
- Rotate any secret the job could read if the log was ever visible to someone who should not see it.
- Add a review rule so changes to
.gitlab-ci.ymlthat addCI_DEBUG_TRACEneed approval. See CODEOWNERS for pipeline files.
Our checklist on secrets in CI test logs and artifacts covers the wider problem, and who can read job logs covers visibility settings.
Safeguard's policies and gates can add automated checks to changes before they merge, and you can try a free scan at https://gold.safeguard.sh/scan.
Quick check
Is a private project log safe to trace?
Safer, not safe. Anyone with Developer access can read it, so rotate secrets that matter.
Can I block someone adding the variable in a merge request?
Review rules on the pipeline file help, but a variable set in project settings needs Maintainer access, so keep that role small.
Sources
- GitLab Docs: Troubleshooting CI/CD variables, fetched 19 October 2026.
- GitLab Docs: CI/CD variables, fetched 19 October 2026.
Last reviewed: 19 October 2026.
