Evaluating Large Language Models in Vulnerability Detection Under Variable Context Windows

David Mohaisen; Jie Lin

REVIEW 4 major objections 6 minor 26 references

Evaluating Large Language Models in Vulnerability Detection Under Variable Context Windows

T0 review · 4 major / 6 minor · reviewed 2026-08-09 · deepseek-v4-flash

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

Pith's one-line read Large language models differ sharply in whether input code length affects their Java vulnerability verdicts, with GPT-4, Mistral, and Mixtral at full context showing no measured effect.

desk verdict A useful question undercut by a load-bearing proxy tokenizer and thin statistics; the robustness claims for GPT-4, Mistral, and Mixtral should not be trusted as written. read the letter →

arxiv 2502.00064 v1 pith:EYWKZW5B submitted 2025-01-30 cs.CR cs.LG

Jie Lin , David Mohaisen This is my paper · ORCID

classification cs.CRcs.LG

keywords largelanguagemodelsvulnerabilitydetectionJavacontextwindowtokenizedcodelengthchi-squaretestrobustnessevaluationBytePairEncoding

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 asks whether the length of tokenized Java code changes how accurately ten large language models detect vulnerabilities. Using a uniform Byte Pair Encoding tokenizer to measure each file's length and chi-square tests on 140 known-vulnerable Java files, it finds that GPT-4, and also Mistral and Mixtral when given their full 32,768-token context, show no statistically significant link between code length and either accuracy or explicitness. In contrast, Gemma, CodeGemma, Phi, and most LLaMA configurations show a significant relationship. The authors argue that a robust detector should be indifferent to input length, so models that accept the null hypotheses are preferable for Java vulnerability detection, and they recommend preprocessing that reduces token count for the length-sensitive models.

What carries the argument

The measurement machinery is a unified Byte Pair Encoding tokenizer with a 30,000-token vocabulary, applied externally to compute every Java file's tokenized length while each LLM receives the raw code and uses its own internal tokenization. The statistical engine is the chi-square test of independence run under two null hypotheses: no relationship between tokenized length and vulnerability-identification accuracy, and no relationship between tokenized length and response explicitness. Responses are manually categorized as correct (explicitly vulnerable), incorrect (explicitly not vulnerable), or irrelevant, and the test compares these categories across token-length groups at a 0.05 significance level, 0.80 power, and a medium effect size of 0.3.

What would settle it

Recompute the tokenized length of the 140 files with each model's native tokenizer and rerun the chi-square tests; if GPT-4 or Mistral then shows a significant length-performance relationship, the reported robustness is an artifact of the proxy tokenizer rather than a property of the models.

Watch

Extended reading notes

Core claim

The paper reports that model families have sharply different length-robustness profiles in Java vulnerability detection. At a significance level of 0.05 with power 0.8 and a medium effect size, GPT-4 accepts both null hypotheses, and Mistral and Mixtral accept both when the context window is set to 32,768 tokens, meaning no statistical relationship was detected between tokenized code length and accurate or explicit vulnerability verdicts. Most other configurations, including all Gemma variants, reject at least one hypothesis. The paper also reports that increasing parameter count alone does not guarantee robustness, that a larger context window helps only some models, and that higher-precision fp16 inference can improve length-independence for CodeGemma and Phi without resolving explicitness issues.

Load-bearing premise

The claim assumes that a single external BPE tokenizer with a 30,000-token vocabulary produces counts that faithfully track how much of each model's effective context the code occupies, even though every LLM uses its own internal tokenization.

Editorial extensions

If this is right

For GPT-4, and for Mistral or Mixtral run at their full 32,768-token context, length-based preprocessing of Java code appears unnecessary for vulnerability detection accuracy and explicitness.
Running Mistral or Mixtral at a restricted 2,048-token context makes them length-sensitive, so context-window allocation is a practical lever for robustness in these open models.
Parameter count alone is not a reliable predictor of length-robustness; architecture and training choices, plus numerical precision for some families, matter more.
For length-sensitive models such as Gemma, CodeGemma, and Phi, reducing token count while preserving code structure is a plausible route to more consistent detection, as the paper explicitly recommends.

Reading between the lines

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

