Pith. sign in

REVIEW 4 major objections 5 minor 3 cited by

MalGuard: Towards Real-Time, Accurate, and Actionable Detection of Malicious Packages in PyPI Ecosystem

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

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

Pith's one-line read By ranking API calls with graph centrality, a Random Forest reaches 99.6% precision and 98.4% recall on malicious PyPI packages.

desk verdict Useful real-world detection system, but the headline accuracy numbers are compromised by test-set leakage in feature selection and K tuning. read the letter →

arxiv 2506.14466 v1 pith:6MEDMRO2 submitted 2025-06-17 cs.CR

Xingan Gao , Xiaobing Sun , Sicong Cao , Kaifeng Huang , Di Wu , Xiaolei Liu , Xingwei Lin , Yang Xiang This is my paper
classification cs.CR
keywords maliciouspackagedetectionPyPIsupplychainsecurityAPIcallgraphcentralitysensitiveextractionLIMEexplainabilitylightweightmachinelearning
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

MalGuard is built on the claim that the hard part of malicious-package detection is not model choice but the feature set: a lightweight machine-learning model can match or beat far heavier language-model detectors if it is given a comprehensive set of sensitive APIs. The paper's proposal is to get that feature set automatically instead of by hand: build an API call graph for known malicious packages, rank each API by graph-centrality scores, take the top 500, and ask an LLM to prune harmless APIs and record the harmful uses each remaining API enables. On a merged benchmark of 9,664 malicious and 10,000 benign PyPI packages, this design reaches 99.6% precision and 98.4% recall, outperforming six baselines on precision by 0.5% to 33.2% and on recall by 1.8% to 22.1%. Because model training takes seconds rather than hours, the same pipeline can be rerun daily on newly uploaded packages; in a five-week scan of 64,348 new uploads it flagged 113 previously unknown malicious packages, 109 of which PyPI removed. A sympathetic reader is meant to take away that automated feature extraction plus a cheap model is a practical, explainable route to ecosystem-scale malware detection.

What carries the argument

The load-bearing mechanism is the centrality-ranked API call graph. For each known malicious package the paper builds a graph whose nodes are API calls and whose edges are invocation relationships, computes closeness, degree, Katz, and harmonic centrality for every node, adds 1 to every score so that APIs written in global scope without call edges are not zeroed out, and then averages scores across packages by API name. The top K APIs, with K=500 chosen as the default, become the candidate feature set; one LLM query per candidate API filters the set and creates a ground-truth dictionary of each retained API's plausible malicious uses. Feature values for detection are the same centrality scores computed within a target package, so the model learns not just whether a sensitive API appears but how central it is to the package's call structure, and LIME refers back to the dictionary to explain individual predictions.

What would settle it

Perform a strictly temporal replay: build the centrality feature set using only malicious packages whose upload date is before a cutoff, choose K on a validation slice from the same period, hold out all packages uploaded after the cutoff in 2024, and compare precision and recall against the reported 99.6% and 98.4%. A large drop would indicate that the reported numbers were inflated by test-aware feature selection; a small drop would confirm the claim.

Watch

Extended reading notes

Core claim

On the paper's own terms, the central discovery is that the bottleneck in detecting malicious PyPI packages is neither model capacity nor inference cost but the timely construction of a complete feature set, and that this bottleneck can be removed by treating the API call graph as a social network. MalGuard computes four centrality measures—closeness, degree, Katz, and harmonic—over the APIs of known malicious packages, averages each API's scores across samples, ranks by that average, and keeps the top 500 candidates; it then uses a general-purpose LLM to discard APIs that are only common utilities and to write down the potential malicious behaviors of those that remain. The resulting feature vector for a new package records centrality values of those APIs, and a Random Forest trained on such vectors yields 99.6% precision and 98.4% recall on the authors' benchmark, improving on six state-of-the-art baselines. The same model, combined with LIME's top-10 features, emits a human-readable report that names the file, line, function scope, and likely malicious purpose for each sensitive API, and this explainability is itself evaluated with a verification dataset and a 24-volunteer rating study. The authors also claim practical validity through 113 newly discovered malicious packages, 109 removed by PyPI.

Load-bearing premise

The whole comparison rests on the assumption that the automatically chosen API features and the K=500 cutoff were not tuned using the test set's labels; the paper extracts features from all malicious packages before the 80/20 split and selects K by test performance, and if that assumption fails the reported accuracy advantage is not an honest estimate of future performance.

Editorial extensions

