Pith. sign in

REVIEW 4 major objections 5 minor 19 references

LLM-Assisted Dynamic Threat Analysis for Attacker-Reachable Software Weaknesses in Autonomous Vehicles

T0 review · 4 major / 5 minor · reviewed 2026-08-14 · deepseek-v4-flash

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

Pith's one-line read The paper claims that LLM-assisted dynamic weakness confirmation in a full autonomous-vehicle software stack fails primarily at build integration—wiring harnesses into the native build—rather than at candidate generation or fuzzing.

desk verdict A careful, honest empirical account of where LLM-generated fuzz harnesses fail on a full AV stack—the bottleneck is build integration, not input generation—but the scope claims reach beyond the single stack and two models studied. read the letter →

arxiv 2608.13450 v1 pith:2JRJ34MM submitted 2026-08-13 cs.SE cs.CRcs.LG

Md Wasiul Haque , Sagar Dasgupta , Mizanur Rahman , Md Rayhanur Rahman This is my paper · ORCID
classification cs.SEcs.CRcs.LG
keywords LLM-assistedfuzzingbuildintegrationAutowareautonomousvehiclesoftwarestaticanalysisdynamicweaknessconfirmationcompiler-in-the-looprepairROS2
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

The paper investigates whether large language models can turn static-analysis findings in a full autonomous-driving codebase into executable harnesses that dynamically confirm whether a weakness is real. It finds that the answer is currently no, and the reason is not weak candidate generation or immature fuzzing: across 740 reachable sites in Autoware, 80 percent of the 2,259 first-shot compile failures were dependency-wiring errors (missing headers and invalid source paths), and after compiler-guided repair only 652 of 2,960 harnesses linked and reached the fuzzer, with all 37 observed crashes arising in generated stub code rather than in Autoware. The paper's contribution is a build-integration failure taxonomy that separates object compileability from linking and target reachability, locating the binding constraint one stage before the fuzzer. A sympathetic reading is that LLM-assisted dynamic analysis is not yet a trustworthy assurance stage, but the failure taxonomy points exactly to where tooling should improve.

What carries the argument

The mechanism that carries the argument is the five-phase pipeline itself, which stages LLM-generated harnesses through compilation against the real Autoware build, compiler-in-the-loop repair (up to three rounds of feeding Clang diagnostics back to the model), linking, fuzzing, and triage, while recording why each artifact drops out. Its output is the build-integration failure taxonomy that classifies first-shot failures into missing includes, invalid source paths, API mismatches, signature mismatches, syntax errors, and other, and the observed 'stub convergence' behavior in which repair satisfies the compiler by removing real dependencies and reimplementing interfaces locally. This taxonomy is what shifts the bottleneck from compilation to linking and target reachability, and it is the paper's main analytical result.

What would settle it

Apply the same pipeline to a second full autonomous-driving stack (for example, Apollo) or with a link-aware repair process that optimizes for preserving target linkage rather than mere object compilation, and observe whether the fraction of generated harnesses that link and exercise real target code rises from 22 percent to a clear majority and whether any static candidate is dynamically confirmed; if either happens, the claim that build integration is the primary barrier would be contradicted.

Watch

Extended reading notes

Core claim

The central claim is that faithful integration with the native build, not candidate selection or fuzz-input generation, is the primary barrier to LLM-assisted dynamic confirmation of software weaknesses in a production-scale autonomous-vehicle stack. The evidence is an end-to-end run on Autoware: 1,436 missing-include and 381 invalid-source-path errors make up 1,817 of the 2,259 first-shot compile failures, repair raises object compileability to 100 percent for the reasoning model only at the cost of stub convergence, and 2,308 of 2,960 harnesses never reach the fuzzer. All 37 crashes observed during fuzzing originate in model-generated stub code, not in Autoware, and no candidate is dynamically confirmed within budget. The authors therefore state that under a full-link, real-target-execution criterion the effective success rate approaches zero across all conditions.

Load-bearing premise

