CVE IDs

[maennchen]

It would be good if we'd always request a CVE-ID for each new vulnerability if it gets added here. This is for two reasons:

• Make the Vulnerability Identifiable across other security advisory systems / references
• It would make a far better filename for the yml files since two can happen at the same day.
• It would make the ID for API entries of #3 more stable than a package name / date combination.

[maennchen]

BTW: I also requested one CVE ID for the ecto vulnerability to get them complete: https://github.com/dependabot/elixir-security-advisories/blob/master/packages/ecto/2017-08-27.yml

(Didn't hear back yet)

[greysteil]

I'm definitely pro including CVE-IDs wherever we have them, but I don't want the process of requesting them to slow down reporting vulnerabilities.

Is there anything else we could do on stable IDs that would fix that issue? (I appreciate that there's not much else that will fix the problem of identifying across systems.)

[greysteil]

If we ever have multiple vulnerabilities for the same package on the same day I was planning to just add -2 to the end of the filename, btw.

[maennchen]

We could just take a unique id (maybe not as long as UUID) as a base or do something similar to the CVE process.

The CVE process would mean to pair the year with an incrementing number.

[greysteil]

I'm fine with whatever, to be honest, as long as it's easy for anyone to submit a valid PR to this repo.

Shall we revisit when you're implementing the side project and you have a concrete idea on what would be most useful? Don't want to add a new id field if it turns out not to be necessary.

[maennchen]

Sure, let's discuss this again as soon as I have something to show on that front. For now, the filename is the id (which leaves some problems if a file is renamed).

[greysteil]

We ended up adding an id column, which must be a unique UUID. There's a link in the README to a generator.