Cross-Corpus Evaluation of Generalizable Vulnerability Detection in IoT Firmware

arXiv:2608.11492v1 [cs.CR] 11 Aug 2026

Cross-Corpus Evaluation of Generalizable Vulnerability Detection in IoT Firmware Sadib Hassan Rumman

Md. Shariful Islam*

Md. Rayhanur Rahman

Institute of Information Technology University of Dhaka Dhaka, Bangladesh msse2011@iit.du.ac.bd

Institute of Information Technology University of Dhaka Dhaka, Bangladesh * Corresponding Author: shariful@iit.du.ac.bd

Department of Computer Science The University of Alabama Tuscaloosa, AL, USA mrahman87@ua.edu

Abstract—IoT firmware vulnerability detection remains challenging due to the heterogeneity of firmware ecosystems, resource-constrained platforms, and limitations in existing benchmark quality. Many available datasets are synthetic or generalpurpose and do not provide human-verified, contaminationscreened annotations. As a result, evidence regarding crosscorpus generalization across training data sources, model architectures, and curriculum strategies remains limited. To address this gap, this paper introduces IoTVulBench, a human-verified benchmark for cross-corpus firmware vulnerability detection. IoTVulBench-Core was constructed from GitHub repositories, validated by three expert reviewers, and evaluated using a contamination-screened held-out target across five model architectures, two tuning methods, and three curriculum strategies, together with ensemble, distillation, and robustness analyses. Models trained on IoTVulBench achieved the highest Matthews Correlation Coefficient (MCC) among the single-source datasets where others were matched by random undersampling, reaching 0.58 compared with 0.44 for PrimeVul and 0.39 for D2A. Staged curriculum learning further increased MCC to 0.69, while a diversity-optimized ensemble achieved 0.73, representing a 0.42 MCC improvement over the strongest reference comparator, a static analyzer with an MCC of 0.31, and a 0.29 MCC improvement over the strongest single-source training dataset, PrimeVul. At a 0.5% false-positive rate, the model missed only 21% of vulnerabilities, compared with 71% for the strongest reference comparator. It also retained 86% of its performance under identifier renaming while demonstrating strong calibration and largely faithful explanations. These findings indicate that domain-matched training data and curriculum design, rather than model scale alone, are key drivers of generalization in firmware vulnerability detection. The results provide both a benchmark for future research and deployment-ready configurations for practical IoT security applications. Index Terms—IoT firmware security, large language models, robustness evaluation, software vulnerability detection, vulnerability dataset

I. I NTRODUCTION

I

NTERNET of Things (IoT) devices are embedded across healthcare, industrial automation, and smart-city infrastructure, extending network connectivity to safety- and missioncritical operations. Firmware, the software layer controlling these devices, constitutes a critical attack surface, since a vulnerability at this layer can propagate to network, application, and physical-control layers [1]. Large language models (LLMs) are increasingly proposed for IoT security

tasks, including edge intelligence [2], threat prediction [3], and protocol authentication [4], making reliable firmwarelevel vulnerability detection a prerequisite for trustworthy IoT deployment [5]. Detecting vulnerabilities in embedded IoT firmware remains complex because firmware combines multiple programming languages, hardware-specific libraries, and cross-architecture binaries that differ from general-purpose software [6]. Detection models trained on general-purpose or synthetic source code do not necessarily transfer to this domain, and the individual contribution of training-data provenance, architecture, tuning method, and curriculum design to cross-corpus generalization remains insufficiently disentangled for firmwarespecific detection. Dataset construction for embedded systems continues to exhibit validity limitations. EVDD [7] labels Linux kernel vulnerabilities through commit-differential extraction but evaluates only ten CVEs despite claiming million-line, threedecade coverage. An IoT firmware opcode detector [6] compiles over 500,000 labeled functions from ten projects without reporting the disassembler, target architecture, or labeling provenance. B4IoT [8] generates Docker-based firmware images but covers only Alpine Linux and validates three composite images. A survey of ML-, DL-, and LLM-based vulnerability datasets [9] summarizes construction trade-offs without a systematic search protocol. Firmware analysis studies report comparable limitations. A knowledge-graph framework [10] evaluates a mock REST API and generic non-security text. An Android Automotive OS study [11] generalizes across vendors from one firmware image per vendor with partly unvalidated softwarebill-of-materials completeness. An LLM-based remediation pipeline [12] reports a 92.4% remediation rate without disclosing the vulnerability count, whereas LLM-assisted symbolic execution [13] and RTOS function identification [14] address narrower verification tasks than end-to-end vulnerability detection. General-purpose LLM-based vulnerability detection has expanded rapidly. Existing surveys review model architectures, fine-tuning methods, and evaluation metrics [15], [16], whereas empirical studies compare LLMs with static analyzers [17], [18] or fine-tune models on function-level

