SBOM Version Tracking Across the Vehicle Lifecycle

Every time a connected vehicle receives an over-the-air update, every time a Tier-1 supplier ships a new firmware revision, and every time a CI/CD pipeline produces a nightly build, the software composition of the vehicle changes — and the SBOM that describes it must change too. SBOM version tracking is the discipline of knowing which SBOM version corresponds to which deployed software state, detecting exactly what changed between versions, and verifying that every SBOM in your inventory is complete and current. Without it, even the most comprehensive SBOM program degrades into a collection of stale documents that cannot answer the question every regulator, auditor, and incident responder will ask: “What software is running in that vehicle right now?”

The challenge is not generating a single SBOM. Modern tooling handles that well. The challenge is managing the hundreds or thousands of SBOM versions that accumulate across vehicle platforms, ECU types, market variants, build configurations, and software releases over a vehicle lifecycle that spans 15 years or more. A single vehicle platform with 30 ECUs, monthly update cycles, and three market variants generates over 10,000 SBOM versions per year. Multiply that across a product portfolio and the version management problem becomes enormous.

This article provides a practical framework for SBOM version tracking in automotive contexts. It covers versioning strategies, SBOM diff analysis for change detection, completeness verification, supply chain version reconciliation, and the critical problem of synchronizing SBOMs with OTA updates. The strategies described here are applicable regardless of whether you use CycloneDX, SPDX, or both.

Why SBOM Version Management Matters

Generating a single SBOM is a solved problem. Keeping track of every SBOM version across every ECU, every build, every release, and every OTA update over a 15-year vehicle lifecycle is the unsolved problem that separates mature SBOM programs from compliance theater. SBOM version management is the connective tissue that makes vulnerability response, regulatory audit, and supply chain oversight operationally viable at scale.

The Version Proliferation Challenge

Consider a mid-size automotive OEM managing five vehicle platforms. Each platform has an average of 25 ECUs with independently versioned software. Firmware builds happen weekly during active development, monthly during production. Each market variant (EU, US, China, Japan) may have different software configurations due to regulatory requirements, feature flags, or carrier-specific telematics modules. At a conservative estimate, this OEM generates over 15,000 distinct SBOM versions per year during active development and over 3,000 per year during steady-state production.

Every one of those SBOM versions must be stored, indexed, and queryable. When a critical CVE drops — say, a remote code execution in a widely-used TLS library — the security team needs to answer three questions within hours: Which SBOM versions contain the affected component? Which of those SBOM versions map to currently deployed software? Which vehicle platforms and ECUs are therefore affected? Without systematic version management, answering these questions requires manual archaeology through thousands of files, and the answer arrives too late to matter.

Regulatory Requirements for SBOM Currency (EU CRA, R155, ISO 21434)

Regulators are increasingly explicit that SBOMs must be current, not historical artifacts. The EU Cyber Resilience Act Article 13 requires manufacturers to identify and document vulnerabilities and components contained in their products, and to ensure this documentation remains up to date throughout the expected product lifetime. An SBOM generated at initial release and never updated does not satisfy this obligation — the CRA expects ongoing currency.

UNECE R155, while not explicitly mentioning SBOMs by name, requires OEMs to demonstrate processes for identifying and managing cybersecurity risks throughout the vehicle lifecycle, including monitoring for new vulnerabilities. ISO/SAE 21434 Clause 8 (Continual cybersecurity activities) mandates ongoing vulnerability monitoring, which is operationally impossible without knowing exactly which software components are deployed in which vehicles at any given time. SBOM version tracking is the mechanism that makes these regulatory requirements achievable.

The EU CRA SBOM currency requirement is particularly demanding because it extends to the full supply chain. If a Tier-2 supplier updates a library in a firmware module, the Tier-1 integrating that module must update its SBOM, and the OEM must update the vehicle-level SBOM. A version tracking system that cannot propagate these cascading updates creates compliance gaps that auditors will identify.

What Happens When You Lose Track of SBOM Versions

The consequences of poor SBOM version management are concrete and measurable. During the Log4Shell incident in December 2021, organizations with robust SBOM versioning assessed exposure within hours because they could query their SBOM inventory by component name and version. Organizations without version tracking spent weeks manually auditing supplier deliverables, build artifacts, and deployed images — during which time their vehicles remained exposed to active exploitation.

