Monitoring Vulnerabilities in Next-Generation Automotive Operating Systems

Badis Hammi; Dimitri Simon; Herv\'e Debar; Joaquin Garcia-Alfaro

REVIEW 1 major objections 6 minor 46 references

Monitoring Vulnerabilities in Next-Generation Automotive Operating Systems

T0 review · 1 major / 6 minor · reviewed 2026-07-09 · glm-5.2

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read Even certified car operating systems carry hundreds of known vulnerabilities

desk verdict Practical automotive CVE scanner with useful survey, but core 'more actionable' claim is unvalidated against ground truth read the letter →

arxiv 2607.07226 v1 pith:TGCPOMNE submitted 2026-07-08 cs.CR

Dimitri Simon , Badis Hammi , Joaquin Garcia-Alfaro , Hervé Debar This is my paper · ORCID

classification cs.CR

keywords software-definedvehiclevulnerabilityscanningautomotiveoperatingsystemsCVEPOSIXexploitabilityassessmentcybersecuritycontainersecurity

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

As cars become software-defined vehicles running POSIX-compatible operating systems, they inherit the vast vulnerability catalogs of the desktop and mobile computing world. This paper scans 14 automotive operating systems and middleware platforms for known CVEs and finds that even safety-certified, real-time operating systems carry dozens of vulnerabilities, while consumer-grade infotainment platforms carry hundreds to over a thousand. The authors build a tool that filters raw scanner output to remove CVEs irrelevant in automotive contexts and then attempts to validate exploitability in containerized replicas of these systems. They demonstrate two working attacks: a SQLite vulnerability exploitable in Android Automotive OS and a SOME/IP service de-association attack that succeeds on some platforms but fails on others, showing that identical CVEs can have divergent real-world outcomes depending on platform-specific defenses.

What carries the argument

The paper's mechanism is a pipeline called VERA that combines multiple vulnerability scanners (Grype, CVE Binary Tool, Vanir, Yocto's cve-check) with a custom filtering layer that removes packages irrelevant in automotive contexts (e.g., developer toolchains, non-privileged CLI utilities), then feeds remaining CVEs into a Docker-based exploitability assessment environment where specific symbols, changelogs, and configurations are checked and proof-of-concept exploits are mounted and tested.

What would settle it

A real-world in-vehicle deployment of one of the tested platforms where the CVEs identified by VERA are overwhelmingly false positives due to vendor hardening, or conversely, where critical exploitable vulnerabilities exist that are invisible to container-based scanning because they depend on hardware-specific code paths or proprietary middleware not present in the Docker image.

Watch

Extended reading notes

Core claim

The central finding is that the migration of automotive systems to POSIX-compatible platforms creates a measurable and substantial vulnerability surface that is not eliminated by safety certification. The paper's tool, applied across 14 platforms, reveals that certified RTOSes like QNX Neutrino and VxWorks 7 carry 33 to 56 CVEs respectively, while infotainment-focused platforms like AGL carry over 1,200. The authors further show that generic vulnerability scanners produce excessive noise when applied to automotive stacks, and that context-aware filtering combined with exploitability validation in containerized environments can reduce this noise and surface vehicle-relevant threats. The de-协会

Load-bearing premise

The paper assumes that Docker container environments faithfully preserve the filesystem, installed packages, and software configurations needed to assess vulnerabilities, even though the authors acknowledge this setup cannot capture vendor-specific kernel builds, firmware interactions, hardware-dependent behavior, or platform-specific security mechanisms that can block exploits in real vehicles.

Editorial extensions

If this is right

Automotive OEMs adopting POSIX-based infotainment or ADAS platforms should integrate context-aware vulnerability filtering into their CI/CD pipelines rather than relying on raw scanner output that buries actionable threats under irrelevant findings.
Safety certification standards like ISO 26262 ASIL and Common Criteria EAL reduce but do not eliminate the CVE surface in automotive operating systems, suggesting that certification regimes need complementary continuous-vulnerability-monitoring requirements.
The divergence in exploitability outcomes for the same CVE across different platforms (e.g., the de-association attack succeeding on AutoSD/TeslaOS but failing on AAOS) implies that vulnerability severity scores alone are insufficient for automotive risk assessment without platform-specific exploitability validation.
Fleet-wide OTA update mechanisms become critical attack vectors when the underlying OS carries hundreds of known-exploited vulnerabilities, making vulnerability monitoring a fleet-safety rather than merely a per-vehicle concern.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