The generalizing step assumes that Autoware's ROS 2 build graph and the two open-weight models tested (codestral:22b and gpt-oss:20b) are representative of full autonomous-vehicle stacks and current LLM practice, so that the build-integration bottleneck is a property of the class of systems, not of this particular stack and model pair.

Editorial extensions

If this is right

  • Static-analysis-derived inventories of safety-relevant sites in stacks like Autoware are plentiful, but without verified executable harnesses they remain candidates; the paper shows the missing infrastructure is harness construction, not candidate discovery.
  • Object compileability should not be used as a success metric for LLM-generated harnesses in dependency-rich codebases, because repair routinely achieves it by stubbing the intended implementation.
  • Providing static-analysis context materially improves first-shot artifact quality (first-shot compileability rose from 24.2 percent to 63.9 percent for the reasoning model), so the static stage pays off even when dynamic confirmation fails.
  • LLM-generated harnesses may still be useful as drafts that human engineers complete and validate, but not as an unattended assurance stage in continuous integration.
  • Model choice matters: the general reasoning model compiled 473 of 740 harnesses first-shot with static context versus 46 for the code-specialized model, indicating that wiring ability, not code specialization, drives early-stage success.

Reading between the lines

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

  • A testable extension would be to give the LLM the package-level build graph rather than per-function source windows, generating harnesses against named build targets; if missing-include and invalid-path failures drop substantially, the paper's diagnosis is confirmed as the actionable bottleneck.
  • The stub-convergence failure mode suggests a new evaluation metric for LLM harness generation: target-preserving linkage, the fraction of generated artifacts that bind to the intended functions at link time and exercise them at run time, which is more meaningful than compileability.
  • Porting the pipeline to a smaller, dependency-light library would likely show much higher linking and confirmation rates, which would support the interpretation that the barrier scales with the size and middleware complexity of the integration graph rather than with the LLM's coding ability.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 5 minor

Summary. The paper presents an end-to-end feasibility study of LLM-assisted dynamic analysis on Autoware, an open-source autonomous-driving stack. The authors first perform a compiler-driven static analysis over 185 packages, recovering 1,375 decision rules, 2,274 validation checks, and 482 input-to-safety-output flows, and derive a weakness taxonomy. From this they select 740 high-priority sites and, for each, generate four artifacts with two local open-weight LLMs (codestral:22b and gpt-oss:20b), a no-static-context ablation, and a naive baseline, yielding 3,700 artifact sets. The artifacts are compiled against the real Autoware build under ASan/UBSan, repaired in a compiler-in-the-loop loop for up to three rounds, and fuzzed when they link. The central observation is an attrition curve: 2,259 of 2,960 LLM-generated harnesses fail first-shot compilation, with 1,817 of those failures classified as dependency-wiring errors; after repair, only 652 harnesses link and reach the fuzzer; no candidate weakness is dynamically confirmed, and all 37 reported crashes originate in stubbed code. The paper concludes that build integration, not candidate generation or fuzzing, is the primary barrier to LLM-assisted dynamic confirmation for full AV software stacks.

Significance. If the results hold, this is a useful and honest negative result: it is among the first end-to-end studies of LLM-assisted dynamic confirmation on a complete AV stack, and it provides a concrete build-integration failure taxonomy that distinguishes object compilation, linking, target reachability, and genuine dynamic confirmation. The paper's strengths include a reproducible pipeline with released prompts, artifacts, static-analysis outputs, and logs; a controlled comparison across model, static context, and a baseline; and explicit separation of 'not exercised' from 'disconfirmed,' which prevents build failures from being misread as evidence against the static candidates. The stub-convergence observation, showing that compiler-in-the-loop repair can increase compileability while moving harnesses away from real target code, is an important practical insight for the fuzz-driver-generation community. The main weakness is scope: the strong headline claim is derived from a single AV stack and two open-weight models, and the paper's own limitations section cautions against direct generalization.

