What should an EU-ready SBOM pipeline do?

Generate a machine-readable inventory for the exact software artifact you ship, retain its provenance, and connect findings to an owned vulnerability-response process. Capture direct and transitive packages, relevant operating-system and build components, and known blind spots. Treat external APIs as service dependencies to govern—not as libraries that a package scanner can discover. An SBOM supports supply-chain risk management; it does not, by itself, prove CRA or NIS2 compliance.

A software bill of materials, or SBOM, is a structured record of software components and their relationships. Its value appears during a vulnerability disclosure, customer assessment, product update or incident: the team can identify affected releases without manually searching every repository.

The difficult part is not producing a JSON file once. It is establishing which product and artifact the file describes, which build inputs the generator can see, how to detect missing components, who reviews results, and how customers or authorities receive the right information. A pipeline should create repeatable release evidence rather than claim that a scanner has discovered every dependency in every runtime environment.

SBOM readiness checklist for scope, dependency coverage, machine-readable output, provenance and response
Tie every inventory to an identifiable release and an owned response process. Original editorial diagram by FIX Solutions.

Understand the EU obligations before choosing tools

The Cyber Resilience Act (CRA), Regulation (EU) 2024/2847, applies to in-scope products with digital elements made available on the EU market. It places lifecycle cybersecurity and vulnerability-handling obligations on manufacturers. Article 13 requires manufacturers to identify and document vulnerabilities and components in the product, including by drawing up an SBOM in a commonly used, machine-readable format that covers at least the product’s top-level dependencies. The Regulation also specifies how that SBOM is to be provided to market-surveillance authorities on request. The scope, product classification, exceptions and role of a company in the value chain require legal and product-specific assessment.

As of 1 November 2026, the CRA’s vulnerability-reporting obligations have applied since 11 September 2026; its main obligations apply from 11 December 2027. The European Commission published non-binding implementation guidance in July 2026. A pipeline being operational early helps a manufacturer produce evidence and respond, but does not replace the required conformity, vulnerability-handling, documentation and market-surveillance processes.

NIS2 is a separate directive. It establishes cybersecurity risk-management and incident-reporting obligations for entities within its scope, including supply-chain security measures. Its application depends on the sector, entity and applicable national implementing law. NIS2 does not impose a universal SBOM-generation duty on every organization. SBOMs can support supplier and vulnerability-risk management where appropriate, but they are one possible evidence input—not a substitute for an organization’s required risk-management program.

The European Commission’s CRA policy and implementation page, its CRA implementation FAQs, and the NIS2 Directive are useful starting points. Applicability, reporting duties and national implementation should be confirmed with counsel and the organization’s product-security and compliance owners.

Define what the SBOM covers

Before automating generation, write down the product boundary. A deployable application may include source packages, private libraries, a runtime, an operating-system base image, vendor binaries, plugins, firmware or optional features. Separate what is known to be included from dependencies pulled in only in particular deployment profiles.

Capture at minimum:

  • Product, version and release identifier.
  • Component name and version, with identifiers such as package URLs where supported.
  • Supplier or origin when known.
  • Dependency relationships, including transitive paths.
  • File or artifact hashes where available and useful for identification.
  • SBOM format, generator, creation time and the build or source revision.
  • Any known exclusions, unresolved identities or coverage limitations.

A package manifest records declared dependencies; it does not necessarily describe the resolved dependency tree or what shipped. Lock files, the actual build graph and image layers provide complementary evidence. Dynamic plugins, downloaded models, optional modules, generated code and files copied into an image outside the package manager can remain invisible to a single manifest-based tool.

Separate source-build and deployed-artifact views when they answer different questions. A source SBOM helps developers identify the application dependency graph. A container or binary SBOM can reveal operating-system packages and embedded components in the release image. Retain the association between each inventory and the immutable artifact digest rather than treating an SBOM named “latest” as release evidence.

Distinguish software components from API and supplier dependencies

An API endpoint is not automatically an open-source package or a component embedded in the binary. Static package scanning will not discover every external service an application calls at runtime. Maintain an API and service dependency inventory alongside the SBOM: provider, service purpose, data exchanged, authentication method, owner, criticality, region, contract and fallback behavior.

Where the chosen BOM format supports services and relationships, include relevant service dependencies in an appropriate BOM model or link the SBOM to the separate service catalog. Do not invent a software package version for an API. Capture API specifications, such as an OpenAPI document, with a version or digest where practical; an API specification describes an interface, not all the software that implements the service.

This distinction improves both coverage and ownership. Developers can scan packages and images; platform and procurement owners can validate externally operated services; architects can review which business workflows depend on those services.

Build the pipeline at the artifact boundary

Use the build system to produce the SBOM for each releasable artifact. A practical pipeline has five stages:

  1. Resolve inputs. Check out a recorded commit, use lock files, pin the build environment and record approved repositories and tool versions.
  2. Generate component inventories. Use package-manager metadata for resolved libraries, then scan built images or binaries for relevant operating-system and embedded components.
  3. Normalize and validate. Select an interchange format and schema version accepted by downstream tooling; validate syntax, identities, relationships and expected product metadata.
  4. Compare and triage. Check policy for prohibited or unapproved components, missing licenses or ownership, stale versions and known vulnerability matches. Give findings to the owning team for context.
  5. Bind evidence to the release. Store the SBOM beside the artifact, keyed by immutable digest and release ID. Protect integrity and access, and publish or provide it through the approved customer and authority channels.

