Claim your names where registries let you, route internal names only to your own registry, and watch for lookalikes. Specifically: register your npm scope, request a NuGet ID prefix reservation, verify your Maven groupId, and configure every client so private names never fall back to a public source.
Step 1: inventory the names you own
List every package name your company publishes or uses internally, per ecosystem. Include names that exist only in private feeds, since those are the ones attackers can guess from a leaked manifest or error message.
Step 2: claim what you can
- npm: create an organization for your scope. npm's documentation says a scope is a namespace tied to an account or organization.
- NuGet: apply for ID prefix reservation. The criteria say the prefix should clearly identify the owner and avoid common words, and short prefixes under four characters are discouraged.
- Maven Central: verify a groupId you control by domain or code hosting account.
- PyPI and crates.io: there is no scope system on the pages we checked, so publish a placeholder only if you genuinely plan to maintain it. npm explicitly treats packages with no genuine function as squatting, so do not become the squatter yourself.
Step 3: route private names privately
Claiming public names is half the job. The other half is stopping your build from asking the public registry for private names at all.
| Ecosystem | Control |
|---|---|
| npm | Map your scope to your private registry in .npmrc |
| NuGet | Package source mapping, so each ID pattern has one allowed source |
| Python | Use one index that proxies and controls both private and public names |
| Maven | Send all requests through one repository manager |
See the dedicated posts on npm scope mapping and NuGet source mapping.
Step 4: watch for lookalikes
Search each registry on a schedule for names close to yours: swapped letters, added words such as "official" or "internal", different separators. Record what you find and report anything malicious. See how to report a malicious package.
Step 5: write it down
Put the list in a short internal standard: who owns each name, where it is registered, and which clients are configured to resolve it. New projects then start from the standard.
Quick check
Should I register every possible variation of my name?
No. You cannot cover them all, and registries frown on holding names with no function. Focus on the exact names you use and rely on client configuration for the rest.
How do I know if an internal name is exposed?
Check whether that name is already registered on public registries, and check your build logs and public repositories for manifests that mention it.
A dependency inventory helps with step 1. Safeguard does SBOM and dependency scanning, and there is a free scan to start.
Sources
- npm scopes
- npm disputes policy
- NuGet ID prefix reservation
- NuGet package source mapping
- Maven Central coordinates requirements
Last reviewed: 19 October 2026.
