SBOM Management Best Practices for Automotive

A modern vehicle contains over 100 million lines of code spread across dozens of electronic control units, infotainment systems, telematics modules, and ADAS controllers. Behind that code sit thousands of software components — open-source libraries, commercial SDKs, AUTOSAR modules, Linux kernel forks, and proprietary firmware blobs. When the Log4Shell vulnerability was disclosed in December 2021, automotive OEMs and suppliers scrambled to determine which of their vehicles were affected. Many could not answer that question for weeks because they lacked a fundamental artifact: a Software Bill of Materials.

An SBOM is a structured, machine-readable inventory of every software component in a product. It lists package names, versions, suppliers, dependency relationships, and licensing information. In the automotive industry, SBOMs are no longer optional — they are a regulatory expectation under UNECE R155, a practical requirement for ISO/SAE 21434 vulnerability management, and an operational necessity for managing supply-chain risk across vehicle lifecycles that span 15 years or more.

This guide covers how to build, maintain, and leverage SBOMs across the automotive supply chain, from format selection through continuous vulnerability monitoring.

Why SBOMs Matter for Automotive

The automotive software supply chain is uniquely complex. A single vehicle platform may incorporate components from 50 or more Tier-1 and Tier-2 suppliers, each contributing firmware, middleware, or application software. The transitive dependency tree for a typical infotainment system alone can exceed 2,000 open-source packages.

Without an SBOM, you are operating blind in several critical areas:

• Vulnerability response: When a critical CVE is published (like Log4Shell, Spring4Shell, or the XZ Utils backdoor), you need to determine within hours — not weeks — which vehicle platforms, ECUs, and software versions are affected. Without SBOMs, this requires manual forensics across dozens of supplier codebases.
• Regulatory compliance: UNECE R155 requires OEMs to demonstrate vulnerability monitoring and incident response capabilities. Auditors increasingly expect SBOM-based evidence that you can trace components to known vulnerabilities. ISO/SAE 21434 Clause 13 (cybersecurity monitoring) is practically impossible without component-level visibility.
• License compliance: Automotive software is a patchwork of GPL, LGPL, Apache, MIT, and proprietary licenses. A single undiscovered GPL component in a binary-linked module can create legal exposure. SBOMs make license audits systematic rather than guesswork.
• Supply-chain transparency: As attack surfaces expand to connected vehicles, understanding exactly what software your suppliers deliver — and what their suppliers deliver to them — is a fundamental security control.
• End-of-life planning: Vehicle platforms remain in production for 5–7 years and on the road for 15+. SBOMs enable proactive identification of components approaching end-of-support before they become unpatched liabilities.

The automotive industry learned from Log4Shell that component visibility is not a nice-to-have. Organizations that had SBOMs assessed exposure in hours. Those without them spent weeks in crisis mode, manually auditing supplier deliverables.

SBOM Formats: CycloneDX vs SPDX

Two dominant standards exist for expressing SBOMs: CycloneDX and SPDX. Both are well-supported, machine-readable, and suitable for automotive use. Choosing between them depends on your priorities and ecosystem.

CycloneDX

Developed by OWASP, CycloneDX was designed from the ground up for security use cases. Key strengths include:

• VEX integration: CycloneDX natively supports Vulnerability Exploitability eXchange (VEX) statements, allowing you to annotate components with vulnerability status (affected, not affected, under investigation, fixed). This is critical for automotive, where not every CVE is exploitable in a specific deployment context.
• Dependency graph: CycloneDX models full dependency trees, distinguishing direct from transitive dependencies. This is essential for understanding blast radius when a deep transitive dependency has a vulnerability.
• Formulation: CycloneDX 1.5+ supports build environment capture, recording the toolchain, build parameters, and environment used to produce the software. This aids reproducibility and provenance verification.
• Lightweight format: JSON and XML serializations are compact and fast to parse, which matters when correlating thousands of SBOMs daily.

SPDX

SPDX (Software Package Data Exchange) is an ISO/IEC 5962 international standard maintained by the Linux Foundation. Key strengths include:

• License compliance focus: SPDX has the most mature license expression syntax, with a comprehensive license list maintained by the SPDX Legal Team. If license compliance is a primary concern, SPDX excels here.
• ISO standardization: Being an ISO standard carries weight in automotive regulatory contexts where auditors expect ISO-referenced artifacts.
• Broad tool support: SPDX has wide adoption in the Linux ecosystem, with tooling in Yocto, Buildroot, and other embedded Linux build systems commonly used in automotive.
• Relationship types: SPDX 2.3+ supports rich relationship types between packages (BUILD_TOOL_OF, DEPENDENCY_OF, CONTAINS, etc.) enabling detailed supply-chain modeling.

Which to Choose?

For most automotive organizations, we recommend CycloneDX as the primary format for security and vulnerability management workflows, while maintaining the ability to produce SPDX for license compliance and regulatory documentation. Modern tooling can generate both formats from the same scan. The key is to standardize on one format internally and define clear expectations for supplier deliverables.

Building Your SBOM Program in Phases

An effective automotive SBOM program is not built overnight. We recommend a four-phase approach that progressively expands coverage and capability.

Phase 1: Internal SBOM Generation

Start by generating SBOMs for software you build in-house. This establishes tooling, processes, and expertise before tackling the harder problem of supplier SBOMs.

CI/CD integration is the foundation. SBOM generation should be an automated step in your build pipeline, not a manual activity performed before releases. Every build that produces a deployable artifact should produce a corresponding SBOM. Tools like syft, cdxgen, and trivy integrate directly into CI/CD pipelines and support CycloneDX and SPDX output.

There are two primary approaches to SBOM generation:

• Build-time analysis: Instruments the build system to capture exact component versions as they are resolved. This is the most accurate approach because it reflects the actual dependency resolution, including platform-specific conditional dependencies. For embedded Linux platforms built with Yocto or Buildroot, build-time SBOM generation leverages the package manager’s dependency graph directly.
• Binary analysis: Scans compiled binaries and firmware images to identify components through string matching, hash comparison, and binary fingerprinting. Essential for components received as pre-compiled binaries from suppliers where source code is not available. Less accurate than build-time analysis but necessary for complete coverage.

Best practice is to combine both: build-time analysis for your own code and binary analysis as a verification step and for third-party binaries.

Phase 2: Supplier SBOM Collection

Tier-1 suppliers deliver software to OEMs; Tier-2 suppliers deliver to Tier-1s. Each handoff should include an SBOM. Making this operational requires three elements:

• Contractual requirements: Update supplier agreements to mandate SBOM delivery with every software release. Specify the format (CycloneDX 1.5+ or SPDX 2.3+), required fields (supplier, version, CPE/PURL identifiers, license), and delivery timeline (SBOMs must accompany software deliverables, not arrive weeks later).
• Supplier portal: Provide a centralized portal where suppliers upload SBOMs alongside software deliverables. The portal should validate SBOM completeness and format conformance on upload, rejecting submissions that do not meet minimum quality thresholds. ThreatZ provides this capability through its supplier SBOM exchange module.
• Validation and quality scoring: Not all SBOMs are created equal. A supplier SBOM that lists 15 top-level packages for an embedded Linux system with 500+ actual components is incomplete and nearly useless. Implement automated quality scoring that checks component count plausibility, presence of version strings, valid PURL identifiers, license data, and dependency depth. Feed quality scores back to suppliers to drive improvement.

The biggest hurdle in supplier SBOM collection is not technical — it is organizational. Many Tier-2 suppliers have never produced an SBOM. Budget time for supplier enablement: workshops, tooling recommendations, and iterative quality improvement.

Phase 3: Vulnerability Correlation

An SBOM without vulnerability correlation is an inventory list. The real value emerges when you continuously match components against known vulnerability databases.

• Data sources: The National Vulnerability Database (NVD) remains the primary source, but supplement it with OSV (Open Source Vulnerabilities) for open-source-specific coverage, supplier advisories, and CERT-CC alerts. Automotive-specific databases like Auto-ISAC intelligence feeds provide context that general databases lack.
• VEX statements: When a vulnerability is found in a component, it does not necessarily mean your product is exploitable. VEX (Vulnerability Exploitability eXchange) statements allow you to document the analysis: is the vulnerable code path reachable? Is it mitigated by other controls? VEX reduces alert fatigue by filtering noise from actionable findings. For automotive, where an ECU may use a library but not the affected function, VEX is indispensable.
• EPSS prioritization: The Exploit Prediction Scoring System (EPSS) provides a probability score indicating how likely a vulnerability is to be exploited in the wild within the next 30 days. Combined with CVSS severity, EPSS enables risk-based prioritization — focusing remediation effort on vulnerabilities that are both severe and likely to be exploited, rather than chasing every high-CVSS finding regardless of real-world exploitability.