If containerized scanning already reveals hundreds of CVEs per platform, real in-vehicle deployments with vendor-specific kernel modifications, proprietary middleware, and hardware-dependent code paths likely harbor additional vulnerabilities invisible to filesystem-level scanning, meaning the reported counts are lower bounds.
The correlation between ecosystem openness and CVE count (open platforms like AGL showing the most CVEs) may partly reflect greater scrutiny rather than greater insecurity, suggesting that closed proprietary platforms could harbor comparable unreported vulnerability populations.
The filtering approach could be extended to other safety-critical POSIX-adjacent domains (medical devices, industrial control systems, avionics) where the same tension between generic scanner noise and domain-specific relevance applies.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Short version: this is a solid engineering paper with a genuinely useful survey component and a working tool, but the central claim that VERA produces more actionable results than existing scanners is never validated against ground truth. The Docker fidelity gap is acknowledged but not bounded, and the filtering heuristics are ad hoc. I think it deserves a serious referee because the survey and tool release have real value, but the authors need to either quantify filtering effectiveness or tone down the comparative claims considerably. The reader's CONDITIONAL verdict is about right, maybe slightly generous on soundness. The stress-test concern lands squarely: the 'more actionable' claim has two pillars (filtering removes noise without removing true positives; Docker preserves what matters for exploitability), and neither is measured against a ground-truth benchmark. The de-association case study actually demonstrates the Docker fidelity gap empirically — the same weakness succeeded on AutoSD/TeslaOS but failed on AAOS due to platform-specific defenses absent in the container. That's an honest finding, but it undercuts the broader exploitability claims across all 14 platforms. The filtering rules (exclude CLI tools, developer toolchains) are reasonable domain adaptations but entirely heuristic — no false-negative measurement. What's genuinely new and well done: the systematic compilation mapping specific vehicle models to their OS/SoC combinations (Table III) and the certification status survey (Table II) are valuable reference material I haven't seen elsewhere. The tool is publicly released with two working exploits, which is real reproducible work. The TARA-based risk assessment for the two attack scenarios adds structure, though the qualitative feasibility scores are subjective. The CVE counts across 14 platforms are useful as a landscape overview, even if they shouldn't be read as exploitability verdicts. The reader is right that this is an engineering contribution, not a methodological advance. The novelty is moderate — combining existing scanners with automotive-specific filtering is practical but incremental. Where I'd push back on the reader: the significance_if_true score of 5.0 feels slightly low given the survey alone is a useful contribution for the community. The paper is for automotive security practitioners and researchers who need a starting point for CVE assessment on POSIX-based vehicle platforms. It's not for someone looking for a new vulnerability detection method. It deserves a serious referee who can assess whether the authors can strengthen the validation or whether the contribution stands on the survey and tool release alone.

Referee Report

1 major / 6 minor

Summary. This paper presents VERA, a vulnerability scanning and analysis suite designed for POSIX-compatible operating systems used in software-defined vehicles (SDVs). The work surveys automotive OS/middleware platforms, scans 14 such platforms for CVEs using a combination of existing scanners (Grype, CBT, Vanir, cve-check) and a custom built-in scanner, applies heuristic filtering to reduce noise, and validates two vulnerabilities through controlled exploitation (CVE-2022-35737 on AAOS, SOME/IP de-association on AutoSD/TeslaOS). The paper also systematizes automotive OS certifications (EAL, ASIL, SIL, CAL) and maps real vehicle models to their OS/SoC combinations. The tool and proof-of-concept exploits are publicly released.

Significance. The paper addresses a genuine gap: existing vulnerability scanners were not designed for automotive POSIX-based platforms and produce excessive noise when applied to them. The systematic mapping of automotive OS certifications (Table II), vehicle models to OS/SoC combinations (Table III), and platform use cases (Table IV) is a useful contribution for the community. The public release of VERA's source code, PoCs, and exploit demonstrations (GitHub repository with video captures) is commendable and supports reproducibility. The cross-platform CVE benchmark across 14 automotive OS/middleware platforms provides a first-of-its-kind comparative snapshot. The two demonstrated exploits (SQLite CVE-2022-35737 and SOME/IP de-association) provide partial end-to-end validation of the scanning-to-exploitation workflow.

major comments (1)

