pulling in other vulnerability databases
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.
Where should we start to implement the above? Any pointers to where a
Python dev might look in the security-tracker source to actually work on
this? It seems this would also affect the DSA/DLA release process - i
think it *is* possible to actually release a CVE-less DSA right now, but
I wonder if the process would stall in other places...
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?
Sorry to bring so many questions and so few answers, but I figured it is
useful to actually scope out the problem better before starting an
implementation. :)
A.
--
Il n'existe aucune limite sacrée ou non à l'action de l'homme dans
l'univers. Depuis nos origines nous avons le choix: être aveuglé par
la vérité ou coudre nos paupières.
- [no one is innocent]
Reply to: