# Overview
{% hint style="warning" %}
Available for **Enterprise** Tier users only
{% endhint %}
After you install the [StepSecurity Actions Security GitHub App](https://github.com/apps/stepsecurity-actions-security) 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:
{% hint style="info" %}
**Newly added repositories may take up to 1 hour to appear on the dashboard**
{% endhint %}
## All Controls
| Control | Description | Remediation |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
| [Network and runtime security monitoring should be enabled for GitHub-hosted runners](#network-and-runtime-security-monitoring-should-be-enabled-for-github-hosted-runners) | This check ensures that [Harden-Runner](/github-actions/harden-runner.md) is in your workflow to protect GitHub-hosted runners from unauthorized access, exfiltration, and tampering | [Secure Repo](/github/orchestrate-security/secure-repo.md) / [Secure Workflow](/github/orchestrate-security/secure-workflow.md) |
| [Network and runtime security should be enabled for self-hosted runners](#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](/github-actions/harden-runner.md) on [self-hosted](/administration/settings/harden-runner-installation.md) runners |
| [Prevent execution of untrusted code from context variables (Script Injection Vulnerability) ](#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 | Enable [GitHub Checks](/github/github-checks/configuration.md#script-injection) and apply workflow-level fixes |
| [Prevent execution of untrusted code from forks (Pwn Request Vulnerability)](#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 | Enable [GitHub Checks](/github/github-checks/configuration.md#pwn-request) and apply workflow-level fixes |
| [Actions should be pinned to a full-length commit SHA](#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](/github/orchestrate-security/secure-repo.md) / [Secure Workflow](/github/orchestrate-security/secure-workflow.md) |
| [Compromised npm packages found in PR](#compromised-npm-packages-found-in-pr) | This check ensures PRs do not introduce confirmed compromised npm packages into the repository | Update or remove compromised packages and rotate secrets if exposed |
| [GITHUB\_TOKEN should have minimum permissions](#github_token-should-have-minimum-permissions) | This check ensures workflows use least privilege token permissions, minimizing excessive access risks | [Secure Repo](/github/orchestrate-security/secure-repo.md) / [Secure Workflow](/github/orchestrate-security/secure-workflow.md) |
| [Third-party GitHub Actions with high scores should be used](#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](/github-actions/actions/stepsecurity-maintained-actions.md) |
| [OIDC should be used when deploying to the cloud](#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](#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](#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 build artifacts](#secrets-should-not-be-logged-in-build-artifacts) | This check ensures no secrets are present in build artifacts uploaded by workflows | Mask or redact secrets from build artifacts before upload |
| [Secrets should not be logged in the build log](#secrets-should-not-be-logged-in-the-build-log) | 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:
1. Open the control detail page from the All Controls table.
2. Locate the finding in the **Findings** tab.
3. 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.
{% hint style="info" %}
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.
{% endhint %}
### Network and runtime security monitoring should be enabled for GitHub-hosted runners
This check ensures that the [step-security/harden-runner](https://github.com/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](/github/orchestrate-security/secure-workflow.md) or [Secure Repo](/github/orchestrate-security/secure-repo.md)
### 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](/administration/settings/harden-runner-installation.md)
### 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](/github/github-checks/configuration.md#script-injection), 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:
```yaml
name: Fix For Script Injection
on:
pull_request:
jobs:
vulnerability-fix:
runs-on: ubuntu-latest
steps:
- name: Echo Pull Request Title
env:
PR_TITLE: ${{ github.event.pull_request.title }}
run: |
echo "Pull Request Title: $PR_TITLE"
```
### 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](/github/github-checks/configuration.md#pwn-request), 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_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:
```yaml
- 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.
### 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](/github/orchestrate-security/secure-workflow.md) or [Secure Repo](/github/orchestrate-security/secure-repo.md)
### 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.
### 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](/github/orchestrate-security/secure-workflow.md) or [Secure Repo](/github/orchestrate-security/secure-repo.md)
### 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](/github-actions/actions/stepsecurity-maintained-actions.md) instead of third-party Actions with a low score.
* If there are no StepSecurity Maintained Actions, then you can [request a maintained Action](/github-actions/actions/github-actions-in-use.md#requesting-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.
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.stepsecurity.io/workspace/overview.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.