Proposal: Extend CycloneDX model to support hardware-software interface semantics

[devashridatta-dotcom]

Summary

Current CycloneDX specifications provide strong support for representing software components, dependencies, and vulnerability metadata. However, for cyber-physical systems (embedded, automotive, aerospace, industrial IoT), there is a missing semantic layer: explicit representation of hardware-software interface contracts.

This includes interactions such as:

• Memory-Mapped I/O (MMIO)
• Hardware register mappings
• Interrupt interfaces
• DMA channels
• Firmware-to-RTL lineage (e.g., High-Level Synthesis flows)

We refer to this missing abstraction as an Interface Bill of Materials (IBOM) concept.

##Problem Statement

SBOM and HBOM artifacts exist independently, but CycloneDX currently lacks a structured way to represent:

• relationships between firmware binaries and hardware registers
• interface-level dependencies between software drivers and RTL modules
• lifecycle changes in hardware-software contracts across updates
• temporal validity of hardware-software interfaces (e.g., FPGA reconfiguration)

As a result, interface-level risks such as firmware-to-gate contract drift cannot be represented or analyzed using existing BOM structures.

Proposed Direction (Non-normative)

Rather than introducing a new BOM type, this proposal suggests exploring whether CycloneDX extension mechanisms can represent interface semantics using:

• component properties
• externalReferences
• relationship metadata
• graph-like dependency extensions

Example (Illustrative Only)

{
  "type": "firmware-interface",
  "name": "UART_MMIO_Interface",
  "properties": [
    {
      "name": "mmio.baseAddress",
      "value": "0x40001000"
    },
    {
      "name": "register",
      "value": "UART_STATUS:0x04:read-only"
    }
  ],
  "relatedComponents": [
    "uart_driver.c",
    "uart_controller.v"
  ]
}

[stevespringett]

Thanks for the request. CycloneDX v2.0 is dramatically improving its hardware support, but this proposal is currently beyond the scope of what we're currently targeting. You may want to join the hardware feature working group at some point to provide additional context for the other folks in the group.

\https://cyclonedx.org/participate/working-groups/

[devashridatta-dotcom]

Thank you, Steve.

I appreciate the clarification regarding the v2.0 scope and the ongoing improvements to hardware support.

The motivation behind this proposal is to represent the operational interfaces between hardware and software components (e.g., drivers, firmware interfaces, MMIO regions, buses, IPC mechanisms, and trust boundaries) that are not explicitly captured in current BOM models but are increasingly important for cyber-physical supply chain assurance.

I understand this may be beyond the immediate v2.0 goals. I would be interested in joining the hardware feature working group to better understand the roadmap and discuss whether these concepts could be explored as an extension or future enhancement.

Thanks again for the guidance.

Best regards,
Devashri Datta

[devashridatta-dotcom]

Proposal: Extend CycloneDX to Represent Interface Contracts and Trust Boundaries Between Hardware and Software Components

Summary

CycloneDX provides strong modeling for software, hardware, services, and dependencies. However, in cyber-physical systems, a critical missing layer exists: explicit representation of interface contracts and trust boundaries between execution domains.

This proposal explores whether CycloneDX can represent this interface layer using existing extension mechanisms, without introducing a new BOM type.

We note that CycloneDX v2.0 is extending hardware component support. This proposal is intended to complement that work by addressing the interface layer between hardware and software components, which is distinct from component inventory.

Motivation

In embedded systems, automotive, aerospace, and industrial control environments, system risk is often introduced not at the component level, but at the interfaces between components and execution domains.

Examples include:

• Firmware ↔ hardware register interfaces (MMIO)
• Interrupt and DMA channels crossing privilege boundaries
• Driver ↔ FPGA or ASIC interfaces
• Bus-level communication (PCIe, CAN, SPI, I2C)
• Firmware ↔ RTL lineage in HLS flows
• Cross-domain trust boundaries (kernel ↔ peripheral, user-space ↔ device firmware)

While CycloneDX captures components and dependencies, it does not explicitly model interface contracts or trust boundaries as first-class entities.

Problem Statement

CycloneDX currently models relationships between BOM components using dependency edges. However, it cannot represent:

1. Interface contracts between heterogeneous domains

   • software ↔ hardware
   • firmware ↔ RTL
   • driver ↔ accelerator

2. Trust boundaries between execution environments

   • kernel-to-peripheral isolation boundaries
   • privileged DMA access paths

3. Structural absence of interface entities

   • interfaces are not first-class BOM objects
   • relationships exist only between components, not interface contracts

4. Temporal validity of interfaces

   • FPGA reconfiguration cycles
   • firmware-hardware co-evolution
   • driver compatibility drift across revisions

As a result, interface-level risks such as DMA privilege escalation paths or firmware-to-gate contract drift cannot be directly represented.

Proposed Direction (Non-Normative)

This proposal explores representing interface semantics using existing CycloneDX extension mechanisms:

• component properties
• externalReferences
• relationship metadata
• dependency graph extensions

Illustrative Example

{
  "interface": {
    "id": "IF-UART-001",
    "name": "UART_MMIO_Interface",
    "type": "mmio",
    "trustBoundary": "kernel-to-peripheral",

    "temporalValidity": {
      "validFrom": "hw-rev-1.0",
      "lastVerified": "2026-05-15"
    },

    "properties": [
      { "name": "mmio.baseAddress", "value": "0x40001000" },
      { "name": "mmio.sizeBytes", "value": "256" },

      { "name": "register.name", "value": "UART_STATUS" },
      { "name": "register.offset", "value": "0x04" },
      { "name": "register.access", "value": "read-only" },
      { "name": "register.width", "value": "32" }
    ],

    "relatedComponents": [
      {
        "ref": "pkg:generic/uart-driver@2.1.0",
        "role": "DEPENDS-ON"
      },
      {
        "ref": "uart_controller.v",
        "role": "IMPLEMENTS"
      }
    ]
  }
}

This example demonstrates:

* explicit interface identity
* structured MMIO/register semantics
* typed relationships between software and hardware artifacts
* temporal validity for hardware-software contract evolution

## AI / Accelerator Interface Example

In AI-enabled embedded systems, similar interface contracts exist between accelerators and host drivers.

For example:

* AXI4-Stream interface between an NPU and host driver
* Tensor shape contract (e.g., [1, 224, 224, 3])
* DMA buffer layout expectations
* Interrupt latency bounds for inference completion

These constraints are critical for correctness and safety, but are not currently represented in SBOM or HBOM artifacts.

## Relationship to Existing BOMs

This proposal does not introduce a new BOM type.

It explores whether interface semantics can be modeled within CycloneDX’s existing extension system as an Interface Bill of Materials (IBOM)-like concept.

Existing CycloneDX dependency relationships are defined between component BOM references. Interface contracts require relationships between a software component and a hardware interface specification that has no current BOM reference, making the interface layer structurally distinct from component-level dependencies.

## Closing Note

This proposal complements CycloneDX v2.0 hardware work by focusing specifically on the interaction layer between components. The intent is not to redefine scope, but to explore whether interface-level semantics, particularly across hardware/software trust boundaries, can be expressed within the existing extensibility model.