I see it working like npm’s vulnerability report feature . We have a form on hex.pm where vulnerabilities can be reported, when a new report is submitted it will be reviewed and if it is determined that there may be a security issue we will notify the package owners. The report will be disclosed publicly after a fix has been released or after certain of days regardless if there is a fix.
It can be integrated with mix hex.audit and package versions with publicly disclosed vulnerabilities should have it visible on their package page.
The reviewers would be a group of volunteers that are trusted in the community and have a track record of working on security issues.
Implementation wise for Hex it is not a lot of work, the bigger problem is putting together and organizing the group reviewers.
To keep the scope small I suggest we focus on the vulnerability reporting instead of including other features such as GitHub integration.
What if the vulnerability is an edge case or considered minor for some? For example, a vulnerability that only exists when using a certain OS? There could, for instance, be an issue when using a package on say a Windows machine, but it wouldn’t impact all those who deploy to a Linux box.
The retiring of a version does not prohibit users from using it. It shows them that there is a problem and has a text explaining the problem. Therefore users that are not affected can either do nothing or still update to a hopefully existing patched version.