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
Sapper Revives Minefield to Deliver Accurate SBOM-Based Vulnerability Impact Reports for Cyber Resilience Act Compliance
Developer Perruer has forked the archived BitBom project Minefield into a new open-source tool called Sapper, fixing critical bugs in dependency graph construction and vulnerability matching. The original Minefield used roaring bitmaps and Tarjan's algorithm to build transitive dependency caches from SBOMs in O(n + m) time, but it incorrectly interpreted SPDX edge directions from protobom 0.6, creating false cycles and massively inflating dependent package counts. Additional fixes addressed SQLite memory database pooling issues, OSV range sorting errors with Go pseudo-versions and ECOSYSTEM ecosystems, and slow OSV ingestion by adding a package name index. Sapper now produces prioritized reports using CISA KEV and EPSS scores, showing exact shortest paths from vulnerable packages to root products while respecting OpenVEX statements. The tool maintains full air-gapped operation and supports CycloneDX 1.3–1.7 and SPDX 2.x formats. These improvements directly help organizations meet the 24-hour notification requirements under the EU Cyber Resilience Act for actively exploited vulnerabilities.
Fake Terraform Providers on HashiCorp Registry Distribute Go Malware to Developers
Cybersecurity researchers have identified Go-based malware distributed through two fake Terraform providers and two Go modules hosted on the official HashiCorp registry. The providers gocommunity-io/dockerd and kreuzwenker/docker, along with modules gocommunity.io/orderedbtree and gogets.dev/btreex, impersonate legitimate projects and represent the first documented case of malicious code being delivered via the HashiCorp registry. Attackers approach developers on LinkedIn, Facebook, and job forums using fake Web3 company profiles, then supply seemingly harmless repositories whose malicious behavior is triggered through npm or PyPI dependencies. Once executed, the malware collects hardware attributes, operating system data, hostname, and node availability before sending the information to attacker infrastructure. Command and control relies on a Slack channel polled every ten seconds and encrypted commands read from Sepolia testnet Ethereum smart contracts every three seconds, with each infected client using ephemeral key pairs for targeted delivery. The code matches the Graphalgo campaign previously documented by ReversingLabs and attributed to North Korean actors.
Challenges in Building Accurate SBOMs for C and C++ Projects Highlighted by CodeScoring Analysis
C and C++ ecosystems lack centralized package manifests, making SBOM generation far more complex than in Python, Java, or JavaScript. Libraries may arrive through system package managers like apt or dnf, build tools such as Conan and vcpkg, or direct source inclusion, with no single record of all components. CodeScoring’s Johnny agent uses eBPF to observe linker commands during builds and cross-references results with dpkg, RPM, and pkg-config metadata. The analysis distinguishes build-time SBOMs, which capture static libraries and compilation commands, from runtime SBOMs that reflect dynamic dependencies at execution. When version data cannot be verified, components are explicitly marked unresolved rather than guessed. The approach also addresses header-only libraries and patched artifacts that defeat simple hash matching.
CrowdSec Confirms Theft of Source Code from Roughly 300 GitHub Repositories via TanStack Supply Chain Attack
French cybersecurity firm CrowdSec has confirmed that attackers stole source code from approximately 300 GitHub repositories, including around 170 private ones. The breach occurred in May 2026 through a compromised TanStack component that exfiltrated an API key with read access to the private codebase. The stolen material included code for the company's SaaS console, AWS procedures, connectors, and automation tools, while the remaining repositories contained already-public open source code. No customer data, passwords, organization details, tokens, or other secrets were included in the leak, and all potentially affected credentials were immediately rotated. CrowdSec stated that the code is tightly integrated with internal systems and has largely changed over the past four months, reducing its usefulness outside the company's environment. The SaaS service code undergoes regular audits, and the company sees no immediate threat from the exposure while the investigation continues.