Skip to content

Products and releases

Everything in alloy-it centres on products (the things you place on the market) and releases (the firmware versions you actually shipped). Impact, triage, reporting, advisories, and conformity all answer the same question: which product, which release?

What is not tracked

Field fleet and installed-device inventory are out of scope, and so is ERP sync. alloy-it records what you placed on the market, not a registry of serial numbers at customer sites. Disclosure targets are advisory recipients and alert addresses.

Products

/products

One product per thing you place on the market. Each carries:

Field Notes
Name and SKU How you and an authority refer to it
CRA risk class default, important_i, important_ii, critical
Support end date Your declared support period under Art. 13(8)

The risk class is not cosmetic: it determines the conformity assessment pathway shown on the Conformity tab, and whether a notified body is involved at all.

The support end date bounds how long you are obliged to provide security updates, and is one of the two conformity checklist items alloy-it can satisfy from data rather than asking you to tick a box.

The product workspace

/products/:productId

Tab Contents
Overview Release list and posture summary
Triage This product's triage queue
Advisories Advisories issued for this product
Reporting Exploit incidents affecting this product
Conformity The Annex VII documentation checklist

Releases

/products/releases lists every release across every product, with inventory and finding status. One product has many releases, and the release is the unit of record for everything downstream.

A release is worth creating even before you have an SBOM for it. An addressable release is what lets you scope an incident; the inventory can be attached later.

Release detail

Tab Contents
Inventory Components from the vendor SBOM and, separately, from firmware analysis
Findings CVEs with severity, KEV flag, and which source matched them
Compare Vendor SBOM against the firmware-derived inventory, when both exist
Unified inventory One merged list with source badges, findings deduplicated across sources
Artifacts The firmware image and analysis report, as downloads
Process Triage, advisory, and provenance sub-states in one place
Provenance Which blueprint built this release, and at which verification tier

Unified inventory is presentation only

The merged view exists so you can read one list instead of two. The stored inventories stay separate and are monitored separately; merging them would lose the distinction between what the vendor claimed and what the binary contains, which is exactly the distinction worth keeping.

Two inventories per release

A release can carry two kinds of inventory, and they answer different questions.

Source Where it comes from What it tells you
uploaded A vendor CycloneDX/SPDX document, or one your build system produced What is claimed to be in the product
derived Generated from the shipped firmware binary, on demand What is actually in the artifact

Where both exist, the Compare tab shows a read-only diff. Neither overwrites the other. Continuous rescan monitors both.

This is the trust-but-verify shape: a vendor SBOM alone is a claim, and for firmware it is frequently an optimistic one.

→ Uploading SBOMs · Firmware analysis

Unlinked uploads

/products/inbox

Firmware binaries and SBOM documents that have been uploaded but not yet attached to a release land here. Link them to the right release from this page.

This exists because uploads often arrive from a pipeline or a colleague before anyone has decided which release they belong to.

Build provenance

A release can record which blueprint built it. This is the bridge between trace back and reproduce: when triage confirms a shipped release is affected, provenance points at the exact build environment to reconstruct.

It is declarative (you or your pipeline set it) and designed so attestation can be layered on later. Recording it costs a moment at release time and saves an archaeology project when a patch is needed four years on.

→ Build environments

Who can do what

Seeing these pages is not the same as being able to change them.

  • Product inventory, triage, reporting, advisories, evidence, and conformity require a Team or Enterprise plan and membership of an organisation group.
  • Uploading SBOMs and mutating compliance data requires organisation admin.

If an area is missing or an action returns 403, that is usually the reason. → Troubleshooting

Next