The Rise And Risk Of Third Party Code

The applications that make up the vast majority of today’s hyper-complex tech stacks are heavily dependent on third-party code. Unfortunately, the same vast benefits these pre-crafted components provide are often undermined by the severe security implications of third-party architecture. It’s critical for modern businesses to not only recognize these risks but actively help to stem the flow of attacks. Cutting-edge tools, including a next-gen WAF solution, may be the only path for third parties’ continued existence.

1. Third-Party Code: Because Why Reinvent The Wheel?

Third-party code describes any lines of a program that can be replicated throughout different applications. This aids in the app development process itself, as time to market, is drastically reduced via code recycling. But even after the foundation of an app is laid, third-party code can be leveraged by its developers for ad tracking, customer reviews, payments, chatbots, tag management, social media integration, or other helper libraries that simplify common functions.

The sheer usefulness and availability of third-party code have seen it seep into every corner of the internet: nowadays, third-party code accounts for up to 70% of every website. In the same survey, 99% of respondents stated that the sites used and produced by their organization contain at least one third-party piece of code.

Open source describes one type of third-party code, though third-party also refers to externally developed code, the license to use which may have been purchased. Regardless of the commercial price of this code, companies have for too long ignored the social and security cost.

2. The Lurking Danger of Shadow Code

Third-party code lends itself to uber-accessible site and app development. Though these no- or low-code environments help lower the barrier of entry for eager entrepreneurs and hobbyists, it’s vital to understand the risks. Profiteering cybercriminals are more than willing to take advantage of naive or negligent developers. Sometimes, it’s not a lack of skill that lets them in, but the high-pressure push toward rapid rollout.

Attackers grouped under the Magecart umbrella have been taking advantage of third-party code since 2015. This crime syndicate relies on digital credit card theft, swiped by covertly injecting JavaScript code on e-commerce checkout pages. Magecart has wreaked an impressively high-stakes trail of destruction: Ticketmaster, British Airways and countless other online brands have all fallen foul of their attacks.

Two high-profile attacks occurred in 2020, as children’s clothes maker Hanna Andersson and British retailer Sweaty Betty were targeted. Both of these attackers are thought to have revolved around apparently-innocuous site addons. Hidden within these lines of code, however, Magecart attackers add a few key lines of JavaScript.

This third-party code often copies legitimate payment forms on an eCommerce site. However, there are crucial – tiny – modifications made. For instance, the payment information is covertly sent to an attacker-controlled server. The transaction itself is still allowed to go through, meaning that end-users are left totally in the dark. The attack on Hanna Andersson went totally unnoticed for weeks – even this represents a relatively fast discovery, with other victims remaining clueless for up to a year.

Most victims are only alerted when stolen credit card info pops up on dark web marketplaces. The cost is significant: Hanna Andersson was ordered to pay $400K in damages to over 200,000 customers; the exact cost to individual victims is more difficult to ascertain, but the theft of their name, shipping address, billing address, and payment card info allows attackers to conduct incredible damage. Magecart attacks actually rose in popularity throughout the Covid-19 pandemic, seeing a 20% increase, while the average detection time hit 22 days.

Magecart may represent malicious third-party code; but even tested, open-source code can accidentally cause one of the greatest security problems of this decade. Log4j describes an open-source logging library that has become one of the most important pieces of architecture throughout the web, responsible for relaying vital logging info back to the developer and maintenance team. In 2021, however, it was discovered that the log4j library was critically vulnerable to remote code execution. This placed hundreds of millions of devices at severe risk, as the flaw was also relatively simple to exploit.

Forgoing third-party code altogether isn’t realistic. Over 60% of websites across the world run on Apache and Nginx servers, while 90% of IT leaders rely on enterprise open-source code regularly. All modern software is built from pre-existing components, and rebuilding these functions from scratch would require massive investments in time and money to produce even relatively simple applications.

3. You Can’t Patch Your Way Out of This One

Once bundled into an application, third-party code can be difficult to test, and even harder to secure. Patches are wholly dependent on the developers; even for active, well-meaning devs, such as those maintaining the log4j functionality, patching takes critical time.

Fear not: a comprehensive security solution can offer a number of tools to virtually patch – and ultimately stop attackers in their tracks. One such tool is the Web Application Firewall (WAF). This sits in between the application and the end-user, monitoring and filtering passing traffic. Next-gen WAFs offer automatic policy creation, along with rapid rule propagation, explicitly to broaden the safety net that third-party code requires.

While the traditional WAF has focused primarily on monitoring external connections, Web Application and API Protection (WAAP) describes a more comprehensive suite of protection. This incorporates the firewall-based approach of the WAF, with a greater focus on APIs. These pieces of code provide programmatic access across different apps and have historically been a major weak point in organizational defenses.

Finally, Runtime Application Self-Protection (RASP) offers a compelling next step toward automated protection. Instead of sitting externally to the app’s own code, RASP acts as a plugin, attaching to an application’s internals. Thanks to its internal view of an app, RASP can monitor its behaviors and map the typical connections and privileges that occur under the hood. Once a baseline behavior is established, RASP can then automatically detect – and critically, shut down – suspicious behavior.

With a proactive suite of virtual patching measures in place, your security is empowered to keep pace with DevOps, whilst helping nullify the threat of cybercriminals and the ensuing lawsuits.