This article was originally published on Pedro Fortuna's LinkedIn page.
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.
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.
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.
Lastly, if you're interested in knowing more about Web Supply Chain Attacks, be sure to grab a copy of our free white paper.