Pith. sign in

REVIEW 3 major objections 5 minor 53 references

A hierarchical code graph with LLM-inferred function roles detects and localizes malicious Python packages without expert review.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

T0 review · grok-4.5

2026-07-12 03:05 UTC pith:QRODETYA

load-bearing objection Solid integrative detector with real PyPI wins and strong tables; the LLM type-scan is the softest load-bearing piece but does not sink the empirical case. the 3 major comments →

arxiv 2607.03350 v1 pith:QRODETYA submitted 2026-07-03 cs.CR cs.AIcs.SE

LLM-Enhanced Hierarchical Heterogeneous Graph Representation Learning for Malicious Python Package Detection

classification cs.CR cs.AIcs.SE
keywords malicious Python packagessoftware supply chainheterogeneous graph neural networklarge language modelsPyPIfunction-level localizationhierarchical code graph
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

Malicious packages on PyPI rarely hide their intent in one place; the attack spreads across packages, files, functions, imports, and install-time scripts. Existing detectors either match fixed signatures, flatten everything into a homogeneous graph, or ask a large language model to read truncated source and guess. This paper argues that the missing piece is an explicit hierarchical heterogeneous graph: package, file, and function nodes linked by contain, import, and call edges, plus an extra layer of function semantic roles that an LLM invents from the code itself. A type-aware graph neural network then propagates messages separately for each node and edge type, so malicious signals can travel along the real attack chain. Dropping one function at a time measures how much the package-level malicious score falls, and the LLM is asked only to explain the highest-scoring subgraphs. On real PyPI packages the method reports roughly 97 percent accuracy and F1, stays stable on tiny and huge packages and on sparse or dense import graphs, and recovers the true malicious functions in most of a manually annotated sample, all without a human expert in the loop.

Core claim

Jointly modeling explicit hierarchical structure (package–file–function nodes and contain/import/call edges) together with LLM-inferred function semantic roles inside a type-aware hierarchical heterogeneous GNN yields package-level malware classification that outperforms traditional ML, signature tools, homogeneous GNNs, and strong zero-shot LLMs, while drop-node attribution plus LLM explanation localizes the responsible functions automatically.

What carries the argument

H2GLM / H2GNN: a hierarchical heterogeneous code graph enriched by LLM-assigned function semantic types, processed by successive type-specific projections, content-type feature processing, and edge-type-guided message passing, followed by drop-node attribution for localization.

Load-bearing premise

The LLM must assign stable, security-relevant function roles and hierarchical summaries that can safely be treated as reliable node types; if those labels are noisy or circular, both the detection gain and the automatic localization rest on sand.

What would settle it

Re-run the full pipeline after replacing the LLM-derived function types with random or purely syntactic labels (or with an independent human taxonomy) and check whether package-level F1 and function-localization accuracy collapse on the same held-out PyPI split.

Watch this falsifier — get emailed when new claim-graph text bears on it.

If this is right

  • Package-level malware scanners can keep high recall and precision even when packages are tiny, multi-megabyte, or import-heavy.
  • Function-level drop-node scores plus LLM explanation can surface the precise attack chain without a human reverse engineer.
  • Homogeneous call-graph GNNs and pure LLM context-window readers are measurably weaker once hierarchy and semantic roles are made explicit.
  • Continuous PyPI monitoring becomes feasible: the pipeline can flag new uploads and submit confirmed malware with no manual triage step.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The same hierarchical-plus-LLM-role pattern could transfer to npm, crates.io, or Maven once language-specific AST extractors exist.
  • False positives on legitimate SDKs that open network sockets suggest that service-registration or provenance context is the next missing node type.
  • If the LLM type inventory is learned once from a small seed and frozen, the method becomes less sensitive to future model updates or prompt drift.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

3 major / 5 minor

