In dependency confusion, how does an attacker learn your internal package names?

## The attack needs one thing: a name Dependency confusion works because a build can be persuaded to fetch a package from a public source when the maintainers intended an internal one. Everything else in the attack is cheap and public: registering a name on a public package index costs nothing, takes minutes, and requires no relationship with the target. The scarce input is knowing which name to register — and in practice that input is rarely scarce at all. A useful way to hold this: your private index protects *artifacts*. It does not protect *names*. Authentication, network restrictions and access reviews on the index all govern who can download or publish your builds. The attacker never asks your index for anything. ## Where names leak **Public source repositories.** The most common leak is a manifest or lock file in a repository the company itself open-sourced. Lock files are especially generous: they enumerate the whole resolved graph, so internal packages that appear only as transitive dependencies of other internal packages are listed by name and version. Nobody reviews a lock file diff for disclosure. **Shipped client code.** Front-end bundles retain module identifiers, and if source maps are published the original internal package structure is fully readable. Anything you ship to a browser, you have published. **Container images.** A published image contains the installed package metadata for its language runtime. Pulling the image and listing what is installed inside is a normal, unauthenticated operation. **Stack traces and error output.** Consider a service whose private module path appears in a stack trace posted to a public forum, a status page, or an unhandled error rendered to end users. In ecosystems where the module path *is* the import identifier, that trace hands over the exact string a build will later resolve. A fresh checkout on a developer machine that has not been configured for the private path will then resolve that path through a public proxy — to whoever registered it. **CI and build logs.** Logs from a public repository's pipeline, or logs attached to a public bug report, routinely print resolution output naming every package fetched. **Humans.** Conference talks, engineering blog posts, job adverts ("experience with our internal `acme-*` platform libraries") and support tickets all name internal libraries. Post-acquisition, the acquired company's names are frequently already documented publicly before integration even begins. ## Latent versus live exposure It helps to separate two states. A name is **latently exposed** when it is known or guessable but nobody has registered it publicly — the attack is one publish away and you would not notice the transition. A name is **live** when someone else already owns it on a public index. Both matter, but they call for different urgency, and the only way to know which state a given name is in is to check the public index for it. Assuming your names are unregistered because they are unusual is not checking. ## Why obscurity fails as a control Three reasons. First, disclosure is a one-way ratchet: a name printed once in a public trace cannot be un-published, and search engines and archives keep it. Second, the guessing bar is low — organisations use consistent prefixes, so learning one internal name teaches the shape of the rest, and a company's public repositories reveal the naming convention even when no internal manifest is exposed. Third, the party who must keep the secret is everyone who has ever pushed code, pasted a log or shipped a bundle, which is not a population that can hold a secret. An insider makes it trivial: someone with nothing more than read access to the internal index — a contractor, an intern, a departing employee — can list the whole private namespace without doing anything that looks like an attack, then publish externally where the organisation has no control at all. ## What this means in an interview The expected answer is a list of concrete leak surfaces plus the reasoning above them: names are inputs, not secrets, and the attacker never touches your infrastructure to obtain them. A candidate who answers "they would have to breach our network first" has the direction of the attack backwards — the malicious package is published *outward*, to a source your build already trusts enough to consult. Fixing this is therefore not a disclosure exercise; it is a decision about what a build is allowed to resolve, which is a separate topic. What you owe here is the recognition that the name is already out, or one screenshot away from it.