major comments (4)
  1. [Abstract and Section 9 (Conclusions)] The abstract and conclusions state that build integration is the primary barrier to reliable LLM-assisted dynamic analysis of 'full autonomous-vehicle software stacks,' but the evidence comes from exactly one stack (Autoware, ROS 2/colcon) and two open-weight models served through Ollama. Section 9 itself says 'the reported rates should not be generalized directly' and that a link-aware repair process 'should perform better.' This is a load-bearing overgeneralization of the central claim. Please either restrict the headline claim to Autoware-class ROS 2 stacks under open-weight models, or add evidence on a second stack or a link-aware repair condition that would test the generality of the build-integration bottleneck.
  2. [Table 8, case study 3 vs Table 7] Table 8 reports that static context raised the gpt-oss model's first-shot compileability from 13.3% to 56.7%, which contradicts Table 7, where gpt-oss without context compiled 179/740 (24.2%) and gpt-oss with context compiled 473/740 (63.9%). These numbers cannot both be correct; please reconcile the case-study summary with the main results table. As printed, the inconsistency undermines confidence in the reported effect of static context.
  3. [Section 7, Fuzzing attribution] The claim that build integration, rather than fuzzing, is the primary barrier is inferred from attrition (only 652 of 2,960 harnesses linked and reached the fuzzer) rather than from a comparison that varies fuzzing conditions. The paper also reports that the realized fuzzing time was 60 seconds per target, not the configured 600 seconds. Please state explicitly that the fuzzing conclusion is an inference from attrition and not a controlled demonstration that fuzzing would have been ineffective had more harnesses linked; otherwise the 'not fuzzing' part of the central claim is stronger than the experimental design supports.
  4. [Abstract and Section 8/Conclusions, crash count] The abstract and conclusions say that all 37 crashes originated in stubbed code rather than Autoware, but the case-study section describes only one crash (Table 8, case 4). Since the claim that no crash reached real Autoware code is important for the interpretation of the negative result, please provide a full inventory or a summary table of all 37 crashes with their originating stack frames and classification.
minor comments (5)
  1. [Abstract and Section 6 (Target Selection)] The abstract calls the 740 sites a 'sample,' while Section 6 and Table 5 describe them as a deterministic 'census' of all P1 and P2 sites. Please align the terminology.
  2. [Section 5 (Analysis Method and Scale)] The term 'compiler-precise' is used repeatedly; consider defining it explicitly as 'analysis driven by the actual compile_commands.json flags, include paths, and preprocessor definitions,' and noting that this does not imply soundness or completeness.
  3. [Table 8, case study 2] Case study 2 refers to 'all 30 targets' for the code-specialized model without defining which 30 targets these are and how they were selected; please specify this subset or its sampling basis.
  4. [Table 6 (Experimental Configuration)] The realized fuzzing time of 60 seconds per target appears only in the limitations section; it would be clearer to include both the configured budget and the realized budget in Table 6.
  5. [Figure 6] The bar chart does not clearly distinguish the five conditions in grayscale; please add a legend or use distinguishable patterns so the paper is readable in print.

Circularity Check

0 steps flagged · score 0.0 of 10

No circular derivation: the central claims are measured attrition statistics, not quantities defined by the study's inputs.

full rationale

Walking the derivation chain, the paper's central claims are observational measurements rather than quantities derived from the inputs by construction. The headline result—that build integration, not candidate generation or fuzzing, is the primary barrier—rests on direct attrition counts: 1,817 of 2,259 first-shot compile failures were dependency-wiring errors (Table 7), only 652 of 2,960 LLM harnesses linked and reached the fuzzer, and all 37 observed crashes originated in generated stubs rather than in Autoware (Conclusions). None of these numbers is a fitted parameter, a predicted value, or a quantity defined in terms of the conclusion. The static-analysis inventory (1,375 decision rules, 2,274 validation checks, 482 input-to-safety-output flows) is an output of the paper's own analysis pipeline; the weakness taxonomy labels those recovered items but does not use the dynamic results to define them, and no downstream prediction reduces to those counts. The 740-target sample is selected by a fixed safety-relevance scoring rule and does not feed back into the build-integration claim. The only self-citation (Haque et al. 2025) appears as contextual background for the difficulty of assuring large software and for static analysis generally; the present paper performs its own repository-scale static analysis, so no load-bearing uniqueness theorem or prior fitted result is imported. Section 9's caveat, 'Because the study evaluates only Autoware and two open-weight models, the reported rates should not be generalized directly,' is an acknowledged external-validity limitation, not an admission of circularity; the abstract's broader generalization may be a scope over-reach, but over-generalization is a correctness and representativeness concern, not a circular-derivation concern. Likewise, the statement that 'a link-aware repair process should perform better' is explicitly a hypothesis about future work, not a conclusion derived from the data. No equation, parameter, or fitted input is renamed as a prediction, and the compiler-in-the-loop repair outcomes are empirically observed from the real build and fuzzing runs. The derivation chain is therefore self-contained against external benchmarks, and no circular step is present.

