The Rise of Software Supply Chain Attacks: When Trust Becomes a Risk

Co-authored by Meenakshi M Kumar

We Trust Software More Than We Realize

“An ounce of prevention is worth a pound of cure!”

Have you ever installed a software update or added a new library to your project without giving it a second thought? Most of us have. After all, if it comes from a trusted source, it should be safe… right?

Well, not always.

Modern software is rarely built from scratch. Developers rely on open-source libraries, third-party packages, and development tools to save time and focus on building innovative applications. But what if one of those trusted components is compromised? Suddenly, the software you trusted becomes the very thing that puts your application at risk.

Let’s uncover how attackers exploit this trust and explore what we, as developers, can do to stay one step ahead.

When Trust Turns Into a Vulnerability

Studies have shown that the vast majority of modern applications include open-source components. Together, these trusted components form the software supply chain.

Instead of attacking an application directly, attackers compromise one of these components. Since the same library or tool is often used by many applications, a single compromise can affect thousands of users and organizations.

Imagine this: instead of breaking into every house in a neighborhood, an attacker contaminates the water supply. With one point of compromise, they can impact everyone who depends on it.

Two Ways Attackers Sneak In

Instead of attacking applications directly, attackers target the software components developers rely on every day. They either exploit vulnerabilities in trusted dependencies or trick developers into installing malicious packages. Let’s look at these two common attack methods.

Dependency Vulnerabilities

Modern applications depend on third-party libraries and frameworks that help developers build software faster. However, these dependencies may contain security flaws that can go unnoticed for a long time.

Attackers actively monitor publicly disclosed vulnerabilities and exploit applications that continue using outdated or unpatched versions. Since many applications include numerous direct and indirect dependencies, developers may not even realize a vulnerable library is part of their project until it’s too late.

A Real-World Example: Log4Shell (2021)

In December 2021, a critical vulnerability called Log4Shell was discovered in the widely used Apache Log4j logging library. Because Log4j was used in millions of Java applications, the vulnerability quickly became a global cybersecurity concern. It allowed attackers to remotely execute malicious code, forcing organizations worldwide to urgently patch their systems.

The Log4Shell incident showed how a single vulnerable dependency could put countless applications and organizations at risk.

Malicious Packages

Unlike dependency vulnerabilities, malicious packages are intentionally created or modified by attackers. Instead of exploiting an existing weakness, attackers trick developers into installing software that already contains malicious code. Once installed, these packages can steal credentials, access sensitive data, install malware, or create backdoors into an application.

Some of the most common techniques include:

Typosquatting

Attackers publish packages with names that closely resemble popular libraries. A simple typing mistake can cause developers to install the wrong package without realizing it.

Example: A package named crossenv was created to imitate the legitimate Python package cross-env, tricking developers into downloading the malicious version.

Dependency Confusion

Attackers publish a public package using the same name as an organization’s private package. If the build system downloads the public package instead of the internal one, the malicious code becomes part of the application.

Example: In 2021, security researcher Alex Birsan demonstrated this technique by publishing packages that were downloaded by build systems at several large organizations, including Microsoft, PayPal, and Apple.

Compromised Maintainer Accounts

Attackers steal the credentials of trusted package maintainers and use those accounts to publish malicious updates. Since these updates come from a trusted source, developers are much less likely to suspect them.

Although these techniques differ, they all exploit one common factor — trust. Instead of attacking applications directly, attackers target the software developers rely on every day.

When Trust Was Broken:

The SolarWinds Attack — The Attack That Spread Through a Trusted Update (2020)

SolarWinds, a company providing IT management software, unknowingly distributed a software update that had been modified by attackers. Since the update came from a trusted vendor, around 18,000 organisation, including government agencies and Fortune 500 companies, installed it without suspicion. The attackers quietly gained access to sensitive systems, remaining undetected for months before the breach was discovered.

How It Could Have Been Prevented?

• Digitally sign and verify every software update.
• Secure CI/CD pipelines with strong access controls.
• Continuously monitor build servers for unauthorised changes.
• Verify software integrity before deployment.

3CX Desktop App — A Trojan Hidden in Legitimate Software(2023)

The attackers first compromised a third-party supplier used by 3CX. They then inserted malicious code into the official 3CX desktop application. Users downloaded what appeared to be a normal software update, unknowingly installing malware on their systems.

How It Could Have Been Prevented?

• Continuously assess third-party vendor security.
• Use behaviour-based threat detection instead of relying only on signatures.
• Monitor software releases for unexpected changes.
• Implement Zero Trust security practices.

Building Software Without Blind Trust

1. Software Composition Analysis(SCA)

“You can’t protect what you don’t know exists!”

Software Composition Analysis (SCA) automatically scans your project’s dependencies and compares them against vulnerability databases such as the National Vulnerability Database (NVD) and GitHub Security Advisories. If a vulnerable component is found, developers receive an alert before the software reaches production.

How It Works?

1. Scans all direct and transitive dependencies.
2. Checks them against known CVEs.
3. Detects outdated or risky packages.
4. Recommends secure versions or patches.
5. Can block builds containing critical vulnerabilities.

2. Software Bill Of Materials(SBOM)

“If you don’t know what’s inside your software, neither do your defenders!”

An SBOM (Software Bill of Materials) is a complete inventory of every software component, library, dependency, and version used in an application. Just as food labels list ingredients, an SBOM reveals exactly what your software is made of. When a new vulnerability is announced, organizations with an SBOM can quickly determine whether they’re affected, instead of manually inspecting every project.

How It Works?

1. Automatically generates a list of all software components.
2. Records component names, versions, licenses, and suppliers.
3. Updates the inventory with every new release.
4. Maps components to newly discovered vulnerabilities.

3. Secure CI/CD Pipeline & Code Signing

Even if the source code is secure, attackers may target the CI/CD pipeline, the system that builds and releases software. If compromised, malicious code can be inserted into legitimate applications without developers noticing. A secure CI/CD pipeline, combined with code signing, ensures that only verified code is built, released and distributed.

How It Works?

1. Every code change is automatically scanned for vulnerabilities.
2. Only authorized developers can trigger builds.
3. Secrets and credentials are securely managed.
4. The final software is digitally signed using cryptographic certificates.
5. Users and systems verify the signature before installation.

Trust, But Verify

As developers, our responsibility goes beyond writing secure code. Every dependency we install, every package we download, and every software update we apply becomes part of our application’s security. That’s why regularly reviewing dependencies, keeping software up to date, and following secure development practices are more important than ever.

The next time you install a package or click “Update Now,” pause for a moment and ask yourself:

“Do I trust this software… or have I verified that I should?”

Because in today’s interconnected software ecosystem, the safest mindset isn’t “Trust by default.” It’s “Trust, but verify.”

Stay curious. Stay secure. Happy coding!