Pith. sign in

REVIEW 4 major objections 6 minor 71 references

MalTotal: Cost-Effective and Language-Agnostic Malicious Code Poisoning Detection for Millions of Repositories

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

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

Pith's one-line read This paper argues that reducing code to minimal, dependency-preserving contexts around sensitive API calls lets LLMs detect malicious code across languages at a small fraction of the usual token cost.

desk verdict A genuinely useful scanner with real cost data and a credible large-scale deployment, but the current draft tunes hyperparameters on the test set and never tests a load-bearing false-negative gap in its TPL extraction; send it out with specific revision requests. read the letter →

arxiv 2608.03232 v1 pith:NWLT2PS4 submitted 2026-08-04 cs.CR

Jian Zhao , Shenao Wang , Qingyang Wu , Yanjie Zhao , Xiao Cheng , Haoyu Wang This is my paper
classification cs.CR
keywords supplychainsecuritymaliciouscodedetectionLLM-assistedanalysisslicingopensourcesoftwarelanguage-agnosticpoisoningstatic
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

MalTotal claims that malicious code in open-source repositories can be detected at large scale, in many programming languages, by giving a large language model small focused slices of code instead of whole files or repositories. The system first finds sensitive APIs, including third-party library functions whose semantics are summarized and cached by an LLM, then slices backward from those API call sites along control, data, and call dependencies to build compact behavior contexts, and finally asks an LLM to judge intent. In a pilot study, whole-repository inputs failed or misled the LLM for up to 46 percent of samples, while slice inputs removed those failures and cut token cost by 97.6 percent. On a five-language benchmark the paper reports an average F1-score of 93.1 percent against eight baselines, and a 94 percent token reduction against file-by-file analysis. Applied to 120,000 GitHub repositories with over 7.3 million files, the pipeline cost about $338 and surfaced 564 previously unknown malicious repositories.

What carries the argument

The central mechanism is the hybrid backward slicer operating on a Code Property Graph (CPG), which jointly encodes abstract syntax, control flow, and program dependence. For each sensitive API call, the slicer traverses the CPG backward along call chains, control dependencies, and data dependencies to collect all code that could influence the call, with the call depth capped at three and entire callee bodies retained; then slices are de-duplicated by maximal-content filtering and merged by line-level Jaccard similarity. A second supporting mechanism is the LLM-assisted third-party API analyzer, which reads only the immediate function body of each library API to decide whether it is sensitiv

What would settle it

Build a small corpus of ground-truth malicious packages where each sample invokes a third-party function whose immediate body is benign but whose transitive callee performs an obvious sensitive action (process spawning or network exfiltration). Run MalTotal's pipeline on that corpus; if recall collapses while recall on directly-sensitive wrappers stays high, the immediate-body simplification is the specific limiting factor predicted by the described design.

Watch

Extended reading notes

Core claim

MalTotal's central claim is that a three-stage pipeline — sensitive-API extraction, hybrid backward slicing over a Code Property Graph, and LLM-based semantic judgment — can identify malicious behavior in a language-agnostic way and at a cost that scales to millions of repositories. The extractor combines a curated knowledge base of 2,147 built-in sensitive APIs with an LLM that analyzes third-party library functions and caches semantic summaries; the slicer starts from each detected sensitive sink and follows call, control, and data dependencies up to depth three, keeping whole function bodies and merging overlapping slices into a minimal set of contexts; the judge classifies each context w

Load-bearing premise

The load-bearing assumption is that reading only the immediate body of a third-party library API is enough to know whether that API is sensitive; if a malicious wrapper hides the sensitive operation behind another function call inside its body, the API is never flagged and the malicious context is never built.

Editorial extensions

If this is right

  • If the results hold, malicious-code detection shifts from ecosystem-specific signatures to a generic semantic pipeline that can be ported to a new language by adding a parsing backend and a starter set of built-in sensitive APIs.
  • Token budgets cease to be the binding constraint on large-scale scans: a 94 percent reduction in LLM input makes a million-repository sweep economically plausible.
  • Detectors that ignore third-party library behavior miss a meaningful share of evasive malware; LLM-summarized library APIs recover part of that blind spot.
  • LLM verdicts come with machine-readable rationale (category, severity, analysis), so triage and false-positive review can be partly automated.
  • Because the method is sink-driven, it naturally suppresses false positives from benign code that merely imports sensitive libraries but never reaches a sensitive operation.