§IV.B and §VI: The central claim that VERA provides 'more actionable' results than existing scanners rests on the filtering heuristics (excluding non-sudo CLI tools, developer toolchains, interpreters). However, the false-negative rate introduced by this filtering is never measured. Table V shows that filtering removes between 0.6% (AAOS 34) and 59.8% (AutoSD) of CVEs, but there is no ground-truth validation that the removed CVEs are genuinely non-exploitable in automotive contexts. For example, a 'developer toolchain' vulnerability in GCC could be leveraged to bypass ASLR (as the authors themselves note in §IV.B), yet such CVEs are filtered out by default. The authors should either (a) construct a ground-truth benchmark of known-exploitable and known-patched CVEs on at least one real automotive platform to measure the filtering false-negative rate, or (b) substantially soften the 'more'

minor comments (6)

Table III: The year column is not sorted chronologically (e.g., 2024 BYD appears before 2022 XPeng, 2022 Toyota). Consider sorting by year for readability.
§V: The EPSS threshold of 0.0003 and CVSS threshold of 5.0 for the 'potential online exploits' column in Tables IX–X are stated without justification. A brief rationale for these cutoffs would help reproducibility.
Table VII: The comparison of scanners lists VERA's cons as 'No state tracking' and 'Not full support of scanner reports,' but these limitations are not discussed in the text. A brief discussion of how these gaps affect the results would strengthen the comparison.
§II.C: The description of TeslaOS notes that 'publicly shared TeslaOS materials primarily refer to Tesla's infotainment/system Linux stack,' but Table XI classifies TeslaOS without a safety/non-safety designation. Clarifying whether TeslaOS was scanned as infotainment-only would help interpret the 243 CVEs reported.
Figure 3: The architecture diagram uses color-coded access modes (read-only, write-only, read & write) but the legend is small. Enlarging or splitting into sub-figures would improve readability.
§V, Table XVI: The TARA feasibility scores in Table XIV (e.g., '≤6 months = 17') are applied to specific scenarios, but the justification for assigning '≤6 months' to 'ATM-T0011: Browser Compromise' for Scenario B is unclear. A brief justification for each temporal estimate would make the risk assessment in Table XVIII more convincing.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: VERA's results are empirical scanner outputs filtered by heuristic rules, not predictions derived from fitted parameters or self-cited theorems.

full rationale

The paper's derivation chain is straightforwardly empirical. VERA scans automotive OS images using existing scanners (Grype, CBT, Vanir, cve-check), applies heuristic filtering rules (excluding CLI tools, developer toolchains), and reports CVE counts as observations. No step in this chain reduces to its inputs by construction. The filtering rules (§IV.B) are design choices, not fitted parameters renamed as predictions. The CVE counts in Tables V–XI are descriptive outputs of scanner runs, not derived quantities. The exploitability assessment involves direct verification (symbol presence checking) and actual controlled exploitation (CVE-2022-35737 on SQLite, de-association attack on SOME/IP). The two self-citations — Sghaier et al. [34] (co-author Hammi) for SDV systemization background, and Pitchamaini et al. [11] (co-author Hammi) for ATM/TARA integration — provide contextual framing for the threat model (§III) but are not load-bearing for VERA's core technical contribution of scanning, filtering, and exploitability assessment. Neither citation invokes a uniqueness theorem or ansatz that would force the paper's conclusions. The acknowledged limitations (Docker fidelity gap, CVSS imperfection) are correctness concerns, not circularity: the authors explicitly state these as gaps rather than disguising them as validated results. The de-association case study honestly reports divergent outcomes across platforms (success on AutoSD/TeslaOS, failure on AAOS), which is the opposite of a circular argument where the conclusion is forced by construction.

Assumptions & free parameters 3 free parameters · 4 assumptions · 1 invented entities

The paper introduces no new mathematical entities or physical postulates. The free parameters are threshold values for reporting and qualitative TARA scores. The primary axiom (Docker fidelity) is explicitly acknowledged as a limitation by the authors themselves.

free parameters (3)

EPSS threshold = 0.0003 (0.03%)
Used in Tables IX-X to filter CVEs for exploit availability reporting; chosen as a cutoff without sensitivity analysis.
CVSS threshold = 5.0
Used alongside EPSS threshold to filter CVEs for exploit reporting in Tables IX-X; no justification provided for this specific value.
TARA feasibility scores = Qualitative assignments in Table XVI
Elapsed time, expertise, knowledge, opportunity, and resources values for attack scenarios A and B are author-assigned qualitative estimates, not measured quantities.