If this is right

  • Ecosystem-scale monitoring becomes feasible because feature extraction, centrality computation, and training finish in minutes to hours, so a registry can rescan all new uploads daily.
  • Feature sets can be updated automatically as new malicious samples arrive, removing the multi-week manual analysis bottleneck that the paper measures at 21 person-hours for a 132-feature set.
  • Detection output becomes actionable: security administrators get file, line, scope, and a list of plausible malicious intents for each sensitive API, which can cut manual verification time.
  • One LLM consultation per sensitive API keeps deployment cost low relative to systems that invoke an LLM per package at detection time.
  • Because centrality-based features are not just binary presence, benign packages that casually touch a sensitive API are less likely to be false-flagged.

Reading between the lines

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

  • The method's dependence on known malicious packages for feature ranking means its sensitivity to brand-new attack techniques is inherited from the dataset and the LLM's prior; a temporal variant that derives features only from packages sampled before the test period would test how much of the reported accuracy survives this dependency.
  • The same centrality-ranking recipe likely transfers to other source-distribution ecosystems such as npm, RubyGems, and crates.io, since the paper notes that malicious APIs differ across platforms but the graph topology of attacks does not.
  • Replacing the LLM filtering step with a static, documentation-derived API risk list would directly test how much of MalGuard's accuracy comes from the LLM's prior rather than from graph centrality; the paper's ablation only compares with and without LLM filtering on one model.
  • The paper's own temporal experiment, where an XGBoost model's recall falls from 80.3% to 53.4% on 2024 samples, implies that the claimed daily-update cadence is not just a convenience but a necessity; the authors do not spell out an update policy.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 5 minor

Summary. The paper proposes MalGuard, a malicious package detection approach for PyPI that automatically extracts a sensitive API feature set via graph centrality analysis on API call graphs, filters and annotates the features using GPT-3.5-turbo, trains lightweight ML models (RF, XGBoost, SVM, MLP) on the resulting features, and uses LIME to produce explanations. The authors report that MalGuard improves precision by 0.5%–33.2% and recall by 1.8%–22.1% over six baselines, achieves 99.6% precision and 98.4% recall on a merged malicious/benign dataset, and identifies 113 previously unknown malicious packages among 64,348 newly uploaded PyPI packages, 109 of which were removed. The evaluation includes an ablation of the LLM filtering step, a hyperparameter sensitivity analysis, an adversarial robustness study, and a user study for the explanations.

Significance. If the reported results held under a clean evaluation protocol, MalGuard would be a valuable contribution: it is lightweight, is accompanied by a real-world deployment with confirmed takedowns, and the authors provide open-source artifacts via Zenodo. The automatic extraction of sensitive APIs via centrality analysis is a plausible way to reduce manual feature engineering, and the explainability component addresses a real need in the security-operations workflow. However, the central quantitative claims are currently compromised by test-set involvement in feature and hyperparameter selection, and the ablation and explanation evaluations are weaker than the text suggests. The real-world deployment part is a strength, but it alone does not validate the headline accuracy numbers.

major comments (4)
  1. [Section 4.2 and Section 5.1] Section 4.2 constructs the sensitive API feature set by aggregating centrality values across all malicious packages and selecting the top K, and this construction is performed before the 80/20 split described in Section 5.1; as a result, the test split contributes to the choice of the feature set, so the precision/recall numbers in Table 8 are not valid out-of-sample estimates. The paper should re-run the pipeline with feature extraction confined to the training split (or nested cross-validation) and report the held-out results, and should additionally report the ranking stability of the selected APIs across different training folds.
  2. [Section 5.4] The sensitivity analysis selects K by comparing model effectiveness on the test set and then adopts K=500 for all subsequent experiments, which is a second form of test-set selection. This invalidates the absolute numbers in the main comparison; K should be chosen on a validation set that is disjoint from the test set, and the test set should be used only once for the final evaluation.
  3. [Section 5.2 and Table 9] The ablation results do not support the claim that LLM filtering improves effectiveness generally: for RF and XGBoost, filtering lowers F1 for Closeness, Harmonic, and Degree centrality, and only Katz centrality benefits from filtering. The paper should either present the filtering benefit as centrality-specific or provide a principled justification for why the chosen combination (Katz + LLM filtering) is the appropriate default rather than an instance of test-set-driven model selection.
  4. [Section 5.3] The explanation verification dataset is generated by GPT-3.5-turbo, the same model used to build the Ground_Truth dataset that the LIME explanations are matched against, so the accuracy scores in Table 10 are partly self-referential. The manual verification step is not described in enough detail to rule out that the LLM's own outputs define the ground truth, and an independent expert-annotated benchmark should be used.
