{"id":"cb03caf6-a5f4-40cf-82e7-ffd943e83b43","arxiv_id":"2607.07226","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"unknown","formal_verification":"none","parameter_count":3,"one_line_summary":"VERA is a vulnerability scanning and filtering suite for automotive POSIX-based operating systems that reduces scanner noise and assesses exploitability in vehicle-specific contexts.","lead":"The paper builds VERA, a tool that scans automotive operating systems for known CVEs and filters them for relevance to vehicle contexts. It matters because modern cars run POSIX-based software stacks with large attack surfaces, and existing scanners produce too much noise for practical triage.","discovery_kind":"unclear","skeptic_critique":{"model":"glm-5.2","headline":"VERA's 'more actionable' claim lacks ground-truth validation; Docker fidelity gap is acknowledged but not bounded.","rationale":"The reader correctly identified the Docker fidelity gap as the load-bearing concern. I agree this is the single most important issue: all quantitative results (Tables V–XI) derive from container scans, and the de-association case study provides direct empirical evidence that the gap matters — the same vulnerability had divergent exploitability outcomes across platforms due to security mechanisms not captured in Docker. The reader also correctly noted the absence of ground-truth validation for the filtering effectiveness claim. I considered whether there might be a more fundamental concern — for instance, whether the CVE-count comparisons across platforms are meaningful given different scanning methods (Grype for non-Android, Vanir/cve-check for Android/Yocto) — but this is a methodological caveat the authors acknowledge, and it does not undermine the core contribution of providing a systematic survey and tool. The Docker fidelity issue is more load-bearing because it affects every quantitative claim in the paper, not just cross-platform comparisons. The paper's independent strengths — public code release, the systematic OS/middleware survey (Tables II–IV), and two working exploits — provide genuine value and justify a CONDITIONAL verdict rather than REJECT. The verdict should remain CONDITIONAL because the contribution is real but the central claim of superior actionability is unvalidated. The authors themselves are transparent about this limitation, which is appropriate, but the paper would be substantially strengthened by even a small ground-truth validation on real hardware. I note that the reader's verdict and my assessment converge, so no adjustment is needed.","tokens_in":24436,"tokens_out":841,"duration_ms":183668,"concrete_test":"Construct a ground-truth benchmark: take one automotive OS (e.g., AGL or AAOS) deployed on actual automotive hardware or a high-fidelity emulator with vendor configurations intact. Manually curate a set of 30-50 CVEs spanning RCE/LPE/ID/DoS classes with known patched/unpatched status. Run VERA and Grype against this benchmark. Measure false-positive rate, false-negative rate, and precision of the filtering step. If VERA's filtering removes any known-exploitable CVE, or if the Docker-based scan misses CVEs present on the real platform due to configuration differences, the 'more actionable' claim weakens.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's central claim is that VERA provides more actionable, vehicle-relevant results than existing scanners. This claim rests on two pillars: (1) the filtering heuristics remove noise without removing true positives, and (2) the Dockerized environment faithfully preserves the elements needed for exploitability assessment. Neither pillar is validated against ground truth. The authors explicitly acknowledge the Docker limitation (§VI: 'does not fully capture the complexity of in-vehicle deployments, including vendor-specific kernel builds and configurations, proprietary implementations, firmware interactions, and hardware-dependent behavior'), and the de-association case study empirically demonstrates the gap: the same weakness was exploitable on AutoSD/TeslaOS but failed on AAOS due to platform-specific security mechanisms absent in the Docker environment. This means the CVE counts, filtering ratios (Table V), and exploitability conclusions all derive from an environment whose fidelity is unmeasured. The filtering heuristics (§IV.B) are described as excluding 'non-sudo command-line utilities' and 'developer toolchains' — reasonable but ad hoc, with no measurement of false-negative rate introduced by filtering. Without a ground-truth benchmark (known-vulnerable and known-patched CVE sets on at least one real automotive platform), the claim that VERA is 'more actionable' than Grype/Trivy is unsubstantiated — it could equally be the case that filtering removes exploitable CVEs or that Docker-based exploitability checks miss platform-specific mitigations. The two successful exploits (CVE-2022-35737 and the de-association attack) demonstrate feasibility but do not validate the broader scanning claims across the 14 platforms.","agreement_with_reader":"agree"},"referee_report":{"model":"glm-5.2","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.","tokens_in":25146,"tokens_out":1010,"duration_ms":144748,"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":[{"comment":"§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'","section":null}],"minor_comments":[{"comment":"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.","section":null},{"comment":"§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.","section":null},{"comment":"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.","section":null},{"comment":"§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.","section":null},{"comment":"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.","section":null},{"comment":"§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.","section":null}],"recommendation":"major_revision","confidential_remarks":"The paper's scope is appropriate for a cybersecurity venue. The main concern is that the 'more actionable' claim is the paper's central selling point over existing scanners, yet it is not validated against ground truth. The Docker fidelity limitation is acknowledged honestly, which is good, but it undermines the exploitability conclusions. The two demonstrated exploits are interesting but insufficient to validate the full pipeline across 14 platforms. The systematization tables (II, III, IV) are genuinely useful and could stand on their own as a contribution even if the scanning framework claims are softened."},"author_rebuttal":null,"desk_editor":{"model":"glm-5.2","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.","headline":"Practical automotive CVE scanner with useful survey, but core 'more actionable' claim is unvalidated against ground truth","tokens_in":25351,"tokens_out":549,"would_cite":false,"duration_ms":88112,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"glm-5.2","headline":"Even certified car operating systems carry hundreds of known vulnerabilities","keywords":["software-defined vehicle","vulnerability scanning","automotive operating systems","CVE","POSIX","exploitability assessment","automotive cybersecurity","container security"],"falsifier":"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.","tokens_in":24658,"feed_emoji":"🚗","tokens_out":962,"duration_ms":205613,"temperature":0.7,"pith_summary":"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.","feed_headline":"Even certified car operating systems carry hundreds of known vulnerabilities","feed_subtitle":"Scanning 14 automotive OS platforms reveals that safety certification does not eliminate the CVE surface inherited from POSIX ecosystems.","key_machinery":"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.","core_discovery":"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-协会","pith_inferences":["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."],"forward_implications":["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."],"fun_headline_variants":["Safety-certified car OS platforms carry dozens to thousands of CVEs","Certified RTOSes carry 33–56 CVEs; infotainment platforms over 1,200","Car OS safety certification does not remove inherited POSIX CVEs","QNX and VxWorks carry dozens of CVEs despite safety certification","14 automotive OS platforms scanned: certification doesn't fix CVE surface"],"cache_read_input_tokens":0,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["Safety-certified car OS platforms carry dozens to thousands of CVEs","Certified RTOSes carry 33–56 CVEs; infotainment platforms over 1,200","Car OS safety certification does not remove inherited POSIX CVEs","QNX and VxWorks carry dozens of CVEs despite safety certification","14 automotive OS platforms scanned: certification doesn't fix CVE surface","POSIX migration gives car operating systems a measurable vulnerability surface","Generic scanners produce excessive noise on automotive OS vulnerability stacks","Certified car OS: 33 to 1,200+ CVEs depending on POSIX footprint"]},"model":"glm-5.2","effort":"low","cost_usd":0.0,"raw_usage":{"total_tokens":1178,"prompt_tokens":437,"completion_tokens":741,"prompt_tokens_details":null},"tokens_in":437,"tokens_out":741,"duration_ms":15868,"temperature":1.0,"reasoning_tokens":645,"cache_read_input_tokens":0,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-07-09T16:47:49.657755+00:00","model_set":{"reader":"glm-5.2"},"falsifier":"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.","supporting_citations":[],"review_version":1}