The unified BPE tokenizer is only a proxy for what each model actually consumes; re-measuring length with each model's native tokenizer could change which configurations accept or reject the null hypotheses.
Because the dataset contains only vulnerable files, 'accuracy' in this study is a true-positive rate, and the length-robustness of false-positive decisions (calling safe code vulnerable) is never tested.
The chi-square design compares length bins rather than a continuous dose-response; a regression-based analysis would indicate whether the length effect is monotonic and where a critical threshold lies.
The fact that Mistral and Mixtral become length-robust only at the largest context window suggests that context pressure, not just architecture, drives the effect, and that intermediate context sizes could be scanned to locate the transition.

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.

Desk Editor's Note

read the letter

Quick take: this is a small empirical study with a genuinely relevant question—does tokenized input length affect LLM vulnerability detection?—but the central measurement leans on a proxy the paper itself admits is separate from each model's own tokenizer, and the statistical reporting is too thin to support the conclusions. I'd want major revision before trusting the robustness claims.

What's actually good: the paper looks at Java rather than the usual C/C++, uses the Vul4J dataset, and compares ten model families across multiple context windows. That is a reasonable scope. The observation that some models (Gemma, Phi) show length sensitivity while others (GPT-4, Mistral, Mixtral at long contexts) don't is exactly the kind of practical signal practitioners want. The chi-square approach is straightforward but not wrong.

The soft spots are severe. The biggest is the unified BPE tokenizer with a 30k vocabulary. Every LLM has its own tokenizer, and the paper gives no evidence that the external token count ranks the 140 files the same way the model's real tokenizer does. Since that external count is the independent variable for every test, the accepted nulls for GPT-4, Mistral, and Mixtral could just mean responses are independent of that particular proxy—not that the models are robust to input length. The stress-test note lands.

Second, all 140 files are vulnerable. Accuracy is therefore sensitivity only; a model that says "yes" to everything scores perfectly. That misses false positives entirely and makes the accuracy-based robustness claims hard to interpret.

Third, Table II reports only accept/reject. No p-values, no effect sizes despite Cohen's w being set, no confidence intervals, and no multiple-testing correction across the dozens of tests. With n=140, power is okay for a medium effect, but the binning scheme and tokenizer choice are free parameters that could flip results. The Mistral and Mixtral robustness conclusions rest on one row each.

Minor: Table I lists CodeLLaMA 70B with a context window of 2048, probably a typo, and the abstract has typos that suggest haste.

Who is this for? Researchers picking LLMs for Java vulnerability detection who want guidance on length sensitivity. The question deserves an answer, but this version doesn't provide it with enough rigor. If I were an editor, I'd send it to peer review because the topic is timely and the flaws are fixable—per-model tokenization or a validated proxy, a dataset with both vulnerable and clean files, full statistics, and ideally a pre-registered analysis. As written, I would not cite the robustness results.

Referee Report

4 major / 6 minor

Summary. The paper studies whether the tokenized length of Java source code affects the accuracy and explicitness of ten LLM families in vulnerability detection. The authors curate 140 vulnerable Java files from Vul4J, obtain responses from 39 model/quantization/context-window configurations, measure code length with a single external BPE tokenizer, and run chi-square tests of independence between binned token counts and two response-quality categories. They report which configurations accept or reject the two null hypotheses, concluding that GPT-4 and the large-context versions of Mistral and Mixtral are robust to input length, while other models are not.

Significance. If the findings were valid, they would be practically useful for selecting and configuring LLMs for vulnerability detection, and the broad multi-model comparison is a reasonable starting point. The paper also makes a concrete falsifiable claim about length-robustness that could inform deployment decisions. However, the current evidence does not support the central claim because the length variable is a proxy that is explicitly decoupled from the tokenization each model actually uses, and because the statistical reporting is too sparse to verify the accept/reject decisions. The comparative breadth and the clear statement of hypotheses are strengths, but the methodology needs substantial rework before the conclusions can be trusted.

major comments (4)