Assumptions & free parameters 4 free parameters · 4 assumptions · 0 invented entities

All counts in the central claim are direct observations from the pipeline, so the main burden is on generalization. Free parameters (target-selection weights, P1/P2 thresholds, fuzzing budget, repair-round limit) define the experimental envelope and bound what the negative result can claim. The axioms record the representativeness assumptions for Autoware, for the two LLMs, and for 'compileability' as a success criterion; the paper itself flags each of these in Section 9. No invented entities are introduced.

free parameters (4)
  • Target selection scoring weights = hand-chosen: actuation +3, validation/bounds +2, external ROS exposure +2, flow +3, safety domain +1
    Used in Section 5 to rank 2,749 condition sites and select the 740 P1/P2 targets; hand-chosen, not fitted, and do not affect the build-integration finding directly but shape the candidate census.
  • P1/P2 score thresholds = P1 >= 8; P2 5-7; P3 rest
    Deterministic site selection in Section 5; arbitrary cutoffs that define the target population.
  • Fuzzing budget per target = 600 s configured; 60 s realized
    Section 7 and Section 9 note the realized time was 60 seconds of the configured 600; the 'no weakness confirmed' result is conditional on this budget.
  • Maximum repair rounds = 3
    Compiler-in-the-loop repair limit in Section 6; a link-aware repair with more rounds might reduce stub convergence, so this parameter bounds the negative result.
assumptions (4)
  • domain assumption The static-analysis classification of decision rules and validation checks, while heuristic, is accurate enough to define a meaningful target census.
    Section 5 states the classification is heuristic and not a sound over/under-approximation; the dynamic findings inherit this uncertainty, though the build-integration attrition does not depend on it.
  • domain assumption Autoware is representative of full autonomous-vehicle software stacks for build-integration difficulty.
    Section 3 selects Autoware for ROS2 architecture and build reproducibility; Section 9 cautions against direct generalization.
  • domain assumption The two selected open-weight LLMs (codestral:22b, gpt-oss:20b) are representative of current LLM artifact-generation capability for this task.
    Section 7 motivates model choice; the paper notes the reasoning model was stronger, and Section 9 says rates should not be generalized.
  • ad hoc to paper Object compilation against the real Autoware headers is a meaningful intermediate success criterion.
    Section 6 defines compileability as object compilation, and Section 9 calls the reported rates 'optimistic upper bounds'; linking is a stricter criterion.

how reviews work

0 comments
Cite this review

Pith. "Pith review of LLM-Assisted Dynamic Threat Analysis for Attacker-Reachable Software Weaknesses in Autonomous Vehicles." pith.science (2026). https://pith.science/paper/2JRJ34MM

@misc{pith2026260813450,
  author       = {Pith},
  title        = {Pith review of: LLM-Assisted Dynamic Threat Analysis for Attacker-Reachable Software Weaknesses in Autonomous Vehicles},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/2JRJ34MM}},
  note         = {Machine review of arXiv:2608.13450}
}
read the original abstract

