# Configuration

GitHub Checks let you enforce StepSecurity security scans as part of your pull request workflow. Each control scans a specific class of supply-chain risk and reports its result back to GitHub as a check that appears alongside your other CI checks.

This page describes the controls available, how to configure them, and how to apply them to your repositories.

Each control is set to either **Required** (blocks merges on failure) or **Optional** (advisory only) when you enable it. See [Types of GitHub Checks](https://docs.stepsecurity.io/github-checks/..#types-of-github-checks) for the distinction between these modes.

<figure><img src="https://754495266-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FQJRZY4cfEeY3I7DXTOCp%2Fuploads%2FWxjYWyQzJaAFabgy9n7p%2FScreenshot%202026-04-25%20at%2000.27.23.png?alt=media&#x26;token=60081da2-955b-4381-935f-345b1735d481" alt=""><figcaption></figcaption></figure>

### **Package Compromised Updates**

Blocks pull requests that introduce or update a dependency known to be compromised.

StepSecurity's SOC continuously monitors the npm and PyPI ecosystems for emerging threats and maintains a real-time database of compromised packages. In many cases this database is updated before an official CVE is published, so teams can block a malicious package faster than traditional vulnerability scanners allow.

If a pull request uses a compromised package, the check fails and prevents the merge, eliminating a major attack vector and helping teams respond to incidents at the speed of the ecosystem.

Available for:

* **npm Package Compromised Updates**: scans npm dependencies
* **PyPI Package Compromised Updates**: scans PyPI dependencies

### **Package Cooldown**

Prevents pull requests from introducing or updating dependencies that were published very recently.

Most supply-chain attacks on public registries are discovered within the first 24 hours of a malicious package being published. A cooldown period gives the ecosystem and StepSecurity's threat intelligence time to catch a malicious release before it reaches your code.

The cooldown window is configurable per control. By default, packages published within the last 2 days fail the check. Once a package version ages beyond the configured cooldown, the check passes automatically, with no manual intervention required.

Available for:

* **npm Package Cooldown**: scans npm dependencies
* **PyPI Package Cooldown**: scans PyPI dependencies

**Configuring the cooldown window.** Click the gear icon next to a Package Cooldown control to open its configuration panel. You can set the cooldown window in days to match your organization's risk tolerance. Use a shorter window for teams that need to adopt new releases quickly, and a longer window for teams that prefer more settling time before accepting new dependency versions.

<figure><img src="https://754495266-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FQJRZY4cfEeY3I7DXTOCp%2Fuploads%2FAUpbat7Z3ufR1gDwo0qF%2FScreenshot%202026-04-25%20at%2000.54.49.png?alt=media&#x26;token=bae1557c-528a-4a0b-b4d0-752e28b4b96c" alt=""><figcaption></figcaption></figure>

### **PWN Request**

Flags GitHub Actions workflows that use patterns vulnerable to a **PWN Request** attack.

PWN Request vulnerabilities occur when a workflow triggered by `pull_request_target` executes untrusted code from a forked pull request with access to the base repository's secrets. Attackers exploit this by submitting a PR that silently modifies a build or test script, which then runs with write access to the repository's secrets and tokens.

This control detects insecure `pull_request_target` patterns and related trigger configurations, surfacing the risk before an attacker can exploit it.

### **Script Injection**

Flags GitHub Actions workflows that use unsanitized external inputs in shell commands.

Script Injection vulnerabilities occur when workflow expressions like `${{ github.event.pull_request.title }}` or `${{ github.event.issue.body }}` are interpolated directly into shell commands. An attacker who controls the PR title or issue body can inject shell code that runs with full access to the workflow's environment, including secrets and the `GITHUB_TOKEN`.

This control scans workflows for these patterns and surfaces warnings so teams can fix them before an attacker uses them to execute code in CI.

## **Apply to Repositories**

Once you've configured controls in the section above, apply them to your repositories in the **Apply to Repositories** section.

You can apply checks to all current and future repositories by selecting the checkbox at the top of the repository list. You can also manage check behavior on a per-repository basis:

* **Required Checks**: enable or disable required-check enforcement for this repository
* **Optional Checks**: enable or disable optional checks for this repository
* **StepSecurity Harden-Runner**: enable or disable the Harden-Runner baseline check for this repository

Per-repository overrides take precedence over the organization-wide setting, so you can enable a check org-wide while exempting specific repositories that need different coverage.


---

# 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/github-checks/configuration.md?ask=<question>
```

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.