minor comments (5)
  1. [Section 2.3] The text states that three master's students spent over a week analyzing 9,664 packages, amounting to 21 person-hours; a week of three students' effort is far more than 21 hours, so the reported effort is inconsistent and should be clarified.
  2. [Section 5.4] The reference to 'Figure 2' for the hyperparameter sensitivity results should be 'Figure 3' (the RF effectiveness figure), since the current citation points to the LIME example output.
  3. [Throughout] There are several typos and inconsistent notations: 'GURADDOG' in Section 7, 'aetattr' in Table 6, 'promoting' for 'prompting' in Section 2.2, and 'cotained' in the Appendix prompt. The authors should proofread the manuscript carefully.
  4. [Section 5.1] The paper does not report a runtime comparison for the real-time claim in the main evaluation; a latency table for MalGuard and the baselines would support the title's real-time assertion.
  5. [Section 5.1 and Section 3] The evaluation does not include a simple frequency-based baseline (e.g., binary presence or count of the selected sensitive APIs without centrality weighting); such a baseline would help isolate the contribution of graph centrality to the reported effectiveness.

Circularity Check

3 steps flagged · score 6.0 of 10

Sensitive-API feature selection and K=500 are chosen using the full malicious dataset/test-set effectiveness before the reported train/test evaluation, and the explanation ground truth is generated by the same LLM used to build the explanations.

  1. fitted input called prediction [Section 4.2 (Sensitive API Extraction and Filter) and Section 5.1 (Effectiveness Evaluation)]
    "we aggregate the centrality values of APIs with the same name across all malicious packages. Specifically, we sum the centrality values of each API and then divide the total by the number of malicious packages to obtain an averaged centrality value for each API. This results in a comprehensive list of APIs with their corresponding averaged centrality values. We then rank the APIs based on their averaged centrality values and select the top K ( K=200,300,400,500 ) as the sensitive API feature set."

    The feature-set ranking is computed by averaging centrality values over the full 9,664-package malicious dataset before Section 5.1 introduces the random 80/20 train/test split. The 20% test malicious packages are therefore included in the averaging that determines which APIs become model features. The test labels are used, through the centrality ranking, to construct the model's input representation. The reported 99.6% precision and 98.4% recall, and the improvements over the baselines, are thus not an independent out-of-sample estimate: the feature set is partly fitted to the test set. The external PyPI confirmation in Section 5.6 is not affected by this split, but it does not validate the headline comparison.

  2. fitted input called prediction [Section 5.4 (Hyperparameter Sensitivity Analysis) and Section 5.1 evaluation]
    "as K increases, the model's effectiveness consistently improves across feature sets derived using four different centrality metrics. For instance, the F1 scores increase by 2%–7% when K is raised from 200 to 500, indicating that higher K values include more suspicious APIs in the feature set. These findings suggest that setting K=500 allows the feature set to capture the most comprehensive set of suspicious APIs. To ensure optimal model effectiveness, all subsequent experiments adopt K=500 as the default parameter setting."

    Section 5.4 reports effectiveness for K=200,300,400,500 and then fixes K=500 for all subsequent experiments on the basis of that effectiveness. No validation set is described in Section 5; the only data partition is the 80/20 train/test split of Section 5.1. Selecting the hyperparameter that maximizes the test-set metrics and then reporting those same test-set metrics as the method's effectiveness is test-set model selection. The headline precision/recall numbers are therefore the best of the tried K values rather than an unbiased evaluation of a fixed configuration, making the reported gains a selected optimum instead of a clean prediction.

1 more flagged steps
  1. other [Sections 4.2, 4.4, and 5.3 (Explainability Evaluation)]
    "we leveraged the language model to perform an analysis of possible malicious behaviors. The analysis results were saved in the format api_name: malicious_behavior, creating a Ground_Truth dataset for further reference. [...] we employed prompt engineering to query the GPT-3.5-turbo model, instructing it to generate malicious behavior analyses in a specified format for the selected packages. To mitigate the potential impact of hallucinations in the LLM on the experimental results, we further conducted manual verification of the model's outputs."

    The explanation outputs are produced by matching LIME-selected features against the GPT-3.5-turbo-generated Ground_Truth dataset (Section 4.4), and the verification dataset used to score those explanations is also generated by GPT-3.5-turbo (Section 5.3). The scoring standard is therefore generated by the same model family that supplies the content being scored. Manual verification is applied on both sides, which reduces but does not eliminate the self-referentiality of the explanation-accuracy claim: the evaluation compares LLM-generated behavior text with LLM-generated behavior text rather than with an independent external ground truth.

full rationale

MalGuard's detection pipeline is not circular at the level of the model itself: centrality values are computed from static API call graphs, labels come from externally curated datasets, and the real-world deployment found 113 packages, 109 of which were removed by PyPI. However, the central quantitative claim is not a clean out-of-sample result. The sensitive-API feature set is ranked over all malicious packages, including the later 20% test split, and K=500 is chosen on the basis of test-set effectiveness. Both steps use the predicted labels to fix the model's inputs, so the reported precision/recall improvements are partially fitted rather than predicted. In addition, the explainability evaluation compares LLM-generated explanations against an LLM-generated verification dataset, which is self-referential. These are concrete, quotable reductions of the reported results to the data used to produce them, justifying a partial-circularity score.

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

