How to Audit All Python Virtual Environments for Compromised Packages Without Executing Python
The growing number of supply-chain attacks targeting popular packages has prompted developers to seek reliable ways to audit their Python installations. Recent incidents affected the npm package Axios, the vulnerability scanner Trivy, and the Python package LiteLLM. In response, one developer created a system to locate every virtual environment on a machine and inspect its installed packages without ever executing Python code.
Virtual environments isolate project dependencies by storing symbolic links to the Python interpreter and site-packages inside a dedicated directory, conventionally named .venv. Because Python itself does not track created environments, the author maintains a personal registry file at ~/.venv_registry that is updated both by periodic find commands and by a shell function that records every newly created environment.
The registry enables a simple Bash script that reads each path, verifies the directory still exists, and then calls uv pip freeze --python against the environment’s interpreter. Because uv is written in Rust, it parses installation metadata without running any Python code—an important safeguard after the LiteLLM compromise demonstrated that even innocuous commands such as python --version could execute attacker-controlled .pth files.
The same registry supports additional security and maintenance tasks. It can be used to identify outdated package versions across all projects, locate remaining usages of libraries the developer wishes to retire, and search project source trees for calls to specific functions without scanning the entire disk.
Global installations outside virtual environments are prevented by setting PIP_REQUIRE_VIRTUALENV=true and by relying on uv, which refuses to modify the system Python unless the --system flag is explicitly supplied. The resulting workflow therefore provides both rapid detection of known malicious packages and ongoing hygiene for a large collection of Python projects on macOS.
Related articles
GitHub and PyPI Add Time-Based Defenses Against Supply Chain Attacks
GitHub and PyPI have introduced new time-based barriers to slow down supply chain attacks. Dependabot now waits a default of 72 hours before proposing version updates, while PyPI rejects new files added to releases older than 14 days. The changes target non-security version updates and attempts to poison older stable releases. Security updates remain immediate, and the cooldown can be adjusted via dependabot.yml. PyPI's restriction addresses risks from compromised tokens or CI/CD pipelines that allow malicious artifacts on past versions. The measures were implemented in July 2026 following incidents involving projects like LiteLLM and Telnyx.
GitHub and PyPI Introduce Time-Based Defenses Against Supply Chain Attacks
GitHub and PyPI have activated new time-based barriers to slow down supply chain attacks. Dependabot now waits a default of 72 hours before proposing version updates, while PyPI rejects new files added to releases older than 14 days. The changes target non-security version updates and attempts to poison older stable releases. Security updates remain immediate, and the cooldown can be adjusted via dependabot.yml. The PyPI restriction, effective since July 8 2026, addresses risks from compromised tokens or CI/CD pipelines. Both platforms aim to give the community time to detect malicious packages before widespread adoption.
Container Image Risks: Why Skipping Verification Today Breaks Your Service Tomorrow
Technical leader Nikita from Cloud.ru details four recurring container security failures observed across client environments. The article examines untracked vulnerabilities in high-privilege components such as the NVIDIA GPU operator, supply-chain compromises affecting even trusted tools like Trivy, persistent secret leakage patterns, and CI/CD pipeline exposure. Real incidents include a 2025 NVIDIA container toolkit exploit that enabled lateral movement to worker nodes and a 2026 Trivy GitHub compromise that poisoned over seventy image tags. The author stresses that pinning to image tags is insufficient and recommends full SHA256 hashes, private registries with caching, Cosign signatures validated by Kyverno or Connaisseur, and pre-commit secret scanning. Practical recommendations include automated CVE notifications and immediate patching of privileged components rather than waiting for sprint cycles.
Should Python Libraries Raise Minimum Dependency Versions to Block Vulnerable Releases?
Seth Larson of the Python Software Foundation argues that library maintainers should not automatically raise the minimum allowed version of a dependency after a vulnerability is disclosed. He states that dependency metadata exists to declare compatibility, while security decisions belong to the application owner who controls the final build. The recommendation has sparked debate in the Python community, with some maintainers supporting the separation of concerns and others viewing security constraints as part of library support obligations. CodeScoring’s analysis examines the practical impact on the ecosystem, noting that over 10,000 packages depend on urllib3 and tens of thousands more rely on numpy, requests, and pandas. The piece concludes that version bounds may incorporate security considerations only after evaluating real usage, affected versions, and downstream compatibility, but they cannot replace application-level vulnerability management with lockfiles and tools such as pip-audit.