GitHub Actions Inspector
Detect security issues in GitHub Actions workflows: unpinned actions, exposed secrets, and dangerous triggers
Enter your GitHub Actions workflow YAML to scan for security vulnerabilities and misconfigurations
What is the GitHub Actions Inspector?
The GitHub Actions Inspector is a client-side security tool that analyzes your GitHub Actions workflow YAML files for vulnerabilities. It detects excessive permissions, hardcoded secrets in run scripts, unpinned third-party actions vulnerable to supply chain attacks, dangerous triggers like pull_request_target, and script injection risks — then calculates a security score with prioritized remediation recommendations.
How to Use
- Paste your GitHub Actions workflow YAML into the input field
- Click "Inspect" or wait for automatic processing
- Review security findings with severity ratings (Critical, High, Medium, Low)
- Follow the recommendations to harden your workflows
- Export a full security report in JSON or Markdown format
Example: Workflow with Security Issues
This workflow has multiple security vulnerabilities the inspector will detect:
name: Insecure CI
on: [pull_request_target]
permissions: write-all
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: some-org/untrusted-action@main
- run: |
echo "Title: ${{ github.event.pull_request.title }}"
api_key="sk-proj-abc123def456"
curl -H "Authorization: Bearer $api_key" https://api.example.comWhat Security Issues Are Detected?
- Excessive permissions — write-all grants full write access to all repository scopes
- Dangerous write scopes — Write access to contents, packages, deployments, or id-token
- Exposed secrets in scripts — Hardcoded passwords, API keys, tokens, and AWS credentials in run steps
- Unpinned actions — Third-party actions referenced by branch or tag instead of full SHA commit hash
- Dangerous triggers — pull_request_target and workflow_run that may execute untrusted code with elevated privileges
- Script injection — User-controlled GitHub context expressions interpolated directly into run scripts
Security Scoring
Each workflow receives a security score from 0 to 100 based on detected findings. Severity weights are: Critical (25 points deducted), High (15 points), Medium (8 points), Low (3 points). The score maps to a letter grade: A (90+), B (75+), C (60+), D (40+), F (below 40).
GitHub Actions Security Best Practices
- Pin all third-party actions to a full SHA commit hash (40-character hex)
- Set granular permissions per job — never use
permissions: write-all - Use
${{ secrets.MY_SECRET }}instead of hardcoded credentials in scripts - Avoid
pull_request_targetunless strictly necessary; never checkout the PR head ref - Pass user-controlled inputs through environment variables instead of
${{ }}in run scripts - Use Dependabot or Renovate to keep pinned action SHAs updated
- Prefer OIDC tokens (
id-token: write) over long-lived secrets for cloud authentication - Review the
permissionskey at both workflow and job level
Supply Chain Security
Third-party GitHub Actions are a common vector for supply chain attacks. When you reference an action
by tag (e.g., uses: org/action@v2), a compromised maintainer can repoint that tag to
malicious code. SHA pinning (e.g., uses: org/action@a5ac7e51b41094c92402da3b24376905380afc29)
ensures you always run the exact code you reviewed, making your CI/CD pipeline tamper-resistant.
Privacy and Security
All inspection happens entirely in your browser using JavaScript. Your GitHub Actions workflow files — which may contain sensitive information like secret names, internal infrastructure details, and deployment configurations — never leave your device. No data is stored, logged, or transmitted.
Frequently Asked Questions
What security issues does the GitHub Actions Inspector detect?
The inspector detects excessive permissions (write-all, dangerous write scopes), hardcoded secrets in run scripts (passwords, API keys, AWS keys, GitHub tokens), unpinned third-party actions (not using SHA pinning), dangerous triggers (pull_request_target, workflow_run), and script injection vulnerabilities from user-controlled GitHub context expressions.
How is the security score calculated?
The score starts at 100 and deducts points based on finding severity: Critical issues (exposed secrets in scripts) deduct 25 points, High issues (unpinned actions, excessive permissions, dangerous triggers, injection risks) deduct 15, Medium issues (dangerous write scopes) deduct 8, and Low issues deduct 3. Grades map to: A (90+), B (75+), C (60+), D (40+), F (below 40).
Why is SHA pinning important for GitHub Actions?
When you reference an action by tag (e.g., actions/checkout@v4), a malicious maintainer or compromised account can move that tag to point to different code. Pinning to a full SHA (40-character commit hash) ensures you always run the exact code you reviewed. Use Dependabot or Renovate to automate SHA updates when new versions are released.
Why is pull_request_target flagged as dangerous?
Unlike pull_request, the pull_request_target trigger runs in the context of the base branch with write permissions and access to secrets. If the workflow checks out the PR's head ref and executes its code, an attacker can submit a malicious PR that exfiltrates secrets or modifies your repository. Use pull_request trigger instead when possible.
What is script injection in GitHub Actions?
Script injection occurs when user-controlled GitHub context values (like issue titles, PR bodies, or comment text) are interpolated directly into run scripts using ${{ }}. An attacker can craft a PR title or issue body containing shell commands that execute in your workflow. Use environment variables to pass these values safely.
Why should I avoid write-all permissions?
The write-all permission grants the workflow token write access to all repository scopes (contents, packages, deployments, etc.). If any step is compromised — through a supply chain attack on a third-party action or injection vulnerability — the attacker gains full write access to your repository, packages, and deployments. Always use granular permissions per job.
Are official GitHub actions (actions/*) exempt from SHA pinning?
The inspector treats actions from the official 'actions/' and 'github/' organizations as lower risk when pinned to a tag, since GitHub maintains these. However, for maximum security in production workflows, SHA pinning is still recommended even for official actions to prevent any theoretical compromise of the GitHub Actions organization.
How should I handle secrets in GitHub Actions workflows?
Never hardcode secrets directly in workflow YAML files. Use GitHub Secrets (Settings → Secrets and variables → Actions) and reference them as ${{ secrets.MY_SECRET }}. Pass secrets to steps via environment variables rather than directly in run scripts. For OIDC-compatible services, use the id-token permission with federated credentials instead of long-lived secrets.
Does the inspector support multi-job workflows?
Yes. The inspector analyzes the entire workflow file including all jobs and their steps. Permissions are checked at both workflow level and individual job level. Each job's steps are scanned for unpinned actions, exposed secrets, and injection vulnerabilities independently.
Is my workflow file sent to any server?
No. All analysis happens entirely in your browser using JavaScript. Your GitHub Actions workflow files — which may contain sensitive information like secret names, internal infrastructure details, and deployment configurations — never leave your device. No data is stored, logged, or transmitted.