Skip to content
HypermediaHypermedia Security Hub

Hypermedia Security: Case Provenance BOM Specification

v1.0.0Hypermedia AuL1

Case Provenance BOM (versioned, sealed catalog; frozen vN = case-of-record)

Published 2026-07-11. By Hypermedia Au Security Team. Serial urn:uuid:56ddde38-9750-45dd-87db-31d791439f7b

The L1 Case Provenance BOM: the signed, versioned catalog of everything in a case — the spine every other object hangs off. One document per case, born at the ingest-seal (version 1), re-issued and re-signed at every seal, frozen at the finalisation-seal as the portable case-of-record. It enumerates every artifact entry, mirrors derivation lineage, pins the custody chain, and is the resolution target for finding input references and publication catalog pins. ISO/IEC 27043 frames chain-of-custody preservation as a concurrent process running from incident detection until the last process; this document is where that process's record is catalogued and sealed.

Validate against: /schemas/case-provenance/v1.schema.json

Download raw JSON

Relationships

References

Referenced by

About this standard

hyper-spec:artifactKind
BOM (L1 — the case catalog / custody ledger)

Sources

cyclonedx.org
CycloneDX 1.7 schema — the signature property is an 'Enveloped signature in JSON Signature Format (JSF)'; dependencies[].ref 'references a component or service by its bom-ref attribute' and dependsOn lists 'the bom-ref identifiers of the components or services that are dependencies of this dependency object'
ecma-international.org
ECMA-424 2nd edition (December 2025) — the CycloneDX 1.7 BOM specification
www.iso.org
ISO/IEC 27043:2015: §11.5 Preserving chain of custody (a concurrent process performed from incident detection until the last process); §11.1 (concurrent processes run throughout to assure admissibility); §11.4 (offers trusted PKI and time stamping as its example of protecting investigative information flow — identifying investigators and authenticating evidence); §3.6 (the definition of digital investigation embeds maintaining the chain of custody); §12 (custody preservation begins with real evidence handling). 27043's Clause 3 sources its evidence vocabulary from ISO/IEC 27037:2012 — the record-content detail cited by custody-chain/v1
www.rfc-editor.org
RFC 2119 (as clarified by RFC 8174) — requirement key words; only capitalised forms are normative
sec.hypermedia.au
website

CPRV-001 CycloneDX Document MUST

checked: schema

A Case Provenance BOM MUST be a CycloneDX 1.7 BOM with bomFormat 'CycloneDX', specVersion '1.7', a urn:uuid serialNumber stable across all versions of the case, a positive integer version, metadata.timestamp (ISO-8601) and metadata.component naming the catalog.

The serialNumber is the case catalog's permanent identity: BOM-Links from every other object (urn:cdx:<serialNumber>/<version>#<bom-ref>) resolve against it. It never changes across seals; only the version advances.

CPRV-002 Versioned Per Seal MUST NOT

checked: schema

The version MUST increase by exactly one at every seal and MUST NOT change between seals. hyper-spec:sealType MUST be exactly one of: ingest, interim, finalisation (closed set). Version 1 MUST be produced by the ingest-seal. Between seals the document MUST NOT be re-signed or altered — custody events append to the ledger without touching the catalog.

Seals are checkpoints that snapshot-and-sign whatever state exists, not the moments objects are created. The publication-seal defined in the case taxonomy signs a Publication (L3), not a catalog version — which is why it is not a value here.

allowed-values
ingest
allowed-values
interim
allowed-values
finalisation
vocabulary
closed

CPRV-003 Component Enumeration MUST

checked: corpus-comparison

components[] MUST enumerate every artifact entry in the case corpus at the moment of the seal — every piece of evidence and every derived artifact, each conforming to artifact-entry/v1. Nothing in the corpus may be absent from the sealed catalog.

The catalog is the complete signed index: the seal binds every hash, which is why individual entries carry no signatures of their own. Completeness at seal is independently attested by the case-catalog/v1 attestation.

component-standard
https://sec.hypermedia.au/standards/artifact-entry/v1

CPRV-004 Lineage Dependencies SHOULD

checked: cross-reference

dependencies[] SHOULD mirror every derivation edge in the corpus: for each derived artifact, an entry whose ref is the derived entry's bom-ref and whose dependsOn lists its source evidence bom-ref, matching the entry's own hyper-spec:sourceEvidenceRef.

CycloneDX's dependency graph (ref → dependsOn, both by bom-ref) is the document-level mirror of the per-entry lineage property — one fact, readable from either end, expressing the W3C PROV derivation in native CycloneDX.