datasets [19]–[21]. Most focus on Java or C#, use small or synthetic evaluation datasets [18], [19], or adopt projectunsplit corpora susceptible to data leakage [21]. Related studies report additional limitations, including single-vulnerability evaluation [22], model-specific bias [23], unvalidated inherited labels [24], low precision despite relative improvements [25], circular ground-truth construction [26], and arbitrary feature encoding for DDoS detection [27]. Broader research examines LLM-based IoT security [2], [5], [28], [29] and domain-specific applications, including edge anomaly detection [30], phishing detection [31], resourceadaptive deployment [32], IoT-network reliability [33], and ML security for 6G and embedded systems [1], [34]. However, human-verified firmware benchmarks that isolate trainingdata provenance and curriculum effects remain unavailable, whereas robustness, calibration, and explainability under distribution shifts receive limited evaluation. This study introduces IoTVulBench, a human-verified, cross-corpus benchmark for IoT firmware vulnerability detection, and uses it to evaluate systematically how training-data source, model architecture, tuning method, and curriculum design affect detection accuracy, efficiency, and robustness. This study addresses the following research questions: RQ1: Does domain-matched, human-verified IoT firmware training data outperform general-purpose vulnerability sources, and does staged curriculum learning improve cross-corpus generalization further? RQ2: How do architecture, tuning method, and model scale affect the accuracy-efficiency trade-off in IoT firmware vulnerability detection, and can ensemble or distillation strategies improve on single-model deployment? RQ3: How robust are trained detectors to lexical and compiler-level perturbation, distribution shift, and realworld temporal conditions, and how faithful are their explanations to true vulnerability indicators? IoTVulBench-Core is a human-verified IoT firmware vulnerability benchmark with a contamination-screened test set. The benchmark supports controlled evaluation of LLM architectures, training data, optimization strategies, deployment methods, and robustness under distribution shifts. The main contributions are as follows: We introduce IoTVulBench-Core, a human-verified IoT firmware vulnerability dataset with contaminationscreened evaluation, per-CWE inter-annotator agreement, and reproducible labeling, addressing limitations in existing benchmarks (RQ1). • We compare four training datasets, five LLM architectures, two tuning methods, and three training curricula to quantify the effects of data source, architecture, and curriculum on vulnerability detection (RQ1, RQ2). • We evaluate ensemble, distillation, and cascade strategies for resource-constrained IoT deployment, analyzing accuracy, latency, memory, and power trade-offs (RQ2). • We assess robustness under identifier renaming, compiler optimizations, and distribution shifts, and evaluate ex•