Reading between the lines

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

  • Editorial inference: the immediate-body-only rule for third-party APIs is the most likely failure point; a malicious wrapper that delegates to a sensitive transitive callee would slip past the extractor, and a targeted test corpus of such wrappers would clarify how much recall is being left on the table.
  • Editorial inference: the parameter choices (depth three, Jaccard threshold 0.3) are tuned on a small sample; checking whether the same settings hold for other languages or larger repositories would show how far the cost-accuracy balance generalizes.
  • Editorial inference: the LLM judge is itself an attack surface, and the paper's acknowledged prompt-injection risk suggests an A/B test of instruction-shielded prompts against the current prompt template.
  • Editorial inference: the headline economics ($338 for 120K repositories) count runtime inference for cached third-party APIs but not the one-time construction of the knowledge base and the 27,746 API analyses that produced the cache; a full lifecycle cost would matter for a security team adopting the pipeline.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 6 minor

Summary. MalTotal proposes a language-agnostic, LLM-assisted framework for detecting malicious code in open-source repositories. The pipeline consists of: (i) an LLM-assisted sensitive API extractor covering both built-in APIs (offline knowledge base) and third-party library (TPL) APIs (online analysis), (ii) a parsing-based pre-filter using Semgrep, (iii) a hybrid backward slicer on Joern Code Property Graphs that incorporates call-chain, control-dependency, and data-dependency slices with a call-depth limit k and Jaccard aggregation threshold tau, and (iv) an LLM-as-a-Judge semantic analyzer. The paper reports an average F1 of 93.1% across Python, JavaScript, Go, Java, and PHP on a new benchmark, a 94.0% token reduction versus file-level analysis, and a large-scale deployment on 120K GitHub repositories that discovered 564 previously unknown malicious repositories at a total cost of $338. The evaluation includes ablation studies, sensitivity analyses for slicing components, an LLM-comparison, a data-contamination check using post-cutoff packages, and a manual verification of TPL API identifications.

Significance. If the empirical claims hold, the paper makes a strong contribution: a scalable, multi-language detection pipeline with a compelling cost profile. The strengths are the public artifact (source code and data are promised), the extensive comparison against 8 baselines, the ablations that isolate the contribution of TPL identification and slicing, the sensitivity analysis on call depth, and the deliberate attempt to address data contamination with a post-cutoff test. The large-scale deployment, even with its limitations, is a meaningful practical demonstration. The main weakness is that a load-bearing design simplification — restricting TPL analysis to the immediate function body — is not validated against false negatives, and several evaluation choices (hyperparameter selection, small positive samples, no confidence intervals) leave room for the headline numbers to be optimistic. These issues are fixable with additional experiments rather than requiring a fundamentally different approach.

