SBOMs & components

Each product version carries one active SBOM. It is the raw material for everything downstream: the component inventory, fleet-wide vulnerability correlation, and the evidence and documentation features.

Upload an SBOM

From a product version, upload a CycloneDX JSON (v1.4–1.6) or SPDX JSON (v2.2/2.3) file. The format is detected from the document itself — you never pick one. Unrecognisable or unparseable content is rejected with an error rather than half-ingested.

Resilic parses the document into components: name, version, package URL (PURL), CPE, and supplier, where the SBOM provides them. Uploading a new SBOM for the same version replaces the previous one — there is exactly one active SBOM per version.

Request an SBOM from a supplier

If you don’t have an SBOM for a component or version, request one:

1. On the product version, choose Request SBOM from supplier and enter the supplier’s name and email address.
2. Resilic emails the supplier a tokenized upload link (and shows it to you, so you can also share it directly). The supplier needs no account: the upload page shows only your organisation name, the requested product/version, and their own name — nothing else.
3. Track requests per version: pending, fulfilled, expired, or revoked. You can revoke a pending request at any time; links are single-use and expire on their own.

When a supplier uploads, the SBOM does not go live automatically. You review it and acknowledge it — only then does it become the version’s active SBOM, with the supplier recorded as its provenance. Until you acknowledge, your previously uploaded SBOM (if any) stays active.

Build an SBOM without tooling

No SBOM from your supplier — just a parts list in a spreadsheet? Build one in Resilic. On any product version without an SBOM you can record components by hand (name, version, supplier) or bulk-import a CSV: pick the file, map its columns to component fields in a preview (only the component name is required — Resilic pre-guesses common English and German headers like Komponente or Hersteller), and import. Rows that can’t be read are reported individually with their line number; the rest import anyway, and re-importing the same file skips what is already recorded.

When the register reflects what you know, choose Create SBOM (CycloneDX). Resilic assembles a CycloneDX 1.6 document from the recorded components and makes it the version’s active SBOM — it feeds vulnerability correlation, coverage badges, and the passport exactly like an uploaded SBOM, and you can download the artifact to pass on to customers or auditors.

Two honesty rules are built in. The artifact names Resilic as the assembler — this is your component declaration, assembled from your inputs, never a scan result. And unless you tick “the component list is complete”, the SBOM itself records its composition as incomplete, so nobody downstream mistakes a partial parts list for a full inventory. You can edit the register and re-create the SBOM at any time; assembled SBOMs show an Assembled badge as their provenance.

Signed SBOMs & tamper evidence

Every ingested SBOM records the SHA-256 of the uploaded file — the integrity anchor you can compare against the original at any time. CycloneDX documents carrying an embedded signature (JSON Signature Format, as produced by cyclonedx-cli sign) are verified on ingest:

• Signed · key pinned — the signature is valid and matches the signing key recorded in the supplier’s qualification file. The strongest provenance.
• Signed — cryptographically valid, but no pinned key to anchor who signed it.
• Signature invalid — the document was altered after signing, or signed with a key that contradicts the pinned one. Treat as untrusted.

To pin a supplier’s key, paste their public key (PEM) into the supplier’s qualification file — exchanged once, out-of-band. Resilic verifies signatures; it does not sign SBOMs itself.

Downloading the original SBOM

Every SBOM ingested since raw retention exists can be downloaded again byte-for-byte — an embedded supplier signature stays verifiable, and the recorded SHA-256 matches the file you get. Find Download SBOM next to the SBOM’s signature badge in the product view. SBOMs ingested before retention existed have no stored original; re-upload them once to enable the download.

Component end-of-life

Each component can carry an end-of-life (EOL) date — when the supplier stops maintaining it. Set it by hand on any component in the SBOM view, or import EOL dates from a CSV (columns purl, end_of_life as yyyy-MM-dd) to fill in a whole SBOM at once, matched by package URL.

The earliest component EOL is the strongest single constraint on a defensible support period: if a component reaches end-of-life before the support period you committed to on the product, Resilic flags a support-period risk on that product and — if you’re subscribed — emails you once. It is a readiness signal, never a hard block: shorten the committed period, plan a component update, or record why the shorter component life is acceptable. The flag clears itself once the risk no longer holds.

Component normalization

Real-world SBOMs from industrial suppliers are messy: the same component named differently, missing identifiers, inconsistent versions. Resilic normalizes every ingested component to a canonical identity (canonical PURL, validated CPE) so correlation can match reliably, and deduplicates across versions — the same OpenSSL 3.1.0 in five product versions is one registry entry.

Normalization is deterministic by default. Where identifiers are missing or fuzzy, an AI-assisted normalizer can resolve them; those components are visibly badged “AI-normalised” and you can correct them. Nothing is signed at ingestion — the human sign-off happens where it is load-bearing, on the Article 14 report itself.

What this is — and isn’t

SBOM obligations are CRA Article 13 / Annex I duties, applying from 11 Dec 2027 — they are not part of Article 14 reporting, and ingesting an SBOM is not “Article 13 compliance”. In Resilic, the SBOM is the detection foundation for Article 14 readiness: it is what lets a CVE be traced to a component, a component to a product version, and a version to the fielded machines it runs on.

Name screening

Every component in the registry is screened automatically against a curated list of well-known package names: one-letter near-misses, look-alike characters (such as l0dash), and well-known names declared under an unexpected package ecosystem — a common dependency-confusion pattern. A flagged component shows a Verify name badge with an explanation. Screening flags for your judgement; it never blocks or rejects a component, and a flag is not a verdict that anything is malicious.