planation faithfulness using counterfactual patching with temporal, federated, and hardware-in-the-loop validation (RQ3). The remainder of this paper is organized as follows. Section II reviews related work. Section III describes the methodology, including dataset construction, data sources, and experimental design. Section IV presents the results, organized by RQ1 through RQ3. Section V presents the conclusion and outlines directions for future research. II. R ELATED W ORK Embedded IoT firmware connects network-facing services with hardware control and has become an increasingly attractive attack surface as LLM-based components are integrated into connected devices [5], [29]. Existing surveys document rapid growth in AI-driven embedded-system security research but report uneven coverage across device, network, and application layers, concentrated publication sources, and limited empirical validation of proposed defenses [29], [34]. Similar observations appear in 6G-enabled edge-learning surveys, where numerous machine-learning threats and countermeasures are cataloged without systematic evaluation of detection effectiveness [1]. Consequently, conceptual security taxonomies have expanded faster than validated firmware-level detection methods. Traditional firmware analysis relies primarily on rule-based static analysis, knowledge graphs, and commercial SAST tools, including SonarQube, CodeQL, and SnykCode [10], [18]. Recent learning-based methods reformulate vulnerability detection as sequence, graph, or vision classification using transformers, attention mechanisms, and hybrid neural architectures for firmware binaries, smart contracts, network traffic, and phishing detection [6], [22], [27], [31]. Current research increasingly adopts LLM-based approaches, including retrieval augmentation, preference-based fine-tuning, control-flow-aware context construction, multi-agent reasoning, symbolic-execution assistance, and automated firmware remediation [12]–[20], [23]. Multi-tool pipelines combining firmware analyzers and LLM agents further improve coverage and explainability, although reported gains remain tool- and dataset-specific [8], [11], [26], [30], [32]. Existing benchmarks include general-purpose vulnerability datasets, embedded Linux corpora, firmware opcode collections, smart-contract datasets, configurable firmware generators, and multi-vendor firmware testbeds [6]–[9], [18], [19], [24], [26]. However, prior studies report limitations including unclear label provenance, incomplete validation, limited benchmark diversity, labeling errors, data leakage, and reliance on small or synthetic datasets [6]–[9], [11], [21], [24], [26]. Firmware-focused studies also use partially validated datasets or narrow evaluation settings, while most LLM-based approaches target general-purpose code instead of embedded firmware [6], [10], [12], [18]–[21]. Existing surveys discuss LLM-IoT security broadly but do not isolate the effects of training data, architecture, tuning strategy, and curriculum [1], [2], [5], [28], [29]. These gaps motivate a human-verified,

contamination-screened benchmark for controlled evaluation of IoT firmware vulnerability detection. III. M ETHODOLOGY A. Study Design Overview The study followed a pre-defined and controlled comparative design, with all research questions specified before data collection. Three phases were conducted: Phase 1 compared training source, architecture, and curriculum on a fixed heldout target; Phase 2 extended the analysis to ensembles, efficiency, and explainability; and Phase 3 examined broader field-level questions under separate ethical review. Matthews Correlation Coefficient (MCC) served as the primary metric because it remains robust under class imbalance which was inherently present in IoTVulBench and also comparative benchmark datasets for random under sampling, while precision, recall, and F1 were reported for completeness. Figure 1 summarizes the overall methodology, from dataset construction to statistical analysis. B. Dataset Construction (Phase 1) IoTVulBench, the central dataset, was constructed from GitHub embedded and IoT firmware repositories and verified by three independent experts rather than automated labeling. Inter-annotator agreement was measured using Fleiss’ kappa for each CWE category, with disagreements resolved through a documented adjudication process. A prior power analysis guided dataset size, and a fixed, contamination-screened heldout target was partitioned from the verified corpus and excluded from all training conditions for consistent evaluation throughout the study. C. Data Sources and Harmonization Four primary training sources, distinguished by label provenance, were compared, while three literature-standard datasets served as secondary references. All datasets were harmonized and also randomly under sampled to match IoTVulBench into a common schema containing source and sample identifiers, code, labels, CWE identifiers, granularity, provenance, and language. CWE labels were mapped to the IoTVulBench taxonomy when supported by a defensible correspondence; otherwise, samples remained in the binary classification set but were excluded from CWE-level analyses. D. Contamination Screening and Experimental Design Matrix Training sources were screened against the held-out target using 8-gram character-overlap matching and repository-level fork detection, and flagged samples were removed before training. A sensitivity analysis injected lexical and semantic duplicates to estimate the impact of residual data leakage. The study evaluated architecture, tuning method, training source, and curriculum in a factorial design, with compute-constrained configurations excluded a priori and reported alongside the results.

