Key takeaways
SBOMs are still critical, even without government mandates, because they help organizations understand what is inside their software and where risk exists.
SPDX and CycloneDX serve different purposes, with SPDX supporting compliance and licensing workflows, while CycloneDX is better suited for security operations and vulnerability management.
OpenVEX and provenance data help teams move beyond static inventories by showing whether vulnerabilities are actually exploitable and whether components can be trusted.
The most mature organizations operationalize SBOMs by integrating them into CI/CD workflows, vulnerability prioritization, and remediation processes.
For years, Software bill of materials (SBOMs) have been closely tied to regulation, procurement requirements, and government guidance. So when the Trump administration rescinded several Biden-era software security memorandums in early 2026, including guidance around SBOMs and software attestations, some organizations may have viewed it as a reason to deprioritize them.
That would be a mistake.
SBOMs were never valuable because the government asked for them. They’re valuable because modern software supply chains have become too large, too dynamic, and too dependent on open source components for teams to manage risk without them.
As AI-generated code, public registries, third-party packages, containers, and SaaS integrations continue to flood enterprise application environments, security leaders need a way to understand what is actually inside their applications, where it came from, and whether or not it can be trusted.
That is what an SBOM provides. But, as software supply chains continue to expand, it’s important to ask: How can organizations operationalize SBOMs before that complexity grows beyond their ability to control it?
Here’s what you need to know.
SPDX vs. CycloneDX: Understanding the two major SBOM formats
Once enterprise engineering teams decide to operationalize SBOMs, one of the first questions they face is which format to use. In most cases, that conversation comes down to two key standards: SPDX and CycloneDX.
Both are designed to document the components, dependencies, and metadata inside software. Both can support compliance, visibility, and risk management efforts. But, both were built with different priorities in mind, which means each one tends to serve a different purpose inside the enterprise.
What SPDX is best for
SPDX was originally created with software licensing and compliance in mind. It’s particularly useful for organizations that need to understand what open source components they’re using, what licenses are attached to them, and whether there are any legal or contractual risks associated with distribution.
For many enterprises, SPDX has become the preferred format for procurement reviews, audit documentation, third-party vendor assessments, and software provenance records. In fact, it’s often the format that many legal, compliance, and governance teams are most comfortable working with because it focuses heavily on software package inventories and licensing obligations.
What CycloneDX is best for
CycloneDX, on the other hand, was designed with security operations in mind. While it can also capture licensing information, it’s typically stronger when it comes to documenting vulnerabilities, dependency relationships, container contents, services, APIs, and runtime metadata.
That makes CycloneDX particularly useful for engineering and security teams trying to operationalize SBOMs inside CI/CD pipelines. It also makes it valuable for vulnerability management programs, container security workflows, and software supply chain monitoring tools.
As software environments become more dynamic and as AI-generated code introduces new packages faster than humans can review them, CycloneDX often provides the richer context teams need to understand not just what is present, but what is risky.
Why most enterprise teams will need both
For most organizations, SPDX and CycloneDX are not competing standards but instead act as complementary ones.
SPDX helps teams answer legal, compliance, and provenance questions, while CycloneDX helps them answer operational, security, and remediation questions.
The most mature organizations increasingly use both. They generate SPDX documents to satisfy auditors, procurement teams, and legal stakeholders, while using CycloneDX to power security tooling, prioritize vulnerabilities, and improve remediation velocity.
The missing layer: why does OpenVEX matter?
Even the most detailed SBOM still has a major limitation. That is: it tells you what’s inside an application, but not whether any of it is actually exploitable.
OpenVEX is designed to add this exploitability context to SBOM data. So, instead of simply flagging that a vulnerable package exists, it helps organizations determine whether that vulnerability is actually reachable and whether remediation is truly required.
For example, an SBOM may show that a vulnerable library exists inside an application. But OpenVEX may reveal that the vulnerable functionality is disabled, unused, or isolated from production traffic. In another case, a package may technically contain a CVE, but the exploit path may not be reachable because the affected component is not enabled in the build.
That level of context is critical in large enterprise environments where security teams cannot afford to treat every CVE as equally urgent.
Without OpenVEX, organizations typically struggle to prioritize remediation based on real-world exposure and fail to focus their resources on the vulnerabilities most likely to create operational, financial, or reputational damage.
THE 2026 STATE OF VULNERABILITY MANAGEMENT | CONTAINER SECURITY EDITION
How to actually operationalize SBOMs
It goes without saying that most enterprise engineering teams already know how to generate an SBOM. The harder challenge is turning that information into something that actually starts to influence security decisions and remediation efforts in real time.
Operationalizing SBOMs means moving them out of audit trails and static spreadsheets and turning them into living records that can support ongoing software supply chain management.
1. Integrate SBOM generation into your existing CI/CD workflows
Integrating SBOM generation directly into CI/CD pipelines ensures teams always have an up-to-date record of what was actually deployed, including packages, dependencies, containers, and transitive components. It also reduces the risk of stale documentation that no longer reflects the production environment.
At the end of the day, SBOMs should not be created once a year, or only when a customer asks for them. They should be generated automatically as part of every (and we mean every) build and release process.
2. Tie SBOMs to vulnerability prioritization
Instead of simply showing that a vulnerable package exists, organizations should use SBOM data to prioritize which issues matter most based on factors like:
- Business criticality
- Exploitability
- Reachability
- Runtime exposure, and
- The importance of the affected system.
Importantly, not every CVE deserves the same response. A vulnerable package inside a low-risk internal tool, for instance, should not be treated the same way as a reachable vulnerability inside a customer-facing production application.
3. Layer in OpenVEX and provenance data
SBOMs alone tell teams exactly what’s present, but they do not explain whether those components are trustworthy or whether vulnerabilities are actually exploitable.
It’s for this reason that mature DevSecOps teams increasingly layer in OpenVEX data alongside their SBOMs, as well as provenance records, signed attestations, and build metadata. This additional context helps security teams understand where a component came from, how it was built, whether it has been tampered with, and whether a flagged vulnerability actually creates risk.
4. Connect SBOMs to automated remediation workflows
Finally, it’s important to connect SBOMs into your existing remediation workflows.
If an SBOM identifies a risky or outdated dependency, teams should be able to quickly identify safer versions, trigger rebuilds, update packages, or replace vulnerable components without relying entirely on manual investigation.
This is where many organizations still struggle. They can identify vulnerabilities, but they cannot fix them fast enough to keep up with the pace of development.
The ActiveState Edge
Generating SBOMs is relatively easy. Operationalizing them is not.
ActiveState helps organizations move beyond static inventories by connecting SBOMs, provenance, OpenVEX context, and remediation into a single view, all without disrupting existing developer workflows. Our catalog of more than 79 million vetted open source components gives teams a more secure starting point, while continuous maintenance and build-from-source provenance reduces the burden of manual investigative work.
Most importantly, we help teams connect vulnerability visibility to action. So, instead of simply identifying open source risk, organizations can prioritize that risk, automatically remediate it and therefore reduce exposure without slowing developer velocity.
Provenance: the foundation of trust in the software supply chain lifecycle
Build attestations, signed artifacts, immutable records, and reproducible builds help organizations verify that software has not been tampered with and can be traced back to a trusted source. This is especially important as malicious packages, dependency confusion attacks, and AI-generated code continue to increase the risk entering enterprise environments.
That is where provenance becomes critical.
Without provenance, teams are often making assumptions about the integrity of the software they deploy. With it, they can make better decisions about what belongs in production and what needs to be remediated or replaced.
If you want to learn more about how ActiveState can help you operationalize SBOMs, improve provenance, and accelerate remediation, talk to one of our experts today.
Frequently Asked Questions
SBOMs raise a lot of questions, especially as organizations move beyond compliance and start using them to improve visibility, prioritize risk, and strengthen software supply chain security.
SPDX is primarily focused on software licensing, compliance, and package inventories, while CycloneDX is more security-focused and better suited for vulnerability management, dependency mapping, and operational workflows.
Many enterprise teams use both formats together to support different stakeholders across legal, compliance, engineering, and security teams.
SBOMs are valuable because they give organizations visibility into the open source components, dependencies, containers, and third-party packages inside their software.
As AI-generated code and external integrations continue to expand the software supply chain, teams need SBOMs to understand what is present, where it came from, and whether it creates risk.
OpenVEX adds exploitability context to SBOM data.
Instead of simply showing that a vulnerable package exists, it helps organizations determine whether the vulnerability is actually reachable, in use, or relevant to their environment. This reduces false positives and helps security teams focus on the vulnerabilities that actually matter.
Organizations can operationalize SBOMs by generating them automatically inside CI/CD pipelines, connecting them to vulnerability prioritization workflows, layering in OpenVEX and provenance data, and tying them directly to remediation processes.
The goal is to turn SBOMs from static documents into living records that support ongoing software supply chain management.
Provenance helps organizations understand where software components came from, how they were built, and whether they can be trusted.
Build attestations, signed artifacts, immutable records, and reproducible builds all help reduce the risk of tampered packages, dependency confusion attacks, and malicious open source components entering production.
