Skip to content

Uploading SBOMs

An SBOM attached to a release is what turns "we shipped v2.4.1" into something that can be scanned, triaged, and reported on. The CRA expects a machine-readable Software Bill of Materials covering at least top-level dependencies, kept current per software version.

Formats

Format Accepted
CycloneDX JSON
SPDX JSON

Upload from the release detail page. Scanning starts on ingest; you do not need to trigger it separately.

Where SBOMs come from

You do not have to generate these by hand. Most embedded build systems can emit one:

Build system How
Zephyr west spdx
Yocto / OpenEmbedded SPDX manifests from the build
Buildroot Built-in SBOM generation
Container-based builds Syft, Trivy, or your registry's own export

If none of these apply (a bare-metal MCU image, for instance), the practical route is to emit an SBOM from whatever produced the binary rather than trying to derive one from the image itself. See firmware analysis for why.

Pushing from CI

The most reliable inventory is the one nobody has to remember to upload. Settings → Integrations provides CI/CD tokens and pipeline snippets for release ingest, so a build can create the release and attach its SBOM as part of shipping.

This matters more than it looks: an inventory that is attached at build time is accurate at build time. An inventory attached six months later is a reconstruction.

One SBOM per version

A new software version needs a new SBOM. This is not an alloy-it rule; it is what the CRA asks for, and it is the difference between an inventory and a snapshot that quietly goes stale.

Each release carries its own inventory. Rescans keep the findings current; they do not update the components, because the components in a shipped binary do not change. If the components changed, that is a new release.

After upload

  1. Components are extracted into the release inventory.
  2. Findings are produced by matching components against vulnerability intelligence.
  3. The release joins the monitoring rotation: scheduled rescans re-query for new CVEs against the same stored inventory.
  4. Findings land in the triage queue, grouped by component.

New high and critical findings are emailed to your PSIRT alert addresses, configured in Settings → PSIRT alerts. They are never sent to your customers; that is advisories, and it happens only after triage.

Verifying what you were given

An SBOM from a supplier is a claim. Where you also hold the shipped binary, you can derive a second inventory from it and compare the two. Both are stored, both are monitored, and the Compare tab shows the difference.

Mismatches are triage input, not errors: a component in the binary that is absent from the vendor document is exactly the thing you want to find before an authority does.

→ Firmware analysis

Next