E. Model Architectures Five architectures spanning three classes were evaluated. UniXcoder-base represented the encoder class. CodeLlama-7B and Qwen2.5-Coder-7B represented the small decoder class, contrasting code-only and multilingual pretraining. Qwen2.5Coder-32B and DeepSeek-Coder-V2-16B represented the midscale decoder class. Only the architecture and methods with notable performance gains were observed in the results section for better description to reflect detection performance and comparison. F. Models, Training, Evaluation, and Statistical Testing (Phase 1) Five architectures were evaluated: one encoder (UniXcoderbase), two small decoders (CodeLlama-7B, Qwen2.5-Coder7B), and two mid-scale decoders (Qwen2.5-Coder-32B, DeepSeek-Coder-V2-16B). Decoders used LoRA/QLoRA, whereas the encoder was fully fine-tuned; models up to 7B were also used to isolate architecture from tuning effects. Each training source was evaluated under size-matched and fullsize randomly under sampled to match IoTVulBench settings using single-source, pooled, and staged curricula, with top configurations repeated across multiple seeds. Performance was compared against a static analyzer, a prior encoder-based detector, and a frontier LLM. Models were evaluated on the primary held-out target and source-specific splits using MCC, precision, recall, F1, false-negative rate at a fixed false-positive rate, calibration, and severity-weighted MCC. Identifier renaming and compiler-level robustness tests were applied to buildable repositories. Statistical significance was assessed using paired Wilcoxon tests with rank-biserial effect sizes and Benjamini-Hochberg correction in the pilot test phase of this study as well. G. Ensemble, Efficiency, Explainability, and Continual Refinement (Phase 2) Ensemble members were selected to maximize accuracy while minimizing error correlation, with confidence-weighted voting. Cross-architecture ensembles, self-consistency sampling, and a static-analysis hybrid were compared. For edge deployment, quantization-aware fine-tuning, distillation, a recall-optimized cascade, retrieval-augmented detection, and a CWE-routed mixture-of-experts were evaluated for memory, latency, and power. Explainability was assessed using lineoverlap, counterfactual faithfulness, and vulnerability localization. Selective prediction employed shift-robust conformal calibration, while high-disagreement cases were re-verified and incorporated into iterative retraining. H. Reproducibility, Governance, and Extended Scope Studies (Phase 3) The replication package includes training scripts, hyperparameters, source manifests, contamination logs, and the transfer matrix, alongside verified consistency checks. Prior to the main evaluation phase, pilot testing examined temporal generalization, patch validation, federated learning, and

TABLE I C OMPARISON OF R EFERENCE PAPERS BY F OCUS , M ETHOD , DATASET, AND K EY L IMITATION Ref

Focus & Method

Dataset

Key Limitation

[10]

KG construction (BiRNN+grey corr.)

Common Crawl, JSONPlaceholder, UCI Alpine Linux images (76 feat.) 4-vendor AAOS firmware 120 images, 10 vendors Sensor/RTOS binaries 10 OSS projects, 530K funcs. CICIoT2023, CICIoMT2024 Linux kernel CVE pairs QEMU/FreeRTOS synthetic FW CodeQL-AOPRO outputs, 5 CWEs Vul4J, 8,011-rec. RAG corpus Unspecified Java corpus ∼60 / 108 papers (SLR) AST/callgraph/dataflow tasks 10-project synthetic corpus Function-level dataset Ethereum opcode/semantic feat. 110-contract benchmark + real-world 22,330 Ethereum contracts N/A

Non-firmware data; invalid eval.

IoE-specific data paths MQTT session data Edge network traffic 11 primary studies 21,430-URL dataset IIoT sensor networks N/A N/A 63 articles (PRISMA)

Theoretical framework only Narrow protocol scope Narrow application scope Small corpus Narrow task (phishing only) Narrow scope (resource optimization) No documented search protocol No original empirical evaluation Severe source concentration (96.7% IEEE)

[8] [11] [26] [13], [14] [6] [27] [7] [12] [25]

Docker FW benchmark generator (B4IoT) SBOM reconstruction + binary divergence Hidden web-interface detection LLM-aided symbolic exec. & RTOS func. ID Opcode-sequence transformer (DeBERTa) Flow-to-image ViT (DDoS detection) Commit-diff vulnerability labeling (EVDD) LLM agent FW generation + remediation Semantic segmentation (SEVDF)

[19] [20] [15], [16] [17] [18] [21] [22] [23]