Phase 4: Continuous Monitoring

SBOM-based vulnerability management is not a point-in-time scan. It is a continuous process that runs for the entire lifecycle of the vehicle platform.

• Daily correlation: Re-run vulnerability correlation against all active SBOMs at least daily. New CVEs are published continuously, and a component that was clean yesterday may have a critical vulnerability today. Automate this completely — no human should need to trigger a scan.
• Alerting: Configure tiered alerts based on severity and exploitability. Critical vulnerabilities with high EPSS scores in safety-relevant ECUs should trigger immediate notifications to the product security team. Lower-severity findings can be batched into weekly reports. Integrate alerts with your existing ITSM or incident response workflow.
• Dashboard and reporting: Provide a centralized dashboard showing vulnerability exposure across all vehicle platforms, ECUs, and software versions. Key metrics include: total components tracked, percentage with known vulnerabilities, mean time to VEX assessment, mean time to remediation, and supplier SBOM quality trends. This data feeds directly into UNECE R155 audit evidence and ISO/SAE 21434 cybersecurity monitoring requirements.

SBOM Challenges in Automotive

Automotive software has characteristics that make SBOM management harder than in enterprise IT or cloud-native environments.

• Firmware and bare-metal components: Many automotive ECUs run on bare-metal or lightweight RTOS platforms (AUTOSAR Classic, FreeRTOS, QNX). These components do not have package managers, and binary analysis is the only option for SBOM generation. Firmware blobs from semiconductor vendors are particularly opaque — they may contain embedded libraries (TLS stacks, USB drivers) that are invisible without deep binary analysis.
• Long lifecycles: A vehicle platform launched in 2026 will still be on the road in 2041. The SBOM must remain accurate and actively monitored for that entire period. Components that were current at launch will inevitably reach end-of-life, requiring planned migration or accept-risk decisions. Few organizations have processes designed for 15-year software lifecycle management.
• Variant management: A single vehicle platform may have dozens of variants — different markets, different option packages, different hardware configurations — each with a slightly different software composition. The SBOM program must track these variants systematically, or vulnerability assessments will miss variant-specific components.
• Binary-only supplier deliverables: Many Tier-1 and Tier-2 suppliers deliver pre-compiled binaries without source code. Binary analysis can identify many components, but accuracy drops for statically-linked libraries, custom forks of open-source projects, and proprietary code. Contractual SBOM requirements (Phase 2) are essential to close this gap, but the transition takes time.
• AUTOSAR and domain-specific stacks: AUTOSAR Classic and Adaptive platform components have their own versioning and module structure that does not map cleanly to standard package identifiers (CPE, PURL). SBOM tooling needs automotive-specific extensions to handle these correctly.

EU Cyber Resilience Act: SBOM Obligations for Automotive Suppliers

The EU Cyber Resilience Act (CRA), which entered into force in 2024 with compliance deadlines phasing in through 2027, represents the most explicit regulatory mandate for SBOMs affecting the automotive supply chain. While UNECE R155 references SBOM implicitly through its vulnerability monitoring requirements, the CRA makes SBOM delivery a direct legal obligation for manufacturers of products with digital elements — a category that unambiguously includes automotive ECUs, telematics modules, infotainment systems, and connected vehicle components sold in the European market.

Machine-Readable SBOM Delivery

Article 13 of the CRA requires manufacturers to identify and document components and dependencies of their products, including by drawing up an SBOM in a commonly used and machine-readable format covering at minimum the top-level dependencies. The regulation does not mandate a specific format, but its technical guidance references both CycloneDX and SPDX as acceptable standards. For automotive suppliers already producing SBOMs for OEM requirements, the CRA formalizes what was previously a contractual expectation into a legal requirement with enforcement mechanisms.

The CRA requires that SBOMs be machine-readable and cover at minimum the top-level dependencies of the product. For automotive ECUs with deep dependency trees, organizations should go well beyond the minimum and document the full transitive dependency graph to satisfy both the letter and spirit of the regulation.

Vulnerability Notification Timelines

