Configuration🔗
Note
Configuration support was added in v0.2.0
.
zizmor
supports a small amount of configuration via YAML config files,
typically named zizmor.yml
.
Precedence🔗
Note
Configuration is always optional, and can always be disabled with
--no-config
. If --no-config
is passed, no configuration is ever loaded.
zizmor
will discover and load
configuration files in the following order of precedence:
- Passed explicitly via
--config
, e.g.--config my-config.yml
. When passed explicitly, the config file does not need to be namedzizmor.yml
. ${CWD}/.github/zizmor.yml
${CWD}/zizmor.yml
For the last two discovery methods, ${CWD}
is the current working directory,
i.e. the directory that zizmor
was executed from.
Only one configuration file is ever loaded. In other words: if both
${CWD}/.github/zizmor.yml
and ${CWD}/zizmor.yml
exist, only the former
will be loaded, per the precedence rules above.
Settings🔗
rules
🔗
rules.<id>
🔗
rules.<id>.ignore
🔗
Type: array
Per-audit ignore rules, where id
is the audit's name, e.g.
template-injection
.
Each member of rules.<id>.ignore
is a workflow rule, formatted as follows:
where filename.yml
is the base filename of the workflow, and line
and
column
are both optional 1-based values indicating the exact line-and-column
location to ignore. If one or both are absent, then the rule applies to the
entire file or entire line.
Important
Composite action findings cannot be ignored via zizmor.yml
currently.
For example, here is a configuration file with two different audit ignore rule groups:
rules:
template-injection:
ignore:
# ignore line 100 in ci.yml, any column
- ci.yml:100
# ignore all lines and columns in tests.yml
- tests.yml
use-trusted-publishing:
ignore:
# ignore line 12, column 10 on pypi.yml
- pypi.yml:12:10
rules.<id>.config
🔗
Type: object
Per-audit configuration, where id
is the audit's name, e.g.
unpinned-uses
.
Not all audits are configurable. See each audit's documentation for details.
Patterns🔗
Several audits support being configured with patterns, which can be used
to match things like uses:
clauses. These patterns share
common syntaxes, and are described here.
Repository patterns🔗
Repository patterns are used to match uses:
clauses.
The following patterns are supported, in order of specificity:
-
owner/repo/subpath@ref
: matches the exact repository, including subpath (if given) and ref. The subpath is optional.Example
github/codeql-action/init@v2
matchesuses: github/codeql-action/init@v2
, but notuses: github/codeql-action/init@main
. -
owner/repo/subpath
: match alluses:
clauses that are exact matches for theowner/repo/subpath
pattern. Thesubpath
can be an arbitrarily deep subpath, but is not optional. Any ref is matched.Example
github/codeql-action/init
matchesuses: github/codeql-action/init@v2
, but notuses: github/codeql-action@v2
. -
owner/repo
: match alluses:
clauses that are exact matches for theowner/repo
pattern. Any ref is matched.Example
actions/cache
matchesuses: actions/cache@v3
, but notuses: actions/cache/save@v3
oruses: actions/cache/restore@v3
. -
owner/repo/*
: match alluses:
clauses that come from the givenowner/repo
. Any subpath or ref is matched.Example
github/codeql-action/*
matchesuses: github/codeql-action/init@v2
,uses: github/codeql-action/upload-sarif@v2
, anduses: github/codeql-action@v2
itself. -
owner/*
: match alluses:
clauses that have the givenowner
. Any repo, subpath, or ref is matched.Example
actions/*
matches bothuses: actions/checkout@v4
anduses: actions/setup-node@v4
, but notuses: pypa/gh-action-pypi-publish@release/v1
. -
*
: match alluses:
clauses.Example
*
matchesuses: actions/checkout
anduses: pypa/gh-action-pypi-publish@release/v1
.