In March 2026, four separate supply chain attacks hit within twelve days of each other. A vulnerability scanner, an infrastructure security scanner, an AI model gateway, and one of the most widely used HTTP clients in the JavaScript world were all compromised, all tools that development teams trusted every single day. The attack surface in each case was the same: dependencies quietly flowing through CI/CD pipelines that nobody was watching closely enough. 

Here’s the uncomfortable part. Most of the organisations affected weren’t careless; they had security tools running. What they lacked was visibility into what was inside the packages those tools relied on. That gap is exactly what a software bill of materials is supposed to close. 

Quick Refresher: What’s an SBOM (Software Bills of Materials), Really 

Think of it as an ingredient list for software.   Every application today is built from dozens, sometimes thousands, of components, and that stack goes well beyond application code. It includes open-source libraries and third-party packages, but also container images, base OS packages, and other installed system dependencies sitting underneath the code your team wrote. A software bill of materials is a complete, machine-readable inventory of every one of those pieces, covering what’s in it, which version, where it came from, and whether it has any known vulnerabilities attached to it. 

It sounds almost too simple to matter. But when a critical flaw gets discovered in some obscure open-source library (think Log4j), the difference between “we know exactly which of our systems use that library” and “let’s go find out” can be measured in weeks. Organisations without an SBOM find out the hard way, usually after everyone else has already patched. 

The Regulatory Picture Just Got Messier, Not Simpler 

If you’ve assumed the SBOM rules are settled, they’re not. 2026 has been a particularly chaotic year to be paying attention to. 

In January, the US Office of Management and Budget rescinded the mandatory SBOM attestation requirements that had applied to federal software vendors since 2022, replacing them with a risk-based approach that lets agencies define their own software assurance requirements rather than follow a single government-wide checklist. 

That doesn’t mean SBOMs are becoming less important. Agencies can still write SBOM requirements into contracts, and plenty will. Sector-specific rules haven’t budged: FDA medical device submissions still require them, and the EU’s Cyber Resilience Act is arguably getting stricter, with reporting obligations kicking in this September and SBOM-specific requirements following in late 2027. 

So, the honest read is this: SBOM mandates are fragmenting rather than disappearing. Instead of one clear standard to build toward, organisations now face patchwork of federal, sectoral, and regional rules that shift depending on who they’re selling to and where. That’s a harder problem to solve than “meet this one checklist,” not an easier one. 

The Real Issue was Never the Paperwork 

An SBOM was never really about compliance. It’s about knowing, at any given moment, what your software is actually made of. 

Third-party and open-source code now makes up somewhere between 80 and 90 per cent of a typical modern application, the majority of what you’re running. Here’s the part that should concern procurement and security leaders alike: in the overwhelming majority of cases where a vulnerable component gets pulled into a build, a fixed version already exists. The problem isn’t missing patches. It’s that organisations don’t know they need one until it’s too late. 

This is exactly where continuous software composition analysis earns its keep. Rather than treating an SBOM as a document generated once, right before an audit, mature engineering teams fold this kind of scanning directly into the build pipeline. Tools like Veracode can automatically flag vulnerable dependencies, licence risks, and outdated components every time code ships, rather than once a year when someone remembers to check. 

What “Doing This Well” Actually Looks Like 

Organisations ahead of the curve share a few habits: 

• They generate SBOMs automatically, in standard formats like CycloneDX or SPDX, as part of every build, not as a manual step before a client asks. 

• They map transitive dependencies, not just the libraries they directly chose, but everything those libraries quietly pull in behind them. 

• They treat vulnerability checking as continuous, correlating new CVEs against their component inventory in near real time. 

• They can answer “Were we exposed?” in minutes, not days, because when the next Log4j-style incident hits, that’s the question every client and regulator will ask.
  

None of these are exotic. It’s mostly about building the right tooling into the pipeline early, rather than bolting it on after the fact. 

Where This Fits into How Mitrais Builds Software 

This is one of the more practical places where a development partner’s day-to-day habits matter more than their sales pitch. Mitrais integrates Veracode’s static and software composition analysis directly into client delivery pipelines, so dependency inventories, known-vulnerability flags, and licence checks happen continuously, as part of every build, not as a scramble the week before a security review. 

That’s a meaningful difference for organisations navigating this fragmented mandate landscape. Instead of asking a vendor, “Can you help us get SBOM-ready?”, a more useful question is: “What does your team already do on every release?” For clients working with Mitrais, that answer includes automated, pipeline-embedded software composition analysis as standard practice, not something spun up in response to a compliance deadline. 

The Bottom Line 

SBOM mandates in 2026 are less unified than they were a year ago, which is precisely why third-party risk management is getting harder, not easier. There’s no single checklist to point to anymore. What actually protects an organisation isn’t a document produced once for an auditor; it’s a development process that knows, continuously and automatically, exactly what it’s built from. 

If your team is thinking about how to build that kind of visibility into your software supply chain, it’s worth asking not just, “Do you produce an SBOM?” but also, “How often, and how automatically?” 

Want to talk about how secure software delivery works in practice? Get in touch with the Mitrais team.