The pipeline introduces no new physical entities. Its free parameters are the feature-set size K, the centrality metric, the +1 centrality offset, the LIME top-feature count, and the LLM filter judgment; all are chosen from data or by the model without an independent validation set.

free parameters (5)
  • K (number of top centrality APIs) = 500
    Selected because F1 improved as K increased from 200 to 500 on the evaluation set (Sec 5.4); no separate validation split.
  • Centrality metric = Katz (best in Table 9)
    The paper reports results for four centrality metrics and the headline numbers match the Katz-based RF model; no pre-registered choice or validation-based selection criterion provided.
  • Centrality offset = 1
    Added to avoid zero centrality values for APIs in packages where malicious code runs in global scope (Sec 4.1).
  • LIME top features = 10
    Chosen as the number of influential non-zero features to include in explanations (Sec 4.4); not varied.
  • LLM filter judgment = null
    GPT-3.5-turbo decides whether an API is potentially malicious; the threshold is the LLM's judgment, not a numeric parameter.
assumptions (4)
  • domain assumption API call graph centrality distributions of Python packages resemble those of Android malware and social networks, making centrality a valid feature signal.
    Sec 3.1 motivates centrality by analogy to Android malware detection and claims similar power-law and community structure without testing on PyPI.
  • domain assumption Static AST extraction captures all API calls relevant to malicious behavior.
    Used in Step 1 (Sec 4.1) to build API call graphs; no dynamic analysis or handling of obfuscated or binary code.
  • domain assumption The malicious labels in the Guo et al. and Sun et al. datasets are correct, and popular packages (>90 days, >1000 downloads) are a valid benign proxy.
    Sec 2.1 constructs the training and evaluation data from these assumptions.
  • domain assumption The LLM's API filtering and malicious-behavior mapping are accurate enough for feature set construction and explanation ground truth.
    Sec 4.2 uses GPT-3.5-turbo to retain or remove APIs and to create the API-to-malicious-behavior ground truth; manual verification is mentioned but not detailed.

how reviews work

0 comments
Cite this review

Pith. "Pith review of MalGuard: Towards Real-Time, Accurate, and Actionable Detection of Malicious Packages in PyPI Ecosystem." pith.science (2026). https://pith.science/paper/6MEDMRO2

@misc{pith2026250614466,
  author       = {Pith},
  title        = {Pith review of: MalGuard: Towards Real-Time, Accurate, and Actionable Detection of Malicious Packages in PyPI Ecosystem},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/6MEDMRO2}},
  note         = {Machine review of arXiv:2506.14466}
}
read the original abstract

Malicious package detection has become a critical task in ensuring the security and stability of the PyPI. Existing detection approaches have focused on advancing model selection, evolving from traditional machine learning (ML) models to large language models (LLMs). However, as the complexity of the model increases, the time consumption also increases, which raises the question of whether a lightweight model achieves effective detection. Through empirical research, we demonstrate that collecting a sufficiently comprehensive feature set enables even traditional ML models to achieve outstanding performance. However, with the continuous emergence of new malicious packages, considerable human and material resources are required for feature analysis. Also, traditional ML model-based approaches lack of explainability to malicious packages.Therefore, we propose a novel approach MalGuard based on graph centrality analysis and the LIME (Local Interpretable Model-agnostic Explanations) algorithm to detect malicious packages.To overcome the above two challenges, we leverage graph centrality analysis to extract sensitive APIs automatically to replace manual analysis. To understand the sensitive APIs, we further refine the feature set using LLM and integrate the LIME algorithm with ML models to provide explanations for malicious packages. We evaluated MalGuard against six SOTA baselines with the same settings. Experimental results show that our proposed MalGuard, improves precision by 0.5%-33.2% and recall by 1.8%-22.1%. With MalGuard, we successfully identified 113 previously unknown malicious packages from a pool of 64,348 newly-uploaded packages over a five-week period, and 109 out of them have been removed by the PyPI official.

Figures

Figures reproduced from arXiv: 2506.14466 by the authors.

