回复：关于CVE良好的请求的讨论

2016年5月12日，星期四，晚上9:49，艺术<amanion@cert.org>写道：

在2016-05-12 20:18，Kurt Seifried写道：

> <http://cveproject.github.io/docs/requester/Reservation-guidelines.html> ____

>因此，对于DWF处理开源漏洞，我的计划是
>目前对于一般情况：
>
> CVE所需的最低要求：
> -oftware名称（和/或URL，如果它是不止一次使用的通用名称）
> - 可vlynerable版本（一个或多个）
> - 基本缺陷（CWE）或可靠触发它或一些的工作复制器
>缺陷的体面描述（做X/Y/Z，并且发生了这奇怪的事情
>具有安全影响）

我认为不错的描述成为CVE名称/标题？还
即使还有一场良好的CWE匹配，也应需要标题名称。
诸如“供应商产品（组件）具有CWE-123”之类的东西。鼓励
好的标题，但接受任何合理的东西。

因此，例如，这是Red Hat最近的一些CVE分配（删除了源信息）：

CVE-2016-3710 QEMU：在VGA模块中检查不正确的银行访问界限

CVE-2016-3711 Haproxy：设置包含OpenShift Pod的内部IP地址的cookie

CVE-2016-3714 ImageMagic MVG 1.外壳字符过滤不足导致（潜在的远程）代码执行

CVE-2016-3715 ImageMagic MVG 3.文件删除

CVE-2016-3716 ImageMagic MVG 4.文件移动

CVE-2016-3717 ImageMagic MVG 5.本地文件读取（由原始研究作者独立报道 -https://hackerone.com/stewie）

CVE-2016-3718 ImageMagic MVG 2. SSRF

这大致是我正在查看的（例如，ImageMagick的内容只是从要求CVE的原始电子邮件中直接出发）。

以上是否足以让MITER导入和创建CVE条目？我认为
目前，也有一些信任/权威的公众参考
必需的？

我的目标是确定最低限度，强烈推荐（本质上，豁免的唯一请求将是具有提出完美请求（例如OpenStack或Samba）的历史记录的要求），理想地开始培训人们添加请求的人（CVSS得分数据将会将其添加到请求中）使此数据更加有价值，正如NIST这样做的事实所证明的。在所有这些信息的理想世界中，自动描述将是微不足道的（变量的字符串将无问题）。

> CVE非常需要（不是强制性的，但最好有一个好的
>没有这些的原因）：
> - 影响组件（例如函数名称，Web应用中的URL等）
> - 链接或脆弱代码的示例或代码修复的链接或示例
> - 如果您无法解释什么，安全影响是什么（AIC？）
>剥削实现我们有问题
>
>请求CVE（它将加快速度）：
> - 固定版本/提交
> -CVSSV2/3评分信息

以上所有内容将在DWF CSV行和集合中实现
文物？需要最小的JSON文件吗？

- 艺术

正确，JSON文件中将具有4个数据层次结构：

-dwf（强烈调节/格式化）

- 社区（提供指南，可能是一些法规）

- 实验（事物内的任何事情都会发生）

- 供应商（强烈调节的，本质上是采购信息和供应商特定的DWF类型信息，例如供应商特定的CVSS2评分）

- -
Kurt Seifried-红色帽子 - 产品安全 - 云
PGP A90B F995 7350 148F 66bf 7554 160d 4553 5E26 7993
红帽产品安全联系人： secalert@redhat.com