Create Hex.pm Vulnerability Disclosure Feature

Following up on the discussion on Elixir Slack.

It would be really cool if hex.pm would provide a feature like the “Report A Vulnerability” process on NPM.

There would have to be a small team of trusted people reviewing those reports and taking actions based on that report.

I haven’t put much thought into that yet since the idea just came up.

3 Likes

Sounds like a good idea :slight_smile:

Slightly related, there was some talk about expanding Hex.pm a couple of years ago - the thread contains some ideas about incorporating GH stars and other ideas to gauge popularity etc.

Perhaps some of those ideas could be considered at the same time?

1 Like

I don’t see what those features have in common.

They could help people ascertain whether they might want to use the package or not (based on popularity/user recommendations, whether there are any unfixed vulnerabilities etc).

whether there are any unfixed vulnerabilities

GitHub stars are a really bad metric for that. Package Versions with a vulnerability should be retired to show that they are not secure.

2 Likes

For reference, this is how npm handles their process:

  • Any user can send in suspected vulnerabilities via email or a form
  • A security team reviews the reports and takes appropriate action (which is either discard or forward to the maintainer)
  • As soon as the issue is resolved, a security advisory is published (Example: https://www.npmjs.com/advisories/682)
  • After 45 days the latest, the advisory is released even if the issue was not resolved

I really like the process and would like to adapt that to hex with small changes.

Since we have a great retirement feature, we should also retire the affected version as soon as the security advisory is released.

A GPG Key for the security report email address should be published.

The biggest questions is in my opinion how we put together a team to do that job.

1 Like

I see it working like npm’s vulnerability report feature [1]. 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.

[1] https://www.npmjs.com/advisories/report

5 Likes

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.

1 Like

Then it’s imho still better to run the patched version besides the fact that I cannot see a way to relyably detect where someone is deploying to.

2 Likes

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.

1 Like

Ah right sorry. I thought it meant they would no longer be useable when running mix deps.get.

If this idea ends up picking up traction and you do look for a team of reviewers, I’m happy to help out with defining that process and jumping onboard.

I’ve been working in security professionally for a long time, and coding Elixir professionally for a few years, and I wouldn’t mind something like this coming to the Elixir ecosystem.

3 Likes