major comments (4)
  1. [§3.1.1 and §4.4] The TPL sensitive API collection restricts extraction to the immediate function body, explicitly "without recursively tracing its transitive callees" (§3.1.1). The entire pipeline depends on the LLM flagging a TPL function as sensitive before the parser emits rules and the slicer runs. A malicious wrapper that delegates a dangerous operation to a transitive callee (e.g., wrapper calls helper that calls os.system) is therefore invisible to the system. The manual verification (§4.4) samples 347 flagged-sensitive TPL APIs and measures only false positives, not false negatives; the w/o-TPL ablation (Table 6) shows TPL identification improves recall but does not validate the immediate-body restriction. No experiment measures how often sensitivity is visible only beyond the immediate body. This is load-bearing for the robustness claim against real-world TPL-based evasion. Please add a targeted
  2. [§3.2 and Table 7] The free parameters k (call depth, default 3) and tau (Jaccard threshold, default 0.3) are tuned empirically. Table 7 shows k=3 chosen on a 500-sample sensitivity set; no sensitivity analysis for tau is provided, and there is no held-out set to prevent selection overfitting. Since the reported average F1=93.1% is obtained under these choices, the benchmark numbers may reflect optimistic tuning. Please provide a tau sensitivity analysis and validate the chosen parameters on a separate holdout (or via nested cross-validation).
  3. [Tables 4 and 5] For Java, Go, and PHP the positive samples are 75, 80, and 143 respectively (Table 4). The F1 differences between MalTotal and the next best (e.g., Java 92.3 vs 48.0 for AppInspector) are large, but the absolute F1 values and cross-model comparisons (Table 9) lack confidence intervals. With sample sizes this small, the reported cross-language F1 differences could be within noise; for example, DeepSeek-V3 vs GPT-4o on Go (91.5 vs 93.3) is likely not significant. Please report CIs (e.g., bootstrap) or apply statistical tests for the headline comparisons.
  4. [§4.5] The large-scale study finds 564 "confirmed previously unknown" malicious repositories, but the confirmation is solely by the research team, with no inter-rater reliability statistic or independent external verification, and the sample population is the StarScout anomalous-repository list, which is not representative of GitHub as a whole. The reported FDR of 32.2% on the flagged set indicates substantial noise. Please provide inter-rater agreement (e.g., Cohen's kappa), a clear audit trail, and state explicitly how generalizable the discovery rate is outside the anomalous-popularity population.
minor comments (6)
  1. [Section 4] The section title contains a typo: "Evalution" should be "Evaluation".
  2. [§5] The sentence "Finally, our reliance on LLMs introduces a new attack surface." appears twice in consecutive paragraphs; remove the duplicate.
  3. [Table 1 and §2.2] The table uses the abbreviation "OOC (%)" while the text refers to "N.A." samples; align terminology.
  4. [§4.1] MalTracker is described as "JavaScrip only" — typo for "JavaScript".
  5. [§3.1.1 and Table 3] The text states 27,746 TPL APIs were analyzed and 694 are sensitive; Table 3 sums to 694. Please clarify whether the 27,746 includes all analyzed functions (sensitive or not) and how caching affects these counts.
  6. [Table 10] The after-cutoff contamination test uses only 260 packages and reports no confidence intervals; the GPT-4o F1 drop (−4.7 and −3.9) is described as "acceptable" but is not tested for significance. Adding a small statistical comparison would strengthen the claim.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: MalTotal's detection pipeline is self-contained, with external benchmarks, ablations, and a post-cutoff LLM generalization test.

full rationale

MalTotal does not derive its central claims from its own outputs. The built-in sensitive API knowledge base is assembled from external sources (MalOSS, MalTracker, official documentation) plus manual curation, not from MalTotal's own detection results. Third-party sensitive APIs are identified by an LLM, but the paper manually verifies a 50% sample (347/694) for false positives and, more importantly, runs a post-cutoff experiment on 260 malicious packages released after the LLM's training date; performance drops only slightly, showing the detector does not rely on the LLM having memorized the benchmark. The hybrid slicer and parsing-based filter are deterministic static-analysis components whose contribution is validated by ablations. Hyperparameters (k=3, tau=0.3) are tuned on a 500-sample subset of the benchmark; this is a mild 'test-set leakage' concern but does not make the reported F1 a mathematical consequence of the tuning, so it is not circularity. The explicit limitations in Section 5 (no transitive callee tracing, no cross-language taint, omitted alias resolution) are acknowledged generalization gaps, not self-referential steps. No load-bearing self-citation, imported uniqueness theorem, or definitional equivalence between an input and a prediction was found. The derivation chain from source code to malicious/benign judgment is independent of the paper's own conclusions.

Assumptions & free parameters 2 free parameters · 5 assumptions · 0 invented entities

The system rests on several domain assumptions about LLM capabilities, the completeness of sensitive API knowledge, and the reliability of the benchmark labels. The only numeric free parameters are the slicing depth k and the aggregation threshold tau, both tuned on the evaluation data rather than a separate holdout.

free parameters (2)
  • call depth limit k = 3
    Selected because it achieves the best F1 on a 500-sample sensitivity study (Table 7); k=4 and k=5 reduce F1.
  • Jaccard aggregation threshold tau = 0.3
    Described as a predefined empirical threshold to prevent merging of distinct slices; no derivation or held-out validation is provided.
assumptions (5)
  • domain assumption LLMs can accurately reason about malicious intent from sufficiently focused code slices
    Motivated by the pilot study in Section 2, but the pilot uses the same model family and only measures FNR, not precision on benign code.
  • domain assumption Most malicious behaviors are implemented through a limited set of sensitive APIs
    Stated in Section 3.1 as drawn from prior works [21,22,30]; the completeness of the curated 2,147 built-in API list is assumed.
  • domain assumption Third-party library sensitivity can be determined from the immediate function body without transitive calls
    Section 3.1.1 explicitly restricts extraction to the immediate body to control cost; a wrapper whose dangerous behavior is hidden in a callee would be missed.
  • domain assumption Joern's Code Property Graph preserves enough language-agnostic structure for slicing across the five languages
    The slicing stage relies on Joern's CPG; any language-specific parsing gap directly reduces recall.
  • domain assumption The benchmark labels are reliable
    Multi-Lang-Bench mixes a peer-reviewed dataset (MalwareBench) with a manually reviewed set derived from SourceFinder; manual review is subjective and small (75-143 positives per language).

how reviews work

0 comments
Cite this review

Pith. "Pith review of MalTotal: Cost-Effective and Language-Agnostic Malicious Code Poisoning Detection for Millions of Repositories." pith.science (2026). https://pith.science/paper/NWLT2PS4

@misc{pith2026260803232,
  author       = {Pith},
  title        = {Pith review of: MalTotal: Cost-Effective and Language-Agnostic Malicious Code Poisoning Detection for Millions of Repositories},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/NWLT2PS4}},
  note         = {Machine review of arXiv:2608.03232}
}
abstract