Figure 1
Figure 1. MALGUARD architecture. Where N is the total number of nodes in the graph, deg(v) represents the degree of the node v (i.e., the number of edges connected to node v) and N is the total number of nodes in the graph. Katz centrality. Katz centrality measures a node’s influ￾ence by considering both the immediate neighbors and the neighbors further away, applying a weighting factor to penal￾ize more distant connections. … view at source ↗
Figure 2
Figure 2. The explanation output result of malicious package [PITH_FULL_IMAGE:figures/full_fig_p008_2.png] view at source ↗
Figure 3
Figure 3. The effectiveness of the Random Forest (RF) model [PITH_FULL_IMAGE:figures/full_fig_p009_3.png] view at source ↗
Figures from the paper (2 more)
Figure 4
Figure 4. Figure 4: Box plot analysis of the average score of 100 mali [PITH_FULL_IMAGE:figures/full_fig_p012_4.png]
Figure 5
Figure 5. Figure 5: Model robustness against adversarial attacks. gory of attacks, we observed that the strategy of replacing all non-zero feature values with 1 led to only a slight drop in effectiveness. This is expected, as the transformation does not alter the underlying API invocation…

Discussion (0). Sign in to comment.

Forward citations

Cited by 3 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

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

    cs.CR 2026-08 conditional novelty 6.0 of 10

    MalTotal combines LLM-based sensitive API discovery, code slicing, and LLM judgment to detect malicious repositories across five languages with an average F1 of 93.1% at low cost per scan.

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

    cs.CR 2026-07 conditional novelty 5.5 of 10

    H2GLM combines LLM-inferred function roles with hierarchical heterogeneous GNN message passing to detect and localize malicious Python packages more accurately than prior ML, graph, and LLM baselines.

  3. An Evaluation of Large Language Models for Detection of Malicious Python Packages

    cs.CR 2026-02 conditional novelty 5.0 of 10

    LLMs detect malicious PyPI packages reasonably at package level but identify specific malicious code indicators poorly, a 'granularity gap' that limits them to triage.

Reference graph

Works this paper leans on

53 extracted references · 50 canonical work pages · cited by 3 Pith papers

  1. [1]

    https://www.sonatype.com/state-of-the-sof tware-supply-chain/2024/scale

    10th annual state of the software supply chain, 2024. https://www.sonatype.com/state-of-the-sof tware-supply-chain/2024/scale

    work page 2024

  2. [2]

    Pypi index, 2024.https://pypi.org/

    work page 2024

  3. [3]

    Pypi simple, 2024.https://pypi.org/simple/

    work page 2024

  4. [4]

    https://www.tiobe.com/tiob e-index/

    Tiobe index, 2024. https://www.tiobe.com/tiob e-index/

    work page 2024

  5. [5]

    Oss gadget: Collection of tools for analyzing open source packages., 2020

    Bertus. Oss gadget: Collection of tools for analyzing open source packages., 2020. https://github.com /microsoft/OSSGadget

    work page 2020

  6. [6]

    Oddfuzz: Discovering java deserialization vulnerabilities via structure-aware directed greybox fuzzing

    Sicong Cao, Biao He, Xiaobing Sun, Yu Ouyang, Chao Zhang, Xiaoxue Wu, Ting Su, Lili Bo, Bin Li, Chuan- lei Ma, Jiajia Li, and Tao Wei. Oddfuzz: Discovering java deserialization vulnerabilities via structure-aware directed greybox fuzzing. InProceedings of the 44th IEEE Symposium on Security and Privacy (SP), pages 2726–2743. IEEE, 2023

    work page 2023

  7. [7]

    Sicong Cao, Xiaobing Sun, Lili Bo, Ying Wei, and Bin Li.BGNN4VD: Constructing bidirectional graph neural- network for vulnerability detection.Inf. Softw. Technol., 136:106576, 2021

    work page 2021

  8. [8]

    MVD: memory-related vulner- ability detection based on flow-sensitive graph neural networks

    Sicong Cao, Xiaobing Sun, Lili Bo, Rongxin Wu, Bin Li, and Chuanqi Tao. MVD: memory-related vulner- ability detection based on flow-sensitive graph neural networks. InProceedings of the 44th IEEE/ACM Inter- national Conference on Software Engineering (ICSE), pages 1456–1468. ACM, 2022

    work page 2022