assumptions (4)

domain assumption Docker containers preserve the filesystem, installed packages, and software configurations relevant for vulnerability assessment of automotive OSes.
Stated in §IV.A: containers 'perfectly preserve the crucial elements required to validate our semi-white-box approach.' This is the foundational assumption enabling all experimental results.
domain assumption CVSS severity scores are a meaningful proxy for vulnerability risk in automotive contexts.
Used throughout Tables IX-XI to categorize and compare vulnerability landscapes. The paper acknowledges (§II.A) that 'severity scores alone are an imperfect proxy' but still relies on them for all quantitative comparisons.
ad hoc to paper Excluding CLI tools and developer toolchains from vulnerability reports improves signal-to-noise for automotive attack surface assessment.
The filtering heuristic in §IV.B assumes an attacker on a vehicle does not have CLI access except for sudo commands. This drives the filtering ratios in Table V but is not validated against ground truth.
domain assumption Public CVE databases (MITRE, NVD) accurately represent the vulnerability landscape of automotive software stacks.
VERA's scanner uses MITRE CVE List V5 as its primary data source. The completeness and accuracy of this database for automotive-specific components is assumed but not verified.

invented entities (1)

VERA (Vulnerability Exposure and Reporting Analysis suite) independent evidence
purpose: Multi-scanner integration framework with automotive-specific filtering, exploitability assessment, and exploit retrieval
Publicly released on GitHub with proof-of-concept exploits; the tool is falsifiable in that its scanning results can be independently reproduced against the same Docker images.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Monitoring Vulnerabilities in Next-Generation Automotive Operating Systems." pith.science (2026). https://pith.science/paper/TGCPOMNE

@misc{pith2026260707226,
  author       = {Pith},
  title        = {Pith review of: Monitoring Vulnerabilities in Next-Generation Automotive Operating Systems},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/TGCPOMNE}},
  note         = {Machine review of arXiv:2607.07226}
}

read the original abstract

Software-defined vehicles (SDVs) are revolutionizing transportation by integrating complex, interconnected hardware, and software systems. This evolution introduces significant security challenges. We present a comprehensive security analysis for SDVs, focusing on software vulnerabilities. We note that existing vulnerability assessment tools fall short in addressing operating systems vulnerabilities, particularly when it comes to efficiently analyzing diverse software stacks in realistic environments. We present and release a vulnerability assessment solution that efficiently addresses these limitations. Our approach combines systematic vulnerability discovery, leveraging public Common Vulnerabilities and Exposures (CVE) databases, within a dockerized development environment that evaluates exploitability risks. The results reveal both breadth of potential threats and the practical constraints we faced during exploitation. We discuss the implications for industry and research, and propose directions for building more resilient SDVs.

Figures

Figures reproduced from arXiv: 2607.07226 by the authors.

**Figure 2.** Deployment architectures for infotainment and ADAS: (a) physical isolation (per-ECU), (b) physical isolation with [PITH_FULL_IMAGE:figures/full_fig_p007_2.png] view at source ↗

**Figure 3.** describes VERA’s architecture. Other Scanners refers to tools like Vanir32 or CVE Binary Tool (CBT)33 . To use the built-in scanner Scanner, it has to (1) create a new database Formatted DB in a custom standard format based on MITRE DB, to eventually (2) scan a Docker image. It is also possible to use another scanner cf. Other Scanners, where CBT would allow to scan an Android emulator through Android Debug Bridge… view at source ↗

Figures from the paper (2 more)

**Figure 4.** Figure 4: Workflow of VERA: (a) setup, (b) Docker images/Android devices scanning, (c) Results analyses and exploitability [PITH_FULL_IMAGE:figures/full_fig_p010_4.png]