The CRA imposes aggressive notification timelines that directly affect SBOM program operations. Manufacturers must notify ENISA (the EU Agency for Cybersecurity) of actively exploited vulnerabilities within 24 hours of becoming aware of them, followed by a detailed vulnerability notification within 72 hours. Without a current, accurate SBOM, determining whether a newly disclosed vulnerability affects your products within these timelines is practically impossible.

This creates a direct operational link between SBOM freshness and regulatory compliance. An SBOM generated at release time and never updated is insufficient — you need the ability to query your current component inventory against newly published CVEs within minutes, not days. Platforms like ThreatZ that provide continuous vulnerability correlation against all active SBOMs enable the rapid impact assessment that the CRA’s notification timelines demand.

Implications for the Automotive Supply Chain

The CRA’s obligations flow through the supply chain. OEMs selling vehicles in the EU are responsible for the cybersecurity of the complete product, but they rely on Tier-1 and Tier-2 suppliers to provide the component-level data needed for compliance. This means:

• Tier-1 suppliers must provide SBOMs for their deliverables that are complete enough for the OEM to fulfill CRA obligations. Incomplete or outdated supplier SBOMs create compliance gaps for the OEM.
• Tier-2 and component suppliers face the same requirements for products they sell directly (e.g., aftermarket telematics, standalone ECU modules) and must also support their Tier-1 customers’ SBOM needs.
• Open-source maintainers are exempted from CRA obligations, but the commercial entities that incorporate open-source components into automotive products are not. The burden of documenting open-source dependencies falls on the manufacturer.

The CRA complements UNECE R155 and ISO/SAE 21434 rather than replacing them. R155 focuses on the cybersecurity management system and type approval process. ISO/SAE 21434 provides the engineering framework. The CRA adds explicit product-level obligations including SBOM delivery. Automotive organizations should view these as a layered compliance stack, with the SBOM program serving as shared infrastructure across all three.

SBOM Generation Tooling: Build-System and CI/CD Integration

Generating SBOMs manually is unsustainable for automotive software that may involve thousands of components across dozens of build configurations. Effective SBOM programs integrate generation tooling directly into the build system and CI/CD pipeline so that every deployable artifact is accompanied by an automatically generated, accurate SBOM.

Software Composition Analysis (SCA) Tools

SCA tools form the first layer of SBOM generation. They analyze source code, package manifests, and container images to identify components and their dependencies. For automotive use cases, the key SCA tools include:

• syft — Anchore’s open-source SCA tool that generates CycloneDX and SPDX from container images, filesystems, and archives. Useful for Linux-based infotainment and telematics systems.
• cdxgen — A CycloneDX generator that supports a wide range of package ecosystems (npm, Maven, pip, Cargo, Go modules, Conan) and produces CycloneDX BOMs with dependency graphs. Its multi-ecosystem support is valuable for automotive platforms combining C/C++ with Python tooling and JavaScript-based HMI components.
• trivy — Aqua Security’s scanner that combines SCA with vulnerability scanning, producing SBOMs alongside vulnerability reports in a single pass. Supports CycloneDX and SPDX output.
• Commercial SCA platforms (Synopsys Black Duck, Snyk, FOSSA, Sonatype) provide deeper analysis including snippet scanning for copied code, license conflict detection, and policy enforcement. These are typically preferred for automotive programs that need to satisfy both security and legal compliance requirements from a single tool.

Build-System Plugins for Automotive Toolchains

Automotive software builds use specialized toolchains that require dedicated SBOM integration. The most important integrations are:

• Yocto / BitBake: The Yocto Project is the dominant build system for automotive-grade Linux (AGL, GENIVI). Yocto natively tracks recipe-level package metadata and can generate SPDX documents through the create-spdx class. For CycloneDX output, tools like cdxgen can parse Yocto build manifests. The key advantage of build-system integration is that Yocto resolves exact package versions including patches applied by .bbappend files, producing SBOMs that reflect the actual built software rather than declared dependencies.
• CMake: The predominant build system for C/C++ automotive middleware and application software. CMake does not have native SBOM generation, but tools like cmake-sbom and the CMake FetchContent dependency metadata can be parsed to produce SBOMs. For projects using vcpkg or Conan as C/C++ package managers alongside CMake, these package managers provide dependency manifests that SCA tools can consume.
• Conan: Increasingly adopted for managing C/C++ dependencies in automotive projects. Conan’s lockfile outputs provide complete dependency graphs with version pinning, which tools like cdxgen can convert to CycloneDX. Conan 2.0’s improved lockfile format makes reproducible SBOM generation straightforward.
• AUTOSAR build chains: Vector DaVinci, ETAS ISOLAR, and EB tresos generate AUTOSAR-specific software configurations. SBOM integration for these tools is typically achieved through post-build analysis of the generated code and linked libraries, rather than native SBOM export. Some vendors are adding SBOM export capabilities, but the ecosystem is still maturing.

