Is the Enterprise on the Brink of a Global Web Supply Chain Attack?

Web supply chain attacks are a real security threat for which the enterprise is vastly unprepared.

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 into third-party scripts to skim the credit card details of E-Commerce shoppers.

While Magecart is still a growing threat and deserves consideration, too little attention is paid to a 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 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 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 emphasis on 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.

When we take a deeper look at the JavaScript ecosystem’s dependency chains, we can visualize just how large an attack surface modern JS applications display.

The study by Zimmermann et al. found that, on average, an npm package has 80 dependencies of its own. While simply multiplying this figure by the 1,000 transient dependencies of the average web app is not accurate by itself (different packages often share the same dependencies), we can safely conclude that, just by getting to the second level of the web supply chain, we are already dealing with many thousands of code dependencies.

This brings us to the second and more important characteristic of the NPM ecosystem: the lack of privilege separation. Boiling this down means that all pieces of third-party code have the same privileges as code that is developed internally. Not only does this mean that the security of the average JavaScript application is scattered over thousands of different third parties, but it also means that it only takes a breach in one of them, no matter how small, to potentially launch a web supply chain attack.

When this same team of researchers further analyzed the actual maintainers of these packages, the overall finding was indeed concerning: 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.

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, are paydirt gold for attackers.

We have seen enough examples of web supply chain attacks to know that not enough is being done to 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: shifting 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 ensure their source is trustworthy while vetting development 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 or 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.

By putting in place a web page monitoring solution, enterprises can react in real-time whenever a rogue third party starts injecting malicious code, automatically triggering security measures to stop the attack.

Third-party code is still breaching companies. Malicious code runs undetected for months and results in significant business damage. It’s high time that the enterprise took concrete action toward minimizing this security threat, using packages from the JavaScript npm ecosystem and monitoring the client side for malicious code.

This article was published on HelpNet Security and was edited to contain additional relevant insights from the study.