RAG-augmented LLM detection (Java) CFG-segmented, DPO-tuned LLM (Java) Surveys: LLM-VD taxonomy & pipeline Static-analysis competence (code LLMs) LLM vs. SAST benchmark (C#) Fine-tuning LLMs for VD (batch packing) Attention-mechanism comparison (WDNN) Multi-agent LLM auditing

[24] [2], [5], [28], [29] [3] [4] [30] [33] [31] [32] [9] [1] [34]

Multi-label vulnerability dataset (DIVE) Surveys: agent threats, taxonomy, edge intel., 7-layer review LLM threat prediction (IoE) Stateful authentication + LLM-IDS (MQTT) LLM agent + SHAP (zero-day resilience) Bibliometric review: LLM-IoT networking CNN-LSTM + SHAP-LLM phishing detection Resource-adaptive LLM deployment (MDP/PPO) Survey: vulnerability-dataset ecosystem Survey: ML security in 6G-IoT Systematic review: AI in embedded security IoT/Firmware

LLM-based VD

Smart Contract

Alpine-only; 3 images validated 1 image/vendor; SBOM tool failures Circular ground-truth recall Narrow scope (stub/func. ID only) No labeling/disassembler docs. Arbitrary flow-to-image encoding Only 10 CVEs documented Remediation rate unverifiable Low precision (1.7–43.8%) Small held-out set (72 pairs) No dataset specification No experiments / no IRR reported Zero-shot prompting only Small, synthetic, author-injected Project-unsplit; leakage risk Single vulnerability class Model-dependency bias Unvalidated labeling inheritance Conceptual; little/uneven empirical validation

LLM–IoT Integration

Broader Surveys

Fig. 1. Overview of the IoTVulBench cross-corpus evaluation methodology.

hardware-in-the-loop possibility theory exploitation to evaluate model proficiency. The dataset and source code will be made available in a Github repository (https://github.com/ rumman9799/IoTVulBench) with persistent access provided upon request. IV. R ESULTS AND A NALYSIS Table II reports precision, recall, F1, MCC, AUC, FNR at 0.5% FPR, and efficiency (parameters, inference cost) across all training sources, architectures, curricula, ensembles, reference comparators, and edge-deployment variants evaluated on the primary held-out target. This table anchors all subsequent analysis.

A. RQ1: Domain Match of Data Source and Curriculum 1) Training-Data Source Comparison: Under matched conditions, models trained with IoTVulBench achieved the highest MCC (0.58) of any single source, exceeding PrimeVul (0.44), D2A (0.39) and SARD-Embedded (0.29) (Table II). 2) Size-Matched vs. Full-Size Consistency: The source ranking held under both size-matched and random under sampled full-size training, indicating the advantage reflects label quality and domain match rather than data volume; D2A and PrimeVul retained larger full-size pools yet remained below IoTVulBench. 3) Curriculum Learning Comparison: Staged curriculum (pretraining on pooled generic sources, then fine-tuning on

TABLE II R ESULTS : ALL CONFIGURATIONS EVALUATED ON THE PRIMARY HELD - OUT AND UNDER SAMPLED TARGET TO MATCH I OTV UL B ENCH . B OLD INDICATES THE BEST VALUE PER COLUMN . ↑ = HIGHER IS BETTER , ↓ = LOWER IS BETTER . T HE PROPOSED CONFIGURATION ( STAGED , DIVERSITY- OPTIMIZED ENSEMBLE ) IS MARKED WITH †. F RONTIER LLM ROW IS ZERO / FEW- SHOT ( NOT FINE - TUNED ) WHILE EVERY OTHER ROW IS FINE - TUNED .

Configuration

P↑

R↑

F1↑

MCC↑

AUC↑

FNR@0.5%FPR↓

Params / Costa

IoTVulBench D2A SARD-Embedded PrimeVul Pooled Staged Ensemble (staged, diversity-opt.)† Distilled student Cascade (student + 7B) Static analyzer Encoder detector (prior work) Frontier LLM (few-shot)

0.71 0.52 0.44 0.58 0.63 0.76 0.79 0.72 0.77 0.61 0.39 0.48

0.68 0.61 0.58 0.63 0.71 0.80 0.83 0.75 0.81 0.42 0.35 0.55

0.69 0.56 0.50 0.60 0.67 0.78 0.81 0.73 0.79 0.50 0.37 0.51

0.58 0.39 0.29 0.44 0.53 0.69 0.73 0.63 0.70 0.31 0.14 0.27

0.74 0.55 0.47 0.61 0.70 0.81 0.85 0.76 0.82 0.53 0.44 0.58

0.34 0.58 0.66 0.49 0.41 0.27 0.21 0.33 0.24 0.71 0.88 0.68

7B 16B — 32B 7B 7B 5×7B 350M Avg. 1.1B — 125M —

Single-Source Training

Curriculum Strategy

IoTVulBench) raised MCC to 0.69, exceeding both singlesource (0.58) and naive pooling (0.53). Precision and recall both improved under staging, indicating reduced false positives and false negatives simultaneously. 4) Domain-Match Advantage vs. Strongest Generic Comparator: The staged IoTVulBench model’s advantage over PrimeVul, the strongest single-source training dataset, remained significant after correction (Table II), confirming the domain-match effect holds against the best available alternative, not only weaker legacy benchmarks. B. RQ2: Efficiency And Accuracy Trade-off Architecture performance depended on the training source, with no model consistently achieving the highest MCC (Spearman ρ = 0.20, p = 0.42). At matched scale (≤7B), LoRAtuned decoders outperformed fully fine-tuned encoders. The staged Qwen2.5-Coder-7B achieved an MCC of 0.69, increasing to 0.73 with a diversity-optimized ensemble and surpassing all baselines by at least ∆MCC ≥ 0.42. QLoRA-native INT4 quantization retained 95% of full-precision performance, while a distilled 350M model preserved 91% of the teacher’s MCC. A recall-optimized cascade achieved MCC 0.70 using an average of 1.1B active parameters. Overall, the distilled model and cascade provided the best accuracy-efficiency tradeoff, whereas the ensemble delivered the highest detection performance. C. RQ3: Robustness and Field Validity The proposed model retained 86% and 82% of unperturbed MCC under identifier renaming and compiler/optimization shifts, respectively, indicating structural rather than lexical dependence. At 0.5% false-positive-rate tolerance, it missed

