Software Supply Chain Attacks: What Organizations Need to Know Now

By Orenda Security

Executive Summary: Software supply chain compromise is now IBM’s second most common and second most expensive breach vector — $4.91 million per incident, 267 days to contain, the longest of any category. Sonatype identified over 454,600 new malicious open-source packages in 2025, a 75% year-over-year increase. Recent incidents — the Shai-Hulud npm worm and the chalk/debug compromise — show dependency risk has outpaced most organizations’ governance. AI-assisted development compounds it: LLMs hallucinate non-existent packages at meaningful rates, and nearly half of AI-generated code introduces known vulnerabilities. This post covers the threat landscape, regulatory context, and the governance and SDLC changes worth evaluating now.

A Governance Problem, Not Just a Technical One

Modern applications are assembled from open-source components at a scale that has outpaced most organizations’ visibility into their own risk. Black Duck’s 2025 OSSRA report found 97% of commercial codebases contain open-source components, averaging 911 per application, 64% transitive — introduced indirectly, without a deliberate review decision. That’s the structural reason supply chain attacks have become the dominant intrusion pattern of 2025–2026: the attack surface has outgrown the governance built to control it.

IBM’s 2025 Cost of a Data Breach Report puts the average supply chain compromise at $4.91 million and 267 days to identify and contain — both above general breach averages. A 2024 BlackBerry survey found more than 76% of organizations had experienced a supply chain attack in the prior year, 74% through a member they weren’t actively monitoring. Checkmarx found 63% had suffered one within two years — while only 50% were actively requesting SBOMs from vendors, and fewer than half knew how to act on them.

Where the Exposure Actually Sits

Four attack patterns account for most current incidents:

Maintainer account compromise. Attackers phish a trusted maintainer’s credentials, then push a malicious update to a package already trusted downstream — bypassing code review, since it arrives through a legitimate, previously-vetted channel.

Dependency confusion and typosquatting. Attackers register public packages that shadow internal private names, or names close enough to popular ones to be pulled in by automated tooling or developer error.

Malicious install-time execution. npm and Python both permit arbitrary code execution during installation via lifecycle hooks — exposure occurs before a developer ever uses the dependency.

CI/CD pipeline compromise. Build systems hold deployment credentials, signing keys, and API tokens, making them high-value targets independent of code quality. The tj-actions/changed-files breach exposed secrets across 23,000+ repositories from one compromised token.

Real Incidents, Real Consequences

SolarWinds (2020) remains the reference case for build-process compromise at scale: a nation-state actor inserted a backdoor into a legitimately signed Orion update, reaching roughly 18,000 organizations, including U.S. federal agencies, and shaped the regulatory response below.

The chalk/debug npm compromise (September 2025) illustrates concentration risk: one phished maintainer account was used to push malicious versions of foundational JavaScript packages with 2 billion-plus weekly downloads — one analysis estimated a blast radius of roughly 34% of npm.

The Shai-Hulud npm worm (2025) marked a shift in tradecraft: the first self-propagating npm worm harvested credentials and used them to automatically republish malicious versions of the victim’s own packages, spreading with no command-and-control infrastructure. A second wave that November compromised hundreds more packages and generated tens of thousands of malicious repositories.

AI-Assisted Development: A New Variable

AI coding tools introduce two distinct, measurable risks. Package hallucination (“slopsquatting”): USENIX Security 2025 research tested 576,000 code samples across 16 LLMs and found an average 19.7% package hallucination rate — repeatable enough across sessions that attackers can pre-register the most common fake names. A researcher proved this in practice: a hallucinated package registered as a test drew over 15,000 organic downloads in three months, including adoption in a major tech company’s public repo. A 2026 replication on newer models found rates compressed to 4.6%–6.1% — improving, but not eliminated.

Code-level vulnerability introduction: Veracode’s 2025 GenAI Code Security Report, testing over 100 LLMs across 80 tasks, found 45% of AI-generated code samples introduced OWASP Top 10 vulnerabilities — a rate that’s stayed flat through Veracode’s Spring 2026 follow-up. Apiiro found AI-generated code associated with 322% more privilege-escalation paths across Fortune 50 codebases.

AI-assisted code and AI-suggested dependencies warrant the same review rigor as code from an unvetted external contributor.

Building Resilience: What Corporations Should Do Now

Governance and risk posture:

• Make SBOM generation standard and build the capability to act on vendor-supplied SBOMs, not just collect them.
• Map controls against NIST SSDF (SP 800-218) and confirm EO 14028/EU CRA readiness where applicable — CRA reporting begins September 2026.
• Track dependency and build-pipeline risk as a distinct category in board-level risk reporting.

SDLC and pipeline controls:

• Enforce phishing-resistant MFA for anyone with publishing or maintainer access to depended-upon code.
• Pin dependency versions in reviewed lockfiles and CI/CD actions to commit SHAs, not mutable tags.
• Adopt behavioral dependency scanning, which catches newly published malicious packages that vulnerability databases can’t.
• Move toward verified build provenance (SLSA) and artifact signing (Sigstore/Cosign).

Bottom Line

Supply chain risk has moved from a specialized concern to a primary breach vector with measurable cost, regulatory exposure, and board-level visibility. Organizations managing it effectively treat it as shared accountability across security and engineering, embedded in SDLC controls rather than periodic audit.

Orenda Security’s penetration testing and SDLC assessments are designed to surface this class of exposure before it reaches production — including the tactics behind the incidents above.

Request a quote for more information