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).
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
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.)
. 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!
@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 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
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.
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.
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.
Happy to help with anything on the database, be that:
keeping merging PRs as/when folks submit them to the database
add additional maintainers to the database (after auditing their GitHub account, of course)
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.com/advisories. That DB
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.com/advisories - 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 https://github.com/dependabot/elixir-security-advisories.
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.com/advisories 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.
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:
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.
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.
. 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!