For illustration, a team might generate a CycloneDX inventory from a language package graph, then separately scan a final container image for operating-system components. Tools such as Syft, Trivy, cdxgen and package-manager-native exporters can help with specific ecosystems, but their inputs and detection behavior differ. Test the chosen version against representative builds and manually inspected ground-truth samples before depending on its output.

Use CycloneDX or SPDX according to customer, regulator and tool requirements. Confirm the exact version, supported fields, relationships and data-exchange expectations with consumers. A valid document can still omit important dependencies or describe the wrong artifact.

Make generation repeatable and fail visibly

Run generation as part of normal release automation, not as a separate task someone remembers before an audit. Pin generator versions, record configuration, make failure visible and assign an owner for schema or tool updates. If generation fails, retain the build logs, block a release when the risk policy requires it and provide a documented exception path with an accountable approver and expiry.

Avoid silently producing an empty or partial SBOM when a package registry is unavailable. Distinguish “no components found” from “generation failed” and “components could not be resolved.” A pipeline should report which sources it examined and which could not be accessed.

Protect the artifact. SBOMs can reveal product composition and vulnerable components. Apply access controls, retention and integrity protections appropriate to its use. Avoid placing private package URLs, credentials or sensitive build paths in a document distributed to every customer.

Preserve provenance and change history

An SBOM is most useful when a responder can establish who created it, for which build and from which source and tool versions. Store the source revision, build run, artifact digest, generator identity and creation time. Sign or attest release metadata using the organization’s trusted build and artifact-signing process; a signature establishes integrity and origin only to the extent that the signing identity and process are trustworthy.

Retain a versioned inventory per release. Do not overwrite the SBOM for a previously shipped artifact when a new release is built. When a vulnerability advisory arrives, the incident team needs to know what customers actually received, not merely the current branch.

Keep exception handling explicit. If a proprietary binary lacks component metadata, record the supplier, product version and unresolved coverage, then pursue an attestation or inventory from the supplier. Do not represent an unknown dependency as an empty component list. Establish a reassessment date and owner.

Connect SBOMs to vulnerability response

Generation is only the first half of the workflow. Load SBOMs into an approved vulnerability or asset platform, correlate components with relevant advisories, and notify the responsible product team. Check the exact release and dependency path, then assess whether the affected code is present and reachable under the deployed configuration. A vulnerability match is a finding to investigate, not an automatic exploitability conclusion.

Track decisions through remediation: upgrade, replace, mitigate, document an assessed exception with an owner and review date, or confirm that the product is not affected with supporting rationale. A VEX statement can communicate a product-specific assessment of vulnerability exploitability in supported formats; it does not replace the component inventory or the investigation itself.

Exercise a response drill using a known test component or controlled advisory scenario. Ask the team to identify affected releases, owners, customers who may require notification, and the next update or mitigation. Measure time to identify and verify exposure, not just how quickly the scanner completed.

Check coverage without promising “every dependency”

Define a coverage test for each release family. Compare the SBOM against lock-file graphs and the resolved build output. Inspect base-image package lists. Sample binaries or image layers using independent tools where warranted. Ask teams to identify private packages, vendored code, plugins and network-loaded components. Track unresolved or excluded components in the release record.

Use a controlled canary repository containing known direct, transitive, development and operating-system dependencies to verify that pipeline changes are still detected. When tools or ecosystems change, repeat the test. A scanner update may improve detection or alter component identifiers, so compare output before changing release policies.

Report coverage as a bounded statement: sources scanned, product profiles included, components resolved, and known blind spots. No automated scanner can guarantee that it has discovered every component that might execute in every possible product configuration.

A practical adoption plan

Weeks 1–2: determine product and legal scope. Identify products placed on the EU market, organization roles, software boundaries, CRA classification questions, NIS2 applicability and customer requirements. Ask legal and product-security owners to validate assumptions.

Weeks 3–4: inventory build sources. Map repositories, package managers, build pipelines, images, vendor binaries and external service dependencies. Select a representative product family.

Weeks 5–6: prove artifact matching. Generate source- and artifact-level SBOMs for development builds and releases. Validate against known dependencies and link each output to a release digest.

Weeks 7–8: connect response and distribution. Define who reviews findings, communicates with suppliers and customers, responds to authority requests, and maintains records. Run a tabletop exercise.

Expand only when teams can maintain the output, triage the findings and answer questions about completeness. The tool rollout is not complete until the response and ownership model works.

Frequently asked questions

Does NIS2 require every company to publish an SBOM?

No. NIS2 imposes cybersecurity risk-management and supply-chain measures on entities within scope under applicable national law; it is not a blanket rule that every company must publish an SBOM. The CRA has its own product-manufacturer obligations. Confirm which rules apply to the organization and product.

Does an SBOM automatically prove CRA compliance?

No. It is one part of product-component transparency and vulnerability handling. Conformity and other lifecycle obligations include more than generating a document, and applicability depends on the specific product and role.

Can a scanner guarantee that every dependency and API is captured?

No. A scanner only sees the inputs it can inspect. Build graphs and artifact scans improve coverage, while external services need separate inventory and ownership. Record gaps and test detection with known components.

Sources and further reading

For an SBOM implementation, begin with a representative build, a defined release boundary and a response owner. FIX Solutions’ IT development services can help plan the build and verification workflow.