Rules / GL018

GL018 Secret variable re-exported at pipeline level

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

What glsec checks

glsec flags top-level variables: entries whose name ends with a secret-indicating suffix (_TOKEN, _SECRET, _PASSWORD, _PASSWD, _PASS, _PWD, _KEY, _CREDENTIAL, _CERT) and whose value is a CI variable reference ($VAR or ${VAR}).

This pattern re-exports a GitLab Settings variable at the pipeline level, making it available to every job in the pipeline — including test jobs, lint jobs, and jobs triggered by merge requests from untrusted forks. If any of those jobs are compromised (e.g. via a poisoned dependency or injected script), the secret is accessible.

Trigger example

variables:
  PROD_DB_PASSWORD: $PROD_DB_PASSWORD   # available to all jobs
  AWS_SECRET_ACCESS_KEY: $AWS_SECRET_ACCESS_KEY

test:
  script: npm test  # gets PROD_DB_PASSWORD and AWS_SECRET_ACCESS_KEY for free

deploy:
  environment: production
  script: ./deploy.sh  # the only job that actually needs these

Safe alternatives

Move the variable to job level so only the job that needs it has access:

deploy:
  environment: production
  variables:
    PROD_DB_PASSWORD: $PROD_DB_PASSWORD   # only available in this job
  script: ./deploy.sh

Use GitLab Settings environment scoping (Settings → CI/CD → Variables → Environment scope): restrict the variable to the production environment so it is only injected into jobs with environment: production.

Notes

• Only top-level variables: entries are flagged — job-level variables are appropriately scoped and not reported.
• Literal values (non-variable-reference) with secret-indicating names are covered by GL006, not this rule.
• Both scalar and extended forms are checked:

  variables:
    DEPLOY_TOKEN:
      value: $DEPLOY_TOKEN
      description: "Used by deploy job"
  

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