Pipenv was the Next Big Thing in 2017. It had Kenneth Reitz behind it, PyPA endorsement, and a promise of npm-like dependency management for Python. By 2020 the maintenance crisis was public, the roadmap was unclear, and the community had largely moved on to Poetry. By 2023 Pipenv is stable again, actively maintained, and quietly running in hundreds of production environments that adopted it during the hype cycle.
If your team is on Pipenv, this is an honest security review of what you have. No cheerleading, no dunking. Just the posture.
Pipfile.lock Is a Real Security Artifact
Pipenv's Pipfile.lock is a JSON file with resolved versions and hashes for every direct and transitive dependency. When you run pipenv install in a repository that has a committed lockfile, the installer uses pip install --require-hashes under the hood. Hash verification is on by default and not easy to turn off.
This is genuinely good. It is better than requirements.txt without hashes (trivial to MITM a PyPI mirror), comparable to Poetry's lockfile, and comparable to pip-compile --generate-hashes. If you are deploying from Pipfile.lock with pipenv install --deploy, your supply chain from lockfile to installed packages has integrity.
The failure mode is teams who generate Pipfile.lock locally but do not run pipenv install --deploy in CI. Without --deploy, Pipenv will regenerate the lockfile if Pipfile has changed without updating the lockfile — which defeats the entire purpose. Add --deploy to your CI and production installs.
How Active Is Pipenv Really?
As of 2023, Pipenv releases have resumed on a reasonable cadence. Matt Davis and others have kept the project going. The pypa/pipenv repository sees steady commits, security issues get addressed, and the 2023.x release series is the current line.
But the community has diverged. Poetry has more users, more plugins, more active development. Hatch is newer and well-maintained. PDM targets a PEP 582 future that matters if you follow PEP direction. uv, from the Astral team, landed in 2023 and aims at the same space with Rust-speed installs. Pipenv is fine, but it is not where new projects are being built.
For a security team, this means the pool of people who can help you with Pipenv-specific issues is shrinking, the rate at which new tooling supports Pipenv is slowing (some SBOM generators added Poetry support years before Pipenv), and Stack Overflow answers about Pipenv are increasingly stale.
Which CVEs Have Actually Hit Pipenv?
Pipenv itself has had few direct CVEs. CVE-2022-21668 was a vulnerability in Pipenv's handling of index URLs in Pipfile that could allow credential leakage if an attacker controlled a subdomain of a private index. It was patched in 2022.3.23.
More commonly, Pipenv's security depends on the security of pip, requests, pyparsing, and the other libraries it pulls in to do its work. CVE-2023-5752 in pip (Mercurial argument injection in VCS URLs) affected Pipenv users transitively because Pipenv uses pip for the actual installation.
The practical implication: pipenv --version alone is not enough. You also need to know what pip version Pipenv is shimming, and whether your bundled virtualenv is current. pipenv --support dumps all of this; add it to your security inventory.
Is Dependency Confusion a Real Risk?
Yes, and Pipenv has handled it acceptably but not perfectly. In Pipfile, you declare sources:
[[source]]
url = "https://pypi.org/simple"
verify_ssl = true
name = "pypi"
[[source]]
url = "https://my-private-index.example.com/simple"
verify_ssl = true
name = "internal"
To pin a specific package to a specific source, use my-package = {version = "*", index = "internal"}. This is per-package. If you forget to set the index on a private package, Pipenv will search both indexes and may prefer a higher version from PyPI — the classic dependency confusion.
Audit every package that is hosted on your private index. Every one of them should have an explicit index = "internal" qualifier. If you have forty private packages and only two have the qualifier, you have thirty-eight dependency confusion risks.
Virtualenv Placement
Pipenv's default is to place the virtualenv in ~/.local/share/virtualenvs/<project-hash>. This is fine on a developer workstation, awkward in CI (where you often want a local .venv), and a minor security consideration on shared servers where multiple users might collide. Set PIPENV_VENV_IN_PROJECT=1 to put the venv in ./.venv — this is almost always what you want.
The security angle: a venv in a predictable shared location is easier for an attacker with limited shell access to tamper with. An in-project venv is isolated to the project directory.
Does It Still Fit Your Team?
The honest question to ask in 2023 is whether Pipenv still fits.
If you have a small, stable Python service that installs fine and works fine, there is no security reason to migrate off Pipenv today. Pipfile.lock with hashes is a legitimate supply chain control.
If you are building new Python projects, the center of gravity has shifted. Poetry for most teams, uv for teams that want speed, PDM if PEP 582 appeals. New Pipenv projects are a rarer choice and the tooling ecosystem reflects that.
If your Pipenv project has been hard to update — resolver timeouts, lockfile regeneration taking minutes — that is a maintenance tax, and maintenance tax is a security risk because it discourages timely patching. I have seen teams defer a cryptography CVE patch for two weeks because regenerating the lockfile was painful.
Migration Path If You Decide to Go
If you do migrate, the path from Pipenv to Poetry is reasonably mechanical. Tools like pipenv-to-pyproject or dephell (now archived but still functional for this) can convert Pipfile to pyproject.toml. Expect to hand-edit, especially for source definitions and scripts.
Do not migrate under deadline pressure. A rushed migration that drops hash verification, loses a private index declaration, or changes transitive resolution is a security downgrade even if it ends on a "modern" tool.
How Safeguard Helps
Safeguard ingests Pipfile.lock as a first-class source, generating a full SBOM from the resolved hashes and versions without requiring you to switch tools. Reachability analysis maps CVEs in transitive dependencies against actual code paths in your Pipenv-managed services, so you know whether to patch urgently or schedule. Griffin AI can draft migration PRs from Pipenv to Poetry or uv when the maintenance signals cross a threshold, preserving your source declarations and hash verification posture. Policy gates can enforce that production deploys always use pipenv install --deploy and fail when the lockfile is out of sync with the Pipfile.