[Section III.E and Section IV] The independent variable in every chi-square test is the token count produced by a single externally fitted BPE tokenizer with a 30,000-vocabulary (Section III.E), which the paper states is "separate from the LLMs' detection process." This makes the measured construct a proxy, not the tokenized length that each model actually consumes. Different LLM families use different internal tokenizers, so the ranking of the 140 files by this proxy can diverge from the ranking by a model's own tokenizer. The central conclusion that GPT-4, Mistral at 32768 context, and Mixtral at 32768 context are robust to tokenized length is therefore unsupported unless the authors demonstrate that the proxy strongly correlates with each model's internal token count, or unless they re-run the analysis using each model's own tokenizer. This is the load-bearing issue for the paper's main claim.
[Section IV and Table II] The paper reports only accept/reject decisions in Table II; it does not report chi-square statistics, p-values, degrees of freedom, effect sizes, or cell counts. With 140 files and roughly 39 separate tests at alpha=0.05, a reader cannot assess whether accepted nulls reflect genuine independence or low power, nor whether rejected nulls survive multiple-testing correction. The stated effect size (Cohen's w=0.3) and power (0.80) are not connected to the actual tests: no achieved power or minimum detectable effect is given, and the token-length binning scheme is never described, although bin boundaries determine degrees of freedom and expected counts. Please provide the full test statistics and a clear explanation of the binning procedure.
[Section III.D and Section V] All 140 dataset files are vulnerable (Section III.A and III.D), so the "accuracy" metric is a sensitivity/true-positive rate with no false-positive component. The null hypotheses are framed as being about "vulnerability detection accuracy," but the experimental design cannot detect length effects on false-positive responses because no non-vulnerable files are presented. The robustness claims for GPT-4, Mistral, and Mixtral are therefore only about the ability to recognize known vulnerabilities in vulnerable files, not about overall detection accuracy. This limitation should be stated explicitly, or the dataset should include balanced negative samples.
[Section III.B and Table I] Table I lists 39 configurations rather than 10 models, because several models appear with multiple quantization schemes and context windows. Treating each configuration as an independent test without accounting for the shared underlying model or the multiplicity of tests inflates the risk of false discoveries. The analysis should address this dependency structure, for example by grouping tests by model family or by applying a multiple-testing correction and reporting adjusted conclusions.

minor comments (6)

[Title and Abstract] The title contains spacing errors ("V ariable", "T okenization"), and the abstract contains typos such as "damanges," "an d," and "t he" that should be corrected before resubmission.
[Section III.E] The BPE tokenizer's training corpus, vocabulary construction, and any preprocessing of Java code before tokenization are not specified. Please provide these details so that the token-count measure is reproducible.
[Table I] The reported context window for CodeLLaMA 70B is 2048, which appears inconsistent with the text stating that CodeLLaMA handles sequences up to 100,000 tokens. Please clarify which context window was used and why the table lists 2048.
[Section II] The statement that "no studies have addressed factors influencing the quality of LLM responses" is too broad given that several cited works, including Khare et al. [8] and Dong et al. [10], examine prompt and context-related factors. Please narrow the claim to the specific relationship studied in this paper.
[Section III.C and Section III.D] The system prompt asks the model to answer "yes or no," but the response categorization includes an "Irrelevant Response" category. Please explain how responses that do not follow the yes/no instruction were scored and whether such responses are counted as incorrect, inexplicitness, or both.
[Section VI] The recommendation that preprocessing should reduce token count while preserving code structure is not directly supported by the experiments, which only test whether length and performance are associated; they do not test whether reducing length improves performance. Please soften this recommendation or add evidence.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity found: the evaluation is an empirical chi-square analysis whose inputs (response labels, token counts) are independently defined and not fitted to the outcomes.

full rationale

The paper's central claim is a statistical comparison between an externally defined token-length proxy and LLM response categories. The only independent variable is the token count produced by a BPE tokenizer with a 30,000-token vocabulary (Section III.E), and the dependent variables are manually categorized LLM responses (Section III.D). The paper explicitly states that this tokenization is 'separate from the LLMs' detection process' and is used 'solely for analysis,' so it is not a fitted parameter or a hidden input to the models being tested. No equation in the paper defines the result in terms of the hypothesis, and no conclusion is derived from a self-citation. The related-work citations by the authors are contextual and not load-bearing. The main limitations—potential mismatch between the external tokenizer and each model's internal tokenizer, low statistical power, and unreported p-values—are measurement-validity concerns, not circularity. Because the dataset (Vul4J) and ground truth are external and the analysis pipeline is transparent, the derivation is self-contained and no circular step can be exhibited.

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

The paper introduces no new entities. Its free parameters are choices about tokenization and statistical thresholds that shape the reported results. The key assumptions are that the externally tokenized length matches each model's effective context usage and that the all-vulnerable dataset supports a meaningful accuracy measure.

free parameters (4)

BPE vocabulary size = 30,000 tokens
Chosen in Section III.E without justification; token counts and thus all chi-square tests depend on this choice.
Chi-square effect size target = 0.3 (Cohen's w)
Set in Section IV; used for power considerations, but no sample size calculation or achieved power reported.
Token-length binning scheme = Not disclosed
Chi-square requires discretizing token length; the number and boundaries of bins are free choices that materially affect accept/reject outcomes, and are not described.
Dataset curation threshold = Not disclosed
Step 6 of Section III.A manually excludes 'non-relevant' files without explicit criteria, which can bias the length distribution and results.

assumptions (3)

domain assumption All 140 curated Java files are vulnerable
The accuracy metric treats a 'yes' response as correct, so the paper only measures sensitivity, not false-positive rate; this is stated in Section III.D.
domain assumption External BPE token count is a valid proxy for the model's processed context length
Section III.E uses one 30k BPE tokenizer for analysis while each LLM tokenizes internally, so the tested length may not correspond to the actual input seen by the model.
standard math Chi-square test assumptions hold
The tests assume independent observations and expected cell counts of at least 5; with 140 files and unknown binning, these conditions are unverified.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Evaluating Large Language Models in Vulnerability Detection Under Variable Context Windows." pith.science (2026). https://pith.science/paper/EYWKZW5B

@misc{pith2026250200064,
  author       = {Pith},
  title        = {Pith review of: Evaluating Large Language Models in Vulnerability Detection Under Variable Context Windows},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/EYWKZW5B}},
  note         = {Machine review of arXiv:2502.00064}
}

