A new whitepaper from Microsoft highlights the risks of software supply chain attacks for organisations that pull package dependencies from public repositories like npm, RubyGems and PIP.

A dependency confusion attack or supply chain substitution attack occurs when a software installer script is tricked into pulling a malicious code file from a public repository instead of the intended file of the same name from an internal repository.

In essence the attack succeeds because many package installers will, when faced with two different versions of the same file, pick the one with the highest version number.  If an attacker can discern the name of an internal script file, they can publish a malicious substitute with a higher version number in the public code repository and then the installer will select the malicious version instead.

As explained by a recent blog post by a security researcher, the names of internal packages can often be found referenced in public code repositories (such as GitHub), in package.json files or other source code files.  The researcher details how he successfully exploited this vector to infiltrate code and secure large bug bounties from Apple, Shopify, Microsoft and PayPal among others.

Microsoft’s whitepaper details three ways to mitigate the risk of a substitution attack:

1. Only use a single private package feed – pull any dependent public packages into your private repository so you can be sure of control. However, this does then mean you need to manually update the public package versions as needed.
2. Control the scope – if your package manager supports scope control (like npm does) you can prevent internal packages from being retrieved from a public repository.
3. Client side verification – integrity verification, when enabled in the package manager, will abort the build if an unexpected change is detected in a dependent file.

For organisations that develop their own software, dependency confusion or substitution attacks exploit public and open-source repositories to inject malicious code into your software builds.  A careful review of software build practices, the choice of package manager and the use of curated feeds (such as Azure Artifacts) can help mitigate the risks.