We will walk you through the risks of code dependencies in web supply chain attacks.
As demand for faster product development grows, developers increasingly rely on code snippets from external sources, especially JavaScript libraries and frameworks. This results in an average web application with more than 1,000 modules, also known as code dependencies.
What does increased use of third-party code mean for security?
JavaScript: the first language of the web
We have seen the technologies used for creating web products develop rapidly, and JavaScript has become the predominant language of the Web.
JavaScript powers 97% of modern websites, and every Fortune 500 company uses it. They rely specifically on npm. It is a JavaScript package ecosystem built globally by millions of developers.
What was the main driver for JavaScript’s success?
The JavaScript open-source community really started to thrive after Node.js was released in 2009. This started the trend of creating reusable code pieces, usually called modules or packages, that different projects could share.
As this ecosystem grew, we saw fully functional front-end frameworks and libraries like React and Angular emerge. This has sped up development not only for Web apps but also for mobile and desktop apps, with frameworks like React Native, Ionic, and NativeScript.
Companies could not afford to miss the opportunity to cut product development time by relying on peer-reviewed third-party modules. As community-built modules became more specific and met more needs, it became less necessary to develop every piece of code in-house.
Third-party code became standard in web development, and the average website now has more than 1000 code dependencies.
Code Dependencies Expose You To Web Supply Chain Attacks
Despite its benefits for product development, third-party code raises security concerns.
A 2019 study by researchers from the Technical University of Darmstadt found that each code dependency that companies use contains, on average, 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.
The overall finding was concerning.
If attackers compromise 20 high-profile developer accounts, they breach half the ecosystem. In other words, a global web supply chain attack could attack hundreds of thousands of private and public organizations worldwide.
By relying so heavily on third-party code, companies have little control or visibility into the code they use and how it behaves. This low-visibility scenario is ideal for attackers, especially through web supply chain attacks.
In a web supply chain attack, attackers target the supply chain of websites and all of their third and fourth parties. This approach enables easier, more scalable attacks. For instance, if an attacker modifies a weaker third-party provider, they can inject arbitrary code into the website and do what they want.
There’s no privilege separation in JavaScript development, which makes it particularly dangerous to have arbitrary code running on your website. This means all third-party code has the same privileges as internally developed code, so it can do anything on your website.
They can add additional code to the web page, hidden in plain sight, for example, to display a fake popup for phishing purposes or to redirect the user to websites containing malware. With that, attackers can leak any data they collect and send it to a drop server they control.
Imagine the consequences of giving attackers easy access to your users’ credentials or PII. With strict regulations like GDPR and CCPA, this clearly violates users’ privacy rights.
When you add that supply chain attacks often go unnoticed for weeks or even months, as we saw with the Magecart web-skimming attack on British Airways in 2018, companies face devastating consequences.
Safely Integrating Third-Party Code
The bottom line is that third-party code isn’t going away, as it remains one of the most valuable assets for competitive product development. But the key to mitigating the risks of externally sourced code is learning to integrate it safely.
This requires development and security teams to reduce code dependencies when possible and implement webpage monitoring to gain visibility into and control over the behavior of all client-side code.
This level of visibility is essential for companies to regain control of their web supply chain. To achieve the desired level of security, they need to do this continuously at runtime.
Take the first step to achieving full website visibility and control. Get started with Jscrambler’s Webpage Integrity solution. This will allow you to get valuable insights into what scripts are running on your website and what suspicious connections they are making.
