Third-party package dependencies · Sources & registries

Reserve internal package names on public registries

When it fails: Internal package names are free to register on public registries.

CB-DEP-SRC-003mediumdraftmanualprofile hardened

Status draft: not part of any release yet, may still change.

Description

The organization owns the namespace, scope or placeholder package names matching its internal packages on each public registry where they could be resolved.

Rationale

A second barrier against dependency confusion, for the day a configuration is wrong or a new project forgets the mapping. It also prevents impersonation of the organization's packages.

Impact

Accounts on public registries must be created and kept secured. Placeholder packages need a clear description so they are not mistaken for real ones.

Audit

  1. For each internal namespace or prefix, check who owns it on each relevant public registry.
  2. Confirm the owning accounts belong to the organization and use multi-factor authentication.

Remediation

  1. Register the namespaces or placeholder names on each relevant public registry.
  2. Protect the accounts with multi-factor authentication and restrict who can publish.

References

Mappings

FrameworkIDRelationNote
NIST SP 800-53 Rev. 55.1.1SR-3related

How this control relates to the other framework's: equivalent, stricter, looser, partial or related.

Threats mitigated

TaxonomyIDNote
MITRE ATT&CKT1195.001
  • related CB-DEP-SRC-002 Bind internal package namespaces to the private registry

People and lifecycle

AuthorsAlice
Introduced inv1.0.0
Created, updated2026-10-16, 2026-10-16