More audit information: package age

Is your feature request related to a problem? Please describe.

Not a problem per se, more of a nice-to-have: in addition to the current audit information I think it would be useful to be alerted of “older” packages. For example, if a required package version was uploaded more than N months ago, where N could be a command-line option. Perhaps there is a more recent update available, but perhaps there isn’t in which case I’d like to be alerted that the package is potentially stale/unmaintained.

Describe the solution you’d like

For example, running pip-audit --warn-aged 12 would list packages whose metadata entry upload_time_iso_8601 is older than a year. I could then check for updates, or consider dropping the package if I suspect it’s not maintained anymore.

Describe alternatives you’ve considered

Manual checking repos, or writing a custom script which fetches that data.

Additional context

This is an attempt to weed out package dependencies that may cause issues, e.g. because packages have become stale.

[jenstroeger]

I’d like to use this issue to scribble down thoughts & ideas, and to keep the conversation going. @woodruffw, unless perhaps you’d like to move the conversation to a more suitable place (e.g. the Python Ideas board).

Assuming the user is online when running pip-audit then for some/many packages the code repository should be available, e.g.

> curl -s https://pypi.org/pypi/Sphinx/5.1.1/json | jq .info.project_urls.Code
"https://github.com/sphinx-doc/sphinx"

Scraping the repository would then give us interesting data points which would help to build some form of “reputation score”. For example:

• Date of the last commit (docs) and the commit frequency indicates whether a repository is “active”
• The run results (docs) indicate whether the last commit passed CI
• The number of open issues (docs), their dates and discussion frequency indicates whether a repository receives attention
• Pull requests (docs), their dates and discussions and closing frequency indicates a code velocity, and if correlated with issues, might indicate whether a package is maintained

Now I understand that this isn’t directly related to security auditing for known vulnerabilities, but I’d argue that an unmaintained package is by definition a liability. Based on that, I’d also argue that a poorly maintained package with lower code/CI/CD quality also poses a risk.

Projects like Scorecard address this somewhat (e.g. by generating a “maintained” score) but it’s not specifically targeted for Python package audits. I’ve not noodled through more/other/related projects yet, either…

[woodruffw]

Makes sense!

Another hiccup we’ll want to consider: package age may not be easily available from all dependency sources, e.g. pip-audit with no arguments, meaning “audit the current environment” rather than “pull down metadata from PyPI”.