A Valid Signature Does Not Make Vulnerable Firmware Safe

Authenticity and vulnerability are different properties

Research published in Computers & Security analysed production Android Automotive OS firmware from four vehicle manufacturers, reconstructed software bills of materials from the binaries and mapped embedded components to known vulnerabilities. The researchers also reproduced CVE-2023-5217 through a WebView-based test on an AAOS 10 image that contained the vulnerable library version.

The important point is not that firmware signing failed. The images were legitimate. The security gap was vulnerability retention inside software that could still pass the authenticity checks expected of an approved image.

A signature answers a narrow but essential question: was this artefact signed by an authorised key and has it changed since signing? It does not prove that every dependency is current, that the build contained no vulnerable component, or that the release remains defensible months or years later.

The difficult part starts after the CVE is found

Replacing a vulnerable component in a production vehicle can affect interfaces, timing, memory, dependencies and regression evidence. UN Regulation No. 156 requires manufacturers to manage software updates and assess their impact, while the exact approval consequences depend on the functions and vehicle characteristics affected by the change.

That creates a supply-chain decision problem. The OEM wants the exposure reduced. A Tier 1 may point to an accepted baseline. The software supplier may provide an upstream fix without carrying the cost of vehicle-level integration and validation. A temporary functional restriction can reduce attack surface while creating warranty, customer or contractual consequences.

ISO/SAE 21434 requires cybersecurity activities and responsibilities to be managed across the supply chain. The practical interface should therefore define who investigates exploitability, who implements the fix, who validates it, who funds temporary mitigation, and who owns external communication when evidence is incomplete.

The lifecycle can outlive the supplier

The harder failure mode appears when the original supplier no longer has the capability or commercial incentive to maintain the dependency. A vehicle can remain in service long after a proprietary component changes owner, loses its original engineering team or becomes unsupported.

For critical dependencies, continuity may require more than source-code access. Reproducible build environments, toolchain availability, dependency records, signing and release procedures, triggered maintenance rights and knowledge transfer may be necessary to preserve the practical ability to produce a trustworthy update.

ISO 24089 reinforces the need to manage software-update responsibilities across manufacturers and suppliers. The engineering objective is therefore not simply to preserve code. It is to preserve the complete capability to build, validate, authorise and release the next version safely.

Written by

Antonio González, PhD

Cybersecurity practitioner focused on product security, OT/ICS and cyber-physical systems. Cybersecurity Under Pressure translates incident evidence into engineering and business decisions.

About →LinkedIn ↗