Software Supply Chain Attack Statistics 2026, Mapped to the BOM That Catches Each One

Ask a security team "are we protected against supply-chain attacks" and most will point to their SBOM. That's a real answer, but it's an incomplete one. In the same 12-month window, real attacks hit a certificate authority, a model registry, and a firmware updater, none of which an SBOM alone would have flagged. Supply-chain risk isn't one problem with one document. It's five different attack surfaces, and there's a specific bill of materials built for each.

SBOM: the one everyone has, and the one npm keeps proving is necessary

Start with the numbers, because they're stark. Sonatype's 2026 State of the Software Supply Chain report found 454,600 new malicious open-source packages in 2025 alone, a 75% increase over the year before. The cumulative total of known malicious packages Sonatype has identified now exceeds 1.233 million. Over 99% of that malware landed on a single ecosystem: npm.

This is the attack surface an SBOM exists for. A software bill of materials lists every dependency, direct and transitive, that ends up in your build. When a malicious package gets published, or an existing one gets compromised, an SBOM is what lets you answer "do we use that" in minutes instead of days.

CBOM: the certificate authority breach an SBOM would never have seen

In April 2026, an attacker got into DigiCert's support systems. Not through a code flaw. Through social engineering. A threat actor used DigiCert's own support chat to send a bad file disguised as a customer screenshot. One system stayed compromised for roughly two weeks before anyone noticed. By the time DigiCert responded, the attacker had already misused real code-signing certificates.

1. 60 EV Code Signing certificates were revoked as a precaution.
2. 27 of those were confirmed to have actually been misused.
3. The certificates were used to sign malware in the Zhong Stealer family.
4. Researchers attributed the intrusion to CylindricalCanine, a subgroup of the GoldenEyeDog (APT-Q-27, Dragon Breath) threat cluster.

Here's why this matters for the BOM question specifically. If one of your dependencies, or a vendor's software, was signed with one of those 27 misused certificates, your SBOM would show you the package name and version. It would not show you the certificate that signed it, whether that certificate is still trusted, or whether it's since been revoked. That's a cryptographic inventory question, not a package inventory question. A CBOM tracks the algorithms, keys, and certificates your software actually trusts, which is the only way to know if an incident like DigiCert's touches you at all.

AIBOM: the model file is the new dependency, and it's not being tracked like one

In May 2026, a Hugging Face repository called Open-OSS/privacy-filter climbed to the top of the trending list, impersonating an official OpenAI release. HiddenLayer's research confirmed it reached over 200,000 downloads in under 18 hours, before it was caught and removed. The repo copied OpenAI's real model card almost verbatim, and its payload ran through a multi-stage chain ending in an infostealer that harvested browser credentials, crypto wallets, SSH keys, and Discord tokens.

A separate, deeper flaw makes this worse than a one-off typosquat. Unit 42 published research on it in September 2025, called Model Namespace Reuse. When a Hugging Face account or model name gets deleted or transferred, an attacker can re-register that exact name. Code that references the model by name then quietly starts pulling from the attacker's version instead. Researchers proved live access into both Google Vertex AI and Microsoft Azure AI Foundry this way. They also found thousands of open-source repos still pointing at names anyone could reclaim.

QBOM: most companies can't answer a question the top web domains already can

Cloudflare tracks how much of the web has actually started the post-quantum transition, not how many vendors talk about it. Their own scan of the top 100,000 domains found that 39% now support post-quantum key agreement as of September 2025, up from 28% just six months earlier. That's real, measured adoption, not a survey of intentions.

The reason this matters now, not in five years, is the algorithms are already finalized. NIST completed FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) on August 13, 2024. The math for post-quantum migration is done. What most organizations can't do yet is answer the more basic question Cloudflare just answered for the top 100,000 domains: what fraction of our own cryptography has actually made the switch. A QBOM is a CBOM graded specifically for that question, which algorithms in your stack are quantum-vulnerable, and how much of your real estate has already moved.

HBOM: the newest, thinnest, and most overlooked front

Worth being honest here rather than stretching thin evidence to sound complete. Hardware and firmware supply-chain security doesn't have the same density of recent, named incidents as the other three categories. It's real, but it's the least mature front, and pretending otherwise wouldn't help anyone.

The clearest recent example is from August 2026. Researchers found malware spreading through a legitimate firmware updater on Android car head units, tied to a group they named MoYu. The malware, called "zhima," arrived through the vehicle's own built-in updater. Not a third-party app store. Not a phishing link. It ran as a reverse-proxy botnet module used for ad fraud. Researchers called it the first documented case of malware spread this way, through a car device's own update mechanism.

CISA published a Hardware Bill of Materials Framework back in September 2023. It's the standards anchor for this category. It exists for a simple reason. Firmware and hardware supply chains have the same blind spot software did a decade ago. Almost nobody can produce a full inventory of what's actually running below the OS layer. Fewer still can verify it wasn't tampered with in transit.

The bottom line

Five real, current attacks. Five different layers. A malicious npm package, a compromised certificate authority, a typosquatted AI model, an unmigrated cryptographic stack, and a tampered firmware updater all count as supply-chain attacks, and all five happened within roughly the same twelve months. An SBOM alone would have caught exactly one of them. The point isn't to buy five separate tools. It's to recognize that supply-chain risk was never a single-document problem, and treat the BOM suite as five views into the same question: what are we actually running, and can we prove it hasn't been tampered with.