Overview
Last updated
Was this helpful?
Last updated
Was this helpful?
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:
This check ensures that the necessary monitoring measures are in place to protect self-hosted runners against unauthorized access and tampering
This check prevents untrusted input from executing as code, reducing script injection risks in workflows
Proper input validation and sanitization
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
This check ensures workflows use least privilege token permissions, minimizing excessive access risks
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
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
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 the build log
Mask sensitive outputs
This check ensures GitHub Actions use full commit SHAs instead of branches or tags.
StepSecurity provides these controls as specific checks on your GitHub organization workflows, ensuring compliance with industry-standard security practices.
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.
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.
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
This check ensures that the necessary monitoring measures are in place to protect self-hosted runners against unauthorized access and tampering
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.
Deploy Harden-Runner on self-hosted runners by following the instructions in the Self-Hosted Runner Settings
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.
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.
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:
instead of:
Validate and sanitize user-controlled inputs before using them in workflows.
Restrict workflow permissions to limit exposure in case of an injection attack.
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.
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.
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:
Limit workflow permissions to minimize access to secrets and other sensitive data.
This check ensures that GitHub workflows use the least required token permissions at the job or workflow level, reducing the risk of excessive access.
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.
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
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.
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.
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.
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.
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.
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
This check ensures each GitHub Action used in the job has a security score of 6 or above to minimize security risks.
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.
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
This check ensures deployment GitHub Actions that support OpenID Connect (OIDC) are configured to use OIDC authentication instead of long-term secrets.
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.
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.
This check ensures publishing secrets are stored as environment secrets rather than repository or organization secrets, ensuring they are only accessible under controlled conditions.
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.
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.
This check ensures all Organization and Repository secrets have been rotated within the last 180 days to minimize security risks.
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.
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.
This check ensures no secrets are present in the build log, preventing accidental exposure of sensitive credentials.
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.
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.
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.
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.
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
This check ensures that is in your workflow to protect GitHub-hosted runners from unauthorized access, exfiltration, and tampering
/
Deploy on runners
/
Use
/
