What is a Software Bill of Materials (SBOM) and why does your data platform need one?

A Software Bill of Materials (SBOM) is a structured, machine-readable inventory of every software component, library, and dependency that makes up an application or platform. Think of it as a nutrition label for software: it tells you exactly what’s inside, where it came from, and which version you’re running. For any organization operating a data platform, an SBOM is the foundation of traceable, auditable software supply chain security. We cover how Stackable approaches SBOM generation and software transparency for Kubernetes-native data platforms specifically at the end.

What components does an SBOM actually list?

An SBOM lists every software component included in a given artifact, from first-party application code down to transitive open-source dependencies. At minimum, a well-formed SBOM records the component name, version, supplier or origin, license, and a unique identifier such as a package URL (PURL) or Common Platform Enumeration (CPE) string. It also documents the relationships between components, showing which package depends on which.

In practice, a complete SBOM for a data platform component might include:

Operating system base image layers and system libraries
Language runtime environments (JVM, Python interpreter, and so on)
Direct application dependencies declared in build manifests
Transitive dependencies pulled in by those direct dependencies
Internal libraries or shared modules authored by the vendor or development team
Cryptographic libraries and their versions

The depth of component coverage matters enormously. A shallow SBOM that only captures declared dependencies misses the transitive graph, and that’s where many real-world vulnerabilities actually live.

What are the main SBOM formats and standards?

The two dominant SBOM formats are CycloneDX and SPDX (Software Package Data Exchange). CycloneDX, maintained by OWASP, is built for security use cases and integrates naturally with vulnerability management tooling. SPDX, a Linux Foundation standard, was originally designed with license compliance in mind but is now widely used for security purposes too. Both formats support JSON and XML serialization, and most tooling treats them as interchangeable.

Beyond format, several related standards shape how SBOMs are used:

Supply-chain Levels for Software Artifacts (SLSA, pronounced “salsa”): A framework for grading the integrity of the build process that produced the artifact, from basic source provenance to fully hermetic, reproducible builds.
Vulnerability Exploitability eXchange (VEX): A companion document to an SBOM that states whether a known vulnerability in a listed component actually affects the product as shipped, which helps cut down on alert fatigue.
Common Security Advisory Framework (CSAF): A machine-readable format for security advisories that can reference SBOM component identifiers to automate patch prioritization.

For most teams starting out, CycloneDX is the practical first choice. It has broad tool support and integrates natively with Common Vulnerabilities and Exposures (CVE) scanning pipelines.

Why is an SBOM especially critical for data platforms?

Data platforms are compositionally complex. A single deployment might combine a query engine, a streaming broker, a storage layer, an orchestrator, and multiple connectors, each with its own deep dependency tree. That complexity multiplies the attack surface and makes manual component tracking completely impractical. An SBOM makes the full composition visible and auditable at scale.

A few factors make SBOMs particularly important in this context:

Open-source dependency depth: Data platforms rely heavily on the Apache ecosystem and other open-source projects. Each upstream project carries its own transitive dependencies, which shift with every release.
Sensitive data proximity: Data platforms sit directly on top of, or right next to, regulated and sensitive data. A compromised component in a query engine or streaming broker can expose data at rest or in transit.
Long-running deployments: Enterprise data infrastructure often runs for months or years between major upgrades. Without an SBOM, teams have no reliable way to determine whether a newly disclosed vulnerability affects something already in production.
Multi-tenant environments: In shared data platform deployments, a vulnerability in a shared library can affect multiple teams or business units at the same time.

How does an SBOM help with vulnerability management?

An SBOM gives security scanners a precise list of components to check against vulnerability databases, which makes continuous vulnerability management possible. When a new CVE is published, tools can immediately cross-reference it against the SBOM inventory and determine whether any deployed component is affected, without waiting for a vendor advisory or manually combing through release notes.

The workflow typically looks like this: the SBOM is generated at build time and stored alongside the artifact. A scanner such as Grype, Trivy, or a commercial equivalent ingests the SBOM and queries databases including the National Vulnerability Database (NVD) and vendor-specific feeds. Any match triggers an alert with the component name, version, CVE identifier, and severity score. A VEX document from the vendor can then suppress false positives where the vulnerable code path isn’t reachable in the shipped configuration.

Without an SBOM, this process means either running a scanner against a live container (which may miss statically linked components) or relying entirely on vendor advisories, which are slower and less granular. The SBOM shifts vulnerability detection left and makes it reproducible.

What regulations and frameworks require an SBOM?

Several major regulatory frameworks now explicitly reference or effectively require SBOMs, particularly for software sold to or used within critical infrastructure.

