PyPitfall: Dependency Chaos and Software Supply Chain Vulnerabilities in Python

Reading scientific cyber security literature is crucial for continuous development and learning. Engaging with research papers often leads to new insights or a deeper perspective on a subject.

The paper titled “PyPitfall: Dependency Chaos and Software Supply Chain Vulnerabilities in Python” (arXiv: 2507.18075) captured my attention. Authored in 2025 by researchers from the Computer Science Department at the New Jersey Institute of Technology.

The article is good readable which makes it easy to gain new knowledge and insights provided.

Some statements in this article are exaggerated. Perhaps due to the fact that the article is revisited with the use of AI.

The claim: “A single package may depend on hundreds of others, each with its dependencies, forming a deep software supply chain labyrinth.” does not belong in a serious article. This strong assertion warrants substantial evidence. Given that Python’s ecosystem is generally considered less prone to the “ultra-small dependency” issue seen in platforms like Node.js (NPM), I would expect to see references to the top 250 most-used Python modules or other robust data supporting this claim. This statement also appears to contradict with later findings presented. Later in the paper it is stated that the majority of packages seldom have more than five direct dependencies.

This paper consistently employs the term “complexity” without providing any explicit definition or framework within the context of dependency analysis. While the study discusses complex dependencies, the term “complicated” would likely be more accurate if the focus is purely on the technical depth and structure of the dependency graph (e.g., the depth of the software supply chain).

The choice of “complexity” usually implies an emphasis on emergent behaviour, non-linearity, and, critically, human factors—the very elements that make security a complex socio-technical challenge, not just a complicated technical one. Given that the paper is focused entirely on analysing static data and lacks any analysis of developer behaviour, decision-making, or human-in-the-loop security processes, the use of the term “complexity” feels misplaced. I am of course biased, since I have studied and written a lot about complexity. Check e.g. the SimplifyIT toolkit or our open library.

The core of the research presented is data analysis. From a broad security perspective I miss a view or some research references that addresses essential human elements that fundamentally drive security risks in open-source software. Security is and will never be solved with technology only.

The paper states: “we assume that Python package developers are not malicious and do not intentionally introduce vulnerabilities into their packages. However, as the number of dependencies grows, developers may not be aware of the known security issues in their dependent third-party packages.”

This statement asks for some nuance and some observations:

• Weakness vs. Vulnerability: The authors do not distinguish with clear definitions the term weakness (a flaw in design or implementation, such as poor coding practice) and vulnerability. A vulnerability is a weakness that can be exploited. Using this definition makes the interpretation of the performed analyse difficult, but within security it is crucial to be clear on terms. Serious security aware Python developers use Static Application Security Testing (SAST) tools, like Python Code Audit, to identify and mitigate such weaknesses proactively. But still secure coding fundamentally relies on developer knowledge to prevent these weaknesses from arising.

• Dependency Validation: When integrating third-party dependencies, it should be standard practice—not an optional step—to minimally validate them against known vulnerabilities. Numerous tools, including Python Code Audit solutions, are available to automate this crucial security hygiene. However the authors show that knowing all your dependencies is not straightforward.

