Package registry allowlist (private mirror)
Demonstrate that all package dependency resolution is enforced through an approved private registry or mirror, and that direct access to public package repositories is technically blocked or logged as violations.
Description
What this control does
Package registry allowlist (private mirror) restricts software package downloads to an organization-controlled registry or mirror that proxies and caches approved packages from public sources such as npm, PyPI, Maven Central, or NuGet. Developers and build pipelines are configured to resolve dependencies exclusively through the private mirror, preventing direct access to public repositories. This control enables vetting, vulnerability scanning, and provenance verification of third-party packages before they enter the software supply chain.
Control objective
What auditing this proves
Demonstrate that all package dependency resolution is enforced through an approved private registry or mirror, and that direct access to public package repositories is technically blocked or logged as violations.
Associated risks
Risks this control addresses
- Introduction of malicious packages through typosquatting or compromised upstream repositories into production code
- Supply chain attacks via dependency confusion where attackers publish malicious packages with internal names to public registries
- Download of packages containing known vulnerabilities that have not been scanned or assessed
- Lack of audit trail for which external packages and versions were consumed by internal projects
- Unavailability of critical dependencies if public registries experience outages or are unreachable
- Data exfiltration through malicious post-install scripts in unvetted packages
- License compliance violations from use of packages with incompatible or restricted licenses
Testing procedure
How an auditor verifies this control
- Obtain the inventory of all package managers in use (npm, pip, Maven, NuGet, etc.) and their configured registry endpoints from DevOps or platform engineering teams
- Review configuration files for each package manager (e.g., .npmrc, pip.conf, settings.xml, nuget.config) across representative developer workstations, CI/CD agents, and container base images to verify registry URLs point exclusively to the private mirror
- Inspect network security controls (firewall rules, egress filtering, DNS policies) to confirm that outbound connections to public package registries are blocked or require exception approval
- Examine the private registry's configuration to verify it proxies and caches packages from approved upstream sources and enforces authentication for package publishing
- Review logs from the private registry for a sample period to identify package download activity, version resolution, and any recorded attempts to bypass the mirror
- Select a random sample of five recent software builds and trace their dependency resolution logs to confirm all packages were retrieved from the private mirror
- Test enforcement by attempting to install a package directly from a public registry (e.g., npm install from registry.npmjs.org) from a developer workstation or CI/CD pipeline to verify the request is blocked or redirected
- Review the private registry's scanning and approval workflow to confirm that new packages are subject to vulnerability scanning and policy checks before being made available to internal consumers
Where this control is tested