Which SBOM tools support SBOM tools for CRA compliance today
A customer or contract asking for an SBOM is asking for something the Cyber Resilience Act already requires manufacturers to produce: a software bill of materials in a commonly used, machine-readable format covering at least the top-level dependencies. Open-source tools such as Trivy and OWASP Dependency-Track can generate that SBOM and then track the components in it against known vulnerabilities. Trivy identifies OS packages and software dependencies in a target and can output them as an SBOM, and it can also scan an existing SBOM. Dependency-Track consumes and produces CycloneDX SBOMs and VEX, flags vulnerable, outdated or modified components and license risk, and applies policies per project. The right pairing depends on your build pipeline, the product's class and who receives the SBOM. A container-based product built in CI has different generation needs from a firmware image, and a SBOM kept only for market surveillance authorities needs less distribution plumbing than one sent to customers.
Before choosing, confirm the SBOM format with your own review, since the Commission can specify the format and elements by implementing act under Article 13(24) and no such act appears in its implementation timeline as updated on 27 July 2026. Check the Commission's CRA implementation page for changes. Ask whether the tool's output round-trips into the other tools you use and whether it records the supply chain relationships the regulation defines. Ownership stays with your organization: you own the SBOM and the technical documentation that contains it, and you decide whether to share it with users. A partner can wire these tools into your pipeline and prepare the evidence, but neither a tool vendor nor an implementation partner issues a conformity report or certificate. That role belongs to the conformity assessment route your product class requires.
What SBOM tooling and related work costs
This table breaks down the cost components of producing and using a CRA software bill of materials, showing who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to structure quote requests, since open-source tool licenses are not the main expense. The main takeaway is that engineering integration, hosting and finding triage usually cost more than the tools themselves.
| Cost component | Who is paid | One-time or recurring | What drives the cost |
|---|---|---|---|
| Open-source generator licenses (for example Trivy, Apache-2.0) | No license fee to the project; any commercial support contract is paid to the vendor | Recurring only if you buy support | Whether you need vendor support, indemnity or an SLA |
| Hosting the vulnerability-tracking platform (for example OWASP Dependency-Track, Apache-2.0) | Your cloud or data center provider, and staff or a partner who operate it | Recurring | Number of products and components, retention period and availability needs |
| Engineering time to integrate SBOM generation into CI and build pipelines | Internal engineers or a partner under a scoped statement of work | One-time, plus upkeep when build systems change | Number of build pipelines, languages and artifact types in scope |
| Configuring SBOM format output and component identifiers | Internal engineers or a partner | One-time, with periodic review | Choice of CycloneDX or SPDX output and how many product lines must match |
| Staff time to triage vulnerability findings and document decisions | Your product security or PSIRT staff | Recurring for the support period | Volume of findings, quality of exploitability data and policy tuning |
| Partner fees for scoped implementation and evidence preparation | The implementation partner, under a written quote | One-time, with optional retainer for ongoing support | Agreed scope, number of products and integration complexity |
| Retaining SBOMs as technical documentation for the support period | Your own storage and records owners | Recurring | Number of product versions and how long records must be kept |
How SBOM generation and tracking tools differ
SBOM tools for CRA compliance fall into a few distinct jobs: producing an inventory from a build or target, tracking that inventory against vulnerability data over time, checking licenses, and wiring both into the build. Each category needs different inputs and produces different outputs, so a single tool rarely covers the whole chain on its own.
Inventory generators
Generators read a target and list what it contains. Trivy identifies the OS packages and software dependencies in use in a target and can produce them as a software bill of materials. It can also scan an existing SBOM, which helps when a supplier hands you one. Feed it a container image, filesystem or repository. Check which SBOM formats it writes today against the format your technical documentation will use, since the CRA leaves the format open for now.
Component trackers
OWASP Dependency-Track (Apache-2.0) consumes SBOMs and produces CycloneDX SBOMs and VEX. It identifies components with known vulnerabilities, outdated or modified components and license risk. Its job starts after generation: you upload SBOMs for each product release, keep them over the support period, and review findings against them. Confirm which CycloneDX and VEX versions your installed release reads and writes before you commit to a format.
Vulnerability source correlation
Tracking quality depends on the advisory sources a tracker queries. Dependency-Track correlates components against sources including the NVD, GitHub Advisories, Sonatype OSS Index, Snyk, Trivy, OSV and VulnDB. Ask which sources your deployment can reach, whether any require credentials or paid access, and how often the data refreshes. Findings from a source you never configured are findings you will miss.
License compliance checks
License checks answer a different question from vulnerability checks: can you legally ship and redistribute each component? Dependency-Track tracks license use by component using SPDX license IDs, so license data needs normalizing to SPDX identifiers before it is compared. Define a policy for which licenses need review, and record decisions with the SBOM. Confirm with your legal team how they want license evidence presented in technical documentation.
Policy and VEX triage
Policies decide which findings block a release. Dependency-Track applies global and per-project policies for security, license and operational compliance, and it can consume VEX statements that record whether a vulnerable component is actually exploitable in your product. Triage with VEX reduces noise, but each not-affected statement needs a documented justification that an assessor can read. Decide who signs those statements before the first release.
Build pipeline integration
Integration decides whether SBOMs are produced for every release or only when someone remembers. Run the generator as a build step, publish the output as a pipeline artifact, and upload it to the tracker automatically. Store each SBOM against its product version so the evidence matches what was shipped. Test the pipeline on a release candidate, because a broken upload at release time leaves a gap in the record.
Which setup fits your product and team
A software vendor with one product and a working CI pipeline can usually generate the SBOM at build time, so every release carries a record of the components it shipped. The pipeline is the natural place to run the generator because it sees the exact dependency tree that gets packaged. Review typically sits with the product security lead, who triages new findings against the release and decides which ones need a fix in the support period. Illustrative example: a team tags a release, the pipeline produces a CycloneDX file, and the file is stored with the technical documentation for that version.
- Generate at build time: Run an SBOM generator as a pipeline step so each release has its own file, not a copy from months earlier.
- Cover the top-level dependencies at minimum: Annex I requires at least top-level dependencies, so check that transitive coverage is at least what your tool can reliably produce.
- Scan the artifact, not only the repository: Container images and packaged binaries can carry components that the source manifest does not show.
- Keep a versioned archive: Store each SBOM with the release it describes so you can produce the right file for an authority request.
- Assign triage ownership: Name who reviews new vulnerability matches and records the decision.
Before relying on this setup, confirm with your team that the generator output is machine-readable in the format you choose and that the archive can be retrieved within the time you would need to answer a reasoned request.
An enterprise with many products and many suppliers has a different problem: the SBOMs come from several teams, several build systems and some vendors who may send their own files in different formats. The central task is consistency, so that a component appearing in five products is recognized as the same component everywhere. A central platform or product security team usually owns the aggregation and the vulnerability correlation, while each product team owns the accuracy of its own SBOM. Illustrative example: a shared Dependency-Track instance receives SBOMs from twenty product pipelines and flags a library vulnerability across all of them in one view.
- Standardize the output: Agree on one format and one set of required fields before teams start generating, so the central view is usable.
- Centralize correlation, not generation: Let product teams produce files and let a central service match components against advisories.
- Track supplier SBOMs separately: Mark which components came from a supplier so their accuracy is reviewed by a named owner.
- Set per-product policies: Apply different alert thresholds to products by risk class rather than one global rule.
- Define who answers authorities: Record which role can retrieve and send an SBOM for each product on request.
Confirm with your supplier contracts what SBOM content and format you can require, because a file you cannot obtain from a supplier leaves a gap in your own technical documentation.
Embedded and industrial products combine vendor firmware, open-source operating system layers, bootloaders and sometimes components that were never built in your own pipeline. The SBOM has to cover the firmware image as shipped, which often means analyzing a binary rather than reading a source manifest. Review involves engineering and security staff together, because a finding on a bootloader component may require a hardware or update decision, not only a library upgrade. Illustrative example: a controller vendor scans the firmware image after the final build and compares it with the component list from its toolchain.
- Analyze the shipped image: Scan the firmware image or root filesystem so the SBOM reflects what devices actually run.
- Reconcile with the build: Compare the image scan against the build manifest to catch components added by the packaging step.
- Record supplier binaries: Components supplied as closed binaries need their origin and version recorded, even when their source is unavailable.
- Plan updates per device family: Link each component to the update path for the devices that carry it, since remediation may need field updates.
- Prepare for long support periods: Keep the SBOM for each shipped variant so older units remain traceable.
Confirm which of your products fall into the important or critical categories before you choose a setup, because the conformity route affects how much evidence the file must support.
Open-core companies and individual maintainers often ship a mix of open-source code they publish and commercial extensions they sell. The SBOM question is where the boundary sits: which components are part of the product you place on the market, and which are only in your development environment. Small teams usually have no separate security function, so the generator should run with little manual effort and the findings should reach whoever maintains the release. Illustrative example: a maintainer runs a free command-line scanner on each tagged release and publishes the output alongside the source archive.
- Define the product boundary: Decide which packages make up the distributed product before generating, so the SBOM matches what users receive.
- Use a lightweight generator: Open-source scanners that run from the command line or a single pipeline step suit small teams with limited time.
- Decide whether to publish: Sharing the SBOM with users is optional, so decide whether to make it available and state that in user information.
- Route findings to a named maintainer: Avoid alerts that no one owns, since unanswered findings are the most common gap in small projects.
- Keep the file for authorities: Even when you publish nothing, store the SBOM so it can be provided to a market surveillance authority on reasoned request.
For the open-source stewardship position, confirm with the Commission's guidance how your activity is classified before assuming the lighter regime applies.
How to set up SBOM generation for CRA evidence
This sequence turns SBOM generation from a one-off export into a repeatable build output that feeds vulnerability tracking, technical documentation and retrieval for a market surveillance authority. Each step ends with an artifact you can show an assessor.
Inventory the product and its build targets
The product engineering lead, with the build or release engineers, lists every product version, firmware or software artifact, and build target that ships to users. For each target, record the top-level dependencies, the operating system packages and any bundled runtimes. Annex I Part II point (1) asks for the SBOM to cover at least the top-level dependencies, so this inventory defines the boundary of what the SBOM must describe. The step is done when each shipped artifact maps to a named build pipeline and an owner, and the list has been reviewed against the product's technical documentation scope.
Select the generator and output format
The security engineering team evaluates open-source generators against the ecosystems in the inventory. Trivy (Apache-2.0) can identify OS packages and software dependencies in a target and produce them as an SBOM, and it can also scan an existing SBOM. OWASP Dependency-Track (Apache-2.0) consumes and produces CycloneDX SBOMs and VEX, which makes CycloneDX a common working format for the tracker. Article 13(24) lets the Commission set the SBOM format by implementing act, and no such act appears in the Commission's implementation timeline as updated on 27 July 2026, so confirm the current position before fixing the format. The step is done when a written decision records the generator, the format and its version, and the reason for the choice.
Integrate SBOM generation into every build
The build or DevOps engineers add an SBOM generation step to each release pipeline so that every tagged build produces a machine-readable SBOM alongside the binary or image. The SBOM should be generated from the built artifact, not from a manifest that may differ from what ships, and stored with the build's version identifier and hash. This is a one-time pipeline change, but it recurs with every release, so the work involves ongoing maintenance as build tooling changes. The step is done when a sample release run produces an SBOM whose component list matches the artifact contents and is archived with the release record.
Feed the SBOM to a vulnerability tracker
The product security team uploads each release SBOM to a tracker such as OWASP Dependency-Track, which correlates components against vulnerability sources and applies global and per-project policies for security, license and operational compliance. The team sets policies that define which findings block a release, which need triage and who approves exceptions. Dependency-Track can also track outdated or modified components, so the policy should cover those as well. This output supports the risk-based vulnerability handling that the CRA expects across the support period. The step is done when a release with a known finding produces a recorded triage decision in the tracker.
Record the process in technical documentation
The compliance lead, with the product and security engineers, writes the SBOM process into the product's technical documentation. Annex VII point 2(b) requires the SBOM to be included in that documentation, so the record should name the inventory, generator, format, build integration, tracker policies and archive location. The document should also say who maintains each step and how changes to the process are reviewed. Recording the process lets an assessor follow the evidence without relying on individual memory. The step is done when the document has a named owner, a version and a cross-reference to the release records that the SBOM generation step produces.
Define how the SBOM is retrieved for an authority
The compliance lead sets out the retrieval path for a market surveillance authority, which Annex VII point 8 describes as provision on reasoned request where needed to check compliance. The procedure should name the person who can release the SBOM, the archive location for each version, the format in which it can be delivered and the target response process. Sharing the SBOM with users is optional under Annex II point 9, so the procedure should also state whether a public or customer-facing copy will be published. Confirm the authority contact route and internal approval steps with your legal team before the first request arrives. The step is done when a tested retrieval exercise produces the correct SBOM for a chosen release within the internal process.
What must be in place before an SBOM supports CRA evidence
An SBOM only counts as CRA evidence when it is tied to a specific release, stored where an assessor can retrieve it, and backed by a documented way to decide which vulnerabilities matter. The six items below connect generation, storage, tooling, triage and accountability, and each one can be checked against a single sample release.
Release-linked SBOM generation
Generate the SBOM inside the build pipeline for every release candidate, not by scanning a running system after the fact. Annex I Part II point (1) asks manufacturers to identify and document components, and an SBOM produced from a different build than the one shipped does not describe the product users receive. To check this with a sample release, confirm the SBOM's component versions and hashes match the artifact's build record and the release tag.
Stored and versioned SBOM per release
Keep each SBOM in a repository that retains it for the full support period, indexed by product, version and build identifier. Annex VII point 2(b) places the SBOM within the technical documentation, and point 8 requires it to be produced to a market surveillance authority on reasoned request. Check by picking an older release and confirming its SBOM can still be retrieved and matches what shipped, without regenerating it.
Documented tool chain
Record which generator, scanner and analysis platform produced the SBOM, including versions and configuration, and how components are matched to vulnerability sources. A tool that changes silently between releases makes results hard to reproduce during an assessment. Check by asking the team to rerun the generator on the sample release with the documented version and compare the output with the stored file.
Vulnerability and VEX triage process
Define who reviews findings, how each one is classed as affected, not affected, under investigation or fixed, and how that decision is recorded as a VEX statement with the SBOM. Dependency-Track consumes and produces CycloneDX SBOMs and VEX, so triage decisions can travel with the component data. Check by selecting one flagged component in the sample release and confirming it has a dated triage decision, a rationale and a link to the remediation or risk acceptance.
Format and field decisions
The CRA leaves the SBOM format and elements to a future Commission implementing act under Article 13(24), and that act does not yet appear in the Commission's timeline as updated on 27 July 2026. Record the format you chose (commonly used and machine-readable) and the fields you capture, so you can convert or extend them later. Check by confirming the sample SBOM covers at least the top-level dependencies and identifies the format version.
Named SBOM owner
Assign one accountable person, usually in product security or the platform team, who signs off the tool chain, approves triage decisions and answers authority requests. Shared ownership tends to leave gaps when a release ships without a stored SBOM. Check by asking who can produce the sample release's SBOM within a working day and who approved its VEX statements, then verifying the answer is written in the process document.
Questions teams ask about SBOM tools for CRA
Are open-source tools enough to meet the CRA SBOM requirement?
Open-source tools can generate and track the SBOM, but the regulation places the duty on the manufacturer, not on the tool. Annex I Part II point (1) requires manufacturers to identify and document vulnerabilities and components, including by drawing up a software bill of materials in a commonly used, machine-readable format covering at least the top-level dependencies. Trivy (Apache-2.0) can produce SBOMs from a target and scan existing ones, and OWASP Dependency-Track (Apache-2.0) consumes and produces CycloneDX SBOMs and VEX and correlates components against several vulnerability sources. The gap that remains is process: someone must own the SBOM, keep it current with each release, and place it in the technical documentation. Confirm the full tool set with your conformity assessment route before you commit.
Do we have to share the SBOM with our customers?
No. Sharing the SBOM with users is optional under the CRA. Annex II point 9 requires user information on where to access the SBOM only if the manufacturer decides to make it available to users. The SBOM is still required in the technical documentation under Annex VII point 2(b), and under Annex VII point 8 it must be provided to a market surveillance authority on reasoned request where needed to check compliance. Your decision on customer sharing is a commercial and contractual one, and it affects how you package and version the SBOM. Some organizations choose to publish it for transparency, while others keep it internal and provide it only to authorities.
Is there a mandatory SBOM format under the CRA yet?
Not yet. Article 13(24) empowers the Commission to specify the format and elements of the SBOM by implementing act, taking into account European or international standards. No such implementing act appears in the Commission's CRA implementation timeline as updated on 27 July 2026. Until one is adopted, the regulation's own wording points to a commonly used, machine-readable format. Choose a format your tools support well, keep the SBOM exportable, and track the Commission's implementation page so you can adjust if an act sets specific fields or formats later.
How much effort does SBOM tool setup take, and what drives it?
Effort depends mainly on how many products, build pipelines and repositories you need to cover, how many dependency layers you must include, and how well your builds already record their inputs. A single product with a clean lockfile and a standard build is far simpler than a portfolio of products with vendored code, multiple languages and container images. Other drivers include how you integrate SBOM generation into CI, how you handle false positives in vulnerability matches, and how you maintain policies in Dependency-Track. No fixed duration is set by the regulation, so ask any implementation partner for a written scope that lists products, pipelines, data sources and deliverables before agreeing to a timeline.
Do we need a consultant to set up SBOM tooling for the CRA?
Not necessarily. Many engineering teams can install and run open-source generators and a tracker themselves, especially if they already maintain CI pipelines and vulnerability workflows. An outside partner is most useful when you have many products, mixed technology stacks, or limited internal capacity and want a fixed-scope deliverable. DeployOpen plans, implements, integrates and documents self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope with written deliverables. DeployOpen does not issue conformity assessments or certificates; those come from independent bodies. Ask any provider to state in writing which parts they own and which remain with your team.
What can a market surveillance authority ask for about our SBOM?
An authority can request the SBOM in the technical documentation where needed to check compliance. Under Annex VII point 8, the manufacturer must provide it to a market surveillance authority on reasoned request. Market surveillance is carried out by national authorities under Regulation (EU) 2019/1020, which the CRA applies. Prepare by keeping each release's SBOM versioned and linked to the product build, storing it with the technical documentation, and being able to explain how it was generated and which vulnerability sources were used. Confirm with your national authority how it expects requests to be made and answered.
Which SBOM tool should we choose for the CRA?
Choose based on the coverage you need, not on a single tool name. Trivy can identify OS packages and software dependencies in a target, produce an SBOM, and scan existing SBOMs. Dependency-Track is suited to ongoing tracking because it correlates components against sources including the NVD, GitHub Advisories, OSV and VulnDB, and applies global and per-project policies. Evaluate each candidate against the components in your products, your build systems, the formats your customers and authorities may accept, and the licenses you must track using SPDX identifiers. Run a pilot on one product before you standardize, and confirm each tool's current capabilities and license terms in its own documentation.
How to choose a partner for SBOM tooling
A partner that sets up SBOM tooling can build the pipeline, configure the scanners, and write the runbooks, but it cannot certify that your product conforms to the CRA. The organization remains the manufacturer and owns the conformity decision, the technical documentation and the SBOM itself. Where a conformity route requires a notified body, only that independent body issues a certificate, and where the route is self-assessment, the EU declaration of conformity is still the manufacturer's own statement. Before signing, confirm in writing which of these roles the partner plays and which the regulator or assessor plays, so no one assumes a certificate is coming that will never be issued.
Ask for a written scope that names the products, product versions and build pipelines in scope, the SBOM generator and format you will use, and the component vulnerability tool, such as OWASP Dependency-Track, that consumes the output. The deliverables list should include the working pipeline, the configuration files and policy settings in version control, and runbooks that a staff engineer can follow without the partner present. Require a handover session and confirm that you hold admin credentials, the source repositories and the configuration history from day one. Ask who maintains the tooling after go-live and how upgrades will be tested. Any recurring support should appear as a separate, priced line, so you can compare it with an internal team's time.
Settle SBOM ownership in the contract as well. The SBOM is part of your technical documentation under the CRA and may need to be given to a market surveillance authority on reasoned request, so the file must stay in your repositories and your record-keeping system, not in a partner's workspace. Confirm the export format, where each SBOM version is archived and how long it is retained. Also confirm the Commission has not yet adopted an implementing act fixing the SBOM format, so your partner should design for a standard, machine-readable output and keep the generator easy to change. Ask the partner to show, in writing, how they would handle a format change.
How DeployOpen prepares SBOM tooling and evidence
DeployOpen plans and implements self-hosted open-source SBOM and vulnerability tooling inside your own infrastructure, so the SBOM and its vulnerability records stay under your control. Your organization still owns its CRA obligations, and an independent assessor or notified body issues any conformity decision.
How we scope
- Agree in writing which products, software versions and build pipelines the SBOM tooling will cover.
- Confirm which SBOM elements, formats and recipients your technical documentation requires for each product.
- Define who receives SBOMs internally, for market surveillance requests, and whether any users will see them.
How we build
- Set up SBOM generation in your build pipelines, using open-source generators such as Trivy against the artifacts you ship.
- Deploy OWASP Dependency-Track inside your environment to ingest CycloneDX SBOMs and track component vulnerabilities.
- Configure security, license and operational policies per project, and test that findings reach the people who triage them.
How we hand over
- Document the tooling architecture, configuration, data flows and the procedure for producing each SBOM version.
- Deliver an evidence set your team can file with technical documentation, showing how SBOMs are generated and kept current.
- Train your engineers and product security staff to run, review and export the tooling without DeployOpen involvement.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, separate from the fixed-scope build.
- Update generator and tracker configurations when the Commission issues SBOM format rules or your product changes.
- Confirm with your assessor or notified body which evidence they will accept, since DeployOpen prepares evidence but does not certify it.
Sources and further reading
- Regulation (EU) 2024/2847, Annex I (EUR-Lex) ↗
- Regulation (EU) 2024/2847, Article 3 (EUR-Lex) ↗
- Regulation (EU) 2024/2847, Annex VII (EUR-Lex) ↗
- Regulation (EU) 2024/2847, Annex II (EUR-Lex) ↗
- Regulation (EU) 2024/2847, Article 13 (EUR-Lex) ↗
- Cyber Resilience Act implementation, Shaping Europe's digital future ↗
