The Hidden Dangers in Our Software Supply Chain: Why It's Bigger Than You Think

In today's fast-paced digital world, software powers everything from the apps on our phones to the cloud systems running global businesses. But behind the scenes, there's a complex web called the software supply chain—the process of sourcing, building, and delivering software components. Traditionally, we've focused on securing this chain during application development and deployment. However, as technology evolves, risks are creeping into unexpected places, like the tools developers use every day and even the software on our personal devices.

This article aims to shed light on how the software supply chain has expanded far beyond just building and shipping apps. We'll break it down in simple terms for non-technical leaders, project managers (PMs), and engineers who might not deal with package management daily. By the end, you'll understand why awareness is crucial and how these hidden vulnerabilities could impact your team or organization.

What Is the Software Supply Chain, Anyway?

Imagine building a house: You don't make every brick, nail, or window yourself. Instead, you source them from suppliers, assemble them, and ensure the final structure is safe. The software supply chain is similar—it's the ecosystem of code, libraries, and tools that developers "source" to create software.

Key elements include:

Open-source packages: Reusable code snippets from public repositories like npm (for JavaScript), PyPI (for Python), or Cargo (for Rust). These are free and community-driven, speeding up development.
Dependencies: Packages often rely on other packages, creating a chain (or "tree") of interconnected code. This is recursive—meaning one package might pull in dozens or hundreds more.
SBOM (Software Bill of Materials): A list of all components in your software, like an ingredients label on food. It helps track what's inside.

In the past, security focused on scanning these packages for vulnerabilities during app building and deployment. Tools would check for known issues, generate an SBOM, and ensure everything was safe before going live. But that's no longer enough. The supply chain has infiltrated deeper into our workflows.

The Old Way: Focusing Only on App Development and Deployment

Historically, teams treated the software supply chain as something confined to production applications—the software your customers use. For example:

A developer writes code for a web app.
They install packages via commands like npm install or pip install.
During the build process (often in a CI/CD pipeline, which automates testing and deployment), the team scans for malicious code or vulnerabilities.
An SBOM is created to document all dependencies.

This approach worked reasonably well for "end-product" software. If a package had a flaw, it could be caught before deployment. But it assumed risks were limited to that final app. Reality? Not so much.

The Expansion: DevOps Tools, Local Installs, and Recursive Risks

Today, software development isn't just about the app—it's about the entire ecosystem supporting it. DevOps (a blend of development and operations) tools, which help automate infrastructure, testing, and monitoring, are often built on the same package systems like JavaScript or Python.

Consider this scenario:

A developer or DevOps engineer runs npm install aws-cdk (a tool for managing AWS cloud infrastructure) on their local laptop or in a CI/CD pipeline.
This isn't for the main app; it's for setting up servers, databases, or deployment scripts.
But aws-cdk has its own dependencies, which have more dependencies, and so on. It's a recursive rabbit hole—hard to fully map or monitor.

Unlike production apps, these tools often run in less controlled environments:

Local machines: Developers install packages directly on their laptops, outside formal security scans.
CI/CD pipelines: Automated workflows that build and deploy code, but they might pull in unvetted packages mid-process.
Everyday tools: Even non-app software like code editors or AI assistants relies on these packages.

The problem? We might vet the top-level package (e.g., the first version of aws-cdk we install), but we have no visibility into the deeper layers. A single update or hidden dependency could introduce risks without anyone noticing.

Evolution of Attacks: From End-User Exploitation to Proactive Credential Theft and Spread

Supply chain attacks aren't new, but their tactics are evolving. Older incidents often focused on injecting malicious code into applications to target end-users, such as visitors to a website. For instance, compromised packages like ua-parser-js in 2021 installed cryptominers or trojans that could steal data from browsers, aiming to hijack cryptocurrency wallets or personal information from unsuspecting users. Similarly, the 2018 event-stream hack embedded a backdoor to steal Bitcoin from apps built with the package, affecting the final deployed software and its users.

These attacks typically relied on the malicious code being bundled into the application and executed in production environments, passively waiting to exploit visitors or users. The damage was downstream, impacting customers rather than the development process itself.

In contrast, more recent worms like Shai-Hulud represent a shift toward aggressive, self-propagating threats that target the development environment upfront. Discovered in mid-September 2025, Shai-Hulud is a worm that infects npm packages, using "onInstall" hooks to run automatically upon installation. It doesn't just sit idle—it actively scans for secrets such as npm tokens, GitHub credentials, AWS keys, and environment variables on local laptops, in CI/CD pipelines, and even queries cloud metadata for ephemeral credentials. Tools like TruffleHog are embedded to deepen the scan, and stolen data is exfiltrated to public GitHub repos created by the worm itself.

What makes it worm-like is its propagation: Using pilfered tokens, it automatically republishes compromised versions of other packages under the maintainer's control, turning victims into unwitting spreaders. This moves the infection window forward, infiltrating source repositories (like GitHub) and cloud services, potentially compromising entire organizations. Over 500 packages were affected in this campaign, including those linked to major companies like CrowdStrike.

