CVE博客
我们的CVE的故事:一个开源,基于社区的例子
分享或评论
客人作者马克·考克斯的Apache软件基金会自2002年以来CVE董事会成员和Apache软件基金会是一个中央社。
几个CVE编号当局(CNAs)造成了“我们的CVE故事“博客系列CVE网站。目的是教育,预测问题,并鼓励其他人成为CVE社区的一部分。虽然一些CNAs可能或多或少类似,每个CNA是独一无二的,有点不同于其他人。
的Apache软件基金会(ASF)与了CVE项目CNA自8月19日,2016年。ASF开源基金会是世界上最大的超过350个人项目和成千上万的提交者。每一个Apache项目分别管理,由不同的人都是志愿者,包括安全团队。他们的流程不同,基金会的只有几个硬需求的过程,主要是围绕创建发布和处理安全问题。你可以想象,作为CNA创建一些有趣的挑战。
2020年,我们的安全团队收到了超过18000封电子邮件,我们调查了近1000名潜在脆弱性报告。ASF过程主要集中在电子邮件,所以我们利用共享Gmail邮箱和标签来处理传入的安全问题的广泛使用GTD(完成任务)的方法。一旦一个问题已被证实和接受一个项目,他们联系安全团队,我们分配适当CVE id。2020年,我们CVE id分配给151的问题。更多的统计数据和值得注意的细节漏洞事件2020可以看到在这里。
我们有一个默认策略来处理安全问题对所有ASF项目,其中包括确保所有安全漏洞CVE ID分配在一份新闻稿中,无论内部或外部的严重性或如果它被发现,和一个常见的过程披露的信息。直到最近,这个过程需要每个项目创建他们自己的安全咨询文本,而且一旦公共问题,提交CVE记录细节CVE程序本身。安全团队将请求从一个名称分配给项目ASF CVE池分配的项目。对于一些项目,只有一年处理一个或两个问题,这是不小的负担必须学习正确的过程和格式,并导致错误的,有时相当可观的CVE记录发表的时间延误。
我们的目标是消除这些延迟,得到CVE列表更新在一天内或更少的问题发表的一个项目,并添加尽可能多的自动化。要求我们的项目的安全性和开发团队应该是最小的,我们应该减少对项目管理费用和繁琐的过程。我们希望我们的项目处理安全问题的东西是很容易的,而不是他们想要避免的东西。
第一步我们的目标是简化和效率是为项目提供了一种方法来捕捉信息漏洞在一个共同的格式我们可以很容易地向CVE程序。我们开始与Vulnogram工具,举办内部修改版本和连接到ASF OAuth系统用于验证我们的提交者。这允许项目得到所有问题的概述目前处理和为他们提供了一个结构化的方式进入脆弱性数据并生成报告和电子邮件格式所需要我们的政策。
CVE程序的自动化工作小组(AWG)是社区工作的设计、开发和部署的自动化功能,支持CVE项目的有效管理。我们加入了测试组在AWG能够使用他们的新CNA Vulnogram API和改变来支持它。为此,我们成了第一个CNA使用CVE请求API来分配生活CVE ID,所以现在ASF安全团队可以使用web工具来分配一个CVE漏洞文档ID为一个项目并创建准备填写。
一旦一个项目一个问题的状态设置为“公开”,它将通知发送给安全团队。然后安全团队使用JSON格式提交请求cveproject git存储库。把请求通常被批准在几小时内,与CVE网站更新后不久。
展望未来,我们希望能继续合作的一部分通过自动化程序的改进。我们的一些未来的目标包括利用将来的api允许我们提交漏洞JSON格式的数据直接从我们的工具。我们也计划一个混合的方法,我们有一组项目,一直在训练正确的CVE ID和分配将能够完成所有的步骤通过提交所有请求CVE ID。其他项目,那些很少使用的过程中,将获得更多的安全团队的指导和审核。
我们也刚刚开始使用JSON数据为一个项目生成自动化咨询页面,Apache HTTP服务器,也会看看扩展这个给别人。
另一个在做这项工作的一部分,我们的目标是将知识从我们的经验作为一个更大的CNA CVE社区提供反馈。我们认为这个经验和知识可以帮助别人。
总之,我们迅速拥抱最近CVE项目创新的过程,使处理CVE IDs更快更有效。我们兴奋的前景,可以减少安全问题的处理繁琐,更快,轻量级的。这不仅有益于我们项目通过释放时间我们全部成员,也是我们项目的用户通过确保脆弱性信息更新和快速、持续可用。
| - - - - - - | 马克·j·考克斯 | |
| 安全副总裁 | ||
| Apache软件基金会 | ||
| 2021年4月12日, |