Summary. The paper proposes H2GLM, an LLM-enhanced hierarchical heterogeneous graph framework for detecting malicious Python packages on PyPI. It builds a hierarchical code graph with package/file/function nodes and contain/import/call edges, uses an LLM to assign function-level semantic roles (phi_LLM) and hierarchical summaries, then trains a type-aware H2GNN (phi-guided projection, phi_LLM-guided processing, psi-guided message passing) for package-level classification. A drop-node attribution step plus LLM reasoning localizes suspicious functions without expert labels. Experiments on a decontaminated corpus of ~3k malicious and matched benign packages report ~97% Acc/F1 overall, large gains over ML, signature tools, homogeneous GNNs, and several LLMs across size and import strata, ablations, a 300-package manual localization set (95.67%), and a four-month PyPI deployment that led to 19 confirmed removals.

Significance. Software supply-chain malware on PyPI is a high-impact, practical problem. The work makes a concrete modeling contribution by jointly treating explicit hierarchical heterogeneity and LLM-inferred latent semantic roles inside a single type-aware GNN, rather than treating LLMs only as encoders or post-hoc explainers. Strengths that should be credited include the stratified evaluation (size and import complexity, including extreme tails), homogeneous-GNN controls, staged t-SNE feature analysis, a manually annotated localization subset, a real deployment with maintainer-confirmed removals, and a public replication package. If the semantic-type layer is shown to be accurate, stable, and non-leaky, the approach is a useful template for other package ecosystems.

