SBOM (SPDX & CycloneDX)

A Software Bill of Materials lists every component (and its version) that goes into a released binary. Auditors increasingly require one — EU MR Annex IV.6, the EU Cyber Resilience Act, US Executive Order 14028. Roboticks ingests SBOMs and embeds them in the per-release evidence pack so the auditor finds the answer without asking. Roboticks accepts both major SBOM formats:

Format	Spec	Producer examples
SPDX 2.3 (and 3.0 when finalised)	ISO/IEC 5962:2021	syft, scancode, Mend, FOSSA
CycloneDX 1.4–1.6	OWASP	syft, trivy, anchore, snyk

For most teams syft (multi-format, multi-language) or trivy (image + filesystem) are the right tools. Both ship in the bundled OSS scanners — no extra fee.

Why an SBOM lands in the evidence pack

Regulators ask “what’s in the binary you shipped to my factory?” and they want a machine-readable answer pinned to the release tag. The Roboticks evidence pack already contains:

Source state (git SHA, commit signature)
Test results (JUnit, MCAP)
Requirement coverage snapshot (ReqIF)
Findings (SARIF + vendor reports)

Adding the SBOM closes the supply-chain loop. The pack now answers:

What was tested? — JUnit + traceability matrix
What were the requirements? — ReqIF snapshot
What runtime behaviours did we capture? — MCAP attachments
What components went into the binary? — SBOM

Upload an SBOM

rbtk sbom upload --tool syft sbom.cdx.json
rbtk sbom upload --tool trivy trivy.sbom.spdx.json

The CLI auto-detects SPDX vs CycloneDX by document structure. The --tool label is free-form for grouping in the dashboard.

Wire it into CI

syft (CycloneDX)
syft (SPDX)
trivy
Container image

syft . -o cyclonedx-json=sbom.cdx.json
rbtk sbom upload --tool syft sbom.cdx.json

syft . -o spdx-json=sbom.spdx.json
rbtk sbom upload --tool syft sbom.spdx.json

trivy fs --format cyclonedx --output sbom.cdx.json .
rbtk sbom upload --tool trivy sbom.cdx.json

# syft against a built image
syft my-registry.acme.com/firmware:v2.4.0 -o cyclonedx-json=sbom.cdx.json
rbtk sbom upload --tool syft sbom.cdx.json --label image=firmware:v2.4.0

CI recipe — SBOM on every release

# .github/workflows/release-sbom.yml
name: Release SBOM
on:
  release:
    types: [published]

jobs:
  sbom:
    runs-on: ubuntu-latest
    permissions: { id-token: write, contents: read }
    steps:
      - uses: actions/checkout@v4

      - name: Install syft + trivy
        run: |
          curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin
          curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh -s -- -b /usr/local/bin

      - name: Build the artefact
        run: ./scripts/build.sh

      - name: Generate SBOMs
        run: |
          syft  ./build -o cyclonedx-json=sbom.cdx.json
          syft  ./build -o spdx-json=sbom.spdx.json
          trivy fs --format cyclonedx --output trivy.cdx.json ./build

      - run: pipx install roboticks-cli
      - run: rbtk auth oidc-from-github

      - name: Upload SBOMs (release-tagged)
        run: |
          rbtk sbom upload --tool syft  sbom.cdx.json --release ${{ github.event.release.tag_name }}
          rbtk sbom upload --tool syft  sbom.spdx.json --release ${{ github.event.release.tag_name }}
          rbtk sbom upload --tool trivy trivy.cdx.json --release ${{ github.event.release.tag_name }}

The --release flag pins the SBOM to the release tag — it ends up in that release’s evidence pack, even if you re-run the workflow later.

Where SBOMs appear

Release detail view — a Supply chain panel shows component counts, license breakdown, and a CVE summary (via the vulnerability scan if trivy was used).
Release evidence pack — the SBOM ships in:
- The PDF, as a Supply-Chain Appendix with component-list, license-table, and the CVE summary
- The ZIP, as raw sbom.cdx.json and sbom.spdx.json files for downstream tooling
Comparison — diff one release’s SBOM against the previous to spot newly introduced components.

Diffing SBOMs

rbtk sbom diff v2.3.0 v2.4.0

ADDED       3 components
  • openssl@3.0.13 (was: 3.0.11)
  • libcurl@8.7.1 (NEW)
  • cyclonedx-py@5.0.0 (NEW)

REMOVED     1 component
  • python-jose@3.3.0

LICENSE CHANGES
  None

--output json returns the structured diff including PURLs and license deltas.

License surfacing

Roboticks extracts SPDX license identifiers from both SBOM formats and surfaces:

Per-release license summary — total components per license
Copyleft check — flags GPL/AGPL/LGPL components for review
Unknown licenses — components syft/trivy couldn’t classify

A release.license_policy.yaml lets you fail an evidence-pack generation if a forbidden license appears:

# .roboticks/release.license_policy.yaml
forbidden:
  - AGPL-3.0-only
  - AGPL-3.0-or-later
require_known_license: true

Provenance and signatures

If your SBOM is signed (in-toto, Cosign, or DSSE-wrapped), upload the signature alongside:

rbtk sbom upload --tool syft sbom.cdx.json --signature sbom.cdx.json.sig

Roboticks records the signature in the SBOM’s metadata block and embeds it in the evidence pack so the auditor can re-verify.

Quotas

Aspect	Limit
Components per SBOM	100,000
Upload size	500 MB per file; gzip helpful at scale
SBOMs per release	unlimited; multiple uploads merge (latest-per-`--tool` wins)

Standards references

SPDX: spdx.dev, spec ISO/IEC 5962:2021
CycloneDX: cyclonedx.org, OWASP project
NTIA minimum elements: ntia.gov/SBOM — what regulators expect
CISA SBOM page: cisa.gov/sbom — US Executive Order context
OpenSSF: openssf.org — supply-chain best practices

Troubleshooting

`SBOM schema validation failed`

Confirm the format with cyclonedx-cli validate or spdx-tools verify. Most validation failures stem from custom fields outside the spec.

SBOM uploaded but not in the release evidence pack

Use --release <tag> on upload. Without it, the SBOM attaches to the current state, not the release-tagged state. You can re-attach:

rbtk sbom attach --release v2.4.0 --sbom-id sbom_a1b2

syft / trivy emit duplicate components

Both tools’ default modes can produce dupes when scanning a tree with multiple package managers (e.g., npm + pip). Pass --exclude to narrow scope or merge SBOMs with cyclonedx-cli merge before upload.

OSS scanners

syft and trivy ship bundled.

Evidence packs

Where SBOMs end up.

Quick Start

GitHub App

Requirements

Traceability

Testing

SDK

Self-Hosted Runners

AI Features

CLI

Evidence Packs

Standards Coverage

Compliance Patterns

Integrations

Pricing

Resources

SBOM (SPDX & CycloneDX)

SBOM (SPDX & CycloneDX)

Why an SBOM lands in the evidence pack

Upload an SBOM

Wire it into CI

CI recipe — SBOM on every release

Where SBOMs appear

Diffing SBOMs

License surfacing

Provenance and signatures

Quotas

Standards references

Troubleshooting

Next

OSS scanners

Evidence packs

​SBOM (SPDX & CycloneDX)

​Why an SBOM lands in the evidence pack

​Upload an SBOM

​Wire it into CI

​CI recipe — SBOM on every release

​Where SBOMs appear

​Diffing SBOMs

​License surfacing

​Provenance and signatures

​Quotas

​Standards references

​Troubleshooting

​Next

OSS scanners

Evidence packs

SBOM (SPDX & CycloneDX)

Why an SBOM lands in the evidence pack

Upload an SBOM

Wire it into CI

CI recipe — SBOM on every release

Where SBOMs appear

Diffing SBOMs

License surfacing

Provenance and signatures

Quotas

Standards references

Troubleshooting

Next