According to Omdia’s 2026 software supply chain security report, 86% of organizations find SBOM generation challenging. A major driver is tool sprawl: teams cobbling together different scanners for different artifact types, getting inconsistent output across pipelines, and spending engineering time reconciling the results rather than acting on them.

SBOMs have become important to how security teams respond to vulnerability disclosures, how compliance teams satisfy auditors, and how procurement decisions get made. That makes the generation step load-bearing. If the SBOM your pipeline produces misses transitive dependencies, records declared versions instead of resolved ones, or is not cryptographically bound to the artifact it describes, every downstream decision built on that data inherits the gap.

This post covers the decisions that determine SBOM quality: when and where to generate, what separates actionable output from data that just checks a box, and how to keep generation reliable as your image portfolio grows.

When to generate: Build-time vs. post-build

The single decision that most affects SBOM quality is when you generate it. There are two broad approaches, and they produce meaningfully different results.

Build-time generation

Build-time generation hooks into the build system itself. The generator has access to the resolved dependency tree, the package manager files, and the full build context. It knows exactly what went into the artifact because it was present when the artifact was assembled.

Container build systems with native attestation support can produce an SPDX SBOM during the image build, attach it as an in-toto attestation, and push both the image and the SBOM to the registry in a single operation. Language-specific build plugins take a similar approach for application dependencies, generating SBOMs as part of the standard build lifecycle.

The advantage is structural: build-time generation captures the resolved state of every dependency, including transitive dependencies that post-build scanners may miss.

Post-build scanning

Post-build tools scan a finished artifact and reverse-engineer its contents. They work by identifying package manager metadata, file signatures, and known patterns within the artifact. This approach works on any OCI-compatible image, regardless of how it was built.

The trade-off is coverage. Statically linked binaries, vendored dependencies, and OS packages installed in intermediate build stages may commonly be missed by post-build scanners. The scanner can only report what it can detect, and detection is heuristic-based rather than derived from the actual build graph.

For container images, our documentation covers how to configure build-time SBOM attestation in detail, including the specific flags and generator options for different build workflows.

What makes an SBOM useful

Generating an SBOM is not the same as generating a useful one. The file format is standard, but the quality of the content varies dramatically depending on how and when the SBOM was produced. Five criteria separate actionable SBOMs from checkbox artifacts.

1. Completeness

A complete SBOM accounts for every component in the artifact across all layers and all package types. This includes OS packages from the base image, application dependencies from every package manager in the build, and any tooling or utilities added during the build process. 

This is where multi-stage and minimal base images create real gaps. A Dockerfile with a Node frontend, a C or C++ component compiled into a static binary, and a distroless final stage presents three distinct challenges: the Node layer has deep transitive dependency trees, the statically linked binary often carries no dependency manifest on disk, and the distroless base has no package manager at all. Post-build scanners can miss the statically linked dependencies and may undercount the Node tree. Build-time generation with access to each stage’s resolved dependency graph is the only way to get a complete picture.

2. Accuracy

Accuracy means the SBOM records resolved versions, not declared ranges. A package manifest might declare “^4.17.0” but the resolved version in the lock file is 4.17.21. The SBOM must reflect what was actually installed, not what was requested.

3. Freshness

An SBOM is a point-in-time snapshot tied to a specific build. Every time the artifact is rebuilt, the SBOM should be regenerated. Stale SBOMs create a false sense of visibility.

4. Verifiability

A verifiable SBOM is one that consumers can confirm was produced by the build system and has not been tampered with. Cryptographic signing and attestation frameworks bind the SBOM to a specific artifact digest, along with build provenance that records where and how the artifact was built.

5. Format compliance

Standard formats like SPDX and CycloneDX define required and optional fields. An SBOM that validates against the schema is interoperable across scanning tools, policy engines, and compliance workflows. One that does not may work with your current tools but will break when you change them.

Some base images already ship with SBOMs that meet all five criteria, along with SLSA Build Level 3 provenance and exploitability data. These SBOMs were generated at build time on hardened build platforms with non-falsifiable provenance, cryptographically signed, and attached as in-toto attestations bound to the image digest. They are continuously regenerated with every rebuild, so freshness is maintained without manual intervention. For those images, the generation question is answered for the most critical layer of the stack, and your effort shifts to generating a complete SBOM for the application layer you add on top.

