> 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/developer-machines/packages/package-configs.md).

# Package Configs

The **Package Configs** page provides an audit of package-manager configuration files across every scope on each developer machine. It surfaces three things for each device: which registry packages actually resolve from, whether a cooldown policy is in effect, and what authentication is configured against the registry.

This view answers two operational questions:

* **Are developer machines pointed at the right registry?** Confirm whether machines resolve packages from StepSecurity Secure Registry or an internal artifact manager (for example, JFrog Artifactory or Google Artifact Registry) rather than directly from the public registry.
* **Is a cooldown policy in place?** Identify machines that are not protected by a cooldown window against newly published packages.

### Supported ecosystems and package managers

Package Configs is organized into per-ecosystem tabs:

* **JavaScript**: `npm`, `pnpm`, `bun`, and `yarn`
* **Python**: `pip`

Within the JavaScript tab, use the package-manager chips (`npm`, `pnpm`, `bun`, `yarn`) to switch between managers. Each manager's configuration is audited independently.

The configuration files audited include `.npmrc`, `bunfig.toml`, `.yarnrc` / `.yarnrc.yml`, and `pip.conf`, evaluated across every scope present on the device.

### Configuration table

<figure><img src="/files/o49saC02kZHHZE8Gxy6R" alt=""><figcaption></figcaption></figure>

For the selected ecosystem and package manager, the table lists each device with the following columns:

| Column                 | Description                                                                                                                                                                                                                                                                                                             |
| ---------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Device**             | The device identifier or hostname. Click to open the device's full details.                                                                                                                                                                                                                                             |
| **{Package manager}**  | The installed version of the selected package manager on the device (for example, an `npm` version), or `Not installed` if the manager is not present.                                                                                                                                                                  |
| **Effective registry** | The registry that packages actually resolve from on the device, along with where that value comes from (for example, `from default`, `from global`, or `default (no config)`). A custom value such as an internal mirror indicates the device is configured to use an artifact manager rather than the public registry. |
| **Cooldown**           | Whether a cooldown policy is in effect for the device. Where applicable, an actionable hint is shown (for example, a prompt to upgrade the package manager to a version that supports the relevant control).                                                                                                            |
| **Files**              | The number of relevant configuration files found versus the number expected for that scope (for example, `1/2`), making partial or missing configuration easy to spot.                                                                                                                                                  |
| **Auth**               | The authentication configured against the registry. Indicators summarize the credential surface detected in the configuration files. A dash (`—`) indicates no authentication is configured.                                                                                                                            |

You can sort the table by **Cooldown** and **Files** to surface the devices most in need of attention, and export the current view using **Export CSV**.

### Reading the effective registry

The **Effective registry** column resolves the registry a device will actually use, accounting for the configuration precedence of each package manager (project, user, and global scopes). The label beneath the registry value tells you where the effective value was set:

* `default (no config)`: no configuration file sets a registry, so the package manager's built-in default applies
* `from default`: the value resolves from a default-scope configuration
* `from global`: the value is set in a global-scope configuration

A device showing an internal host (for example, an `npm-mirror` path on an internal Nexus or Artifactory instance) is resolving packages through an artifact manager. A device showing the public registry default is going directly to the public registry and is not behind Secure Registry or an internal proxy.

### Config details

Selecting a device opens a side panel with the full configuration audit for that device and package manager.

<figure><img src="/files/yxnn1FyFzWxxL5AoGkNS" alt=""><figcaption></figcaption></figure>

The panel header shows the device, the ecosystem (for example, `NPM`), when the configuration was collected, and the agent version that reported it.

#### **Effective config**

The **Effective config** block shows what the package manager would actually resolve at runtime, after applying scope precedence:

* **Registry**: the effective registry, with the scope the value comes from (for example, `from global`)
* **Cooldown**: the effective cooldown policy, or an upgrade hint when the installed package manager version does not support cooldown
* **npm version** (or the selected manager's version): the installed version and the path to the executable (for example, `/usr/bin/npm`)
* **Files discovered**: how many of the expected configuration files were found (for example, `2 existing of 2 checked`)

#### **Per-scope breakdown**

The **Per-scope breakdown** shows what each individual configuration scope sets, listed in the package manager's precedence order (later scopes win). Each scope card identifies the scope and the file it came from (for example, `GLOBAL /etc/npmrc`, `USER /home/fedora/.npmrc`) and shows:

* **Registry**: the registry set in that scope, or `not set`
* **Cooldown**: the cooldown value set in that scope (for example, `14 days`), or `not set`
* **Auth entries**: the credentials configured in that scope, shown as `none`, or as indicators such as `hardcoded` (credentials written directly into the file) and `env-ref` (credentials referenced from an environment variable)

The per-scope view makes it clear *which* file is responsible for the device's effective configuration. For example, a registry set at the global scope but absent at the user scope tells you the effective registry is coming from `/etc/npmrc`, not from the developer's home directory.

### Why it matters

Package-manager configuration is where supply chain controls are either enforced or quietly bypassed on a developer machine. A machine that resolves packages directly from the public registry, with no cooldown and no authentication, has none of the protection that Secure Registry or an internal proxy provides, regardless of what is configured centrally. Configuration also drifts: a single `.npmrc` in a project directory can override an organization's intended registry without anyone noticing.

Use this page to:

* **Verify Secure Registry adoption**: confirm developer machines resolve packages through Secure Registry or an approved artifact manager rather than the public registry
* **Find cooldown gaps**: identify devices not protected by a cooldown window against newly published packages
* **Audit the auth surface**: see where registry credentials are configured, and where they are missing or unexpected
* **Catch configuration drift**: spot machines whose effective registry differs from your organization's standard

For background on cooldown windows and how Secure Registry enforces them, see [Secure Registry](/packages/secure-registry.md).


---

# 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:

```
GET https://docs.stepsecurity.io/developer-machines/packages/package-configs.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.