# 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](https://docs.stepsecurity.io/harden-runner) is in your workflow to protect GitHub-hosted runners from unauthorized access, exfiltration, and tampering | [Secure Repo](https://docs.stepsecurity.io/orchestrate-security/secure-repo) / [Secure Workflow](https://docs.stepsecurity.io/orchestrate-security/secure-workflow) | | [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](https://docs.stepsecurity.io/harden-runner) on [self-hosted](https://docs.stepsecurity.io/settings/harden-runner-installation) 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 | Proper input validation and sanitization | | [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 | Limit workflow permissions and use a safer trigger | | [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](https://docs.stepsecurity.io/orchestrate-security/secure-repo) / [Secure Workflow](https://docs.stepsecurity.io/orchestrate-security/secure-workflow) | | [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](https://docs.stepsecurity.io/orchestrate-security/secure-repo) / [Secure Workflow](https://docs.stepsecurity.io/orchestrate-security/secure-workflow) | | [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](https://docs.stepsecurity.io/actions/stepsecurity-maintained-actions) | | [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 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. ### 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](https://docs.stepsecurity.io/orchestrate-security/secure-workflow) or [Secure Repo](https://docs.stepsecurity.io/orchestrate-security/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](https://docs.stepsecurity.io/settings/harden-runner-installation) ### 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 #### 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 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: ```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](https://docs.stepsecurity.io/orchestrate-security/secure-workflow) or [Secure Repo](https://docs.stepsecurity.io/orchestrate-security/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. ### 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](https://docs.stepsecurity.io/orchestrate-security/secure-workflow) or [Secure Repo](https://docs.stepsecurity.io/orchestrate-security/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](https://docs.stepsecurity.io/actions/stepsecurity-maintained-actions) instead of third-party Actions with a low score. * If there are no StepSecurity Maintained Actions, then you can [request a maintained Action](https://docs.stepsecurity.io/actions/github-actions-in-use#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 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/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.