Ever since the Web development ecosystem evolved to the current paradigm of code reuse, companies have placed themselves too close to the abyss. Web supply chain attacks are a real security threat – and one which the enterprise is vastly unprepared for.
The security threats of relying on third-party code are mostly known within the scope of Magecart attacks – which consist of attackers injecting malicious code in third-party scripts to skim credit card details of E-Commerce shoppers. While Magecart is still a growing threat and deserves consideration on its own, too little attention is paid to a very different type of third-party code: npm packages.
Too many dependencies, too large an attack surface
NPM itself tells us that the average web app today contains over 1,000 code dependencies, with some breaching the 2,000 mark. Security-wise, each of these pieces of third-party code can actually serve as an attack vector to inject malicious code into applications. A recent study by Markus Zimmermann et al. provided much-needed insight into just how serious a security threat this practice of reusing code poses to the industry as a whole.
To frame why these threats actually exist in the first place, this team of researchers pinpoints some characteristics of the npm ecosystem, one of which is the abnormally large incidence of code reuse when compared to other ecosystems – which I mentioned above. Apart from this, two other characteristics play an important role: the accented use of micropackages and the lack of privilege separation.
The reliance on micropackages is especially relevant because, while they comprise 47% of all packages, they simply contain a few lines of code – usually because they either perform trivial tasks or are used to call other dependencies. However small and innocuous micropackages may appear, individually they carry the same security threat as more complex packages because their dependency chains are just as long.
And when this same team of researchers further analyzed the actual maintainers of these packages, the overall finding was concerning indeed: 20 maintainer accounts can reach more than half of the ecosystem. A breach in one of these can essentially trigger a global supply chain attack.
Despite the current troubles, NPM’s team has been actively developing solutions that might help alleviate this problem. Recently, the company announced a Security Insights API that is meant to provide application developers with data they can use to assess if an npm package had been changed maliciously. It allows the developer, for instance, to check if an update was published with 2FA enabled, or if it was published using the TOR network. Using this information, the developer can potentially – and more importantly, automatically – reject an update and fail the build. It’s still probably too soon to understand how far this new API will take us.
All of these considerations wouldn’t show much cause for concern if this ecosystem was only used by non-commercial projects, or even small companies – what magnifies their importance is that every single Fortune 500 company relies on the npm ecosystem. Enterprises whose apps often amass millions of users and handle sensitive data, such as credit card details or protected health information – paydirt gold for attackers.
We have seen enough examples of web supply chain attacks to know that there still isn’t enough being done to actually mitigate these attacks. Mainstream security measures are still falling short. And the key to a suitable response may come from a change of mindset.
A new security mindset: Shift from prevention to monitoring
There’s no doubt that the npm ecosystem still has a long road ahead, security-wise. The study by Zimmermann et al. urges NPM to responsibly audit packages, to make sure that their source is trustworthy whilst vetting dev accounts. Some progress has been made in this direction recently, namely with the addition of npm-audit to automatically warn developers of known vulnerabilities in each package.
However, when critical enterprise applications could be at stake, and when millions of users could have sensitive data (such as financial or health details) stolen through client-side attacks, enterprises can’t afford to wait nor to trust. And yet, third-party code is here to stay. Solving this conundrum requires a change of mindset – there’s no infallible way of making sure that these third-parties aren’t injecting malicious code. The most reasonable fallback therefore, is to gain complete visibility of client-side threats.