As part of my day job on Google’s open-source security team, I’ve been working for the past year with a team from Trail of Bits to author, implement and maintain https://pypi.org/p/pip-audit/, a standalone tool for scanning Python environments for packages with known vulnerabilities. This is the first such tool to integrate directly with PyPI for vulnerability data and be intended to be an entirely community-owned and operated project.
We’re at the point now where
pip-audit is more or less feature-complete & bug-free, and there’s a potential path towards elevating the
pip-audit project as a subcommand of
pip itself. I’ve outlined a rough roadmap for this path here. We (the
pip-audit maintainers) would like to welcome discussion on the roadmap as well as get buy-in from the wider community on the overall plan.
Our ultimate goal is to make a) useful vulnerability tooling that is b) free to use, c) community owned and operated and and d) canonical and easily available to every Python user. We’ve already achieved a) and b) and to some extent c) (the project is open-source, and we plan to request a transfer to the PyPA org) but we think the most effective way to achieve d) is by making
pip-audit a subcommand of
pip itself, due to
pip’s wide user base.
Given that our goal has always been to become a subcommand of
pip, we’ve taken a lot of care to design
pip-audit in a way should make integration as easy as possible:
- We’ve designed
pip-audit’s CLI in a way that is in line with
pip’s existing CLI and UX and with commands that should feel natural to the average
pipuser: commands for auditing environments or requirements files with
pip-auditshould feel very similar to existing commands for installing with
- We’ve taken great care in taking on additional sub-dependencies that would unnecessarily increase
pip’s footprint, and aligning with
pip’s existing sub-dependencies where possible
- We’ve designed
pip-audititself in a way that should make it possible to mount it as a vendored subcommand of
pip, rather than re-implementing it from scratch. This means that it should be a low maintenance burden on the
pipmaintainers, as ongoing development & maintenance could continue to happen in the
pipmaintainers getting the final say in what makes it into
pipitself, of course).
The point of this discussion is to share this potential plan early on with the community and get feedback, specifically on the following questions:
- Do you think support for known vulnerability auditing something that would be valuable to have in
- Does the feature set of
pip-auditalign with what you’d find valuable?
- Is the proposed roadmap the best path forward?
Thanks in advance!