Identifying and Managing Vulnerabilities in Python Packages 

Did you hear about the malicious PyPI package that collects environment details and sends the info to an unknown web service? Or the Trojan horse one that installs, fetches a .exe file from a non-descript domain, then attempts to execute? What about the package that targets British-English speakers and tries to steal bitcoin? 

Malicious packages are a real risk when working with open-source ecosystems, and they can cause serious harm to your organization and systems. But malicious packages are only part of the story. You also need to watch out for vulnerable packages. 

Most Python users eventually discover there are two very different types of risk here, and they require very different ways of handling them.  

Python, Malicious Packages, and Vulnerabilities 

A malicious package is intentionally harmful. It contains code designed to steal data, execute malware, or hide its activity using techniques like typosquatting.

Take the colorama and colourama case.

colorama, first released in 2010, is a legitimate package used to make ANSI escape sequences work on Windows.

colourama, by contrast, was a typosquatted package designed to trick users searching for the real library. It copied the original code and added malware that inspects the Windows clipboard for bitcoin addresses.

Python’s popularity and massive ecosystem make this kind of attack especially effective. A simple typo in a pip install command is often enough to pull in the wrong dependency. Organizations can defend against this class of risk using tools like PyPI scanning and package approval workflows. The goal is simple: prevent untrusted packages from ever entering internal environments.

Vulnerable packages are different.

These are legitimate packages that later have security flaws discovered in them, sometimes months or years after they were published. Those issues are tracked through sources like CVEs and GitHub Security Advisories.

A WhiteSource report noted that many Python vulnerabilities are low-severity, but high-severity issues still exist. At some point, every Python team will run into this problem. Detecting vulnerabilities is important, but understanding their impact and deciding how to respond is often the harder challenge.

Why Build-Time Scanning Isn’t Enough

Most teams already use tools like pip-audit during CI/CD workflows to scan Python environments for known vulnerabilities before deployment. These tools are extremely useful and often serve as the first layer of defense against vulnerable packages. But build-time scanning has a natural limitation: it only captures a snapshot in time.

A package considered safe today may have a critical vulnerability disclosed months or years later, long after it has already entered production.

Build-time scanners such as pip-audit are effective at identifying known vulnerabilities during CI. However, because they focus on the environment being scanned at that moment, they generally provide limited visibility into how vulnerable packages are being used across deployed applications and environments.

In practice, not all vulnerabilities carry the same risk. Some require very specific conditions to exploit. Others may already be exposed in production systems. Without additional context, teams are left interpreting scan results manually. That often leads to alert fatigue, unnecessary upgrades, and inconsistent decisions across teams. 

Continuous Vulnerability Management with ProGet 

 This is where ProGet extends the model. Instead of treating vulnerability scanning as a one-time build step, ProGet regularly re-evaluates the packages in your feeds against the latest vulnerability information.

Packages typically move through multiple stages as they are consumed across an organization. They may be downloaded from upstream sources, cached locally, promoted between feeds, and reused across environments. ProGet maintains visibility into packages as they move through these stages.

When a new vulnerability is published, ProGet scans the packages already in your feeds to determine which ones are affected. Teams can quickly identify affected packages, review info on the associated vulnerability, and understand where those packages are being used across the organization.

This changes how vulnerability data is used in practice.

ProGet also helps teams move beyond raw severity scores. By evaluating vulnerabilities against a risk profile set up to reflect your organization’s environment, it helps teams prioritize issues based on the level of risk they pose to the organization rather than treating every vulnerability as equally urgent.

This gives teams a more practical way to prioritize response efforts. Some vulnerabilities can be scheduled for remediation during normal development cycles, while others may not need any action at all. Higher-risk issues may require immediate containment to reduce exposure until a fix can be implemented.

Because these assessments happen directly within ProGet, the same guidance can be applied consistently across feeds, teams, and environments rather than requiring individual developers to interpret raw vulnerability data on their own.

The result is a more actionable vulnerability management process. Instead of simply identifying vulnerabilities, teams gain additional context to help prioritize response efforts and determine what actions should be taken next.

Managing Risk Over Time 

Build-time tools like pip-audit are still essential. They help prevent known vulnerable packages from entering production in the first place.

But vulnerability management doesn’t end there. Because new vulnerabilities can be discovered at any time, teams need ongoing insight into the packages already running across their environments.

ProGet extends build-time scanning by maintaining that awareness across the entire package lifecycle, from initial download through long-term production use. The result is a more complete model: detect issues early, while continuously understanding their impact as your environment changes.

Next, we’ll look at how CI/CD automation helps Python teams consistently test, validate, and manage application changes as packages, dependencies, and environments continue to evolve.