An SBOM Does Not Prove That Automotive Vulnerability Management Works

The same software can produce different vulnerability answers

The study combines vulnerability-database analysis with scans of selected automotive-related repositories using multiple tools. Its most operationally important result is not simply the number of findings. The tools did not produce identical results across repositories, and the authors describe cases where one scanner identified vulnerabilities that others did not.

That matters because an SBOM is an inventory artefact, not a vulnerability-management outcome. Knowing that a component exists is necessary, but the organisation still has to detect relevant vulnerability intelligence, establish whether the affected code is present and reachable, map the result to actual product versions, and decide what action is required.

The control is the lifecycle, not the document

The paper identifies 413 automotive vulnerabilities across its study period and 827 vulnerable libraries in the repository scans. It also highlights overlap in commonly reused dependencies. That creates a blast-radius problem: one vulnerable dependency can require assessment across multiple products, branches and suppliers.

A mature process therefore needs a repeatable chain: component inventory, vulnerability detection, applicability assessment, VEX or equivalent decision record, risk treatment, remediation, verification and retained evidence. Scanner disagreement becomes a governance input rather than an excuse to select the most convenient result.

For OEMs and suppliers, the key assurance question is not whether an SBOM exists. It is whether a new vulnerability can be traced through that chain quickly enough to produce a defensible product decision.

Related context. The same evidence-chain problem appears in VEX applicability decisions and in signed-firmware assurance: inventory only becomes useful when it is tied to the exact deployed product state and a defensible decision.