Varun's Blog

Notes and observations

Package managers and security

There is a growing trend of extensions and packages being taken over by advertising companies and crackers. When installing packages with tools such as npm take care that the package you are installing is legit.

Version Pinning and auto updates

It is unsafe to use package managers without explicit version pinning. Eg. v 1.2.3 precisely, not v 1.X.X or even 1.2.X. There have been cases of package dev’s accounts being taken over maliciously by hackers who then release a point version that auto upgrades itself. Auto updates of packages - even inadvertent ones - are a very bad idea. It is important to use npm-shrinkwrap or such to freeze package versions - and it is very important to maintain this carefully.


This is a major problem, and great care must be taken when installing packages. npm install reqiest instead of npm install request can cause a typosquatted package to be installed which appears to work like the actual package but also has malicious code injected into it.

Obfuscated Code

Having obfuscated code in a package is a significant red flag. Obfuscated (or binary) code in a package is reason enough to do without the package. Hidden code is fine in an end user app but it has no place in a dev package. Even if the obfuscated code is currently harmless the package could easily be sold tomorrow to a developer who then proceeds to add malicious code to it - code that is well hidden within the previously obfuscated code. Avoid.

How packages become compromised

Security Updates

If you include a third party package in your application you are responsible for securing it. If the third party package includes more packages of its own, and one of those packages are compromised you are still responsible for the mess that occurrs.

The OWASP lists using packages with known vulnerabilities in the top ten ways applications are vulnerable/become compromised. (

In practise this means keeping an eye out for vulnerable packages and updating them as soon as you are aware. This is not necessarily related to package hijacks although it could be. The package could also have a vulnerability that exposes your application to problems.

The best option is to not use any packages you did not write.

A barebones ExpressJs app created with the Express creation tool has about 50 dependencies (including sub-dependencies). That’s a massive attack surface.

Therefore, if a hacker detects a vulnerability in one package every single webapp on the Internet that uses the package is now compromised. There is no such thing as safety in numbers although visibility will be higher for more popular packages meaning you are likely to be notified of hacks sooner - if those hacks are ever detected in the first place. And remember: “But everyone else was doing it” is never a good defense. Ultimately if your app breaks it is your problem irrespective of the cause.

Checking for vulnerabilities

There is no foolproof way apart from being generally aware.

( audits your node packages for you. ( is an equivalent for Ruby. Ruby generally has better support.

( tracks package library versions.

Local package cache

After pinning specific package versions, it is a good idea to keep a cache of the packages on your server. This is needed for a few reasons:


Using npm, pip, et. al. comes at a significant cost in terms of maintenance and upkeep. Maintainers, developers, and devops need to be constantly on the lookout for phishing and hacking attempts - a lack of discipline will cause problems. This is particularly difficult because things will work smoothly most of the time, and thus issues are likely to be ignored during routine development, maintenance, and testing - because there are no immediate errors/roadblocks. The cost of an error is extremely high (and could potentially be fatal, eg. like Wannacry) but likelihood is small.