Beyond incident response, version tracking failures create audit findings. When a UNECE R155 auditor asks to see the current SBOM for a specific ECU in a specific vehicle variant, and the team produces a document from 18 months ago with no evidence of updates since, the auditor reasonably questions whether the vulnerability monitoring process is functioning. Version tracking also prevents a subtler failure: deploying software that was never scanned. If the SBOM generation step is decoupled from the deployment pipeline and no version reconciliation exists, it is possible for OTA updates to push software to vehicles for which no SBOM was ever produced.

SBOM Versioning Strategies

There is no single correct way to version SBOMs. The right strategy depends on your build cadence, release model, organizational structure, and tooling capabilities. What matters is consistency: every SBOM version must have a unique, stable identifier, and that identifier must be traceable to the exact software artifact the SBOM describes.

Per-Build Versioning

In per-build versioning, every CI/CD pipeline run that produces a deployable artifact also produces a new SBOM version. The SBOM version identifier is typically derived from the build number or commit hash — for example, platform-x-ecu-ivi-build-4821 or the CycloneDX serialNumber field containing a UUID that is unique per build. This approach provides the highest granularity and the most precise traceability between SBOM and artifact.

The advantage of per-build versioning is completeness. Every software state that could theoretically be deployed has a corresponding SBOM. The disadvantage is volume: active development branches may produce hundreds of builds per week, most of which are never deployed beyond test environments. Organizations using per-build versioning need robust retention policies that archive SBOMs for deployed builds indefinitely while purging SBOMs for builds that were never promoted beyond development.

Per-Release Versioning

Per-release versioning ties SBOM versions to formal software releases rather than individual builds. When the release engineering team cuts a release candidate, the SBOM is generated and versioned to match the release tag — for example, platform-x-ecu-ivi-v2026.2.1. Only SBOMs for formally released software are tracked in the version management system.

This approach dramatically reduces the number of SBOM versions to manage, which simplifies querying and reduces storage costs. However, it creates a gap during development: builds between releases have no tracked SBOM, which means vulnerabilities discovered during that window cannot be assessed against in-progress software. Per-release versioning works best for organizations with infrequent, well-defined release milestones and limited OTA update cadence.

Per-ECU / Per-Component Versioning

Rather than versioning the entire vehicle SBOM as a monolith, per-ECU versioning treats each ECU or major software component as an independently versioned SBOM unit. The infotainment SBOM, the telematics SBOM, the ADAS controller SBOM, and each domain controller SBOM have their own version sequences. A vehicle-level SBOM is then composed by referencing the current versions of all ECU-level SBOMs.

This mirrors how automotive software is actually developed and deployed. ECU firmware is typically updated independently — an OTA update may touch only the infotainment system while leaving the body controller unchanged. Per-ECU versioning accurately reflects this reality and avoids the problem of creating a new vehicle-level SBOM version when only one ECU changed. Both CycloneDX and SPDX support this compositional model: CycloneDX through nested BOMs and the serialNumber plus version fields on each BOM, and SPDX through the documentNamespace and external document references that link sub-SBOMs into a parent document.

Recommended Hybrid Approach

For most automotive organizations, we recommend a hybrid strategy that combines the strengths of all three approaches. Use per-build versioning in CI/CD pipelines to ensure every deployable artifact has a corresponding SBOM. Use per-ECU versioning as the organizational unit, so each ECU maintains its own SBOM version history. Use per-release versioning to tag the specific SBOM versions that are formally released and deployed to production vehicles. The vehicle-level SBOM is a composition document that references the current released version of each ECU SBOM.

This hybrid approach means that when a vulnerability is discovered, you can query by component across all ECU SBOMs to identify affected units, then cross-reference against the release tags to determine which deployed vehicle variants are impacted. The CycloneDX serialNumber provides a globally unique identifier for each SBOM instance, while the version field tracks the sequence within a given component. In SPDX, the documentNamespace serves a similar purpose, providing a unique URI for each SBOM document that can be referenced from other documents.

SBOM Delta/Diff: What Changed Between Versions?

Knowing that a new SBOM version exists is only half the picture. The actionable question is: what changed? SBOM diff analysis — computing the precise set of additions, removals, and version changes between two SBOM versions — transforms raw version data into decision-relevant intelligence for security teams, release managers, and compliance officers.

Component-Level Diff Analysis