Proposed / Edge-Deployment

Reference Comparators

21% of vulnerabilities versus 71% for the strongest comparator (Table II), with strong calibration (Brier score = 0.09); explanations overlapped vulnerable lines in 78% of correct detections, with 71% causally validated and 0.74 localization accuracy. Shift-robust conformal prediction maintained coverage within 1.2 points of 95% versus 8–11 points of under-coverage for standard methods, while refinement improved MCC by 0.02 per cycle without detected drift. Extended validation achieved MCC 0.65 on screened postcutoff CVEs and 0.64 under federated training, within 0.05 of centralized training; hardware-in-the-loop testing confirmed 29/40 detections as exploitable. All pre-registered comparisons remained significant after Benjamini–Hochberg correction (paired Wilcoxon, N = 96): IoTVulBench versus generic sources (∆MCC = +0.14–+0.29, p < 0.02), staged versus single-source curricula (∆MCC = +0.11, p = 0.008), and the proposed configuration versus the strongest static analyzer (∆MCC = +0.42, p < 0.001) even in the pilot test evaluation. Overall, domain-matched data and staged curricula improved generalization, diversity-optimized ensembles maximized accuracy, distilled cascades optimized accuracy-efficiency, and the approach remained robust, calibrated, and reliable under distribution shift and practical evaluation. V. C ONCLUSION Firmware vulnerability detection depended more on label provenance and curriculum design than model scale: a stagedtrained 7B model outperformed a 32B model trained on generic data, and no architecture generalized best across all training sources. Robustness, calibration, and largely faithful explanations suggest that predictions relied primarily on structural reasoning, although the 71% causal correctness rate indicates room for improvement. Temporal, federated, and

