Few threats capture the complexity of today’s digital ecosystem quite like supply chain attacks. These incidents don’t just exploit technical vulnerabilities; they exploit the interconnected nature of modern software development, where every dependency, package, and third-party service can become an unintentional gateway.

In this blog, we’ll examine how supply chain attacks unfold, highlight some of the most significant real-world examples, and share practical steps organizations can take to strengthen their defenses.

What is a supply chain attack?

A supply chain attack is a cyberattack that affects organizations not by targeting them directly, but by compromising the third-party software, code packages, infrastructure, or services they rely on.

Instead of storming the castle gates, attackers sneak in through the trusted vendors already inside your defenses: the open-source libraries, SaaS providers, or infrastructure platforms your organization depends on daily.

In essence, the target is trust itself.

When an attacker compromises a software supplier, an update server, or a code dependency, they can silently distribute malicious code to thousands of downstream customers.

This kind of attack can be far more impactful than a direct breach. It can ripple across entire ecosystems, affecting every organization that uses the infected software, along with their products and end customers.

And because cloud, DevOps automation, and continuous delivery encourage constant integration of third-party code and services, the attack surface grows with every dependency added.

Supply chain attacks are uniquely frustrating: they create security issues not because of your actions, but because of others you’ve trusted, often unknowingly.

The most infamous example: SolarWinds

The SolarWinds Orion compromise remains one of the largest and most devastating supply chain attacks in history. Attackers compromised SolarWinds’ software build process and injected malicious code into legitimate updates, which were then distributed to over 18,000 organizations, including government agencies and Fortune 500 companies.

This wasn’t just a technical feat, it was a strategic manipulation of trust. Organizations installed the update believing it came from a legitimate, signed vendor.

The lesson was clear: a single compromised vendor can undermine thousands of secure environments.

The latest noteworthy examples

NPM (2025)

Open-source package ecosystems like npm illustrate how trust in community tools can itself become an attack vector. When maintainers or packages are compromised, that trust can betray downstream consumers.

  • In the TinyColor / @ctrl/tinycolor” (September 2025) campaign, attackers injected malicious scripts into the popular TinyColor package and dozens of related packages, turning them into a self-propagating worm that harvested developer tokens, cloud credentials, and secrets during installation. 
  • In the Qix npm attack (September 2025), a developer’s npm account was phished and used to publish compromised versions of foundational libraries (e.g. chalk, strip-ansi, debug), betraying the trust multiple consumers placed in those packages. 
  • In the s1ngularity (August 2025) incident, malicious versions of the Nx package (and its plugins) included post-install scripts that scanned affected systems for tokens, SSH keys, API secrets, then exfiltrated them to attacker-controlled GitHub repos, effectively weaponizing trusted build tooling for widespread credential theft. 

Together, these cases underscore that supply chain attacks thrive on the very trust developers place in open-source tools. When that trust is breached, millions of downstream projects become vulnerable without directly being targeted themselves.

XZ Utils (March 2024)

In early 2024, a backdoor was discovered in XZ Utils, a core Linux compression utility used across major distributions. The attacker patiently contributed to the open-source project for over two years, gained maintainer trust, and eventually inserted malicious code into official releases.

This incident highlighted a new reality, attackers are playing the long game. They’re infiltrating open-source projects and waiting for the perfect moment to strike.

Had the XZ backdoor gone unnoticed longer, it could have provided remote access to thousands of Linux systems worldwide, including cloud infrastructure.

TJ actions (March 2025)

On March 14, 2025, attackers compromised the widely used GitHub Action tj-actions/changed-files (integrated in over 23,000 repositories), injecting malicious code and retroactively altering version tags to reference a commit that dumps CI/CD secrets (e.g. from runner memory) into build logs.  Because many workflows automatically trust and execute third-party Actions, this exploit enabled attackers to steal secrets not by attacking individual orgs directly, but by poisoning a tool those orgs already trusted, making it a textbook example of a supply chain attack.

The greatest examples that didn’t happen yet (but will most certainly will)

The same scenario that occurred in NPM can, and likely will, happen in other large distribution platforms, such as PyPI (Python Package Index).

Even more concerning is the next frontier: AI models.

As organizations rapidly adopt open-source models from Hugging Face, Ollama, and similar repositories, few realize how easy it would be to upload a malicious model that includes hidden payloads, from data exfiltration to remote command execution.

Imagine deploying a model to production that quietly sends sensitive embeddings or API keys to an attacker-controlled endpoint.

This isn’t science fiction. It’s the next logical evolution of supply chain attacks.

And the same risks extend to GitHub, a platform that acts as the heartbeat of modern development.

Recently, the Orca Research Pod discovered a vulnerability in GitHub Actions that could allow remote code execution (RCE) in high-profile repositories. While responsibly disclosed, this finding underscores the widespread misconfigurations and automation flaws that make even the world’s most trusted platforms a potential attack vector.

These are not isolated issues; they’re signals of a broader trend. As the software ecosystem grows more interconnected, the blast radius of trust expands exponentially.

What can you do to reduce the risk?

1. Apply the principle of least privilege (PoLP)

Limit every identity, human and machine, to the minimum necessary access. CI/CD pipelines, build systems, and deployment bots should never hold long-lived credentials or permissions that exceed their function. Even if an upstream dependency is compromised, a strong least-privilege model breaks the potential attack path before it spreads deeper into your environment.

2. Strengthen your build and integration security

To fortify your development pipeline:

  • Verify the integrity and signatures of all third-party code and containers. 
  • Use software composition analysis (SCA) to track dependencies and detect malicious or outdated components. 
  • Isolate build environments and scan CI/CD runners for privilege escalation or persistence mechanisms.

3. Continuously monitor for anomalies

Supply chain compromises often manifest through subtle deviations: unusual API calls, outbound connections from build servers, or unexpected dependency updates.

Cloud-native monitoring and threat detection tools, such as Orca’s agentless side scanning, can provide visibility across workloads, APIs, and configurations without slowing down development.

4. Adopt a Zero-Trust approach

Treat every external dependency, plugin, or AI model as potentially hostile until verified. Validation should extend beyond source code to include metadata, maintainers, and build provenance.

A cybersecurity Awareness Month call to action

This Cybersecurity Awareness Month, let your message to engineering, DevOps, research, and executive teams be loud and consistent:

“Trust nothing upstream, verify everything.”

Supply chain attacks don’t just challenge your perimeter; they challenge your trust assumptions. As defenders in the cloud era, your strategy must evolve from “protect us” to “validate everything we ingest and integrate.”

How can Orca help?

The Orca Cloud Security Platform helps organizations safeguard their software supply chain by delivering complete visibility and continuous monitoring across every layer of the cloud environment—from development pipelines to production workloads. Our patented SideScanning™ technology agentlessly detects vulnerabilities, misconfigurations, exposed secrets, and other risks across clouds and repositories, ensuring that nothing goes unnoticed. By unifying findings from code to cloud, Orca enables teams to identify and remediate issues before they propagate downstream, strengthening trust across the entire software supply chain.

Interested in discovering the benefits of the Orca Cloud Security Platform? Schedule a personalized 1:1 demo.