Topics In Demand
Notification
New

No notification found.

Malicious Packages Are a Rising Threat in Software Supply Chain Attacks
Malicious Packages Are a Rising Threat in Software Supply Chain Attacks

332

0

In this post, let's discuss what a software supply chain attack is and how it can negatively impact your business. We’ll define, deconstruct, and offer suggestions on how you can protect your business from one of the leading sources of software supply chain attacks - the infamous malicious package.

What’s a software supply chain attack, and what are the inherent security risks?

In a software supply chain attack, an adversary slips an intentional vulnerability, malicious code, or an entire malicious component into a trusted piece of software or hardware supplied and consumed in a hardware or software supply chain.

Modern software development involves integrating third-party software into enterprise applications. According to the 2021 Veracode State of Software Security report, 97% of a typical application written in Java is made up of open-source libraries. This statistic suggests that only 3% of Java’s code is original, showing just the depth and breadth of today’s third-party libraries and open-source code.

This practice essentially builds a chain of trust between the parties in the software supply chain. But, in reality, this practice also requires risk because third-party software packages and open-source packages potentially contain vulnerabilities or malicious code delivered through the software supply chain, affecting all the applications that consume the vulnerable or malicious packages.

Which type of threats exists in the software supply chain?

There are three software supply chain security threats.

 

  • The first two threats show software vulnerabilities, intentional or unintentional. Those vulnerabilities usually refer to software bugs, where each bug is typically assigned a Common Vulnerabilities and Exposures (CVE) identifier when it’s disclosed and published.

 

  • The third software supply chain threat is the malicious component or software package. Unlike vulnerabilities that require exploitation, this threat includes actual malicious code that performs unwanted actions and malicious activity when used. A CVE is usually not assigned when the danger is disclosed for this type of threat. The entire package or specific versions of the package are removed from the package repository, for example, PyPi or NPM, after being reported as malicious. The lack of an identification mechanism for malicious package names and versions makes it very hard for developers and security stakeholders to track. We’ll discuss solutions to overcome this challenge in the following posts in this blog series.

Attackers can utilize the threats to perform actual attacks. The unintentional vulnerabilities of third-party code could also be considered a supply chain attack. Still, the conservative term of software supply chain attack usually refers to intentional sabotage of a supply chain by slipping a malicious code or planting an intentional vulnerability, as seen in the two examples above. So usually, while unintentional vulnerability is considered a threat to the software supply chain security, it’s out of scope when discussing attacking a supply chain.

Why would an attacker go for the software supply chain?

There are two reasons an attacker would go for the software supply chain:

  1. The essence of this hacker methodology is to attack everything and nothing at the same time. A hacker can strike all software that depends on a malicious package and all the end consumers of those applications that use this specific infected dependency in a few keystrokes. It’s a quick way to infect a broad surface.

 

  1. Requires small effort on the part of the hacker to cause maximum damage as compared to the classic targeted attacks that we’ve seen in the last 20 and 30 years when attackers focused on exploiting vulnerabilities.

An attacker would need high technical skills for a targeted attack because it essentially involves finding a vulnerability, developing a working exploit, or paying for one.

Look at the pricing table below from Zerodium; an exploit acquisition platform.

This shows that a remote code execution exploit can cost up to $1 million for a single exploit, with a zero-click RCE exploit for Windows being the most expensive. This also demonstrates the complexity and high bounty/rewards when exploiting vulnerabilities.

When comparing this effort to attacking a malicious open-source software package, the options are endless, as hundreds of thousands of packages are out there. Hence, the attacker simply has to find a single package to attack or publish a single malicious software package and abuse the trust between parties in the supply chain, making this attack method effective. In the next blog posts, we’ll see why and how easy it is to attack with malicious open-source packages.

Popular packages like faker & colours of NPM can be game over for a large consumer community who happen to be part of the supply chain of this package.

As you prepare your security strategy for 2023, it would be good to ask yourself, “How am I defending against software supply chain attacks and malicious packages?” because some packages can target the users of large enterprise solutions and be the demise of your organization. 

Want to learn more? Register for an upcoming JFrog webinar.


About The Author 

Kavita Viswanath is associated with JFrog as Vice President & General Manager. She is an industry veteran with a profound understanding of market dynamics, customer expectations, the technology landscape, and their co-relations. Her impeccable oversight across technology and e-commerce sectors helped global organizations realize their true strength in the highly competitive Indian market.


That the contents of third-party articles/blogs published here on the website, and the interpretation of all information in the article/blogs such as data, maps, numbers, opinions etc. displayed in the article/blogs and views or the opinions expressed within the content are solely of the author's; and do not reflect the opinions and beliefs of NASSCOM or its affiliates in any manner. NASSCOM does not take any liability w.r.t. content in any manner and will not be liable in any manner whatsoever for any kind of liability arising out of any act, error or omission. The contents of third-party article/blogs published, are provided solely as convenience; and the presence of these articles/blogs should not, under any circumstances, be considered as an endorsement of the contents by NASSCOM in any manner; and if you chose to access these articles/blogs , you do so at your own risk.


JFrog is on a mission to power all the world’s software updates, driven by a “Liquid Software” vision to allow the seamless, secure, fearless flow of binaries from developers to the edge. The JFrog DevOps Platform enables software creators to power their entire software supply chain throughout the full binary lifecycle to build, secure, distribute, and connect any source with any production environment. Millions of users and thousands of customers worldwide and the majority of the Fortune 100 depend on JFrog solutions to securely embrace digital transformation.

© Copyright nasscom. All Rights Reserved.