The widespread adoption of open source software (OSS) has introduced significant security risks, with malicious code poisoning attacks increasingly targeting public package registries and open-source platforms. Existing detection approaches, including heuristic-, learning-, and LLM-based methods, suffer from language-specific designs, limited generalization, and high analysis costs, making them unsuitable for large-scale multi-language analysis. To address these challenges, we propose MalTotal, a scalable and cost-effective framework for language-agnostic malicious code detection. MalTotal leverages LLM-assisted semantic reasoning to identify sensitive APIs, perform hybrid semantic slicing, and reconstruct malicious behavior contexts while reducing analysis overhead. Our evaluations show that MalTotal outperforms 8 state-of-the-art baselines, achieving an average F1-score of 93.1% across 5 mainstream languages. Its hybrid slicing reduces LLM token consumption by 94.0%, lowering the analysis cost from \$86.25 to \$5.19 on 2,168 repositories. In a large-scale study of 120K GitHub repositories containing over 7.3 million files, MalTotal discovered 564 previously unknown malicious repositories across multiple languages at a total cost of \$338. These results demonstrate the effectiveness, scalability, and cost-efficiency of MalTotal in mitigating large-scale code poisoning attacks.

Figures

Figures reproduced from arXiv: 2608.03232 by the authors.

Figure 1
Figure 1. The workflow of MalTotal it provides a general indication of the significant computational and cost burden for large-scale deployment. These results underscore the critical importance of optimizing context granularity to ensure cost-effective and scalable large-scale deployment. Motivation and Insights. The results of this pilot study provide valuable insights that motivate the design of MalTotal. While LLMs demonst… view at source ↗
Figure 2
Figure 2. The partial prompt template used for LLM-based third-party API analysis across languages. [PITH_FULL_IMAGE:figures/full_fig_p008_2.png] view at source ↗
Figure 3
Figure 3. An example of malicious behavior context extraction using hybrid slicing on the CPG. It includes (1) [PITH_FULL_IMAGE:figures/full_fig_p010_3.png] view at source ↗
Figures from the paper (1 more)
Figure 4
Figure 4. Figure 4: The prompt template for LLM-based analysis. [PITH_FULL_IMAGE:figures/full_fig_p011_4.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

71 extracted references · 47 canonical work pages

  1. [1]

    Akamai Security Intelligence Group. 2024. XZ Utils Backdoor: Everything You Need to Know, and What You Can Do. https://www.akamai.com/blog/security-research/critical-linux-backdoor-xz-utils-discovered-what-to-know Accessed: 2025-07-12

    work page 2024

  2. [2]

    Alex Birsan. 2021. Dependency Confusion: How I Hacked Into Apple, Microsoft and Dozens of Other Companies. https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610 Accessed: 2026-01-30

    work page 2021

  3. [3]

    DataDog. 2024. GuardDog. https://github.com/DataDog/guarddog. Accessed: 2026-01-30

    work page 2024

  4. [4]

    DataDog. 2026. malicious-software-packages-dataset. https://github.com/DataDog/malicious-software-packages- dataset. Accessed: 2026-01-30

    work page 2026

  5. [5]

    DeepSeek-AI. 2024. DeepSeek-V3 Technical Report. arXiv:2412.19437 [cs.CL] https://arxiv.org/abs/2412.19437

    arXiv 2024

  6. [6]

    Ruian Duan, Omar Alrawi, Ranjita Pai Kasturi, Ryan Elder, Brendan Saltaformaggio, and Wenke Lee. 2021. Towards Measuring Supply Chain Attacks on Package Managers for Interpreted Languages. In28th Annual Network and Distributed System Security Symposium, NDSS. https://www.ndss-symposium.org/wp-content/uploads/ndss2021_1B- 1_23055_paper.pdf

    work page 2021

  7. [7]

    Shehan Edirimannage, Charitha Elvitigala, Asitha Kottahachchi Kankanamge Don, Wathsara Daluwatta, Primal Wijesekara, and Ibrahim Khalil. 2024. Developers Are Victims Too : A Comprehensive Analysis of The VS Code Extension Ecosystem.CoRRabs/2411.07479 (2024). arXiv:2411.07479 doi:10.48550/ARXIV.2411.07479

    arXiv doi:10.48550/arxiv.2411.07479 2024

  8. [8]

    Python Software Foundation. 2025. PyPI: The Python Package Index. https://pypi.org/ Accessed: 2026-01-30

    work page 2025

Show all 71 references
  1. [9]

    Laura French. 2025. Claude Agent Skills could be used to deploy malware, researchers say. https://www.scworld.com/ news/claude-agent-skills-could-be-used-to-deploy-malware-researchers-say. Accessed: 2026-01-30

    2025

  2. [10]

    Xingan Gao, Xiaobing Sun, Sicong Cao, Kaifeng Huang, Di Wu, Xiaolei Liu, Xingwei Lin, and Yang Xiang. 2025. MalGuard: Towards Real-Time, Accurate, and Actionable Detection of Malicious Packages in PyPI Ecosystem.CoRR abs/2506.14466 (2025). arXiv:2506.14466 doi:10.48550/ARXIV.2...

    2025 doi arXiv

  3. [11]

    Mohamed Ghobashy. 2025. Shiny tools, shallow checks: how the AI hype opens the door to malicious MCP servers. https://securelist.com/model-context-protocol-for-ai-integration-abused-in-supply-chain-attacks/117473/. Accessed: 2026-01-30

    2025

  4. [12]

    GitHub. 2024. Octoverse: AI leads Python to top language as the number of global developers surges. https: //github.blog/news-insights/octoverse/octoverse-2024/ Accessed: 2025-07-12

    2024

  5. [13]

    GitHub. 2025. CodeQL: Semantic Code Analysis Engine. https://codeql.github.com/. Accessed: 2026-01-30

    2025

  6. [14]

    Go. 2025. Go Standard Library. https://pkg.go.dev/std. Accessed: 2026-01-30

    2025

  7. [15]

    Gobbi and Johannes Kinder

    Matías F. Gobbi and Johannes Kinder. 2023. Poster: Using CodeQL to Detect Malware in npm. InProceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security, CCS 2023, Copenhagen, Denmark, November 26-30, 2023, Weizhi Meng, Christian Damsgaard Jensen, Cas ...

    2023

  8. [18]

    Rafiqul Islam, Md Zahidul Islam, Ryan H

    Sajal Halder, Michael Bewong, Arash Mahboubi, Yinhao Jiang, Md. Rafiqul Islam, Md Zahidul Islam, Ryan H. L. Ip, Muhammad Ejaz Ahmed, Gowri Sankar Ramachandran, and Muhammad Ali Babar. 2024. Malicious Package Detection using Metadata Information. InProceedings of the ACM on Web...

    2024

  9. [19]

    Hao He, Haoqin Yang, Philipp Burckhardt, Alexandros Kapravelos, Bogdan Vasilescu, and Christian Kästner. 2026. Six Million (Suspected) Fake Stars on GitHub: A Growing Spiral of Popularity Contests, Spam, and Malware. In International Conference on Software Engineering (ICSE). ...

    2026

  10. [20]

    Xinyi Hou, Yanjie Zhao, Shenao Wang, and Haoyu Wang. 2025. Model Context Protocol (MCP): Landscape, Security Threats, and Future Research Directions.CoRRabs/2503.23278 (2025). arXiv:2503.23278 doi:10.48550/ARXIV.2503.23278

    2025 doi arXiv

  11. [21]

    Cheng Huang, Nannan Wang, Ziyan Wang, Siqi Sun, Lingzi Li, Junren Chen, Qianchong Zhao, Jiaxuan Han, Zhen Yang, and Lei Shi. 2024. DONAPI: Malicious NPM Packages Detector using Behavior Sequence Knowledge Mapping. In33rd USENIX Security Symposium, USENIX Security 2024, Philade...

    2024

  12. [23]

    Nguyen, Claudio Di Sipio, and Davide Di Ruscio

    Motunrayo Ibiyo, Thinakone Louangdy, Phuong T. Nguyen, Claudio Di Sipio, and Davide Di Ruscio. 2025. Detecting Malicious Source Code in PyPI Packages with LLMs: Does RAG Come in Handy?CoRRabs/2504.13769 (2025). arXiv:2504.13769 doi:10.48550/ARXIV.2504.13769

    2025 doi arXiv

  13. [24]

    Java. 2025. Java API Specification. https://docs.oracle.com/javase/8/docs/api/overview-summary.html. Accessed: 2026-01-30

    2025

  14. [25]

    Joern. 2025. Code Property Graph Specification. https://cpg.joern.io/. Accessed: 2026-01-30

    2025

  15. [26]

    Joern. 2025. Joern: Open-source code analysis platform based on code property graphs. https://github.com/joernio/joern. Accessed: 2026-01-30

    2025

  16. [28]

    Piergiorgio Ladisa, Serena Elisa Ponta, Nicola Ronzoni, Matias Martinez, and Olivier Barais. 2023. On the Feasibility of Cross-Language Detection of Malicious Packages in npm and PyPI. InAnnual Computer Security Applications Conference, ACSAC 2023, Austin, TX, USA, December 4-...

    2023

  17. [29]

    Haoyang Li, Huan Gao, Zhiyuan Zhao, Zhiyu Lin, Junyu Gao, and Xuelong Li. 2025. LLMs Caught in the Crossfire: Malware Requests and Jailbreak Challenges.CoRRabs/2506.10022 (2025). arXiv:2506.10022 doi:10.48550/ARXIV.2506. 10022

    2025 doi arXiv

  18. [31]

    Wentao Liang, Xiang Ling, Jingzheng Wu, Tianyue Luo, and Yanjun Wu. 2023. A Needle is an Outlier in a Haystack: Hunting Malicious PyPI Packages with Code Clustering. In38th IEEE/ACM International Conference on Automated Software Engineering, ASE 2023, Luxembourg, September 11-...

    2023

  19. [32]

    Yue Liu, Chakkrit Tantithamthavorn, and Li Li. 2025. Protect Your Secrets: Understanding and Measuring Data Exposure in VSCode Extensions. In2025 IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER). 551–562. doi:10.1109/SANER64311.2025.00058

    2025

  20. [33]

    lyvd. 2022. bandit4mal. https://github.com/lyvd/bandit4mal. Accessed: 2026-01-30

    2022

  21. [34]

    Md Rayhanul Masud and Michalis Faloutsos. 2024. Unveiling A Hidden Risk: Exposing Educational but Malicious Repositories in GitHub.CoRRabs/2403.04419 (2024). arXiv:2403.04419 doi:10.48550/ARXIV.2403.04419

    2024 doi

  22. [35]

    Tanzir Mehedi, Chadni Islam, Gowri Sankar Ramachandran, and Raja Jurdak

    Sk. Tanzir Mehedi, Chadni Islam, Gowri Sankar Ramachandran, and Raja Jurdak. 2025. DySec: A Machine Learning-based Dynamic Analysis for Detecting Malicious Packages in PyPI Ecosystem.CoRRabs/2503.00324 (2025). arXiv:2503.00324 doi:10.48550/ARXIV.2503.00324

    2025 doi arXiv

  23. [36]

    Microsoft. 2024. ApplicationInspector. https://github.com/microsoft/ApplicationInspector. Accessed: 2026-01-30

    2024

  24. [37]

    Microsoft. 2024. OSSGadget. https://github.com/microsoft/OSSGadget. Accessed: 2026-01-30. , Vol. 1, No. 1, Article . Publication date: August 2026. MalTotal: Cost-Effective and Language-Agnostic Malicious Code Poisoning Detection... 23

    2024

  25. [38]

    Shradha Neupane, Grant Holmes, Elizabeth Wyss, Drew Davidson, and Lorenzo De Carli. 2023. Beyond Typosquatting: An In-depth Look at Package Confusion. In32nd USENIX Security Symposium (USENIX Security 23). USENIX Association, Anaheim, CA, 3439–3456. https://www.usenix.org/conf...

    2023

  26. [39]

    Node.js. 2025. Node.js Documentation. https://nodejs.org/docs/latest/api/. Accessed: 2026-01-30

    2025

  27. [40]

    NPM. 2025. NPM: The NodeJS Package Manager. https://www.npmjs.com/ Accessed: 2026-01-30

    2025

  28. [41]

    Marc Ohm, Henrik Plate, Arnold Sykosch, and Michael Meier. 2020. Backstabber’s Knife Collection: A Review of Open Source Software Supply Chain Attacks. InDetection of Intrusions and Malware, and Vulnerability Assessment - 17th International Conference, DIMV A 2020, Lisbon, Por...

    2020 doi

  29. [42]

    Marc Ohm and Charlene Stuke. 2023. SoK: Practical Detection of Software Supply Chain Attacks. InProceedings of the 18th International Conference on A vailability, Reliability and Security(Benevento, Italy)(ARES ’23). Association for Computing Machinery, New York, NY, USA, Arti...

    2023

  30. [43]

    PHP. 2025. PHP Function Reference. https://www.php.net/manual/en/funcref.php. Accessed: 2026-01-30

    2025

  31. [44]

    Python. 2025. Python Module Index. https://docs.python.org/3/py-modindex.html. Accessed: 2026-01-30

    2025

  32. [45]

    Papalexakis, and Michalis Faloutsos

    Md Omar Faruk Rokon, Risul Islam, Ahmad Darki, Evangelos E. Papalexakis, and Michalis Faloutsos. 2020. SourceFinder: Finding Malware Source-Code from Publicly Available Repositories in GitHub. In23rd International Symposium on Research in Attacks, Intrusions and Defenses (RAID...

    2020

  33. [46]

    Md Omar Faruk Rokon, Pei Yan, Risul Islam, and Michalis Faloutsos. 2021. Repo2Vec: A Comprehensive Embedding Approach for Determining Repository Similarity. InIEEE International Conference on Software Maintenance and Evolution, ICSME 2021, Luxembourg, September 27 - October 1,...

    2021

  34. [47]

    Haya Samaana, Diego Elias Costa, Emad Shihab, and Ahmad Abdellatif. 2025. A Machine Learning-Based Approach For Detecting Malicious PyPI Packages. InProceedings of the 40th ACM/SIGAPP Symposium on Applied Computing, SAC 2025, Catania International Airport, Catania, Italy, 31 M...

    2025

  35. [48]

    Simone Scalco, Ranindya Paramitha, Duc-Ly Vu, and Fabio Massacci. 2022. On the feasibility of detecting injections in malicious npm packages. InARES 2022: The 17th International Conference on A vailability, Reliability and Security, Vienna,Austria, August 23 - 26, 2022. ACM, 1...

    2022

  36. [49]

    David Schmotz, Sahar Abdelnabi, and Maksym Andriushchenko. 2025. Agent Skills Enable a New Class of Realistic and Trivially Simple Prompt Injections.CoRRabs/2510.26328 (2025). arXiv:2510.26328 doi:10.48550/ARXIV.2510.26328

    2025 doi

  37. [50]

    Adriana Sejfia and Max Schäfer. 2022. Practical Automated Detection of Malicious npm Packages. In44th IEEE/ACM 44th International Conference on Software Engineering, ICSE 2022, Pittsburgh, PA, USA, May 25-27, 2022. ACM, 1681–1692. doi:10.1145/3510003.3510104

    2022

  38. [51]

    Semgrep. 2025. Semgrep Registry. https://semgrep.dev/r. Accessed: 2026-01-30

    2025

  39. [52]

    Robert Simmons. 2025. Threat Actor Banana Squad Exploits GitHub Repos in New Campaign. https://www. reversinglabs.com/blog/threat-actor-banana-squad-exploits-github-repos-in-new-campaign Accessed: 2026-01-30

    2025

  40. [53]

    Socket Inc. [n. d.]. Socket: Secure your supply chain with zero trust open source. https://socket.dev/. Accessed: 2026-01-30

    2026

  41. [54]

    Sonatype. 2024. 2024 State of the Software Supply Chain. https://www.sonatype.com/state-of-the-software-supply- chain/Introduction Accessed: 2026-01-30

    2024

  42. [55]

    Xiaobing Sun, Xingan Gao, Sicong Cao, Lili Bo, Xiaoxue Wu, and Kaifeng Huang. 2024. 1+1>2: Integrating Deep Code Behaviors with Metadata Features for Malicious PyPI Package Detection. InProceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering...

    2024

  43. [56]

    Apiiro Team. 2025. Malicious Code Campaign: GitHub Repo Confusion Attack. https://apiiro.com/blog/malicious- code-campaign-github-repo-confusion-attack/ Accessed: 2026-01-30

    2025

  44. [57]

    FOSSA Team. 2022. Understanding and Preventing Dependency Confusion Attacks. https://fossa.com/blog/ dependency-confusion-understanding-preventing-attacks/ Accessed: 2026-01-30

    2022

  45. [58]

    SafeDep Team. 2026. Agent Skills Threat Model. https://safedep.io/agent-skills-threat-model/. Accessed: 2026-01-30

    2026

  46. [59]

    Sonatype Security Research Team. 2025. Open Source Malware Index Q1 2025: Data exfil threats rising sharply. https://www.sonatype.com/blog/open-source-malware-index-q1-2025 Accessed: 2026-01-30

    2025

  47. [60]

    Michal Tereszkowski-Kaminski, Santanu Kumar Dash, and Guillermo Suarez-Tangil. 2024. A Study of Malicious Source Code Reuse Among GitHub, StackOverflow and Underground Forums. InComputer Security - ESORICS 2024 - 29th European Symposium on Research in Computer Security, Bydgos...

    2024 doi

  48. [61]

    Duc-Ly Vu, Zachary Newman, and John Speed Meyers. 2023. Bad Snakes: Understanding and Improving Python Package Index Malware Scanning. In2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE). 499–511. doi:10.1109/ICSE48619.2023.00052

    2023

  49. [62]

    Jian Wang, Zhen Li, Jixiang Qu, Deqing Zou, Shouhuai Xu, Ziteng Xu, Zhenwei Wang, and Hai Jin. 2025. MalPacDetector: An LLM-Based Malicious NPM Package Detector.IEEE Trans. Inf. Forensics Secur.20 (2025), 6279–6291. doi:10.1109/ TIFS.2025.3580336

    2025

  50. [63]

    Yayi Wang, Shenao Wang, Jian Zhao, Shaosen Shi, Ting Li, Yan Cheng, Lizhong Bian, Kan Yu, Yanjie Zhao, and Haoyu Wang. 2026. YASA: Scalable Multi-Language Taint Analysis on the Unified AST at Ant Group.CoRRabs/2601.17390 (2026). arXiv:2601.17390 doi:10.48550/ARXIV.2601.17390

    2026 doi

  51. [65]

    Always Contribute Back

    Dominik Wermke, Jan H. Klemmer, Noah Wöhler, Juliane Schmüser, Harshini Sri Ramulu, Yasemin Acar, and Sascha Fahl. 2023. "Always Contribute Back": A Qualitative Study on Security Challenges of the Open Source Supply Chain. In2023 IEEE Symposium on Security and Privacy (SP). 15...

    2023

  52. [66]

    Wikipedia. 2025. XZ Utils backdoor. https://en.wikipedia.org/wiki/XZ_Utils_backdoor Accessed: 2025-07-12

    2025

  53. [67]

    Di Xue, Gang Zhao, Zhongqi Fan, Wei Li, Yahong Xu, Zhen Liu, Yin Liu, and Zhongliang Yuan. 2024. Poster: An Exploration of Large Language Models in Malicious Source Code Detection. InProceedings of the 2024 on ACM SIGSAC Conference on Computer and Communications Security, CCS ...

    2024

  54. [68]

    Zeliang Yu, Ming Wen, Xiaochen Guo, and Hai Jin. 2024. Maltracker: A Fine-Grained NPM Malware Tracker Copiloted by LLM-Enhanced Dataset. InProceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis, ISSTA 2024, Vienna, Austria, September 16-20...

    2024

  55. [69]

    Williams

    Nusrat Zahan, Philipp Burckhardt, Mikola Lysenko, Feross Aboukhadijeh, and Laurie A. Williams. 2025. Leveraging Large Language Models to Detect NPM Malicious Packages. In47th IEEE/ACM International Conference on Software Engineering, ICSE 2025, Ottawa, ON, Canada, April 26 - M...

    2025

  56. [70]

    Nusrat Zahan, Thomas Zimmermann, Patrice Godefroid, Brendan Murphy, Chandra Maddila, and Laurie Williams

  57. [71]

    Nguyen, and Davide Di Ruscio

    Muhammad Umar Zeshan, Phuong T. Nguyen, and Davide Di Ruscio. 2025. Are They a Silver Bullet? On the Ability of LLMs to Detect Malicious Code in PyPI Packages.SSRN(2025). https://ssrn.com/abstract=5220789 Accessed: 2025-07-12

    2025

  58. [72]

    Junan Zhang, Kaifeng Huang, Yiheng Huang, Bihuan Chen, Ruisi Wang, Chong Wang, and Xin Peng. 2025. Killing Two Birds with One Stone: Malicious Package Detection in NPM and PyPI using a Single Model of Malicious Behavior Sequence.ACM Trans. Softw. Eng. Methodol.34, 4, Article 1...

    2025 doi

  59. [74]

    Xinyi Zheng, Chen Wei, Shenao Wang, Yanjie Zhao, Peiming Gao, Yuanchao Zhang, Kailong Wang, and Haoyu Wang

  60. [75]

    Ruofan Zhu, Ganhao Chen, Wenbo Shen, Xiaofei Xie, and Rui Chang. 2025. My Model is Malware to You: Transforming AI Models into Malware by Abusing TensorFlow APIs. In2025 IEEE Symposium on Security and Privacy (SP). 486–503. doi:10.1109/SP61157.2025.00012

    2025

  61. [76]

    Markus Zimmermann, Cristian-Alexandru Staicu, Cam Tenny, and Michael Pradel. 2019. Small World with High Risks: A Study of Security Threats in the npm Ecosystem. In28th USENIX Security Symposium, USENIX Security 2019, Santa Clara, CA, USA, August 14-16, 2019, Nadia Heninger an...

    2019

  62. [2022]

    InProceedings of the 44th International Conference on Software Engineering: Software Engineering in Practice(Pittsburgh, Pennsylvania)(ICSE-SEIP ’22)

    What are weak links in the npm supply chain?. InProceedings of the 44th International Conference on Software Engineering: Software Engineering in Practice(Pittsburgh, Pennsylvania)(ICSE-SEIP ’22). Association for Computing Machinery, New York, NY, USA, 331–340. doi:10.1145/351...

  63. [2024]

    Towards Robust Detection of Open Source Software Supply Chain Poisoning Attacks in Industry Environments. InProceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering, ASE 2024, Sacramento, CA, USA, October 27 - November 1, 2024, Vladimir Filko...

    2024

Pith tools

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