Policies

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

Existing workflow run policies displayed in the dashboard

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 Workflow Run Policies page

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

Step 2: Click “Create Policy”

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

Click the create button

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

Setting up Compromised Actions Policy

Step 4: Select Repositories/Organizations

• Choose whether to apply the policy to:

  • All current and future repositories/organizations (default), or

  • Select specific repositories/organizations manually

Step 6: Save the Policy

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

Click the save button

Follow this interactive demo to see how this workflow run policy works in practice:

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”

• You can exempt specific users or bot accounts from this policy. When a workflow is triggered by an exempted user or bot, the run will not be blocked by the policy.

Step 2: Choose Target Repositories/Organizations

Step 3: Save the Policy

Setting up Secret Exfiltration Policy

Follow this interactive demo to see how this workflow run policy works in practice:

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”

Setting Up Allowed Actions Policy

Step 2: Add Actions to Allowlist

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

Setting Up Allowed Actions Policy

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

Setting up Actions Policy using existing Action in the organization

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

Setting up Actions Policy using existing Action in the organization

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

Setting up Actions Policy using existing Action in the organization

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

Setting up Actions Policy by Repository using Actions

Step 3: Click "Save"

Setting up Actions Policy by Repository using Actions

Follow this interactive demo to see how this workflow run policy works in practice:

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

Selecting Runner Label Policy Type

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.

Specify runner labels to disable

Step 3: Select Repositories/Organizations

Choose whether to apply the policy to:

• All current and future repositories/organizations (default), or

• Select specific repositories/organizations manually

Select Repositories

Step 4: Save the Policy

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

Click the save button

Follow this interactive demo to see how this workflow run policy works in practice: