SBOMembeddedsupply-chain

SBOMs for Embedded Systems: Best Practices When Using WCET Tools

bbinaries

2026-01-26

12 min read

Practical guide to producing SBOMs and provenance for embedded firmware when WCET tools (like RocqStat) are part of your toolchain.

Why embedded teams hit a wall: SBOMs, WCET tools and opaque provenance

If your build pipeline produces firmware that must meet real-time deadlines, you already know the pain: slow artifact distribution, opaque timing models, and a jumble of specialized libraries that never make it into your SBOM. Add a WCET (Worst-Case Execution Time) analysis stage and the complexity multiplies — timing models, hardware descriptors, and analysis metadata are now first-class safety artifacts that need provenance.

In 2026, OEMs, regulators and security-conscious integrators expect not just a binary and a checksum but a traceable, signed provenance chain that includes the tools that determined the timing safety of that binary. This article gives practical, step-by-step guidance for producing strong SBOMs and provenance metadata for embedded artifacts when your toolchain includes WCET tools such as RocqStat, and other specialized timing libraries.

The 2026 context — why timing analysis belongs in your SBOM and provenance

Recent industry moves underline the momentum: in January 2026 Vector Informatik announced the acquisition of StatInf's RocqStat technology and team to integrate WCET estimation into its VectorCAST toolchain. The move highlights two trends:

Timing safety is now a first-class requirement in safety-critical industries such as automotive and avionics.
Toolchains are consolidating: timing analyzers are integrated into verification pipelines, so their outputs must be discoverable and auditable.

"Timing safety is becoming a critical..." — Vector announcement, Jan 16, 2026

At the same time, governments and large integrators continue to push suppliers for SBOMs, signature transparency, and reproducible builds for firmware and device images. In practice that means your SBOM must document more than source packages — it must capture toolchain versions, WCET model files, hardware descriptors, and the outputs of the timing analysis itself.

High-level requirements for embedded SBOMs with WCET components

Before we dive into commands and examples, here are the must-have attributes for an SBOM and provenance package when WCET is in the loop:

Complete component inventory: runtime libraries, prebuilt vendor blobs, toolchain binaries (compiler, linker, assembler), and WCET tools and models.
Provenance metadata: build recipe (commit SHAs), build environment (container image digest or VM snapshot), toolchain checksums, and WCET tool output references.
Signed attestations: signatures for the binary, SBOM, and timing-analysis artifacts (use PGP or Sigstore/Cosign).
Reproducibility hints: SOURCE_DATE_EPOCH, determinism flags, and any non-deterministic inputs (test vectors, measurement harness) documented.
Hardware binding: CPU model, frequency, cache configuration, and board revisions necessary to interpret WCET results.

Step 1 — Inventory everything, including WCET tools and models

Start by deciding your SBOM schema. In 2026, SPDX and CycloneDX remain the most widely accepted formats; both support custom properties where you can add timing-specific metadata. Use a scanner that can inspect native binaries, package managers, and folders — for embedded projects, Syft (Anchore) is a strong choice because it detects many package types and emits SPDX/CycloneDX output.

Example: generate a CycloneDX SBOM of your firmware build directory using Syft

syft ./build/output -o cyclonedx-json --file firmware-bom.json

Syft will capture detected components; but you must enrich that SBOM with WCET-specific artifacts that syft may not detect by default (binary model files, annotations, or specialized vendor libs). Plan to append or merge extra components — treat those model files like captured field evidence and document chain-of-custody similar to field-proofing workflows.

What to include for WCET-specific coverage

WCET tool binary and version: e.g., RocqStat vX.Y.Z binary and checksum.
WCET model files: cache/branch models, microarchitectural description files, and any annotation files used during analysis.
Analysis configurations: the exact analysis command-line, config files, and environment variables.
Hardware description: CPU model, frequency, cache sizes, and board revision used for the deterministic model.
Timing harness and test vectors: inputs and trace logs used for measurement-driven calibration — capture and store these like a portable evidence kit (portable capture kits & edge workflows).

Step 2 — Represent WCET artifacts in your SBOM

You can represent WCET files as standard components in either SPDX or CycloneDX. Use component type=library or tool and attach properties to indicate role and provenance. Example CycloneDX JSON snippet showing a RocqStat model component:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.4",
  "components": [
    {
      "type": "tool",
      "name": "RocqStat",
      "version": "1.2.0",
      "bom-ref": "pkg:tool/rocqstat@1.2.0",
      "properties": [
        {"name": "role", "value": "wcet-analyzer"},
        {"name": "model-file", "value": "models/armv8/cache-model-2026-01.json"},
        {"name": "model-checksum", "value": "sha256:abcdef..."}
      ]
    }
  ]
}

If you use SPDX, include similar facts as SPDX packages with external references that point to model files and analysis reports.

Step 3 — Capture provenance: the “who, how and with what”

An SBOM alone documents what is present. Provenance tells you how a binary was produced. In 2026, the recommended stack for provenance and attestation in CI pipelines includes:

in-toto for capture of supply chain steps.
Sigstore / Cosign for signing and transparency logs (Rekor).
SLSA levels to classify the strength of your CI attestations.

Capture and sign these elements in a reproducible pipeline step that runs WCET analysis:

Record the tool versions (compiler, RocqStat, linker) and their checksums.
Record the build recipe: git commit SHA, build target, and container image digest (if using containers for build/analysis) — treat image digests like a migration anchor in your multi-registry strategy (multi-cloud migration playbook).
Store WCET outputs (reports and trace logs) together with an attestations file linking the binary to the analysis input and output.

Example: sign the SBOM and the WCET report with Cosign (keyless)

Using cosign's keyless mode (Sigstore) is now common practice to avoid managing long-lived private keys. First, ensure cosign is installed and you have an oidc provider configured in your CI.

# sign SBOM
cosign sign-blob --keyless --subject "ci://myorg/myfirmware/${GITHUB_RUN_ID}" firmware-bom.json > firmware-bom.sig

# sign WCET report (analyze-report.json)
cosign sign-blob --keyless analyze-report.json > analyze-report.sig

# verify
cosign verify-blob --keyless --signature firmware-bom.sig firmware-bom.json

Cosign stores a transparency record in Rekor that helps auditors verify the signature and link it back to the CI identity. For environments that require PGP, produce both cosign and GPG detached signatures. For secure approval workflows and messaging around attestation handoffs, consider integrating secure document workflows similar to secure RCS messaging for approvals.

Step 4 — Make your builds reproducible (reduce variability that breaks provenance)

Reproducible builds are not just a nicety — they're essential to validating analysis results that depend on compiled code layout. For embedded WCET, small compiler reorderings or timestamp skew can change code layout and invalidate timing assumptions.

Set SOURCE_DATE_EPOCH in the build environment to control timestamps.
Use deterministic linker flags (e.g., --build-id with a fixed algorithm, strip non-deterministic sections).
Pin toolchains to a digested container image (record image digest in provenance metadata) and account for cost and consumption impacts in your cloud strategy (cost governance & consumption discounts).
Record exact compiler flags and optimization levels used for timing-sensitive modules.

# example: bitbake / Yocto style reproducibility hints
export SOURCE_DATE_EPOCH=1672531200
export DISTRO_VERSION="release-2026.01"
bitbake my-ecu-image

Step 5 — Link WCET reports to artifacts in the SBOM

The WCET report must be discoverable and cryptographically bound to the binary it validates. Use SBOM properties or external references to link to the report and its signature.

{
  "components": [
    {
      "bom-ref": "pkg:firmware/my-ecu@1.0.0",
      "type": "application",
      "properties": [
        {"name": "wcet-report", "value": "reports/my-ecu-wcet-2026-01.json"},
        {"name": "wcet-report-sig", "value": "reports/my-ecu-wcet-2026-01.json.sig"}
      ]
    }
  ]
}

Store the SBOM, the signed WCET report, and the binary together in an artifact repository or an OCI registry. In 2026 the OCI distribution specification is widely used for firmware — push your firmware image and associate SBOMs and attestations as separate OCI artifacts using ORAS & OCI and consider registry resilience and edge delivery strategies discussed in multi-cloud and edge playbooks.

# push firmware image and SBOM (example)
oras push myregistry.example.com/my-ecu:1.0.0 firmware.bin --artifact-type application/vnd.oci.image.layer.v1+binary
oras push myregistry.example.com/my-ecu:1.0.0 firmware-bom.json --artifact-type application/vnd.cyclonedx+json
oras push myregistry.example.com/my-ecu:1.0.0 analyze-report.json --artifact-type application/vnd.myorg.wcet+json

Step 6 — CI pipeline pattern: build -> wcet -> attestation -> publish

A recommended pipeline stage order and responsibilities:

Checkout code, resolve dependencies, and launch a pinned build container (record digest).
Compile with deterministic flags; produce binary and ELF map files.
Run WCET analysis (RocqStat/other) using the same pinned container; capture analysis config and outputs.
Produce SBOM (Syft) and enrich it with WCET artifacts and hardware descriptors.
Generate in-toto link metadata for each step (build, analyze, sign).
Sign artifacts and attestations with Cosign and/or GPG; push everything to an OCI registry or artifact repo.

Example in-toto link step (conceptual): the link metadata records the command that ran RocqStat and includes checksums of the inputs and outputs. Use in-toto-run tooling provided by your in-toto integration for your CI. For secure operator workflows and human approvals around these steps, adapt patterns from secure messaging and approval workflows (secure RCS messaging).

Special considerations for vendor-supplied libraries and black-box IP

Embedded systems often include vendor-supplied libraries or prebuilt IP where source isn't available. For those cases:

Require vendors to provide an SBOM for their blob, with a model file for any timing assumptions.
If vendor SBOMs are not available, record the binary checksum, the supplier identity, and any contract or email reference in the artifact properties.
Prefer vendor attestation (signature) and include it in your provenance chain. If the vendor provides a signed timing model, capture that signature too — handle vendor artifacts with the same care you give portable field evidence and capture kits (portable capture kits).

Auditability — make it easy for integrators to verify timing claims

Auditors need to reproduce or at least validate the lineage of timing results. Provide the following as a minimum for each release:

SBOM (CycloneDX or SPDX) and its signature.
WCET analysis report and its signature.
Build container digest and build script (or bitbake recipe) used to produce the binary.
Hardware description + a note whether the analysis is model-based or measurement-augmented.
Mapping between functions in the binary and the WCET hotspots (map file).

For large programs, include a concise README that explains where timing-critical modules live, how to reproduce the analysis locally, and references to the exact tool versions used.

Practical checklist: What to include in your release bundle

firmware.bin (the binary) + sha256 and sha512 hashes
firmware.bin.asc (PGP detached signature) and cosign transparency record
firmware-bom.json (CycloneDX or SPDX) + signature
wcet-report.json (full WCET outputs) + signature
analysis-config.yaml (RocqStat / tool invocation and flags)
mapfile and linker script
hardware.json (CPU model, frequency, cache sizes)
build-recipe.txt (git commit, container digest, build flags)

Case study (concise): ECU image with RocqStat in CI

Team: automotive supplier. Goal: ship an ECU image with SBOM and WCET attestation to their Tier-1.

CI picks container image myorg/buildenv@sha256:deadbeef.
Build step compiles with SOURCE_DATE_EPOCH and emits firmware.bin and firmware.map.
WCET step runs RocqStat inside the same container using models/armv8/cache-model-2026-01.json and outputs analyze-report.json.
SBOM step runs syft to produce CycloneDX JSON, then a small script adds RocqStat as a component with model and checksum properties.
Attestations are created: cosign signs SBOM and wcet report; in-toto link metadata records each step. Rekor stores signatures for transparency.
Artifacts pushed to an OCI registry; Tier-1 verifies cosign Rekor entries and checks SBOM components for presence of vendor blobs and WCET model signatures.

Outcome: audit passed, delivery accepted. The key difference from earlier practice was including the WCET model and analysis output in provenance — the integrator could confirm the toolchain used and that the timing evidence matched the shipped binary.

Advanced strategies and predictions for 2026+

As toolchains consolidate (Vector + RocqStat being a 2026 example), expect the following:

WCET tools will expose richer machine-readable metadata formats for SBOM integration (model versions, hardware bindings, analysis traces).
OCI registries will become the de facto delivery channel for firmware with native support for SBOM and attestation artifacts via ORAS and Cosign annotations.
Automated compliance gates will check that SBOMs include timing models and signatures before allowing OTA deployment.

Start aligning your pipelines now: record every step, treat timing models like source code, and sign everything.

Common pitfalls and how to avoid them

Pitfall: SBOMs omit the WCET model file. Fix: add model files as separate components and include checksums and vendor signatures.
Pitfall: Different containers for build and analysis. Fix: pin a single container digest for both build and WCET stages and record it in provenance — consider multi-cloud and registry migration patterns in your deployment plan (multi-cloud migration playbook).
Pitfall: Unsigned WCET reports. Fix: sign reports with Cosign/GPG and publish Rekor entries.
Pitfall: Vendor blobs with no metadata. Fix: demand vendor SBOMs or include detailed vendor references in your SBOM and require vendor-signed attestations.

Practical commands and a starter script

Below is a condensed example workflow you can adapt in CI. It assumes syft, cosign, oras and rocqstat are available in the build container.

# 1. Build (assume reproducible env variables set)
make all
# 2. Generate SBOM
syft ./build/output -o cyclonedx-json --file firmware-bom.json
# 3. Run WCET
rocqstat analyze --config wcet-config.yaml --binary build/output/firmware.bin --output analyze-report.json
# 4. Enrich SBOM (simple jq append example, or use a small Python script)
python tools/enrich_sbom_with_wcet.py firmware-bom.json analyze-report.json models/cache-model-2026.json
# 5. Sign SBOM & WCET report
cosign sign-blob --keyless firmware-bom.json > firmware-bom.sig
cosign sign-blob --keyless analyze-report.json > analyze-report.sig
# 6. Push to registry with ORAS
oras push registry.example.com/my-ecu:1.0.0 firmware.bin --artifact-type application/vnd.firmware
oras push registry.example.com/my-ecu:1.0.0 firmware-bom.json --artifact-type application/vnd.cyclonedx+json
oras push registry.example.com/my-ecu:1.0.0 analyze-report.json --artifact-type application/vnd.myorg.wcet+json

Closing: actionable takeaways

Include WCET tools and model files as explicit SBOM components with checksums and vendor signatures.
Capture provenance for build and analysis steps using in-toto and Sigstore/Cosign, storing records in Rekor for transparency.
Make builds reproducible and pin your build & analysis environment to container digests; record everything in the SBOM or provenance manifests.
Use OCI registries (ORAS) to publish firmware, SBOMs and analysis artifacts together for easier verification by integrators.
Require vendor-signed SBOMs and attestations for any prebuilt IP or black-box libs included in your images.

Next steps — get this into your pipeline

Start small: pick one release and produce an enriched SBOM that includes WCET artifacts. Run a local verification: can you re-run the WCET step in a pinned container and get the same report? If not, iterate until your provenance is reproducible and verifiable.

Need a checklist or a pipeline template? Contact binaries.live for a tailored SBOM & provenance audit for embedded toolchains (including WCET integration), or download our embedded SBOM checklist to get started.

binaries

Contributor

Senior editor and content strategist. Writing about technology, design, and the future of digital media. Follow along for deep dives into the industry's moving parts.