CPRV-005 Custody Pin MUST

checked: cross-reference

hyper-spec:custodyChainRef and hyper-spec:caseCatalogRef MUST both be present in every version, and each MUST resolve (BOM-Link + paired hash) to its attestation: custodyChainRef to a custody-chain/v1 attestation whose claim targets this catalog, caseCatalogRef to a case-catalog/v1 attestation whose claim targets this version.

ISO/IEC 27043 §11.5 defines preserving the chain of custody as a concurrent process performed from incident detection until the last process, and §3.6 writes maintaining the chain of custody into the very definition of a digital investigation — which is why this pin is a MUST on every version, not a finalisation nicety. The custody record's field-level contents are governed by custody-chain/v1 (whose sources sit in ISO/IEC 27037 §6.1, the acquisitive-stage standard 27043's own vocabulary builds on).

target-standard
https://sec.hypermedia.au/standards/custody-chain/v1
iso-basis
ISO/IEC 27043 §11.5 + §3.6 (concurrent process, definition-level custody)

CPRV-006 Sidecar References MUST NOT

checked: schema

The seal token reference (hyper-spec:sealTsaTokenRef, every seal) and the Evidence Record reference (hyper-spec:evidenceRecordRef, finalisation) MUST be recorded in the sidecar index keyed by this document's serialNumber and version, and MUST NOT appear as properties inside the sealed document. A verifier MUST treat their presence inside a sealed catalog as a broken seal.

Both artifacts are created after the seal signature and cover it — the token proves the signature's moment, and the Evidence Record's leaves include the signed document itself. Writing either reference into the document would require editing it after signing (breaking the seal) or a hash cycle (each containing the other's digest). The references are locators with no evidential weight: verification starts at the Evidence Record and the token and works inward — they prove the catalog, never the reverse.

sidecar-index
Timestamps/index.json

CPRV-007 Transparency Reference MUST NOT

checked: profile-conditional

A transparency receipt reference MUST NOT appear in the sovereign default. It MUST be present as an externalReferences entry, per transparency-receipt/v1, only when a cross-org TransparencyLog implementation is wired. A verifier under the sovereign profile MUST treat its absence as correct, never as missing.

A cross-org matter carries a transparency receipt reference in externalReferences; a sovereign matter carries none. Enabling transparency changes which TransparencyLog implementation is wired, not the document schema.

target-standard
https://sec.hypermedia.au/standards/transparency-receipt/v1

CPRV-008 Seal Signature MUST

checked: cryptographic-signature

Every sealed version MUST carry an enveloped JSF signature (ES384 or ES512, Fulcio keyless) over the document, and metadata.authors[] MUST match the identity in the signing certificate. Every seal signature MUST be covered by that seal's RFC 3161 token proving it was created within the ephemeral certificate's validity window (timestamp-token/v1 #cert-window-proof).

CycloneDX 1.7 defines the signature property as an enveloped signature in JSON Signature Format (JSF) — the seal is native to the document format, not a wrapper. The identity-plus-external-time pairing is what ISO/IEC 27043 §11.4 offers as its example of protecting investigative information flow: trusted PKI and time stamping to identify the different investigators and authenticate evidence. Identity comparisons are made between Fulcio-verified identities, never name strings.

iso-basis
ISO/IEC 27043 §11.4 (trusted PKI + time stamping endorsement)

CPRV-009 Frozen At Finalisation MUST NOT

checked: chain-verification

The finalisation-seal produces the final version: the corpus closes, the Evidence Record is built over it, and no further catalog version may be issued for the case. References into any version remain valid forever and MUST NOT be rewritten as versions advance: the version in a BOM-Link only locates; the paired contentHash proves the bytes. An object citing the catalog MUST cite the version current at its own creation time.

Reference survival is why continuous work and versioned sealing coexist: a finding promoted while the catalog stood at version 2 cites …/2#evidence-001, and that reference still proves the same bytes when the catalog freezes at version N, because evidence is immutable and the hash never changes. The frozen final version is the portable case-of-record the Publication pins.

CPRV-010 Case Identity MUST

checked: schema

hyper-spec:caseId MUST be present and identical across all versions. hyper-spec:corpusSize SHOULD state the component count at seal. hyper-spec:rslHead MAY carry the gittuf Reference State Log head commit at seal time, only where gittuf is enabled.

caseId is the human/case-management join; serialNumber is the cryptographic one. corpusSize is a cheap self-consistency check a verifier can test against components[].length before doing any hashing.