Overview

Available for Enterprise Tier users only

After you install the StepSecurity Actions Security GitHub App in your GitHub Account and access your dashboard, you should see the Overview dashboard.

On this page, you can see all the controls enabled by StepSecurity:

All Controls

Control	Description	Remediation
Network and runtime security monitoring should be enabled for GitHub-hosted runners	This check ensures that Harden-Runner is in your workflow to protect GitHub-hosted runners from unauthorized access, exfiltration, and tampering	Secure Repo / Secure Workflow
Network and runtime security should be enabled for self-hosted runners	This check ensures that the necessary monitoring measures are in place to protect self-hosted runners against unauthorized access and tampering	Deploy Harden-Runner on self-hosted runners
Prevent execution of untrusted code from context variables (Script Injection Vulnerability)	This check prevents untrusted input from executing as code, reducing script injection risks in workflows	Proper input validation and sanitization
Prevent execution of untrusted code from forks (Pwn Request Vulnerability)	This check ensures workflows triggered by unsafe events (e.g., pull_request_target) don’t run untrusted code from forks without safeguards	Limit workflow permissions and use a safer trigger
GITHUB_TOKEN should have minimum permissions	This check ensures workflows use least privilege token permissions, minimizing excessive access risks	Secure Repo / Secure Workflow
Leaked secrets due to compromise of reviewdog GitHub Actions	This check ensures that workflows do not use the vulnerable reviewdog/actions-setup GitHub Action, which could lead to unauthorized access to secrets and repository compromise.	Replace all instances of reviewdog/actions-setup@vx with step-security/reviewdog-action-setup@v1
Leaked secrets due to compromise of tj-actions/changed-files GitHub Actions	This check ensures that workflows do not use the vulnerable tj-actions/changed-files GitHub Action, which could lead to unauthorized access to secrets and repository compromise.	Replace all instances of tj-actions/changed-files@vx with step-security/changed-files@v45
Third-party GitHub Actions with high scores should be used	This check ensures each GitHub Action used in the job has a security score of 6 or above to minimize security risks	Use StepSecurity Actions
OIDC should be used when deploying to the cloud	This check ensures deployment actions use OIDC authentication instead of long-term secrets	Remove long-term secrets from your repository and migrate to OIDC-based authentication
Publishing secrets should be set as environment secrets	This check ensures publishing secrets are stored as environment secrets for controlled access	Move publishing credentials to environment secrets
Secrets should be rotated periodically	This check ensures all Organization and Repository secrets have been rotated within the last 180 days	Rotate secrets at least every 180 days to maintain security
Secrets should not be logged in the build log	This check ensures no secrets are present in the build log	Mask sensitive outputs
Actions should be pinned to a full-length commit SHA	This check ensures GitHub Actions use full commit SHAs instead of branches or tags.	Secure Repo / Secure Workflow

StepSecurity provides these controls as specific checks on your GitHub organization workflows, ensuring compliance with industry-standard security practices.

Network and runtime security monitoring should be enabled for GitHub-hosted runners

This check ensures that the step-security/harden-runner GitHub Action is included in your workflow for GitHub-hosted runners to prevent unauthorized access, exfiltration, and tampering.

Why This Matters

Without security monitoring, attackers can exploit CI/CD workflows to leak sensitive code or credentials. harden-runnerhelps detect and prevent these threats by monitoring network activity and restricting unexpected behaviors.

How to Fix It

Fix this issue with an automated pull request that adds the step-security/harden-runner GitHub Action to the job using Secure Workflow or Secure Repo

Network and runtime security should be enabled for self-hosted runners

This check ensures that the necessary monitoring measures are in place to protect self-hosted runners against unauthorized access and tampering

Why This Matters

Without security monitoring, attackers can exploit self-hosted runners to exfiltrate code or steal CI/CD credentials. Harden-Runner helps mitigate these risks by monitoring network activity and detecting suspicious file modifications.