CI/CD Pipeline Integration Patterns

The recommended architecture for automated SBOM generation follows a pipeline-as-code approach:

1. Build stage: Compile the software and capture build metadata (toolchain versions, build flags, environment variables). For Yocto builds, this is the bitbake execution that resolves all recipes.
2. SBOM generation stage: Immediately after a successful build, run the SCA tool against the build output. Generate SBOMs in your primary format (CycloneDX or SPDX) with full dependency graphs.
3. Validation stage: Validate the generated SBOM against the format schema, check minimum field completeness (supplier, version, PURL identifiers, license), and verify component count plausibility against historical baselines.
4. Signing and storage: Cryptographically sign the SBOM (using cosign, PGP, or your organization’s signing infrastructure) and store it alongside the build artifact in your artifact repository. The SBOM must be versioned and retrievable for the entire lifecycle of the software it describes.
5. Upload to SBOM management platform: Push the signed SBOM to your centralized SBOM management platform (e.g., ThreatZ) for vulnerability correlation and lifecycle tracking.

Treat the SBOM as a build artifact with the same retention, versioning, and integrity requirements as the software it describes. If you cannot produce an SBOM, the build should fail — just as it would for a failed unit test.

SBOM for ECU Firmware: Embedded-Specific Challenges

Generating SBOMs for ECU firmware presents unique challenges that have no direct parallel in enterprise software or cloud-native applications. Firmware runs on resource-constrained microcontrollers, often without an operating system or package manager, and is frequently delivered as opaque binary blobs from semiconductor vendors.

Binary Analysis for Firmware

When source code is unavailable — which is common for Tier-2 supplier firmware, BSP (Board Support Package) components, and semiconductor vendor libraries — binary analysis is the only path to SBOM generation. Binary analysis tools work through several complementary techniques:

• String extraction: Scanning firmware binaries for embedded version strings, copyright notices, license text, and library identifiers. Tools like binwalk and BANG (Binary Analysis Next Generation) excel at this approach. Effective for identifying well-known libraries that embed version information (e.g., OpenSSL, mbedTLS, zlib).
• Hash-based identification: Computing cryptographic hashes of firmware sections and comparing them against databases of known component hashes. This works well for statically-linked libraries that have not been modified. The OWASP Binary Analysis comparison database and commercial equivalents provide reference hash sets.
• Function fingerprinting: More advanced tools like CodeSentry and Finite State use function-level binary fingerprinting to identify components even when they have been compiled with different optimization flags or partially modified. This technique is essential for automotive firmware where suppliers commonly apply patches to open-source libraries before compilation.
• Firmware unpacking: Many ECU firmware images use layered packaging (compressed filesystem images, encrypted partitions, bootloader chains). The first step in binary analysis is unpacking these layers to access the individual binaries. Tools like binwalk handle common firmware packaging formats, but proprietary formats from specific semiconductor vendors may require custom extraction scripts.

RTOS and Bare-Metal Components

ECUs running real-time operating systems (AUTOSAR Classic OS, FreeRTOS, QNX Neutrino, VxWorks) or bare-metal firmware present a different SBOM challenge than Linux-based systems. These environments typically lack package managers, and components are statically linked into a single monolithic binary. Key considerations include:

• AUTOSAR BSW modules: Basic Software modules in AUTOSAR Classic (communication stacks, diagnostic services, memory abstraction) are delivered as source or object files by the AUTOSAR tool vendor. These must be tracked individually in the SBOM, including the specific AUTOSAR release version, vendor, and any patches applied during configuration.
• RTOS kernel and middleware: The RTOS kernel itself, along with middleware components (TCP/IP stacks, file systems, USB stacks), must be documented with exact versions. Many commercial RTOS vendors now provide SBOMs for their deliverables, but quality varies significantly.
• HAL and driver libraries: Hardware Abstraction Layer code and peripheral driver libraries from semiconductor vendors (e.g., STM32 HAL, NXP SDK, Infineon MCAL) are often distributed as compiled libraries or auto-generated code. These contain their own dependencies (CMSIS, DSP libraries) that must be captured in the SBOM.

