Rules / GL012

GL012 when: always on deploy-stage job

Severity: warn
OWASP: CICD-SEC-1 – Insufficient Flow Control Mechanisms

What glsec checks

glsec flags jobs that have when: always AND are identified as deployment jobs by either:

• Having an environment: key (unambiguous deploy context), or
• Having a stage: whose name contains a deploy-related keyword: deploy, release, publish, ship, prod, production, staging

Jobs in test, build, lint, or security stages are excluded — when: always there is sometimes intentional for cleanup or reporting tasks.

Trigger example

stages: [test, deploy]

sast:
  stage: test
  script: run-sast

deploy-production:
  stage: deploy
  when: always          # runs even if sast failed
  environment: production
  script: ./deploy.sh

Safe alternative

Remove when: always and rely on the default when: on_success, which only runs the job if all prior jobs in the pipeline passed:

deploy-production:
  stage: deploy
  # when: on_success is the default — no need to specify
  environment: production
  script: ./deploy.sh

If you need to deploy after a partial failure (e.g. only one test suite failed), use a dependency-based approach with needs: instead of bypassing all gates.

Why this matters

when: always tells GitLab to run the job regardless of the outcome of all preceding jobs. On a deployment job this means:

• A failed SAST scan does not prevent deployment
• Failed unit tests do not prevent deployment
• A failed secret_detection job does not prevent deployment

The security and quality gates in earlier stages are effectively disabled for the downstream deployment.

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