Hi Antoine, On Wed, Jan 24, 2018 at 12:12:41PM -0500, Antoine Beaupré wrote: > So picking one thing from this thread and adding the security tracker > people in the loop, so we can focus on *one* topic here. :) > > On 2018-01-21 14:09:01, Paul Wise wrote: > > On Fri, Jan 19, 2018 at 11:52 PM, Antoine Beaupré wrote: > > > >> I have found that Snyk had issues in its database that weren't in Mitre: > >> > >> https://snyk.io/vuln/npm:jquery > > > > I note that nodesecurity also has some CVE-less issues: > > > > https://nodesecurity.io/advisories?search=jquery > > > >> Finally, I wanted to bring Snyk.io to the teams' attention. I'm a little > >> disturbed by that new service - I feel there's significant overlap > >> between their vulnerability reporting process and Mitre's DWF/DNA > >> process, even down to using Google forms to welcome submissions, in the > >> case of DWF (!!). The Snyk (closed) database tracks vulnerabilities in > >> web apps, mostly, covering the following languages: Golang, Java > >> (maven), Javascript (npm), .NET (nuget), PHP (composer), Python (pip), > >> and Ruby (rubygems). I haven't done a formal study, but a quick glance > >> at the latest issues show that only a small fraction of the issues > >> reported there have CVE IDs at all. > >> > >> This connects with the question of how to track issues without CVEs. In > >> general, that is a problem we have in the security tracker because it's > >> so bound to CVE identifiers. But this is a new problem as well: by > >> opening a new process for submitting vulnerabilities, this system > >> potentially bypasses the CVE system altogether, using a > >> commercial/proprietary backend. I am worried about the impact this will > >> have on our triaging efforts and wonder where we should go from here. > >> > >> Food for thought? > > > > I would guess there are a lot of different vuln databases out there: > > > > Competition for Mitre & CVEs (Snyk) > > Language communities (NodeSecurity) > > OS vendors (RH/SUSE) > > Upstream projects (Xen, Linux etc) > > Security community (oss-sec, fulldisclosure, conferences etc) > > > > Each of them have their own identifiers and possibly also link to CVEs. > > > > I'd suggest we need (semi-)automated ingestion of all of the above, > > like we currently have for CVEs. > > Okay, so this is a broader, recurring problem we have with the security > tracker right now... From my perspective, I've always and only used CVEs > as unique identifiers for vulnerabilities in my work in the security > tracker. When that was not possible, say because a CVE wasn't issued > yet, CVE-YYYY-XXXX templates were used, which leads to ugly TMP-FOO > markers in the web interface. > > Are you saying there are ways, right now, in the security tracker, to > use non-CVE identifiers as unique markers in a meaningful way? I > remember we discussed using BTS bug numbers in the past, but right now > those are, as far as I know, bound to entries in data/CVE/list only.
We can use CVEs and as fallback Debian Bugs as unique identifier. But for releasing a security update we do not have arequirement that a CVE has already to be assigned (ideally it is, because it makes identifying and tracking it easier in the long term). If no CVE is assigned, and no bug is present, just fill one for the tracking purpose. And btw, MITRE had admittely some problems in past to timely assign a CVE to issues, but this is becoming increasingly better, CVEs are assigned (on proper requests) quite fast in meanwhile. > And are we admitting here that we should just give up on the CVE process > in those cases? Or should we make an effort (say like we do in reporting > bugs against packages in teh BTS) to actively seek CVE identifiers for > vulnerabilities that lack them, like I did for the jquery issues? Please do not give up on the CVE process, when there is need for an CVE identifer, please continue to request such. Regards, Salvatore