Your generation toolchain is attack surface

The tools you use to generate SBOMs run with elevated access to your build environment. They read your source code, your dependency trees, and your build artifacts. A compromised generator does not just produce bad output; it has the access to exfiltrate or modify what it scans.

This is not a theoretical concern. Version tags on GitHub Actions and container images are mutable. A tool you pinned to v2.1 today can silently become something different tomorrow if a maintainer account is compromised or a tag is force-pushed. The exposure window for incidents like these is typically measured in hours, but automated pipelines can pull compromised versions within minutes.

Treat your generation tooling with the same rigor you apply to any other build dependency:

• Pin to immutable references (commit SHAs, not version tags).
• Verify checksums before execution.
• Run generation in CI, not on developer machines, for reproducible and auditable output.
• Monitor for upstream security advisories on your generation tools.

This is one dimension of a broader software supply chain security challenge: every tool in your pipeline is a dependency that needs the same scrutiny as your application code. For base images, you can sidestep this risk entirely. Images built on hardened build platforms with non-falsifiable provenance carry their supply chain metadata from the point of origin, cryptographically verified end-to-end.

Integrating SBOM generation into CI/CD

Manual SBOM generation works for one-off audits. For production workflows, generation needs to be automatic, reproducible, and wired into the rest of your delivery pipeline. The pattern is consistent across CI systems.

Generate at build

Add SBOM generation as a build stage step, immediately after the image is produced. For container images, BuildKit attestation flags are the most reliable approach. For application dependencies, language-specific plugins (CycloneDX for Maven/Gradle, npm/yarn for Node) produce the highest-quality output because they access the resolved dependency graph.

For multi-stage builds, generate from the final stage only. Intermediate stages often install build tools and test frameworks that do not ship in the production image. Generating against intermediate stages inflates the SBOM with components that are not deployed, creating noise in vulnerability scans.

Choose an attestation format

SPDX is the native output format for BuildKit attestation and the stronger choice if license compliance is a primary concern. CycloneDX has richer vulnerability correlation support and more granular component classification, making it the better fit for security-focused workflows. If your consumption tools (policy engines, vulnerability scanners, compliance dashboards) have a preference, follow it. If they support both, default to SPDX for container images since it requires no additional tooling beyond BuildKit’s built-in generator.

Attach to the artifact

Store the SBOM alongside the artifact it describes. For container images, this means attaching it as an OCI attestation in the registry rather than saving it as a separate file in an artifact store. Attestation-based storage keeps the SBOM discoverable, versioned, and bound to the specific image digest. When the image is promoted from dev to staging to production, the SBOM travels with it through every registry, rather than requiring a separate copy-and-sync workflow that inevitably drifts.

Validate before publishing

Add a validation step between generation and registry push. Run the SBOM through a format validator (SPDX and CycloneDX both provide official schema validators), check that the component count is reasonable for the artifact, and verify that the SBOM references the correct image digest. A build that produces 12 components for an image you know contains 200+ packages should fail the pipeline, not ship silently.

Scan and enforce continuously

SBOM generation at build time captures what’s shipped. Continuous scanning tells you what’s become vulnerable since. New CVEs drop daily, and an SBOM that was clean at build time can have critical exposures within weeks. Continuous analysis against SBOM data matches new disclosures against your inventory without re-pulling images, and surfaces policy violations as they emerge. With SBOMs attached to every image, you can gate deployment: no image ships without a valid SBOM, no image deploys with a known-vulnerable package above your severity threshold.

Implementation details vary by CI system. Our documentation covers the specific flags and configuration for generating and attaching SBOM attestations across common container build workflows.

Verifying your SBOM output

Before relying on your SBOM output for compliance reporting or vulnerability management, verify that it meets the quality criteria below.

