← GitHub Actions secrets: inherit Check
GitHub Actions secrets: inherit Check vs. zizmor
zizmor's secrets-inherit audit already flags secrets: inherit on a
reusable-workflow call, local or external. This tool's matching finding covers the same external-workflow
ground. What it adds is the one question that audit does not ask: is the job reachable from a stranger's
fork in the first place?
What each tool is for
zizmor (github.com/zizmorcore/zizmor) is an open-source, MIT-licensed static
analysis tool for GitHub Actions, installed with pip install zizmor or
cargo install zizmor and run against workflow files or a whole repository. Its
secrets-inherit audit, per its own documentation, detects excessive secret inheritance
between a calling workflow and a reusable (called) workflow: any job whose uses: calls a
reusable workflow with secrets: inherit, whether that workflow is local
(./.github/workflows/file.yml) or external
(owner/repo/.github/workflows/file.yml@ref), on the reasoning that secrets: inherit
violates the principle of least authority and makes it impossible to tell which exact secrets a reusable
workflow actually ran with.
This checker makes the narrower secrets-inherit-external-workflow finding on
the same external-repository pattern zizmor already covers -- and covers less of it, since it does not
flag a local reusable-workflow call the way zizmor does. What it adds is
secrets-inherit-untrusted-trigger: secrets: inherit on a job whose workflow is
triggered by pull_request_target or workflow_run, where a fork's pull request
controls the event and the job still runs with the base repository's context. Per zizmor's published
documentation and source, its secrets-inherit audit does not check which trigger a job runs
on or whether a fork can reach it -- it flags the inheritance on its own, regardless of reachability.
| Question | Where to answer it |
|---|---|
I want to know whether any job in my repo hands a reusable workflow every secret with secrets: inherit, local or external. | zizmor's secrets-inherit audit -- it covers both, this tool only the external half. |
I want to know whether a pull_request_target or workflow_run job -- one a fork can trigger -- is the one holding secrets: inherit. | This checker -- zizmor's audit does not check the trigger or fork-reachability at all. |
| I want one maintained scanner covering dozens of GitHub Actions security patterns beyond secret inheritance -- permissions, injection, cache poisoning, impostor commits, and more. | zizmor -- that breadth is its whole job; this tool checks only the two secrets: inherit patterns above. |
| I don't want to install a CLI (pip or cargo) just to check one file. | This checker -- it is a page, not a package. It only makes sense as a substitute for the external-workflow finding, though; for the trigger-reachability finding there is nothing else to substitute for. |
Run zizmor for full coverage of the inheritance pattern, including local reusable workflows. This tool is worth a separate pass specifically for the trigger question -- a repository can pass zizmor's secrets-inherit audit today and still have a pull_request_target or workflow_run job handing a fork-reachable run every secret it can see, and nothing in that audit's stated scope would flag it.
Common questions
Does zizmor already catch secrets: inherit?
Yes, for the pattern itself. zizmor is an open-source, MIT-licensed static analysis CLI (installed with pip install zizmor or cargo install zizmor) whose secrets-inherit audit, per its own documentation, detects excessive secret inheritance between a calling workflow and a reusable (called) workflow -- any job whose uses: calls a reusable workflow with secrets: inherit, local (./.github/workflows/file.yml) or external (owner/repo/.github/workflows/file.yml@ref) alike, on the reasoning that secrets: inherit violates the principle of least authority and makes it impossible to tell which exact secrets a reusable workflow ran with. This checker's secrets-inherit-external-workflow finding is the external-repository slice of that same pattern.
What does zizmor's secrets-inherit audit not check?
Per its published documentation and source, zizmor's secrets-inherit audit does not check whether the job carrying secrets: inherit is reachable from a pull_request_target or workflow_run trigger -- it flags the inheritance itself, regardless of which trigger runs the job or whether a fork can raise it. This checker's second finding, secrets-inherit-untrusted-trigger, is exactly that reachability check: secrets: inherit on a job whose workflow is triggered by pull_request_target or workflow_run, where a stranger's fork controls the event.
So is this checker just a narrower copy of zizmor?
For one of its two findings, yes -- secrets-inherit-external-workflow covers ground zizmor's secrets-inherit audit already covers, and covers more broadly (zizmor also flags a local reusable-workflow call, which this tool does not, since a local call carries no different-repository risk). This tool's reason to exist is the other finding: secrets-inherit-untrusted-trigger, the pull_request_target/workflow_run reachability check that is outside the stated scope of zizmor's audit. If you already run zizmor, this tool adds that one check; it does not replace zizmor.
Why use a narrower tool instead of just running zizmor?
Two reasons, and only one is about coverage. First, zizmor is a CLI you install and point at files or a repository; this tool is a page you paste one file into, with nothing to install, which is faster for a single workflow you already have open. Second, and the one that matters: the untrusted-trigger finding is not in zizmor's secrets-inherit audit at all, so a clean zizmor scan can still carry a fork-reachable secrets: inherit call that only this tool's second finding names.
Does this tool need a GitHub token the way zizmor sometimes does?
No, never. zizmor documents an optional online mode -- set GH_TOKEN, GITHUB_TOKEN, or ZIZMOR_GITHUB_TOKEN -- for audits that benefit from GitHub API access. This tool has no online mode to opt into: nothing here talks to a server under any configuration, so there is no token to supply.
Is this page affiliated with zizmor or its maintainers?
No. This site is not affiliated with, endorsed by, or sponsored by zizmor, zizmorcore, or its maintainers. zizmor is an independent open-source project, named here only to describe what this checker is and is not, using facts drawn from its own public documentation and source at github.com/zizmorcore/zizmor and docs.zizmor.sh.