User manual

Generating SBOMs

A Software Bill of Materials (SBOM) is a machine-readable inventory of every component in your software: direct dependencies, transitive dependencies, and their versions. SBOMs have become a key building block in supply chain security, enabling automated vulnerability scanning and license compliance analysis.

With the EU Cyber Resilience Act (CRA) requiring SBOM delivery for software sold in the EU, and US Executive Order 14028 making SBOMs a federal procurement expectation, many organizations now treat SBOM generation as a hard requirement.

Camel releases ship with SBOMs

Starting from Camel 4.0.3, every release ships with PGP-signed CycloneDX SBOMs (JSON and XML) covering all Camel modules and their dependencies. These are available on the download page alongside the release artifacts.

Generating SBOMs for your own applications

To produce an SBOM for your Camel application (as opposed to the framework itself), choose the approach that matches your runtime.

Camel CLI

The Camel CLI has a built-in sbom command that generates an SBOM for your integration project without any extra tooling.

camel sbom

This produces a sbom.json file in CycloneDX format by default.

To use SPDX format instead:

camel sbom --sbom-format=spdx

To generate for a specific target runtime:

camel sbom --runtime=spring-boot

camel sbom --runtime=quarkus

The output format can be switched between JSON and XML:

camel sbom --sbom-output-format=xml

See the camel sbom command reference for all available options.

Camel Spring Boot

Spring Boot 3.3+ has built-in SBOM support: it generates a CycloneDX SBOM during the build, packages it inside the uber jar at META-INF/sbom/application.cdx.json, and can expose it via an actuator endpoint. Since Camel Spring Boot runs on top of Spring Boot, this automatically covers Camel and all its transitive dependencies — no extra plugin or Camel-specific configuration needed.

Camel Quarkus

Quarkus has its own dependency resolver that differs from standard Maven resolution, which means the generic CycloneDX Maven plugin will not capture the full dependency graph. Instead, use the native Quarkus CycloneDX extension. Add it to your project:

<dependency>
    <groupId>io.quarkus</groupId>
    <artifactId>quarkus-cyclonedx</artifactId>
</dependency>

This generates a distribution SBOM automatically every time you build. You can also generate a dependency SBOM before building with mvn quarkus:dependency-sbom.

Analyzing SBOMs

Once you have a CycloneDX SBOM — a released Camel SBOM from the download page, the aggregate SBOM kept in the source tree under camel-sbom/, or one you generated for your own application — you can feed it into vulnerability scanners, license and policy tools, and continuous-monitoring platforms. Because the SBOM already captures the resolved dependency graph, these tools work from the file alone: no rebuild or re-resolution of the project is required.

The examples below assume a CycloneDX JSON file named camel-sbom.json; substitute the file you actually have (for a release, e.g. camel-4.23.0-sbom.json).

Scanning for known vulnerabilities

Several open source scanners read a CycloneDX SBOM directly and match its components against vulnerability databases:

# Anchore Grype
grype sbom:camel-sbom.json

# Aqua Trivy
trivy sbom camel-sbom.json

# Google OSV-Scanner (v2)
osv-scanner scan source -L camel-sbom.json

OSV-Scanner auto-detects CycloneDX files whose name is bom.json / bom.xml or ends in .cdx.json / .cdx.xml. For any other name, point it at the file explicitly with -L as above.

Inspecting, validating and converting

The CycloneDX CLI validates, converts and diffs BOMs. Camel’s SBOMs use CycloneDX specification version 1.6, and the CLI’s validate defaults to a newer schema version, so pass --input-version v1_6 explicitly:

# Validate against the CycloneDX 1.6 schema
cyclonedx validate --input-file camel-sbom.json --input-format json --input-version v1_6 --fail-on-errors

# Convert JSON to XML (use --output-format spdxjson to convert to SPDX)
cyclonedx convert --input-file camel-sbom.json --output-format xml --output-file camel-sbom.xml

# Diff two SBOMs — e.g. what dependencies changed between two Camel releases
cyclonedx diff camel-4.22.0-sbom.json camel-4.23.0-sbom.json --component-versions

For quick, ad-hoc queries no dedicated tool is needed — the JSON can be sliced with jq:

# List every component as group:name:version
jq -r '.components[] | "\(.group // ""):\(.name):\(.version)"' camel-sbom.json

# Find the version of a specific library across the whole graph
jq -r '.components[] | select(.name | test("jackson")) | "\(.name) \(.version)"' camel-sbom.json

Continuous monitoring with OWASP Dependency-Track

OWASP Dependency-Track ingests CycloneDX SBOMs and continuously re-evaluates them as new CVEs are disclosed, so a component that is clean today but vulnerable next week surfaces without re-scanning. Upload the SBOM through the UI (Projects → your project → Upload BOM), or automate it from CI through the REST API:

curl -X POST "https://<dependency-track-host>/api/v1/bom" \
  -H "X-Api-Key: $DTRACK_API_KEY" \
  -F "projectName=apache-camel" \
  -F "projectVersion=4.23.0" \
  -F "autoCreate=true" \
  -F "bom=@camel-sbom.json"

The /api/v1/bom endpoint expects multipart/form-data. Use autoCreate=true together with projectName/projectVersion to create the project on first upload, or target an existing one with -F "project=<project-uuid>" instead. See the Dependency-Track CI/CD guide for the maintained GitHub Action, Jenkins plugin and CLI wrappers.

Alongside each SBOM, Camel also publishes a CycloneDX VEX file (camel-sbom.vex.json). A VEX (Vulnerability Exploitability eXchange) document records which known vulnerabilities in the dependency graph are not exploitable as Camel ships them, so tools such as Dependency-Track can apply it to suppress those findings and reduce false-positive noise.