read the original abstract

This study examines the impact of tokenized Java code length on the accuracy and explicitness of ten major LLMs in vulnerability detection. Using chi-square tests and known ground truth, we found inconsistencies across models: some, like GPT-4, Mistral, and Mixtral, showed robustness, while others exhibited a significant link between tokenized length and performance. We recommend future LLM development focus on minimizing the influence of input length for better vulnerability detection. Additionally, preprocessing techniques that reduce token count while preserving code structure could enhance LLM accuracy and explicitness in these tasks.

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

26 extracted references · 6 canonical work pages

[1]

AMAL: high- ﬁdelity, behavior-based automated malware analysis and cl assiﬁcation,

A. Mohaisen, O. Alrawi, and M. Mohaisen, “AMAL: high- ﬁdelity, behavior-based automated malware analysis and cl assiﬁcation,” Comput. Secur . , vol. 52, pp. 251–266, 2015. [Online]. Available: https://doi.org/10.1016/j.cose.2015.04.001

doi:10.1016/j.cose.2015.04.001 2015
[2]

Analyzing and detecting emerging internet of things malware: A graph-based approac h,

H. Alasmary, A. Khormali, A. Anwar, J. Park, J. Choi, A. Ab usnaina, A. Awad, D. Nyang, and A. Mohaisen, “Analyzing and detecting emerging internet of things malware: A graph-based approac h,” IEEE Internet Things J. , vol. 6, no. 5, pp. 8977–8988, 2019. [Online]. Available: https://doi.org/10.1109/JIOT.2019.2925929

arXiv 2019
[3]

Industry-speciﬁc vulnerability assessm ent,

M. Alkinoon, H. Althebeiti, A. Alkinoon, M. Mohaisen, S. Salem, and D. Mohaisen, “Industry-speciﬁc vulnerability assessm ent,” in W eb Information Systems Engineering - WISE 2024 - 25th Internat ional Conference, Doha, Qatar , December 2-5, 2024, Proceedings, Part V , ser. Lecture Notes in Computer Science, M. Barhamgi, H. Wang , and X. Wang, Eds., vol. 1...

