To provide a shorter response: I'm in no way saying its the only tool to use, its just one part of a process. I'm also not saying we're going to rely solely on NVD in the future, hence my comment regarding "increase the amount of information", i.e. we would monitor multiple sources within cve-check-tool, and cve-check-tool is just one part of a set of tools. Regardless, this topic derailed quickly, I simply provided you with a means and a set of potential CVEs - my main interest is if someone intends to look into the patch naming situation. I don't use Arch Linux myself so wouldn't be the one to be able to implement it without assistance. - ikey On 16/04/15 00:32, Levente Polyak wrote:
So cve-check-tool deals solely with non-embargoed CVEs, and as such the CVEs known to distributions are handled differently. An example of this is the recent openssl updates, whereby the CVE was marked as "reserved" for a fair amount of time. This is naturally because these are high publicity projects, and it gives everyone plenty of time to migrate.
We've already got a few things being worked on at the moment to monitor these hi-p projects to increase the amount of information available to cve-check-tool at any one time.
Note for relatively normal CVEs (99% of them) they appear rapidly within the DB, and we index/check every vuln from 2002 up to the current minute (NVD is resynced every 3-4hr)
No, its simply not true! It lacks behind often a lot, even for non embargoed and publicly disclosed vulnerabilities which often even have PoCs attached. Even for initially embargoed CVEs after the vendor releases a own advisory its still unavailable after multiple months.
Most of the time if we write advisories for Arch Linux then we have to point to Red-Hat or mitre as the NVD does not contain the CVE yet (and most of the time that has nothing to do with embargoed CVEs like the openssl case) as those were disclosed on public lists with full details and CVE IDs were assigned by mitre. During distribution level of mitigation we experience over and over again that NVD is hanging behind for some non-embargoed CVEs for days, weeks and sometimes moths.
You can check our CVE page [0] or the released advisories [1], if at the point we write an advisory the NVD contains the CVE already, we are always using that as a reference link. If its not available then we use something different, please note how often some other links are used to that particular point of time (also several of the non embargoed CVEs on the CVE [0] page do *still* not have a association in NVD!
After a fast 5min search just to name some, which are disclosed for a very long time and still have no entry in NVD: - icecast: CVE-2015-3026 - tor: CVE-2015-2928 CVE-2015-2929 - musl: CVE-2015-1817 - webkitgtk: CVE-2015-2330 - sudo: CVE-2014-9680 - ntp: CVE-2014-9297 CVE-2014-9298 - postgresql: CVE-2014-8161 CVE-2015-0241 CVE-2015-0243 CVE-2015-0244
Don't get me wrong, your tool is great and useful, but trust me, only monitoring NVD for a distribution level of mitigation is *very* far from being optimal, enough or up-to-date (also when monitoring some of the "hi-p projects"). Please don't take this as offense.
cheers, Levente
[0] https://wiki.archlinux.org/index.php/CVE [1] https://wiki.archlinux.org/index.php/Security_Advisories