One asset, many witnesses
More than one scanner will often see the same cryptographic object: the code scanner spots a hard-coded certificate, the TLS probe sees the same certificate served on an endpoint, the SBOM scanner sees the library that loads it. Rather than showing you three disconnected findings, the platform derives a canonical crypto asset from each observation and dedupes them by a source-agnostic identity key.
| Asset type | Identity key shape | Typical sources |
|---|---|---|
| Source usage | code:... — deterministic, from rule + path + code fingerprint | Static code scanner |
| Dependency | dependency:... — from the package purl | SBOM and dependency scanners, code scanner |
| Certificate | cert:sha256:<leaf-fingerprint-hex> | TLS probe, certificate and key files in code |
| TLS endpoint | endpoint:tls:<host>:<port>:<sni> | TLS probe, TLS configuration rules |
| Cloud KMS key | cloudkey:... — from the cloud key resource id | Cloud posture scanner |
Because the key is derived from the object itself — a certificate fingerprint, a host:port, a purl — and not from which scanner saw it, evidence from every source accretes onto one asset row. Each observation is appended to the asset immutable evidence ledger with its source scanner, confidence, and timestamp.
The inventory page
Route: /orgs/<org>/projects/<project>/inventory. The header shows the total count of deduped assets and a Download CBOM button. The left rail drives everything through the URL query string, so a filtered view is shareable.
- Search — free text across assets.
- Asset type — Certificate, Key, TLS endpoint, Cloud KMS key, Dependency, Source usage, Data asset, Unknown.
- Quantum safety — ordered worst-first: Classically broken, Vulnerable, Grover-weakened, Hybrid, Quantum safe, Unknown.
- Algorithm — a facet built from the algorithms actually present, so it only offers real choices.
- Owner — a facet built from owners present in the data;
Unassignedselects assets with no owner.
| Column | Content |
|---|---|
| Asset | Display name plus the canonical identity key in monospace |
| Type | Human-readable asset type |
| Algorithm | Algorithm, with key size appended when known |
| Quantum safety | Colour-coded chip |
| Evidence | Number of evidence records accreted on this asset |
| Findings | Number of related open findings, highlighted when above zero |
| Last seen | Relative time of the most recent observation |
Empty is not the same as unavailable
| State | What it means | What to do |
|---|---|---|
| Populated table | The normal state once scans have run and their evidence has been folded in. | Nothing. |
| Empty — "No assets match these filters" | The inventory API is reachable and answered honestly, but nothing matches. With no filters active, this is the honest "nothing ingested yet" state. | Clear a filter, or run a scan. |
| Unavailable — "Inventory not available in this deployment" | The web app cannot reach a backend serving the assets endpoint. Rather than silently substituting demo data, the page says so. | Raise it with your tenant administrator — you should not see this on a fully provisioned tenant. |
Asset detail and the evidence ledger
Route: .../inventory/<assetId> — the identity key is URL-encoded, since it contains colons. The header card shows the asset type, its quantum-safety classification, the display name, and a CBOM shortcut. A field grid summarizes what the evidence supports: algorithm, key size, owner, service, environment, exposure, evidence count, open findings, migration target, and the first and last seen window.
Two tabs follow. Evidence is the append-only ledger: each record shows the source scanner, its source type (code, dependency, tls, cloud, cert-key-file, runtime, sbom, manual), a confidence percentage, the observation time, and the raw source reference. Related findings lists findings linked to the asset through its evidence.
The CBOM download
The Download CBOM button maps to GET /api/v1/projects/{projectId}/cbom. The download is a CycloneDX 1.6-compatible Cryptographic Bill of Materials served as application/vnd.cyclonedx+json.
- One CycloneDX component per crypto asset — algorithms, keys, certificates, TLS endpoints and protocols, and crypto-relevant dependencies — each carrying its algorithm, key size, and quantum-safety posture.
- Evidence references on each component, tying the entry back to the observations that justify it.
- A dependencies section rooted at the project.
- Standard BOM metadata:
bomFormat,specVersion: 1.6, aserialNumber, and a document version.
Because it is standard CycloneDX, the CBOM feeds anything that already consumes CycloneDX BOMs: asset-management platforms, compliance tooling, audit evidence lockers, and your own drift detection in CI. If the deployment cannot generate one, the download responds 503 with an explicit message — never an empty or fabricated document.
Related pages
TLS endpoint and certificate posture
The read-only TLS surface: endpoint posture rows, certificate inventory, derived issue severities, the honest-empty contract, and the recognized PQC hybrid groups.
Scans, findings and reports
The day-to-day working loop: run a scan, read the live progress stream, filter and triage findings, save views, and export evidence.
Compliance evidence: what RelixQ produces
Which artifact answers which requirement, what RelixQ emits, and where the evidence boundary sits. For the mandates and deadlines themselves, see Post-quantum concepts.
REST API reference
The endpoint map for the Enterprise REST API: authentication, tenancy, per-service endpoint tables, honest-empty semantics, and the internal endpoints you should never call directly.