Security, compliance, and troubleshooting pipelines
The Security, compliance, and troubleshooting domain tests whether you can keep pipelines from leaking credentials or over-privileging jobs, apply compliance controls, and diagnose failures from configuration and runner symptoms rather than guesswork.
Security and compliance controls
Use protected branches, protected tags, protected environments, and protected runners so sensitive jobs and variables only run on reviewed refs. CI_JOB_TOKEN is scoped to the job and should be allowlisted for cross-project access; do not substitute a personal access token. OIDC id_tokens give short-lived, audience-bound credentials for cloud and Vault authentication. Masked variables reduce accidental log exposure but are not encryption. Security scanning jobs (SAST, DAST, dependency, container, secret detection) publish artifacts:reports; compliance frameworks and security policies can enforce scans and pipeline execution on protected branches. Pin remote includes and CI/CD components to immutable versions to reduce supply-chain risk.
Troubleshooting method
Validate configuration with CI Lint (/ci/lint, the API, or glab ci lint) before pushing. Read the job log for the failing script line and exit code, then check runner tags, protected status, and whether the runner is online. CI_DEBUG_TRACE: "true" increases log verbosity but can expose secrets, so enable it temporarily on a non-production ref. CI_DEBUG_SERVICES helps with service containers. Common structural errors include a visible job without script, rules combined with only/except, cyclic needs, and a needs target that rules excluded.
Worked example
workflow:
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
deploy:
rules:
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $CI_COMMIT_REF_PROTECTED == "true"
when: manual
environment: production
script: ./deploy.sh
The workflow creates pipelines only for merge requests and the default branch, reducing exposure from arbitrary branch pushes. The deploy job is limited to a protected default branch and is manual. A protected PROD_TOKEN is available only in that context; a fork MR pipeline would not receive it.
Traps
Turning on debug tracing with production secrets in scope is a leak. Assuming masking prevents all exposure is wrong; transformed secrets can still appear. Assuming CI_JOB_TOKEN can clone any project ignores allowlisting. Unpinned remote includes can change a protected pipeline without a repository change. Manual jobs and protected environments are not the same control; use both where separation of duties matters.