Skip to content

CBOM Artifacts

A CBOM Artifact is a frozen, dated, content-hashed snapshot of every cryptographic component matching a Scope at the moment of generation. It's what you hand an auditor, attach to a vendor questionnaire, or submit alongside a regulatory filing.

The CBOM is one of four kinds. The same pipeline also produces a software BOM, a hardware BOM and a full-inventory snapshot — same scope, same hash, same signature, same comparison. See Bills of Materials for what each kind contains and for the OCSF event export. This page covers the cryptographic kind, which is the default and what this page always described.

Once generated, an artifact is immutable. Regenerating against the same scope tomorrow produces a different artifact — that's deliberate. You keep both. The two can be compared (Enterprise — see below) to show how your posture changed.

Where to find them

Risk & Compliance → Bills of Materials in the primary nav. Or directly: /risk-compliance/cbom.

The page lists every artifact your tenant has generated, of every kind, newest first. Use the Kind filter to narrow it to CBOMs. Each row shows:

Column What it means
Name Either the human name you gave it at generation time, or <scope> — <date> if you skipped naming.
Scope The boundary the artifact was generated against, plus the scope version that was in force. Auditable.
Kind Which bill of materials this is — see Bills of Materials.
Generated When the snapshot was taken.
Entries How many components are in the BOM. For a CBOM: certificates, algorithms, protocols, keys, libraries.
Size Canonical byte count. Used for storage billing.

Where the bytes live is on the artifact itself rather than in the list: open a row and the Storage line reads "Object" (S3, production) or "Inline" (Postgres — dev, and brand-new installs that have not configured S3 yet). It gave up its column to Kind, which distinguishes two artifacts of the same scope on the same day; storage does not.

Generating an artifact

  1. Click Generate.
  2. Leave Kind on Cryptographic (CBOM) — it is the default. The other three kinds are described in Bills of Materials.
  3. Pick a Scope. Every artifact lives against exactly one scope.
  4. Optionally give it a meaningful name. For audit submissions, name the artifact after the engagement: "Q2 2026 PCI Submission," "ACME Vendor Onboarding 2026-05."
  5. Click Generate. The snapshot is taken synchronously; a new row appears.

Downloading

The Download dropdown offers:

  • CycloneDX 1.7 (.json) — the canonical format. Industry-standard for cryptographic BOMs. This is also what the content_hash refers to, so re-downloads always verify. Artifacts generated before v0.2.0 declare CycloneDX 1.6 and keep their original bytes — an artifact is immutable evidence and is never re-rendered; its cyclonedx_spec_version says which version it is.

SPDX and PDF downloads, artifact signing, and compliance attestation are part of the Enterprise CBOM evidence layer — see below.

Algorithm ratings

New reports use catalogue strength and risk assessments. An explicit risk score of zero is retained; a missing catalogue score or strength is unassessed, rather than a guessed score of 25 or an acceptable-strength label. Known weak-algorithm counts count confirmed weak rows; they are not proof that every other algorithm was assessed. PDF reports label absent strength Unassessed. Existing frozen artifacts retain their original values and bytes.

Content hash & integrity

Every artifact carries a SHA-256 hash of its canonical bytes. The hash is shown in the table (truncated; full value on the row's detail). If anyone tampers with the file after download, the hash won't match — your auditor can verify by recomputing.

Storage location

Two paths, automatic based on platform configuration:

  • Object storage (S3 or BYO) — production deployments configure storage in admin settings. CBOMs upload to your bucket with a tenant-scoped prefix (cbom/<tenant_id>/...). Storage usage counts toward your plan's included storage quota (monitoring only — there is no overage billing).
  • Inline (Postgres) — when no storage is configured, the CycloneDX bytes live in cbom_artifacts.inline_content. Same fidelity, lower scalability — fine for evaluating the platform or running it in a contained environment. Switch to object storage in admin → Storage when you're ready.

Deletion

CBOMs soft-delete. The row stays so dangling comparison references show "deleted by X on …" rather than 404. The actual object/inline content is removed from active queries.

System scopes (All, Production, Non-Dev/Test) cannot be deleted because an artifact references them by id — same protection applies to artifacts pointed at by scheduled deliveries (Phase 2 stub; no consumers yet).

What's Enterprise, not Core

Core generates the artifact and exports CycloneDX. The evidence layer on top — comparison (diffing two artifacts with categorized changes), the compliance-attestation layer, signing and verification, and SPDX / PDF downloads — is Enterprise. Those endpoints answer 402 Payment Required on a Core install rather than failing obscurely.

Still on the roadmap

  • Scheduled delivery — "email me a CBOM for scope X every Monday." Schema is in place; consumers ship in a later release.

Frequently asked

Is generating a CBOM expensive? For typical tenants (hundreds to low thousands of assets), generation is sub-second. Large enterprise tenants may see a few seconds while the snapshot walks the inventory. Storage cost is dominated by the canonical JSON, which compresses well.

Can I regenerate an artifact with the same id? No. Each generate call creates a new row. That's the point — you keep history.

How does the artifact know which scope version it was generated against? The scope_version and scope_name_snapshot columns capture both. If you edit the scope later (rename or change the predicate), older artifacts continue to reference the version that was in force at generation time.

Why don't I see SPDX and PDF downloads in the dropdown? They're part of the Enterprise CBOM evidence layer, re-rendered server-side from the same canonical CycloneDX bytes. On Core, requesting them returns a 402 with an upgrade message; on Enterprise they appear in the Download dropdown alongside CycloneDX.