StepSecurity
ResourcesCompanyPricingInstall StepSecurity AppLogin
  • Introduction
  • Getting Started
    • Quickstart (Community Tier)
      • Getting Started with Secure Workflow
      • Getting Started with Secure Repo
      • Getting Started with Harden Runner
    • Quickstart (Enterprise Tier)
  • Guides
    • How to enable network and runtime monitoring (Harden-Runner) for runners
    • How to restrict network connections to explicitly allowed endpoints
    • How do I authenticate with the StepSecurity app
    • How should I improve the security of third-party actions in my organization
    • How should I reduce the number of Harden-Runner anomalous endpoint alerts
    • How can developers see and fix StepSecurity findings without security’s help?
  • Overview
  • Harden-Runner
    • Workflow Runs
    • All Destinations
    • Detections
    • GitHub Checks
    • Suppression Rules
    • Policy Store
    • Self-Hosted Runners
    • Runbooks
      • Anomalous Outbound Network Calls
      • How to Determine Minimum Token Permissions
  • Orchestrate Security
    • Policy Driven PRs
    • Secure Workflow
    • Secure Repo
    • Pull Requests
  • Run Policies
    • Policies
    • Policy Evaluations
  • Artifact Monitor
  • Actions Secret
  • Actions
    • GitHub Actions In Use
    • Reusable Workflows
    • GitHub Actions Score
    • StepSecurity Maintained Actions
  • Settings
    • Notifications
    • Self-Hosted Runners
    • API Key
    • GitHub Checks
    • Control Evaluation
  • Admin Console
    • Resources
    • S3 Integration
    • Members
    • Security & Auth
      • Setting Up Google SSO
      • Setting Up Okta SSO
      • Setting Up Microsoft Entra (Azure AD)
    • Audit Logs
  • Partnerships
    • RunsOn
  • Who's Using Harden-Runner?
  • Enterprise Readiness
Powered by GitBook
On this page
  • Creating a New Policy in Your Organization
  • Compromised Actions Policy
  • Secret Exfiltration Policy
  • Allowed Actions Policy
  • Runner Label Policy

Was this helpful?

Export as PDF
  1. Run Policies

Policies

PreviousRun PoliciesNextPolicy Evaluations

Last updated 14 days ago

Was this helpful?

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

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.

- Block the use of compromised Actions

- Prevents unauthorized access to Secrets

- Block specific GitHub Actions

- Prevent or monitor usage of specific runners

Click the save button
Setting up Secret Exfiltration Policy
Setting up Secret Exfiltration Policy
Setting Up Allowed Actions Policy
Setting Up Allowed Actions Policy
Setting up Actions Policy using existing Action in the organization
Setting up Actions Policy using existing Action in the organization
Setting up Actions Policy using existing Action in the organization
Setting up Actions Policy by Repository using Actions
Setting up Actions Policy by Repository using Actions
Selecting Runner Label Policy Type
Specify runner labels to disable
Select Repositories
Click the save button
Compromised Actions Policy
Secret Exfiltration Policy
Allowed Actions Policy
Runner Label Policy
Existing workflow run policies displayed in the dashboard
Workflow Run Policies dashboard
Click the create button
Setting up Compromised Actions Policy
Setting Up Compromised Actions Policy
Setting Up Secret Exfiltration Policy