• Component count sanity check: Compare the number of components in your SBOM against what you expect from the Dockerfile, lock files, and base image. A Node.js app with 200 declared dependencies should produce substantially more entries once transitive dependencies are included.
• Resolved versions, not ranges: Spot-check entries to confirm the SBOM records specific versions (4.17.21) rather than declared ranges (^4.17.0).
• Transitive dependency depth: Verify that transitive dependencies appear, not just top-level packages. If your app declares 30 direct dependencies but the SBOM contains 32 entries, transitive coverage is likely incomplete.
• OS package coverage: Confirm that base image OS packages appear alongside application dependencies.
• Digest binding: Verify the attestation references the correct image digest. An unbound SBOM cannot be trusted to describe its artifact.
• Format validation: Run the SBOM through a schema validator (SPDX and CycloneDX both provide official tools).

Start generating, then start verifying

The best time to add SBOM generation to your pipeline is the next time you touch your CI configuration. Start with your highest-traffic production image. Configure build-time generation, attach the SBOM as an attestation, and validate the output against the checklist above. Then expand to the rest of your portfolio.

If you want a head start, Docker Hardened Images ship with complete SBOMs, SLSA Build Level 3 provenance, and OpenVEX data already attached, so you can skip the generation step for your base layers entirely. For everything you build on top, Docker Scout provides continuous vulnerability matching against your SBOM data and enforces policies across your image portfolio.

• Get started with Docker Hardened Images →
• Explore vulnerability monitoring with Docker Scout →

Frequently asked questions

Sources

Omdia, Securing the Software Supply Chain: Strategic Approaches to Support Scaling Development with AI Adoption, May 2026.

The EU Cyber Resilience Act (CRA) was officially introduced on December 10th 2024, to protect foundational EU values in the face of rising cyberattack threats. As cyberattacks targeting products with digital elements have grown more frequent and costly, the regulation establishes the first horizontal cybersecurity baseline for all hardware and software products sold in Europe. The urgency is real given that in Omdia’s 2026 software supply chain security report, 77% of organizations reported experiencing a supply chain incident in the last year.

The regulation will take full effect on December 11, 2027, but mandatory vulnerability reporting obligations take effect on September 11, 2026. For teams building and shipping containerized software, the CRA turns practices like SBOM generation, vulnerability disclosure, and image hardening from voluntary best practices into legal requirements.

This guide covers what the EU CRA requires, who it applies to, how its SBOM mandate connects to container build workflows, and what teams need to do before the compliance deadlines arrive.

What is the EU Cyber Resilience Act (CRA)?

Before the CRA, the EU had no single, cross-sector regulation setting cybersecurity baselines for  products with digital elements. A smart thermostat, an enterprise database, and a container runtime were all subject to different (or no) cybersecurity obligations. There was no general obligation to patch vulnerabilities, disclose security incidents, or document the software of products with digital elements launched in the EU market. The CRA closes that gap with a horizontal regulation that applies across several industries, placing the primary burden on manufacturers.

The regulation defines a product with digital elements as any software or hardware product, including its remote data processing solutions and any components placed on the market separately. That scope is intentionally broad: it covers everything from consumer IoT devices to enterprise software platforms to container images distributed through registries. Manufacturers must design products securely, handle vulnerabilities throughout the product lifecycle, and provide transparency about software composition.

How the CRA relates to NIS2

The CRA is one part of the broader EU cybersecurity strategy that includes other regulatory frameworks, like NIS2 and DORA. Since the CRA and NIS2 both deal with cybersecurity obligations, they’re easy to conflate, but they target different things. The CRA applies to cybersecurity of products with digital elements, while NIS2 applies to the cybersecurity of essential and important entities.

Recital 12 of CRA even affirms that SaaS, PaaS, or IaaS solutions are subject to NIS2, in principle carving them out of its own scope. However, the line is blurry for products depending on cloud infrastructure.

The European Commission’s March 2026 draft guidance introduced a three-part test for determining when a cloud component falls under CRA scope:

1. Does the processing happen remotely?
2. Would the product lose a core function without it?
3. Did the manufacturer design, develop, or is control of that remote component under its responsibility?

