Skip to content

ActionScope

If a GitHub Actions workflow in your repo is compromised, what can an attacker actually do in your AWS account?

ActionScope reads your .github/workflows/ files, Terraform and JSON IAM policies, and tells you — in plain English — what your CI/CD pipeline can actually do in AWS, and which workflow-layer attack surfaces it exposes.

Get started in 30 seconds Install from PyPI

What it catches

  • Known-compromised actions

    Curated database of compromised actions — tj-actions/changed-files, actions-cool/issues-helper, actions-cool/maintain-one-comment, aquasecurity/trivy-action. Mutable-tag references produce a CRITICAL finding with the advisory URL.

    Browse the database

  • OIDC trust misconfigurations

    Wildcard subjects, missing sub/aud, unsafe set operators, branch scoping instead of environment scoping. SARIF rule AS007/AS008.

    Read the guide

  • Script injection / pwn requests

    Detects direct interpolation of attacker-controlled GitHub event fields (github.event.pull_request.title, github.event.issue.body, …) into run: blocks — the pattern behind the April 2026 prt-scan attack.

  • IAM blast radius

    Extracts every aws-actions/configure-aws-credentials role ARN, correlates with Terraform or JSON IAM policies in your repo, and classifies the resulting blast radius. Optionally verifies live via read-only IAM API calls.

    AWS verification setup

  • Unpinned actions

    Distinguishes full-SHA pins (safe) from short SHAs (still mutable), tags, and branches. --resolve-pins suggests current SHAs via the GitHub API.

  • SARIF for Code Scanning

    Native SARIF 2.1.0 output with 16 rules (AS001-AS016). Upload to the GitHub Security tab for first-class alerts.

    SARIF integration

  • Reusable workflows

    Follows local jobs.<id>.uses calls recursively, reports mutable external refs, and can inspect external workflow YAML with a GitHub token.

    Reusable workflow inspection

  • Correlated exposure paths

    Connects mutable or known-compromised actions to AWS credentials and reachable IAM permissions in the same workflow job.

    Exposure path model

How it's different from actionlint, zizmor, Scorecard, Checkov

Most workflow-security tools answer one side of the boundary:

  • actionlint — is this workflow YAML valid?
  • zizmor / Scorecard — does this workflow have dangerous patterns?
  • Checkov — are these IAM policies misconfigured (in isolation)?

ActionScope crosses the boundary. It ties a specific workflow to a specific IAM role to a specific blast radius and emits a single, correlated report.

30-second install

pip install actionscope
actionscope scan .                  # static analysis, no AWS creds needed
actionscope scan . --aws-verify     # live IAM verification (read-only)
actionscope scan . --resolve-pins   # suggest full-SHA pins for unpinned actions
actionscope scan . --github-token "$GITHUB_TOKEN"  # inspect shared workflows

Or use it as a GitHub Action:

- uses: r12habh/ActionScope@v0
  with:
    fail-on: high
    comment-pr: true
    upload-sarif: true

Research-backed

ActionScope ships with findings from a public study of 493 GitHub repositories and 3,981 AWS-enabled workflows:

  • 95.5% use at least one external action not pinned to a full SHA
  • 58.2% use static AWS access keys instead of OIDC
  • 44.0% expose role ARNs directly in workflow YAML
  • 8.1% combine pull_request_target with write-capable token permissions — the pattern behind the April 2026 prt-scan attack

Full research findings

Limitations and calibration

Not every finding is a confirmed vulnerability. Some are exposure signals that need human review, and some are context-dependent. Understanding the difference is key to trusting ActionScope's output.

Read the limitations guide