Executive Order 14028 (US context only): The 2021 US executive order on improving national cybersecurity directed federal agencies to require SBOMs from software vendors as part of procurement. That requirement has since influenced commercial procurement practices well beyond the public sector.
Cyber Resilience Act (CRA): The European Union’s Cyber Resilience Act, which entered into force in 2024, imposes security and transparency requirements on products with digital elements sold in the EU market. The CRA’s documentation and vulnerability handling obligations are most naturally satisfied with an SBOM, though the regulation doesn’t mandate a specific format.
NIS 2 Directive: The NIS 2 Directive requires operators of essential services and important entities to implement supply chain security measures. An SBOM supports the component visibility needed to comply with those requirements.
Digital Operational Resilience Act (DORA): For financial entities operating in the EU, DORA requires ICT risk management practices that include third-party dependency tracking, which an SBOM directly supports.

Even where regulations don’t yet mandate SBOMs explicitly, the underlying requirements for supply chain transparency and vulnerability management are genuinely difficult to meet without one.

How do you generate an SBOM for a Kubernetes-native data platform?

Generating an SBOM for a Kubernetes-native data platform means producing component inventories at the container image level and then aggregating them across all the images that make up a deployment. The most practical approach is to generate SBOMs during the container build pipeline, before images are pushed to a registry.

Commonly used tools for SBOM generation include:

Syft: An open-source CLI tool from Anchore that generates CycloneDX or SPDX SBOMs from container images, filesystems, or OCI artifacts. It’s widely used in CI/CD pipelines.
Trivy: A scanner from Aqua Security that combines SBOM generation with vulnerability scanning in a single tool, supporting both CycloneDX and SPDX output.
BuildKit / ko / Dockerfile-based tooling: Some build tools can embed SBOM generation natively as part of the image build step, which is preferable because it captures the exact build-time state.

For a Kubernetes data platform deployment, the recommended approach is to generate and sign SBOMs per image, store them as OCI artifacts in the same registry alongside the image, and use a policy engine such as Kyverno or OPA Gatekeeper to enforce that only images with a valid, signed SBOM are admitted to the cluster. This creates a fully traceable software supply chain from build to runtime.

What’s the difference between a runtime SBOM and a build-time SBOM?

A build-time SBOM captures the components present when a software artifact is assembled. A runtime SBOM reflects what’s actually executing in a live environment. They answer different questions: the build-time SBOM tells you what was shipped; the runtime SBOM tells you what’s running right now, including any modifications that happened after deployment.

Build-time SBOMs are more reliable for supply chain integrity because they’re generated under controlled conditions and can be cryptographically signed. They’re the standard for compliance and procurement purposes. Runtime SBOMs are useful for detecting configuration drift, identifying components loaded dynamically at runtime, or auditing environments where the deployed state may have diverged from the original image.

For most data platform security programs, build-time SBOMs are the right starting point. Runtime SBOM tooling, which typically uses eBPF-based or agent-based observation, adds a second layer of assurance for high-security environments where drift detection matters. The two approaches are complementary, not competing.

Should you require an SBOM from your data platform vendor?

Yes, and increasingly, procurement teams in regulated industries are making it a contractual requirement. Asking a vendor for an SBOM is a reasonable due diligence step, the same kind of step as asking for a penetration test report or a security disclosure policy. A vendor who can’t provide one is signaling limited visibility into their own software supply chain.

When evaluating an SBOM from a vendor, check for:

Coverage depth: does it include transitive dependencies, or only direct ones?
Format: is it machine-readable CycloneDX or SPDX, or a human-readable PDF that scanners can’t ingest?
Freshness: is it generated per release, or is it a one-time document that quickly goes stale?
Signing: is the SBOM cryptographically signed so you can verify it hasn’t been tampered with?
VEX accompaniment: does the vendor also provide VEX documents to clarify exploitability for known CVEs?

For open-source data platforms, you have an additional option: generate the SBOM yourself from the published source code and container images. This is one of the real advantages of open-source software supply chain transparency. You’re not dependent on the vendor’s disclosure timeline, and you can run your own scanners against the public artifacts whenever you need to.

How Stackable supports SBOM and software supply chain transparency

The Stackable Data Platform (SDP) is built with software supply chain transparency as a design principle, not something bolted on later. Because the SDP is 100% open source, every component, operator, and container image is publicly available for independent inspection and SBOM generation. You don’t have to take our word for what’s inside.

Concretely, Stackable provides:

Publicly available container images for all SDP operators and data app images, which can be scanned with Syft, Trivy, or any compatible tool to generate your own SBOMs
Reproducible builds aligned with SLSA principles, so the provenance of each image can be traced back to its source
Release notes and changelogs that document component version changes across SDP releases, supporting your vulnerability management workflow
A Kubernetes-native architecture that works naturally with policy engines like Kyverno, allowing you to enforce SBOM presence as an admission control requirement in your cluster

If your organization needs commercial support for SBOM integration, supply chain auditing, or compliance documentation as part of a CRA, NIS 2 Directive, or DORA program, talk to the Stackable team about what’s possible. You can also explore SDP demos to see the platform’s modular architecture in action before committing to anything.

Apache Kafka® is a registered trademark of the Apache Software Foundation. Apache Spark™ is a trademark of the Apache Software Foundation. All other Apache product names and trademarks are the property of the Apache Software Foundation. Trino is a trademark of the Trino Software Foundation. Use of these names does not imply endorsement by the respective foundations.