Hypermedia Security: Publication BOM Specification
v1.0.0Hypermedia AuL3
Publication BOM (typed, versioned, frozen on delivery; composes approved findings over the frozen catalog)
The L3 Publication BOM: the signed disclosure — the externally-facing artifact of record. It binds the rendered report to exactly the findings it discloses (compositions with aggregate complete: CycloneDX's own statement that no further constituents exist) and to the frozen finalised catalog it was written from. Publications are typed (an open list seeded with exec-summary and technical-report), versioned (draft to approved), and frozen on delivery — a revision is a new superseding version, never an edit. Release is gated by publish-approval/v1: a second identity, distinct from the report author, signs the disclosure decision.
Validate against: /schemas/publication/v1.schema.json
Relationships
References
- references →Hypermedia Security: Case Provenance BOM Specification
- references →Hypermedia Security: Finding BOM Specification
- target-standard →Hypermedia Security: Case Provenance BOM Specification
- disclosability →Hypermedia Security: Finding Approval Specification
- checker-standard →Hypermedia Security: Publish Approval Specification
Referenced by
- Hypermedia Security: Publish Approval Specification(references)
- Hypermedia Security: Publish Approval Specification(composition-standard)
About this standard
- artifact-kind
- BOM (L3 — the signed disclosure; 1..P per case)
Sources
- cyclonedx.org
- CycloneDX 1.7 — verified from the schema file 2026-07-11: compositions aggregate 'complete' = 'the relationship is complete. No further relationships including constituent components, services, or dependencies are known to exist'; assemblies = 'the bom-ref identifiers of the components or services being described'
- www.iso.org
- ISO 21043-5:2025 (Forensic sciences — Part 5: Reporting; published June 2025, Edition 1) — cited at title/scope level (clause text not verified first-hand): specifies requirements for reports that are accurate, clear, transparent, complete, unambiguous, impartial and suitable for their intended use, including review of case records and reports, issuance and control of reports, and testimony
- www.rfc-editor.org
- RFC 2119 (as clarified by RFC 8174) — requirement key words; only capitalised forms are normative
- sec.hypermedia.au
- website
PUBL-001 CycloneDX Document MUST
A Publication BOM MUST be a CycloneDX 1.7 BOM with bomFormat 'CycloneDX', specVersion '1.7', a urn:uuid serialNumber, a positive integer version, metadata.timestamp (ISO-8601), and metadata.component naming the publication. The version advances through the draft-to-approved review loop and on supersession.
The serialNumber is the publication's permanent identity across its versions; publish-approval claims and delivery records resolve against it.
PUBL-002 Publication Identity MUST
metadata MUST carry cyberbench:caseId and cyberbench:publicationType. The type vocabulary is OPEN, seeded with exec-summary and technical-report; new types MAY be added without a version bump. Any version greater than 1 MUST additionally carry cyberbench:supersedes: the BOM-Link and paired hash of the publication version it replaces.
Both cyberbench:publicationType and cyberbench:supersedes are additions beyond the original Content-Spec field list, made deliberately: the case taxonomy defines publication types and requires each revision to link back to the version it replaces, but no L3 field carried either. The supersedes link must be explicit at this layer because delivered publication versions coexist — several reports of different types and versions can exist for one case, and the chain between them is part of the record. (Proposed in the SPEC-12 ticket per the epic's approved gap plan; not vetoed at review.)
- type-seed-values
- exec-summarytechnical-report
- type-vocabulary
- open
- supersedes-condition
- MUST when version > 1
- field-origin
- proposed fields per the approved gap plan (epic confirm item 3, SPEC-12 ticket 2026-07-11)
PUBL-003 Report Document MUST
components[] MUST carry exactly one data component: the rendered report, with a SHA-256 hash of its delivered bytes.
The hash is the delivered report's integrity anchor — what the publish-approval approves, what the recipient can verify, and what the Evidence Record covers. The reporting duties this document discharges are those of ISO 21043-5:2025 (Forensic sciences — Reporting): reports accurate, clear, transparent, complete, unambiguous, impartial and suitable for their intended use, with controlled issuance — cited at scope level; the clause text was not verified first-hand.
- iso-basis
- ISO 21043-5:2025 (title/scope level)
PUBL-004 Catalog Pin MUST NOT
metadata MUST carry cyberbench:finalisedCatalogRef, resolving (BOM-Link + paired hash) to the FINALISATION version of the case's Case Provenance BOM. A publication MUST NOT pin an interim catalog version.
The disclosure is bound to the closed corpus: the frozen case-of-record whose Evidence Record already covers every hash. Pinning an interim version would mean disclosing against an evidence base that could still grow — the finalisation-only rule keeps 'what was the report written from' a closed question.
PUBL-005 Complete Composition MUST
compositions[] MUST carry aggregate 'complete' with assemblies naming, by BOM-Link, exactly the findings the report discloses. Every composed finding MUST be disclosable: it MUST carry a current terminal finding-approved from an identity distinct from its author (verifier-enforced at composition). A finding MAY appear in more than one publication.
aggregate 'complete' is CycloneDX's own completeness statement — no further constituents are known to exist — so 'the report contains exactly these findings and nothing undisclosed' is carried by the format's documented semantics, not by convention. The disclosability condition is the finding-approval invariant applied at the moment of composition.
- aggregate
- complete (const)
- disclosability
- https://sec.hypermedia.au/standards/finding-approval/v1#supersession-and-invariant
PUBL-006 Author Signature MUST
The Publication BOM MUST carry an enveloped JSF ES256 signature by the report author. The release decision MUST be signed by a different identity (publish-approval/v1, approver distinct from author, Fulcio-verified).
The same maker-checker shape as findings, at the release boundary: the author signs what the report is; a distinct approver signs that it may leave the enclave.
- checker-standard
- https://sec.hypermedia.au/standards/publish-approval/v1
PUBL-007 Versioning And Delivery MUST NOT
Publication versions run draft to approved: each version is a signed object, and a changes-requested review outcome produces a new version linking to its predecessor via cyberbench:supersedes. A DELIVERED publication is FROZEN: it MUST NOT change after delivery; any revision MUST be a new superseding version. Superseded and rejected versions MUST be retained, never edited or deleted.
Delivered-is-frozen is what makes 'which report did you give them' a question with one answer. Several publications can exist per case (different types, and versions within each); the supersedes chain plus the retained history keeps every delivered artifact accountable. ISO 21043-5's issuance-and-control-of-reports duty is discharged by exactly this discipline.
- trigger
- publish-approval/v1 changes-requested
- iso-basis
- ISO 21043-5:2025 issuance and control of reports (title/scope level)