Pith. sign in

REVIEW 5 major objections 7 minor 58 references

A Study of Malware Prevention in Linux Distributions

T0 review · 5 major / 7 minor · reviewed 2026-08-12 · deepseek-v4-flash

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

Pith's one-line read Current open-source malware scanners are inadequate for Linux distribution packages, with none achieving detection rates above 70% in a new benchmark built from Wolfi OS packages.

desk verdict The interview findings are genuinely useful, but the paper's headline claim that no scanner beats 70% is contradicted by its own tables and the quantitative evaluation needs a full re-do before I'd trust it. read the letter →

arxiv 2411.11017 v3 pith:QPJ3CWW5 submitted 2024-11-17 cs.CR cs.SE

Duc-Ly Vu , Trevor Dunlap , Karla Obermeier-Velazquez , Thanh-Cong Nguyen , Paul Gibert , John Speed Meyers , Santiago Torres-Arias This is my paper · ORCID
classification cs.CRcs.SE
keywords LinuxmalwaresoftwaresupplychainsecuritydetectionbenchmarkdistributionsWolfiOSAPKpackagesscannersXZUtilsbackdoor
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

Existing open-source malware detection tools are not ready to protect Linux distribution package repositories, according to this study. Interviews with maintainers from five major distributions show that most projects rely on reproducible builds and cryptographic signing, and only Wolfi OS actively scans packages for malware. The authors built six benchmark datasets of malicious and benign Linux packages, covering both source code and APK binaries, and evaluated six open-source scanners against them. None of the tools exceeded a 70% true positive rate, and most produced so many false positives that volunteer maintainers would be overwhelmed. The stakes are concrete: without better scanners, a backdoor like the XZ Utils compromise could enter major distributions undetected.

What carries the argument

The load-bearing mechanism is the benchmark dataset suite constructed by the authors. Starting from the Wolfi OS package set, the authors assume every package and upstream repository is benign ground truth, then build six malicious datasets: known malicious samples from the Backstabber's Knife Collection; those samples compiled into Wolfi APKs with the melange build tool; benign source projects injected with known malicious code snippets; those injected projects packaged as APKs; real Linux malware source code converted into APKs; and Go projects with Coldfire-based malware inserted into the middle of five-version histories. Each sample is scanned, and a tool counts as detecting malware if it produces at least one alert or, for VirusTotal, a malicious verdict. This single-threshold protocol produces the confusion matrices across all six datasets, and those matrices are what support the claim that no tool exceeds 70% detection.

What would settle it

Audit a random sample of the 1,866 Wolfi upstream repositories and 1,652 APKs with independent manual reverse engineering or a dynamic sandbox; finding malware in a non-trivial fraction would invalidate the reported false positive rates. Alternatively, rerun the evaluation on a hand-verified benign corpus from another distribution, such as Debian or Alpine, and check whether the tools' false positive rates match the ones reported here.

Watch

Extended reading notes

Core claim

The central discovery is that open-source malware scanners, as they exist today, cannot reliably distinguish malicious Linux packages from benign ones. The paper introduces the first benchmark suite for Linux package malware, consisting of six datasets: historical malicious source code from the Backstabber's Knife Collection; the same samples compiled into Wolfi APKs; synthetic source code with injected malicious snippets; synthetic malicious APKs; full-fledged Linux malware turned into APKs; and an over-time dataset of Go projects where only the middle version of each five-version history is malicious. These are paired with 1,866 benign Wolfi upstream repositories and 1,652 benign APKs. Scanning this collection with Bandit4Mal, Malcontent, ODB, Packj, VirusTotal, and Capslock yields a uniformly negative result: no tool reaches a 70% detection rate, most tools flag large fractions of benign packages as malicious, and differential version-diff analysis is noisy and low-precision. The paper concludes that current tools are unlikely to be adopted by distribution maintainers and need better rules, dynamic analysis, and tuning.

Load-bearing premise

The benchmark labels every Wolfi OS package and its upstream repository as benign without verifying it, so any actually malicious package in that set would inflate the measured false positive rates and distort the ground truth.

Editorial extensions

If this is right

  • Distribution maintainers should not rely on current open-source scanners as a gate before accepting packages, since the false positive volumes would overwhelm volunteer review.
  • Wolfi's Malcontent-based scanning, while pioneering, will also miss most real malware until its detection rules improve substantially.
  • The benchmark suite can serve as a reusable baseline for future scanners, and any tool that exceeds roughly 70% true positive at a tolerable false positive rate on these datasets would be a meaningful advance.
  • Differential scanning that compares alert sets between package versions does not yet reduce noise enough to be practically useful.
  • VirusTotal's relatively balanced performance suggests that aggregating many detection engines is more promising than any single open-source tool.

Reading between the lines

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

  • The benchmark's benign ground truth is the weakest link: if a non-trivial fraction of the 1,866 Wolfi packages are actually malicious, the reported false positive rates are inflated and the entire comparison shifts; a manual audit of a random sample would settle this.
  • The 'none above 70%' result likely underestimates real-world difficulty, because the malicious datasets are largely historical or synthetically injected and real malware can be obfuscated; a dynamic-analysis-based benchmark could be even harsher.
  • The authors' affiliation with Wolfi's maintainer raises a question the paper does not address: whether Malcontent would score differently if benchmarked by an independent team on a non-Wolfi benign corpus.
  • A natural extension is to evaluate commercial scanners against the same benchmark, since VirusTotal's aggregate beats all open-source tools and the paper's exclusion of closed-source scanners leaves that comparison open.
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

5 major / 7 minor

Summary. This paper examines malware prevention in Linux distribution package repositories through two studies: semi-structured interviews with seven maintainers from Alpine, Arch, Debian, Ubuntu, and Wolfi, and a benchmark evaluation of six open-source malware scanners (Bandit4Mal, Malcontent, ODB, Packj, VirusTotal, Capslock) on six newly constructed malicious datasets paired with benign Wolfi packages and repositories. The interviews find that most distributions rely on reproducible builds and cryptographic signing, with only Wolfi actively scanning packages using Malcontent. The scanner evaluation reports high false positive rates and generally low true positive rates, leading the authors to conclude that none of the evaluated tools achieved detection rates above 70% and that current tools are unlikely to be adopted by Linux distribution maintainers.

Significance. If the benchmark results were reliable, the paper would make a useful contribution: it is, to my knowledge, the first interview study of Linux distribution maintainers on proactive malware scanning, and it provides a Linux-package malware benchmark that spans source code and APK artifacts plus an over-time variant. The dataset design is thoughtful, and the authors explicitly document several threats to validity. However, the quantitative evaluation as currently presented is internally inconsistent and cannot support the headline conclusion; the paper therefore reads as a promising empirical study that currently needs substantial repair rather than as a completed result.

major comments (5)
  1. [Section 9, Tables 5 and 7] The central claim that 'none of the tools achieved detection rates above 70%' is contradicted by the paper's own confusion matrices: Table 5 reports VirusTotal with 22 true positives out of 30 malicious samples in Dataset #1 (73.3%) and ODB with 29 true positives (96.7%), and Table 7 reports VirusTotal with 22 true positives out of 30 in Dataset #2. Because no alternative definition of 'detection rate' is given, the conclusion is either false or unverifiable; the metric must be defined and reconciled with the tables.
  2. [Tables 5, 7, and 8] Several confusion matrices contain row sums that do not match the dataset sizes stated in Table 2. In Table 5, Bandit4Mal's malicious row sums to 10 rather than 30, and the benign rows sum to 891, 1856, 1775, 1183, and 1855 rather than the 1866 Wolfi upstream repositories. In Table 7, ODB's malicious row sums to 25 rather than 30 and its benign row sums to 1748 rather than 1866. In Table 8, ODB's malicious row sums to 28 rather than 30. These inconsistencies make the reported precision and recall values impossible to verify and suggest that failed analyses or mislabeled columns are being silently dropped.
  3. [Section 3.4] The detection threshold is not applied uniformly across tools: the stated default threshold is one alert, but for Malcontent only 'High' and 'Critical' alerts are considered while for the other scanners any alert appears to count. Because no severity threshold is reported for the other tools, the cross-tool comparisons in Tables 5-9 conflate raw alert counts with detection decisions and do not constitute a controlled comparison of detection capability.
  4. [Sections 3.3.1 and 8.1] The benign ground truth is load-bearing for all false-positive claims, yet Section 3.3.1 assumes all Wolfi packages and upstream repositories are benign and Section 8.1 acknowledges that this assumption has not been thoroughly validated. Since high false-positive rates are central to the conclusion that the tools are unsuitable, the paper needs either substantially stronger validation of the benign labels or a sensitivity analysis showing that plausible labeling errors do not change the conclusion.
  5. [Sections 3.2 and 3.3] The paper introduces six datasets as a contribution, but no dataset repository, artifact link, or evaluation script is provided. Given the arithmetic inconsistencies in the reported tables, independent verification is impossible; the authors should release the benchmark data and evaluation code, or at minimum the per-sample classification counts underlying every table.
minor comments (7)
  1. [Section 5, Table 4] Several table entries are incomplete, including ODB's mean being reported as 'value missing' and the Malcontent observation ending with '(statement incomplete)'; the table and surrounding text should be completed.
  2. [Section 3.4] The text '16 000Y ARA detection rules' should read '16,000 YARA detection rules'.
  3. [Section 1] The phrase 'these findings shed light on the shed light on a fundamental gap' contains a duplicated clause and should be rewritten.
  4. [Table 8] The table heading says 'Dataset #4 vs Malicious Wolfi APKs' where the surrounding text and the identical benign columns indicate it should say 'vs Benign Wolfi APKs'.
  5. [References] Reference [33] contains a stray 'wolfi os' in its title, and the URL formatting should be checked.
  6. [Section 9] The closing sentence 'Here is to hoping' is informal for a journal conclusion; consider 'Here is hoping' or a more formal rephrasing.
  7. [Figure 3] The caption does not define the 'combined dataset' used for the alert distribution; clarify whether it pools benign and malicious samples and justify that aggregation.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the empirical benchmark claims are grounded in independently constructed datasets and observed alert counts, not in fitted parameters or self-referential definitions.

full rationale

This paper is an empirical measurement study, not a derivation. The central claim—that existing open-source scanners underperform on Linux package malware—is supported by alert counts and confusion matrices obtained by running six tools over externally sourced malware samples and Wolfi packages. No parameter is fitted to a subset of data and then renamed a prediction; the detection threshold is a fixed, stated methodological choice (Section 5), not a fitted input. The benign-label assumption in Section 3.3.1 is explicitly acknowledged as unvalidated in Section 8.1, but it is a data-labeling caveat, not a definitional equivalence that forces the conclusion. The affiliation of several authors with Chainguard and the inclusion of Wolfi packages and the Malcontent tool from that ecosystem create a potential conflict of interest, but conflict alone is not circularity: the benchmark includes external malicious samples from the Backstabber's Knife Collection and other sources, and the reported results are empirical observations. Self-citations to prior work by the same authors (e.g., [23]) are used as related work and as a source of known malicious code snippets for constructing datasets; they do not serve as an unverified premise that determines the outcome. The internal arithmetic inconsistencies and the apparent conflict between the Section 9 statement that no tool exceeded 70% detection and the VirusTotal rows in Tables 5 and 7 are correctness and reproducibility concerns, not circularity. Accordingly, no load-bearing step reduces to its own inputs, and the circularity score is 0.

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

The benchmark datasets are constructed by the authors and not independently verified. The benign baseline relies on an untested assumption, and the evaluation parameters are chosen by the researchers rather than derived from theory. No new theoretical entities are introduced.

free parameters (3)
  • Alert threshold = 1
    The default detection threshold is set to one alert, meaning any sample triggering at least one alert is considered malicious. This is a chosen decision boundary that affects all evaluations and is not derived from data.
  • Malcontent severity filter = High/Critical
    The Malcontent analysis only considers 'High' and 'Critical' alerts, a hand-chosen severity cutoff that influences its precision and recall.
  • Dataset #6 injection position = Third version (v3m)
    Malware is injected into the middle version of each five-version project sequence, a design choice that may affect over-time detection results.
assumptions (4)
  • domain assumption All Wolfi packages and their upstream repositories are benign.
    Assumed in Section 3.3.1, acknowledged as unvalidated in Section 8.1. This is the negative class in all evaluations.
  • domain assumption The selected malicious samples from Backstabber's Knife Collection are representative of Linux package malware.
    Section 3.3.2, sampling bias is acknowledged in Section 8.1. The samples are historical and may not reflect current threats.
  • ad hoc to paper A detection threshold of one alert is an appropriate indicator of maliciousness.
    Section 5, the default threshold is set to one for all tools, which may not match each tool's intended usage or severity levels.
  • ad hoc to paper For Malcontent, only High and Critical alerts are meaningful.
    Section 3.4, 'The later analysis only considers the High and Critical alerts', a choice that may bias results for Malcontent.

how reviews work

0 comments
Cite this review

Pith. "Pith review of A Study of Malware Prevention in Linux Distributions." pith.science (2026). https://pith.science/paper/QPJ3CWW5

@misc{pith2026241111017,
  author       = {Pith},
  title        = {Pith review of: A Study of Malware Prevention in Linux Distributions},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/QPJ3CWW5}},
  note         = {Machine review of arXiv:2411.11017}
}
read the original abstract

Malicious attacks on open-source software packages are a growing concern. The discovery of the XZ Utils backdoor intensified these concerns because of the potential widespread impact. This study, therefore, explores the challenges of preventing and detecting malware in Linux distribution package repositories. To do so, we ask two research questions: (1) What measures have Linux distributions implemented to counter malware, and how have maintainers experienced these efforts? (2) How effective are current malware detection tools in identifying malicious Linux packages? To answer these questions, we conduct interviews with maintainers at several major Linux distributions and introduce a Linux package malware benchmark dataset. Using this dataset, we evaluate the performance of six open-source malware detection scanners. Distribution maintainers, according to the interviews, have mostly focused on reproducible builds to date. Our interviews identified only a single Linux distribution, Wolfi OS, that performs active malware scanning. Using this new benchmark dataset, the evaluation found that the performance of existing open-source malware scanners is underwhelming. Most studied tools excel at producing false positives but only infrequently detect true malware. Those that avoid high false positive rates often do so at the expense of a satisfactory true positive. Our findings provide insights into Linux distribution package repositories' current practices for malware detection and demonstrate the current inadequacy of open-source tools designed to detect malicious Linux packages.

Figures

Figures reproduced from arXiv: 2411.11017 by the authors.

Figure 1
Figure 1. Our Benchmarking of Malware Detection Tools [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. Construction of the “over time” dataset for a single [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. Distribution of alerts generated by the malware [PITH_FULL_IMAGE:figures/full_fig_p007_3.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

58 extracted references · 53 canonical work pages

  1. [1]

    Xz utils backdoor - everything you need to know, and what you can do

    A. S. I. Group, “Xz utils backdoor - everything you need to know, and what you can do.” https://www.akamai.com/blog/security-resea rch/critical-linux-backdoor-xz-utils-discovered-what-to-know, 2024, accessed: 2024-11-14

    work page 2024

  2. [2]

    What we know about the xz utils backdoor that almost infected the world,

    D. Goodin, “What we know about the xz utils backdoor that almost infected the world,” Apr. 2024. [Online]. Available: https://arstechnica.com/security/2024/04/what-we-know-about-the-x z-utils-backdoor-that-almost-infected-the-world/

    work page 2024

  3. [3]

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

    R. Duan, O. Alrawi, R. P. Kasturi, R. Elder, B. Saltaformaggio, and W. Lee, “Towards measuring supply chain attacks on package managers for interpreted languages,” in Proc. of NDSS’21 , 2021

    work page 2021

  4. [4]

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

    M. Ohm, H. Plate, A. Sykosch, and M. Meier, “Backstabber’s knife collection: A review of open source software supply chain attacks,” in International Conference on Detection of Intrusions and Malware, and Vulnerability Assessment. Springer, 2020, pp. 23–43

    2020

  5. [5]

    Ty- posquatting and combosquatting attacks on the python ecosystem,

    D.-L. Vu, I. Pashchenko, F. Massacci, H. Plate, and A. Sabetta, “Ty- posquatting and combosquatting attacks on the python ecosystem,” in 2020 IEEE European Symposium on Security and Privacy Workshops (EuroS&PW), 2020

    work page 2020

  6. [6]

    npm blog archive: kik, left-pad, and npm,

    I. Z. Schlueter, “npm blog archive: kik, left-pad, and npm,” Mar

    work page

  7. [7]

    A systematic analysis of the event-stream incident,

    I. Arvanitis, G. Ntousakis, S. Ioannidis, and N. Vasilakis, “A systematic analysis of the event-stream incident,” in Proceedings of the 15th European Workshop on Systems Security , ser. EuroSec ’22. New York, NY , USA: Association for Computing Machinery, 2022, p. 22–28. [Online]. Available: https://doi.org/10.1145/3517208.3523753

    work page arXiv 2022

  8. [8]

    The 5x5—the xz backdoor: Trust and open source software,

    N. Bansal and S. Scott, “The 5x5—the xz backdoor: Trust and open source software,” May 2024. [Online]. Available: https://dfrlab.org/2 024/05/01/the-5x5-the-xz-backdoor-trust-and-open-source-software/

    work page 2024

Show all 58 references
  1. [9]

    Reflections on trusting trust,

    K. Thompson, “Reflections on trusting trust,” Communications of the ACM, vol. 27, no. 8, pp. 761–763, 1984

    1984

  2. [10]

    Countering trusting trust through diverse double- compiling,

    D. A. Wheeler, “Countering trusting trust through diverse double- compiling,” in 21st Annual Computer Security Applications Confer- ence (ACSAC’05). IEEE, 2005, pp. 13–pp

    2005

  3. [11]

    Reproducible builds: Increasing the integrity of software supply chains,

    C. Lamb and S. Zacchiroli, “Reproducible builds: Increasing the integrity of software supply chains,” IEEE Software, vol. 39, no. 2, pp. 62–70, 2021

    2021

  4. [12]

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

    S. Torres-Arias, H. Afzali, T. K. Kuppusamy, R. Curtmola, and J. Cappos, “in-toto: Providing farm-to-table guarantees for bits and bytes,” in 28th USENIX Security Symposium (USENIX Security 19) , 2019, pp. 1393–1410

    2019

  5. [13]

    For good measure: Counting broken links: A quant’s view of software supply chain security,

    D. Geer, B. Tozer, and J. S. Meyers, “For good measure: Counting broken links: A quant’s view of software supply chain security,” USENIX; Login, vol. 45, no. 4, 2020

    2020

  6. [14]

    Cybersecurity: Federal response to solarwinds and microsoft exchange incidents — u.s. gao,

    U. S. G. A. Office, “Cybersecurity: Federal response to solarwinds and microsoft exchange incidents — u.s. gao,” Feb. 2022. [Online]. Available: https://www.gao.gov/products/gao-22-104746

    2022

  7. [15]

    Advanced persistent threat compromise of government agencies, critical infrastructure, and private sector organizations,

    CISA, “Advanced persistent threat compromise of government agencies, critical infrastructure, and private sector organizations,” Apr. 2021. [Online]. Available: https://www.cisa.gov/news-events/cy bersecurity-advisories/aa20-352a

    2021

  8. [16]

    S3c2 summit 2023-11: Industry secure supply chain summit,

    N. Zahan, Y . Acar, M. Cukier, W. Enck, C. K ¨astner, A. Kapravelos, D. Wermke, and L. Williams, “S3c2 summit 2023-11: Industry secure supply chain summit,” arXiv preprint arXiv:2408.16529 , 2024

    2023 arXiv

  9. [17]

    An empirical study on software bill of materials: Where we stand and the road ahead,

    B. Xia, T. Bi, Z. Xing, Q. Lu, and L. Zhu, “An empirical study on software bill of materials: Where we stand and the road ahead,” in 2023 IEEE/ACM 45th International Conference on Software Engi- neering (ICSE). IEEE, 2023, pp. 2630–2642

    2023

  10. [18]

    Software bills of materials are required. are we there yet?

    N. Zahan, E. Lin, M. Tamanna, W. Enck, and L. Williams, “Software bills of materials are required. are we there yet?” IEEE Security & Privacy, vol. 21, no. 2, pp. 82–88, 2023

    2023

  11. [19]

    Sigstore: Software signing for everybody,

    Z. Newman, J. S. Meyers, and S. Torres-Arias, “Sigstore: Software signing for everybody,” in Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security , 2022, pp. 2353–2367

    2022

  12. [20]

    Speranza: Usable, privacy-friendly software signing,

    K. Merrill, Z. Newman, S. Torres-Arias, and K. R. Sollins, “Speranza: Usable, privacy-friendly software signing,” in Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security, 2023, pp. 3388–3402

    2023

  13. [21]

    Supply-chain levels for software artifacts

    “Supply-chain levels for software artifacts.” [Online]. Available: https://slsa.dev/

  14. [22]

    Reflections on trusting docker: Invisible malware in continuous integration systems,

    F. Moriconi, A. I. Neergaard, L. Georget, S. Aubertin, and A. Francil- lon, “Reflections on trusting docker: Invisible malware in continuous integration systems,” in 2023 IEEE Security and Privacy Workshops (SPW). IEEE, 2023, pp. 219–227

    2023

  15. [23]

    Bad snakes: Understanding and improving python package index malware scanning,

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

    2023

  16. [24]

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

    M. Ohm, F. Boes, C. Bungartz, and M. Meier, “On the feasibility of supervised machine learning for the detection of malicious software packages,” in Proceedings of the 17th International Conference on Availability, Reliability and Security , 2022, pp. 1–10

    2022

  17. [25]

    Shifting the lens: Detecting malware in npm ecosystem with large language models,

    N. Zahan, P. Burckhardt, M. Lysenko, F. Aboukhadijeh, and L. Williams, “Shifting the lens: Detecting malware in npm ecosystem with large language models,” arXiv preprint arXiv:2403.12196, 2024

    2024 arXiv

  18. [26]

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

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

    2023

  19. [27]

    R. K. Yin, Qualitative research from start to finish . Guilford publications, 2015

    2015

  20. [28]

    Wolfi os,

    Chainguard, “Wolfi os,” 2024. [Online]. Available: https://github.c om/wolfi-dev/os

    2024

  21. [29]

    GitHub API Documentation,

    GitHub Inc., “GitHub API Documentation,” 2025. [Online]. Available: https://docs.github.com/en/rest

    2025

  22. [30]

    Malpacdetector: An llm-based malicious npm package detector,

    J. Wang, Z. Li, J. Qu, D. Zou, S. Xu, Z. Xu, Z. Wang, and H. Jin, “Malpacdetector: An llm-based malicious npm package detector,” IEEE Transactions on Information Forensics and Security , 2025

    2025

  23. [31]

    melange,

    Chainguard, “melange,” 2023, accessed: 2024-11-14. [Online]. Available: https://github.com/chainguard-dev/melange

    2023

  24. [32]

    Linux malware,

    Timb Machine, “Linux malware,” 2023, accessed: 2024-11-14. [Online]. Available: https://github.com/timb-machine/linux-malware

    2023

  25. [33]

    Coldfire: Golang malware development librarywolfi os,

    R. C. Labs, “Coldfire: Golang malware development librarywolfi os,”

  26. [34]

    Linux malware detect,

    R. MacDonald, “Linux malware detect,” 2025. [Online]. Available: https://github.com/rfxn/linux-malware-detect

    2025

  27. [35]

    Badit4mal,

    lyvd, “Badit4mal,” 2024. [Online]. Available: https://github.com/lyv d/bandit4mal

    2024

  28. [36]

    Lastpymile: identifying the discrepancy between sources and pack- ages,

    D.-L. Vu, F. Massacci, I. Pashchenko, H. Plate, and A. Sabetta, “Lastpymile: identifying the discrepancy between sources and pack- ages,” in Proceedings of the 29th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engin...

    2021

  29. [37]

    Malcontent,

    Chainguard, “Malcontent,” 2024. [Online]. Available: https://github .com/chainguard-dev/malcontent

    2024

  30. [38]

    Oss detect backdoor,

    Microsoft, “Oss detect backdoor,” 2024. [Online]. Available: https:// github.com/microsoft/OSSGadget/tree/main/src/oss-detect-backdoor

    2024

  31. [39]

    [Online]

    Ossilate, “Packj,” 2024. [Online]. Available: https://github.com/ossil late-inc/packj

    2024

  32. [40]

    Virustotal,

    VirusTotal, “Virustotal,” 2024. [Online]. Available: https://www.viru stotal.com/

    2024

  33. [41]

    Capslock,

    Google, “Capslock,” 2024. [Online]. Available: https://github.com/g oogle/capslock

    2024

  34. [42]

    The container security platform,

    T. gVisor Authors, “The container security platform,” https://github .com/google/gvisor, accessed: 2024-11-14

    2024

  35. [43]

    Spellbound: Defending against package typosquatting,

    M. Taylor, R. K. Vaidya, D. Davidson, L. De Carli, and V . Ras- togi, “Spellbound: Defending against package typosquatting,” arXiv preprint arXiv:2003.03471, 2020

    2003 arXiv

  36. [44]

    Typosquatting in programming language package managers,

    N. P. Tschacher, “Typosquatting in programming language package managers,” Ph.D. dissertation, Universit ¨at Hamburg, Fachbereich In- formatik, 2016

    2016

  37. [45]

    Anomalicious: Automated detection of anomalous and potentially malicious commits on github,

    D. Gonzalez, T. Zimmermann, P. Godefroid, and M. Sch ¨afer, “Anomalicious: Automated detection of anomalous and potentially malicious commits on github,” in 2021 IEEE/ACM 43rd International Conference on Software Engineering: Software Engineering in Prac- tice (ICSE-SEIP). IEE...

    2021

  38. [46]

    Reproducible builds,

    Debian, “Reproducible builds,” 2025. [Online]. Available: https: //wiki.debian.org/ReproducibleBuilds

    2025

  39. [47]

    It’s like flossing your teeth: On the importance and challenges of reproducible builds for software supply chain security,

    M. Fourn ´e, D. Wermke, W. Enck, S. Fahl, and Y . Acar, “It’s like flossing your teeth: On the importance and challenges of reproducible builds for software supply chain security,” in 2023 IEEE Symposium on Security and Privacy (SP) . IEEE, 2023, pp. 1527–1544

    2023

  40. [48]

    A secure enclave signing solution,

    A. Linux, “A secure enclave signing solution,” https://gitlab.archlin ux.org/archlinux/signstar, accessed: 2024-11-14

    2024

  41. [49]

    Contour: A practical system for binary transparency,

    M. Al-Bassam and S. Meiklejohn, “Contour: A practical system for binary transparency,” in Data Privacy Management, Cryptocurrencies and Blockchain Technology: ESORICS 2018 International Workshops, DPM 2018 and CBT 2018, Barcelona, Spain, September 6-7, 2018, Proceedings 13. Sp...

    2018

  42. [50]

    {CHAINIAC}: Proactive {Software-Update} transparency via collectively signed skipchains and verified builds,

    K. Nikitin, E. Kokoris-Kogias, P. Jovanovic, N. Gailly, L. Gasser, I. Khoffi, J. Cappos, and B. Ford, “ {CHAINIAC}: Proactive {Software-Update} transparency via collectively signed skipchains and verified builds,” in 26th USENIX Security Symposium (USENIX Security 17), 2017, p...

    2017

  43. [51]

    A qualitative study of the linux open source community,

    H. Zhao, “A qualitative study of the linux open source community,”

  44. [52]

    Motivation of software developers in open source projects: an internet-based survey of con- tributors to the linux kernel,

    G. Hertel, S. Niedner, and S. Herrmann, “Motivation of software developers in open source projects: an internet-based survey of con- tributors to the linux kernel,” Research policy , vol. 32, no. 7, pp. 1159–1177, 2003

    2003

  45. [53]

    Lj interviews linus torvalds,

    P. Hughes and G. Shurleff, “Lj interviews linus torvalds,” Linux Journal, vol. 1996, no. 29es, pp. 1–es, 1996

    1996

  46. [54]

    Committed to trust: A qualitative study on security & trust in open source software projects,

    D. Wermke, N. W ¨ohler, J. H. Klemmer, M. Fourn ´e, Y . Acar, and S. Fahl, “Committed to trust: A qualitative study on security & trust in open source software projects,” in 2022 IEEE symposium on Security and Privacy (SP) . IEEE, 2022, pp. 1880–1896

    2022

  47. [55]

    Vulnerability management in linux distributions: An empirical study on debian and fedora,

    J. Lin, H. Zhang, B. Adams, and A. E. Hassan, “Vulnerability management in linux distributions: An empirical study on debian and fedora,” Empirical Software Engineering, vol. 28, no. 2, p. 47, 2023

    2023

  48. [1999]

    Available: https://cdr.lib.unc.edu/concern/masters p apers/v405sf00g

    [Online]. Available: https://cdr.lib.unc.edu/concern/masters p apers/v405sf00g

  49. [2016]

    Available: https://blog.npmjs.org/post/141577284765 /kik-left-pad-and-npm

    [Online]. Available: https://blog.npmjs.org/post/141577284765 /kik-left-pad-and-npm

  50. [2020]

    Available: https://github.com/redcode-labs/Coldfire

    [Online]. Available: https://github.com/redcode-labs/Coldfire

Pith tools

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