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
