> For the complete documentation index, see [llms.txt](https://docs.stepsecurity.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.stepsecurity.io/packages/secure-registry/policy.md).
# Policy
The **Policy** tab is where you configure the security controls that Secure Registry enforces. Every package request that flows through Secure Registry is evaluated against the controls you enable here before a response is returned.
Open the **Policy** tab and use the **Registry** selector to choose an ecosystem (**npm**, **PyPI**, **Maven**, or **NuGet**), then toggle each control on or off. Controls are configured independently per ecosystem, so each ecosystem's policy can differ. Not every control is available for every ecosystem; see Control availability by ecosystem below. Click **Save Changes** to apply.
#### Control availability by ecosystem
Controls are configured independently per ecosystem, and not all controls are available in every ecosystem yet. Controls marked **Coming soon** appear in the Policy tab but cannot be enabled.
| Control | npm | PyPI | Maven | NuGet |
| ---------------------------- | --------- | ----------- | ----------- | ----------- |
| **Cooldown Period** | Available | Available | Available | Available |
| **Compromised Packages** | Available | Available | Available | Available |
| **Custom Block List** | Available | Available | Coming soon | Available |
| **Typosquatting Protection** | Available | Coming soon | Coming soon | Coming soon |
| **Registry Settings** | Available | Not offered | Not offered | Not offered |
Maven and NuGet are in **Beta**, indicated by a badge next to each in the **Registry** selector.
### Cooldown Period
Blocks packages published within a configurable number of days, giving the community and StepSecurity's SOC time to vet new releases before they reach your environment. Set the cooldown window in the **Period (days)** field; the default is 2.
Cooldown is the first line of defense against zero-day supply chain attacks. Most malicious packages are discovered within 24 hours of publication, so a multi-day cooldown shifts the discovery window outside your installation window.
#### **Exempted Packages**
Use the **Exempted Packages** field to allow specific packages or scopes to bypass the cooldown window. Type a pattern and press **Enter** to add it. Patterns are matched as regular expressions, so you can exempt a single version, an entire package, or a whole scope.
| Pattern | What it exempts |
| ------------- | ------------------------------- |
| `react@2.3.4` | A single version of one package |
| `lodash@*` | All versions of one package |
| `@scope/*` | All packages under a scope |
Exempted packages still flow through Secure Registry and are evaluated by every other enabled control (for example, Compromised Packages). Only the cooldown check is skipped.
**Need an urgent version now?** If a version inside the cooldown window must be installed immediately (for example, a critical security patch), add the exact version as an exemption (such as `react@2.3.4`), click **Save Changes**, and retry the install. Prefer an exact-version pattern over a package-wide one: it is self-limiting, since it never covers future versions, and once the version ages beyond the cooldown window it would pass anyway.
Use exemptions sparingly. Each exempted pattern is an explicit opt-out of the zero-day window, so reserve them for packages you have already vetted or that you control internally.
### Compromised Packages
Blocks installs of package versions that StepSecurity's SOC or the broader security community has flagged as compromised or malicious. When this control is on, any request for a flagged version is blocked, and the evaluation is recorded in the [Policy Evaluations](/packages/secure-registry/policy-evaluations.md) log.
This control catches packages whose maintainer account was hijacked, packages that were published with embedded malware, and packages reported as malicious after publication. Unlike Cooldown, which buys time for the community to discover an attack, Compromised Packages enforces against attacks that have already been confirmed.
Compromised Packages is independent of the cooldown window: a flagged version is blocked whether or not it falls inside the cooldown period, and exempting a package from cooldown does **not** exempt it from this control.
### Custom Block List
Blocks specific packages or versions from being served through your registry, regardless of publication date or compromise status. Use it to enforce internal bans: a package your security team has rejected, a version with a known incompatibility, or a dependency you are migrating away from.
Turn the control on, then add one pattern per entry. The block list matches glob patterns, so you can block a single version, a version range, an entire package, or a whole scope.
| Pattern | What it blocks |
| ----------- | ------------------------------- |
| `lodash@4*` | All 4.x versions of one package |
| `lodash@*` | All versions of one package |
| `@scope/*` | All packages under a scope |
{% hint style="warning" %}
The Custom Block List and the Cooldown **Exempted Packages** field use different matching syntaxes. Custom Block List patterns are globs; Exempted Packages patterns are regular expressions. The two are not interchangeable, even though the example patterns look similar.
{% endhint %}
The Custom Block List is evaluated independently of every other control. A package on the block list is blocked even if it is outside the cooldown window, is not flagged as compromised, and passes the typosquatting check.
### Typosquatting Protection
Blocks packages whose names closely resemble popular packages, protecting against typosquatting attacks. When this control is on, a request for a package whose name is a likely typo of a well-known package is blocked, and the evaluation is recorded in the [Policy Evaluations](/packages/secure-registry/policy-evaluations.md) log.
#### Whitelisted Packages
Use the **Whitelisted Packages** field to allow specific packages through the typosquatting check. Type a package name and press **Enter** to add it.
Unlike the Cooldown Exempted Packages field, which matches regular expressions, the whitelist requires **exact package names**. Specify the full name of each package you want to allow (for example, `@scope/package-1` or `lodash`); patterns such as `lodash@*` or `@scope/*` are not supported here.
Whitelist a package when its name legitimately resembles a popular package and the Typosquatting control is flagging it as a false positive. Whitelisting affects only the typosquatting check; the package is still evaluated by every other enabled control.
### Registry Settings
Each ecosystem has a **Registry Settings** panel for behavior that is not a blocking control. Settings are configured per ecosystem, alongside that ecosystem's policy.
**Tarball URL Rewriting (npm)**
Rewrites the tarball URLs in npm metadata responses so that package downloads are routed through Secure Registry instead of the public npm registry.
### Saving changes
Changes to the Policy tab take effect only after you click **Save Changes**. The page records who last saved the policy and when, so you have a basic audit trail of policy changes per ecosystem.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## 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, and the optional `goal` query parameter:
```
GET https://docs.stepsecurity.io/packages/secure-registry/policy.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
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.