Software bill of materials mandates are reshaping how vendors get chosen

Ernst & Young's breach this week, claimed by the ShinyHunters extortion gang, followed a pattern that's become the default failure mode of 2026: attackers didn't break EY's own defenses, they compromised credentials through a supply-chain vendor and walked in through the front door. That pattern is exactly what software bill of materials mandates are designed to catch before it happens — and most companies still can't act on the SBOMs they're already required to collect.

An SBOM is a structured inventory of every component inside a piece of software: every library, every dependency, every version, down to the smallest module, including firmware. The idea is straightforward — if you know exactly what's inside a vendor's product, you can check it against known vulnerabilities the moment a new CVE drops, instead of finding out during an incident response call.

The Regulatory Wave Landing in 2026

The EU's Cyber Resilience Act, in force since December 2024, moves into its enforcement phase this year. Vulnerability and incident reporting requirements take effect in September 2026, with full SBOM production requirements following in December 2027 — giving vendors a runway, but not an indefinite one. The CRA requires a comprehensive component inventory from any vendor selling digital products into the EU market, which in practice means most global software vendors.

Financial services face a parallel requirement. Under the EU's Digital Operational Resilience Act (DORA), Articles 28 through 30 require regulated financial entities to understand and manage the full chain of providers behind any critical function — not just their direct vendor, but that vendor's vendors. A bank can no longer treat its cloud provider as a black box; it has to be able to answer what's actually running underneath it.

In the US, Executive Order 14028 already requires NIST-standard SBOMs for federal software procurement, translated by CISA into concrete contract requirements. That single policy lever has done more to normalize SBOM production among commercial vendors than any voluntary standard — companies that want federal contracts have to produce one regardless of whether their other customers ask for it.

Why Having an SBOM Isn't the Same as Using One

The failure mode showing up across 2026 deployments is consistent: organizations treat SBOM collection as a compliance checkbox rather than an operational input. They request SBOMs from vendors, file them, and stop there. Few build the pipeline that actually converts a static component list into a live decision — automatically flagging when a new CVE lands against a library three vendors have deployed and pushing that alert to whoever owns the vendor relationship.

That gap is exactly where the EY-style attack pattern lives. A supply-chain compromise doesn't announce itself as a vulnerability in your own stack; it shows up as compromised credentials at a vendor whose internal software composition you may never have actually inventoried, let alone monitored against new disclosures.

What an Operational SBOM Pipeline Actually Requires

• Machine-readable ingestion, not PDFs. SBOMs need to arrive in standard formats (SPDX or CycloneDX) that can be parsed automatically, not as a document a compliance team files away.
• Continuous CVE matching. The inventory is only useful if it's checked against new vulnerability disclosures on an ongoing basis, not once at vendor onboarding.
• Ownership mapping. Every flagged component needs a named internal owner responsible for following up with the vendor — without this, alerts pile up unactioned.
• Depth beyond tier one. DORA-style requirements exist precisely because tier-one vendor risk assessment misses the compromise that happens two or three vendors down the chain, which is where recent high-profile breaches have actually originated.

Actionable Takeaways

If your organization is collecting SBOMs purely to satisfy a contract clause or an auditor, you're carrying the compliance cost without the security benefit — and the EU enforcement timeline (September 2026 for incident reporting, December 2027 for full SBOM production) means the requirement is only going to tighten from here. Start by picking one high-risk vendor category — the kind with deep access to internal systems, like the IT service management platforms implicated in this week's EY breach — and build the ingestion-to-alerting pipeline for that category first, rather than trying to operationalize every vendor relationship at once. A partial pipeline that actually triggers alerts beats a complete SBOM archive that nobody queries.