SpeckBOM compilation manifest now supports two output formats:
- CycloneDX v1.6 JSON (OWASP/ECMA-424) — preferred for security tooling
- SPDX 3.0.1 JSON-LD (ISO 5962:2023) — preferred for regulated environments
Key changes:
- §4.5: Restructured as 'Compilation Manifest (SpeckBOM Output)' with dual format
support, comparison table (CycloneDX vs SPDX capabilities), both JSON examples,
and separate field mapping tables for each format
- Added compiler output section: --bom-format cdx|spdx|both (default: both)
- Appendix B restructured into 4 sections:
B.1 Provenance Graph (JSON-LD / PROV-O) — intent layer
B.2 SpeckBOM — CycloneDX v1.6 mapping table
B.3 SpeckBOM — SPDX 3.0.1 mapping table
B.4 Three-layer architecture: intent (PROV-O) + composition (CycloneDX or SPDX)
Rationale: Different regulators mandate different formats. DO-178C shops
need SPDX (ISO normative), security teams need CycloneDX (OWASP ecosystem).
Supporting both makes SpeckBOM universally adoptable.
Replace custom JSON-LD compilation manifest with valid CycloneDX v1.6
documents using bomType: specBOM and speckl: property namespace.
Key changes:
- §4.5: Compilation manifest now outputs CycloneDX v1.6 JSON
- Added 'Why CycloneDX' section comparing CycloneDX vs SPDX for this use case
- Full CycloneDX JSON example for DrugDosageCalculator
- Added CycloneDX field mapping table (SpeckDL primitive → CycloneDX location)
- Added path to standardization (community proposal → OWASP recognition)
- Appendix B restructured into three sections:
B.1 Provenance Graph (JSON-LD / PROV-O) — intent layer
B.2 SpeckBOM (CycloneDX v1.6) — composition layer
B.3 Two-Layer Architecture — how they complement each other
This extends an existing OWASP/ECMA-424 standard rather than defining
a bespoke format, ensuring compatibility with Dependency-Track and
the full CycloneDX tooling ecosystem.
New language features:
- bom {} block: declares toolchain dependencies (compiler, solver, runtime),
license, and content hash — the spec analog of an SBOM
- Import version pinning: hash and version on import statements for
reproducible builds and dependency integrity
- §3.6.6: SpeckBOM semantics — maps each bom clause to JSON-LD/SPDX
- §3.6.7: Import pinning semantics — hash verification at compile time
- §4.5: Compilation manifest — auto-generated audit-ready JSON-LD output
with spec hash, dependency integrity, toolchain versions, artifact hashes,
verification results, and reproducibility flag
- Updated EBNF grammar for bom_def and import hash/version
- Updated examples (InfusionPumpController shows bom block, PaymentService
shows import pinning)
- Updated Appendix B with SpeckBOM JSON-LD mappings
Together with existing DP primitives (provenance, review, derives, satisfies,
author, source), SpeckBOM provides the full picture: intent provenance +
composition manifest + verification evidence = audit-ready specification.
New language members: provenance, review, derives, satisfies, author, source
- provenance block: declare intent sources (regulation, design_decision, parent_spec, external_doc)
- review directive: mark verification boundaries (manual, auto, hybrid)
- derives/satisfies: spec-to-spec and spec-to-requirement edges
- author/source: who wrote it and what drove it
- Provenance-aware event semantics: runtime events trace back to intent
- Updated EBNF grammar, semantics, examples, and JSON-LD mapping
- Three new examples: regulated medical device, auto-verified service, compliance audit trail
- All primitives optional — Specks without provenance still compile fine
