Re: pulling in other vulnerability databases
Hi
On Thu, Jan 25, 2018 at 08:41:43AM +0800, 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.
This is IMHO only part of the truth. Actually MITRE is becoming faster
recently, I think that should be acknowledged as well. One point with
those RESERVED entries is that the (sub-)CNA assigning such should
notify the parent/top CNA about the publication. As you will note with
all the recent CVEs which got assigned by Debian, after publication a
team member did notify MITRE (if they do not notify themself via the
released DSA) and the state changed.
Cf. CVE-2018-0486, CVE-2017-16995 to CVE-2017-16997, CVE-2017-8805 to
CVE-2017-8824.
So it's as well on the responsibility of a project which is a CNA or got
assigned a CVE under "embargo" to notify then MITRE about the
publication.
And good news is that there is work on improving that workflow.
*But* you are right as well, that there are still way to many RESERVED
entries, for published CVEs which apparently never reached back to MITRE
database. I have not done any analysis. So this is only an example:
For 2018 there are currently 46 RESERVED, but already public CVEs. Out
of those at least 3 were assigned by DWF, 2x curl, 1x glibc and I
expect Kurt Seifried of DWF to merge them back soonish. One big hunck
is from the recent Mozilla advisory. All of those I would have expected
that they will merged back by DWF and mozilla in the upcoming few days.
> 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.
>
> 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).
I'm actually not super-excited if non-MITRE feeds are automatically
merged. MITRE CVE database is our master-reference. Those can be
updated automatically. Every other external query should IMHO be
subject to a check for sanity. We have seen quite often discrepancies,
e.g. typos in CVE ids.
Maybe though I'm missunderstanding the proposal :)
Regards,
Salvatore
Reply to: