The Omnipresent Bill of Materials: Full-Spectrum CycloneDX 1.6+ for Offline Systems Assurance

J. McKenney

This paper is part of the WG-10-AN Assurance Network body of work, establishing CycloneDX 1.6+ as the multi-dimensional bill-of-materials standard the rest of the network's procurement and attestation papers build on. It sits alongside WG-10-AN-08-Zero-Knowledge-Procurement-Attestations, which builds a zero-knowledge attestation layer on top of the CycloneDX graph this paper defines, and WG-10-AN-06-Supply-Chain-Transparency-Use-Cases, which walks through applied use cases of the same multi-BOM model.

Licence: CC BY 4.0. 17 September 2026.

Executive Abstract#

Every piece of industrial equipment is built from a chain of hardware, firmware, software and cryptographic components, and a security incident can start anywhere in that chain. A conventional software bill of materials lists only the software layer, leaving hardware, operational configuration, cryptography, and cloud services invisible to a security review.

This paper presents CycloneDX 1.6+, an open bill-of-materials standard, as a way to describe all five layers, hardware, software, operational configuration, cryptography, and services, in one connected, machine-readable graph. It shows how that graph can be built and verified inside a facility with no internet connection, using signed offline data exchanges carried across one-way hardware links, and tied to the facility's physical engineering drawings so a finding traces to an actual piece of equipment.

It maps the approach onto regulatory requirements emerging in the EU and in industrial cybersecurity standards, arguing that a five-dimensional bill of materials turns those requirements from a paperwork exercise into something a facility can verify.

Abstract#

Industrial control systems, embedded devices, and hyperscale compute environments face compounding supply chain vulnerabilities spanning silicon fabrication, firmware, network runtimes, and cryptographic algorithms. Traditional Software Bill of Materials (SBOM) formats such as SPDX were architected for open-source licensing compliance and lack the semantic breadth to describe cyber-physical systems.

This monograph presents OWASP CycloneDX 1.6+ as the omnipresent, full-stack bill of materials standard for mission-critical industrial systems assurance, formalizing five BOM dimensions: Hardware BOM (HBOM), Software BOM (SBOM), Operations BOM (OBOM), Cryptography BOM (CBOM), and Services/SaaS BOM (SaaSBOM). We model the multi-BOM dependency graph G_BOM as a directed acyclic graph (DAG) partitioned across those five vertex classes with typed dependency edges (Executes-On, Configured-By, Secured-By, Communicates-With). We detail how CycloneDX enables air-gapped, offline vulnerability and exploitability tracking across Purdue Level 1 and 2 networks using cryptographically signed Vulnerability Exploitability eXchange (VEX) and Vulnerability Disclosure Reports (VDR) transported across unidirectional hardware data diodes. Finally, we show how CycloneDX binds hardware silicon roots of trust (OCP Caliptra, TPM 2.0 DICE) to physical P&ID asset tags (ISO 15926 series / DEXPI 2.0), establishing the verified cyber half of the cyber-physical digital twin.

1. Beyond Software#

The Imperative for Full-Spectrum Systems Transparency

The architecture below summarizes how CycloneDX 1.6+'s five BOM dimensions connect hardware, software, operational, cryptographic and service-level components into a single verifiable graph.

Industrial automation, power generation, and hyperscale compute environments operate across deep vertical stacks of abstraction. In a modern liquid-cooled artificial intelligence cluster or an IEC 61850 electrical substation, an operational failure rarely originates from an isolated application bug. A catastrophic loss of cooling or a busbar breaker lockout can stem from:

1. An unpatched buffer overflow in an embedded microcontroller's lightweight TCP/IP stack (lwIP).
2. An untracked, insecure debugging interface left open in a Baseboard Management Controller (BMC) firmware image.
3. An expired or deprecated X.509 certificate within an internal microservices communication bus.
4. A misconfigured Modbus routing conduit bridging Purdue Level 2 supervisory networks directly to corporate enterprise VLANs.
5. A silicon-level erratum in a field-programmable gate array (FPGA) or physical unmeasured NOR flash memory.

Historically, software supply chain security has focused almost exclusively on application-layer package registries (e.g., Maven, npm, PyPI, and crates.io). Under United States Executive Order 14028 and European Union Regulation 2024/2847 (the Cyber Resilience Act, $\text{CRA}$), organizations are mandated to maintain machine-readable inventories for all digital products.

However, treating the bill of materials as a flat list of software dependencies is dangerously deficient for critical operational technology ($\text{OT}$):

• Blindness to Silicon & Hardware Microarchitecture: Software executes on physical silicon. If the Hardware Root of Trust ($\text{RoT}$), Baseboard Management Controller ($\text{BMC}$), or physical microcontroller stepping is omitted from the inventory, hardware-level backdoors and microarchitectural side-channel exploits remain completely invisible.
• Ignorance of Runtime Operational Context: Software libraries do not execute in an abstract void. Their real-world exploitability is dictated by network boundaries, firewall rules, listening ports, and physical process setpoints. A known critical remote code execution ($\text{RCE}$) vulnerability in a web server is harmless if the server is bound strictly to 127.0.0.1 and isolated behind an air gap.
• Cryptographic Blindness: With the commercial advent of quantum cryptanalysis and harvest-now-decrypt-later ($\text{HNDL}$) threats, critical systems require continuous, automated discovery of symmetric keys, asymmetric public key infrastructure, and post-quantum cryptographic ($\text{PQC}$) migration status.

2. The Five Dimensions of CycloneDX 1.6+#

OWASP CycloneDX 1.6+ resolves the structural limitations of legacy formats by providing a unified, extensible data model serialized natively in JSON, XML, and Protocol Buffers. It standardizes five distinct yet deeply interconnected BOM categories.

2.1 Hardware Bill of Materials ($\text{HBOM}$)#

CycloneDX represents physical components using the device and hardware component types. An $\text{HBOM}$ entry captures:

• Electronic Product Codes ($\text{EPC}$), serial numbers, and manufacturer part numbers.
• Board stepping, printed circuit board ($\text{PCB}$) layer revisions, and silicon errata.
• Hardware Roots of Trust, including Open Compute Project ($\text{OCP}$) Caliptra, TPM 2.0, and physical unclonable functions ($\text{PUF}$).

{
  "type": "device",
  "bom-ref": "cdu-mainboard-rev2.1",
  "name": "Cooling Distribution Unit Controller Board",
  "version": "Rev 2.1-B0",
  "supplier": {
    "name": "Tetrel Industrial Systems",
    "url": ["https://tetrel.com"]
  },
  "hashes": [
    {
      "alg": "SHA-256",
      "content": "8f4b2b7d4c28c8e1e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934c"
    }
  ],
  "properties": [
    { "name": "caliptra:root_of_trust", "value": "enabled" },
    { "name": "hardware:silicon_stepping", "value": "B0" },
    { "name": "dexpi:equipmentTag", "value": "CDU-101A" }
  ]
}

2.2 Software Bill of Materials ($\text{SBOM}$)#

Captures operating systems, kernel drivers, firmware binaries, and runtime libraries. Every component is uniquely identified using Package URLs ($\text{purl}$) and Common Platform Enumerations ($\text{CPE}$), with complete dependency trees:

{
  "type": "operating-system",
  "bom-ref": "os-freertos-10.4.3",
  "name": "FreeRTOS",
  "version": "10.4.3",
  "purl": "pkg:generic/freertos@10.4.3",
  "cpe": "cpe:2.3:o:amazon:freertos:10.4.3:*:*:*:*:*:*:*",
  "evidence": {
    "identity": {
      "field": "purl",
      "confidence": 1.0,
      "methods": [{ "technique": "binary-analysis" }]
    }
  }
}

2.3 Operations Bill of Materials ($\text{OBOM}$)#

$\text{OBOM}$ documents the operational runtime configuration of the system. In industrial systems, this captures network listener states, communication protocols, firewall filtering policies, and hard-coded engineering setpoints:

{
  "type": "data",
  "bom-ref": "obom-modbus-runtime-config",
  "name": "Purdue Level 2 Modbus TCP Configuration",
  "properties": [
    { "name": "network:listening_port", "value": "502" },
    { "name": "network:interface", "value": "eth0_isolated" },
    { "name": "iec62443:zone", "value": "Zone-Cell-02" },
    { "name": "iec62443:conduit", "value": "Conduit-L2-SCADA" },
    { "name": "control:max_temperature_cutoff", "value": "72.5" }
  ]
}

2.4 Cryptography Bill of Materials ($\text{CBOM}$)#

Standardized as a first-class citizen in CycloneDX 1.6, $\text{CBOM}$ provides automated inventory of cryptographic assets across four distinct object primitives:

1. cryptographic-assets: Algorithms, key sizes, block modes, and NIST/BSI security strength levels (e.g., AES-256-GCM, ML-KEM-768, ML-DSA-65).
2. keys: Key identifiers, hardware security module ($\text{HSM}$) handles, state (active, expired, compromised), and storage protections.
3. certificates: Complete X.509 certificate chains, subject alternative names ($\text{SAN}$), signing authorities, validity periods, and revocation mechanisms.
4. protocols: Network security protocols, cipher suites, TLS 1.3 parameters, and SSH configurations.

2.5 Services & SaaS Bill of Materials ($\text{SaaSBOM}$)#

Documents external network endpoints, telemetry feeds, and vendor cloud management portals. It records endpoint URIs, data flow directions, encryption requirements, and authentication mechanisms, exposing unauthorized telemetry channels in air-gapped facilities.

3. Mathematical Topology of the Multi-BOM Graph#

We formalize the full-stack system architecture as a heterogeneous directed acyclic graph:

Where the vertex set $V_{\text{BOM}}$ partitions into the five canonical BOM classes:

And the directed edge set $E_{\text{dep}}$ represents typed semantic dependencies:

We define four primary relationship operators:

• Executes-On ($e_{\text{exec}} \in V_{\text{SBOM}} \times V_{\text{HBOM}}$): Software binary $s$ executes on physical hardware $h$.
• Configured-By ($e_{\text{conf}} \in V_{\text{SBOM}} \times V_{\text{OBOM}}$): Runtime behavior of software $s$ is bounded by operational configuration $o$.
• Secured-By ($e_{\text{sec}} \in (V_{\text{SBOM}} \cup V_{\text{OBOM}}) \times V_{\text{CBOM}}$): Communication channel or binary integrity is attested by cryptographic key/algorithm $c$.
• Communicates-With ($e_{\text{comm}} \in V_{\text{OBOM}} \times V_{\text{SaaSBOM}}$): Local daemon connects to external service endpoint $w$.

4. Air-Gapped Offline Vulnerability Tracking via VEX and VDR#

A fundamental engineering constraint in critical utilities, nuclear facilities, and classified defense networks is strict adherence to the Purdue Model air gap. Level 1 (sensing and manipulation) and Level 2 (supervisory control) industrial networks have no direct internet connectivity. They cannot query the National Vulnerability Database ($\text{NVD}$) or cloud software scanners in real time.

CycloneDX solves this operational dilemma through deterministic, offline-native artifacts: Vulnerability Exploitability eXchange ($\text{VEX}$) and Vulnerability Disclosure Reports ($\text{VDR}$).

4.1 Formal VEX State Machine#

A vendor or internal security research group publishes a cryptographically signed VEX document declaring the precise exploitability state of a Common Vulnerabilities and Exposures ($\text{CVE}$) identifier within a specific component:

1. not_affected: The component contains the vulnerable library, but the vulnerable function or execution path is completely unreachable, or compensated by hardware controls.
2. affected: The vulnerability is reachable and exploitable; immediate maintenance or isolation is required.
3. fixed: The vulnerability has been patched in the active version.
4. under_investigation: The vendor is currently conducting static/dynamic call graph analysis.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "version": 1,
  "vulnerabilities": [
    {
      "id": "CVE-2024-38812",
      "source": { "name": "NVD", "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38812" },
      "analysis": {
        "state": "not_affected",
        "justification": "code_not_reachable",
        "detail": "Vulnerable directory traversal daemon is omitted during compile-time linking of the RTOS build target."
      },
      "affects": [
        { "ref": "os-freertos-10.4.3" }
      ]
    }
  ]
}