Bootloader and Secure Boot Dependencies

The bootloader chain (first-stage bootloader, second-stage bootloader, secure boot verification code) is a critical attack surface that must be represented in the SBOM. Bootloaders like U-Boot or vendor-specific implementations contain cryptographic libraries, TLS stacks, and parsing code that are independently vulnerable. The secure boot trust chain depends on these components — a vulnerability in the bootloader can compromise the integrity of the entire ECU software stack, making bootloader SBOM coverage essential for ISO/SAE 21434 threat analysis.

SBOM Sharing and Supply-Chain Exchange

An SBOM is only as useful as the supply-chain processes that produce, transmit, and consume it. Automotive supply chains involve multiple tiers of suppliers, each with different levels of SBOM maturity, different confidentiality concerns, and different tooling capabilities. Establishing effective SBOM exchange practices is as important as the technical format of the SBOM itself.

NTIA Minimum Elements as a Baseline

The NTIA (National Telecommunications and Information Administration) published minimum elements for SBOMs that have become the de facto baseline for supply-chain exchange. Every SBOM exchanged between automotive supply-chain partners should include at minimum:

• Supplier name — the entity that created or distributed the component
• Component name — the name of the software package as designated by the supplier
• Version of the component — the version identifier used by the supplier
• Unique identifiers — CPE, PURL, or other identifiers enabling automated vulnerability correlation
• Dependency relationships — which components depend on which other components
• Author of SBOM data — the entity that generated or assembled the SBOM document
• Timestamp — when the SBOM was generated

These minimum elements are necessary but often insufficient for automotive use cases. OEMs should additionally require license information, cryptographic hashes, and PURL identifiers in supplier SBOMs to enable automated vulnerability correlation and license compliance checks.

Trust Boundaries and Redaction Policies

Suppliers have legitimate concerns about revealing proprietary component details in their SBOMs. A Tier-1 supplier may not want to disclose the specific third-party libraries used in their proprietary algorithms, viewing this as trade-secret information. At the same time, the OEM needs sufficient component visibility for vulnerability management. Balancing these concerns requires clear redaction policies:

• Full-detail SBOMs are maintained internally by the supplier for their own vulnerability management and retained under NDA for regulatory audits.
• Redacted SBOMs provided to customers may omit proprietary component names while retaining version information, hashes, and vulnerability identifiers. The supplier commits to monitoring these components and notifying the OEM of any vulnerabilities through a coordinated disclosure process.
• Summary SBOMs list only open-source and commercially available components, with proprietary elements aggregated into opaque entries. This provides the least visibility but may be acceptable where strong contractual vulnerability notification obligations exist.

Redaction should never remove vulnerability-critical information. A redacted SBOM that hides component identifiers while retaining hashes and PURL still enables automated vulnerability matching. The goal is protecting trade secrets, not obscuring security-relevant data.

Bilateral Agreements and Exchange Protocols

Effective SBOM exchange requires formalized agreements between supply-chain partners. These bilateral agreements should cover:

• Format and version: Specify the accepted SBOM format (CycloneDX 1.5+ or SPDX 2.3+), serialization (JSON preferred for machine processing), and minimum field requirements beyond the NTIA baseline.
• Delivery cadence: SBOMs must accompany every software delivery, not arrive as a separate process weeks later. Define whether incremental (delta) SBOMs are acceptable for minor updates or whether full SBOMs are always required.
• Quality thresholds: Define minimum quality criteria (component count plausibility, percentage of components with valid PURLs, license data completeness) and the remediation process when SBOMs fail quality checks.
• Vulnerability notification: Define obligations for the supplier to notify the OEM when newly disclosed vulnerabilities affect components in previously delivered SBOMs, including notification timelines aligned with CRA requirements.
• Confidentiality and use restrictions: Specify how the OEM may use, store, and share the received SBOM data, including restrictions on forwarding component details to other supply-chain partners.

ThreatZ facilitates this exchange through its supplier portal, which enforces format validation, quality scoring, and access control policies at the point of SBOM upload, reducing the manual overhead of enforcing bilateral agreement terms.

Runtime SBOM Verification and Drift Detection

