name is the github link to a python security advisory database repository we are considering making use of for handling vulnerability scanning of our python backend. There is a need to verify if this repository is a valid packaging advisory authority.
The actual process of verifying this is left to the assignee of this task to figure out how to handle, then share their methods and results under this task.
While researching the above mentioned github repo, it is also necessary to research other possible ways of solving this problem.
Description
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Open | None | T288685 Establish active/active multi-dc support for Toolhub | |||
Resolved | bd808 | T115650 Create an authoritative and well promoted catalog of Wikimedia tools | |||
Resolved | bd808 | T271483 Complete and announce initial production deployment of Toolhub | |||
Resolved | sbassett | T273020 Security Readiness Review For Toolhub | |||
Open | None | T288535 Find vulnerabilty scanner to run periodically on Toolhub python dependencies | |||
Open | None | T298987 Find a valid packaging advisory authority for python projects |
Event Timeline
As far as I know, the Python ecosystem doesn't have an official packaging authority; however, PyPA is considered the de facto packaging authority and is generally regarded as trustworthy. PyPA was created back in the day by the team that worked on pip and virtualenv. As of 2021, PyPA is a PSF (Python Software Foundation) fiscal sponsoree.
Whether https://github.com/pypa/advisory-db is a good candidate for our vulnerability scanning needs is a different question.
It probably will be, at least from a licensing standpoint, especially for anything that uses wmcs resources, since those need to be free culture/OSI-compliant. pypa/advisory-db is CC BY 4.0 as-is and also shouldn't be a problem if accessed via osv.dev. Unfortunately, the alternative python safety db is CC-BY-NC, which isn't great and then obviously tools like snyk, though their clis might be OSS, their vuln dbs are very proprietary. There was some related discussion here T304737 about this topic, and is one reason why we no longer plan to offer python safety as an available application security tool for Gitlab CI.