PaperlayerView exact revision on arXiv

Source-linked AI summary

LLMSec-AV: A Vulnerability Taxonomy and LLM-Driven Software Weakness Discovery Framework for Autonomous Vehicles

Md. Wasiul Haque, Sagar Dasgupta, Mizanur Rahman

arXiv:2609.09386v1cs.CR

TL;DR

Safety-critical AV software requires security analysis that understands how code can affect vehicle behavior, a context general-purpose analyzers lack. LLMSec-AV combines an AV-specific taxonomy with LLM-based analysis and recovered up to 0.761 of weakness locations, while conventional analyzers did not exceed matched random expectations.

  • Problem

    General-purpose vulnerability analysis lacks an explicit model of AV actuation reachability and safety impact, despite the safety-critical role of vehicle software.

  • Method

    The study constructs an 18-class machine-readable AV vulnerability taxonomy and uses it as structured context in LLMSec-AV for multi-step weakness analysis with disclosure retrieval.

  • Results

    0.761: model conditions recovered up to 0.761 of 46 upstream-fix weakness locations, while all four static analyzers failed to beat matched random expectations.

  • Takeaways & Limitations

    The findings support using model-based analysis to complement rather than replace static analysis, especially for six weakness classes not directly expressible as rules.

  • Takeaways & Limitations

    The results support analytic rather than statistical generalization because the study uses one public AV stack, one run per condition, and no variance estimate.

Abstract

from arXiv · show

Automated vehicles rely on millions of lines of safety-critical software, yet general-purpose analyzers do not understand which code can affect vehicle motion. This study asks whether large language models (LLMs) with explicit automated-vehicle (AV) security knowledge improve weakness detection beyond rule-based tools. We developed an AV vulnerability taxonomy with 18 weakness classes from vulnerability records, security advisories, and AV-security literature, and integrated it into LLM-based Security Analysis for Automated Vehicles (LLMSec-AV). Evaluated on Autoware, the framework decomposed 770 translation units into 4,673 functions and analyzed 161 functions under four prompting conditions involving taxonomy context, retrieval from 374 prior disclosures, and multi-step analysis. Findings were compared with 46 weakness locations mined from upstream fixes and a flag-volume-matched permutation baseline. CodeQL, Semgrep, cppcheck, and the Clang Static Analyzer evaluated the same code, with AV-specific rules added to CodeQL and Semgrep. Generated fuzzing harnesses were tested using AFL++ and sanitizers. LLM conditions recovered up to 76% of the 46 known weakness locations, outperforming conventional analyzers. CodeQL, Semgrep, and the Clang Static Analyzer matched none, while cppcheck matched one despite 1,301 alerts. Unaided prompting achieved similar detection performance, showing that the taxonomy did not drive recall. However, taxonomy context increased the share of findings assigned to a weakness class from near zero to over 80%, improving interpretability and triage. Six of the 18 classes could not be directly represented as static-analysis rules. LLMSec-AV introduces an AV-specific, machine-readable vulnerability taxonomy for weakness discovery and shows that LLMs can complement conventional analyzers by identifying and organizing safety-relevant findings in real AV software.

INTRODUCTION

Autonomous-vehicle safety depends on the correctness of millions of lines of software, while general-purpose analyzers lack models of actuation reachability and transportation-specific safety impact. The study addresses this gap by constructing an 18-class machine-readable AV vulnerability taxonomy and developing LLMSec-AV around domain-grounded analysis.

  • Motivation: AV safety depends partly on the correctness of several million lines of software implementing perception, localization, prediction, planning, and control.Every steering, acceleration, or braking command results from computation, making software faults a systematic source of potentially hazardous behavior.
  • Limitations of Existing Analysis: General-purpose analyzers detect common weaknesses but do not inherently model data reaching steering actuators, externally influenceable inputs, or transportation-specific safety impacts.The limitation applies to CodeQL, Semgrep (Semgrep, Inc. 2025), cppcheck, and the Clang Static Analyzer (LLVM Project 2025).
  • LLM-Based Analysis: LLMs may provide AV-specific security context, but prompting them only to identify security bugs does not explicitly model actuation reachability or safety impact.Their code-generation and reasoning capabilities are established (Chen et al. 2021), while vulnerability-detection results on generic corpora are mixed.
  • Contributions: The study constructs a machine-readable AV vulnerability taxonomy with 18 operationally defined weakness classes, including seven specific to the cyber-physical driving context.Classes are mapped to CWE identifiers (MITRE Corporation 2024), instantiated in ROS 2 idioms, and linked to supporting disclosed vulnerabilities.
  • Evaluation Design: The evaluation uses real Autoware code and distinguishes analyzer-reported hypotheses from confirmed findings, requiring fuzzing harnesses to reproduce reported weaknesses.Autoware is analyzed at a pinned commit with its native build configuration so analyzers, the language model, and fuzzer operate on the same code; fuzzing uses Fioraldi et al. (2020).

RELATED WORK … Weakness Discovery in Source Code

Prior work extensively examines network, middleware, and sensor threats, but provides limited support for source-level detection of application weaknesses whose importance depends on automated-driving context. Because proprietary platforms are not inspectable and conventional analyzers do not model vehicle-level consequences, open-source stacks provide the practical basis for this study.

  • RELATED WORK: Prior research extensively characterizes network, middleware, and sensor threats, while offering limited support for detecting application-level weaknesses tied to automated-driving context.The study therefore addresses a gap between established vehicle-security research and context-dependent source-level weakness discovery.
  • Automated Driving Software Platforms: Proprietary platforms from Waymo, Zoox, Aurora, Mobileye, and Tesla are unavailable for independent source-level analysis, limiting review to documentation, reports, and operational statistics.Their safety claims cannot be evaluated through inspectable source artifacts.
  • Automated Driving Software Platforms: Autoware provides a full ROS 2-based pipeline from sensing through control, while Apollo offers comparable scope through CyberRT and openpilot provides driver assistance only.The cited platforms differ in system scope, with Autoware and Apollo covering end-to-end automated-driving functions.
  • Automated Driving Software Platforms: Because source-analysis methods require accessible code and reproducible builds, open stacks are the practical basis for this study.This requirement motivates evaluating an open automated-driving platform rather than proprietary systems.
  • Security of Automated and Connected Vehicles: Earlier studies demonstrated remote compromise of in-vehicle networks, while later work examined ROS trust, SROS2 security, DDS/RTPS attacks, and sensor spoofing.Sensor spoofing is explicitly outside this study’s scope.
  • Weakness Discovery in Source Code: CodeQL, Semgrep, cppcheck, and the Clang Static Analyzer provide declarative, syntactic, local-checking, and path-sensitive strategies, respectively, but none natively models ROS 2 sources, actuation reachability, or vehicle-level consequences.Their complementary designs motivate comparison with an approach that incorporates automated-driving context.

THREAT MODEL AND SCOPE … Evaluation Boundary

The study models ROS 2 participants with DDS access as capable of manipulating communication and inputs, and evaluates C++ Autoware on ROS 2 Humble within a defined, reproducible boundary. Autoware provides an analytic case study, while physical, hardware, side-channel, and supply-chain attacks remain out of scope.

  • THREAT MODEL AND SCOPE: DDS-accessible ROS 2 participants may publish to topics, invoke services, or modify parameters unless optional security plugins are provisioned.This threat model follows ROS 2’s default trust posture.
  • Terminology: A weakness is a defect class, whereas a vulnerability is a specific exploitable instance; confirmed findings require sanitizer-detected faults within the fuzzing budget.Unconfirmed findings remain unresolved rather than automatically being treated as false positives.
  • Experimental Case: Autoware is the reproducible case study because it is full-stack, production-representative, buildable at a pinned revision, and supported by public development history.The single-case design supports analytic rather than statistical generalization; Apollo uses CyberRT, while openpilot has narrower driver-assistance scope.
  • Experimental Case: Autoware’s ROS 2 nodes exchange typed DDS messages across sensing, perception, localization, planning, control, and actuation, but typing does not ensure semantic validity.For example, float64 fields may contain NaN or infinity, and concurrency depends on callback groups and executor configuration.
  • Attacker Capabilities: The adversary may publish, invoke services, modify parameters, disrupt streams, or provide forwarded off-vehicle inputs, while physical, hardware, side-channel, and supply-chain attacks are excluded.In-scope forwarded inputs include maps, calibration files, V2X messages, and teleoperation commands.
  • Evaluation Boundary: The evaluation targets C++ Autoware on ROS 2 Humble, covering 770 non-test, non-generated translation units from the workspace compilation database.Native compilation commands preserve consistent type resolution across parsing, CodeQL extraction, and harness compilation.

AV VULNERABILITY TAXONOMY … Example Classes in Detail