**Figure 5.** Figure 5: Killchain state machines for the paths of scenarios A and B. [PITH_FULL_IMAGE:figures/full_fig_p015_5.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

46 extracted references · 46 canonical work pages

[1]

Pes ´e, Chiara Bodei, Ilaria Matteucci, Richard R

Marco De Vincenzi, Mert D. Pes ´e, Chiara Bodei, Ilaria Matteucci, Richard R. Brooks, Monowar Hasan, Andrea Saracino, Mohammad Hamad, and Sebastian Steinhorst. Contextualizing security and privacy of software-defined vehicles: State of the art and industry perspectives, 2024

work page 2024
[2]

Android Automotive OS Update Bul- letin—September 2024

Android Automotive OS. Android Automotive OS Update Bul- letin—September 2024. Technical report, Android Automotive OS, September 2024

work page 2024
[3]

Harness: Transparent and lightweight protection of vehicle control on untrusted android automo- tive operating system

Haochen Gong, Siyu Hong, Shenyi Yang, Rui Chang, Wenbo Shen, Ziqi Yuan, Chenyang Yu, and Yajin Zhou. Harness: Transparent and lightweight protection of vehicle control on untrusted android automo- tive operating system. In34th USENIX Security Symposium: USENIX Security 2025. USENIX Association, 2025

work page 2025
[4]

Vexed by vex tools: Consis- tency evaluation of container vulnerability scanners.arXiv preprint arXiv:2503.14388, 2025

Yekatierina Churakova Mathias Ekstedt. Vexed by vex tools: Consis- tency evaluation of container vulnerability scanners.arXiv preprint arXiv:2503.14388, 2025

work page arXiv 2025
[5]

Davs: Dockerfile analysis for con- tainer image vulnerability scanning.Computers, Materials & Continua, 72(1), 2022

Thien-Phuc Doan and Souhwan Jung. Davs: Dockerfile analysis for con- tainer image vulnerability scanning.Computers, Materials & Continua, 72(1), 2022

work page 2022
[6]

Real- time security warning and ecu identification for in-vehicle networks

Hongqian Wei, Qiang Ai, Wenqiang Zhao, and Youtong Zhang. Real- time security warning and ecu identification for in-vehicle networks. IEEE Sensors Journal, 23(17):20258–20266, 2023

work page 2023
[7]

Review of the security of backward-compatible automotive inter-ecu communication.IEEE Access, 9:114854–114869, 2021

Chandra Sharma, Samuel Moylan, Eugene Y Vasserman, and George T Amariucai. Review of the security of backward-compatible automotive inter-ecu communication.IEEE Access, 9:114854–114869, 2021

work page 2021
[8]

An endogenous security study of telematics box in intelligent connected vehiclesc.IEEE Embedded Systems Letters, 2024

Zhen Zhang, Yuezhong Zhang, Jinfeng Zhang, Jichao Xie, and Shaoxun Liu. An endogenous security study of telematics box in intelligent connected vehiclesc.IEEE Embedded Systems Letters, 2024

work page 2024

Show all 46 references

[9]

Applying security testing techniques to automotive engineering

Irdin Pekaric, Clemens Sauerwein, and Michael Felderer. Applying security testing techniques to automotive engineering. InProceedings of the 14th International Conference on Availability, Reliability and Security, pages 1–10. ACM, 2019

2019
[10]

Icvtest: A practical black-box penetration testing framework for evaluating cybersecurity of intelligent connected vehicles

Haichun Zhang, Jie Wang, Yijie Wang, Minfeng Li, Jinghan Song, and Zhenglin Liu. Icvtest: A practical black-box penetration testing framework for evaluating cybersecurity of intelligent connected vehicles. Applied Sciences, 14(1), 2024

2024
[11]

Systematic Risk Analysis of Multi-Stage Attacks in Zonal Automotive E/E Architecture

Ramakrishnan Pitchaimani, S ´ebastien Canard, Badis Hammi, and Au- rel Sorin Spornic. Systematic Risk Analysis of Multi-Stage Attacks in Zonal Automotive E/E Architecture. In2025 23nd International Symposium on Network Computing and Applications (NCA), pages 1–9. IEEE, 2025

2025
[12]

Cybersecurity testing for automotive domain: A survey.Sensors, 22(23):9211, 2022

Feng Luo, Xuan Zhang, Zhenyu Yang, Yifan Jiang, Jiajia Wang, Mingzhi Wu, and Wanqiang Feng. Cybersecurity testing for automotive domain: A survey.Sensors, 22(23):9211, 2022

2022
[13]

Comparing vulnerability severity and exploits using case-control studies.ACM Transactions on Information and System Security (TISSEC), 17(1):1–20, 2014

Luca Allodi and Fabio Massacci. Comparing vulnerability severity and exploits using case-control studies.ACM Transactions on Information and System Security (TISSEC), 17(1):1–20, 2014

2014
[14]

Standard, International Organization for Standardization, Geneva, CH, 2018

Ensure comprehensive functional safety for road vehicles, covering all critical aspects from vocabulary to guidelines. Standard, International Organization for Standardization, Geneva, CH, 2018

2018
[15]

Standard, International Organization for Stan- dardization, Geneva, CH, 2024

Road vehicles – Functional safety – Use of pre-existing software architectural elements. Standard, International Organization for Stan- dardization, Geneva, CH, 2024

2024
[16]

Standard, International Organization for Standardization, Geneva, CH, 2021

Road vehicles – Cybersecurity engineering. Standard, International Organization for Standardization, Geneva, CH, 2021

2021
[17]

Standard, International Electrotechnical Commission, Geneva, CH, 2022

Electrical, electronic and programmable electronic safety-related sys- tem. Standard, International Electrotechnical Commission, Geneva, CH, 2022

2022
[18]

Standard, International Organization for Stan- dardization, Geneva, CH, 2022

Information security, cybersecurity and privacy protection – Evaluation criteria for IT security. Standard, International Organization for Stan- dardization, Geneva, CH, 2022

2022
[19]

Exploring the potential of zephyr in automotive and software defined vehicles

Ahmann Philipp. Exploring the potential of zephyr in automotive and software defined vehicles. InOpen Source Summit Europe 2024, Vienna, Austria, September 2024. The Linux Foundation

2024
[20]

Experimental security analysis of a modern automobile

Karl Koscher, Alexei Czeskis, Franziska Roesner, Shwetak Patel, Ta- dayoshi Kohno, Stephen Checkoway, Damon McCoy, Brian Kantor, Danny Anderson, Hovav Shacham, et al. Experimental security analysis of a modern automobile. In2010 IEEE symposium on security and privacy, pages 44...

2010
[21]

Remote exploitation of an unaltered passenger vehicle.Black Hat USA, 2015(S 91):1–91, 2015

Charlie Miller and Chris Valasek. Remote exploitation of an unaltered passenger vehicle.Black Hat USA, 2015(S 91):1–91, 2015

2015
[22]

Iso/sae 21434:2021 road vehicles – cybersecurity engineering, 2021

ISO/SAE. Iso/sae 21434:2021 road vehicles – cybersecurity engineering, 2021

2021
[23]

Automotive cybersecurity: A survey on frameworks, standards, and testing and monitoring tech- nologies.Sensors, 24(18):6139, 2024

Claudiu Vasile Kifor and Aurelian Popescu. Automotive cybersecurity: A survey on frameworks, standards, and testing and monitoring tech- nologies.Sensors, 24(18):6139, 2024

2024
[24]

Cyber attacks via consumer electronics: Studying the threat of covert malware in smart and autonomous vehicles.IEEE Transactions on Consumer Electronics, 69(4):825–832, 2023

Mohammad Sayad Haghighi, Faezeh Farivar, Alireza Jolfaei, Azin Bayrami Asl, and Wei Zhou. Cyber attacks via consumer electronics: Studying the threat of covert malware in smart and autonomous vehicles.IEEE Transactions on Consumer Electronics, 69(4):825–832, 2023

2023
[25]

In- fotainment System Matters: Understanding the Impact and Implications of In-Vehicle Infotainment System Hacking with Automotive Grade Linux

Seonghoon Jeong, Minsoo Ryu, Hyunjae Kang, and Huy Kang Kim. In- fotainment System Matters: Understanding the Impact and Implications of In-Vehicle Infotainment System Hacking with Automotive Grade Linux. In13th ACM Conference on Data and Application Security and Privacy, CODA...

2023
[26]

Driving with sharks: A review of cybersecurity threats in connected vehicles.IEEE Transactions on Intelligent Transportation Systems, 18(11):3081–3090, 2017

Mahmoud Hashem Eiza and Qiang Ni. Driving with sharks: A review of cybersecurity threats in connected vehicles.IEEE Transactions on Intelligent Transportation Systems, 18(11):3081–3090, 2017

2017
[27]

Systematic review on the recent trends of cybersecurity in automobile industry.IEEE Access, 11:106947–106964, 2023

Mohammad Nasim Uddin, Mohammad Jabir Hossain Chowdhury, Fahad Faisal, and Debashis Dipta. Systematic review on the recent trends of cybersecurity in automobile industry.IEEE Access, 11:106947–106964, 2023

2023
[28]

Automotive cyber security - emerging risks and new case study insights.ATZelectronics worldwide, 19:14–19, 2024

Numaan Huq. Automotive cyber security - emerging risks and new case study insights.ATZelectronics worldwide, 19:14–19, 2024

2024
[29]

Security vulnerabilities in toll collection system

Lembhe Pankaj. Security vulnerabilities in toll collection system. Journal of Engineering and Applied Sciences Technology, pages 1–7, 10 2023

2023
[30]

Security analysis of over-the- air updates for connected vehicles.IEEE Internet of Things Journal, 5(6):4965–4974, 2018

Haibo He, Wei Li, and Jun Zhang. Security analysis of over-the- air updates for connected vehicles.IEEE Internet of Things Journal, 5(6):4965–4974, 2018

2018
[31]

Context-aware security for vehicles and fleets: A survey.IEEE Access, 9:101809–101846, 2021

Daniel Grimm, Marco Stang, and Eric Sax. Context-aware security for vehicles and fleets: A survey.IEEE Access, 9:101809–101846, 2021

2021
[32]

Analysis and simulation of cyber at- tacks against connected and autonomous vehicles

Shahida Malik and Weiqing Sun. Analysis and simulation of cyber at- tacks against connected and autonomous vehicles. In2020 International Conference on Connected and Autonomous Driving (MetroCAD), pages 62–70, 2020

2020
[33]

Cybersecurity best practices for the safety of modern vehicles

National Highway Traffic Safety Administration. Cybersecurity best practices for the safety of modern vehicles. Technical Report DOT HS 812 333, NHTSA, 2022

2022
[34]

Advancing security in software- defined vehicles: A comprehensive survey and taxonomy.arXiv preprint arXiv:2510.09675, 2025

Khaoula Sghaier, Badis Hammi, Ghada Gharbi, Pierre Merdrignac, Pierre Parrend, and Didier Verna. Advancing security in software- defined vehicles: A comprehensive survey and taxonomy.arXiv preprint arXiv:2510.09675, 2025

2025
[35]

An- alyzing and securing some/ip automotive services with formal and practical methods

Daniel Zelle, Timm Lauser, Dustin Kern, and Christoph Krauß. An- alyzing and securing some/ip automotive services with formal and practical methods. InProceedings of the 16th International Conference on Availability, Reliability and Security. Association for Computing Machinery, 2021

2021
[36]

https://atm.automotiveisac.com/, 2024

Automotive threat matrix. https://atm.automotiveisac.com/, 2024

2024
[37]

Evaluating container security and reproducibility in research software engineering.Authorea Preprints, 2025

Akshay Mittal and Vivek Venkatesan. Evaluating container security and reproducibility in research software engineering.Authorea Preprints, 2025

2025
[38]

Systematic risk assessment for connected and autonomous vehicles using tara and iso/sae 21434.IEEE Transac- tions on Intelligent Transportation Systems, 22(7):4478–4489, 2021

Xin Wang and Yifan Zhang. Systematic risk assessment for connected and autonomous vehicles using tara and iso/sae 21434.IEEE Transac- tions on Intelligent Transportation Systems, 22(7):4478–4489, 2021

2021
[39]

Simulation- based cybersecurity risk assessment for connected and autonomous vehicles.IEEE Transactions on Intelligent Transportation Systems, 25(10):103005, 2024

Madhawa Jayarathne, Julien Epps, and Karin Maag. Simulation- based cybersecurity risk assessment for connected and autonomous vehicles.IEEE Transactions on Intelligent Transportation Systems, 25(10):103005, 2024

2024
[40]

Security analysis of infotainment systems in software-defined vehicles.IEEE Transactions on Vehicular Technology, 71(5):4872–4883, 2022

Junsung Jeong, Sangwoo Kim, and Jaewoo Lee. Security analysis of infotainment systems in software-defined vehicles.IEEE Transactions on Vehicular Technology, 71(5):4872–4883, 2022. 19

2022
[41]

Lightweight protection mechanism for vehicle control on android automotive os.IEEE Transactions on Dependable and Secure Computing, 20(3):2100–2112, 2023

Wei Gong, Li Zhang, and Jian Wang. Lightweight protection mechanism for vehicle control on android automotive os.IEEE Transactions on Dependable and Secure Computing, 20(3):2100–2112, 2023

2023
[42]

Buczak and Erhan Guven

Anna L. Buczak and Erhan Guven. A survey of cybersecurity tools for vulnerability scanning in containers.IEEE Communications Surveys & Tutorials, 24(4):2356–2387, 2022

2022
[43]

Davs: Dockerfile analysis for container image vulnerability scanning.IEEE Access, 10:87654–87665, 2022

Thanh Doan and Souhwan Jung. Davs: Dockerfile analysis for container image vulnerability scanning.IEEE Access, 10:87654–87665, 2022

2022
[44]

Em- pirical study for open source libraries in automotive software systems

Yanan Zhang, Yuqiao Ning, Chao Ma, Longhai Yu, and Zhen Guo. Em- pirical study for open source libraries in automotive software systems. IEEE Access, 11:123717–123728, 2023

2023
[45]

Tara 2.0 for connected and automated vehicles.IEEE Transactions on Intelligent Transportation Systems, 2025

Meriem Benyahya, Anastasija Collen, Teri Lenard, and Niels Alexander Nijdam. Tara 2.0 for connected and automated vehicles.IEEE Transactions on Intelligent Transportation Systems, 2025

2025
[46]

Privacy Nightmare on Wheels: Every Car Brand Reviewed By Mozilla – Including Ford, V olkswagen and Toyota – Flunks Privacy Test

Mozilla. Privacy Nightmare on Wheels: Every Car Brand Reviewed By Mozilla – Including Ford, V olkswagen and Toyota – Flunks Privacy Test. https://www.mozillafoundation.org, 2023

2023

Pith tools

Reviewed July 9, 2026 · model on record in the stance chip above.

[1] [1]

Pes ´e, Chiara Bodei, Ilaria Matteucci, Richard R

Marco De Vincenzi, Mert D. Pes ´e, Chiara Bodei, Ilaria Matteucci, Richard R. Brooks, Monowar Hasan, Andrea Saracino, Mohammad Hamad, and Sebastian Steinhorst. Contextualizing security and privacy of software-defined vehicles: State of the art and industry perspectives, 2024

work page 2024

[2] [2]

Android Automotive OS Update Bul- letin—September 2024

Android Automotive OS. Android Automotive OS Update Bul- letin—September 2024. Technical report, Android Automotive OS, September 2024

work page 2024

[3] [3]

Harness: Transparent and lightweight protection of vehicle control on untrusted android automo- tive operating system

Haochen Gong, Siyu Hong, Shenyi Yang, Rui Chang, Wenbo Shen, Ziqi Yuan, Chenyang Yu, and Yajin Zhou. Harness: Transparent and lightweight protection of vehicle control on untrusted android automo- tive operating system. In34th USENIX Security Symposium: USENIX Security 2025. USENIX Association, 2025

work page 2025

[4] [4]

Vexed by vex tools: Consis- tency evaluation of container vulnerability scanners.arXiv preprint arXiv:2503.14388, 2025

Yekatierina Churakova Mathias Ekstedt. Vexed by vex tools: Consis- tency evaluation of container vulnerability scanners.arXiv preprint arXiv:2503.14388, 2025

work page arXiv 2025

[5] [5]

Davs: Dockerfile analysis for con- tainer image vulnerability scanning.Computers, Materials & Continua, 72(1), 2022

Thien-Phuc Doan and Souhwan Jung. Davs: Dockerfile analysis for con- tainer image vulnerability scanning.Computers, Materials & Continua, 72(1), 2022

work page 2022

[6] [6]

Real- time security warning and ecu identification for in-vehicle networks

Hongqian Wei, Qiang Ai, Wenqiang Zhao, and Youtong Zhang. Real- time security warning and ecu identification for in-vehicle networks. IEEE Sensors Journal, 23(17):20258–20266, 2023

work page 2023

[7] [7]

Review of the security of backward-compatible automotive inter-ecu communication.IEEE Access, 9:114854–114869, 2021

Chandra Sharma, Samuel Moylan, Eugene Y Vasserman, and George T Amariucai. Review of the security of backward-compatible automotive inter-ecu communication.IEEE Access, 9:114854–114869, 2021

work page 2021

[8] [8]

An endogenous security study of telematics box in intelligent connected vehiclesc.IEEE Embedded Systems Letters, 2024

Zhen Zhang, Yuezhong Zhang, Jinfeng Zhang, Jichao Xie, and Shaoxun Liu. An endogenous security study of telematics box in intelligent connected vehiclesc.IEEE Embedded Systems Letters, 2024

work page 2024