# zizmor: static analysis for GitHub Actions workflows

> zizmor is a Rust static analysis tool for CI/CD configuration, aimed at teams who want to catch template injection, credential leakage and excessive permissions in GitHub Actions before a workflow runs. It installs from crates.io, PyPI or a container image, and its audits are the part worth reading first.

**zizmorcore/zizmor** — Static analysis for GitHub Actions

- Repository: https://github.com/zizmorcore/zizmor
- Website: http://docs.zizmor.sh/
- Stars: 6,617 · Forks: 261
- Language: Rust
- License: MIT
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/zizmorcore-zizmor

## The problem zizmor targets: workflow YAML that runs with your credentials

A GitHub Actions workflow is executable code that most reviewers read as configuration. It can interpolate untrusted input into a shell command, hand a runner a token with more scope than the job needs, or leave credentials behind in a cache or artifact. The README lists exactly this class of finding: template injection leading to attacker-controlled code execution, accidental credential persistence and leakage, excessive permission scopes and credential grants to runners, and impostor commits with confusable git references. The audience is anyone who owns a repository where .github/workflows/ is edited by more than one person, and where a merged workflow file is a deployment path. The README also says zizmor covers Dependabot and pre-commit, so the scope is CI/CD configuration generally rather than Actions alone.

## How zizmor works: a Rust workspace of parsers and audit crates

The Cargo.toml workspace lists the crates that make up the tool: github-actions-expressions, github-actions-models, pre-commit-models, yamlpatch, yamlpath, tree-sitter-iter, zizmor itself and zizmor-sarif. Those names describe a pipeline. The models crates turn workflow and pre-commit files into typed structures, the expressions crate handles the ${{ }} expression language, yamlpath and yamlpatch address locations inside a YAML document, and zizmor-sarif converts findings into SARIF for code scanning. The Dockerfile shows a second packaging path: the prep stage runs uv tool install zizmor==${ZIZMOR_VERSION} on a Wolfi base image and copies the resulting binary into a runtime image whose entrypoint is /usr/bin/zizmor. The Makefile adds a schema target, cargo run --features schema -- --generate-schema, which writes support/zizmor.schema.json, so the tool can emit a machine-readable schema of its own configuration. The practical consequence of the Rust binary plus the SARIF crate is that zizmor can run as a local command or as a code scanning uploader without a separate converter.

## Installing zizmor and running a first audit

The README points to docs.zizmor.sh/installation/ for installation steps and does not repeat them inline, so the commands below come from the packaging files in the repository rather than from the README. The Dockerfile installs the tool with uv, which means the PyPI distribution is a working entry point:

```bash
uv tool install zizmor
zizmor --version
```

If you prefer a container, the Dockerfile's runtime stage ends with an entrypoint of /usr/bin/zizmor, so the image runs the tool directly and a smoke test of zizmor --version is already baked into the build. The Cargo.toml sets rust-version = "1.97.0" and edition = "2024", so a source build needs a toolchain at least that new. Once the binary is on your PATH, point it at a repository and read the findings:

```bash
zizmor .
```

The README does not document the exact default output format or the exit code behaviour, so check docs.zizmor.sh/usage/ for the recipes the project maintains. For CI, the zizmor-sarif crate exists to produce SARIF, and the documentation is the place to confirm the flag that selects it.

## Where zizmor stops being the right tool

zizmor reads configuration. It does not run your workflow, and nothing in the README claims it observes runtime behaviour, so a finding it reports is a property of the YAML rather than proof of exploitability in your environment. That distinction matters when a workflow is generated by a template engine or a bot: the file zizmor sees may not be the file that runs. The scope is also narrower than the name CI/CD suggests. The README names GitHub Actions, Dependabot and pre-commit; GitLab CI, Jenkins and CircleCI are not mentioned, and the workspace crates are github-actions-models and pre-commit-models, which is consistent with that boundary. A team standardised on GitLab should treat zizmor as out of scope rather than as a gap to work around. There is also a noise cost the README does not address: it documents no suppression syntax inline, and the related search phrase "Zizmor: ignore" suggests users look for one, so plan to read the audit documentation before enabling the tool on a large repository.

