Policies

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

Creating a New Policy in Your Organization

There are five 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

• Harden-Runner Policy - Require the Harden-Runner action in every workflow run

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: Does not block the workflow run but records the violation in the Evaluations page

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 5: 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

Creating a Secret Exfiltration Policy

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

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 on the allowlist is blocked (Enforce) or flagged (Dry Run). You can also require that every allowed action be pinned to a specific commit SHA, which protects against tag-overwrite and supply-chain attacks.

Why It Matters

Every third-party GitHub Action that runs in your workflow inherits access to your repository's GITHUB_TOKEN and any secrets the job exposes. An unvetted, typosquatted, or compromised action can:

• Exfiltrate secrets, tokens, or source code

• Inject malicious code into build artifacts

• Pivot into internal systems via repository-scoped credentials

• Execute arbitrary commands with the permissions of the workflow

Maintaining an allowlist narrows your exposure to the set of actions your security team has reviewed. Requiring pinned references on top of that protects you from a second category of attack: a previously-trusted action whose @v4 tag or @main branch is moved to point at malicious code — the pattern behind the tj-actions/changed-files compromise and similar incidents.

Creating an Allowed Actions Policy

Step 1: Select “Allowed Actions Policy”

Step 2: (Optional) Require pinned actions

Toggle Only allow pinned actions on if you want to block any action reference that is not pinned to a commit SHA. This applies on top of the allowlist — an action must be both allowlisted and pinned to pass.

Step 3: 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"

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 4: 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.

Why It Matters

The runs-on value determines what machine a job actually executes on, and different runner labels have very different security and cost profiles.

The Runner Label Policy lets you enforce that jobs only execute on approved runner labels. This is useful when you want to block specific runner types, for example, preventing the use of GitHub-hosted runners because your organization standardizes on self-hosted runners for security or compliance reasons.

Creating a Runner Label Policy

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: Does not block the workflow run but records the violation in the Evaluations page

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:

Harden-Runner Policy

The Harden-Runner Policy ensures that every workflow run in your organization executes in a hardened environment. It blocks jobs where the Harden-Runner action is missing, or where it is present but is not configured as the first step of the job.

Why It Matters

Harden-Runner provides runtime security for GitHub-hosted runners — network egress filtering, file integrity monitoring, process monitoring, and outbound call auditing. These protections only take effect if the action is initialized before any other step runs. A job that runs actions/checkout or installs dependencies before Harden-Runner has already given any malicious code an unmonitored window to execute.

This policy reduces risk by:

• Guaranteeing that Harden-Runner is adopted consistently across all covered repositories

• Preventing developers from accidentally (or intentionally) removing Harden-Runner from a workflow

• Ensuring Harden-Runner is always the first step, so no code executes before monitoring is active

• Supporting organization-specific bootstrap actions as valid Harden-Runner equivalents

Creating a Harden-Runner Policy

Step 1: Fill in Policy Details

• Policy Name — e.g., Require Harden-Runner

• Policy Type — select Harden-Runner Policy

• Action — choose between:

  • Enforce: actively blocks jobs that are missing Harden-Runner or have it configured incorrectly

  • Dry Run: does not block the workflow run but records the violation on the Evaluations page

Step 2: (Optional) Scope the policy with Target runner labels

By default the policy applies to all jobs across the selected repositories, including self-hosted runners that may not have the Harden-Runner action available.

To restrict the policy to specific runner types, toggle Target runner labels on and add one or more labels (for example, ubuntu-latest, ubuntu-22.04). The policy will then only evaluate jobs whose runs-on value matches one of these labels.

Use this when you have a mix of GitHub-hosted and self-hosted runners and only want to enforce Harden-Runner on GitHub-hosted ones.

Step 3: (Optional) Add Custom Actions

If your organization wraps Harden-Runner inside an internal bootstrap action, add those actions under Custom Actions so they are recognized as valid Harden-Runner equivalents.

• Type the action's owner/repo (for example, my-org/bootstrap-security) and press Enter to add it.

• Version tags are ignored — matching is done on the action name only.

Step 4: Select Repositories/Organizations

Choose whether to apply the policy to:

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

• Specific repositories/organizations selected manually

Step 5: Save the Policy

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