The authors neglect the long-standing challenges and current developments in Software Bill of Materials (SBOMs). I think this is a significant omission, as SBOMs are central to managing supply chain risk and all problems with software dependencies are present in SBOM puzzles.Relevant security projects, such as the OWASP CycloneDX project (https://cyclonedx.org/), are making substantial progress in this field, particularly for Python packages.

While the study focuses on vulnerabilities within the open-source ecosystem and Python’s dependency supply chain, I miss a topology of common supply chain attacks specific to the Python ecosystem. The most prominent attacks often involve malicious updates that deliberately sneak code flaws into widely used packages—a weakness intentionally planned with a malicious goal in mind.

The authors recognise the fact that there is no perfect solution for solving the ‘supply chain security problem’. Perhaps out of scope for this paper, but the last 8 years some fantastic work has been going on to mitigate risks in this field. This paper does not mention any of these open initiatives.

This paper, by focusing solely on FOSS security, risks perpetuating the harmful and inaccurate perception that open-source software is inherently insecure. Too many security researchers only focus on FOSS ecosystems. The majority of real security threats for society and companies are closed source solutions that are hidden from the public eye.

Instead of fueling the “insecure FOSS” narrative, a more valuable analysis would:

• Quantify commercial dependence on Python modules.

• Analyze the investment gap between commercial use and FOSS maintenance.

The focus should shift from blaming FOSS to demonstrating the financial necessity of investing in the security and maintenance of the open-source software supply chain.

The study concentrates on vulnerabilities registered exclusively within the National Vulnerability Database (NVD). This is a risk to the validity of the presented results.

• Incomplete: Relying solely on the NVD inherently provides an incomplete picture, as a significant number of vulnerabilities remain unregistered. Any “hard conclusions” drawn regarding the overall security status of the ecosystem must therefore be approached with extreme caution.

• Search Ambiguity: The stated search methodology—using the ambiguous term “Python library” within the NVD and MITRE databases is limited. The more accurate and common terminology is “Python module” or “Python package.” While the researchers acknowledge this limitation, a more exhaustive search strategy using broader or more precise terms would have been necessary to identify more known vulnerabilities in the PyPI ecosystem.

The paper presents PyPitfall, an analysis concluding that out of 378,573 PyPI packages analyzed, 4,655 have dependencies guaranteed to contain known vulnerabilities.

• Perception of representation results is key: While 4,655 sounds large, it represents only 1.2% of the packages analyzed.

• Ecosystem Context: This 1.2% percentage needs to be framed within the reality of the PyPI registry, which includes numerous hobby projects, abandoned packages, and code not written by professional developers. Critically, the majority of high-value, closed-source business applications developed using Python are not published on PyPI.org. Therefore, extrapolating conclusions about enterprise security risk based solely on PyPI metadata requires careful consideration.

From an Open Research perspective, this paper is significantly lacking to meet standards.

• Missing Artifacts: I was disappointed to find no publicly available repository containing the code or scripts used to generate the PyPitfall results, nor the raw or processed data gathered from PyPI.org and the NVD.

• FAIR Principles: The researchers outlined the high-level architecture and mentioned general tools but omitted crucial, granular details required for replication. Especially when researching open-source ecosystems, the expectation for reproducible research—adhering to FAIR principles (Findable, Accessible, Interoperable, Reusable)—is high. The lack of data and code prevents a detailed inspection of the experiment’s validity.

While software supply chain attacks are a valid and significant concern for Python, the paper lacks strong, quantifiable evidence demonstrating the actual scale of this problem within the Python ecosystem specifically. The references used appear too generic and are arguably not directly transferable or relevant to the unique characteristics of the Python landscape.

The conclusion advocating for enhanced security awareness in the Python software supply chain is valid. You should understand dependencies. Direct and indirect. The authors could have done a better job in using clear definitions for the various types of dependencies. From a security point of view system or host dependencies with weakness have far more impact that weaknesses in Python modules. Also the section on the so called ‘complexity’ of circular dependencies is exaggerated. The issues with circular dependencies are far more difficult to solve from a reproducible builds perspective. Anyone who has created large programs in C/CPP is aware of issues that can occur with circular dependencies. Most Python developers will never need to deal with circular dependencies.

As the authors themselves concluded, the challenge of preventing weaknesses from being incorporated into a Python software supply chain remains a highly complex issue that this paper’s analysis, despite its scope, does not fully resolve.

While the growing attention from researchers on Python security subjects and the publication of findings are great, studies like this often fall short. It is easy to diagnose security problems inherent in a volunteer-driven open-source ecosystem. The challenge, and the responsibility of the academic community, should be to move beyond mere exposure to focus on developing effective mitigation strategies that solve the underlying problems. Therefore, the findings of this paper may have limited impact on improving Python security until a more solution-focused approach is adopted.

A valuable addition the paper missed would be concrete guidance for Python developers. My advice focuses on mitigating inherent risks:

• Treat All Dependencies as Untrusted: The popularity of a Python module, like Pydantic, is not a security metric; it conveys nothing about the presence of vulnerabilities. As demonstrated by high-profile incidents. A “verify, never trust” approach must be standard practice for all third-party libraries.

• Recognise the Boundary of the Standard Library: Understand that modules not included in the Python Standard Library, such as urllib3 and requests, introduce an external maintenance and security liability. This boundary is intentional and serves as a natural risk demarcation point.

• Prioritise Simplicity to Reduce Attack Surface: A core principle in security is simplicity. Because dependency management is inherently complicated, and complex supply chains are the main vector for attacks, developers should rigorously limit the number of dependencies used. Keeping the software architecture and dependencies simple is the most effective way to control and secure the software supply chain.

• Use Python Secure Coding Guidelines when creating Python software.

Try Python Code Audit

A modern Python source code analyzer based on distrust.