Solution 03 · Trusted Delivery

Make every firmware release traceable, from supplier component to update package.

A release is more than a version number. It is a set of components, a build, an authorisation decision and an artifact you can point to later. This is the direction we are building with design partners.

Compare two release SBOMs Contact us about Early Access

Capabilities

What this includes, and what each part really is today

Every capability carries a status. “Available now” means you can use it on this site. “Early Access” means design-partner scope. “Planned” means it does not exist yet.

Firmware and product release records

Early Access

Tie a build and its artifacts to one product version, not to a shared drive.

Design-partner scope. The public website does not provide release storage; the app workspace holds product and version records today.

Supplier component traceability

Early Access

Follow a supplier module to the product versions that contain it, without flattening the origin.

Early Access. The SBOM diff tool already documents which component versions changed between two builds.

Signing and provenance

Early Access

Record who signed what, with which key, and what the signature covers.

Early Access. The X.509 decoder is available now for inspecting a certificate; it does not verify a signature or a trust chain.

Production authorisation

Planned

Require an explicit, recorded decision before an update is allowed to ship.

Not implemented. No authorisation workflow, approval record or policy engine is claimed to exist.

OTA package and module evidence

Early Access

Keep the artifact hash, the component list and the authorisation together.

Design-partner scope. Local hashing of a chosen file works today; the OTA evidence record does not.

A release flow you can defend later

Build the firmware and generate the SBOM as part of the build, not afterwards.
Validate the SBOM and fail the release on schema or identity defects you care about.
Compare it with the previous release so the change is a reviewable list, not a diff of hashes.
Sign the artifact and record what the signature covers and which key was used.
Record the authorisation decision with the evidence that was reviewed.
Keep the package hash, the component list and the decision together for the support period.

What works today

SBOM validation with explicit limits, defect locations and exportable results.
Two-release SBOM comparison with added, removed, updated and unchanged components.
Local X.509 decoding for subject, issuer, validity window, key usage and fingerprints.
Browser-local processing with no upload, so a supplier or customer can run the check on their own machine.

Where the boundaries are

Signed artifacts and authorised updates require infrastructure we are not going to pretend exists. The website describes the workflow and links Early Access; it does not offer an authorisation button that only stores a local value.

No fake trust signals

A decoded certificate is not a verified chain. A diff is not an impact assessment. A validated SBOM is not a secure product. Each result states what it does not prove.

What we do not claim

Production authorisation is not implemented.
Signing, provenance and OTA evidence are Early Access.
Decoding a certificate does not verify signatures, trust paths or revocation.
A validated SBOM does not establish that a release is secure.

Start with what exists

The free tools need no account and cover the first two questions every programme starts with: is this product in scope, and is this inventory usable?

CRA scope checker SBOM validator Contact us about Early Access