doi:10.1007/978-981-96-0576-7 2024
[4]

Enriching vulnerabilit y reports through automated and augmented description summarization,

H. Althebeiti and D. Mohaisen, “Enriching vulnerabilit y reports through automated and augmented description summarization,” in Information Security Applications - 24th International Conference, WI SA 2023, Jeju Island, South Korea, August 23-25, 2023, Revised Selected P apers, ser. Lecture Notes in Computer Science, H. Kim and J. M. Y oun, Eds., vol. 144...

doi:10.1007/978-981-99-8024-6 2023
[5]

C leaning the nvd: Comprehensive quality assessment, improvements, and analyses,

A. Anwar, A. Abusnaina, S. Chen, F. Li, and D. Mohaisen, “C leaning the nvd: Comprehensive quality assessment, improvements, and analyses,” IEEE Transactions on Dependable and Secure Computing , vol. 19, no. 6, pp. 4255–4269, 2022

work page 2022
[6]

DL-FHMC: deep learning-based ﬁne-grained hierarchical learning approa ch for robust malware classiﬁcation,

A. Abusnaina, M. Abuhamad, H. Alasmary, A. Anwar, R. Jang , S. Salem, D. Nyang, and D. Mohaisen, “DL-FHMC: deep learning-based ﬁne-grained hierarchical learning approa ch for robust malware classiﬁcation,” IEEE Trans. Dependable Secur . Comput. , vol. 19, no. 5, pp. 3432–3447, 2022. [Online]. Available: https://doi.org/10.1109/TDSC.2021.3097296

arXiv 2022
[7]

Transformer-based language models for softw are vulnerability detection,

C. Thapa, S. I. Jang, M. E. Ahmed, S. Camtepe, J. Pieprzyk, and S. Nepal, “Transformer-based language models for softw are vulnerability detection,” in Annual Computer Security Applications Conference, ACSAC 2022 . ACM, 2022, pp. 481–496. [Online]. Available: https://doi.org/10.1145/3564625.3567985

arXiv 2022
[8]

Understanding the effectiveness of large language models in detecting security vulnerabilities,

A. Khare, S. Dutta, Z. Li, A. Solko-Breslin, R. Alur, and M . Naik, “Understanding the effectiveness of large language models in detecting security vulnerabilities,” CoRR, vol. abs/2311.16169, 2023. [Online]. Available: https://doi.org/10.48550/arXiv.2311.16169

arXiv doi:10.48550/arxiv.2311.16169 2023

Show all 26 references

[9]

Benchmarking large language models for log analysis, secu rity, and interpretation,

E. Karlsen, X. Luo, N. Zincir-Heywood, and M. I. Heywood, “Benchmarking large language models for log analysis, secu rity, and interpretation,” CoRR, vol. abs/2311.14519, 2023. [Online]. Available: https://doi.org/10.48550/arXiv.2311.14519

2023 doi arXiv
[10]

Exploring context window of large language m odels via decomposed positional vectors,

Z. Dong, J. Li, X. Men, W. X. Zhao, B. Wang, Z. Tian, W. Chen , and J.-R. Wen, “Exploring context window of large language m odels via decomposed positional vectors,” CoRR, vol. abs/2405.18009, 2024. [Online]. Available: https://doi.org/10.48550/arXiv.2405.18009

2024 doi arXiv
[11]

Llama: Open and efﬁcient foundation language models,

H. Touvron, T. Lavril, G. Izacard et al. , “Llama: Open and efﬁcient foundation language models,” CoRR, vol. abs/2302.13971, 2023. [Online]. Available: https://doi.org/10.48550/arXiv.2302.13971

2023 doi arXiv
[12]

Llama 2: Open foundation and ﬁne-tuned chat models,

H. Touvron, L. Martin et al., “Llama 2: Open foundation and ﬁne-tuned chat models,” CoRR, vol. abs/2307.09288, 2023. [Online]. Available: https://doi.org/10.48550/arXiv.2307.09288

2023 doi arXiv
[13]

Code llama: Open foundation models for code,

