Cross-Ecosystem Vulnerabilities in Python Applications

NO|Complexity SimplifyIT - Radical Open Innovation

SubscribeSign in

Cross-Ecosystem Vulnerabilities in Python Applications<br>Security-by-Design: Surviving Vulnerabilities in Your Python Dependencies

Maikel<br>Jul 08, 2026

Share

Ecosystem cyber Vulnerabilities sketch

Some notes after reading the paper “Cross-Ecosystem Vulnerability Analysis for Python Applications” (19 Mar 2026, https://arxiv.org/abs/2603.18693v1)<br>Python is the most widely used programming language worldwide. However, using Python code does not mean your application is secure by default; security breaches are still possible.<br>As the creator of a FOSS Python Static Application Security Testing (SAST) tool, Python Code Audit, I am always interested in Python security research—especially to find new, simple ways to make cybersecurity more effective.<br>Most research performed on Python security is of mediocre quality and exaggerates the impact of the vulnerabilities found. This research paper falls into that category.<br>Observations

The paper elaborates on “indirectly vulnerable packages”, but a clear definition of what this means is missing. The authors seem to mean a Python package that depends on a system library with a vulnerability that is present on an operating system. In that case, speaking about ‘vulnerabilities’ for the dependent Python package is misleading. There are many ways that a Python package can remain resilient against vulnerabilities in dependencies. When simple security-by-design rules are followed, the mantra is zero trust. The question missing from this paper is: why are simple security design rules not being followed?

The following statement is questionable: “This package depends on the Python package igraph, which bundles the vendored library libxml2-3998bec4.so.2.9.1, and also depends on Python package pycairo.”

A detailed analysis shows that pycairo is not a dependency of either the scppin package or the igraph package. However, the paper clearly states that igraph 0.11.9 depends on the Python package pycairo. Pycairo is a Python module providing bindings for the Cairo graphics library.<br>So, to me, this is a disturbing discrepancy that I cannot explain. I wanted to investigate this a bit deeper, so I checked all dependencies—both direct and indirect—with Google Open Source Insights. This is an excellent tool to check all direct and indirect (transitive) dependencies of a Python package, but it could not find a link to pycairo. I also used my own Python Code Audit tool to search for Python dependencies of igraph, but no dependency on pycairo was found. Since my tool uses AST parsing, I trust it to find direct Python dependencies within Python packages.<br>Consequently, the link from igraph to the pycairo package remains a mystery to me. Perhaps the researchers used AI and it went into hallucination mode? The real pain points, of course, are the missing code and data that the researchers used. This is why open research is vital for good research. The results presented in this paper cannot be verified, since this research paper does not apply open research principles in any way; the created and used software is unavailable, and the underlying data is also missing.<br>This paper puts an emphasis on “popular” Python packages. However, popular does not mean secure. Security is never black and white: depending on the context, risks vary.

There is a great emphasis on “accurate vulnerability assessment”. However, far more important before using any software—open or closed-source—is performing a risk assessment for your specific context. This research paper adds fuel to the popular opinion that open-source software equates to insecure software. Of course, it is hard to conduct open research on closed Python software, but the efforts made to keep vulnerabilities away from PyPI.org are highly competent and strongly organised. Improvements are always possible and are continuously happening.

Known vulnerabilities have very limited meaning, since the majority of weaknesses in Python applications (or other types of applications) are never exposed or registered as a CVE. The process for registering a CVE is long, painful, and very time-consuming.

This paper focuses too heavily on known vulnerabilities, instead of looking towards a more shift-left approach—an approach that gives Python package developers a simple way to verify weaknesses in dependent libraries. The research method used by these researchers is complex by design and will, therefore, fail in practice.

The human factor is left entirely out of scope. It would be excellent for these kinds of security researchers to develop a simple method for Python package developers who depend on third-party C-libraries to prevent or detect weaknesses and vulnerabilities within a development pipeline. The Reproducible Builds project is doing great work, and I think ensuring every Python package that depends on non-Python code is...