The AV vulnerability taxonomy defines 18 driving-relevant weakness classes grounded in vulnerability records, security literature, and ROS 2/DDS behavior. Detailed examples show why vehicle context, middleware semantics, numerical validity, and actuator consequences challenge conventional analysis.

  • AV VULNERABILITY TAXONOMY: Classes are included when weakness significance is specific to or materially amplified by automated driving, considering function, input path, middleware context, and vehicle consequence.The taxonomy table distinguishes AV-only classes from generic weaknesses whose consequence class changes in a vehicle, and records whether each class is expressible as a static-analysis rule.
  • Construction: The taxonomy draws on 372 retained records from 393 NVD and advisory entries, AV and robotics security literature, and documented ROS 2 and DDS defaults.CVE API queries covered robotics, middleware, automotive, and embedded-control terms, while exact-phrase and domain-anchor filtering reduced off-domain matches.
  • Structure and Evidence: The taxonomy contains 18 classes—7 AV-specific and 11 AV-amplified—mapped to 18 primary CWE identifiers and supported by 416 intersecting vulnerability records.Each class records provenance, code pattern, ROS 2 instantiation, vehicle consequence, detection notes, severity prior, and an ISO/SAE 21434 impact rating for SAE Level 4 operation.
  • Example Classes in Detail: AV-VULN-001 illustrates a shared safety-critical state race in which callbacks access vehicle state without mutual exclusion, potentially producing commands for states the vehicle never occupied.The race can arise from ROS 2 executor and callback-group semantics rather than explicit thread creation, so analyzers focused on standard threading and locking may miss it.
  • Example Classes in Detail: Figure 1 orders taxonomy classes by the number of supporting corpus records and distinguishes AV-specific classes from AV-amplified classes with filled and hollow markers, respectively.The evidence count is based on corpus records whose CWE mappings intersect each class.
  • Example Classes in Detail: The examples show that several AV weaknesses require context-dependent reasoning across middleware behavior, numerical semantics, dataflow, and vehicle-level actuation rather than surface-level syntax.These properties make AV-VULN-010, AV-VULN-011, and AV-VULN-018, alongside the missing-finiteness example, central to RQ3.
  • Example Classes in Detail: AV-VULN-008 shows that syntactically valid control code can let NaN bypass both steering-limit comparisons and reach the actuator.Detection requires combining IEEE 754 semantics, legal NaN values in ROS 2 float64 fields, and the actuator-facing sink; similar reasoning applies to AV-VULN-010, AV-VULN-011, and AV-VULN-018.

Transferability · LLMSEC-AV PIPELINE

LLMSec-AV analyzes motion-relevant functions using taxonomy and disclosure context, then dynamically confirms flagged findings against compiled code. Its taxonomy is designed for middleware-neutral transfer, but this study evaluates only one software stack.

  • Transferability: The taxonomy uses middleware-neutral class definitions with separate instantiation fields for ROS 2 idioms.Retargeting is intended to require revising 18 instantiations rather than reconstructing the taxonomy.
  • Transferability: Transferability remains a design objective because the study evaluates only one software stack.
  • LLMSEC-AV PIPELINE: The pipeline analyzes the target stack at function level and focuses on functions that may influence vehicle motion.Each selected function is supplied to the language model for security analysis.
  • LLMSEC-AV PIPELINE: Each function is analyzed with the vulnerability taxonomy and the most relevant prior disclosures.
  • LLMSEC-AV PIPELINE: Flagged findings undergo dynamic confirmation against the compiled implementation.
  • LLMSEC-AV PIPELINE: Four general-purpose analyzers evaluate the same code units as LLMSec-AV.
  • LLMSEC-AV PIPELINE: Findings from all producers are assessed against a common ground truth.

Stage 1: Decomposition and Safety-Critical Tagging · Stage 2: Taxonomy and Retrieval Corpus · Stage 3: Structured Multi-Step Analysis

