The Ticking Time Bomb in Every Company's Code

Working in application security sometimes feels like walking a fine line between "business as usual" and "doomsday is coming." This balance becomes increasingly harder at times like these, when digital acceleration is happening in every sector, outpacing the security controls put in place.

Much of the disruption that kindled this acceleration happened in the Web development and security space. Twenty years ago, the "typical" website was a static page for informational purposes. Today, it's a dynamic Web app that handles extremely sensitive data and performs critical operations.

Sensitive data continuously passing through almost every website gives attackers a golden opportunity to steal and sell this private information. Unfortunately, such attacks have become wildly successful — and the growth of exposed records keeps climbing. Recent data indicates that the number of exposed records in first quarter of 2020 was 273% higher than in the same quarter of 2019.

By now, those working in application security know that traditional security systems (server-side and network security such as Web application firewalls) can't prevent data-exfiltration attacks targeting websites. Attackers are taking advantage of a blind spot in client-side security, injecting malicious code into companies' websites without ever having to breach their first-party servers. And this brings us to the "ticking time bomb": the Web supply chain.

Benefits and Risks in Code Dependencies
The typical JavaScript development process often relies on open-source components that speed development. This means companies end up using hundreds of pieces of externally sourced code (also known as modules or code dependencies) on their websites. This scenario provides little to no feasible control for companies, and most end up trusting that the modules they use are reliable and secure. Not only that, but these modules may also rely on third-party code, which creates an even more complex chain of code dependencies.

The more dependencies used, the bigger the attack surface and the greater the likelihood that an attacker could gain control of one of the dependencies and inject malicious code into the Web page.

If this concept of Web supply chain attacks seems to resemble the SolarWinds incident, that's because SolarWinds is a perfect example of how a supply chain attack can reach incredible proportions. So, it only makes sense to wonder whether the Web supply chain will be next.

Recently attackers planted a remote code execution backdoor in the official PHP Git repository. The malicious code was caught in a post-commit code review, so it never made its way into an official package release. However, it highlights another security weakness in the Web supply chain — if the malicious code were better hidden, could it have made its way into publicly available package releases? This has happened before, for instance in the Copay incident, where the malicious code affected several versions of the product (a cryptocurrency wallet) and stole users' data.

We saw another glimpse of how bad things can go when security researcher Alex Birsan successfully breached 35 tech firms, including Microsoft, Apple, and PayPal, by taking advantage of a design flaw known as dependency confusion. While this was all done for ethical security research purposes, attackers quickly replicated this strategy to try to catch other companies off guard.

These examples are just the very tip of the iceberg. The Web supply chain runs very deep and wide, with the average Web app containing over 1,000 pieces of externally sourced code. And with recent research showing that installing just one of these packages means implicitly trusting 79 third-party packages and 39 maintainers (on average), we can only guess at the size of a modern Web app's attack surface.

Disarm Potential Danger
So, with so many moving pieces and growing consensus that the Web supply chain is a disaster waiting to happen, what can be done?

The answer seems to be adopting a defense-in-depth approach, going beyond server-side and network security controls and implementing better vendor management along with a layered client-side defense. Implementing new protocols for vetting and managing third-party vendors is increasingly important, although it can be difficult to vet hundreds of third-party packages. Plus, vetting gives a picture at a given moment in time and doesn't identify legit scripts that suddenly become infected. As such, it's important to add a layer of security that can detect and control suspicious code behaviors on the client side at runtime. Gaining control at this level can make the difference between taking months to detect a data breach that originated from within the Web supply chain or detecting and mitigating it in real time.

These are some of the steps organizations can take to reduce their overall exposure to the Web supply chain and avoid being caught if this bomb goes off. Let's just hope that, unlike in action movies, they don't wait until the very last second to disarm it.