Software Supply Chain Attacks: From Typosquatting to Worms Like Shai-Hulud

What Is a Software Supply Chain Attack?

A software supply chain attack occurs when malicious code is introduced into software indirectly, by compromising:

• Dependencies
• Build tools
• CI/CD pipelines
• Distribution mechanisms such as package registries

Instead of attacking your application directly, attackers target how your application is built.

When you install a dependency, you inherit its behavior, including any malicious logic embedded within it.

The Classic Registry Attack Model (npm and PyPI)

For years, the dominant attack pattern followed a simple model:

1. Upload a malicious package to a trusted registry such as npm or PyPI
2. Make it look legitimate using names, descriptions, and README files
3. Get it installed via:
   • Typos
   • Name confusion
   • Dependency resolution mistakes
   • Automated CI builds
4. Execute malicious code during installation or runtime
5. Steal secrets and exfiltrate data

This model requires no vulnerability exploitation, only normal developer behavior.

How Attackers Increase Their Odds

Attackers do not rely on chance. They systematically use several techniques.

Typosquatting

Publishing look-alike packages such as requessts or lodahs to exploit human error.

Name and Trend Hijacking

Using names related to popular frameworks, AI tooling, or internal-sounding utilities.

Dependency Confusion

Publishing public packages with the same name as private or internal ones, exploiting misconfigured build systems.

Maintainer Account Compromise

Phishing or stealing tokens from maintainers, then publishing malicious updates to trusted packages.

This last method is the most dangerous and it set the stage for Shai-Hulud.

The Shai-Hulud Campaign: A Turning Point

Shai-Hulud marked a significant escalation in supply chain attacks against npm.

Unlike traditional malicious packages, Shai-Hulud behaved like a worm.

What Made Shai-Hulud Different?

Instead of stopping at a single compromised package, Shai-Hulud:

• Infected a maintainer’s npm account
• Injected malicious install scripts into packages
• Harvested credentials and tokens
• Used those credentials to publish infected versions of other packages
• Spread laterally across the ecosystem

Once inside, it propagated automatically.

What It Targeted

The malware focused on developer and CI environments, stealing:

• npm and GitHub tokens
• Cloud credentials
• Environment variables
• CI/CD secrets

Some variants also injected malicious GitHub Actions to continue data exfiltration during automated builds.

Why Shai-Hulud Matters

Shai-Hulud demonstrated that:

• Supply chain attacks can be self-propagating
• Trust in maintainers can be weaponized at scale
• Open-source ecosystems can be abused without exploiting a single CVE

This was not a one-off mistake. It was an architectural weakness being exploited.

What Malicious Packages Usually Contain

Across npm and PyPI campaigns, including Shai-Hulud-style attacks, common behaviors include:

Credential Theft

• GitHub and GitLab tokens
• npm and PyPI credentials
• AWS, GCP, and Azure keys

File Harvesting

• .env files
• .npmrc and .pypirc
• SSH private keys

Install-Time Execution

• postinstall scripts in npm
• setup.py or build hooks in PyPI

In many cases, simply installing the package is enough. No import or execution is required.

Why These Attacks Keep Working

Supply chain attacks succeed because:

• Registries are open by design
• Dependency graphs are large and opaque
• Install scripts run automatically
• CI systems execute unattended
• Developers reasonably trust popular tools

From an attacker’s perspective, this is low cost and high impact.

Practical Lessons for Developers

This is not about avoiding open source. It is about using it realistically.

Effective mitigations include:

• Pinning dependency versions
• Auditing install scripts
• Hardening CI/CD pipelines
• Enforcing MFA for maintainers
• Monitoring dependency changes, not just vulnerabilities
• Treating new or obscure packages with caution

No single control is sufficient. Defense must be layered.

Final Thoughts

Shai-Hulud showed that supply chain attacks are no longer limited to isolated malicious packages. They can spread, persist, and scale by abusing trust and automation.

As software becomes more interconnected, the supply chain becomes the attack surface.

Understanding this shift is essential for modern developers, not just security teams.

Additional Context and Analysis

The following sections expand on the threat model and add important context without changing the core argument above.

A Critical Reality: Legitimate Maintainers Can Become the Threat

Not all supply chain attacks involve fake packages or external attackers.

A popular package can become malicious if:

• A maintainer’s account is compromised
• A maintainer is coerced or socially engineered
• A maintainer intentionally adds a backdoor
• Ownership or control of a package changes hands

When this happens, the malicious code is published under a trusted name, signed by a legitimate maintainer, and distributed through official channels.

Developers update automatically. CI systems pull the latest version. No exploit is required.

This scenario bypasses most traditional defenses because nothing appears suspicious at the surface level.

Why Independent Security Researchers Are Necessary

Because registries operate at massive scale, no registry can manually review every update.

This makes independent researchers critical to ecosystem safety.

Researchers continuously:

• Monitor new and updated packages
• Analyze install scripts and runtime behavior
• Correlate suspicious activity across campaigns
• Detect patterns humans and tools miss in isolation

Many large supply chain attacks, including Shai-Hulud-style campaigns, were discovered outside of registry operators and vendors.

Without this independent monitoring, malicious packages would remain active far longer.

What a Real Supply Chain Incident Looks Like

A typical real-world supply chain incident does not start with an obvious breach.

It often looks like this:

1. A developer or CI system installs a dependency as part of a normal build
2. An install script runs automatically
3. The script reads environment variables or configuration files
4. Credentials are sent to an external endpoint
5. The build succeeds and no alarms are triggered
6. Days or weeks later, stolen credentials are used elsewhere

From the developer’s perspective, nothing appears broken. The compromise happens quietly and the impact is delayed.

This delayed feedback loop is one reason supply chain attacks are difficult to detect and investigate.

Why Traditional Security Tools Often Miss Supply Chain Attacks

Many traditional security controls are not designed for this threat model.

Common gaps include:

• Vulnerability scanners focus on known CVEs, not malicious intent
• Static analysis rarely executes install scripts
• Network monitoring may not flag small credential exfiltration
• Code reviews usually do not include transitive dependencies
• CI pipelines assume dependencies are trusted inputs

Because malicious packages often use legitimate language features and normal network calls, they blend into expected behavior.

As a result, supply chain attacks frequently bypass defenses that are effective against more traditional exploits.

Signals Security Researchers Use to Identify Malicious Packages

Researchers who analyze npm and PyPI ecosystems do not rely on a single indicator. They look for patterns such as:

• Newly published packages with install scripts and no meaningful functionality
• Code that accesses environment variables unrelated to its stated purpose
• Obfuscated payloads in otherwise simple libraries
• Network requests made during installation
• Rapid version changes shortly after publication
• Maintainers publishing many unrelated packages in a short time

Individually, these signals may be benign. Together, they often indicate malicious intent.

This pattern-based approach is how many large campaigns are discovered early.

Why This Is Not an Argument Against Open Source

None of this means open-source software is inherently unsafe.

Open-source ecosystems enable:

• Faster innovation
• Shared security improvements
• Public scrutiny and research
• Rapid detection and response once issues are found

The problem is not openness. The problem is scale combined with automation and trust by default.

Understanding supply chain risk allows teams to use open source responsibly rather than fearfully.

Where This Is Headed

Supply chain attacks are unlikely to disappear.

Current trends suggest:

• More automated propagation
• Greater focus on CI and developer credentials
• Increased targeting of popular ecosystems and tooling
• Faster publish exploit remove cycles

At the same time, registries and tooling are improving detection, requiring stronger authentication, and investing in ecosystem security.

The outcome will likely be an ongoing balance between convenience and verification rather than a single permanent fix.