Autonomous vehicles depend on large safety-critical software stacks, where weaknesses reachable from adversarial inputs may affect steering, braking, or other control decisions. Static analysis can identify candidate sites, but dynamically confirming exploitability requires executable test artifacts that are difficult to construct manually. We investigate whether large language models (LLMs) can automate this process for Autoware, an open-source autonomous-driving stack. We perform compiler-precise static analysis across 185 packages, identifying 1,375 decision rules, 2,274 validation checks, and 482 input-to-safety-output flows, from which we derive a weakness taxonomy and sample 740 reachable sites. Two local open-weight LLMs, a no-static-context ablation, and a naive-template baseline generate 3,700 artifact sets, which are compiled against the real build under sanitizers, repaired through compiler-in-the-loop feedback, and fuzzed when executable. The main result is a build-integration failure taxonomy showing that 80% of first-shot compilation failures arise from dependency wiring rather than program logic. The reasoning model compiled 64% of harnesses on the first attempt, compared with 6% for the code-specialized model. Repair achieved full object-compileability for the reasoning model only through extensive stubbing; fewer than half of its harnesses reached the fuzzer, and all 37 observed crashes originated in stubbed code rather than Autoware. No candidate weakness was dynamically confirmed within budget. These results show that build integration, not candidate generation or fuzzing, is the primary barrier to reliable LLM-assisted dynamic analysis of full autonomous-vehicle software stacks.

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

19 extracted references · 14 canonical work pages

  1. [1]

    Haque, M. W., M. Erfan, S. Dasgupta, M. R. Rahman, and M. Rahman, Security Vulnerabilities in Software Supply Chain for Autonomous Vehicles.arXiv preprint arXiv:2509.16899,

    work page arXiv

  2. [9]

    https://autowarefoundation.github.io/autoware-documentation/mai n/home/, 2026, accessed

    Autoware Foundation,Autoware Documentation. https://autowarefoundation.github.io/autoware-documentation/mai n/home/, 2026, accessed

    work page 2026

  3. [10]

    InProceedings of the Fourth Annual ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages (POPL), 1977, pp

    Cousot,P.andR.Cousot,Abstractinterpretation: Aunifiedlatticemodelforstaticanalysisofprogramsbyconstruction or approximation of fixpoints. InProceedings of the Fourth Annual ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages (POPL), 1977, pp. 238–252. Lattner, C. and V. Adve, LLVM: A Compilation Framework for Lifelong Program Analysis & Tr...

    work page 1977

  4. [11]

    https://codeql.github.com/, 2026, accessed

    GitHub,CodeQL. https://codeql.github.com/, 2026, accessed

    work page 2026

  5. [13]

    Bindu, A

    Fang, R., R. Bindu, A. Gupta, and D. Kang, LLM Agents can Autonomously Exploit One-day Vulnerabilities.arXiv preprint arXiv:2404.08144,

    arXiv

  6. [15]

    Shammah, and A

    Shalev-Shwartz, S., S. Shammah, and A. Shashua,On a Formal Model of Safe and Scalable Self-driving Cars. arXiv:1708.06374,

    arXiv

  7. [16]

    Tokunaga, Y

    Kato, S., S. Tokunaga, Y. Maruyama, S. Maeda, M. Hirabayashi, Y. Kitsukawa, A. Monrroy, T. Ando, Y. Fujii, and T.Azumi,Autowareonboard: Enablingautonomousvehicleswithembeddedsystems.InProceedingsofthe 9th ACM/IEEE International Conference on Cyber-Physical Systems (ICCPS), 2018, pp. 287–296. Baidu,Apollo: An Open Autonomous Driving Platform. https://githu...

    work page 2018

  8. [17]

    Paek, and S.-H

    Jung, H.-Y., D.-H. Paek, and S.-H. Kong, Open-Source Autonomous Driving Software Platforms: Comparison of Autoware and Apollo.arXiv preprint arXiv:2501.18942,

    arXiv

