再保险:CVE计算文件的草稿

在08/24/2016 04:54点,Kurt Seifried写道:
> 一些反馈:上下文中的一个漏洞CVE程序,是可以利用的代码,导致负面影响保密,完整性和可用性,需要一个代码更改来减轻或地址。一些vulns内部协议和唯一的代码更改,“补丁”是完全删除代码/功能。我们可以添加“一般要求”吗?我担心软件/ API的交集vulns将越来越普遍(多个实例,和人们会开始寻找)。
>     
    确实有cf发出协议(例如,
    针对SSLv3 cve - 2014 - 3566),这样甚至不是代码本身。然而,我
    认为“一般”将定义为决定是否不切实际
    一个特定的实例是一个漏洞。我建议:
    “CVE漏洞在程序,是用代码表示
    可以利用,造成负面影响
    机密性、完整性和可用性,需要一个编码
    变化,规范改变或规范缓解或弃用
    地址。”
> INC4:我们能更好的定义公共/私人吗?例如如果一个医疗设备制造商计划使用CVE为一个问题,然后他们会通知用户直接的?同上航空/ SCADA /等。
>     
    我不确定我理解你想要发生的事情。有限的
    扩散?作为一个客户,我很困惑得到通知说
    CVE我不能在公开网站上查找,如果这就是你
    的意思。如果你是被禁止的问题,不是CVE这样做了吗?
> INC5:“CVE id分配给产品customer-controlled或customer-installable。”前提方案上锁定呢?我知道很多医疗设备、高端制造、等你买它,但你不要碰它,公司技术服务。同上等其他监管项目电梯(合约地大多数电梯维护涉及到“如果有人但我们触摸它,你保证是完全空白”)。
>     
    我猜INC5的目的是确定客户可以修补
    或降低脆弱性。然而,我认为这是同样
    有用的能够跟踪如果管理解决方案的提供者
    应用补丁或者减轻漏洞,所以我赞成
    更广泛的使用cf。这适用于无论它是开放的
    源解决方案管理代表你或别的喜欢的人
    固件或一个完全封闭的解决方案。
帕斯卡