再保险:CNA规则公告

    我认为这个问题属于扫描仪厂商或NVD,谁应该
    担心影响到底是哪个供应商,软件版本,
    和哪个报告适用于扫描报告
    发现。这使我想起了史蒂夫的咒语,“CVE不是
    漏洞数据库”。基于这个咒语和论证
    基于一个提供全面服务的漏洞数据库可以或应该
    理想情况下,我相信CVE不应该扭曲。除此之外,
    我敢打赌,扫描仪将报告* *如果他们不能这样的cf
    确定供应商,并计算它们作为单独发现的
    目标(即使Kens建议“主”的CVE留存,
    将使CVE层次如CWE)。
我想象这个报告:“你有247823在你的网络漏洞!”
    我赞成单一CVE,避免使它的东西
    等级制度。
    布莱恩再次感谢复制cve-editorial-board-list,我从来没见过
    的孩子的消息。
帕斯卡在10/07/2016 08:26点,耶利哥写道:
> 在星期五,2016年10月7日,孩子叫Nandakumaraiah写道::>例如,IBM: >一直使用cve - 2014 - 8730的产品,尽管早期的改变:>条目从斜方专门指定它只对F5产品。::按照新规则(CNT3),一个共同的弱点在“协议:实现”应该得到一个CVE。因为这是“相同:特定的常见的错误”的TLS协议实现虽然:协议规范中没有问题。似乎像一个:合理使用新规则引用这个漏洞有:单CVE id。前进,但追溯试图执行的问题,已经有一定程度的抽象,不工作。当前的抽象和作业在一年多的地方需要。:新规则更符合消费者如何使用cf指:常见的漏洞。当我们的客户问我们关于“TLS的贵宾犬”:他们使用cve - 2014 - 8730来引用这个漏洞。当:漏洞扫描器扫描,他们可能会发现cve - 2014 - 8730的一个实例。:告诉客户,斜接说F5 cve - 2014 - 8730是有限的:产品只会令人困惑,可能导致错误的解释。不知道每一个扫描仪呢。 There is a lot of value in having a per-vendor finding in that case, else that single finding will come with a list of 250+ advisories that are not easily distinguished from each other, that carry the solution. A per-vendor plugin/scan basis would allow for much more friendly reporting when it comes to the solution. Many people aren't aware of this because they haven't seen a VDB actually track affected products to that degree. I can assure you that the 'mega entries' of VulnDB where it is a single entry for a protocol vulnerability are unwieldy and not as user friendly as the abstracted implementation issues. We have entries with over 500 advisory links and well over 1,000 products impacted. That is what many companies have been demanding for vulnerability management, yet most VDBs have never bothered with it. Brian
>