B. Rozi` ere, J. Gehring et al. , “Code llama: Open foundation models for code,” CoRR, vol. abs/2308.12950, 2023. [Online]. Available: https://doi.org/10.48550/arXiv.2308.12950

2023 doi arXiv
[14]

Introducing meta llama 3: The most capable ope nly available llm to date,

Meta AI, “Introducing meta llama 3: The most capable ope nly available llm to date,” 2024, meta AI Blog. [Online]. Availa ble: https://ai.meta.com/blog/meta-llama-3/ 4

2024
[15]

Gemma: Open models based on gemini research and technology,

T. Mesnard, C. Hardin et al. , “Gemma: Open models based on gemini research and technology,” CoRR, vol. abs/2403.08295, 2024. [Online]. Available: https://doi.org/10.48550/arXiv.2403.08295

2024 doi arXiv
[16]

Codegemma - an ofﬁcial google release for code llms,

P . Cuenca, O. Sanseviero, V . Srivastav, P . Schmid, M. Da vaadorj, and L. B. Allal, “Codegemma - an ofﬁcial google release for code llms,” April 2024, accessed: 2024-05-31. [Online]. Av ailable: https://huggingface.co/blog/codegemma

2024
[17]

Mistral 7b,

A. Q. Jiang, A. Sablayrolles et al. , “Mistral 7b,” CoRR, vol. abs/2310.06825, 2023. [Online]. Available: https://doi.org/10.48550/arXiv.2310.06825

2023 doi arXiv
[18]

Mixtral of experts,

——, “Mixtral of experts,” CoRR, vol. abs/2401.04088, 2024. [Online]. Available: https://doi.org/10.48550/arXiv.2401.04088

2024 doi arXiv
[19]

Textbooks are all you need,

S. Gunasekar, Y . Zhang et al. , “Textbooks are all you need,” CoRR, vol. abs/2306.11644, 2023. [Online]. Available: https://doi.org/10.48550/arXiv.2306.11644

2023 doi arXiv
[20]

Phi-2: The surprising power of small language models,

M. Abdin, J. Aneja et al. , “Phi-2: The surprising power of small language models,” Microsoft Research Blog , 2023. [Online]. Available: https://www.microsoft.com/en-us/research/blog/phi-2-the-surprising-power-of-small-language-models/

2023
[21]

Phi-3 technical report: A highly capable language model locally on your phone,

M. I. Abdin, S. A. Jacobs et al., “Phi-3 technical report: A highly capable language model locally on your phone,” CoRR, vol. abs/2404.14219,

arXiv
[22]

Reimagining self-adaptation in the age of large language models,

R. Donakanti, P . Jain, S. Kulkarni, and K. V aidhyanatha n, “Reimagining self-adaptation in the age of large language models,” CoRR, vol. abs/2404.09866, 2024. [Online]. Available: https://doi.org/10.48550/arXiv.2404.09866

2024 doi arXiv
[23]

Incremental comprehension of garden-path sente nces by large language models: Semantic interpretation, syntacti c re-analysis, and attention,

A. Li, X. Feng, S. Narang, A. Peng, T. Cai, R. S. Shah, and S. V arma, “Incremental comprehension of garden-path sente nces by large language models: Semantic interpretation, syntacti c re-analysis, and attention,” CoRR, vol. abs/2405.16042, 2024. [Online]. Available: https://...

2024 doi arXiv
[24]

Vul4j : A dataset of reproducible java vulnerabilities geared towards the stud y of program repair techniques,

Q.-C. Bui, R. Scandariato, and N. E. D. Ferreyra, “Vul4j : A dataset of reproducible java vulnerabilities geared towards the stud y of program repair techniques,” in MSR. ACM, 2022, pp. 464–468. [Online]. Available: https://doi.org/10.1145/3524842.3528482

2022
[25]

A new algorithm for data compression,

P . Gage, “A new algorithm for data compression,” The C Users Journal archive , vol. 12, pp. 23–38, 1994. [Online]. Available: https://api.semanticscholar.org/CorpusID:59804030 5

1994
[2024]

Available: https://doi.org/10.48550/ar Xiv.2404.14219

[Online]. Available: https://doi.org/10.48550/ar Xiv.2404.14219

doi arXiv

Pith tools

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

[1] [1]

AMAL: high- ﬁdelity, behavior-based automated malware analysis and cl assiﬁcation,

A. Mohaisen, O. Alrawi, and M. Mohaisen, “AMAL: high- ﬁdelity, behavior-based automated malware analysis and cl assiﬁcation,” Comput. Secur . , vol. 52, pp. 251–266, 2015. [Online]. Available: https://doi.org/10.1016/j.cose.2015.04.001

doi:10.1016/j.cose.2015.04.001 2015

[2] [2]

Analyzing and detecting emerging internet of things malware: A graph-based approac h,

H. Alasmary, A. Khormali, A. Anwar, J. Park, J. Choi, A. Ab usnaina, A. Awad, D. Nyang, and A. Mohaisen, “Analyzing and detecting emerging internet of things malware: A graph-based approac h,” IEEE Internet Things J. , vol. 6, no. 5, pp. 8977–8988, 2019. [Online]. Available: https://doi.org/10.1109/JIOT.2019.2925929

arXiv 2019

[3] [3]

Industry-speciﬁc vulnerability assessm ent,

M. Alkinoon, H. Althebeiti, A. Alkinoon, M. Mohaisen, S. Salem, and D. Mohaisen, “Industry-speciﬁc vulnerability assessm ent,” in W eb Information Systems Engineering - WISE 2024 - 25th Internat ional Conference, Doha, Qatar , December 2-5, 2024, Proceedings, Part V , ser. Lecture Notes in Computer Science, M. Barhamgi, H. Wang , and X. Wang, Eds., vol. 1...

doi:10.1007/978-981-96-0576-7 2024

[4] [4]

Enriching vulnerabilit y reports through automated and augmented description summarization,

H. Althebeiti and D. Mohaisen, “Enriching vulnerabilit y reports through automated and augmented description summarization,” in Information Security Applications - 24th International Conference, WI SA 2023, Jeju Island, South Korea, August 23-25, 2023, Revised Selected P apers, ser. Lecture Notes in Computer Science, H. Kim and J. M. Y oun, Eds., vol. 144...

doi:10.1007/978-981-99-8024-6 2023

[5] [5]

C leaning the nvd: Comprehensive quality assessment, improvements, and analyses,

A. Anwar, A. Abusnaina, S. Chen, F. Li, and D. Mohaisen, “C leaning the nvd: Comprehensive quality assessment, improvements, and analyses,” IEEE Transactions on Dependable and Secure Computing , vol. 19, no. 6, pp. 4255–4269, 2022

work page 2022

[6] [6]

DL-FHMC: deep learning-based ﬁne-grained hierarchical learning approa ch for robust malware classiﬁcation,

A. Abusnaina, M. Abuhamad, H. Alasmary, A. Anwar, R. Jang , S. Salem, D. Nyang, and D. Mohaisen, “DL-FHMC: deep learning-based ﬁne-grained hierarchical learning approa ch for robust malware classiﬁcation,” IEEE Trans. Dependable Secur . Comput. , vol. 19, no. 5, pp. 3432–3447, 2022. [Online]. Available: https://doi.org/10.1109/TDSC.2021.3097296

arXiv 2022

[7] [7]

Transformer-based language models for softw are vulnerability detection,

C. Thapa, S. I. Jang, M. E. Ahmed, S. Camtepe, J. Pieprzyk, and S. Nepal, “Transformer-based language models for softw are vulnerability detection,” in Annual Computer Security Applications Conference, ACSAC 2022 . ACM, 2022, pp. 481–496. [Online]. Available: https://doi.org/10.1145/3564625.3567985

arXiv 2022

[8] [8]

Understanding the effectiveness of large language models in detecting security vulnerabilities,

A. Khare, S. Dutta, Z. Li, A. Solko-Breslin, R. Alur, and M . Naik, “Understanding the effectiveness of large language models in detecting security vulnerabilities,” CoRR, vol. abs/2311.16169, 2023. [Online]. Available: https://doi.org/10.48550/arXiv.2311.16169

arXiv doi:10.48550/arxiv.2311.16169 2023