A component-level SBOM diff produces four categories of changes. Added components are packages present in the new SBOM version but absent in the previous one — these may introduce new attack surface or new vulnerabilities that did not exist in the prior release. Removed components are packages that were present before but are no longer included — these may resolve previously known vulnerabilities but could also indicate functionality regression if the removal was unintentional. Updated components are packages present in both versions but with different version numbers — these require analysis to determine whether the version change introduces new vulnerabilities, resolves existing ones, or is security-neutral. Unchanged components confirm stability but still require ongoing monitoring against newly published CVEs.

Effective diff analysis requires stable component identifiers across SBOM versions. Package URL (PURL) identifiers are the most reliable anchor because they encode the package type, namespace, name, and version in a standardized format. Diffing by component name alone is fragile because the same logical component may appear with slightly different names across SBOMs produced by different tools or at different times. Organizations should normalize component identifiers to PURL before performing diffs.

Why SBOM Diff Matters for Vulnerability Response

When a new software release is being evaluated, the SBOM diff tells the security team exactly which components require fresh vulnerability assessment. If the diff shows that the release updated openssl from 3.0.12 to 3.2.1, the team can immediately check the CVE history between those versions, confirm that known vulnerabilities in 3.0.12 are resolved, and verify that no new vulnerabilities were introduced in 3.2.1. Without the diff, the team must re-assess every component in the SBOM, which for a system with 500 or more components is prohibitively time-consuming.

SBOM diff also enables proactive risk assessment before deployment. If the diff reveals that a new release adds three previously unused open-source libraries, the security team can evaluate those libraries for known vulnerabilities, licensing concerns, and maintenance health before the release is pushed to production vehicles. This shift-left approach prevents the deployment of software with known risks that would be discovered later during routine monitoring.

For regulatory purposes, maintaining a history of SBOM diffs provides an auditable record of how the software composition evolved over time. UNECE R155 auditors can review the diff history to verify that the OEM actively tracked component changes, assessed their security implications, and made informed decisions about each release.

Presenting SBOM Diffs to Stakeholders

Raw diff data — a list of added, removed, and changed components — is useful for engineers but insufficient for managers, compliance officers, and executive stakeholders. Effective SBOM diff reporting translates component-level changes into security impact summaries. A well-structured diff report includes the component-level change list, the vulnerability impact (how many known CVEs are introduced or resolved by the changes), the license impact (whether any new components introduce licensing obligations such as GPL), and a risk assessment summary that contextualizes the changes for the specific deployment environment.

Visual diff presentations, such as the side-by-side comparison shown in the diagram above, are particularly effective for cross-functional review meetings where non-technical stakeholders need to understand the security implications of a software update. Color-coded change indicators (green for added, red for removed, amber for updated, gray for unchanged) provide an immediate visual summary before the detailed analysis is reviewed.

Completeness Verification: Does the SBOM Cover Everything?

Version tracking answers the question of which SBOM version is current. Completeness verification answers a different but equally important question: does that SBOM actually describe all the software in the product? An SBOM can be perfectly versioned and meticulously tracked but still miss 40% of the components because the generation tooling could not analyze certain binaries, the supplier SBOM was incomplete, or the build-time scan did not capture runtime dependencies.

Coverage Gap Detection

Coverage gaps are the silent failure mode of SBOM programs. They cannot be detected by looking at the SBOM alone — you can only find what is missing by comparing the SBOM against an independent source of truth about what software is actually present. Several techniques help identify coverage gaps:

• Binary-to-SBOM reconciliation: Take the compiled firmware image or container image that the SBOM is supposed to describe, run an independent binary analysis scan (using tools like binwalk, syft, or commercial binary analysis platforms), and compare the results against the SBOM. Any components found by the binary scan but absent from the SBOM represent coverage gaps. This technique is especially important for supplier-delivered binaries where the supplier SBOM may not capture embedded sub-dependencies.
• Runtime inventory comparison: For Linux-based ECUs that support runtime inventory agents, compare the list of installed packages, loaded shared libraries, and running processes against the SBOM. Discrepancies may indicate components that were added at runtime (through package manager installs or dynamic loading) but not captured in the build-time SBOM.
• Historical baseline comparison: Compare the component count and composition of the current SBOM version against historical baselines for the same ECU type. If previous versions of the infotainment SBOM consistently listed 350–400 components and a new version lists only 180, this anomaly suggests a generation failure rather than a genuine reduction in software content.
• Cross-reference with build manifests: Build systems like Yocto produce detailed manifests listing every recipe and package that went into the image. Comparing the SBOM against the build manifest identifies components that the build system resolved but the SBOM generation tool missed.

Freshness Verification

An SBOM that was complete when generated may become stale if the software it describes has been updated without a corresponding SBOM refresh. Freshness verification compares the SBOM generation timestamp against the most recent software modification timestamp for the same asset. If the ECU firmware was updated via OTA three months ago but the SBOM on record was generated six months ago, the SBOM is stale and may not reflect the current software composition.

Freshness checks should be automated and run continuously. The SBOM management platform should flag any asset where the software version on record (from deployment tracking or OTA management systems) is newer than the SBOM version on record. These staleness alerts should be treated as compliance gaps requiring immediate remediation through SBOM regeneration.

Quality Scoring Across Versions

Not all SBOMs are equal in quality, and quality can vary across versions even for the same asset. A quality scoring framework evaluates each SBOM version against a set of measurable criteria and produces a composite score that enables trend analysis. Key quality dimensions include:

• Identifier coverage: The percentage of components that have valid PURL or CPE identifiers enabling automated vulnerability correlation. SBOMs where components are listed only by name without standardized identifiers are significantly less useful for automated security workflows.
• Version specificity: The percentage of components with exact version numbers rather than version ranges or missing versions. A component listed as “openssl” without a version is nearly useless for vulnerability assessment.
• Dependency depth: Whether the SBOM captures only top-level packages or the full transitive dependency tree. Shallow SBOMs miss vulnerabilities in transitive dependencies, which represent the majority of the dependency graph in most software projects.
• License data: The percentage of components with declared license information. Missing license data creates legal risk and indicates an SBOM that may have been generated with a tool that does not fully analyze component metadata.
• Supplier data: The percentage of components with supplier or author information populated. This is required by NTIA minimum elements and is necessary for supply chain risk assessment.

Track quality scores across versions to detect regressions. If the quality score for a particular ECU SBOM drops between versions, it may indicate a change in build tooling, a new component type that the SCA tool cannot analyze, or a supplier delivering lower-quality SBOMs. Quality score trends are also powerful evidence for UNECE R155 audits, demonstrating that the organization actively monitors and improves its SBOM program over time.

SBOM Version Tracking Across the Supply Chain

Automotive supply chains are deep and interconnected. A Tier-2 semiconductor vendor delivers a BSP to a Tier-1 system integrator, who integrates it with middleware and application software before delivering a complete ECU software package to the OEM. Each tier produces its own SBOM, and each SBOM has its own version history. Tracking these versions across organizational boundaries is one of the hardest problems in automotive SBOM management.

Supplier SBOM Versioning

Every supplier deliverable should include a versioned SBOM that uses the same unique identifier scheme as the software it describes. When a Tier-1 supplier ships firmware revision 4.2.1 for a body controller ECU, the accompanying SBOM should carry a version identifier that maps unambiguously to that firmware revision. If the supplier updates the firmware to 4.2.2 (perhaps patching a single vulnerability in an embedded TLS library), the new SBOM version must clearly document what changed relative to 4.2.1.

The practical challenge is that many suppliers do not yet have mature SBOM versioning practices. They may deliver a fresh SBOM with each software release but without a stable version identifier, without a reference to the previous version, and without any diff information. This forces the OEM to manually compare successive SBOMs to determine what changed — a tedious and error-prone process that does not scale.

Contractual requirements should specify not just the SBOM format and content, but also the versioning scheme. Require suppliers to use the CycloneDX serialNumber (a UUID unique per SBOM document) and version fields, or the SPDX documentNamespace (a unique URI per document version), to provide stable identifiers that enable automated version tracking and diff analysis on the OEM side.

Cascading Version Updates (Tier-2 to Tier-1 to OEM)

When a Tier-2 supplier updates a component, the version change must cascade through the supply chain. If the Tier-2 updates a cryptographic library from version 2.1 to 2.2 to patch a vulnerability, the Tier-1 who integrates that library must update their SBOM to reflect the new version, and the OEM must update the vehicle-level SBOM to incorporate the Tier-1 update. This cascade must happen reliably and promptly — the EU CRA’s 24-hour notification requirement for actively exploited vulnerabilities means there is no room for version information to lag by weeks as it passes through supply chain tiers.