How to Fix It

• Deploy Harden-Runner on self-hosted runners by following the instructions in the Self-Hosted Runner Settings

Prevent execution of untrusted code from context variables (Script Injection Vulnerability)

This check ensures context variables in workflows are not used in a way that allows untrusted input to be executed as code, preventing script injection vulnerabilities.

Why This Matters

If workflow context variables (e.g., ${{ github.event.issue.title }}) are not properly handled, attackers can inject malicious scripts into workflows. This can lead to arbitrary command execution, data exfiltration, or unauthorized access to repository secrets.

How to Fix It

If this check fails, take one of the following actions:

• Avoid using context variables in script execution unless properly sanitized.

• Use safe quoting practices when referencing context variables in shell commands.

Example:

run: echo "${{ github.event.issue.title }}"

instead of:

run: echo ${{ github.event.issue.title }}

• Validate and sanitize user-controlled inputs before using them in workflows.

• Restrict workflow permissions to limit exposure in case of an injection attack.

Prevent execution of untrusted code from forks (Pwn Request Vulnerability)

This check ensures that workflows triggered by potentially unsafe events, such as pull_request_target, do not execute untrusted code from forked repositories without proper safeguards.

Why This Matters

Using risky triggers like pull_request_target without explicitly defining a reference (ref) when checking out code can expose secrets and lead to repository compromises. Attackers can manipulate pull requests to run unauthorized code with elevated permissions.

How to Fix It

If this check fails, take one of the following actions:

• Use a safer trigger: Prefer pull_request over pull_request_target where possible.

• Restrict code checkout: If you must use pull_request_target, ensure that the code is only checked out from a trusted branch by specifying an explicit ref:

- name: Checkout trusted code
  uses: actions/checkout@v3
  with:
    ref: 'main' # Specify a safe reference instead of defaulting to PR changes

• Limit workflow permissions to minimize access to secrets and other sensitive data.

GITHUB_TOKEN should have minimum permissions

This check ensures that GitHub workflows use the least required token permissions at the job or workflow level, reducing the risk of excessive access.

Why This Matters

By default, GitHub tokens may have broad permissions, increasing the attack surface. If a workflow grants unnecessary privileges, a compromised workflow run could lead to unauthorized actions, such as modifying repository settings or leaking sensitive data.

How to Fix it

• Set minimum GitHub token permissions at the job or workflow level.

• Fix this issue with an automated pull request that adds the step-security/harden-runner GitHub Action to the job using Secure Workflow or Secure Repo

Leaked secrets due to compromise of reviewdog GitHub Actions

This check ensures that workflows do not use the vulnerable reviewdog/actions-setup GitHub Action, which could lead to unauthorized access to secrets and repository compromise.

Why This Matters

The review dog/actions-setup GitHub Action has a known vulnerability that could be exploited to compromise repository secrets. If an attacker gains control over this action, they could leak credentials, tamper with workflow execution, or escalate privileges within the CI/CD pipeline.

How to Fix It

To resolve this issue, replace all instances of tj-actions/changed-files@vx with a secure alternative:

• Use step-security/reviewdog-action-setup@fab6de28ae8bc2a032c9e655d990afa450edb995 # v1.3.2 or step-security/reviewdog-action-setup@v1.

Leaked secrets due to compromise of tj-actions/changed-files GitHub Actions

This check ensures that workflows do not use the vulnerable tj-actions/changed-files GitHub Action, which could lead to unauthorized access to secrets and repository compromise.

Why This Matters

The tj-actions/changed-files GitHub Action has a known vulnerability that could be exploited to compromise repository secrets. If an attacker gains control over this action, they could leak credentials, tamper with workflow execution, or escalate privileges within the CI/CD pipeline.

How to Fix It

To resolve this issue, replace all instances of tj-actions/changed-files@vx with a secure alternative:

