(日期:][下一个日期][线程:][线程下][日期索引][线程索引]

再保险:CVE托管服务



在2017-02-24下午,耶利哥写道:>没有,味道中,使用“CVE”作为ID计划的一部分。> >完全没有逻辑的或有益的理由这样做。我曾以为不会改变的计划,但是没有很多的想法。不确定我看到一个逻辑或有益的理由创建一个单独的“服务”计划,但我不一定对。> (CVE支持两个前缀计划十年(CVE和可以)。有两个方案的原因,世界改变,CVE进化而来的。我记得它是相当繁琐(虽然这可能是值得的初期CVE)。在这个讨论可以/ CVE是什么意思?>——许多组织将不希望跟踪在线服务,以及混合> >会非常痛苦的覆盖率(指标|百分比)等。> -一些组织可能更感兴趣的是云/服务跟踪>(如公司存在多云服务本身)似乎是合理的。有另一种国旗“服务”vulns吗? Keeping in mind the continued blurring of product and service. Not a reserved block of IDs. > - For the countless vuln tourists (both individual and companies) > that do > yearly stats entirely based on CVE and not understanding CVE at > all, > this will forever make ALL stats they generate entirely worthless. > I > mean, they are already worthless, but this will make it more so. Counting is broken, for many reasons, which you know better than most. That's as much a function of the nature of vulnerabilities as it is the effort anybody puts in to counting. Identification, identification, identification. > - Did I mention there is no logical reason to mix them under a > unified CVE > identifier? =) You did, but I throw the tautology flag :) - Art

页面最后更新或审查:2017年2月28日