major comments (3)
  1. [Section IV-B, Eq. (1); Table V] Section IV-B (Eq. 1) and the associated implementation note state that the function-type inventory is produced by a single centralized LLM scan over 100 packages drawn from the target dataset, after which every Function node is labeled and those types drive both H2GNN layers and the localization explanations. No accuracy, inter-run stability, inter-annotator agreement, or train/test isolation of that scan is reported. The ablation in Table V shows a ~4.8 F1 drop when phi_LLM-guided processing is removed, so the layer is load-bearing for the headline numbers. If the 100 packages overlap the test split, or if the LLM largely rediscovers surface patterns already correlated with the package label, the claimed benefit of latent semantic heterogeneity is circular or leaky rather than a genuine modeling advance. The authors should (i) document the exact split isolation of the type-induction sca
  2. [Section IV-D, Eq. (8); RQ5 / Table VI] Section IV-D defines the function attribution score s(v_f) as the drop in malicious probability after removing a single function node (Eq. 8) and thresholds at lambda=0.45 tuned on validation. This is presented as measuring association (and, in the case study, as identifying the core malicious function). Drop-node scores are sensitive to graph connectivity, residual paths, and correlated supporting utilities; they do not establish that the removed node is a necessary cause of malice. The 95.67% localization accuracy on 300 packages is encouraging but rests on the same unvalidated phi_LLM types and on author-constructed ground truth without reported inter-annotator statistics. The paper should either (a) reframe the claim strictly as model-internal attribution rather than causal localization, or (b) add controls (e.g., random-node baselines, multi-node removals, comparison to gradient/att
  3. [Tables I-IV; Section V-A] Tables I-IV report large absolute gains but no confidence intervals, bootstrap estimates, or statistical significance tests across the stratified splits. With a fixed 15/15/70 split and free parameters (lambda, H2GNN depth/dimensions, LLM type inventory), it is hard to judge whether the ~2% variance claimed across strata and the gaps versus MPHunter/HERCULE/Qwen3 are stable. Adding per-stratum CIs or a small multi-seed/multi-split study would make the central empirical claim much more secure without changing the experimental design.
minor comments (5)
  1. [Figure 1] Figure 1's three-panel paradigm sketch is useful but the node labels (N/A vs Semantic Type k) are hard to read in the rendered version; a clearer legend would help.
  2. [Section IV-B] The prompt templates and the exact list of LLM-induced function types are deferred to the replication package. A short table or appendix listing the discovered type inventory (and how many functions fall into each) would make the paper self-contained.
  3. [Section IV] Notation mixes H2GLM / H2GNN / G_H; a single consistent acronym table early in Section IV would reduce cognitive load.
  4. [Section V-H] In the real-world deployment paragraph, the 13 unconfirmed cases are attributed to legitimate SDK network patterns; a brief discussion of how service-registration context could be added as a feature would strengthen the practical takeaway.
  5. [Section VII] Related work cites several concurrent GNN-LLM security papers; a short explicit contrast paragraph (what prior work models as homogeneous vs what H2GLM adds) would sharpen the novelty claim.

Circularity Check

0 steps flagged

No circular derivation: empirical supervised detector whose labels, graphs, and metrics are external to the model equations.

full rationale

H2GLM is a standard supervised learning pipeline (heterogeneous graph construction + LLM-derived node attributes + type-aware GNN + drop-node attribution). Package-level labels come from an external malware corpus plus popular PyPI packages under a decontamination protocol; they are not defined by any equation inside the paper. The hierarchical graph (package/file/function nodes, contain/import/call edges) and the H2GNN layers (Eqs. 3–7) are architectural choices whose parameters are learned from the training split; the reported Acc/F1 numbers are ordinary held-out evaluation against those external labels, not quantities forced by construction. LLM function-type assignment (Eq. 1) and hierarchical summaries are intermediate features, not the target variable; even though the type vocabulary is induced by a scan of 100 packages from the same ecosystem, this is ordinary feature engineering and does not make the malicious/benign prediction equal to its own input. Localization accuracy is measured against a separately annotated subset of 300 packages (author consensus), again an external evaluation, not a self-definitional loop. No uniqueness theorem, ansatz, or fitted parameter is imported via self-citation and then re-presented as a first-principles prediction. The paper therefore contains no circular step under the six enumerated patterns; score 0 is the correct, non-manufactured outcome.

Axiom & Free-Parameter Ledger

3 free parameters · 5 axioms · 2 invented entities

The central claim rests on standard GNN/LLM tooling plus several paper-specific modeling choices: a hand-designed hierarchy of node/edge types, LLM-induced function roles treated as types, particular feature encoders, a two-layer type-aware message-passing design, a drop-node threshold λ, and dataset construction assumptions (hash decontamination, popularity-matched benign packages, author-built localization labels). No physical constants; free parameters are architectural and threshold choices plus learned weights.

free parameters (3)
  • drop-node threshold λ = 0.45
    Tuned on validation with step 0.05 and set to 0.45; directly controls which functions are declared malicious for localization.
  • H2GNN depth L and hidden/projection dimensions = L=2; hidden dim e.g. 128 in baselines
    Architecture choices (L=2 stated; homogeneous baselines use hidden 128) that shape capacity and multi-hop propagation; learned weights are fit to the train split.
  • LLM-induced function-type inventory = generated from 100-package scan
    Type set is automatically generated by scanning 100 packages rather than fixed a priori; the resulting discrete type vocabulary is a data-dependent design parameter of ϕ_LLM.
axioms (5)
  • standard math Standard supervised learning and GNN message-passing mathematics (projection, mean aggregation, residual update, global mean pool + MLP).
    Used throughout §IV-C equations (3)–(7) without novel proof obligations.
  • domain assumption AST-extractable package/file/function hierarchy plus contain/import/call relations adequately represent malicious behavior propagation in Python packages.
    Graph Extraction §IV-A; dynamic eval/exec and environment-aware paths may be only partially visible statically.
  • domain assumption LLM function-role labels and hierarchical summaries are trustworthy enough to serve as semantic node types and features.
    Eq. (1) and Hierarchical Heterogeneous Feature Graph Generation; errors here propagate into classification and explanations.
  • ad hoc to paper Drop in malicious probability after removing a function node measures that function’s causal contribution to malice.
    Localization §IV-D Eq. (8); assumes limited compensatory pathways and stable classifier behavior under node deletion.
  • domain assumption MD5 + fuzzy hashing decontamination and popularity-stratified benign sampling yield a leakage-free, representative train/test distribution.
    Dataset Construction §V-A; underpins all reported metrics.
invented entities (2)
  • Hierarchical Heterogeneous Feature Graph G_H with ϕ_LLM semantic types no independent evidence
    purpose: Add latent functional heterogeneity on top of structural package/file/function graphs so H2GNN can do type-aware learning.
    Defined in §IV-B; the graph schema is a modeling construct, not an independently measured physical object.
  • H2GNN (ϕ-guided projection, ϕ_LLM-guided processing, ψ-guided message passing) no independent evidence
    purpose: Specialize message passing to hierarchical and semantic heterogeneity for package classification.
    Introduced in §IV-C as the paper’s core model; evidence is empirical performance, not external theory.

pith-pipeline@v1.1.0-grok45 · 23118 in / 3474 out tokens · 25895 ms · 2026-07-12T03:05:20.204568+00:00 · methodology

0 comments
read the original abstract

Malicious Python packages have become a major threat to software supply chain ecosystems due to the widespread adoption of open-source repositories such as PyPI. Existing learning-based detection methods struggle to capture the hierarchical organization and heterogeneous interactions among different program entities. Although Large Language Models (LLMs) have demonstrated strong capabilities in code understanding and semantic reasoning, they are rarely integrated with structural program representations for fine-grained malicious behavior analysis. In this paper, we propose an LLM-enhanced hierarchical heterogeneous graph representation learning framework for malicious Python package detection. The framework constructs a hierarchical heterogeneous code graph that explicitly models heterogeneous code entities and different types of structural dependencies. LLMs are further leveraged to infer function-level semantic roles, introducing an additional layer of semantic heterogeneity. Based on this graph, we develop a hierarchical heterogeneous graph neural network that performs type-aware message passing over different node and edge categories, effectively modeling malicious behavior propagation for accurate package-level classification. The framework also incorporates a function-level attribution mechanism which, combined with LLM reasoning, automatically identifies suspicious functions and localizes fine-grained malicious behaviors without human expert intervention. Extensive experiments on real-world datasets show that our framework consistently outperforms traditional machine learning methods, graph-based detectors, and state-of-the-art LLMs across packages with varying sizes and dependency complexities, while providing accurate, robust, and interpretable malicious behavior localization.

Figures

Figures reproduced from arXiv: 2607.03350 by Baoquan Cui, Fengge Wu, Hang Gao, Jian Zhang, Peng Qiao, Xiaoyu Chen, Zhen Tang.

Figure 1
Figure 1. Figure 1: Three types of code security analysis paradigms [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: The figure shows a malicious Python package where attacks span various stages. [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: The framework of H2GLM, consisting of four components:1) Graph Extraction, which constructs code data into a heterogeneous graph; 2) Hierarchical Heterogeneous Feature Graph Generation, which leverages LLMs to transform code data into a hierarchical heterogeneous graph to fully characterize the features contained within the code; 3) Classification, which utilizes a heterogeneous GNN specifically designed f… view at source ↗
Figure 4
Figure 4. Figure 4: T-SNE visualization of feature representations at different stages. [PITH_FULL_IMAGE:figures/full_fig_p009_4.png] view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

