Workflow Run Policies allow you to enforce security controls by blocking GitHub Actions workflow runs that violate organization-defined policies. This is particularly useful for preventing misconfigurations and supply chain attacks in your CI/CD pipelines.

How It Works

When a workflow run violates a policy, the run is automatically blocked. You can define policies such as:

• Automatically block compromised GitHub Actions, preventing them from executing in your workflows

• Whether secrets can be used on non-default branches

• Which GitHub Actions are permitted, including internal/private actions

• Which runner labels are allowed or disallowed

Below are the supported policy types and example runs where the policy enforcement blocked workflow execution:

When a workflow run is blocked, you will see this message in the workflow run:

The run was canceled by @stepsecurity-app[bot].

Compliant workflow runs continue without any impact—everything runs as expected.

Use this interactive demo to learn how to set up an Actions policy in your organization:

Use this page to view and manage all workflow run policies created in your organization.

Creating a New Policy in Your Organization

There are four policy types you can create:

• Compromised Actions Policy - Block the use of compromised Actions

• Secret Exfiltration Policy - Prevents unauthorized access to Secrets

• Allowed Actions Policy - Block specific GitHub Actions

• Runner Label Policy - Prevent or monitor usage of specific runners

Compromised Actions Policy

The Compromised Actions Policy prevents the use of known malicious or compromised GitHub Actions in workflows. It scans for references to actions flagged as security risks and blocks their execution to protect your environment.

Why It Matters

Workflows often rely on third-party actions, which may be:

• Compromised via account takeovers

• Malicious by design

• Altered to include malware or backdoors

This policy reduces risk by:

• Maintaining a list of compromised actions

• Scanning workflows for those references

• Blocking runs using them

• Alerting developers with actionable feedback

What Developers See

If a compromised action is used:

• The workflow is automatically canceled and a PR comment explains the violation and suggests trusted alternatives

To try the Compromised Action policy, add this action to your workflow:

step-security/dummy-compromised-action@main

To create a compromised Actions policy, follow the steps below:

Step 1: Navigate to the Policies page

• Go to your StepSecurity dashboard, then to Run Policies → Policies in the sidebar.

Step 2: Click “Create Policy”

• Click the Create Policy button on the top right of the page.

Step 3: Fill in Policy Details

• Policy Name – e.g., Compromised Actions Policy

• Policy Type – Select "Compromised Actions Policy"

• Action – Choose between:

  • Enforce: Actively blocks compromised Actions

  • Dry Run: Sends notifications but does not block

Step 4: Select Repositories

• Choose whether to apply the policy to:

  • All current and future repositories (default), or

  • Select specific repositories manually

Step 6: Save the Policy

• After configuring all settings, click Save to create the policy.

Secret Exfiltration Policy

The Secret Exfiltration Policy protects against unauthorized secret access in GitHub Actions. It blocks modified workflows in non-default branches from using secrets unless explicitly approved.

Why It Matters

Workflows often need secrets to access protected resources. Attackers may exploit non-default branches to run malicious workflows and exfiltrate secrets. This policy helps stop that by:

• Allowing secret access only if the workflow matches the default branch

• Enforcing approval for legitimate changes

• Creating an auditable approval trail

How It Works

• Detects non-default branch workflows accessing secrets (${{ secrets.X }}, toJSON(secrets))

• Compares workflow content to the default branch using SHA256

• Requires a workflows-approved label from a different team member for approval

• Blocks runs without proper matching or approval

What Developers See

If a modified workflow accesses secrets:

• The run is canceled, and a PR comment explains the block and how to get approval (a teammate has to add the "workflows-approved" label to the PR)

• Once the "workflows-approved" label has been added by a teammate, the workflow can be re-run

To create a Secrets Exfiltration policy, follow the steps below:

Step 1: Select “Secret Exfiltration Policy”

Step 2: Choose Target Repositories

Step 3: Save the Policy

Allowed Actions Policy

Use this policy to enforce an allowlist of GitHub Actions. Any action not listed is blocked (Enforce) or flagged (Dry Run).

To create a Allowed Actions policy, follow the steps below:

Step 1: Select “Allowed Actions Policy”

Step 2: Add Actions to Allowlist

• Manually type and add actions (e.g., actions/checkout) OR

• Use All Actions (Used) to select from known usage

• Select one Action and click "Add to Allowed List"

• Decide whether to allow all versions (default) or select specific commit versions OR

• Use Repository Filter (Optional): Go to By Repository (Used) tab → Select a repo → Add used actions

Step 3: Click "Save"

Runner Label Policy

Use this policy to block untrusted GitHub-hosted runners or allow only specific self-hosted runners.

To create a Runner Label policy, follow the steps below:

Step 1: Fill in Policy Details

• Policy Name – e.g., Do not allow GitHub-Hosted Runners

• Policy Type – Select Runner Label Policy

• Action – Choose between:

  • Enforce: Actively blocks disallowed runner labels

  • Dry Run: Sends notifications but does not block

Step 2: Specify Disallowed Runner Labels

• Type in the runner labels you want to block (e.g., ubuntu-latest, macos-latest) and press Enter to add.

Step 3: Select Repositories

Choose whether to apply the policy to:

• All current and future repositories (default), or

• Select specific repositories manually

Step 4: Save the Policy

• After configuring all settings, click Save to create the policy.

When a configured policy is not followed, the associated GitHub Actions workflow run will be blocked automatically. This helps enforce organization-wide security and compliance standards.

In such a case, you will see the following message within the workflow run:

The run was canceled by @stepsecurity-app[bot].

Viewing Blocked Runs in the Dashboard

To investigate blocked runs, go to the “Policy Evaluations” dashboard under Run Policies in the StepSecurity platform.

This dashboard provides:

• A list of recent policy evaluation events across your organization.

• Information about the repository, workflow file, and timestamp of each event.

• The status of the run (e.g., Blocked).

• A direct link to the workflow run for deeper inspection.

Understanding Why a Run Was Blocked

Click the arrow next to any listed evaluation to expand detailed information about:

• The specific policy or policies that were violated (e.g., Do not allow GitHub-Hosted Runners).

• The reason the run was blocked, based on the conditions defined in the policy (e.g., the job was configured to run on ubuntu-latest, which violates the organization’s policy against using GitHub-hosted runners)