## zizmor compared with actionlint and CodeQL

actionlint and zizmor both read GitHub Actions YAML, but they answer different questions. actionlint is a linter for workflow correctness: expression syntax, shellcheck integration, runner label validity. zizmor's README frames its output as security findings, which is why the audit list reads like a threat model rather than a style guide. The two are complementary, and the related searches show people compare them directly. CodeQL is a different category again. It analyses application source code with a query language and a database build step, while zizmor parses CI configuration and ships its checks as compiled audits in the same binary. If your concern is a vulnerable dependency in a workflow step, neither zizmor nor actionlint is a scanner for that; the README lists Dependabot as a configuration format zizmor analyses, not as a vulnerability database.

## Maintenance, release cadence and the MIT licence

The most recent release listed is v1.30.1 on 2026-09-09, with v1.30.0 on 2026-08-30 and a release candidate before it, and the last push to the default branch was on 2026-09-21. The repository is not archived. The workspace version in Cargo.toml is 1.30.1, matching the release tag, so the crates and the binary move together. The licence is MIT, stated in the README and in the workspace package metadata, which permits commercial use and modification provided the copyright notice and permission notice are preserved; the repository has no separate licence file listed beyond LICENSE. Upgrading means tracking the crate version, the PyPI version and the container tag, since the Dockerfile takes ZIZMOR_VERSION as a build argument rather than pinning a digest. Nothing in the repository describes a migration policy or a deprecation window for audits, so a version bump is the moment to re-read docs.zizmor.sh/audits/ and see which checks changed.

## Conclusion

Adopt zizmor if your repository already carries GitHub Actions workflows and you want a fast, offline check that runs in CI or a pre-commit hook. Skip it if your CI is not GitHub Actions, Dependabot or pre-commit: the audit set is built around those formats, and the README lists no other CI system. Before rolling it out, read docs.zizmor.sh/audits/ and confirm which audits are enabled by default in the version you install, because the README does not state the default set.

## FAQ

### What is zizmor?

zizmor is a static analysis tool for CI/CD systems, written in Rust and licensed under MIT. The README says it finds and fixes security issues in GitHub Actions, Dependabot and pre-commit setups, including template injection, credential leakage and excessive permission scopes.

### How do you use zizmor?

Install the binary, then point it at a repository: the Dockerfile installs it with uv tool install zizmor, and the README directs readers to docs.zizmor.sh/quickstart/ and docs.zizmor.sh/usage/ for the quickstart and usage recipes.

### How does zizmor compare with actionlint?

actionlint is a linter for workflow correctness, while zizmor's README describes security findings such as template injection and excessive credential grants. They read the same YAML and answer different questions, so running both is reasonable.

### How does zizmor compare with CodeQL?

CodeQL analyses application source code, while zizmor parses CI configuration files such as GitHub Actions workflows. The workspace includes a zizmor-sarif crate, so zizmor findings can be emitted in the same SARIF format code scanning tools consume.

### What are alternatives to zizmor?

The README's scope is GitHub Actions, Dependabot and pre-commit, and the workspace crates are github-actions-models and pre-commit-models. actionlint, a linter for GitHub Actions workflow correctness, and CodeQL, which analyses source code rather than CI configuration, are the two comparison points the project's own search traffic raises.

## Sources

- [License: MIT](https://github.com/zizmorcore/zizmor/blob/main/LICENSE)
- [Project website](http://docs.zizmor.sh/)
- [README](https://github.com/zizmorcore/zizmor/blob/main/README.md)
- [Releases](https://github.com/zizmorcore/zizmor/releases)
- [zizmorcore/zizmor on GitHub](https://github.com/zizmorcore/zizmor)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/zizmorcore-zizmor