Re: pulling in other vulnerability databases
On 2018-01-25 08:41:43, Paul Wise wrote:
> On Thu, Jan 25, 2018 at 1:12 AM, Antoine Beaupré wrote:
>
>> 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.
>
> That is how things are supposed to work indeed.
>
>> Are you saying there are ways, right now, in the security tracker, to
>> use non-CVE identifiers as unique markers in a meaningful way?
>
> Not AFAIK. I think that having non-CVE identifiers on hand is a useful
> but secondary goal. Achieving the primary goal also makes it easier to
> achieve this too.
>
> I'm mainly pointing out we need better automated ingestion of
> vulnerability data for multiple reasons:
>
> Mitre is *very* slow at unrestricting CVE information after a project
> has published advisories, just look in CVE/list for things that are
> still RESERVED but we have data for.
It was said by others, but I also want to stress that I've witnessed a
welcome improvement in the processing speed at Mitre. They are getting
better at this - it was this or complete failure, so I guess they had no
choice. :)
> There are more vulnerability databases than just CVEs and this problem
> is not going to go away. Some of these may (partially) overlap with
> the CVE database.
I think we should *try* to make other databases sync up with the CVE
process. The security tracker itself is such a database, and we *do*
that process. We're not special: others, especially when they are
corporations like Snyk, should follow established community
standards. We should hold them up to this publicly.
> The manual ingestion of vulnerability information into the security
> tracker currently falls mainly on just one person (carnil). Having
> just one person do all of that work isn't fair on them and does not
> scale. If we automate more ingestion then there will be less latency
> and he will have less work to do and be able to focus more on other
> things like vulnerability feeds that aren't automatable (like mailing
> lists).
Yeah, that's tricky business. I am constantly impressed by the amount of
work done by the security team, so I can certainly appreciate this! So I
think it would be interesting to have semi-automated tools to inspect
external databases and make sure we're not missing anything. We
shouldn't inject the data automatically like we do for authoritative
sources like Mitre, however, because that could become really chaotic;
it could actually *increase* the load on the team, because of the
increase in (possibly) unreviewed material coming in.
[...]
> First we should decide if we want non-CVE identifiers and define how
> we want to represent non-CVE identifiers in data/CVE/list. I would go
> for yes and something like this:
>
> CVE-2017-17565 (An issue was discovered in Xen through ...)
> ...
> ID: XSA-251
>
> Next the database would need an additional identifier mapping table.
See, I'm lost here. Why would we have non-CVE-identified issues in
data/CVE/list? Shouldn't this be something like data/XSA/list in this
case?
The problem that you quickly run into is that you *will* have
duplication between those lists. Right now, CVE ids are a "primary key"
in data/CVE/list - if we add entries *without* CVE ids there, things get
confusing fast (i know we already do, but it's a temporary measure). And
if we add non-CVE identifiers *elsewhere*, we add the extra load of
filtering out duplicates...
So I guess I'm answering my own question: injesting other databases is
not really feasible.
[...]
> I think the GSoC or Outreachy would be an ideal way to achieve this
> and wrote a proposal a couple of years ago, but couldn't find anyone
> interested in mentoring it. ISTR last time I brought up this idea it
> was dismissed as a bad idea.
>
> https://wiki.debian.org/SummerOfCode2015/ProjectProposals/SecurityTrackerCheckExternal
I think it would be a good idea if it would be restricted to a simple
triage / audit mechanism, not an automated ingestion mechanism.
>> 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?
>
> I don't think it is a good idea to give up on the CVE process and I
> think doing so would be a violation of the Debian Social Contract. In
> my opinion it would be a good idea (modulo workload issues) to seek
> CVE identifiers for vulnerabilities reported in all vulnerability
> databases, just like is done for the BTS (tag=security is kind of a
> vuln db) and other locations.
I think it's fair to say we all seem to be in agreement that we want to
keep going with the CVE process. :)
A.
--
We know the road to freedom has always been stalked by death.
- Angela Davis
Reply to: