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.

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 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.