This evolution from passive end-user attacks to proactive dev-side credential hunting amplifies the risk, as it enables exponential spread across the supply chain before detection.

A Real-World Wake-Up Call: The Shai Hulud NPM Worm

To illustrate the danger, let's look at a recent incident: the Shai Hulud worm, a malicious package that spread through npm in 2025.

Here's what happened in simple terms:

Shai Hulud disguised itself as a legitimate package.
It used an "onInstall" hook—a script that runs automatically when the package is installed.
Once installed, it didn't just sit there. It scanned for sensitive data like API keys, passwords, or "secrets" on the local machine.
It went further: In CI/CD pipelines, it hunted for environment variables (secret values used in automation).
Even scarier, it attempted to access cloud services like AWS to steal more secrets.

This wasn't limited to production apps. Developers running npm install locally exposed their personal laptops. Pipelines automating DevOps tasks became infection points. The worm spread because npm packages are public—anyone can publish without upfront checks. No gatekeepers, just trust in the community.

Shai Hulud highlights a key flaw: Even if you trust the initial package, recursive dependencies mean you might unwittingly install something harmful. And since DevOps tools run with high privileges (e.g., access to cloud accounts), the fallout can be massive—data breaches, financial loss, or operational downtime.

Why Are We So Vulnerable? The Trust Issue with Open Source

Open source is amazing—it democratizes innovation and accelerates progress. But our over-reliance on it creates blind spots. Here's why:

Public Repositories Without Validation:
- Platforms like npm.js and PyPI are open to all. Anyone with an account can upload a package—no mandatory security reviews.
- Contrast this with app stores like Apple's, which vet submissions. In open source, it's "publish first, fix later."
Recursive Dependencies Make Visibility Impossible:
- A simple install can pull in hundreds of sub-packages. Tools like dependency trees exist, but they're not always used, especially in ad-hoc DevOps tasks.
- Updates happen automatically in many setups, introducing new risks without notice.
Beyond App Pipelines:
- Risks extend to non-development tools. For instance:
- VSCode (Visual Studio Code): A popular code editor built on Electron (a framework for desktop apps using web tech). It uses npm packages and supports extensions that pull in more code.
- Claude or similar AI tools: Many are built with Python or JS dependencies, potentially vulnerable.
- Electron-based apps: These are desktop programs (like Slack or Discord) that auto-update. An update could inject malicious code via a compromised package.

In short, open source is everywhere—not just in your company's app, but in the tools enabling your workflow. We trust it because it's convenient, but that trust is often unearned.

The Broader Impact: From Laptops to Critical Infrastructure

This isn't just a developer problem; it affects entire organizations:

Non-Tech Leaders and PMs: Budgets for security might focus on apps, but a breach in a DevOps tool could halt projects, expose customer data, or lead to compliance fines (e.g., GDPR or HIPAA).
Engineers Outside the Process: If you're not handling packages daily, you might assume IT has it covered. But local installs bypass central controls.
Global Scale: Supply chain attacks like SolarWinds (2020) or Log4j (2021) showed how one vulnerability ripples worldwide. Now, with DevOps proliferation, the attack surface is larger.

Imagine a PM overseeing a cloud migration: The team uses aws-cdk in pipelines. A worm like Shai Hulud sneaks in, steals AWS credentials, and compromises your entire infrastructure. It's not hypothetical—it's happening.

Moving Forward: Awareness Is Key, with a Focus on Hygiene

The software supply chain has evolved, and so must our mindset. It's no longer just about the app you deploy; it's about every tool, script, and dependency in your ecosystem.

To build resilience:

Educate Teams: Train everyone—from execs to engineers—on supply chain risks. Use SBOMs not just for apps, but for tools.
Adopt Best Practices: Lock dependencies to specific versions, use private registries for vetted packages, and scan local/CI environments regularly.
Emphasize Hygiene: Maintain laptop and pipeline hygiene by using minimal, scoped credentials—grant only the access needed for a task, and rotate them frequently. Avoid storing secrets in plain text or environment variables without encryption, and use tools like secret managers (e.g., AWS Secrets Manager) to limit exposure. This is especially critical against worms like Shai-Hulud that hunt for broad tokens to spread to clouds and repos.
Question Trust: Don't assume open source is safe. Verify publishers, review changelogs, and limit auto-updates.

Awareness is the first step. By recognizing that vulnerabilities lurk in DevOps tools, local installs, and everyday software—and that attacks are shifting to proactive theft for wider spread—we can foster a culture of caution. In a world where software is ubiquitous, staying vigilant isn't optional—it's essential for security and success.

What are your thoughts? Have you encountered supply chain issues in your tools? Share in the comments below!

This article is based on emerging trends in software security as of September 2025.

Image credit: https://xkcd.com/2347/