hardware-in-the-loop evaluations further supported generalizability, with hardware evidence remaining limited. Supplementary training and evaluation on larger external benchmarks (e.g., D2A, PrimeVul), following random under sampling and standard preprocessing, introduced some noise relative to IoTVulBench but showed largely consistent performance trends, corroborating the study’s overall conclusions. Future work will expand robustness testing, hardware validation, explanation faithfulness, rare-CWE coverage, federated evaluation, and patch generation, and will incorporate full-scale versions of these external datasets alongside an enlarged IoTVulBench corpus to further improve accuracy and realworld applicability. VI. DECLARATION OF AI AI tools were used solely for language refinement, including paraphrasing, grammar correction and clarity. R EFERENCES [1] M. A. Ferrag, O. Friha, B. Kantarci, N. Tihanyi, L. Cordeiro, M. Debbah, D. Hamouda, M. Al-Hawawreh, and K.-K. R. Choo, “Edge learning for 6g-enabled internet of things: A comprehensive survey of vulnerabilities, datasets, and defenses,” IEEE Communications Surveys & Tutorials, vol. 25, no. 4, pp. 2654–2713, 2023. [2] O. Friha, M. A. Ferrag, B. Kantarci, B. Cakmak, A. Ozgun, and N. Ghoualmi-Zine, “Llm-based edge intelligence: A comprehensive survey on architectures, applications, security and trustworthiness,” IEEE Open Journal of the Communications Society, vol. 5, pp. 5799–5856, 2024. [3] M. A. Khan, “Llm-driven real-time threat prediction and response for internet of energy (ioe),” IEEE Network, 2025. [4] N. Jamil, M. Shariq, S. S. H. Shah, H. S. Mehdy, Z. A. A. Alyasseri, E. Hosseini, A. D. E. Berini, and Z. M. Zain, “A novel stateful authentication framework approach with llm-based ids for mqtt security,” IEEE Internet of Things Journal, 2025. [5] A. Joshi and S. Baidya, “Securing the cognitive layer: A survey on security threats, defenses, and privacy-preserving architectures for llmiot integration,” Journal of Cybersecurity and Privacy, vol. 6, no. 2, p. 63, 2026. [6] M. Nandish, J. Kumar, H. Mohan, and M. M. Kumar, “Transformerbased vulnerability detection in iot firmware binaries using opcode sequences,” IEEE Access, 2025. [7] M. Alqarni, A. Azim, and T. Singh, “Evdd-a novel dataset for embedded system vulnerability detection mechanism,” in 2022 21st IEEE International Conference on Machine Learning and Applications (ICMLA). IEEE, 2022, pp. 764–769. [8] D. de Ruck, V. Goeman, M. Willocx, J. Lapon, and V. Naessens, “Linuxbased iot benchmark generator for firmware security analysis tools,” in Proceedings of the 18th International Conference on Availability, Reliability and Security, 2023, pp. 1–10. [9] T. Karim and M. S. Akter, “Vulnerability datasets for software security: A survey of existing resources, challenges, and future directions,” Computers & Security, p. 104926, 2026. [10] P. Xiao, L. Xie, F. Hang, and H. Li, “Advanced technique for firmware security analysis through heterogeneous data fusion and knowledge mapping,” PloS one, vol. 20, no. 4, p. e0319660, 2025. [11] H. Yu, F. Khan, S. H. Ding, J. Wu, N. Stakhanova, and B. C. Fung, “Security risk assessment of android automotive os software supply chain using firmware reverse engineering,” Computers & Security, p. 104923, 2026. [12] S. M. Abtahi and A. Azim, “Securing llm-generated embedded firmware through ai agent-driven validation and patching,” in 2025 IEEE International Conference on Collaborative Advances in Software and COmputiNg (CASCON). IEEE, 2025, pp. 210–218. [13] L. Deng, Q. Zhong, J. Song, H. Lei, and W. Li, “Llm-based unknown function automated modeling in sensor-driven systems for multilanguage software security verification,” Sensors, vol. 25, no. 9, p. 2683, 2025.

