[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: pulling in other vulnerability databases

On 2018-01-25 09:07:37, Salvatore Bonaccorso wrote:
> 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.

Agreed. My experience with the CVE process has been generally positive
recently, if a little confusing. I wasn't advocating we give up on the
CVE process, I must admit this was sort of a straw men argument here. ;)

But I am deeply concerned by the amount of shade there is in there. I
think pabs has a good idea here that we could tap into those sources
somehow: those are real vulnerabilities, with real impacts, and we need
to be aware of those. In jQuery, some of those had been disclosed for
years until I just happened to stumble upon them haphazardly.

This process doesn't work. From what I understand, there are two

 1. convince those other vendors (e.g. Snyk) to properly follow the CVE
    process somehow

 2. do that job ourselves.

If we keep with the CVE process *and* we suck the other feeds into our
system, then we effectively commit to doing #2 here, so that's something
to keep in mind as well.

To go back to pabs' original list:

> Competition for Mitre & CVEs (Snyk)
> Language communities (NodeSecurity)

Those two should just follow the CVE process. They partly do already as
some of their issues *are* linked to CVE identifiers when they are
available. But they could become CNAs themselves and have the capacity
to issue CVEs, if mitre is too slow for them, for example.
> OS vendors (RH/SUSE)
> Upstream projects (Xen, Linux etc)

I believe those already follow the CVE process and eventually converge
over doing the right thing. So I am not really concerned about those

> Security community (oss-sec, fulldisclosure, conferences etc)

This is a much fuzzier and wider list, however. oss-sec, iirc, does
follow the CVE process, whereas fulldisclosure
is... er... different. And the community as a whole has wildly varying
views of the CVE process, I'm not sure it's realistic to convince the
community as a whole to follow what we think is the right process.

I also do not see exactly which databases we could follow here: very
often those are just discussion forums and intangible spaces without a
formal database. So while I'm concerned about the culture of our
security communities, and esp. about the political and ethical
implications of 0day hoarding, for example, I am not sure it's within
the scope of what we can do in the security tracker here. :)

So, regarding the first two (and similar), someone needs to teach those
folks about proper security tracking here... ;) Should I contact them
directly? Or maybe someone with more credentials from the security team
would have more weight?

Thank you for your time.


It is not enough to fight for the land; it is even more important to
enjoy it. While you can. While it’s still here.
                        - Edward Abbey

Reply to: