Pith. sign in

REVIEW 3 major objections 5 minor 70 references

A Machine Learning-Based Approach For Detecting Malicious PyPI Packages

T0 review · 3 major / 5 minor · reviewed 2026-08-11 · deepseek-v4-flash

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

Pith's one-line read A stacking ensemble classifier using package metadata, code, and text vocabulary is shown to detect malicious PyPI packages with an F1 of 94.2%, and 90% on unseen typical packages.

desk verdict A plausible PyPI malware detector with a useful shared dataset, but the headline F1 is a macro average and the Packj-based text feature confounds the baseline comparison. read the letter →

arxiv 2412.05259 v1 pith:QXIRLM4E submitted 2024-12-06 cs.SE

Haya Samaana (1) , Diego Elias Costa (2) , Emad Shihab (2) , Ahmad Abdellatif (3) ((1) An Najah National University , Nablus , Palestine , (2) Concordia University , Montreal
show 6 more authors
Quebec Canada (3) University of Calgary Calgary Alberta Canada)
This is my paper · ORCID
classification cs.SE
keywords maliciouspackagessupplychainsecurityPyPIstackingensemblestaticanalysisvocabulary-baseddetectiontyposquatting
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

This paper sets out to show that a machine-learning classifier, built from static clues in a Python package's metadata, configuration files, source code, and the text of its suspicious code lines, can identify malicious PyPI packages as a whole package rather than as individual function calls. The authors report that a stacking ensemble of five base classifiers reaches an F1-score of 94.2 percent on a cross-validated set of 138 known malicious and 5,193 popular packages, and 90 percent on an unseen set of 143 new malicious and 397 typical packages. If these numbers hold, registry maintainers could run the classifier on every newly submitted package and triage the worst candidates for manual review, cutting down the manual workload that currently limits ecosystem vetting. The paper also claims its approach produces fewer false alerts than two widely used static-analysis tools, Bandit and Packj, on the sample it tested.

What carries the argument

The load-bearing mechanism is the vocabulary-based text feature. The authors use the Packj static-analysis report to extract lines of code that invoke sensitive APIs (read, open, connect, getattr, system, and others), enrich them with code from setup.py and any source files containing suspicious URLs, and feed the tokenized text to the classifier as a document. This lets the model learn the wording and combination of code rather than just the presence of boolean flags. Around this text feature, the model layers carefully crafted package-level indicators: a missing or invalid homepage, a missing or invalid author email, a setup.cfg that has been left at the minimal auto-generated configuration, mismatched license declarations across the classifier/field/file locations, the presence of install commands or suspicious URLs, and long strings typical of obfuscation. The stacking ensemble is the meta-classifier that combines Random Forest, Support Vector Machine, Decision Tree, Multilayer Perceptron, and Bernoulli Naive Bayes, and the paper reports that the synergy of all features plus text achieves the highest F1.

What would settle it

Take the 397 'typical' packages from the test set and subject each to deep manual inspection plus dynamic sandbox execution to check for malicious behavior. If more than a small percentage of them show malicious or unwanted activity, the classifier's assumed ground truth is wrong, and its test precision and F1 overestimate real-world performance. Similarly, the 5,193 popular training packages could be spot-checked the same way.

Watch

Extended reading notes

Core claim

The central claim is that a stacking ensemble classifier, using eight feature groups—two metadata features (valid homepage or repository, valid author email), two file-level features (minimum setup configuration, license mismatch), three code-level features (install command, suspicious URL, long string), and one text feature built from lines of code that call suspicious APIs such as getattr, connect, open, and read—can separate malicious PyPI packages from benign ones at package level. On the training set the stacking classifier achieves 98% precision and 91% recall (F1 94.2%), and on a held-out test set of 143 new malicious packages and 397 randomly selected typical packages it achieves 96% precision and 87% recall (F1 90%). The text vocabulary alone outperforms the other seven features combined (F1 89% versus 84%), and the full model recovers 105 of 143 malicious test packages while flagging no benign test packages. These results are presented as evidence that the approach generalizes from popular packages to the broader PyPI population.

Load-bearing premise

The paper assumes that all packages labeled 'benign' in both training and test sets genuinely contain no malicious code, even though it admits that newly published packages cannot be assumed benign; if any of the 397 typical test packages are actually malicious, the reported test precision and F1 of 90 percent are too optimistic.

Editorial extensions

If this is right

  • Registry maintainers could run the classifier on every new PyPI submission and send only the flagged packages to a human reviewer, making the weekly triage of roughly 1,800 versions feasible.
  • Because the model operates on static features, it can scale to the entire registry without the resource cost of dynamic analysis, and it alerts on whole packages, not just suspicious function calls.
  • The text vocabulary feature points reviewers to the specific code lines the model found suspicious, so a human can quickly verify the alert.
  • The approach's low false-positive rate on the tested benign packages suggests it could be deployed as an early filter before more expensive analysis methods are invoked.
  • The 38 erroneously classified malicious packages were mostly clones of popular packages with thin payloads, so augmenting the features with similarity or provenance signals could close that gap.

Reading between the lines

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

  • I infer that the license-mismatch feature, which the paper finds in 77% of malicious but only 1% of benign packages, could be used as a standalone high-precision pre-filter, leaving the ML model to adjudicate ambiguous cases.
  • If the core claim is correct, a multi-tier vetting pipeline combining this static classifier with subsequent dynamic analysis of only flagged packages would be cheaper and more accurate than either method alone.
  • The paper's own analysis leaves open that 'typical' PyPI packages may sometimes be malicious, so a practical deployment should follow up on the classifier's 'benign' verdicts with a low-cost dynamic probe to catch false negatives.
  • A natural test of the vocabulary hypothesis is to retrain on a newer malicious package collection and see whether the same token patterns still discriminate, or whether attackers shift vocabulary to evade the model.
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

3 major / 5 minor

Summary. The paper proposes a package-level machine learning pipeline for detecting malicious PyPI packages using metadata, file, code, and text features. The authors train six classifiers on 5,193 popular PyPI packages and 138 known malicious packages, evaluate them with stratified 10-fold cross-validation, and test the best stacking ensemble on 397 unverified 'typical' packages and 143 new malicious packages. They report a training F1-score of 94.2% and a test F1-score of 90%, and compare their approach against Bandit, Packj, and the method of Ohm et al. in terms of usefulness and detection coverage. The paper also releases a dataset and identifies important features such as suspicious APIs, URLs, license mismatches, and author/homepage validity.

Significance. If the reported performance reflects per-class detection accuracy, the approach would be a practical, package-level vetting aid for PyPI, complementing function-level scanners, and the released dataset could support further research. The authors should be credited for evaluating on a separate test set and for comparing with existing tools. However, the headline F1 is a macro-average that overstates malicious-class detection, and the text feature is derived from Packj, which is also a baseline in the usefulness comparison. These issues directly affect how the central claims should be interpreted and require attention before publication.

major comments (3)
  1. [Abstract and Section 5.1 (Tables 3 and 5)] The reported F1-scores of 94.2% (training) and 90% (test) are macro-averages over the benign and malicious classes, not the F1 for the malicious class that the paper claims to identify. In Table 3, the best stacking configuration shows a per-class malicious F1 of 88%. From the test confusion counts in Table 5 (105 true positives, 38 false negatives, 0 false positives among the 397 typical packages), the malicious-class precision is 100%, recall is 105/143 = 73.4%, and F1 is approximately 84.7%. Thus the abstract's statement 'F1-measure of 0.94 for identifying malicious packages' is inconsistent with the paper's own per-class numbers and overstates the detector's positive-class performance. The per-class metrics should be reported and used in the abstract and RQ1.
  2. [Section 4.2 and Section 5.3 (RQ3)] The text-related feature is constructed from Packj's static analysis report ('we rely on the generated static analysis report of the packj tool to construct a portion of text feature'), and Packj is one of the two baseline tools in the usefulness evaluation of RQ3. The model therefore ingests a key signal from the very tool it is claimed to outperform, which makes the RQ3 comparison circular. Section 7's threats-to-validity paragraph acknowledges reliance on Packj for feature extraction 'rather than drawing final conclusions' but does not address the baseline comparison. The authors should either re-run the RQ3 comparison with features that do not come from Packj, or explicitly frame the comparison as showing the added value of Packj-derived features rather than as a head-to-head against Packj.
  3. [Section 4.1 and Table 5] The 397 'typical' packages treated as benign in the test set are not verified as non-malicious, although Section 4.1 states that 'we cannot assume that other recently published packages are benign.' The test row reports zero false positives among these packages; if any of them are actually malicious, the reported precision and F1 overestimate the model's generalization. The authors should verify these labels with an independent malicious-package scanner or at least report the results under an alternative assumption (e.g., a small percentage of the typical packages being malicious) to quantify the sensitivity of the conclusion.
minor comments (5)
  1. [Table 5] The table reports test precision of 96% and recall of 87%, but these are macro-averages; the table should state this explicitly and include the per-class precision, recall, and F1 for both malignant and benign classes.
  2. [Figure 3] The figure content appears to have been replaced by a garbled path string ('/uni00000053/uni00000044/...'), making the figure unreadable in the submitted version; the plot should be regenerated and its axes and legend described in the caption.
  3. [Section 4.2] The sentence 'We found no correlation' after computing Pearson correlation does not report the correlation values or the significance threshold; including these values would improve reproducibility.
  4. [Section 5.3] The adaptation of Ohm et al.'s method to Python packages is not described in enough detail; specify which features were ported and how the intersection of the three classifiers was implemented on the PyPI dataset.
  5. [Section 6] There is a typo in 'For examaple' (should be 'For example') in the paragraph about libpesh-0.1.

Circularity Check

1 steps flagged · score 4.0 of 10

Partial evaluation circularity: the text feature is built from Packj's static-analysis output, and RQ3 then benchmarks the model against Packj.

  1. other [Section 4.2 (Text-related feature), Section 5.3 (RQ3)]
    "To avoid reinventing the wheel, we rely on the generated static analysis report of the packj tool [41] to construct a portion of text feature. ... In the first experiment, we utilized the above mentioned tools for the reasons specified in Section 2. ... we compared our approach with (1) two benchmarking tools: Bandit and Packj"

    The text-related feature, which the paper shows is the strongest feature family (Text alone yields F1 89% vs 84% without it), is constructed from Packj's static-analysis report. RQ3 then compares the resulting model against Packj as an external baseline. This makes the usefulness comparison non-independent: the model's input already contains the output of one of the baselines it is claimed to outperform. The RQ1 detection F1 is still measured against held-out malicious labels, so the central classification claim is not definitionally forced; the circularity is confined to the RQ3 comparison and is partial.

full rationale

The main classification pipeline is not circular: features are extracted from package artifacts and Packj's static report, labels come from the Ohm et al. corpus (malicious) and a popularity-based benign proxy, and RQ1's F1 is evaluated on held-out and external malicious packages with independent labels. The one genuine circularity is confined to RQ3's usefulness comparison. The paper constructs its text feature 'to avoid reinventing the wheel' from Packj's generated static-analysis report (Section 4.2), and then compares the resulting model against Packj as one of 'two benchmarking tools' (Section 5.3). Because the model's most important feature family already contains Packj's alert information, the RQ3 claim that the approach 'outperforms' Packj is not an independent benchmark result; it is a comparison of a system that has been given one baseline's output as input against that same baseline. This is a partial, evaluation-level circularity, not a definitional one: the RQ1 malicious-vs-benign F1 is not an identity with Packj's verdict, and the model also uses metadata, file, and code features. The paper's own construct-validity threat acknowledges the reliance on Packj but does not remove the circularity from the RQ3 comparison. No self-citation is load-bearing, and there is no imported uniqueness theorem. Score 4 reflects the partial nature: the central detection claim has independent content, while the usefulness comparison is compromised.

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

The central claim rests on the assumption that the selected benign packages are truly non-malicious, that the 397 typical test packages are benign without verification, and that Packj's static analysis provides a sound basis for the text feature. No new ontological entities are introduced.

free parameters (3)
  • long string threshold = 40 characters
    Chosen from prior work (Canali et al. 2011) to classify obfuscated strings; not fitted to this dataset but is a hand-set threshold.
  • tokenizer vocabulary size = not pinned (range 200-2000)
    Grid-searched hyperparameter; the paper lists the range but does not state the selected value in the final pipeline.
  • stacking meta-learner = not specified
    The final estimator of the stacking ensemble is not described, affecting exact reproduction.
assumptions (4)
  • domain assumption Popular packages are benign
    Training set uses top-5000 downloaded and top-dependent packages as safe; acknowledged in Section 4.1.
  • domain assumption Randomly selected typical packages are benign
    Test set of 397 packages treated as benign without content verification; Section 4.1 and 5.1.
  • domain assumption Packj's suspicious API report is a valid basis for the text feature
    The text feature is built from lines of code around Packj-flagged APIs; Section 4.2.
  • standard math ML algorithms and cross-validation provide unbiased estimates
    Standard supervised learning assumptions used without formal guarantees.

how reviews work

0 comments
Cite this review

Pith. "Pith review of A Machine Learning-Based Approach For Detecting Malicious PyPI Packages." pith.science (2026). https://pith.science/paper/QXIRLM4E

@misc{pith2026241205259,
  author       = {Pith},
  title        = {Pith review of: A Machine Learning-Based Approach For Detecting Malicious PyPI Packages},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/QXIRLM4E}},
  note         = {Machine review of arXiv:2412.05259}
}
read the original abstract

Background. In modern software development, the use of external libraries and packages is increasingly prevalent, streamlining the software development process and enabling developers to deploy feature-rich systems with little coding. While this reliance on reusing code offers substantial benefits, it also introduces serious risks for deployed software in the form of malicious packages - harmful and vulnerable code disguised as useful libraries. Aims. Popular ecosystems, such PyPI, receive thousands of new package contributions every week, and distinguishing safe contributions from harmful ones presents a significant challenge. There is a dire need for reliable methods to detect and address the presence of malicious packages in these environments. Method. To address these challenges, we propose a data-driven approach that uses machine learning and static analysis to examine the package's metadata, code, files, and textual characteristics to identify malicious packages. Results. In evaluations conducted within the PyPI ecosystem, we achieved an F1-measure of 0.94 for identifying malicious packages using a stacking ensemble classifier. Conclusions. This tool can be seamlessly integrated into package vetting pipelines and has the capability to flag entire packages, not just malicious function calls. This enhancement strengthens security measures and reduces the manual workload for developers and registry maintainers, thereby contributing to the overall integrity of the ecosystem.

Figures

Figures reproduced from arXiv: 2412.05259 by the authors.

Figure 1
Figure 1. The workflow for identifying malicious packages. [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. The permutation feature importance. applied to all features discussed in Section 4.2. We use permuta￾tion_importance function in the Scikit-learn library [42] to compute the feature importance values of the stacking classifier. Results: We find that the most important features are related to the following features: has suspicious url, has a licence, has a valid author email, has minimum configuration, has long strin… view at source ↗
Figure 3
Figure 3. The average number of alerts generated by bandit and packj tools from the whole package and setup.py file. [PITH_FULL_IMAGE:figures/full_fig_p009_3.png] view at source ↗
Figures from the paper (1 more)
Figure 4
Figure 4. Figure 4: The result of the intersection approach [ [PITH_FULL_IMAGE:figures/full_fig_p009_4.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

70 extracted references · 60 canonical work pages

  1. [1]

    (accessed: 23.07.2024). Bertusk. https://bertusk.medium.com/ discord-token-stealer-discovered-in-pypi-repository-e65ed9c3de06

    work page 2024

  2. [2]

    dateutil

    (accessed: 23.07.2024). dateutil. https://snyk.io/blog/ malicious-packages-found-to-be-typo-squatting-in-pypi/

    work page 2024

  3. [3]

    Libraries- the open source discovery service

    Accessed on 21/7/2024. Libraries- the open source discovery service. https: //libraries.io/

    work page 2024

  4. [4]

    Rabe Abdalkareem, Suhaib Mujahid, and Emad Shihab. 2020. A machine learning approach to improve the detection of ci skip commits. IEEE Transactions on Software Engineering (2020)

    work page 2020

  5. [5]

    Mahmoud Alfadel, Diego Elias Costa, and Emad Shihab. 2021. Empirical anal- ysis of security vulnerabilities in python packages. In 2021 IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER) . IEEE, 446–457

    work page 2021

  6. [6]

    André Altmann, Laura Toloşi, Oliver Sander, and Thomas Lengauer. 2010. Per- mutation importance: a corrected feature importance measure. Bioinformatics 26, 10 (2010), 1340–1347

    work page 2010

  7. [7]

    Anonymous. 2024. A Machine Learning-Based Approach For Detecting Malicious PYPI Packages | Zenodo. https://zenodo.org/records/13825064

    work page arXiv 2024

  8. [8]

    (accessed: 27.07.2024)

    bandit. (accessed: 27.07.2024). bandit. https://github.com/PyCQA/bandit

    work page 2024

Show all 70 references
  1. [9]

    (accessed: 20.07.2024)

    bandit4mal. (accessed: 20.07.2024). bandit4mal. https://github.com/lyvd/ bandit4mal

    2024

  2. [10]

    Victor R Basili, Lionel C Briand, and Walcélio L Melo. 1996. How reuse influences productivity in object-oriented systems. Commun. ACM 39, 10 (1996), 104–116

    1996

  3. [11]

    (accessed: 12.08.2024)

    bleepingcomputer. (accessed: 12.08.2024). cryptocur- rency. https://www.bleepingcomputer.com/news/security/ malicious-pypi-packages-hijack-dev-devices-to-mine-cryptocurrency/

    2024

  4. [12]

    Kenneth A Bollen and Kenney H Barb. 1981. Pearson’s r and coarsely categorized measures. American Sociological Review (1981), 232–239

    1981

  5. [13]

    (accessed: 20.07.2024)

    botaa3. (accessed: 20.07.2024). botaa3. https://blog.sonatype.com/ another-day-of-malware-malicious-botaa3-pypi-package

    2024

  6. [14]

    Davide Canali, Marco Cova, Giovanni Vigna, and Christopher Kruegel. 2011. Prophiler: a fast filter for the large-scale detection of malicious web pages. In Proceedings of the 20th international conference on World wide web . 197–206

    2011

  7. [15]

    Bodin Chinthanet, Brittany Reid, Christoph Treude, Markus Wagner, Raula Gaikovina Kula, Takashi Ishio, and Kenichi Matsumoto. 2021. What makes a good Node. js package? Investigating Users, Contributors, and Runnability. arXiv preprint arXiv:2106.12239 (2021). 9

    2021 arXiv

  8. [16]

    François Chollet et al. 2018. Keras: The python deep learning library.Astrophysics source code library (2018), ascl–1806

    2018

  9. [17]

    (accessed: 23.07.2024)

    colourama. (accessed: 23.07.2024). colourama. https://bertusk.medium.com/ cryptocurrency-clipboard-hijacker-discovered-in-pypi-repository-b66b8a534a8

    2024

  10. [18]

    Alexandre Decan, Tom Mens, and Eleni Constantinou. 2018. On the impact of security vulnerabilities in the npm package dependency network. In Proceedings of the 15th international conference on mining software repositories . 181–191

    2018

  11. [19]

    (accessed: 20.06.2024)

    domains. (accessed: 20.06.2024). domains. http://s3.amazonaws.com/alexa-static/ top-1m.csv.zip

    2024

  12. [21]

    Ruian Duan, Omar Alrawi, Ranjita Pai Kasturi, Ryan Elder, Brendan Saltaformag- gio, and Wenke Lee. 2020. Towards measuring supply chain attacks on package managers for interpreted languages. arXiv preprint arXiv:2002.01139 (2020)

    2020 arXiv

  13. [22]

    (accessed: 23.07.2024)

    encode32. (accessed: 23.07.2024). encode32. https://jfrog.com/blog/ jfrog-discloses-3-remote-access-trojans-in-pypi/

    2024

  14. [23]

    Kalil Garrett, Gabriel Ferreira, Limin Jia, Joshua Sunshine, and Christian Kästner

  15. [24]

    Mehdi Golzadeh, Alexandre Decan, Damien Legay, and Tom Mens. 2021. A ground-truth dataset and classification model for detecting bots in GitHub issue and PR comments. Journal of Systems and Software 175 (2021), 110911

    2021

  16. [25]

    Rebecca Elizabeth Grinter. 1996. Understanding dependencies: A study of the coordination challenges in software development . University of California, Irvine

    1996

  17. [26]

    Yacong Gu, Lingyun Ying, Yingyuan Pu, Xiao Hu, Huajun Chai, Ruimin Wang, Xing Gao, and Haixin Duan. 2023. Investigating package related security threats in software registries. In 2023 IEEE Symposium on Security and Privacy (SP) . IEEE, 1578–1595

    2023

  18. [27]

    Sajal Halder, Michael Bewong, Arash Mahboubi, Yinhao Jiang, Md Rafiqul Is- lam, Md Zahid Islam, Ryan HL Ip, Muhammad Ejaz Ahmed, Gowri Sankar Ra- machandran, and Muhammad Ali Babar. 2024. Malicious Package Detection using Metadata Information. In Proceedings of the ACM on Web ...

    2024

  19. [28]

    Yung-Tsung Hou, Yimeng Chang, Tsuhan Chen, Chi-Sung Laih, and Chia-Mei Chen. 2010. Malicious web content detection by machine learning. expert systems with applications 37, 1 (2010), 55–60

    2010

  20. [29]

    Berkay Kaplan and Jingyu Qian. 2021. A survey on common threats in npm and PyPI registries. In International Workshop on Deployable Machine Learning for Security Defense. Springer, 132–156

    2021

  21. [30]

    Byung-Ik Kim, Chae-Tae Im, and Hyun-Chul Jung. 2011. Suspicious malicious web site detection with strength analysis of a javascript obfuscation.International Journal of Advanced Science and Technology 26 (2011), 19–32

    2011

  22. [31]

    Piergiorgio Ladisa, Henrik Plate, Matias Martinez, and Olivier Barais. 2023. Sok: Taxonomy of attacks on open-source software supply chains. In 2023 IEEE Sym- posium on Security and Privacy (SP) . IEEE, 1509–1526

    2023

  23. [32]

    Genpei Liang, Xiangyu Zhou, Qingyu Wang, Yutong Du, and Cheng Huang. 2021. Malicious Packages Lurking in User-Friendly Python Package Index. In2021 IEEE 20th International Conference on Trust, Security and Privacy in Computing and Communications (TrustCom). IEEE, 606–613

    2021

  24. [33]

    (accessed: 20.07.2024)

    licenses. (accessed: 20.07.2024). licenses. https://blog.inedo.com/python/ python-package-licenses

    2024

  25. [34]

    (accessed: 1.08.2024)

    maloss. (accessed: 1.08.2024). maloss tool. https://github.com/osssanitizer/maloss

    2024

  26. [35]

    (accessed: 20.07.2024)

    malwarecheck. (accessed: 20.07.2024). malwarecheck. https://warehouse.pypa. io/development/malware-checks.html

    2024

  27. [36]

    Parastoo Mohagheghi, Reidar Conradi, Ole M Killi, and Henrik Schwarz. 2004. An empirical study of software reuse vs. defect-density and stability. In Proceedings. 26th International Conference on Software Engineering . IEEE, 282–291

    2004

  28. [37]

    Marc Ohm, Felix Boes, Christian Bungartz, and Michael Meier. 2022. On the Feasibility of Supervised Machine Learning for the Detection of Malicious Soft- ware Packages. In Proceedings of the 17th International Conference on A vailability, Reliability and Security. 1–10

    2022

  29. [38]

    Marc Ohm, Henrik Plate, Arnold Sykosch, and Michael Meier. 2020. Backstabber’s knife collection: A review of open source software supply chain attacks. In International Conference on Detection of Intrusions and Malware, and Vulnerability Assessment. Springer, 23–43

    2020

  30. [39]

    Marc Ohm, Arnold Sykosch, and Michael Meier. 2020. Towards detection of software supply chain attacks by forensic artifacts. In Proceedings of the 15th international conference on availability, reliability and security . 1–6

    2020

  31. [40]

    (accessed: 20.07.2024)

    OSSGadget. (accessed: 20.07.2024). OSSGadget. https://github.com/microsoft/ OSSGadget

    2024

  32. [41]

    (accessed: 20.07.2024)

    packj. (accessed: 20.07.2024). packj. https://github.com/ossillate-inc/packj

    2024

  33. [42]

    Fabian Pedregosa, Gaël Varoquaux, Alexandre Gramfort, Vincent Michel, Bertrand Thirion, Olivier Grisel, Mathieu Blondel, Peter Prettenhofer, Ron Weiss, Vincent Dubourg, et al . 2011. Scikit-learn: Machine learning in Python. the Journal of machine Learning research 12 (2011), ...

    2011

  34. [43]

    (accessed: 20.08.2024)

    pymafka. (accessed: 20.08.2024). pymafka. https://www.bleepingcomputer.com/news/security/ malicious-pypi-package-opens-backdoors-on-windows-linux-and-macs/

    2024

  35. [44]

    O’Reilly Media, Inc

    Kenneth Reitz and Tanya Schlusser. 2016. The Hitchhiker’s guide to Python: best practices for development. " O’Reilly Media, Inc. "

    2016

  36. [45]

    Konrad Rieck, Philipp Trinius, Carsten Willems, and Thorsten Holz. 2011. Auto- matic analysis of malware behavior using machine learning. Journal of computer security 19, 4 (2011), 639–668

    2011

  37. [46]

    Jukka Ruohonen, Kalle Hjerppe, and Kalle Rindell. 2021. A large-scale security- oriented static analysis of python packages in PyPI. In 2021 18th International Conference on Privacy, Security and Trust (PST) . IEEE, 1–10

    2021

  38. [47]

    Simone Scalco, Ranindya Paramitha, Duc-Ly Vu, and Fabio Massacci. 2022. On the feasibility of detecting injections in malicious npm packages. In Proceedings of the 17th International Conference on A vailability, Reliability and Security. 1–8

    2022

  39. [48]

    Adriana Sejfia and Max Schäfer. 2022. Practical Automated Detection of Malicious npm Packages. arXiv preprint arXiv:2202.13953 (2022)

    2022 arXiv

  40. [49]

    Matthew Taylor, Ruturaj K Vaidya, Drew Davidson, Lorenzo De Carli, and Vaibhav Rastogi. 2020. Spellbound: Defending against package typosquatting. arXiv preprint arXiv:2003.03471 (2020)

    2020 arXiv

  41. [50]

    (accessed: 12.07.2024)

    thehackernews. (accessed: 12.07.2024). stealing. https://thehackernews.com/ 2022/08/10-credential-stealing-python-libraries.html

    2024

  42. [51]

    Christoph Treude and Martin P Robillard. 2016. Augmenting API documentation with insights from stack overflow. In2016 IEEE/ACM 38th International Conference on Software Engineering (ICSE) . IEEE, 392–403

    2016

  43. [52]

    Nikolai Philipp Tschacher. 2016. Typosquatting in programming language package managers. Ph.D. Dissertation. Universität Hamburg, Fachbereich Informatik

    2016

  44. [53]

    Ruturaj K Vaidya, Lorenzo De Carli, Drew Davidson, and Vaibhav Rastogi

  45. [54]

    Hugo van Kemenade and Richard Si. 2022. hugovk/top-pypi-packages: Release 2022.08. https://doi.org/10.5281/zenodo.6947954

    2022 doi

  46. [55]

    arXiv preprint arXiv:1903.02613 (2019)

    Security issues in language-based software ecosystems. arXiv preprint arXiv:1903.02613 (2019)

    2019 arXiv

  47. [56]

    Duc-Ly Vu, Zachary Newman, and John Speed Meyers. 2022. A Bench- mark Comparison of Python Malware Detection Approaches. arXiv preprint arXiv:2209.13288 (2022)

    2022 arXiv

  48. [57]

    Duc-Ly Vu, Fabio Massacci, Ivan Pashchenko, Henrik Plate, and Antonino Sabetta

  49. [58]

    Duc Ly Vu, Ivan Pashchenko, Fabio Massacci, Henrik Plate, and Antonino Sabetta

  50. [59]

    Duc-Ly Vu, Ivan Pashchenko, Fabio Massacci, Henrik Plate, and Antonino Sabetta

  51. [60]

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

    2023

  52. [61]

    Wei Xu, Fangfang Zhang, and Sencun Zhu. 2012. The power of obfuscation techniques in malicious JavaScript code: A measurement study. In 2012 7th Inter- national Conference on Malicious and Unwanted Software . IEEE, 9–16

    2012

  53. [62]

    Wei Xu, Fangfang Zhang, and Sencun Zhu. 2013. Jstill: mostly static detection of obfuscated malicious javascript code. In Proceedings of the third ACM conference on Data and application security and privacy . 117–128

    2013

  54. [63]

    Nusrat Zahan, Thomas Zimmermann, Patrice Godefroid, Brendan Murphy, Chan- dra Maddila, and Laurie Williams. 2022. What are weak links in the NPM supply chain?. In 2022 IEEE/ACM 44th International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP) ...

    2022

  55. [64]

    In 2020 IEEE European Symposium on Security and Privacy Workshops (EuroS&PW)

    Typosquatting and combosquatting attacks on the python ecosystem. In 2020 IEEE European Symposium on Security and Privacy Workshops (EuroS&PW) . IEEE, 509–514

    2020

  56. [65]

    Weiwei Xu, Hao He, Kai Gao, and Minghui Zhou. 2023. Understanding and Remediating Open-Source License Incompatibilities in the PyPI Ecosystem.arXiv preprint arXiv:2308.05942 (2023)

    2023 arXiv

  57. [69]

    Junan Zhang, Kaifeng Huang, Bihuan Chen, Chong Wang, Zhenhao Tian, and Xin Peng. 2023. Malicious Package Detection in NPM and PyPI using a Single Model of Malicious Behavior Sequence. arXiv preprint arXiv:2309.02637 (2023)

    2023 arXiv

  58. [70]

    Markus Zimmermann, Cristian-Alexandru Staicu, Cam Tenny, and Michael Pradel

  59. [71]

    In 28th USENIX Security Symposium (USENIX Security 19)

    Small world with high risks: A study of security threats in the npm ecosystem. In 28th USENIX Security Symposium (USENIX Security 19) . 995–1010. 10

  60. [2019]

    In 2019 IEEE/ACM 41st International Conference on Software Engineering: New Ideas and Emerging Results (ICSE-NIER)

    Detecting suspicious package updates. In 2019 IEEE/ACM 41st International Conference on Software Engineering: New Ideas and Emerging Results (ICSE-NIER) . IEEE, 13–16

    2019

  61. [2020]

    In Proceedings of the 2020 ACM SIGSAC Conference on Computer and Communications Security

    Towards using source code repositories to identify software supply chain attacks. In Proceedings of the 2020 ACM SIGSAC Conference on Computer and Communications Security. 2093–2095

    2020

  62. [2021]

    In Proceedings of the 29th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering

    Lastpymile: identifying the discrepancy between sources and packages. In Proceedings of the 29th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering . 780–792

Pith tools

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