Show all 53 references
  1. [9]

    A systematic literature re- view on explainability for machine/deep learning-based software engineering research.arXiv preprint arXiv: 2401.14617, 2024

    Sicong Cao, Xiaobing Sun, Ratnadira Widyasari, David Lo, Xiaoxue Wu, Lili Bo, Jiale Zhang, Bin Li, Wei Liu, Di Wu, and Yixin Chen. A systematic literature re- view on explainability for machine/deep learning-based software engineering research.arXiv preprint arXiv: 2401.14617, 2024

    2024 arXiv

  2. [10]

    Coca: Improving and explain- ing graph neural network-based vulnerability detection systems

    Sicong Cao, Xiaobing Sun, Xiaoxue Wu, David Lo, Lili Bo, Bin Li, and Wei Liu. Coca: Improving and explain- ing graph neural network-based vulnerability detection systems. InProceedings of the 46th IEEE/ACM Inter- national Conference on Software Engineering (ICSE), pages 155:1–...

    2024

  3. [11]

    Xgboost: A scal- able tree boosting system

    Tianqi Chen and Carlos Guestrin. Xgboost: A scal- able tree boosting system. In Balaji Krishnapuram, Mohak Shah, Alexander J. Smola, Charu C. Aggarwal, Dou Shen, and Rajeev Rastogi, editors,Proceedings of the 22nd ACM SIGKDD International Conference on Knowledge Discovery and ...

    2016

  4. [12]

    Pypi mirror of alibaba company, 2024

    Alibaba company. Pypi mirror of alibaba company, 2024. https://mirrors.aliyun.com/pypi/simple/

    2024

  5. [13]

    Pypi mirror of huawei company, 2024

    Huawei company. Pypi mirror of huawei company, 2024. https://mirrors.huaweicloud.com/repository /pypi/simple/

    2024

  6. [14]

    Pypi mirror of tencent company, 2024

    Tencent company. Pypi mirror of tencent company, 2024. https://mirrors.cloud.tencent.com/pypi/sim ple

    2024

  7. [15]

    Analyse suspicious files, do- mains, ips and urls to detect malware and other breaches, automatically share them with the security community,

    VirusTOTAL company. Analyse suspicious files, do- mains, ips and urls to detect malware and other breaches, automatically share them with the security community,

  8. [16]

    Guarddog, 2024

    DataDog. Guarddog, 2024. https://github.com/D ataDog/guarddog

    2024

  9. [17]

    BERT: pre-training of deep bidirec- tional transformers for language understanding

    Jacob Devlin, Ming-Wei Chang, Kenton Lee, and Kristina Toutanova. BERT: pre-training of deep bidirec- tional transformers for language understanding. In Jill Burstein, Christy Doran, and Thamar Solorio, editors, Proceedings of the 2019 Conference of the North Amer- ican Chapte...

    2019

  10. [18]

    Pypi mirror of douban company, 2024

    douban. Pypi mirror of douban company, 2024. http: //pypi.doubanio.com/simple/

    2024

  11. [19]

    Towards measuring supply chain attacks on package managers for interpreted languages

    Ruian Duan, Omar Alrawi, Ranjita Pai Kasturi, Ryan El- der, Brendan Saltaformaggio, and Wenke Lee. Towards measuring supply chain attacks on package managers for interpreted languages. InProceedings of the 28th Annual Network and Distributed System Security Sym- posium (NDSS)....

    2021

  12. [20]

    PBDT: python backdoor detection model based on combined features.Secur

    Yong Fang, Mingyu Xie, and Cheng Huang. PBDT: python backdoor detection model based on combined features.Secur . Commun. Networks, 2021:9923234:1– 9923234:13, 2021

    2021

  13. [21]

    Centrality in social networks: Conceptual clarification.Social network: critical con- cepts in sociology

    Linton C Freeman et al. Centrality in social networks: Conceptual clarification.Social network: critical con- cepts in sociology. Londres: Routledge, 1:238–263, 2002

    2002

  14. [22]

    Anomalicious: Automated de- tection of anomalous and potentially malicious commits on github

    Danielle Gonzalez, Thomas Zimmermann, Patrice Gode- froid, and Max Schaefer. Anomalicious: Automated de- tection of anomalous and potentially malicious commits on github. In43rd IEEE/ACM International Confer- ence on Software Engineering: Software Engineering in Practice, ICSE...

    2021

  15. [23]

    An empirical study of mali- cious code in pypi ecosystem

    Wenbo Guo, Zhengzi Xu, Chengwei Liu, Cheng Huang, Yong Fang, and Yang Liu. An empirical study of mali- cious code in pypi ecosystem. InProceedings of the 38th IEEE/ACM International Conference on Automated Soft- ware Engineering (ASE), pages 166–177. IEEE, 2023

    2023

  16. [24]

    A new status index derived from sociometric analysis.Psychometrika, 18(1):39–43, 1953

    Leo Katz. A new status index derived from sociometric analysis.Psychometrika, 18(1):39–43, 1953

    1953

  17. [25]

    Juggling the gadgets: Binary-level code randomization using in- struction displacement

    Hyungjoon Koo and Michalis Polychronakis. Juggling the gadgets: Binary-level code randomization using in- struction displacement. InProceedings of the 11th ACM on Asia Conference on Computer and Communications Security, ASIA CCS ’16, page 23–34, New York, NY , USA, 2016. Assoc...

    2016

  18. [26]

    Adversar- ial examples on discrete sequences for beating whole- binary malware detection.CoRR, abs/1802.04528, 2018

    Felix Kreuk, Assi Barak, Shir Aviv-Reuven, Moran Baruch, Benny Pinkas, and Joseph Keshet. Adversar- ial examples on discrete sequences for beating whole- binary malware detection.CoRR, abs/1802.04528, 2018

    2018 arXiv

  19. [27]

    Malicious packages lurking in user-friendly python package index

    Genpei Liang, Xiangyu Zhou, Qingyu Wang, Yutong Du, and Cheng Huang. Malicious packages lurking in user-friendly python package index. In20th IEEE International Conference on Trust, Security and Privacy in Computing and Communications, TrustCom 2021, Shenyang, China, October 2...

    2021

  20. [28]

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

    Wentao Liang, Xiang Ling, Jingzheng Wu, Tianyue Luo, and Yanjun Wu. A needle is an outlier in a haystack: Hunting malicious pypi packages with code clustering. In38th IEEE/ACM International Conference on Auto- mated Software Engineering, ASE 2023, Luxembourg, September 11-15, ...

    2023

  21. [29]

    Harmony in the small-world.Physica A: Statistical Mechanics and its Applications, 285(3-4):539–546, 2000

    Massimo Marchiori and Vito Latora. Harmony in the small-world.Physica A: Statistical Mechanics and its Applications, 285(3-4):539–546, 2000

    2000

  22. [30]

    Chatgpt., 2024.https://chatgpt.com/

    OpenAI. Chatgpt., 2024.https://chatgpt.com/

    2024

  23. [31]

    Keromytis

    Vasilis Pappas, Michalis Polychronakis, and Angelos D. Keromytis. Smashing the gadgets: Hindering return- oriented programming using in-place code randomiza- tion. InIEEE Symposium on Security and Privacy, SP 2012, 21-23 May 2012, San Francisco, California, USA, pages 601–615....

    2012

  24. [32]

    Yang, Zachary DeVito, Martin Raison, Alykhan Tejani, Sasank Chil- amkurthy, Benoit Steiner, Lu Fang, Junjie Bai, and Soumith Chintala

    Adam Paszke, Sam Gross, Francisco Massa, Adam Lerer, James Bradbury, Gregory Chanan, Trevor Killeen, Zeming Lin, Natalia Gimelshein, Luca Antiga, Alban Desmaison, Andreas Köpf, Edward Z. Yang, Zachary DeVito, Martin Raison, Alykhan Tejani, Sasank Chil- amkurthy, Benoit Steiner...

    2019

  25. [33]

    2023 china software supply chain security analysis report, 2023

    Qi’anxin. 2023 china software supply chain security analysis report, 2023. https://www.qianxin.com/ threat/reportdetail?report_id=297

    2023

  26. [34]

    Pypi massive forged packet name attack, 2024

    Qi’anxin. Pypi massive forged packet name attack, 2024. https://mp.weixin.qq.com/s/VIThE0I5BkQBW6h IOubnkQ

    2024

  27. [35]

    Practical automated de- tection of malicious npm packages

    Adriana Sejfia and Max Schäfer. Practical automated de- tection of malicious npm packages. In44th IEEE/ACM 44th International Conference on Software Engineer- ing, ICSE 2022, Pittsburgh, PA, USA, May 25-27, 2022, pages 1681–1692. ACM, 2022

    2022

  28. [36]

    Russia-linked ’lumma’ crypto stealer now targets python devs, 2024

    Sonatype. Russia-linked ’lumma’ crypto stealer now targets python devs, 2024. https://www.sonatype.c om/blog/crytic-compilers-typosquats-known -crypto-library-drops-windows-trojan

    2024

  29. [37]

    1+1>2: Integrating deep code behaviors with metadata features for mali- cious pypi package detection

    Xiaobing Sun, Xingan Gao, Sicong Cao, Lili Bo, Xi- aoxue Wu, and Kaifeng Huang. 1+1>2: Integrating deep code behaviors with metadata features for mali- cious pypi package detection. InProceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering (...

    2024

  30. [38]

    Pypi mirror of tsinghua university,

    Tsinghua university. Pypi mirror of tsinghua university,

  31. [39]

    D.-L. Vu. A fork of bandit tool with patterns to identify- ing malicious python code., 2020. https://github.c om/lyvd/bandit4mal

    2020

  32. [40]

    https://pypi.tuna.tsinghua.edu.cn/simp le/

  33. [41]

    Bozhi Wu, Sen Chen, Cuiyun Gao, Lingling Fan, Yang Liu, Weiping Wen, and Michael R. Lyu. Why an android app is classified as malware: Toward malware classifica- tion interpretation.ACM Trans. Softw. Eng. Methodol., 30(2):21:1–21:29, 2021

    2021

  34. [42]

    Lastpymile: identifying the discrepancy between sources and packages

    Duc Ly Vu, Fabio Massacci, Ivan Pashchenko, Henrik Plate, and Antonino Sabetta. Lastpymile: identifying the discrepancy between sources and packages. In Diomidis Spinellis, Georgios Gousios, Marsha Chechik, and Mas- similiano Di Penta, editors,ESEC/FSE ’21: 29th ACM Joint Euro...

    2021

  35. [43]

    Mitigating adversarial effects through randomization.arXiv preprint arXiv:1711.01991, 2017

    Cihang Xie, Jianyu Wang, Zhishuai Zhang, Zhou Ren, and Alan Yuille. Mitigating adversarial effects through randomization.arXiv preprint arXiv:1711.01991, 2017

    2017 arXiv

  36. [44]

    Malscan: Fast market-wide mobile malware scanning by social-network centrality analy- sis

    Yueming Wu, Xiaodi Li, Deqing Zou, Wei Yang, Xin Zhang, and Hai Jin. Malscan: Fast market-wide mobile malware scanning by social-network centrality analy- sis. In34th IEEE/ACM International Conference on Automated Software Engineering, ASE 2019, San Diego, CA, USA, November 11...

    2019

  37. [45]

    Leveraging large language models to detect npm malicious pack- ages

    Nusrat Zahan, Philipp Burckhardt, Mikola Lysenko, Fer- oss Aboukhadijeh, and Laurie Williams. Leveraging large language models to detect npm malicious pack- ages. InProceedings of the 47th IEEE/ACM Inter- national Conference on Software Engineering (ICSE), pages 683–683. IEEE, 2025

    2025

  38. [46]

    Maltracker: A fine-grained NPM malware tracker copi- loted by llm-enhanced dataset

    Zeliang Yu, Ming Wen, Xiaochen Guo, and Hai Jin. Maltracker: A fine-grained NPM malware tracker copi- loted by llm-enhanced dataset. In Maria Christakis and Michael Pradel, editors,Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis, IS...

    2024

  39. [47]

    Cyber-guided deep neural network for malicious repository detection in github

    Yiming Zhang, Yujie Fan, Shifu Hou, Yanfang Ye, Xusheng Xiao, Pan Li, Chuan Shi, Liang Zhao, and Shouhuai Xu. Cyber-guided deep neural network for malicious repository detection in github. In Enhong Chen and Grigoris Antoniou, editors,2020 IEEE Inter- national Conference on Kn...

    2020

  40. [48]

    Killing two birds with one stone: Malicious package detection in npm and pypi using a single model of malicious be- havior sequence.ACM Trans

    Junnan Zhang, Kaifeng Huang, Yiheng Huang, Bihuan Chen, Ruisi Wang, Chong Wang, and Xin Peng. Killing two birds with one stone: Malicious package detection in npm and pypi using a single model of malicious be- havior sequence.ACM Trans. Softw. Eng. Methodol., 34(4):104:1–104:28, 2025

    2025

  41. [49]

    Pycomm: Malicious com- mands detection model for python scripts.J

    Anmin Zhou, Tianyi Huang, Cheng Huang, Dunhan Li, and Chuangchuang Song. Pycomm: Malicious com- mands detection model for python scripts.J. Intell. Fuzzy Syst., 42(3):2261–2273, 2022

    2022

  42. [50]

    Fighting fire with fire: Continuous attack for adversarial android malware detection

    Yinyuan Zhang, Cuiying Gao, Yueming Wu, Shihan Dou, Cong Wu, Ying Zhang, Wei Yuan, and Yang Liu. Fighting fire with fire: Continuous attack for adversarial android malware detection

  43. [51]

    is_malicious

    Deqing Zou, Yueming Wu, Siru Yang, Anki Chauhan, Wei Yang, Jiangying Zhong, Shihan Dou, and Hai Jin. Intdroid: Android malware detection based on API in- timacy analysis.ACM Trans. Softw. Eng. Methodol., 30(3):39:1–39:32, 2021. Appendix A LLM Prompts for Malicious Analysis Her...

    2021

  44. [52]

    Large language model for vulnerability detection and repair: Literature review and the road ahead.ACM Trans

    Xin Zhou, Sicong Cao, Xiaobing Sun, and David Lo. Large language model for vulnerability detection and repair: Literature review and the road ahead.ACM Trans. Softw. Eng. Methodol., 34(5):145:1–145:31, 2025

    2025

  45. [2024]

    https://www.virustotal.com/gui/home/up load

Pith tools

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