Creating a public vulnerabilities database

There is a Google Summer of Code proposal project [1] for adding features to Hex that will allow users to report security vulnerabilities, maintaining a database of confirmed vulnerabilities, and displaying the reports on the hex.pm website and CLI tooling. I have talked about this in the past [2] and I hope it can work similar to NPM’s feature set for reporting and curating vulnerabilities that @kitplummer linked to.

[1] Home · erlef/gsoc Wiki · GitHub
[2] https://forum.elixirforum.com/t/create-hex-pm-vulnerability-disclosure-feature/15905/7

I’m definitely interested in picking up the “let’s make the Elixir package ecosystem better” torch. By better I mean pretty much replicate NPM’s response:

• Create a “security” effort: https://www.npmjs.com/policies/security
• Make the advisories core to Hex.pm: https://www.npmjs.com/advisories
• Inform about currency: https://docs.npmjs.com/cli-commands/outdated.html

Snyk highlights some other things as well: 10 npm Security Best Practices | Snyk

And I also believe there’s a need to address other obvious risks: such as the reproducible build problem and general bus-factor of the flattened package ecosystem/transitive dependency matrix explosion.

@kitplummer I kind of put that project on ice since it basically got no traction at all from the community.

If you’d like to pick it back up, you’re very welcome to do so. If there’s any interest in the community, I’d love to make this work as well.

I’m also thinking it would make sense to get mix_audit into Hex, as a first-class citizen.

That’s what I wanted to test-drive with this repo: GitHub - ex-security-advisory/cli-client: ⚠ Client for the Elixir Security Vulnerability Project API. · GitHub

Expanding the scope a little bit. I’d like to see more responsibilities for these things within the hex.pm ecosystem - as the centralized package source. Curious what you guys think about https://reproducible-builds.org too.

I think transitioning the database to GitHub Advisory Database · GitHub makes sense as things evolve at Github.

I’m also thinking it would make sense to get mix_audit into Hex, as a first-class citizen. I believe the “audit” task and reproducible builds would go a long way to “assuring” the quality of the package/dependency environment.

Caveat, I’m doing a little bit of research into the Hex ecosystem, in terms of risk associated with dependencies and source repositories. I know similar things have been done on the NPM and Python ecosystems - both to raise aware of security in dependencies and adjudicate packages (especially critical ones). I’m tying a few loose ends then will make my work available (probably here first) then to the wider Elixir community. Will of course appreciate any feedback.

One of the obvious things is that Hex doesn’t require or verify source repositories - in fact the spec provides only an arbitrary place for a source link (with an arbitrary key) making it difficult to traverse from package to source in any automated way. Not impossible, but any complexity or lack of standard creates potential holes.

Happy to help with anything on the database, be that:

1. keeping merging PRs as/when folks submit them to the database
2. add additional maintainers to the database (after auditing their GitHub account, of course)
3. transferring the database to another namespace, if folks want

When I started the database I was building Dependabot, which was directly consuming from it. Since then, Dependabot got acquire by GitHub, and I ended up working on all things related to code scanning there. Dependabot still consumes the database though

Longer term, I’d love to see the database become part of GitHub Advisory Database · GitHub. That DB

• is licensed under Creative Commons Attribution 4.0, which I think is acceptable
• is easy for maintainers to contribute to (for supported languages, which don’t yet include Elixir) and linked up to a flow where GitHub will issue CVEs when required/desired (which is already supported for Elixir)
• receives dedicated curation (we have folks at GitHub who are paid to maintain it and to review all entries in the NVD for missing entries)

We’re not there quite yet on adding support for Elixir to GitHub Advisory Database · GitHub - the blocker on GitHub’s side is having our curation tooling and team in a place where they can take on new languages. In the meantime I’m more than happy to keep doing the right thing on GitHub - dependabot/elixir-security-advisories: Old database of Elixir security advisories before the GitHub Security Advisory DB supported Hex / Elixir. · GitHub.

Yeah, there are very few security advisories being published in the Elixir community. Seems like most security vulnerabilities just gets patched without any advisory.

It’s unfortunate, but I don’t blame devs. I use GitHub Security Advisories but have no idea how I otherwise would handle the process of getting CVE id and such. Github makes it so easy, so hopefully it’ll ease the burden and we’ll start to see a lot more advisories being published.

The good thing is that the repo is active, and services like dependabot uses it.

Edit: It would be really nice to see that repo being a more integrated part of the Elixir community though. Maybe used on hex.pm.

Couple years later…

Doesn’t seem like there’s a lot of action in the database. Probably a combination of research isn’t happening on Elixir things - at least out of the Phoenix and its periphery. Maybe with mix_audit getting going it’ll help.

Doesn’t look like elixirsecurity.com made it - redirects to @griffinbyatt blog. And the elixiradvisories.org site, looks like it died on the vine.

I wouldn’t mind help picking on the elixiradivsories.org @maennchen - at least to get it back to displaying thing correctly. Have a few other thoughts…

Awesome!

Agree a web API to serve the data is the way to go - should be easy to use the GitHub repo as a backend for that, too, and get the benefit of making it easy for folks to contribute.

Glad you’re going through with this! I think the amount of detail looks great. As far as format for Sobelow, I think ultimately a web-API around this data will be most useful. I bought the elixirsecurity.com domain a while ago for pretty much exactly this use case.

Definitely happy to help out on this/support new findings. I’m fairly busy over the next couple of weeks, but feel free to tag me in an issue on Github if you want to brainstorm

@griffinbyatt - particularly interested in your feedback, since you found most of the vulnerabilities in there! Would the format work for Sobelow? Would you like more details stored on each vulnerability?