If the answer to all three is yes, the cloud component is part of the product for CRA purposes. Where that test pulls a cloud component into scope and the component processes personal data, the GDPR applies on top of the CRA rather than in place of it, so you still need to assign controller and processor roles and confirm a lawful basis.

Who the CRA applies to

The CRA assigns obligations based on your role in bringing a product to market.

Key requirements for the EU CRA

The CRA organizes its requirements into two main areas, both defined in Annex I of the regulation: essential cybersecurity requirements for product properties, and vulnerability handling obligations for the product lifecycle.

Security by design

Products must be designed, developed, and produced to ensure an appropriate level of cybersecurity based on a risk assessment. In practice, this means shipping with secure default configurations, minimizing the attack surface by removing unnecessary components, protecting the confidentiality and integrity of stored and transmitted data, and providing mechanisms for secure updates.

For container images, the security-by-design requirement maps directly to image hardening:

• minimal base layers
• no unnecessary shells or package managers
• secure defaults out of the box.

The essential requirements also include data minimization: a product should process only personal or other data that is adequate, relevant, and limited to what is necessary for its intended purpose.

Vulnerability handling

Manufacturers must maintain processes for identifying, documenting, and remediating vulnerabilities throughout the support period they define for each product. This includes coordinated vulnerability disclosure policies, timely security updates, and public disclosure of fixed vulnerabilities with enough detail for users to assess impact and apply remediation.

Security updates must be provided free of charge for the duration of the support period. Public disclosures should be limited to the technical detail users need and must not expose personal data, such as the identity of a reporter or of affected users, consistent with the CRA’s expectation that disclosures avoid increasing risk and with GDPR limits on publishing personal data.

Transparency and SBOMs

The CRA also requires manufacturers to include a software bill of materials in the technical documentation for every product with digital elements. The SBOM must be in a commonly used, machine-readable format and must include, at minimum, the top-level dependencies of the product. However, the regulation does not mandate a specific format, but in practice that typically means SPDX or CycloneDX.  Scope the generated SBOM to package and dependency metadata and keep embedded secrets and personal data out of the artifact.

An important nuance: The CRA does not require manufacturers to publish SBOMs publicly. SBOMs must be included in technical documentation and provided to market surveillance authorities on request. Also, the documentation must be retained for ten years after the product is placed on the market, or for the duration of the support period, whichever is longer.

Incident and vulnerability reporting

Manufacturers must report actively exploited vulnerabilities and severe security incidents to the relevant national Computer Security Incident Response Team (CSIRT) and to ENISA through a single reporting platform. The reporting timelines are:

Note for Privacy: These reports can contain personal data, such as a reporter’s identity or affected-user details, so limit each report to the technical information the CSIRT and ENISA actually need and handle any personal data in line with the GDPR.  Notifications should also avoid disclosing information that would increase risk to users.

Conformity assessment

Before placing a product on the EU market, manufacturers must complete a conformity assessment to verify compliance with the essential cybersecurity requirements. The type of assessment depends on how the product is classified under the CRA.

Product categories and conformity assessment

The CRA classifies products into three tiers based on their cybersecurity risk, with each tier subject to increasingly rigorous conformity assessment procedures.

If you’re shipping container runtimes, you likely fall into the Important Class II category and will need a third-party assessment. Products that pass their conformity assessment receive the CE marking, which indicates compliance with the CRA and allows them to be sold on the EU market. Products that fail, or that are found to be non-compliant after placement, can be ordered withdrawn or recalled by national market surveillance authorities.

CRA timeline: 3 Deadlines that matter

The CRA entered into force on December 10, 2024, but its obligations phase in over three years. Each milestone introduces a distinct set of requirements.

The key detail most teams miss: the September 2026 reporting obligation is applicable to products that are already in the market. It retroactively applies to products already on the EU market, not just new releases. If you are selling container images to EU customers today, your 24-hour reporting clock starts in months, not years.

Penalties for non-compliance

Article 64 of the CRA establishes three penalty tiers for non-compliance, with fines set at the member-state level but capped by the regulation:

