An SBOM tool can produce valuable machine-readable evidence, but its output is only as complete as the information and artefacts it can see. Under the Cyber Resilience Act, manufacturers need governed component information that supports wider technical documentation and vulnerability handling.
A file is not the same as component governance
When teams begin preparing for the Cyber Resilience Act (CRA), an obvious first step is to evaluate an SBOM tool, connect it to a build pipeline and generate a machine-readable file. That is useful, but it does not settle the underlying task.
The CRA defines a software bill of materials (SBOM) as a formal record containing details and supply-chain relationships of components included in the software elements of a product with digital elements. Annex I, Part II requires manufacturers to identify and document vulnerabilities and components, including by drawing up an SBOM in a commonly used, machine-readable format covering at least the product's top-level dependencies. Regulation (EU) 2024/2847
That is a defined legal minimum, not a promise that one scan gives a complete picture of every relevant component relationship. Product risk, architecture and the evidence needed to explain the product may justify deeper coverage. The SBOM also sits within a wider set of obligations: technical documentation must cover matters including the product, its design and development, production, vulnerability-handling processes and the SBOM. It must be prepared before the product is placed on the market and updated where appropriate during the support period. Regulation (EU) 2024/2847
What automated tools can and cannot show
Automated generation can analyse source code, package-manager records or build artefacts and turn visible information into an SBOM. This is often highly effective, especially where dependencies are declared through well-understood software ecosystems.
However, each route has a particular vantage point. A source-code scan, a package-manager inventory, a build-artifact analysis and a binary analysis can each reveal different information. CISA's SBOM framing guidance recognises automated lifecycle generation, manual generation for older systems and heuristic analysis of finished software as distinct creation routes. It also distinguishes design, source, build and deployed SBOMs. CISA SBOM Framing
This matters particularly for embedded products. For example, teams may need to confirm the status of:
- firmware supplied with a bought-in modem, wireless chip or sensor;
- proprietary libraries received as binaries from a supplier; and
- patches, drivers and configurations in a customised board support package.
These components may be visible through supplier documentation, a supplier SBOM, engineering records or a particular analysis method. They may not be visible from every source artefact or to every tool. Treating any one automated output as the whole component picture can therefore leave unexamined gaps.
Build the component record around the product
A reliable approach starts with a controlled view of the product and its version, rather than with a single tool output. The engineering record should identify direct dependencies and, where relevant to risk, architecture or evidence needs, deeper dependencies and their relationships. It should also make clear which information has been confirmed, what evidence supports it and what remains unknown.
CISA describes an SBOM as a formal, machine-readable inventory of software components, dependencies, component information and relationships. Its guidance says the inventory should be as comprehensive as possible and should state when relationships cannot be articulated. This is operational guidance rather than the CRA's legal minimum, but it is a useful discipline for handling incomplete visibility. CISA SBOM Framing
An engineering component list maintained from early design can provide a practical basis for this work. It can be updated when a library, module, firmware image or supplier part is introduced, changed or removed. It should not be mistaken for a separate legal format requirement; its value is that it creates traceability between design choices, supplier information, builds and the eventual SBOM.
Use tools as part of a controlled workflow
Tools can create, enrich, compare and validate SBOM information. Their most useful role depends on the product and the available evidence. A practical workflow can include the following controls:
- Define the product boundary, product version and software elements covered.
- Record direct dependencies and determine whether deeper dependencies need to be captured for the product's risk and architecture.
- Obtain and assess supplier evidence for externally provided software, firmware and components.
- Record known limitations and relationships that cannot yet be articulated, rather than silently treating them as absent.
- Produce the required machine-readable SBOM in a commonly used format.
- Compare the component record and SBOM against source, build or deployed artefacts as appropriate, then investigate material differences.
- Connect component information to vulnerability handling, including the product context needed to assess whether a reported vulnerability affects the product.
- Control updates so that the component record, SBOM and technical documentation remain aligned during the support period.
SPDX and CycloneDX are available formats for representing machine-readable SBOM information. Neither format by itself guarantees completeness, vulnerability status or CRA conformity. SPDX specifications CycloneDX SBOM capabilities
Keep vulnerability handling distinct from inventory
An SBOM is important evidence for vulnerability handling, but it is not a vulnerability decision on its own. Assessing whether a product is affected also requires reliable component identity, relevant vulnerability information, product context and analysis.
The CRA requires manufacturers to document a cybersecurity risk assessment and take its outcome into account during planning, design, development, production, delivery and maintenance. It also requires vulnerability handling processes. An SBOM can support these activities, but a scan or an SBOM alone does not establish conformity. Regulation (EU) 2024/2847
An industrial development example
For industrial automation and control system products, IEC 62443-4-1:2018 provides an example of secure product-development lifecycle practice. Its scope includes hardware, software and firmware, and its component-management approach addresses security risks from externally provided components. This can be a useful control model for managing supplier-provided technology and maintaining an inventory for defect management.
The standard is not itself a CRA requirement, and using it does not establish CRA conformity. IEC 62443-4-1:2018
What a reviewer should be able to trace
A reviewer should be able to trace the product and version in scope; the direct dependencies and any deeper coverage chosen; the evidence supporting externally provided software and firmware; declared unknowns and limitations; the machine-readable SBOM; comparisons with relevant artefacts; vulnerability-handling decisions; and controlled updates to the technical documentation.
That traceability is the difference between generating a component file and governing component information throughout the product lifecycle.