Cross-Ecosystem Vulnerability Analysis for Python Applications

Python applications depend on native libraries that may be vendored within package distributions or installed on the host system. When vulnerabilities are discovered in these libraries, determining which Python packages are affected requires cross-ecosystem analysis spanning Python dependency graphs and OS package versions. Current vulnerability scanners produce false negatives by missing vendored vulnerabilities and false positives by ignoring security patches backported by OS distributions. We present a provenance-aware vulnerability analysis approach that resolves vendored libraries to specific OS package versions or upstream releases. Our approach queries vendored libraries against a database of historical OS package artifacts using content-based hashing, and applies library-specific dynamic analyses to extract version information from binaries built from upstream source. We then construct cross-ecosystem call graphs by stitching together Python and binary call graphs across dependency boundaries, enabling reachability analysis of vulnerable functions. Evaluating on 100,000 Python packages and 10 known CVEs associated with third-party native dependencies, we identify 39 directly vulnerable packages (47M+ monthly downloads) and 312 indirectly vulnerable client packages affected through dependency chains. Our analysis achieves up to 97% false positive reduction compared to upstream version matching.

💡 Research Summary

The paper tackles a pressing problem in modern software supply‑chain security: determining which Python applications are affected by vulnerabilities in native libraries that may be bundled (vendored) inside Python wheels or provided by the host operating system. Existing Software Composition Analysis (SCA) tools either miss vendored binaries (producing false negatives) or rely solely on version strings, which is insufficient because Linux distributions frequently back‑port security fixes without changing the upstream version (producing false positives).

Key Contributions

1. Provenance‑aware vulnerability analysis – The authors introduce a two‑pronged method to identify the exact origin of each vendored library.

   • Content‑based hashing: Manylinux’s auditwheel appends an 8‑character SHA‑256 hash to each bundled shared object. By maintaining a historical archive of Debian, Ubuntu, and Red Hat package binaries, the tool can match the hash to the original OS package and retrieve the precise distribution‑specific version, including any back‑ported patches.
   • Dynamic version extraction: When hash matching fails (e.g., the library was rebuilt from source), lightweight, library‑specific dynamic analyses parse ELF metadata, symbol versions, and embedded strings to infer the upstream release and whether distribution patches are present.

2. Cross‑ecosystem call‑graph construction – The approach stitches together three layers of call information:

   • Python‑level static analysis (AST‑based import and function‑call extraction).
   • Native extension call graphs generated via LLVM‑based static slicing and ELF dependency inspection (DT_NEEDED, RPATH).
   • System‑library call graphs.
     This unified graph enables reachability queries from a known vulnerable function (e.g., xmlParseChunk in libxml2) back to any Python function that might invoke it, even through multiple dependency hops and dynamic loading (dlopen).

3. Empirical evaluation – The authors implemented the technique in a tool called PYXSIEVE and applied it to the top 100 000 PyPI packages (all with ≥1 000 monthly downloads as of January 2026). Findings include:

   • Provenance could be resolved for 63.1 % of vendored libraries, either to an exact OS package version or to an upstream release.
   • 39 packages directly bundled vulnerable shared objects, accounting for >47 M monthly downloads (e.g., pymssql with >35 M downloads).
   • 312 additional client packages were indirectly vulnerable because their dependency chains could reach vulnerable functions in vendored or system libraries.
   • Compared with a state‑of‑the‑art scanner (Trivy), PYXSIEVE reduced false positives by up to 97 % by correctly handling back‑ported fixes.

Technical Challenges Addressed

• Misleading upstream versions – The tool distinguishes between upstream version numbers and distribution‑specific revisions, crucial for correctly interpreting back‑ported security patches.
• Build‑time modifications – Even when binaries are altered during wheel creation, the hash‑based matching still works for many cases; otherwise, dynamic analysis recovers version information.
• Long dependency chains – By integrating Python and native call graphs, the system can efficiently evaluate reachability across large, multi‑level dependency graphs.

Impact and Future Work
The study demonstrates that a provenance‑aware approach is essential for accurate vulnerability assessment in the Python ecosystem, where many projects rely on manylinux wheels that embed copies of system libraries. The authors responsibly disclosed all findings, leading to 51 patches at the time of writing. Limitations include handling heavily stripped or heavily patched binaries where hash matching fails, and extending the methodology to other native extension languages such as Rust or Go. Future directions involve machine‑learning‑based binary similarity for better matching, real‑time integration into CI/CD pipelines, and broader multi‑language support.

Overall, the paper provides a solid, reproducible framework that bridges the gap between Python package management and OS‑level security, significantly improving the precision of supply‑chain vulnerability detection.