Summary
OpenSSF's current artifact ecosystem (SLSA, SBOM, GUAC, in-toto, Sigstore)
provides strong provenance guarantees for software build pipelines. For
cyber-physical systems embedded, automotive, FPGA-based, and AI-accelerated
a structural gap remains: the interface contracts between firmware and hardware
(MMIO regions, registers, interrupt vectors, DMA channels, HLS synthesis lineage)
are not representable in any existing OpenSSF artifact format.
This gap has material policy consequences: the June 2026 AI/Cybersecurity EO's
CISA clearinghouse for AI-assisted vulnerability scanning operates on
SBOM-visible components only interface-level vulnerabilities fall entirely
outside its effective discovery scope.
The Three Specific Gaps in Current OpenSSF Tooling
1. SLSA provenance stops at the software build boundary.
There is no SLSA schema for High-Level Synthesis (HLS) compilation steps
where a software function (C/C++) is compiled directly into hardware RTL,
generating MMIO register maps that firmware depends on. A single change in
an HLS optimization flag (e.g., enabling loop pipelining) can silently shift
a hardware register offset, breaking firmware that was correctly signed and
passed all SBOM checks. SLSA cannot represent this provenance step.
2. GUAC has no node type for hardware registers or MMIO interface contracts.
GUAC can ingest SBOM, SLSA, and scorecard data, but cannot answer:
"Does CVE-X in software component Y have a write path to safety-critical
hardware register Z?" The hardware interface layer MMIO regions,
interrupt vectors, DMA channels is absent from GUAC's graph model.
3. in-toto link metadata has no defined schema for hardware compilation provenance.
The HLS compilation chain (software source → HLS toolchain → RTL module →
MMIO interface → firmware driver) crosses the software-hardware domain boundary.
in-toto's materials and products fields have no defined semantics for
hardware register maps as compilation outputs.
Proposed Solution: Interface Bill of Materials (IBOM)
We propose the Interface Bill of Materials (IBOM) as a complementary
OpenSSF artifact class addressing this gap.
IBOM defines a Hardware-Software Interaction Graph (HSIG = (V, E, P)) with:
- 8 typed edge classes: IMPLEMENTS, EXPOSES, CONSUMES, GENERATED-FROM,
DEPENDS-ON, TRUST-BOUNDARY, RECONFIGURES, VALIDATES
- 6 node layers (L0 Assessment Artifacts → L5 RTL/Hardware Modules)
- Formal drift detection: Δ(HSIG_t, HSIG_t+1) with six severity-classified
drift event categories
- PURL-based cross-referencing to existing SBOM and HBOM artifacts (BOM triad)
The central novel contribution is the GENERATED-FROM edge: linking a software
source function through a versioned HLS compilation chain (tool version,
optimization flags hash, target device) to the hardware register map it produces.
This edge type cannot be expressed in any existing CycloneDX, SPDX, or in-toto
construct confirmed by CycloneDX maintainer Steve Springett, who labeled a
related proposal (Issue #959, June 2026) as a "proposed core enhancement"
and referred it to the Hardware Feature Working Group.
IBOM Integration Points with Existing OpenSSF Projects
| OpenSSF Project |
Integration Path |
| SLSA |
GENERATED-FROM edge extends SLSA provenance into HLS synthesis steps |
| GUAC |
IBOM as a native GUAC data source type; enables hardware-register graph queries |
| in-toto |
GENERATED-FROM synthesis-chain block maps to in-toto materials/products |
| Sigstore |
IBOM documents can be signed and verified via Sigstore's transparency log |
Questions for the TAC Community
-
Should IBOM be proposed as a formal OpenSSF Sandbox project or SIG,
or is integration into an existing project (GUAC, SLSA) the preferred path?
-
Is the SLSA provenance framework an appropriate home for HLS synthesis
step attestation, or does this require a separate schema extension?
-
Are there existing OpenSSF members or working groups focused on embedded,
automotive, or industrial supply chain security who should be included
in this discussion?
-
Would the TAC consider IBOM as a candidate for the OpenSSF Sandbox
given the existing prototype implementation and standards body engagement?
Summary
OpenSSF's current artifact ecosystem (SLSA, SBOM, GUAC, in-toto, Sigstore)
provides strong provenance guarantees for software build pipelines. For
cyber-physical systems embedded, automotive, FPGA-based, and AI-accelerated
a structural gap remains: the interface contracts between firmware and hardware
(MMIO regions, registers, interrupt vectors, DMA channels, HLS synthesis lineage)
are not representable in any existing OpenSSF artifact format.
This gap has material policy consequences: the June 2026 AI/Cybersecurity EO's
CISA clearinghouse for AI-assisted vulnerability scanning operates on
SBOM-visible components only interface-level vulnerabilities fall entirely
outside its effective discovery scope.
The Three Specific Gaps in Current OpenSSF Tooling
1. SLSA provenance stops at the software build boundary.
There is no SLSA schema for High-Level Synthesis (HLS) compilation steps
where a software function (C/C++) is compiled directly into hardware RTL,
generating MMIO register maps that firmware depends on. A single change in
an HLS optimization flag (e.g., enabling loop pipelining) can silently shift
a hardware register offset, breaking firmware that was correctly signed and
passed all SBOM checks. SLSA cannot represent this provenance step.
2. GUAC has no node type for hardware registers or MMIO interface contracts.
GUAC can ingest SBOM, SLSA, and scorecard data, but cannot answer:
"Does CVE-X in software component Y have a write path to safety-critical
hardware register Z?" The hardware interface layer MMIO regions,
interrupt vectors, DMA channels is absent from GUAC's graph model.
3. in-toto link metadata has no defined schema for hardware compilation provenance.
The HLS compilation chain (software source → HLS toolchain → RTL module →
MMIO interface → firmware driver) crosses the software-hardware domain boundary.
in-toto's
materialsandproductsfields have no defined semantics forhardware register maps as compilation outputs.
Proposed Solution: Interface Bill of Materials (IBOM)
We propose the Interface Bill of Materials (IBOM) as a complementary
OpenSSF artifact class addressing this gap.
IBOM defines a Hardware-Software Interaction Graph (HSIG = (V, E, P)) with:
DEPENDS-ON, TRUST-BOUNDARY, RECONFIGURES, VALIDATES
drift event categories
The central novel contribution is the GENERATED-FROM edge: linking a software
source function through a versioned HLS compilation chain (tool version,
optimization flags hash, target device) to the hardware register map it produces.
This edge type cannot be expressed in any existing CycloneDX, SPDX, or in-toto
construct confirmed by CycloneDX maintainer Steve Springett, who labeled a
related proposal (Issue #959, June 2026) as a "proposed core enhancement"
and referred it to the Hardware Feature Working Group.
IBOM Integration Points with Existing OpenSSF Projects
materials/productsQuestions for the TAC Community
Should IBOM be proposed as a formal OpenSSF Sandbox project or SIG,
or is integration into an existing project (GUAC, SLSA) the preferred path?
Is the SLSA provenance framework an appropriate home for HLS synthesis
step attestation, or does this require a separate schema extension?
Are there existing OpenSSF members or working groups focused on embedded,
automotive, or industrial supply chain security who should be included
in this discussion?
Would the TAC consider IBOM as a candidate for the OpenSSF Sandbox
given the existing prototype implementation and standards body engagement?