• Use step-security/changed-files@3dbe17c78367e7d60f00d78ae6781a35be47b4a1 # v45.0.1 or step-security/changed-files@v45

Third-party GitHub Actions with high scores should be used

This check ensures each GitHub Action used in the job has a security score of 6 or above to minimize security risks.

Why This Matters

Using third-party GitHub Actions with low-security scores increases the risk of vulnerabilities, including supply chain attacks. Actions with higher security scores are more likely to follow best practices, reducing the chance of exploitation.

How to Fix it

• Use StepSecurity Actions instead of third-party Actions with a low score.

• If there are no StepSecurity Maintained Actions, then you can request a maintained Action

OIDC should be used when deploying to the cloud

This check ensures deployment GitHub Actions that support OpenID Connect (OIDC) are configured to use OIDC authentication instead of long-term secrets.

Why This Matters

Using long-term secrets in workflows increases security risks, as secrets can be leaked, misused, or rotated improperly. OIDC provides a more secure and automated way to authenticate deployments, eliminating the need to store and manage credentials manually.

How to Fix it

• Enable OIDC authentication for your deployment Actions instead of using static secrets.

• Update workflows to use federated credentials, which allow short-lived tokens to be issued dynamically.

• Remove long-term secrets from your repository and migrate to OIDC-based authentication for enhanced security.

Publishing secrets should be set as environment secrets

This check ensures publishing secrets are stored as environment secrets rather than repository or organization secrets, ensuring they are only accessible under controlled conditions.

Why This Matters

Storing publishing secrets as environment secrets restricts their access to workflows running in protected branches or requiring manual approval. This prevents unauthorized use of sensitive credentials, reducing the risk of accidental exposure or misuse.

How to Fix It

• Move publishing credentials to environment secrets instead of using repository or organization secrets.

• Configure deployment protection rules to enforce manual approvals or restrict deployments to protected branches.

Secrets should be rotated periodically

This check ensures all Organization and Repository secrets have been rotated within the last 180 days to minimize security risks.

Why This Matters

Long-lived secrets increase the risk of exposure, as compromised credentials can be misused for extended periods. Regularly rotating secrets reduces the likelihood of unauthorized access and mitigates the impact of leaked credentials.

How to Fix It

If this check fails, take one of the following actions:

• Rotate secrets at least every 180 days to maintain security.

• Use OpenID Connect (OIDC) for authentication instead of long-term secrets to eliminate the need for manual rotation.

• Automate secret management by integrating secret rotation policies into your security workflows.

Secrets should not be logged in the build log

This check ensures no secrets are present in the build log, preventing accidental exposure of sensitive credentials.

Why This Matters

If secrets are logged in plaintext during builds, they can be exposed to unauthorized users, leading to security breaches. Attackers may exploit leaked credentials to gain access to repositories, infrastructure, or sensitive data.

How to Fix It

If this check fails, take one of the following actions:

• Mask sensitive values by using GitHub’s secrets masking feature to prevent them from appearing in logs.

• Avoid echoing secrets in scripts—use environment variables securely instead of printing them.

• Review build logs regularly for unintended secret exposure and take corrective action.

• Use OpenID Connect (OIDC) for authentication where possible to reduce reliance on long-term secrets.

Actions should be pinned to a full-length commit SHA

This check ensures each GitHub Action used in the job is referenced using a full-length commit SHA instead of a branch name or version tag.

Why This Matters

Referencing GitHub Actions by branch name (e.g., main) or version tags (e.g., v1.0.0) introduces security risks. The action’s code could change unexpectedly, potentially introducing vulnerabilities. Pinning actions to a full-length commit SHA ensures that only the expected, reviewed code is executed, reducing the risk of supply chain attacks.

How to Fix it

• Pin Actions to a full-length commit SHA.

• Fix this issue with an automated pull request that adds the step-security/harden-runner GitHub Action to the job using Secure Workflow or Secure Repo