4.2 Offline Graph Reachability Algorithm#

When a validated VEX file is ingested across the unidirectional diode, the air-gapped assessment engine runs a local topological query without emitting a single outbound network packet:

Where $\text{PathExists}(u, v, G_{\text{BOM}})$ evaluates whether a directed conduit path exists from an external boundary node to the target software component through the operational topology ($\text{OBOM}$). If no network route exists, or if the VEX justification proves code unreachability, the operational risk is suppressed, preventing unnecessary emergency shutdowns of running continuous processes.

5. Hardware Root-of-Trust Integration: OCP Caliptra & TPM 2.0 DICE#

A Software Bill of Materials is only as trustworthy as the platform that boots it. If an attacker with physical or low-level access flashes a compromised bootloader into SPI flash memory, software-based integrity assertions become completely untrustworthy.

CycloneDX 1.6+ resolves this by binding the $\text{HBOM}$ directly to hardware-measured attestation chains using the Device Identifier Composition Engine ($\text{DICE}$) and the Open Compute Project's Caliptra Silicon Root of Trust.

5.1 DICE Mathematical Formulation#

The root identity begins in silicon with an immutable Unique Device Secret ($\text{UDS}$), burned into one-time programmable ($\text{OTP}$) fuses or generated by a physical unclonable function:

Every transition produces an asymmetric keypair $(\text{Priv}_k, \text{Pub}_k)$ and an Alias Certificate signed by $\text{Priv}_{k-1}$. The resulting leaf certificate and cryptographic quote are recorded in the CycloneDX component evidence.identity block, providing mathematical proof of silicon authenticity.

6. The Cyber-Physical Bridge: DEXPI 2.0 Physical Tag Binding#

The most significant advance of CycloneDX 1.6+ in critical infrastructure is its ability to bridge cyber assets to physical engineering schematics. Traditional cybersecurity stops at the IP address or host name. Industrial plant engineers think in terms of Process & Instrumentation Diagrams (P&ID) governed by the ISO 15926 series and DEXPI 2.0.

In the Eigenia architecture formulated by J. McKenney, CycloneDX components embed physical plant tags as native metadata properties:

When an engineering change notice ($\text{ECN}$) modifies a physical pipe diameter in DEXPI 2.0, the digital twin automatically verifies that the underlying variable frequency drive firmware ($\text{SBOM}$) possesses the correct torque curves and frequency limits in its operational configuration ($\text{OBOM}$).

7. Regulatory Harmonization: EU CRA, IEC 62443, and NIS2#

Implementing the omnipresent CycloneDX 1.6+ architecture directly satisfies the most stringent emerging global cybersecurity mandates:

8. Conclusion#

The cybersecurity of critical cyber-physical infrastructure cannot survive on fragmented, software-only inventories. By transcending traditional flat SBOM formats, OWASP CycloneDX 1.6+ provides the five-dimensional semantic architecture required to secure industrial assets across their complete lifecycle.

Through the integration of hardware roots of trust (OCP Caliptra, TPM DICE), air-gapped offline VEX/VDR analysis, and bidirectional bindings to DEXPI 2.0 physical engineering topologies, the framework established by J. McKenney and Eigenia achieves true systems assurance. Critical infrastructure operators can now maintain 100 percent continuous supply chain visibility inside air-gapped facilities, transform compliance from a manual burden into an automated verification pipeline, and safeguard physical operations against compounding multi-layer attacks.

9. References#

The technical claims above rest on the standards applied in the body text: the OWASP CycloneDX 1.6+ specification and its HBOM, SBOM, OBOM, CBOM and SaaSBOM dimensions, SPDX for comparison, the OCP Caliptra and TPM 2.0 DICE hardware root-of-trust specifications, DEXPI 2.0 and the ISO 15926 series for the physical engineering topology binding, US Executive Order 14028, EU Regulation 2024/2847 (the Cyber Resilience Act), IEC 62443, and NIS2. The standards comparison table in section 7 summarizes publicly published standards rather than a claims history or a measured deployment.