Effective cascading requires machine-readable version relationships between SBOMs at different tiers. The Tier-1 SBOM should reference the Tier-2 SBOM version it incorporates, and the OEM SBOM should reference the Tier-1 SBOM versions for each ECU. In CycloneDX, the externalReferences field with type bom provides this capability, linking to the sub-SBOM document. In SPDX, the ExternalDocumentRef element serves the same purpose. When the Tier-2 publishes a new SBOM version, automated systems can detect that the Tier-1 SBOM references an outdated Tier-2 version and flag it for update.

SBOM Exchange Versioning Protocols (CycloneDX serialNumber, SPDX namespace)

Both major SBOM formats provide built-in mechanisms for versioning and identity, but they work differently and understanding the distinction matters for supply chain exchange.

CycloneDX uses a two-part identity scheme. The serialNumber field is a UUID that uniquely identifies a specific SBOM document — a new serialNumber is generated each time the SBOM is produced, even for the same software. The version field is an integer that indicates the revision number within a logical SBOM sequence. Together, these fields allow consumers to determine both the identity of the SBOM (is this a new SBOM or a revision of one I already have?) and its position in a sequence (is this version 3 newer than the version 2 I already have?). For supply chain exchange, the combination of serialNumber and version provides a complete versioning protocol that supports both initial delivery and incremental updates.

SPDX uses the documentNamespace field, which is a unique URI that identifies a specific SPDX document. The namespace typically includes the document name and a UUID or version identifier, ensuring global uniqueness. When a new version of the SBOM is produced for the same software component, a new namespace is assigned. SPDX does not have a separate version integer field like CycloneDX; instead, the namespace itself changes to indicate a new version. This makes it slightly harder to determine the ordering of SPDX versions programmatically, unless the namespace includes an explicit version component (which is a recommended practice).

For supply chain exchange, standardize on one approach and document it in your bilateral agreements with suppliers. If you use CycloneDX, require suppliers to populate both serialNumber and version fields. If you use SPDX, require a consistent namespace naming convention that includes a version component. Without these conventions, automated version tracking across supply chain boundaries becomes unreliable.

Reconciling SBOM Versions with OTA Updates

Over-the-air updates are the primary mechanism by which the software composition of production vehicles changes after initial delivery. Every OTA update that modifies ECU firmware changes the ground truth of what software is deployed in the field. If the SBOM management system does not stay synchronized with the OTA management system, the SBOM inventory becomes stale — and stale SBOMs produce stale vulnerability assessments that may miss critical exposure.

The OTA-SBOM Synchronization Problem

The OTA-SBOM synchronization problem arises because OTA update systems and SBOM management systems are typically separate platforms maintained by different teams. The OTA team knows which software version was pushed to which vehicles. The cybersecurity team knows which SBOM version maps to which software version. But unless these two systems are integrated, there is no single source of truth that can answer the question: “For vehicle VIN WBAXXXXXXXXXX, what is the current SBOM for each ECU?”

This gap becomes critical during incident response. When a critical vulnerability is announced, the security team queries their SBOM management system for affected components. The system returns a list of SBOM versions containing the vulnerable component. But mapping those SBOM versions to specific vehicles in the field requires cross-referencing with the OTA deployment records — which vehicles received which software updates, which updates succeeded, and which vehicles are still running older versions because they have not connected to the OTA server recently.

The OTA SBOM synchronization challenge is compounded by fleet heterogeneity. At any given time, a fleet of 500,000 vehicles of the same model may be running five or more different software versions because OTA updates roll out gradually and not every vehicle is always connected. The SBOM management system must track not just the latest SBOM version but the entire version distribution across the deployed fleet.

Integrating SBOM Generation into the OTA Pipeline

The most reliable way to maintain OTA-SBOM synchronization is to make SBOM generation an integral, non-optional step in the OTA package build pipeline. When the OTA team builds an update package, the same pipeline that compiles the software, signs the package, and stages it for deployment should also generate the corresponding SBOM, validate it, sign it, and upload it to the SBOM management platform. This ensures that no OTA update can be deployed without a corresponding SBOM.

The integration architecture should follow this sequence:

1. Build: Compile the ECU firmware or software package intended for OTA deployment.
2. SBOM generation: Run the SCA tool against the build output, producing a CycloneDX or SPDX document with a unique serialNumber or documentNamespace.
3. SBOM validation: Verify format conformance, minimum field completeness, component count plausibility against the historical baseline, and quality score above the minimum threshold.
4. SBOM signing: Cryptographically sign the SBOM alongside the OTA package, linking the two artifacts together.
5. Upload: Push the signed SBOM to the management platform, tagged with the OTA package identifier, target ECU type, target vehicle platforms, and target markets.
6. Deployment tracking: As the OTA system deploys the update to individual vehicles, the SBOM management platform receives deployment events and updates its records to reflect which vehicles are now running software described by the new SBOM version.

This pipeline integration ensures a one-to-one mapping between OTA packages and SBOM versions. When the security team queries “which vehicles have a vulnerable component,” the system can answer precisely because it knows which SBOM version each vehicle is running, and each SBOM version was produced from the same build that created the OTA package.

Handling Partial and Failed Updates

Not every OTA update succeeds. Network interruptions, battery voltage drops, storage constraints, and verification failures can all cause an OTA update to fail partway through. From an SBOM perspective, a partially updated ECU is in an indeterminate state — it may be running the old software version, the new version, or a corrupted mix of both. The SBOM management system must account for these failure modes.

Modern OTA systems implement A/B partitioning or rollback mechanisms that guarantee the ECU is always in a known state: either the old version (if the update failed and rolled back) or the new version (if the update succeeded). The OTA system reports the outcome of each update attempt to the backend, and this outcome must be propagated to the SBOM management system. If the update succeeded, the SBOM is updated to the new version. If the update failed and rolled back, the SBOM remains at the previous version. If the update is in progress (queued but not yet installed), the SBOM should reflect the currently running version, not the pending version.

Edge cases arise when the OTA system and SBOM management system disagree on the current state. For example, the OTA system may report a successful update, but the vehicle has not reported back to confirm installation. In these ambiguous cases, the SBOM management system should flag the vehicle as “unconfirmed” and treat the SBOM version as uncertain until the vehicle next connects and reports its actual software inventory. This conservative approach prevents false confidence in vulnerability assessments.

Fleet-level reporting should distinguish between vehicles with confirmed current SBOMs, vehicles with pending updates, vehicles with unconfirmed update status, and vehicles that have not connected to the OTA server within a defined freshness window. This segmentation allows the security team to prioritize verification efforts and provides honest reporting to auditors about the actual coverage and freshness of SBOM data across the fleet.

Key Takeaways

• SBOM version tracking is the difference between a compliance checkbox and operational security. Generating a single SBOM is easy. Managing thousands of SBOM versions across ECUs, builds, releases, variants, and supply chain tiers over a 15-year vehicle lifecycle is the real challenge that determines whether your SBOM program can actually answer vulnerability questions in hours rather than weeks.
• Adopt a hybrid versioning strategy. Use per-build versioning in CI/CD for complete traceability, per-ECU versioning as the organizational unit that mirrors how automotive software is actually developed and deployed, and per-release tagging to identify the SBOM versions that map to production deployments. CycloneDX serialNumber/version and SPDX documentNamespace provide the identity mechanisms.
• SBOM diff analysis is essential for efficient security operations. Computing the precise delta between SBOM versions tells security teams exactly which components require fresh vulnerability assessment, which known CVEs are resolved, and which new risks are introduced. Without diff, every release requires full re-assessment of the entire component inventory.
• Completeness verification prevents the silent failure of incomplete SBOMs. Use binary-to-SBOM reconciliation, runtime inventory comparison, historical baseline anomaly detection, and build manifest cross-referencing to identify coverage gaps. Track quality scores across versions to detect regressions early.
• Supply chain version tracking requires contractual and technical coordination. Require suppliers to use standardized SBOM versioning fields (serialNumber, version, documentNamespace), establish machine-readable references between SBOMs at different tiers, and build automated cascade detection to flag when upstream SBOM updates have not been propagated downstream.
• OTA-SBOM synchronization must be a pipeline integration, not a manual process. Make SBOM generation a mandatory, automated step in the OTA package build pipeline. Propagate deployment events from the OTA management system to the SBOM management platform so that the SBOM inventory always reflects what is actually deployed in the field, including handling partial and failed updates.
• EU CRA Article 13 demands ongoing SBOM currency. A release-time SBOM that is never updated does not satisfy the regulation. Version tracking, freshness verification, and supply chain cascade propagation are the mechanisms that maintain SBOM currency throughout the product lifetime as required by the CRA, UNECE R155, and ISO/SAE 21434 Clause 8.