53 extracted references · 1 canonical work pages

  1. [1]

    PyPI statistics,

    Python Software Foundation, “PyPI statistics,” https://py pi.org/stats/, 2024

  2. [2]

    Highly evasive attacker leverages SolarWinds supply chain to compromise multiple global victims with SUNBURST backdoor,

    FireEye, “Highly evasive attacker leverages SolarWinds supply chain to compromise multiple global victims with SUNBURST backdoor,” https://cloud.google.com/blog/ topics/threat-intelligence/evasive-attacker-leverages-sol arwinds-supply-chain-compromises-with-sunburst-bac kdoor, 2020, originally published by FireEye; now hosted by Mandiant (Google Cloud). A...

  3. [3]

    Apache Log4j security vulnerabilities,

    Apache Software Foundation, “Apache Log4j security vulnerabilities,” https://logging.apache.org/log4j/2.x/s ecurity.html, 2021

  4. [4]

    SLSA: Supply-chain levels for software arti- facts,

    OpenSSF, “SLSA: Supply-chain levels for software arti- facts,” https://slsa.dev/, 2023

  5. [5]

    in-toto: Providing farm-to-table guarantees for bits and bytes,

    S. Torres-Arias, H. Afzali, T. K. Kuppusamy, R. Curtmola, and J. Cappos, “in-toto: Providing farm-to-table guarantees for bits and bytes,” in28th USENIX Security Symposium (USENIX Security 19). Santa Clara, CA: USENIX Association, Aug. 2019, pp. 1393–1410. [Online]. Available: https://www.usenix.org /conference/usenixsecurity19/presentation/torres-arias

  6. [6]

    Spellbound: Defending against package typosquatting,

    M. Taylor, R. K. Vaidya, D. Davidson, L. D. Carli, and V . Rastogi, “Spellbound: Defending against package typosquatting,” 2020. [Online]. Available: https://arxiv.org/abs/2003.03471

  7. [7]

    Beyond typosquatting: An in-depth look at package confusion,

    S. Neupane, G. Holmes, E. Wyss, D. Davidson, and L. D. Carli, “Beyond typosquatting: An in-depth look at package confusion,” in32nd USENIX Security Symposium (USENIX Security 23). Anaheim, CA: USENIX Association, Aug. 2023, pp. 3439–3456. [Online]. Available: https://www.usenix.org/conference/ usenixsecurity23/presentation/neupane

  8. [8]

    Small world with high risks: A study of security threats in the npm ecosystem,

    M. Zimmermann, C.-A. Staicu, C. Tenny, and M. Pradel, “Small world with high risks: A study of security threats in the npm ecosystem,” in28th USENIX Security Symposium (USENIX Security 19). Santa Clara, CA: USENIX Association, Aug. 2019, pp. 995–1010. [Online]. Available: https://www.usenix.org/conference/ usenixsecurity19/presentation/zimmerman

  9. [9]

    Bad snakes: Understanding and improving python package index mal- ware scanning,

    D.-L. Vu, Z. Newman, and J. S. Meyers, “Bad snakes: Understanding and improving python package index mal- ware scanning,” in2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE), 2023, pp. 499–511

  10. [10]

    Sok: Taxonomy of attacks on open-source software supply chains,

    P. Ladisa, H. Plate, M. Martinez, and O. Barais, “Sok: Taxonomy of attacks on open-source software supply chains,” in2023 IEEE Symposium on Security and Pri- vacy (SP), 2023, pp. 1509–1526

  11. [11]

    Practical automated detection of malicious npm packages,

    A. Sejfia and M. Sch ¨afer, “Practical automated detection of malicious npm packages,” inProceedings of the 44th International Conference on Software Engineering, ser. ICSE ’22. ACM, May 2022, p. 1681–1692. [Online]. Available: http://dx.doi.org/10.1145/3510003.3510104

  12. [12]

    Towards measuring supply chain attacks on package managers for interpreted languages,

    R. Duan, O. Alrawi, R. P. Kasturi, R. Elder, B. Saltaformaggio, and W. Lee, “Towards measuring supply chain attacks on package managers for interpreted languages,” 2020. [Online]. Available: https://arxiv.org/abs/2002.01139

  13. [13]

    Backstabber’s knife collection: A review of open source software supply chain attacks,

    M. Ohm, H. Plate, A. Sykosch, and M. Meier, “Backstabber’s knife collection: A review of open source software supply chain attacks,” 2020. [Online]. Available: https://arxiv.org/abs/2005.09535

  14. [14]

    Security issues in language-based software ecosystems,

    R. K. Vaidya, L. D. Carli, D. Davidson, and V . Rastogi, “Security issues in language-based software ecosystems,”

  15. [15]

    Available: https://arxiv.org/abs/1903.026 13

    [Online]. Available: https://arxiv.org/abs/1903.026 13

  16. [16]

    An empirical study of malicious code in pypi ecosystem,

    W. Guo, Z. Xu, C. Liu, C. Huang, Y . Fang, and Y . Liu, “An empirical study of malicious code in pypi ecosystem,” 2023. [Online]. Available: https: //arxiv.org/abs/2309.11021

  17. [17]

    On the feasibility of supervised machine learning for the detection of malicious software packages,

    M. Ohm, F. Boes, C. Bungartz, and M. Meier, “On the feasibility of supervised machine learning for the detection of malicious software packages,” inProceedings of the 17th International Conference on Availability, Reliability and Security, ser. ARES ’22. New York, NY , USA: Association for Computing Machinery, 2022. [Online]. Available: https://doi.org/10...

  18. [18]

    Pvdetector: Pretrained vulnerability detection on vulnerability-enriched code semantic graph,

    J. Li, L. Cui, J. Zhang, L. Li, R. Xi, and H. Zhu, “Pvdetector: Pretrained vulnerability detection on vulnerability-enriched code semantic graph,”ACM Trans. Softw. Eng. Methodol., vol. 35, no. 6, May 2026. [Online]. Available: https://doi.org/10.1145/3768582

  19. [19]

    Devign: Effective vulnerability identification by learning comprehensive program semantics via graph neural networks,

    Y . Zhou, S. Liu, J. Siow, X. Du, and Y . Liu, “Devign: Effective vulnerability identification by learning comprehensive program semantics via graph neural networks,” 2019. [Online]. Available: https://arxiv.org/abs/1909.03496

  20. [20]

    Evaluating llm-based detection of malicious package updates in npm,

    E. Wyss, D. Tassio, L. De Carli, and D. Davidson, “Evaluating llm-based detection of malicious package updates in npm,” 10 2025, pp. 678–692

  21. [21]

    Malguard: Towards real- time, accurate, and actionable detection of malicious packages in pypi ecosystem,

    X. Gao, X. Sun, S. Cao, K. Huang, D. Wu, X. Liu, X. Lin, and Y . Xiang, “Malguard: Towards real- time, accurate, and actionable detection of malicious packages in pypi ecosystem,” 2025. [Online]. Available: https://arxiv.org/abs/2506.14466

  22. [22]

    Redetect: A hybrid llm-gnn framework for high-precision reentrancy vulnerability detection in smart contracts

    S. Lin, “Redetect: A hybrid llm-gnn framework for high-precision reentrancy vulnerability detection in smart contracts.”

  23. [23]

    Contain- ing malicious package updates in npm with a lightweight permission system,

    G. Ferreira, L. Jia, J. Sunshine, and C. K ¨astner, “Contain- ing malicious package updates in npm with a lightweight permission system,” in2021 IEEE/ACM 43rd Interna- tional Conference on Software Engineering (ICSE), 2021, pp. 1334–1346

  24. [24]

    1+1¿2: Integrating deep code behaviors with metadata features for malicious pypi package detection,

    X. Sun, X. Gao, S. Cao, L. Bo, X. Wu, and K. Huang, “1+1¿2: Integrating deep code behaviors with metadata features for malicious pypi package detection,” ser. ASE ’24. New York, NY , USA: Association for Computing Machinery, 2024, p. 1159–1170. [Online]. Available: https://doi.org/10.1145/3691620.3695493

  25. [25]

    Codebert: A pre-trained model for programming and natural languages,

    Z. Feng, D. Guo, D. Tang, N. Duan, X. Feng, M. Gong, L. Shou, B. Qin, T. Liu, D. Jiang, and M. Zhou, “Codebert: A pre-trained model for programming and natural languages,” 2020. [Online]. Available: https://arxiv.org/abs/2002.08155

  26. [26]

    Graphcodebert: Pre-training code representations with data flow,

    D. Guoet al., “Graphcodebert: Pre-training code representations with data flow,” 2021. [Online]. Available: https://arxiv.org/abs/2009.08366

  27. [27]

    Deepwukong: Statically detecting software vulnerabilities using deep graph neural network,

    X. Cheng, H. Wang, J. Hua, G. Xu, and Y . Sui, “Deepwukong: Statically detecting software vulnerabilities using deep graph neural network,” vol. 30, no. 3, Apr. 2021. [Online]. Available: https://doi.org/10.1145/3436877

  28. [28]

    Killing two birds with one stone: Malicious package detection in npm and pypi using a single model of malicious behavior sequence,

    J. Zhang, K. Huang, Y . Huang, B. Chen, R. Wang, C. Wang, and X. Peng, “Killing two birds with one stone: Malicious package detection in npm and pypi using a single model of malicious behavior sequence,”ACM Transactions on Software Engineering and Methodology, vol. 34, no. 4, p. 1–28, Apr. 2025. [Online]. Available: http://dx.doi.org/10.1145/3705304

  29. [29]

    Spiderscan: Practical detection of malicious npm packages based on graph-based behavior modeling and matching,

    Y . Huanget al., “Spiderscan: Practical detection of malicious npm packages based on graph-based behavior modeling and matching,” inProceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering, ser. ASE ’24. New York, NY , USA: Association for Computing Machinery, 2024, p. 1146–1158. [Online]. Available: https://doi.org/10.1...

  30. [30]

    Efficient code analysis via graph representation learning-guided large language models,

    H. Gao, T. Peng, B. Cui, H. Huang, F. Wu, J. Zhao, and J. Zhang, “Efficient code analysis via graph representation learning-guided large language models,”

  31. [31]

    Available: https://arxiv.org/abs/2601.128 90

    [Online]. Available: https://arxiv.org/abs/2601.128 90

  32. [32]

    Bandit4mal,

    D.-L. Vu, “Bandit4mal,” https://github.com/lyvd/bandit 4mal, 2020, accessed: 2026-06-26

  33. [33]

    Ossgadget,

    Microsoft, “Ossgadget,” https://github.com/microsoft/O SSGadget, 2023, accessed: 2026-06-27

  34. [34]

    Warehouse: PyPI setup pattern malware check,

    Python Software Foundation, “Warehouse: PyPI setup pattern malware check,” https://github.com/pypi/ware house, 2020, commit 4d68ab7

  35. [35]

    Detecting python malware in the software supply chain with program analysis,

    R. Shariffdeen, B. Hassanshahi, M. Mirchev, A. El Hus- seini, and A. Roychoudhury, “Detecting python malware in the software supply chain with program analysis,” in2025 IEEE/ACM 47th International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP), 2025, pp. 203–214

  36. [36]

    A needle is an outlier in a haystack: Hunting malicious pypi packages with code clustering,

    W. Liang, X. Ling, J. Wu, T. Luo, and Y . Wu, “A needle is an outlier in a haystack: Hunting malicious pypi packages with code clustering,” in2023 38th IEEE/ACM Interna- tional Conference on Automated Software Engineering (ASE), 2023, pp. 307–318

  37. [37]

    Qwen2.5 technical report,

    A. Yang, B. Yang, B. Zhanget al., “Qwen2.5 technical report,” 2025. [Online]. Available: https: //arxiv.org/abs/2412.15115

  38. [38]

    The llama 3 herd of models,

    A. Grattafiori, A. Dubey, A. Jauhriet al., “The llama 3 herd of models,” 2024. [Online]. Available: https://arxiv.org/abs/2407.21783

  39. [39]

    Qwen3 technical report,

    Qwen, A. Yang, A. Liet al., “Qwen3 technical report,”

  40. [40]

    Available: https://arxiv.org/abs/2505.093 88

    [Online]. Available: https://arxiv.org/abs/2505.093 88

  41. [41]

    Deepseek-r1 incentivizes reasoning in llms through reinforcement learning,

    D. Guo, D. Yang, H. Zhanget al., “Deepseek-r1 incentivizes reasoning in llms through reinforcement learning,”Nature, vol. 645, no. 8081, p. 633–638, 2025. [Online]. Available: http://dx.doi.org/10.1038/s41586-0 25-09422-z

  42. [42]

    Typosquatting and combosquatting attacks on the python ecosystem,

    D.-L. Vu, I. Pashchenko, F. Massacci, H. Plate, and A. Sabetta, “Typosquatting and combosquatting attacks on the python ecosystem,” in2020 IEEE European Symposium on Security and Privacy Workshops (Eu- roS&PW), 2020, pp. 509–514

  43. [43]

    Dependency confusion: How I hacked into Apple, Microsoft and dozens of other companies,

    A. Birsan, “Dependency confusion: How I hacked into Apple, Microsoft and dozens of other companies,” https: //medium.com/@alex.birsan/dependency-confusion-4a5 d60fec610, 2021, medium. Accessed: 2026-06-23

  44. [44]

    Systematic review: Malware detection and classification in cybersecurity,

    S. Berrios, D. Leiva, B. Olivares, H. Allende-Cid, and P. Hermosilla, “Systematic review: Malware detection and classification in cybersecurity,”Applied Sciences, vol. 15, no. 14, p. 7747, 2025

  45. [45]

    Deep learning ap- proaches for malware detection: A comprehensive review of techniques, challenges, and future directions,

    M. Alshoulie and A. Mehmood, “Deep learning ap- proaches for malware detection: A comprehensive review of techniques, challenges, and future directions,”IEEE Access, vol. 13, pp. 118 652–118 677, 2025

  46. [46]

    ebpf: A new frontier for malware,

    D. Bogle, “ebpf: A new frontier for malware,” https: //redcanary.com/blog/threat-detection/ebpf-malware/, 2023, red Canary Blog. Accessed: 2026-06-23

  47. [47]

    Intriguing properties of adversarial ml attacks in the problem space [extended version],

    J. Cortellazziet al., “Intriguing properties of adversarial ml attacks in the problem space [extended version],” 2024

  48. [48]

    Heterogeneous graph attention network,

    X. Wang, H. Ji, C. Shi, B. Wang, P. Cui, P. Yu, and Y . Ye, “Heterogeneous graph attention network,” 2021. [Online]. Available: https://arxiv.org/abs/1903.07293

  49. [49]

    Heterogeneous graph transformer,

    Z. Hu, Y . Dong, K. Wang, and Y . Sun, “Heterogeneous graph transformer,” 2020. [Online]. Available: https: //arxiv.org/abs/2003.01332

  50. [50]

    Magnn: Metapath aggregated graph neural network for heterogeneous graph embedding,

    X. Fu, J. Zhang, Z. Meng, and I. King, “Magnn: Metapath aggregated graph neural network for heterogeneous graph embedding,” inProceedings of The Web Conference 2020, ser. WWW ’20. ACM, Apr. 2020, p. 2331–2341. [Online]. Available: http://dx.doi.org/10.1145/3366423.3380297

  51. [51]

    Model- ing and discovering vulnerabilities with code property graphs,

    F. Yamaguchi, N. Golde, D. Arp, and K. Rieck, “Model- ing and discovering vulnerabilities with code property graphs,” in2014 IEEE Symposium on Security and Privacy, 2014, pp. 590–604

  52. [52]

    Code llama: Open foundation models for code,

    B. Rozi `ereet al., “Code llama: Open foundation models for code,” 2024. [Online]. Available: https: //arxiv.org/abs/2308.12950

  53. [53]

    Vulnerability detection with code language models: How far are we?

    Y . Ding, Y . Fu, O. Ibrahim, C. Sitawarin, X. Chen, B. Alomair, D. Wagner, B. Ray, and Y . Chen, “Vulnerability detection with code language models: How far are we?” 2024. [Online]. Available: https: //arxiv.org/abs/2403.18624