How do you find security issues in GitHub Actions workflows with zizmor?

What zizmor is looking for in a workflow

zizmor is most useful when you treat it as a workflow security reviewer, not a generic linter. It inspects the YAML for patterns that expand trust unexpectedly, such as broad trigger conditions, overbroad token permissions, risky use of untrusted event data, and workflow steps that can be steered by repository content or pull request inputs.

That makes the unit of review the workflow’s trust boundary, not just the syntax. A finding matters when it changes who can trigger the job, what the job can access, or whether attacker-controlled input can influence execution.

For teams that want a broader GitHub Actions hardening baseline, the GitHub and GitHub Actions Security Guide covers the surrounding controls that make zizmor findings easier to interpret and fix.

How to triage findings without overreacting

Not every warning is equally urgent. A good triage pass asks whether the workflow runs on protected branches, whether it can reach production secrets, whether the action is pinned and trusted, and whether the input path is attacker-influenced. Findings become high priority when a low-trust event can reach a high-value secret or deployment path.

Where a finding is about a public pull request, a fork, or other untrusted source, assume the workflow is hostile until proven otherwise. Where the workflow already uses strict permissions and narrow triggers, the same finding may be a low-risk hygiene issue rather than an immediate exposure.

If you want concrete examples of how a small workflow mistake turns into secret exposure, the GhostAction campaign 2025 and tj-actions/changed-files compromise 2025 show why apparently routine workflow paths deserve careful review.

What to fix first in a risky workflow

Start with the changes that reduce blast radius fastest: narrow the trigger, reduce token permissions, and remove any step that consumes untrusted data in a privileged context. Then review third-party actions, pin them to immutable references, and separate build-time jobs from release or deployment jobs so the same workflow does not both ingest outside input and handle sensitive credentials.

When zizmor flags something that touches secrets, release automation, or self-hosted runners, the right fix is usually structural rather than cosmetic. The goal is to make the dangerous path impossible, not merely less obvious in the YAML.

When you need a deeper model for these decisions, the CI/CD Pipeline Identity Security Guide is the best companion for understanding where workflow permissions, OIDC federation, and publishing tokens change the risk profile.

Risk and Threat Considerations

GitHub Actions workflows are attractive because they often sit close to source code, CI secrets, and deployment credentials. A weak trigger or permissive job token can let untrusted code influence a trusted pipeline, which turns a routine automation path into a secret-exposure and supply-chain risk.

Failure mechanism: An attacker exploits workflow trust assumptions, such as permissive pull request handling, unsafe context interpolation, or overbroad permissions, to run code or read secrets in a job that was meant to be restricted.

Impact: The result can be leaked credentials, malicious releases, tampered build artifacts, or lateral movement into package, cloud, or production systems if the workflow had privileged access.

Practitioner Guidance

What to verify: Check whether each zizmor finding is reachable from an untrusted event path and whether the workflow can touch production-scoped secrets, deployment tokens, or release automation. If yes, treat the issue as a real exposure even if no abuse has been observed.

Decision rule: If the finding affects trigger scope, token scope, or untrusted input handling, fix the workflow before merging; if it only flags a low-impact pattern in a non-privileged job, track it as hardening debt and verify it cannot grow into a sensitive path later.

Practitioner takeaway: zizmor is most valuable when you use it to reason about trust boundaries, not just code style, because the dangerous cases are the ones where attacker-controlled input reaches a privileged workflow step.

Related resources from NHI Mgmt Group

• How should security teams reduce risk from compromised GitHub Actions workflows?
• How should security teams govern GitHub Actions workflows that use secrets to update policy stores?
• How should security teams prevent shell injection in GitHub Actions workflows that interpolate untrusted context data?
• How should security teams implement short-lived access for GitHub Actions and similar automated workflows?