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

再保险:CNA需求



我最近一直在思考这个问题,主要是因为我希望开始铸造CNA在不长的一段时间。

一些想法:

1)“成熟”安全流程究竟是什么?
2)一个“成熟”CVE过程究竟是什么?

# 1我认为理想的“供应商接受安全漏洞(或发现他们内部)和修复他们,理想情况下一些通知机制(例如更新日志,标签提交,安全勘误表,等等)。我认为这里的彻底的最低接受错误和记录在一些公共的格式,例如在一个bug追踪器。理想情况下,他们会提供一些响应/指导(如一个补丁,或“我们不会修理它,因为. . ")所以人们作出明智的决策。一般大多数项目有这个能力由于托管在一个平台上,有一个bug跟踪能力(例如GitHub)。

2 #反暴力极端主义的核心是CVE #附加到一个安全漏洞,所以最低是多少?明智的描述:

(供应商名称)(产品名称)的版本(版本信息)是容易的(缺陷类型)(组件)产生的一些影响。

是好的,坏的情况下我们生活中可以没有确切的vuln类型(例如CVE - 2016 - 1000002,这是微不足道的验证,实际上我不知道底层vuln),也没有一个确切的影响(例如不少内核错误并不证明是可利用的,但我们都可以同意他们需要CVE和固定)和我们生活中可以没有确切的脆弱性信息(例如,有人可能是笔测试,不知道它到底是什么版本)。显然,信息越多越好。

所以对于# 2我关心的是,中央社做的“质量”CVE作业是正确的(分裂/合并,它是一个实际vuln,等等)。至少这信息将让人们做出决定(做最坏情况我们停止使用这个软件?)等等。

所以对于诸如“供应商回复邮件“我真的不在乎从CNA / CVE的角度来看,只要供应商CNA做适当的cf。特别是在开源世界,我知道一个人负责我们都使用一个图书馆,他每天700 +电子邮件,你猜怎么着?他不会回复你的,除非是超级棒。

所以我认为为自己DWF CNA要求基本上可以归结为“他们问题,推动数据返回上游是正确的CVE ?”换句话说,如果它走,会谈,看起来像一只鸭子,对我来说足够近。


- - -
Kurt Seifried——红帽产品安全——云
PGP A90B F995 7350 148 f 66高炉7554 160 d 4553 5 e26 7993
红帽产品安全联系: secalert@redhat.com


页面最后更新或审查:2016年6月07