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
solutions:
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
people.
> 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.
A.
--
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: