poutine

Scans CI pipelines in a repo or a whole GitHub or GitLab org for supply-chain misconfigurations, with rules in Rego.

Stars: ★ 523
License: Apache-2.0
Language: Go
Latest release: v1.1.6 · 22 May 2026
Last push: 9 Oct 2026
OpenSSF Scorecard: 7.6 / 10

ghtier rating4/5 · Recommended

Strong at org-wide scans and build-tool risks, but fewer workflow audits than zizmor and a smaller community.

How it works

poutine, from BoostSecurity, reads pipeline definitions (GitHub Actions, GitLab CI and others) into a common model and evaluates rules written in Rego with an embedded Open Policy Agent engine. It can scan a local checkout, one remote repository, or every repository in an organization through the API.

Its distinctive rule is untrusted_checkout_exec: it knows which build tools execute code from the working tree (npm install, make, pip and many more, catalogued in BoostSecurity's Living Off The Pipeline project) and flags them when they run on a checkout of PR code in a privileged workflow. Other rules cover injection, self-hosted runners on PR triggers, default permissions on risky events and known-vulnerable build components.

What it catches

Privileged workflows that build or install untrusted PR code
Expression injection in run: steps and scripts
Self-hosted runners reachable from pull requests
Jobs that receive all secrets
Known-vulnerable actions and build components

Run it

brew install poutine
poutine analyze_local .
# a whole org, with GH_TOKEN set:
poutine analyze_org my-org --format sarif

What leaves your machine

analyze_local sends nothing. analyze_repo and analyze_org call the GitHub or GitLab API with your token and clone the repositories.

Limits

Fewer GitHub-specific audits than zizmor (no impostor commit or cache-poisoning checks).
Writing your own rules means learning Rego.

Related incidents

OrganizationOngoing

"Pwn requests": pull_request_target & workflow_run

The structural flaw behind most of the incidents on this page. pull_request deliberately withholds write permissions and secrets; pull_request_target was created to restore them, and becomes hazardous the moment maintainers treat it as a normal CI trigger. workflow_run carries the same risk and gets far less attention: the triggered workflow can access secrets and write tokens even when the workflow that triggered it could not. One industry scan found 38% of organizations have a workflow vulnerable to script injection or dangerous triggers. Since 8 December 2025, pull_request_target always runs the workflow file from the default branch and checks out the default branch, whatever branch the pull request targets. That closes attacks through an old, vulnerable workflow left on another branch. It does not help when the default branch workflow itself checks out and runs the pull request's code.

Click to open →

OrganizationDecember 2024

Ultralytics build cache poisoning

Template injection via a crafted branch name against a format.yml workflow using pull_request_target. Secrets including secrets._GITHUB_TOKEN were exfiltrated and the build cache poisoned to inject a cryptominer into v8.3.41 and v8.3.42. The read from researchers was that the attackers had write access but preferred extracting CI/CD secrets, then used them to poison the cache and ship malicious releases.