• Up to €15 million or 2.5% of global annual turnover (whichever is higher) for failure to comply with essential cybersecurity requirements and other core obligations (Art. 64 (2)) 
• Up to €10 million or 2% of global annual turnover (whichever is higher) or failure to comply with other CRA obligations (Art. 64 (3))
• Up to €5 million or 1% of global annual turnover (whichever is higher) for supplying incorrect, incomplete, or misleading information to authorities (Art. 64 (4))

Beyond fines, market surveillance authorities can order product withdrawals, recalls, or outright bans from the EU market. For organizations selling software products into the EU, losing market access is often a more significant consequence than the fine itself.

Open-source software and the CRA

The CRA’s treatment of open source was one of the most debated aspects during the legislative process. The final text draws a clear line based on commercial activity.

Free and open-source software that’s not used in the course of a commercial activity, either directly or through support, is outside the CRA’s scope. Individual developers and volunteer maintainers are not classified as manufacturers under the regulation, as long as they operate outside a commercial activity. And the CRA explicitly does not apply to open-source software supplied for distribution outside the scope of a commercial activity.

However, the regulation introduces a new role: the open-source software steward. 

A “steward” is a legal person (a company or foundation, not an individual) that systematically supports the development of open source software intended for commercial activities. The CRA applies a light-touch regime for stewards with limited obligations. They must mainly:

1. Maintain a cybersecurity policy.
2. Report actively exploited vulnerabilities.
3. Cooperate with market surveillance authorities. 

Critically, stewards are not subject to financial penalties for CRA infringements.

Organizations that distribute open-source software under a commercial model, whether through paid support or commercial container image registries, are classified as manufacturers, not stewards. The distinction matters because manufacturers carry the full weight of CRA obligations, including conformity assessment and CE marking.

What the CRA means for container teams

Everything above applies to the full universe of digital products. Here’s where it gets specific. Container images and runtimes distributed commercially into the EU qualify as products with digital elements under the CRA. If your organization publishes container images in a registry that EU customers can pull from, and those images are part of a commercial offering, the CRA applies and you may be considered a manufacturer. This is true regardless of where your organization is headquartered.

The practical implications span the entire container lifecycle:

• Image composition transparency: Every image needs a machine-readable SBOM that documents at least the top-level dependencies. Image-layer SBOMs generated at build time, which capture OS packages, runtime libraries, and transitive dependencies, go further than the CRA’s minimum.
• Vulnerability management: Organizations must have processes to track, remediate, and report vulnerabilities in the components their images contain. Starting September 2026, all vulnerability and incident reporting obligations listed in Article 14 come into effect.
• Security by design: Images should ship with minimal attack surfaces, secure default configurations, and no unnecessary components. Hardened base images with shells, package managers, and debug tools removed satisfy this requirement more directly than standard community images.
• Provenance and integrity: The CRA’s essential requirements include protecting the integrity of the product and verifying that components have not been tampered with. Cryptographic signatures and provenance attestations address this directly.
• Support periods: Manufacturers must define and communicate a support period during which they will handle vulnerabilities. For container images, that means committing to a patch and rebuild cadence for the lifecycle of each supported image tag.

Compliance starts at the image layer

The CRA raises the bar for every organization that ships software into the EU. For container teams, the requirements map directly to practices the industry has been moving toward: hardened images, build-time SBOMs, provenance attestations, vulnerability monitoring, and defined support lifecycles. The difference is that these practices are no longer optional.

Thankfully, Docker Hardened Images ship with the artifacts the CRA demands: complete SBOMs, SLSA Build Level 3 provenance with non-falsifiable attestations, OpenVEX exploitability data, and cryptographic signatures. The images are minimal by default, continuously rebuilt against upstream fixes, and backed by defined support periods. Pair that with continuous vulnerability monitoring against SBOM data limited to package and component metadata and excluding personal data and embedded secrets, and the CRA’s 24-hour reporting clock starts with a known blast radius rather than a manual triage.

• Get started with Docker Hardened Images →
• Explore vulnerability monitoring with Docker Scout →

Frequently asked questions

Source

Omdia, Securing the Software Supply Chain: Strategic Approaches to Support Scaling Development with AI Adoption, May 2026.