LLMSec-AV decomposes Autoware into function-level units, filters and samples safety-critical code, retrieves prior disclosures, and applies structured multi-step analysis. The pipeline explicitly carries safety-criticality, data-flow, and taxonomy-classification artifacts into final findings.

  • Stage 1: Decomposition and Safety-Critical Tagging: 4,673 function-level code units were produced from 770 translation units, with exact source extents and one parsing failure.Function-level granularity matches baseline analyzers’ line-level outputs, fits the model context window, and supports targeted fuzz-harness generation; enclosing-file context represents cross-function behavior.
  • Stage 1: Decomposition and Safety-Critical Tagging: The deterministic six-group keyword filter tagged 1,106 of 4,673 units (23.7%) for model confirmation or rejection.The signal groups cover actuation, perception fusion, planning decision, localization, concurrency and shared state, and untrusted entry, with supporting evidence recorded for agreement measurement.
  • Stage 1: Decomposition and Safety-Critical Tagging: The evaluation sampled 120 units round-robin across pipeline-domain and primary-signal cells, then added 41 units containing mined real-world issues, yielding 161 evaluated units.The augmentation preceded analysis, was independent of producer performance, applied identically to every producer, and retained the stratified and known-issue strata separately.
  • Stage 2: Taxonomy and Retrieval Corpus: The retrieval corpus contains 374 entries—372 vulnerability records and 2 advisories—embedded into 768-dimensional vectors for exhaustive cosine search.Each unit retrieves the top 6 entries above a similarity threshold of 0.35 using queries built from unit identity and body rather than taxonomy labels.
  • Stage 3: Structured Multi-Step Analysis: The full condition uses three model invocations that pass structured outputs verbatim through safety-criticality, data-flow tracing, and taxonomy classification.The steps identify actuation influence, externally influenced sources, propagation paths, guards, unguarded dangerous flows, and matching hazardous patterns.
  • Stage 3: Structured Multi-Step Analysis: The LLMSec-AV pipeline constructs knowledge, analyzes decomposed code units, runs four baseline analyzers on identical translation units, and dynamically confirms findings before scoring.Figure 2 depicts the shared pipeline terms for both analyzer families.
  • Stage 3: Structured Multi-Step Analysis: Structured multi-step analysis carries an explicit intermediate trace naming sources, guards, and unguarded flows into classification rather than relying on model-internal reasoning.Retrieved disclosures enter at classification, and the resulting structured finding is submitted for dynamic confirmation; the design does not require a reasoning-tuned model.

Ablation Design · Stage 4: Dynamic Confirmation · Ground Truth

The study isolates prompting components across four controlled conditions, dynamically confirms flagged findings with fuzzing and sanitizers, and constructs ground truth from confirmed crashes and security-relevant upstream fixes. Dynamic outcomes use fixed attribution and time-budget rules applied equally to model and baseline findings.

  • Ablation Design: Four conditions isolate component contributions: zero_shot uses unaided prompting, taxonomy_only adds taxonomy context, taxonomy_rag adds retrieved disclosures, and full adds three-step decomposition.The task instruction and output contract are byte-identical; only injected context differs, except that full uses three invocations.
  • Stage 4: Dynamic Confirmation: Each flagged finding receives a generated harness that reads standard-input fuzzer data while preserving NaN, infinity, zero, negative, and extreme-magnitude values.Harnesses compile with the target translation unit's native build flags under AFL++, AddressSanitizer, and UndefinedBehaviorSanitizer.
  • Stage 4: Dynamic Confirmation: Build failures are classified with a fixed taxonomy and retried for up to 2 compiler-in-the-loop rounds, returning compiler diagnostics to the model identically across conditions.
  • Stage 4: Dynamic Confirmation: Crashes are replayed under sanitizers and attributed only when a stack contains a frame in the flagged file within 10 lines of the reported unit.Outcomes are confirmed, crash unattributed, no crash in budget, harness build failed, or harness generation failed.
  • Stage 4: Dynamic Confirmation: Dynamic confirmation allows 900 seconds per finding and applies the same terms to baseline findings, preventing unequal confirmation conditions.
  • Ground Truth: Ground truth combines locations confirmed through Stage 4 fuzzing with security-relevant fixes committed after the pinned Autoware revision.Because public vulnerability records rarely identify files and lines, qualifying fixes are treated as evidence that corresponding pre-fix code was weak, with diffs localizing affected lines.
  • Ground Truth: The upstream-fix ground-truth source examined 7,561 newer commits across repositories containing evaluated code.Each qualifying security-relevant fix was used to identify affected pre-fix lines through its diff.

Stage 5: Scoring … FINDINGS

