The recent incident with the event-stream JavaScript library has several people questioning the security of using open-source components. By falling under (legitimate) control of a developer with malicious intents, the library was compromised and, among other things, resulted in a hack against the Copay crypto wallet.

Code reuse has become the status quo in development. Studies regarding programming language adoption found that the most important selection factor is the existence of open source libraries.

But let's look back at how we reached this stage: JavaScript itself evolved in this direction. With the emergence of Node.js, we got modules (based on the CommonJS spec.). Other module formats became popular as well, and then we got code bundlers as a way to execute this code on the client-side. As the front-end evolved, we started to entrust the use of Web Components — such as React.js.

Every single step has led to increasing the development speed, as it's now easier than ever to reuse code — our code and everyone else's code.

But everyone else's code often has the same privileges as all the remaining code that was written by us. For years, we know that the best practice on the client-side is to execute untrusted code in its own sandboxed iFrame, in a different origin. But, for one reason or the other, very few people do that. It's all usually mixed together. Security is an afterthought.

When a module has an issue, it gets ugly. It usually has total permissions to modify everything. This is where the major problems start.

Up until now, one of the few strategies we had to correct this was to use Open Source Auditing (OSA) tools that check if there are known vulnerabilities in the modules you're using. This enables you to stop using them or update to a newer, more secure version. But, as stories like the event-stream one come to show, this is not enough.

Enterprises need to strengthen their own security systems to properly deal with compromised JavaScript libraries and modules. Sure, assessing vulnerabilities must become a good practice — but the stakes are too high to rely on a single line of defense. As anyone working in security knows, it’s always best to bet in security in depth.

This is one of the main reasons why I advocate the usage of our Application Real-time Monitoring approach. In an attack scenario, timing is key and tracking the client-side for malicious injections serves as a major line of defense that enables companies to detect and react to threats in real-time.

As I said before, code reuse is and will remain a standard practice in development. At times like this, questioning the use of open source components brings little value to the discussion. Instead, we should advocate the importance of security in-depth and prevent needlessly sacrificing agility for the cost of security.