Rules / GL006

GL006 Hardcoded secrets in variables: block

Severity: error
OWASP: CICD-SEC-6 – Insufficient Credential Hygiene

What glsec checks

glsec scans all variables: blocks (global, default:, and per-job) for scalar values that match known secret patterns:

Values that are variable references (starting with $) are ignored. Obvious documentation placeholders are also skipped: a matched value is ignored when it contains example, placeholder, changeme, redacted, or your-token-here (case-insensitive) — for instance AKIAIOSFODNN7EXAMPLE or glpat-your-token-here.

Trigger example

variables:
  AWS_SECRET_ACCESS_KEY: "AKIAIOSFODNN7EXAMPLE"
  DEPLOY_TOKEN: "glpat-xxxxxxxxxxxxxxxxxxxx"

deploy:
  script:
    - aws s3 sync dist/ s3://my-bucket/

Safe alternative

Store secrets in GitLab CI/CD Variables (project Settings → CI/CD → Variables). Mark them as Masked so they are redacted in job logs, and optionally as Protected to restrict access to protected branches.

Reference them by name without embedding the value in the file:

variables:
  # References a masked CI/CD variable — no secret stored in the repo
  AWS_SECRET_ACCESS_KEY: "$AWS_SECRET_ACCESS_KEY"

deploy:
  script:
    - aws s3 sync dist/ s3://my-bucket/

Why this matters

Variables in .gitlab-ci.yml are committed to git history and visible to every user with repository read access. A secret stored here:

• Cannot be rotated without a new commit
• Is permanently readable in git history even after deletion
• May be exfiltrated by a compromised dependency or forked pipeline

The only safe remediation after accidental exposure is to immediately rotate the credential.

Documentation for glsec 1.23.0. Source of this page · Rule implementation