LLMSec-AV’s primary model conditions localized upstream-fixed weaknesses above flag-volume null expectations, unlike four static analyzers, while taxonomy context mainly improved labeling. Dynamic confirmation yielded no confirmed findings because generated harnesses generally failed to integrate with ROS 2 types and initialization.

  • Stage 5: Scoring: A true positive required falling within 10 lines of a ground-truth location in the same file, with adjacent locations merged to avoid inflating recall.This scoring rule treats nearby reports as one weakness.
  • Stage 5: Scoring: Every unconfirmed finding was counted as a false positive, making reported precision a lower bound based on each producer’s flag volume.A released-artifact variant excluding inconclusive findings agreed closely because Stage 4 decided almost nothing.
  • EVALUATION METHODOLOGY AND CONFIGURATION: The evaluation used pinned Autoware revision e53832e8 on ROS 2 Humble, analyzing 161 code units sampled or added for mined issues from 4,673 functions across 770 translation units.All tools used native compilation settings; model inference used temperature 0.1, top-p 0.9, and a fixed seed, with retrieval indexing 374 disclosures.
  • Baseline Configuration: RQ2 compared domain-configured CodeQL, Semgrep, cppcheck, and Clang Static Analyzer runs, separating custom from stock findings where applicable.CodeQL used four AV-specific queries, Semgrep used eight AV rules, and the other analyzers ran broad built-in checks without comparable custom dataflow rules.
  • Baseline Configuration: Experiments ran on an Intel Core i9-14900F system with 32 threads, 62 GiB memory, and an NVIDIA RTX 4090 with 23 GiB.Complete software versions and configuration files were included in the released artifacts.
  • FINDINGS: All primary model conditions localized weaknesses later fixed upstream above their flag-volume null expectations, whereas none of four static analyzers did, including those with AV-specific rules.The comparison included CodeQL, Semgrep, cppcheck, and the Clang Static Analyzer.
  • FINDINGS: Unaided prompting also exceeded the null, indicating the advantage belonged to model-based analysis; taxonomy context modestly improved recall and substantially improved weakness-class labeling.The taxonomy therefore contributed more to interpretability than to detection recall.
  • FINDINGS: Dynamic confirmation produced no confirmed findings because most generated fuzzing harnesses failed to integrate with the ROS 2 type and initialization surface.This limited confirmation occurred after generated harnesses were tested for integration.

Analysis Inventory · Aggregate Comparison and the Volume-Matched Null (RQ1, RQ2)

Across 1,318 runs on 161 code units, LLM conditions recovered 0.217–0.761 of 46 mined weakness locations, while conventional analyzers matched at most one. The comparison used a volume-matched permutation null, but reported precision remains only a lower bound.

  • Analysis Inventory: The study executed 1,318 runs across two models, four conditions, and a medium-reasoning-effort gpt-oss replication on a 15-unit subset.The runs covered 161 code units, and Table 2 tracked finding volume, taxonomy mapping, prompt truncation, and answer exhaustion.
  • Analysis Inventory: Prompt truncation and answer exhaustion were treated as validity failures rather than negative findings because the intended treatment was not completed.These failure categories were included in the analysis inventory alongside finding volume and taxonomy mapping.
  • Aggregate Comparison and the Volume-Matched Null (RQ1, RQ2): The ground truth consisted solely of 46 deduplicated locations mined from upstream fixes after Stage 4 confirmed no findings.The resulting comparison was independent of which producers supplied candidates for confirmation.
  • Aggregate Comparison and the Volume-Matched Null (RQ1, RQ2): 0.217–0.761 recall was achieved by model conditions against 46 mined locations; cppcheck matched one, while CodeQL, Semgrep, and Clang Static Analyzer matched none.The zero matches included CodeQL and Semgrep with AV-specific rule sets.
  • Aggregate Comparison and the Volume-Matched Null (RQ1, RQ2): cppcheck matched one location despite reporting 1,301 findings, illustrating the contrast between high alert volume and low ground-truth recall.The other conventional analyzers matched none, including under AV-specific CodeQL and Semgrep rules.
  • Aggregate Comparison and the Volume-Matched Null (RQ1, RQ2): The rule-based analyzers’ weakness matches were not explained by flag volume, whereas model conditions localized mined weaknesses at rates beyond volume alone.The comparison used a flag-volume-matched permutation null to separate localization from the number of reported findings.
  • Aggregate Comparison and the Volume-Matched Null (RQ1, RQ2): Reported precision is only a lower bound because known weak locations do not establish that findings elsewhere are false.Practical precision therefore requires blind adjudication of findings at previously unknown locations, and the lower bound tends to fall as flag volume rises.

Component Attribution (RQ4) … DISCUSSION

