It is a little known fact, however, that the current npm installer – when installing a package globally ( npm run with -g or –global) – does not honor the package-lock.json file and will happily download the latest available version of any package dependency, according to the dependencies specified in the package.json file. We highly recommend using package-lock.json and specifying exact dependency versions whenever possible. The common method for enforcing the use of specific versions of the npm dependencies in a project is using package-lock.json file, which specifies the allowed versions of the libraries. To illustrate the risk that may be introduced in modern development methodologies, let’s examine the process of installing npm packages and see how this can lead to applications inadvertently pulling malicious packages from the npm registry. The potential risk in npm package installation This incident shows us how trust, built and established for years, can be broken one day and as such even new versions of a robust package cannot be trusted. The trust in the code obtained from public repositories is deeply rooted in many package managers, but this trust might be misplaced. The deeply troubling fact is that in many circumstances, new code may be pulled from a repository, used in a project and executed on the machine, in a way that is almost invisible to the developer. Just as easily, the developer could have introduced malicious code, which would be executed on hundreds of thousands of machines which were known to download the faulty version of the package.

While the introduced fault was cosmetic in nature, and the inflicted damage is in principle limited to the urgent need to fix numerous tools which became inoperable, this scenario demonstrates a deeper and more concerning problem. The developer, Marak Squires, introduced changes which rendered these packages useless, and caused hanging of applications using one of those packages. In a more recent development, the highly popular colors and faker npm packages were purposefully corrupted by their maintainer.

The question of who really controls this code, and is responsible for detecting and fixing software supply chain security issues, became a significant source of concern after the discovery of the Log4Shell vulnerability. Modern software projects are mostly composed of open source code.

Npm update specific package