[14] Z. Zheng, Y.-a. Tan, Z. Chen, Z. Lu, W. Meng, and S. Wang, “Empowering iot security: Automated identification of standard library functions in rtos firmware with llm and rag,” IEEE Internet of Things Journal, 2026. [15] Z. Sheng, Z. Chen, S. Gu, H. Huang, G. Gu, and J. Huang, “Llms in software security: A survey of vulnerability detection techniques and insights,” ACM Computing Surveys, vol. 58, no. 5, pp. 1–35, 2025. [16] S. M. Taghavi Far and F. Feyzi, “Large language models for software vulnerability detection: a guide for researchers on models, methods, techniques, datasets, and metrics,” International Journal of Information Security, vol. 24, no. 2, p. 78, 2025. [17] C.-Y. Su and C. McMillan, “Do code llms do static analysis?” Empirical Software Engineering, vol. 31, no. 5, p. 116, 2026. [18] D. Gnieciak and T. Szandala, “Large language models versus static code analysis tools: A systematic benchmark for vulnerability detection,” IEEE Access, vol. 13, pp. 198 410–198 422, 2025. [19] G. Antal, L. Értekes, N. Szolnoki, and P. Hegedűs, “Evaluating retrievalaugmented generation for llm-based vulnerability detection: An empirical study on real-world java vulnerabilities,” IEEE Access, vol. 14, pp. 50 878–50 891, 2026. [20] S. Wang, Y. Jiang, S. Xu, Y. Liu, M. Yin, and G. He, “Fine-tuning a vulnerability-specific large language model for a hybrid software vulnerability detection method,” Engineering Applications of Artificial Intelligence, vol. 165, p. 113410, 2026. [21] A. Shestov, R. Levichev, R. Mussabayev, E. Maslov, P. Zadorozhny, A. Cheshkov, R. Mussabayev, A. Toleu, G. Tolegen, and A. Krassovitskiy, “Finetuning large language models for vulnerability detection,” IEEE Access, 2025. [22] S. B. Osei, R. Huang, R. Wang, and Z. Ma, “An empirical study of attention mechanisms in wide and deep neural networks for smart contract vulnerability detection,” Journal of Systems and Software, p. 112895, 2026. [23] Z. Wei, J. Sun, Y. Sun, Y. Liu, D. Wu, Z. Zhang, X. Zhang, M. Li, Y. Liu, C. Li et al., “Advanced smart contract vulnerability detection via llm-powered multi-agent systems,” IEEE Transactions on Software Engineering, 2025. [24] S. J. Alsunaidi, H. Aljamaan, and M. Hammoudeh, “Dive: A multi-label smart contract vulnerability dataset,” Scientific Data, 2026. [25] Z. Cao, Y. Sun, Z. Xu, K. Li, Y. Fu, Y. Zhang, Z. Kong, and Y. Liu, “Reframing paths as logic: Semantic segmentation for vulnerability detection,” Proceedings of the ACM on Programming Languages, vol. 10, no. OOPSLA1, pp. 1989–2016, 2026. [26] J. Guo, H. Yang, K. Yan, J. Hu, X. Jia, H. Du, and Q. Zhou, “Falconscope: Effective and efficient detection of hidden web interfaces in iot devices,” in Proceedings of the ACM Web Conference 2026, 2026, pp. 3066–3077. [27] M. Ali, Y. Saleem, S. Hina, and G. A. Shah, “Ddosvit: Iot ddos attack detection for fortifying firmware over-the-air (ota) updates using vision transformer,” Internet of Things, vol. 30, p. 101527, 2025. [28] F. He, T. Zhu, D. Ye, B. Liu, W. Zhou, and P. S. Yu, “The emerged security and privacy of llm agent: A survey with case studies,” ACM Computing Surveys, vol. 58, no. 6, pp. 1–36, 2025. [29] F. Sarhaddi, N. T. Nguyen, A. Zuniga, M. Khan, P. Hui, S. Tarkoma, H. Flores, and P. Nurmi, “Llms and iot: A comprehensive survey on large language models and the internet of things,” IEEE Open Journal of the Communications Society, vol. 7, pp. 3585–3616, 2026. [30] Y. K. Saheed and J. E. Chukwuere, “Autonomous llm agent: A memoryaugmented, edge-optimized shap explanations with zero-day attack resilience in iot/industrial iot networks,” IEEE Internet of Things Journal, 2025. [31] S. M. Alasmari, H. Sakly, N. Kraiem, and A. Algarni, “Phishing detection in iot: an integrated cnn-lstm framework with explainable ai and llm-enhanced analysis,” Discover Internet of Things, vol. 5, no. 1, p. 102, 2025. [32] K. Xu, D. Zhang, and X. Wang, “Llm-conductor: A closed-loop resource-adaptive architecture for secure llm deployment in industrial sensor networks and iiot systems,” Sensors, vol. 26, no. 9, p. 2733, 2026. [33] M. Alipio and M. Bures, “The role of large language models in designing reliable networks for internet of things: A short review of most recent developments,” IEEE Access, 2025. [34] A. Oun, K. Wince, and X. Cheng, “The role of artificial intelligence in boosting cybersecurity and trusted embedded systems performance: A systematic review on current and future trends,” IEEE Access, 2025.

Related documents

• Cross-Corpus Evaluation of Generalizable Vulnerability Detection in IoT Firmware#615189
• Cross-Corpus Evaluation of Generalizable Vulnerability Detection in IoT Firmware#614222
• A Transient Prefix for Identifying Profiles under Development by the Working Groups of the Internet Engineering Task Force#135031
• CVE-2026-83196 — CRITICAL 9.1#923742
• CVE-2026-83229 — CRITICAL 9.1#923744