A company uses an internal-only library named acme-utils, kept in its internal package repository (private registry). An attacker registered a package with the same name, acme-utils, and a higher version number in a public package repository, and it turned out that, depending on the build settings, the internal build environment could pull in the attacker's package. Which of the following is the most appropriate countermeasure to this "dependency confusion"?

Answer: B. Put internal-only packages in a namespace managed by the organization, configure that namespace to be fetched only from the internal repository, and pin versions and hash values with a lock file

Dependency confusion is a kind of software supply chain attack. Some package managers consult several repositories and, depending on their settings, choose the higher version number when the same name exists, and attackers abuse this to get a malicious package with the same name as an internal one pulled in. The countermeasure is to use a namespace (scope) managed by the organization for internal packages, tie that namespace only to the internal repository and state explicitly which repository each package is fetched from. In addition, pinning the versions and hash values of dependencies with a lock file prevents them from being silently replaced by something else. Registering the organization's namespace in the public repository first also helps prevent impersonation.

• A. Small version numbers actually make it more likely that the attacker's package with a large version number is chosen.
• B. Correct. Fixing the source and pinning versions and hash values prevent substitution.
• C. Anyone can register in a public repository, so without specifying the source, a malicious package may be pulled in.