Rules / GL053

GL053 Missing `workflow:rules` allows pipelines from untrusted sources

Severity: warn
OWASP: CICD-SEC-4 – Poisoned Pipeline Execution
CWE: CWE-284 – Improper Access Control

Risk

Without a top-level workflow:rules block, GitLab runs a pipeline for every event — including merge requests from external contributors and fork pipelines. Fork pipelines run the forked repository's pipeline code but in the context of the upstream project, potentially with access to protected variables if the runner configuration is not hardened.

A workflow:rules block that explicitly gates on a trusted source or branch (e.g. $CI_PIPELINE_SOURCE == "push", $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH) is the primary project-level defence against untrusted pipeline execution.

Trigger example

# no workflow: block at all — pipelines run for every event including fork MRs
build:
  script: make

# workflow:rules present but with no source/branch condition
workflow:
  rules:
    - when: always

build:
  script: make

Safe alternative

workflow:
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
    - if: $CI_COMMIT_TAG

build:
  script: make

What is not flagged

The rule treats a workflow:rules block as intentionally source-filtered — and stays silent — when any rule's if: references one of:

$CI_PIPELINE_SOURCE
$CI_COMMIT_BRANCH / $CI_COMMIT_REF_NAME / $CI_COMMIT_REF_SLUG
$CI_COMMIT_TAG
$CI_MERGE_REQUEST_IID
$CI_DEFAULT_BRANCH

Notes

Severity is warn — many simple projects intentionally run on all events, and some rely on hardened runner / protected-variable configuration rather than workflow rules.
Suppress per-file with a .glsec-ignore entry or inline # glsec:ignore GL053 if your project deliberately runs unrestricted pipelines.

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

GL053 Missing workflow:rules allows pipelines from untrusted sources