An SBOM represents the intended software composition at build time. But what is actually running on a deployed ECU may diverge from the build-time SBOM due to OTA updates, field modifications, partial update failures, or even unauthorized software changes. Runtime SBOM verification closes this gap by comparing the actual deployed software state against the expected SBOM.

Integrity Verification Approaches

Runtime verification can operate at multiple levels depending on the ECU’s capabilities and connectivity:

• Secure boot chain verification: The most fundamental form of runtime integrity checking. Each stage of the boot process verifies the cryptographic signature of the next stage, ensuring that only authorized software executes. While not a full SBOM verification, secure boot provides confidence that the software image matches the signed build artifact for which the SBOM was generated.
• Runtime hash attestation: After boot, the ECU computes cryptographic hashes of loaded binaries and firmware partitions, then reports these hashes to a backend verification service. The service compares reported hashes against the expected hashes in the SBOM. Discrepancies indicate drift — either from an update that was not reflected in the SBOM or from an unauthorized modification.
• Software inventory agents: For Linux-based ECUs (infotainment, telematics, ADAS), lightweight inventory agents can enumerate installed packages, running processes, and loaded libraries, then report this inventory for comparison against the SBOM. This provides the most granular runtime visibility but requires agent deployment and ongoing resource consumption on the ECU.

Drift Detection and Update Reconciliation

Over-the-air (OTA) updates are now standard in modern vehicles, and each update can change the software composition of one or more ECUs. SBOM drift detection identifies when the deployed software state no longer matches the most recent SBOM on record. Common drift scenarios include:

• Successful OTA update without SBOM refresh: The ECU software was updated, but a new SBOM was not generated or uploaded. The solution is to integrate SBOM generation into the OTA package build pipeline so that every update package includes an updated SBOM.
• Partial update failure: An OTA update was interrupted, leaving the ECU in a state that matches neither the old nor the new SBOM. Runtime verification detects this inconsistency, and the update system should trigger a rollback or retry.
• Configuration drift: Feature flags, calibration data, or runtime configuration changes alter the effective software behavior without changing binaries. While these changes may not appear in a traditional SBOM, CycloneDX’s formulation section and properties fields can capture configuration-level metadata when relevant to security posture.

Effective drift detection requires a feedback loop: the runtime verification system reports the current state, the SBOM management platform compares it against the expected state, discrepancies are flagged for investigation, and the SBOM is updated once the actual state is confirmed. ThreatZ supports this workflow through its variant-aware SBOM tracking, which maps SBOMs to specific ECU software versions and flags when deployed versions diverge from tracked versions.

Operational Metrics for SBOM Programs

An SBOM program without metrics is flying blind. Key performance indicators (KPIs) provide visibility into program effectiveness, identify bottlenecks, and supply the quantitative evidence that UNECE R155 auditors and ISO/SAE 21434 assessors increasingly expect. The following metrics should be tracked and reported on a regular cadence.

Coverage Metrics

• SBOM coverage percentage: The percentage of deployed software assets (ECUs, applications, firmware images) that have a current, validated SBOM on record. Target: 100% for all production software. Track separately for in-house software (which should reach 100% quickly) and supplier-delivered software (which typically ramps more slowly).
• Component identification rate: For binary-analyzed SBOMs, the percentage of binary content that has been successfully identified as known components versus unidentified binary blobs. A rate below 70% indicates gaps in binary analysis tooling or opaque supplier deliverables that need contractual remediation.
• Dependency depth: The average and maximum depth of dependency trees in your SBOMs. Shallow SBOMs (only top-level packages) miss transitive dependency vulnerabilities. Track this metric to ensure SBOMs capture the full dependency graph.

Freshness and Accuracy Metrics

• SBOM age: The average time elapsed since each active SBOM was last generated or refreshed. SBOMs older than the most recent software update for their asset are stale and may not reflect the current component composition. Target: SBOMs should be no older than the most recent software build for each asset.
• Correlation lag: The time between a new CVE being published in NVD/OSV and it being matched against your active SBOMs. With automated daily correlation, this should be under 24 hours. Longer lag times indicate process or tooling gaps.
• SBOM quality score trend: Track the quality scores of supplier-delivered SBOMs over time. Improving trends indicate successful supplier enablement. Flat or declining trends signal the need for additional supplier engagement or contractual enforcement.

Vulnerability Exposure Metrics

