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:
Newly added repositories may take up to 1 hour to appear on the dashboard
All Controls
This check ensures that Harden-Runner is in your workflow to protect GitHub-hosted runners from unauthorized access, exfiltration, and tampering
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
This check prevents untrusted input from executing as code, reducing script injection risks in workflows
Enable GitHub Checks and apply workflow-level fixes
This check ensures workflows triggered by unsafe events (e.g., pull_request_target) don’t run untrusted code from forks without safeguards
Enable GitHub Checks and apply workflow-level fixes
This check ensures GitHub Actions use full commit SHAs instead of branches or tags.
This check ensures PRs do not introduce confirmed compromised npm packages into the repository
Update or remove compromised packages and rotate secrets if exposed
Default branch should be protected
This check ensures the repository's default branch has branch protection rules enabled, including required pull request reviews, blocked force pushes, and admin enforcement
Enable branch protection on the default branch in GitHub
This check ensures workflows use least privilege token permissions, minimizing excessive access risks
This check ensures each GitHub Action used in the job has a security score of 6 or above to minimize security risks
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
This check ensures publishing secrets are stored as environment secrets for controlled access
Move publishing credentials to environment secrets
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
This check ensures no secrets are present in build artifacts uploaded by workflows
Mask or redact secrets from build artifacts before upload
This check ensures no secrets are present in the build log
Mask sensitive outputs
StepSecurity provides these controls as specific checks on your GitHub organization workflows, ensuring compliance with industry-standard security practices.
Managing Findings
Each control surfaces findings across your repositories and workflows. From the control detail page, you can review findings, track remediation progress, and suppress findings that don't apply to your environment.
The detail page for each control organizes findings into four tabs:
Findings — Active findings that require attention.
In Progress — Findings with remediation work underway (for example, an automated pull request that has been opened but not yet merged).
Fixes — Findings that have been resolved.
Suppressed — Findings you've chosen to exclude from active tracking.
Suppressing findings
Suppression is useful when a finding is a known false positive, an accepted risk, or otherwise not applicable to your environment. To suppress a finding:
Open the control detail page from the All Controls table.
Locate the finding in the Findings tab.
Click the action menu on the finding row and select the suppress option.
Suppressed findings move to the Suppressed tab and no longer count against the control's compliance status. You can unsuppress a finding at any time to return it to active tracking.
Suppressing a finding does not fix the underlying issue — it only excludes the finding from active tracking. Use suppression deliberately and document the reason where possible.
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-Runner helps 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
Enable continuous scanning with GitHub Checks
The most reliable way to catch script injection vulnerabilities is to enable GitHub Checks, which scans your workflow files for script injection patterns on every pull request. The check flags overly permissive triggers and unsanitized external inputs as a failing or blocking check, so issues are surfaced before they're merged.
In addition to enabling GitHub Checks, apply these workflow-level fixes:
Avoid inline scripts
Wherever possible, use tried and tested GitHub Actions instead of inline scripts. Please note that a GitHub Action itself can be vulnerable to script injection attacks, so you must review the Action before using it.
Intermediate Environment Variable
If you must use inline scripts, consider using intermediate environment variables to access user controller attributes. Here is an example:
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
Enable continuous scanning with GitHub Checks
The most reliable way to catch pwn request vulnerabilities is to enable GitHub Checks, which inspects your workflow files for insecure configurations such as pull_request_target triggers that can be exploited by malicious forked PRs. The check flags these risks on every pull request before they can be merged.
In addition to enabling GitHub Checks, apply one or more of these workflow-level fixes:
Use a safer trigger: Prefer
pull_requestoverpull_request_targetwhere 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:
Limit workflow permissions to minimize access to secrets and other sensitive data.
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
Compromised npm packages found in PR
This check ensures that pull requests (PRs) do not introduce known compromised npm packages into the codebase.
Why This Matters
Introducing compromised npm packages into a repository can result in severe security issues, including:
Unauthorized code execution during CI/CD runs,
Exfiltration of secrets via malicious package behavior,
Complete takeover of repository environments, especially if secrets or deployment keys are exposed during the workflow.
How to Fix it
Update the compromised package(s) to a safe version, preferably the latest secure release.
Replace or remove the package if it is no longer actively maintained or cannot be safely updated.
Rotate your secrets if a known-compromised package was already used in prior workflow runs.
Default branch should be protected
This check ensures the repository's default branch has branch protection rules enabled, including required pull request reviews, blocked force pushes, and admin enforcement.
Why This Matters
Branch protection prevents unauthorized or unreviewed changes from landing on the branch that ships. Without it, anyone with write access can push directly to the default branch, force-push over history, or merge code without review. Each of these gaps gives an attacker or a compromised contributor a straight path to inject malicious or unsafe code into production.
Required pull request reviews ensure at least one other person sees every change. Blocking force pushes preserves the audit trail and prevents history rewrites that hide malicious commits. Admin enforcement closes the most common escape hatch, which is admins bypassing the rules they set for everyone else.
How to Fix It
Enable branch protection on the default branch in GitHub:
Require at least 1 approving pull request review before merging
Block force pushes
Enforce the rules for administrators (do not allow admins to bypass protections)
You can configure these settings under Settings > Branches > Branch protection rules in each repository, or apply them at scale using GitHub rulesets at the organization level.
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
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 build artifacts
This check ensures no secrets are present in build artifacts produced by workflows, preventing accidental exposure through downloadable outputs.
Why This Matters
If secrets are written into build artifacts — such as compiled binaries, logs, archives, or test reports — they can be downloaded by anyone with access to the workflow run, including users who would not otherwise have access to repository secrets. Attackers who gain access to artifacts can extract credentials and use them to access repositories, infrastructure, or sensitive data.
How to Fix It
If this check fails, take one of the following actions:
Review the artifact contents and remove any files containing secrets before uploading.
Mask or redact sensitive values from files that must be included in artifacts.
Avoid writing secrets to disk during workflow execution — use environment variables and ensure they are not persisted to artifact paths.
Use OpenID Connect (OIDC) for authentication where possible to reduce reliance on long-term secrets.
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.
Last updated
Was this helpful?