Across these analyses, model-based methods localized upstream-corrected weaknesses beyond static analyzers, but confirmation failures prevent precision claims or unattended deployment. Taxonomy context improved labeling and possibly recall, retrieval did not help, and multi-step analysis reduced finding volume without clearly establishing component rankings.

  • Component Attribution (RQ4): Taxonomy context increased recall from 0.7391 to 0.8478 and explicit class labeling from near zero to above four-fifths, while also increasing finding volume.The recall margin was too small to interpret from a single run, making the taxonomy’s clearest contribution organizational: prioritization, routing, and auditing by vehicle-level consequence.
  • Component Attribution (RQ4): Retrieval reduced both recall and finding volume and showed no benefit, while multi-step analysis reduced volume while retaining recall near the taxonomy-only condition.Retrieval should be reconsidered unless a corpus closer to ROS 2 application code is available.
  • Component Attribution (RQ4): The ablation did not support a reliable component ranking: F1 ranged from 0.2365 to 0.2783 across one run per condition without variance estimates.The conditions differed behaviorally despite the small, non-variance-supported F1 spread.
  • Confirmation Outcomes by Class (RQ3): Of 187 submitted findings, 0 were confirmed because 173 harnesses failed to compile, leaving 14 usable attempts and no sanitizer fault among 13 completed runs.This negative result concerns function-level confirmation methodology, not evidence that the reported weaknesses were absent.
  • Producer Disagreement (RQ3): Rule-based analyzers mapped 956 findings to 14 classes, with 96.8% in rule-expressible classes, whereas model-based analysis generated candidates in non-expressible classes.The 18-class taxonomy contains 12 matchable classes; six depend on missing checks, semantic conventions, or deployment properties.
  • Producer Disagreement (RQ3): Candidates in non-expressible classes were not dynamically confirmed, so their correctness remains unresolved and requires independent adjudication.Rule-based analyzers cannot directly represent these classes, whereas model-based analysis can generate findings within them.
  • DISCUSSION: Model-based analysis localized upstream-corrected weaknesses, including locations missed by all four static analyzers, but its precision and unattended-deployment suitability remain unknown.Dynamic confirmation failed for reasons unrelated to finding validity, so the results support complementing rather than replacing static analysis.
  • DISCUSSION: Reliable dynamic confirmation requires message-level fuzzing against a live ROS 2 node graph, with harness synthesis providing message definitions and constructors.Combined with blind manual triage, this could estimate precision and review cost.

CONCLUSIONS · FUNDING

LLMSec-AV introduced an 18-class machine-readable AV vulnerability taxonomy and recovered up to 0.761 of 46 upstream-fix locations across Autoware evaluations. The conclusions are limited by incomplete ground truth, narrow experimental scope, and unestablished precision, while future work targets live ROS 2 message-level fuzzing and broader replication; funding came from TraCR and NSF.

  • CONCLUSIONS: Up to 0.761 of 46 upstream-fix locations were recovered by LLMSec-AV across 161 Autoware code units evaluated against four conventional analyzers.The taxonomy contained 18 operationally defined classes, and CodeQL and Semgrep included hand-written AV-specific rules.
  • CONCLUSIONS: The study’s conclusions are bounded by incomplete ground truth, heuristic mined locations, and unestablished precision beyond the 46 known locations.Of 61 mined locations, 44 remained medium-confidence, and a 10-line tolerance could credit nearby but distinct findings.
  • CONCLUSIONS: Traditional-tool baseline coverage was limited to 77 of 2,300 findings across 36 of 161 units, restricting the strength of cross-tool conclusions.This baseline limitation is one of several factors bounding the study’s interpretation.
  • CONCLUSIONS: The results support analytic rather than statistical generalization because the study used one AV stack, two quantized local models, one run per condition, and no variance estimate.Small differences among zero_shot, taxonomy_only, taxonomy_rag, and full should therefore not be overinterpreted.
  • CONCLUSIONS: Future work should replace function-level harnessing with message-level fuzzing of live ROS 2 node graphs and use message definitions and constructor signatures for harness synthesis.Blind manual triage and this confirmation substrate are needed to establish precision.
  • CONCLUSIONS: Replication should extend to another AV stack and middleware, such as Apollo, evaluate multiple seeds and stronger models, and focus on classes that cannot be directly represented as rules.
  • FUNDING: The research was supported by the National Center for Transportation Cybersecurity and Resiliency and the National Science Foundation.Awards included TraCR 69A3552344812 and 69A3552348317, and NSF Award 2340456.
Loading 2609.09386v1…