Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
PlatformBOM Compliance

Every BOM type. One platform.

SBOM, CBOM, AIBOM, HBOM, QBOM — O3 generates, manages, and keeps every bill of materials current as your software evolves. One platform for every compliance mandate your team faces, now and as regulations mature.

BOM Compliance Dashboard
5 BOM types active
SBOMEO 14028 · EU CRA · DoD
2 min ago·248 components
Current
CBOMNIST PQC · FIPS 140-3
2 min ago·34 components
Current
AIBOMEU AI Act
2 min ago·4 components
Drift detected
HBOMIEC 62443 · NERC CIP
4 hr ago·47 components
Current
QBOMNSA CNSA 2.0 · DoD
2 min ago·34 components
Current
All BOM Types

Every regulation. One platform.

Regulators keep adding BOM requirements. O3 adds support before the mandate hits.

SBOM (CycloneDX + SPDX)

Software Bill of Materials in CycloneDX 1.4/1.5/1.6 and SPDX 2.3 formats. Meets NTIA minimum elements, EO 14028, EU CRA, and DoD requirements.

CBOM (cryptographic inventory)

Cryptographic Bill of Materials covering every algorithm, key, certificate, and protocol across source code, binaries, and configurations.

AIBOM (AI model inventory)

AI Bill of Materials inventorying every model, dataset, and ML dependency. Required for EU AI Act transparency obligations and risk classification.

HBOM (hardware components)

Hardware Bill of Materials covering CPUs, firmware, chipsets, and embedded controllers — with vulnerability correlation for known hardware CVEs.

QBOM (quantum readiness)

Quantum Bill of Materials scoring every cryptographic algorithm for quantum vulnerability with break-year estimates and CNSA 2.0 gap analysis.

Unified BOM dashboard with drift alerts

Single dashboard showing all BOM types, their last-updated timestamps, component counts, and drift alerts when BOMs diverge from the live software state.

Regulatory Coverage

Regulators keep adding BOM requirements. O3 covers every one.

EO 14028 required SBOMs. EU CRA extended them. EU AI Act added AIBOMs. NSA mandated QBOMs. DoD added HBOMs to critical systems. Rather than managing five different tools, O3 provides a single platform that generates and maintains every BOM type from one inventory.

Start your compliance program
Regulation → BOM type coverage matrix
US EO 14028
NTIA SBOM minimum elements
SBOMCovered
EU Cyber Resilience Act
Component transparency + vulnerability disclosure
SBOMCovered
EU AI Act
Technical documentation for AI systems
AIBOMCovered
NSA CNSA 2.0
Post-quantum algorithm transition
QBOMCovered
DoD Quantum Readiness
Cryptographic inventory mandate
CBOM + QBOMCovered
NERC CIP / IEC 62443
OT/ICS hardware asset inventory
HBOMCovered
NIST PQC Standards
FIPS 203, 204, 205 readiness
CBOM + QBOMCovered
FAQ

Questions,
answered.

Everything teams ask before rolling this out. Still stuck? Reach our team.

  • Each BOM type inventories a different layer of your software system: SBOM (Software Bill of Materials) covers software components and dependencies. CBOM (Cryptographic BOM) covers cryptographic algorithms, keys, and certificates. AIBOM (AI BOM) covers AI models, datasets, and ML dependencies. HBOM (Hardware BOM) covers physical hardware components and firmware. QBOM (Quantum BOM) scores cryptographic algorithms specifically for quantum vulnerability. They are complementary, a complete compliance program requires all five.
  • US EO 14028 and EU CRA require SBOMs. EU AI Act requires AIBOM-equivalent technical documentation for AI systems. NSA CNSA 2.0 and DoD quantum readiness mandates require CBOM and QBOM. NERC CIP and IEC 62443 for critical infrastructure require hardware inventory equivalent to HBOM. NIST PQC standards (FIPS 203, 204, 205) readiness requires CBOM + QBOM. O3 covers all of these from a single platform.
  • O3 integrates with CI/CD pipelines and generates updated BOMs on every build. When a dependency is added, removed, or updated, or when a new AI model is deployed, the corresponding BOM is updated automatically. A drift alert is triggered when the live BOM diverges from the last committed state, ensuring compliance evidence stays synchronized with the actual software state.
  • Yes. O3 scans container images (Docker, OCI), Kubernetes workloads, and cloud-native applications to generate SBOMs covering all packages installed in the image layer, including OS packages (apt, rpm, apk), language packages (npm, pip, maven, cargo), and custom binaries. HBOM generation for cloud instances uses instance metadata APIs to identify underlying hardware.
  • Yes. O3 exports SBOMs in CycloneDX 1.4, 1.5, and 1.6 and SPDX 2.3, the two formats recognized by NTIA, EU CRA, and DoD. Export formats include JSON, XML, and SPDX tag-value. CBOMs are exported in CycloneDX 1.6 which includes the cryptographic asset extension. AIBOMs follow the emerging CycloneDX ML-BOM specification.