Show all 19 references
  1. [18]

    Gog, I., S.Kalra, P.Schafhalter, M.A.Wright, J.E.Gonzalez, andI.Stoica,Pylot: AModularPlatformforExploring Latency–Accuracy Tradeoffs in Autonomous Vehicles

    comma.ai,openpilot: AnOperatingSystemforRobotics.https://github.com/commaai/openpilot,2024,accessed2026. Gog, I., S.Kalra, P.Schafhalter, M.A.Wright, J.E.Gonzalez, andI.Stoica,Pylot: AModularPlatformforExploring Latency–Accuracy Tradeoffs in Autonomous Vehicles. InProceedings ...

    2024

  2. [2016]

    ISO, Geneva, Switzerland,

    International Organization for Standardization,ISO 26262:2018 Road Vehicles — Functional Safety. ISO, Geneva, Switzerland,

    2018

  3. [2017]

    Austin, V

    Ispoglou, K., D. Austin, V. Mohan, and M. Payer, FuzzGen: Automatic Fuzzer Generation. InProceedings of the 29th USENIX Security Symposium, 2020, pp. 2271–2287. 16 Haque, Dasgupta, Rahman, and Rahman Meng, R., M. Mirchev, M. Böhme, and A. Roychoudhury, Large Language Model Gui...

    2020

  4. [2018]

    ISO/SAE, Geneva, Switzerland,

    International Organization for Standardization and SAE International,ISO/SAE 21434:2021 Road Vehicles — Cyber- security Engineering. ISO/SAE, Geneva, Switzerland,

    2021

  5. [2019]

    Gil-Uriarte, I

    Mayoral-Vilches, V., E. Gil-Uriarte, I. Z. Ugarte, G. O. Mendia, R. I. Pisón, L. A. Kirschgens, A. B. Calvo, A. H. Cordero, L. Apa, and C. Cerrudo, Towards an Open Standard for Assessing the Severity of Robot Security Vulnerabilities, the Robot Vulnerability Scoring System (RV...

    arXiv

  6. [2020]

    Bruening, A

    Serebryany, K., D. Bruening, A. Potapenko, and D. Vyukov, AddressSanitizer: A Fast Address Sanity Checker. In Proceedings of the USENIX Annual Technical Conference (ATC), 2012, pp. 309–318. LLVM Project,libFuzzer – a library for coverage-guided fuzz testing. https://llvm.org/d...

    2012

  7. [2021]

    Aggarwal, A. and P. Jalote, Integrating static and dynamic analysis for detecting vulnerabilities. In30th Annual International Computer Software and Applications Conference (COMPSAC’06), IEEE, 2006, Vol. 1, pp. 343–350. Fioraldi, A., D. Maier, H. Eißfeldt, and M. Heuse, AFL++:...

    2006

  8. [2023]

    Lambert, A

    Yurtsever, E., J. Lambert, A. Carballo, and K. Takeda, A Survey of Autonomous Driving: Common Practices and Emerging Technologies.IEEE Access, Vol. 8, 2020, pp. 58443–58469. Webb, N., D. Smith, C. Ludwick, T. Victor, Q. Hommes, F. Favarò, G. Ivanov, and T. Daniel,Waymo’s Safet...

    2020 arXiv

  9. [2024]

    https://github.com/google/oss-fuzz-gen, 2024, accessed

    Google,OSS-Fuzz-Gen: LLM-aided Fuzz Target Generation. https://github.com/google/oss-fuzz-gen, 2024, accessed

    2024

  10. [2025]

    Koopman, P. and M. Wagner, Challenges in Autonomous Vehicle Testing and Validation.SAE International Journal of Transportation Safety, Vol. 4, No. 1, 2016, pp. 15–24. Kalra,N.andS.M.Paddock,DrivingtoSafety: HowManyMilesofDrivingWouldItTaketoDemonstrateAutonomous Vehicle Reliab...

    2016

  11. [2026]

    Manès,V.J.M.,H.Han,C.Han,S.K.Cha,M.Egele,E.J.Schwartz,andM.Woo,TheArt,Science,andEngineering of Fuzzing: A Survey.IEEE Transactions on Software Engineering, Vol. 47, No. 11, 2021, pp. 2312–2331. Macenski, S., T. Foote, B. Gerkey, C. Lalancette, and W. Woodall, Robot Operating ...

    2021

Pith tools

Reviewed August 14, 2026 · model on record in the stance chip above.