Policy Evaluations

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 Policy Evaluations in the Dashboard

To review how policies evaluated recent workflow runs, go to the "Policy Evaluations" dashboard under Workflow Run Policies in the StepSecurity platform. You can filter evaluations by workflow and by status.

Each evaluation shows one of three statuses:

• Allowed: the run did not violate any applicable policy.
• DryRunBlocked: the run violated a policy in Dry Run mode. The violation was recorded, but the run was not cancelled.
• Blocked: the run violated a policy in Enforce mode and was cancelled.

The dashboard also shows the repository, workflow file, and timestamp of each event, a direct link to the workflow run, and, for runs triggered from pull requests, a link to the related PR.

Understanding Why a Run Was Blocked

Click the arrow next to any listed evaluation to expand a per-policy breakdown. The breakdown lists every policy that applied to the run and the violations each one raised, for example:

• Compromised actions detected (Compromised Actions Policy)
• Disallowed runner labels detected or Runner labels not in allowed list (Runner Label Policy)
• Use of unapproved actions (Allowed Actions Policy)

Policies that passed are listed with a green check, so you can see the full evaluation picture for the run, not just the violation that blocked it.

For Runner Label Policy violations in allow-list mode, the violation details list the exact labels or constraint values that were not on the policy's allowed list.

Compromised Actions List at Run Time

For evaluations that involve a Compromised Actions Policy, the breakdown includes a Compromised actions list at run time link. It opens the compromised actions list exactly as it existed when the run was evaluated. Actions added to the list later are not shown.

This matters because the compromised actions list updates continuously. A run that passed yesterday may reference an action that is on the list today; the point-in-time record lets you confirm what the run was actually checked against.

Run Policy Timing

Each evaluation includes timing metrics so you can verify how quickly enforcement occurred:

• Webhook received: when StepSecurity received the workflow run event from GitHub.
• Cancel started / Cancel finished / Cancel duration: shown for blocked runs, covering the cancellation call itself.
• Webhook to cancel finished: the total time from receiving the event to the run being cancelled.

Enforcement typically completes in under two seconds end to end, cancelling the run before a malicious step can do harm.