Guardrails / pipeline

No privileged workflow runs untrusted code

pipeline/no-untrusted-checkout@v1

No workflow triggered by pull_request_target, issue_comment or workflow_run checks out a revision of its own choosing, or passes the request's revision into a command.

Id	pipeline/no-untrusted-checkout
Version	v1
Category	pipeline
Default severity	error
Interpreter	python3
Timeout	30 seconds
Violations tolerated	0
Collects	workflow

Collectors

This guardrail gathers nothing itself. It depends on the collectors below, which the CLI runs once per build before any check, and reads what they found out of GUARDRAIL_FACTS. A collector that collects nothing skips this guardrail rather than failing it.

Collector	Gathers	Inputs it is given
workflow	The pipeline definitions in the checkout, read as they are written: which triggers start them, what permissions they hand a job, which runner each job asks for, and every action a step reaches for and how tightly it is pinned. Names and shapes only, never a secret, an input value or an environment value.	pipelines

The inputs above are this guardrail's own, passed straight through. Configuring one in buildnote.json changes what is collected, and two guardrails configured the same way share the one collection.

Configuration

{
  "guardrails": {
      "failOn": "error",
      "comment": true,
      "checks": [
          {
              "use": "pipeline/no-untrusted-checkout@v1",
              "severity": "error",
              "with": {
                  "pipelines": ".github/workflows/*.yml,.github/workflows/*.yaml,.gitlab-ci.yml,azure-pipelines*.yml,Jenkinsfile"
              },
              "exemptions": []
          }
      ]
  }
}

Inputs

Input	Description	Default	Environment variable
pipelines	Comma separated globs naming the pipeline definitions to read.	.github/workflows/*.yml,.github/workflows/*.yaml,.gitlab-ci.yml,azure-pipelines*.yml,Jenkinsfile	GUARDRAIL_INPUT_PIPELINES

How to fix

Split the workflow. Do the untrusted work under pull_request, which runs without your secrets, and leave the privileged trigger to the step that needs the token, checking out only the base:

on: pull_request_target
jobs:
  label:
    steps:
      - uses: actions/checkout@<sha>

pull_request_target runs with the repository's secrets and a writable token against a workflow definition from the base branch. Checking out the pull request head under it hands both to whoever opened that pull request, which is the single most exploited CI misconfiguration there is.

This reads the input names a checkout step declares, not their values, so a ref under one of these triggers is the signal. Checking out the base explicitly is the rare legitimate case: give that step no ref at all, which is what checking out the base means under pull_request_target.

More in pipeline

• pipeline/actions-pinned-by-digest. Every third party action a workflow uses is pinned to a full commit sha rather than to a tag or a branch.
• pipeline/job-timeout-set. Every job declares how long it may run, so a hung job is cut off rather than holding a runner until the platform's own limit.
• pipeline/least-privilege-token. Every workflow declares permissions, and none of them takes write access to everything.
• pipeline/no-script-injection. No run step interpolates a ${{ }} expression an outsider controls, such as a pull request title or a branch name, straight into the shell body.

All 5 pipeline guardrails