Creating a public vulnerabilities database

I’ve been looking for an open-source database of Elixir vulnerabilities, similar to The Ruby Advisory Database, The RustSec Advisory Database, or The PHP Advisory Database. As far as I can tell, there isn’t one for Elixir yet.

Assuming I’m not missing an existing one, would people be up for helping me maintain an Elixir one? I built Dependabot, and want to create a DB for vulnerabilities so that it can immediately create and tag security-related PRs in the same way it does for other languages (details here).


Not sure if it’s the sort of thing you were thinking of, but currently there’s:

1 Like

It could be a nice addition to -

Maybe you could check with them?

There are some CVEs for elixir (just 4 …), maybe you could use them somehow?

1 Like

Yeah, having an unencumbered database would make it easy to add a check command to hex, which would be rad.

I saw Sobelow, and it looks like they’ve got some dependency vulnerability data in there in this folder. Don’t want to duplicate work, but I think it might be better to have a database of static files, like other languages do, that Sobelow could then consume?


I think a vulnerability database would be great as a standalone project. If you (or anyone) ends up creating one, I’m sure it would end up as a Sobelow integration :slight_smile:


Sweet! If you think this is the right approach @griffinbyatt then I think it’s definitely worth doing. I’ll create a repo under Dependabot’s account, unless you want to put it under NCC Group? It lives more naturally with you guys, if you want it. (We used you when I was at GoCardless, btw, and you were great.)

1 Like

The best place for it would be probably under hexpm, I think … The vulnerability reports could also be filed through

I’m sure @michalmuskala, @ericmj, or @wojtekmach would know more about this.

:+1:. I’ll get it started and we can move it later. Obviously a marketing/ego boost for Dependabot to hold it, but I promise not to be pig headed about where it lives in the long term!


OK, here’s my first version. Comments / suggestions very welcome!


@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?


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 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 :slight_smile:



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.



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 made it - redirects to @griffinbyatt blog. And the site, looks like it died on the vine.

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

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

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 :slight_smile:

Longer term, I’d love to see the database become part of 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 - 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


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

I think transitioning the database to 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.


@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:

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:

Snyk highlights some other things as well:

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.

1 Like

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 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.

[2] Create Vulnerability Disclosure Feature