• Vulnerability exposure window: The mean time from CVE publication to VEX assessment completion (determining whether the vulnerability is exploitable in your specific deployment context). This is the window during which you have a known-but-unassessed vulnerability in your products. Target: under 5 business days for critical CVEs, under 15 business days for high-severity CVEs.
• Mean time to remediation (MTTR): For vulnerabilities assessed as exploitable, the mean time from assessment to deployed fix (via OTA update, patch, or component replacement). Track separately for safety-relevant ECUs versus non-safety systems.
• Open vulnerability count by severity: The total number of unresolved vulnerabilities in your active SBOMs, segmented by CVSS severity and EPSS exploitability. This is the headline metric for executive reporting and UNECE R155 audit evidence.

Supplier Compliance Metrics

• Supplier SBOM delivery rate: The percentage of supplier software deliveries that include an SBOM meeting your minimum quality criteria. Track per-supplier to identify laggards requiring additional enablement.
• Supplier response time: When a vulnerability is identified in supplier-delivered components, the mean time for the supplier to provide a VEX assessment or patch. This metric is critical for CRA compliance, where the OEM’s notification obligations depend on timely supplier input.
• Format and quality conformance: The percentage of received supplier SBOMs that pass automated validation checks (correct format, valid schema, minimum field completeness, plausible component count) without requiring manual correction or resubmission.

Publish SBOM program metrics on a monthly dashboard visible to engineering leadership and compliance teams. The metrics serve dual purposes: driving internal process improvement and providing ready-made evidence for regulatory audits under UNECE R155 and the EU CRA.

How ThreatZ Manages SBOMs

ThreatZ provides an integrated SBOM management module designed specifically for automotive workflows. Rather than bolting generic SBOM tooling onto automotive processes, ThreatZ addresses the domain-specific challenges described above.

• Multi-format ingestion: Import SBOMs in CycloneDX 1.4/1.5/1.6, SPDX 2.2/2.3, and CSV formats. ThreatZ normalizes all inputs into a unified internal representation, enabling consistent querying and correlation regardless of source format.
• Supplier portal with quality scoring: Suppliers upload SBOMs through a dedicated portal. Automated validation checks format conformance, component count plausibility, PURL/CPE identifier presence, license data completeness, and dependency depth. Quality scores are tracked over time and visible to both OEM and supplier.
• Continuous vulnerability correlation: ThreatZ correlates all active SBOMs against NVD, OSV, and configurable advisory feeds daily. Results are enriched with EPSS scores, CVSS vectors, and exploitability context. The platform supports VEX workflows, allowing product security teams to assess and document exploitability for their specific deployment context.
• Variant-aware tracking: SBOMs are linked to specific vehicle platforms, ECU types, software versions, and market variants. Vulnerability queries can be scoped to a single variant or aggregated across the entire product portfolio.
• TARA integration: Vulnerability findings from SBOM correlation feed directly into the ThreatZ TARA module, automatically creating threat scenarios for newly discovered component vulnerabilities. This closes the loop between vulnerability monitoring and risk assessment as required by ISO/SAE 21434.
• Compliance evidence: ThreatZ generates audit-ready reports demonstrating SBOM coverage, vulnerability monitoring cadence, mean response times, and VEX assessment completeness — the evidence UNECE R155 auditors expect to see.

Key Takeaways

• SBOMs are a foundational artifact for automotive cybersecurity. Without component-level visibility, vulnerability response, regulatory compliance, and supply-chain risk management are guesswork.
• Choose CycloneDX for security workflows (VEX, dependency graphs, vulnerability correlation) and maintain SPDX capability for license compliance and ISO-referenced documentation.
• Build your SBOM program in phases: start with internal CI/CD integration, then expand to supplier collection, vulnerability correlation, and continuous monitoring.
• Supplier enablement is the hardest part. Invest in contractual requirements, portal tooling, and iterative quality improvement rather than expecting perfect SBOMs on day one.
• Automotive-specific challenges — firmware opacity, 15-year lifecycles, variant management, and AUTOSAR stacks — require domain-aware tooling, not generic IT SBOM scanners.
• Continuous monitoring is non-negotiable. A point-in-time SBOM scan has a half-life of days as new vulnerabilities are published. Daily correlation with tiered alerting keeps exposure visible.
• VEX and EPSS together eliminate alert fatigue. Document exploitability context for your deployments and prioritize by real-world exploitation likelihood, not just CVSS score.