As software development progresses along the software supply chain lifecycle, the package stage emerges as a pivotal juncture, converting source code into executable artifacts prepared for distribution. This critical stage, however, is not immune to vulnerabilities, making it a prime target for malicious actors seeking to undermine software integrity and security. This blog post delves into the prevalent threats that can arise during this phase and outlines effective strategies to mitigate them. This content serves as a continuation of our blog series exploring software supply chain security across the SDLC.
Table of Contents
The Package Stage in the Software Development Life Cycle
The package stage of the software supply chain lifecycle encompasses the process of packaging and preparing software for distribution to users. This stage involves creating installation packages, managing dependencies, and generating metadata for the software.
Build integrity threats are vulnerabilities that could allow attackers to introduce unauthorized changes to the software during the packaging process. These threats can be introduced through various methods, such as compromising the package registry, exploiting vulnerabilities in packaging tools, or manipulating third-party dependencies.
The total dependency on open-source components in modern software made this stage the most frequent SSCA target. Introducing stealth malware in a popular open-source component is a dream for many cybercriminals. This is why more than 245,000 malicious packages were found during 2023.
Examples of Software Supply Chain Security Threats in the Package Stage
Use compromised package
This refers to the act of deploying or using a software package that has been tampered with or modified by an adversary.
This can happen after the package has left the official package registry, either through direct access to the user’s system or through social engineering tactics that trick the user into downloading or installing a malicious package. An example of this vector was the Browserify typosquatting Attack.
An attacker, seeking to compromise Linux and Mac systems, infiltrated the development process of a popular Node.js library called Browserify. The attacker slipped malicious code into the project’s source code, intending to distribute it through the NPM package registry. Once the tainted Browserify package was uploaded to NPM, unsuspecting developers would download and install it, believing it to be the legitimate version. The malicious code, embedded within the package, would run silently, compromising the integrity of the systems it infected. This could lead to data theft, system instability, or even remote access for the attacker.
Compromise package registry
A compromised package registry is a software repository that has been infiltrated by an adversary who has gained unauthorized access to the registry’s administrative interface or infrastructure.
This allows the adversary to modify or replace legitimate software packages with malicious ones, which can then be distributed to unsuspectingly installed users. An example of this type of threat was the Attack on Package Mirrors: A researcher, with the intent of promoting open-source software, compromised several popular package registries, including Maven Central, NPM, and RubyGems. By gaining access to these registries, the researcher was able to create mirrors, and replicas of the original repositories, which provided a convenient alternative for developers to download packages.
However, these mirrors harbored a sinister purpose. The compromised mirrors served as conduits for the researcher to distribute malicious packages. These packages replaced legitimate ones, undetected by the primary registries, and unsuspecting developers unknowingly downloaded and installed them. Once installed, these malicious packages unleashed their payload, executing arbitrary code, stealing sensitive data, or disrupting operations.
Upload Modified Package
An adversary uploads a modified package to a repository or distribution channel that contains malicious code or payloads. This can be done by modifying the package’s source code, packaging, or metadata.
One of the most notorious of this type of threat was the CodeCov Attack in 2021. An attacker, seeking to compromise software projects using CodeCov, a popular continuous integration and continuous delivery (CI/CD) tool, utilized leaked credentials to gain unauthorized access to a project’s Google Cloud Storage (GCS) bucket. Once the attacker gained access to the GCS bucket, they uploaded a malicious artifact, a modified version of the CodeCov package, which was then distributed to users through the CodeCov service. Unsuspecting developers, relying on the automatic updates feature, would download and install the malicious package, believing it to be the legitimate one. Once installed, the malicious code would run silently, compromising the integrity of the systems it infected. This could lead to data theft, system instability, or even remote access for the attacker.
Attacks on the package registries are so common that some attack patterns received a name:
In Typosquatting, the bad actor uploads to the registry multiple malicious packages with slight typo errors or similar names to legit, popular ones, with the hope that developers will misspell the intended package name with a malicious one. Often the malicious package masquerades as the legit one to pass undetected, augmenting the probability of being hit with stargazing.
Dependency Confusion leverages the way some package managers resolve the requested packages from multiple registries. When an organization uses internal components published in an internal registry, an attacker who knows the fact may publish a malicious component with the same name in a public registry. If the name used for the internal component is not scoped, some package managers will fetch the malicious component instead of the internal one.
With Troyan Packages, the cybercriminal disguises malware among useful valid code. This could be used by the real author, or by a contributor that offers himself to maintain the package. This is also known as Package Hijacking. Attackers used many techniques to hijack an existing package, like Domain Takeover where an abandoned expired domain was taken by the attacker that re-created the old maintainer email and performed password recovery to take over the maintainer account.
Final Remarks
As organizations increasingly adopt software development methodologies that prioritize automation and continuous delivery, the significance of securing the software package stage has never been more paramount. By implementing robust security measures throughout this critical phase, organizations can substantially mitigate the risk of succumbing to malicious attacks that can compromise the integrity and security of their software.
The strategies delineated in this blog post, along with the examples provided, serve as a stark reminder that the package stage represents a vulnerable point within the software supply chain. Organizations must heed these threats and implement the necessary security measures to safeguard their software from attack. By doing so, they can guarantee the integrity, security, and dependability of their software for their users and customers.
Join Our Journey Toward a Secure Software Ecosystem
Don’t miss the chance to stay one step ahead in the realm of software supply chain security. Subscribe to our blog today and be among the first to receive our latest insights, ensuring that your organization remains resilient and secure amidst evolving threats. Together, we can construct a more robust and secure software ecosystem for everyone.
Remember, software supply chain security is an ongoing journey, not a destination. By continuously evaluating and adapting security practices to address emerging threats, organizations can safeguard their software supply chain and deliver trusted software to their users.
Watch our Video Demo
