CAN和CVE的区别

 

CAN/CVE号码

你或许看到过随安全问题出现的CAN号码或CVE号码。例如看起来类似“CAN-2004-0397”或“CVE-2002-0092”。

两种号码都代表了相同类型的实体：在http://cve.mitre.org/上维护的“常见漏洞和曝光”列表中的一个条目。这个列表的目的为所有已知的安全问题提供标准化的名称，这样每个人都可以在讨论时使用唯一的标准化的名称，并提供一个可以查找更多信息的中心地点。 “CAN”和“CVE”的唯一区别是前者代表了候选条目，还未经CVE编辑委员会认可，而后者则是经过认可的条目。 然后，两种类型的条目都对公众可见，条目的编号不会随着认可而改变—仅仅是“CAN”前缀替换成了“CVE”。

CAN/CVE条目本身并不包含bug的完整描述，以及如何防范的信息。相反，它只会包含一个简短的摘要，然后是到参考和外部资源的列表（例如邮件列表归档），人们可以去查看详细信息。http://cve.mitre.org/的真正目的是提供一个组织良好的空间，每个漏洞都可以有一个名称以及获取更多信息的途径。一个条目的例子可以看http://cve.mitre.org/cgi-bin/cvename.cgi?name=2002-0092。请注意，引用可以非常的简洁，其中的来源表现为神秘的缩写。这些缩写的关键点可以看http://cve.mitre.org/data/refs/refkey.html。

如果你的漏洞达到了CVE的标准，你或许会希望得到一个CAN号码。这个过程是故意封闭的：一般来说，你需要认识某人，或认识某人认识某人。这并不是表面上的那么疯狂。为了避免被伪造的或编写糟糕的提交压垮，CVE编辑委员会只从已知和信任的来源获取提交。然而，为了获取你的漏洞列表，你需要从你的项目找一个CVE编辑委员会认识的人。在你的开发者中询问一下是否认识某人之前曾经完成过CAN过程，或知道某人会认识。这样做的好处是该链路上的某处，某人会知道足够的信息告诉你 a) 根据MITRE的标准，它不会作为漏洞或曝光，所以没有提交的意义，或者 b) 这个漏洞已经有了CAN或CVE号码。后者可能是因为该bug已经在另一个安全忠告列表上发布了，例如位于http://www.cert.org/或者位于http://www.securityfocus.com/的BugTraq邮件列表。 （如果是在你的项目对此一无所知的情况下发生了这种情况，你一定会担心还有什么不知道的。）

如果你已经得到了CAN/CVE号码，你一定希望尽早将其纳入bug研究中来，这样以后的所有交流都可以引用这个号码。在公布之前，CAN条目会被禁止访问；这个条目会作为占位符保持（这样就不会丢失名称），但不会揭示任何漏洞信息，直到你宣布此bug并修正了它。

关于CAN/CVE流程的更多信息可以查看http://cve.mitre.org/about/candidates.html，一个开源项目中使用CAN/CVE号码的例子可以看http://www.debian.org/security/cve-compatibility。