GitHub Actions Workflow Security Analyzer
Check a GitHub Actions workflow for script injection, dangerous triggers, unpinned actions, broad token permissions and leaked secrets. Runs in your browser, nothing is uploaded.
Runs in your browser Your input never leaves your device.
Paste a workflow (.github/workflows/*.yml) or a composite action.yml. It is read in your browser: nothing is uploaded, and nothing is fetched from GitHub, so pins are judged by their form (a full 40-character commit hash), not checked against the repository.
Findings
Jobs
| Job | Runs on | Steps | Line |
|---|
What is checked
Triggers that run untrusted pull request code with secrets (pull_request_target, workflow_run); script injection through ${{ }} expressions in run scripts and github-script, rated by how much an attacker controls the value; actions and reusable workflows not pinned to a commit; Docker images that are not pinned or use latest; container passwords written in the file; token permissions (none set, write-all, write scopes shared by every job); checkout that leaves the token in .git/config; ACTIONS_ALLOW_UNSECURE_COMMANDS; secrets: inherit; untrusted data written to GITHUB_ENV or GITHUB_PATH; bot-name conditions; self-hosted runners; secrets pasted into script text; downloads piped into a shell; credentials committed in the file; and checkout of pull request code under a privileged trigger.
Findings describe the text you pasted, not your repository settings. The core rules were compared with the zizmor auditor on hundreds of generated workflows and on the workflows shipped in common npm packages; run zizmor and actionlint in CI for the full picture.
Report a problem with this tool
About this tool
GitHub Actions workflows run with your repository secrets and a write-capable token, so a few patterns matter more than any others: untrusted text from an issue or pull request pasted into a shell script (script injection), the pull_request_target and workflow_run triggers that run privileged jobs for fork pull requests, third-party actions referenced by a movable tag instead of a commit, and a GITHUB_TOKEN with more access than the job needs. This tool reads a workflow or a composite action.yml in your browser and reports them with the line of each. For every ${{ }} expression in a run script or github-script it decides whether an attacker can control the value (issue and pull request titles, branch names, commit messages and similar are high; inputs and env are lower; fixed values such as the commit sha are ignored). It checks pins by form: only a full 40-character commit hash counts. The core rules (triggers, script injection, unpinned actions and images, container credentials, insecure commands, secrets: inherit, persisted checkout credentials, missing permissions, GITHUB_ENV writes, bot conditions) follow the zizmor auditor and were compared with it on hundreds of generated workflows and on the workflows shipped in a few common npm packages; the rest (pwn-request checkout, secrets in script text, downloads piped to a shell, committed credentials, self-hosted runners) are extra. It reads text only: it does not fetch actions, check that a commit exists, read repository settings or run anything.
How to use it
- Paste the workflow YAML or load the file.
- Read the findings from the top: critical and high ones are paths to code execution or credential theft.
- Fix script injection by passing the value through an environment variable, and pin actions to a commit hash with the version in a comment.
- Copy the Markdown summary into your pull request or ticket.
Common problems
- It says the YAML cannot be parsed
- GitHub would reject the file too. The message names the problem; a common cause is a colon followed by a space inside an unquoted run line, which needs quotes or a block (run: |).
- An action I pin is still reported
- Only a full 40-character commit hash counts as pinned. A short hash, a tag like v4 and a branch name are all movable.
- A finding is a false positive for my setup
- The rules look at the text only. For example a pull_request_target workflow that never checks out or runs pull request code can be safe, but is still flagged because it is easy to break later.