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