NuGet Lack of Version Pinning

Under certain circumstances (in application dependency descriptors) the versions should be pinned to avoid misbehaviour or injection of malicious dependencies (direct or indirect).

For example, under NuGet, a publishable package.lock.json makes dependencies pinned and avoids future injections, but existing vulnerabilities for the pinned versions should be handled.

This detector checks if the pinning file exists and is added to control version.

If the project has not version pinning file package.lock.json.

Attackers can create new public components with higher versions and the NuGet installer could use the new version.

If the attacker gains access to publish new versions of Nice.Package, he can create a new version "4.99.99" with malware, and NuGet will happily resolve this new version with malicious code.

Create a lock file to fix the versions of dependencies and sub-dependencies.

To configure NuGet to persist the full closure of package dependencies, the RestorePackagesWithLockFile property in the project manifest could be set, so NuGet restore will generate a lock file (packages.lock.json).

Read the Locking dependencies section in the NuGet documentation for full details.

Of course, reviewing dependencies is always recommended. But at least an attack based on introducing malware on new versions of existing packages will not affect you immediately.

Malware packages are detected by the community or by Xygeni Malware Early Warning, and known vulnerabilities are also detected and patched regularly. You have to trade off the rate of version updates for getting security and quality patches but without opening the door to supply-chain attacks.

Version pinning helps with reproducible builds, and forces version upgrades not to be fully automatic.