安全和Zephyr项目

David Brown是Linaro物联网和嵌入式（Linaro IoT and Embedded，LITE）工作组的安全主管。除了物联网设备的一般安全性之外，David还是MCUboot安全引导加载程序项目的维护者。David来自Zephyr项目银牌成员Linaro，现在担任该项目的安全架构师。

Zephyr项目的宪章的一部分规定将有一个安全小组委员会。这个委员会由每个白金会员公司的个人以及两个选举产生的职位组成，一个安全架构师（现在是我）和一个主席。主席负责定期召开安全会议（每两周举行一次），架构师负责项目的整体安全。

在过去，这个安全小组委员会（通常称为安全团队，有时称为安全工作组）生成了一组描述项目安全目标和过程的文档，并开发了一个初步的威胁模型。

最近的一个发展是关于管理已发现的漏洞的过程，包括CVE系统。在我们的项目外部，CVE数据库（常见漏洞和利用）分配一个唯一的标识符，每个漏洞发现跨任何参与项目。2017年9月7日，Zephyr项目成为CNA或CVE编号机构。通过生成描述我们流程的特定文档，这允许我们控制CVE的分配，以便我们能够自己管理这些CVE。

感到脆弱

CVE系统背后的关键思想是漏洞的思想。考虑漏洞的一种方法是，它描述了系统的一个特征（通常是软件缺陷），可以利用这个特征在系统中造成意外或意外的行为。这些操作的后果可能是轻微的麻烦，也可能是毁灭性的，比如允许远程特权升级，甚至可以控制设备。CVE系统就如何分配这些数字以及如何确定优先级提供了许多规则和指导方针。

在2020年5月，该项目收到了一份来自NCC小组的报告，概述了在Zephyr代码基中发现的几十个漏洞。我们开始为此分配CVE，并改进和记录我们用于跟踪这些问题的方法。

因为从某种程度上说，这些漏洞是可以利用的，所以不要过早地泄露这些信息是很重要的。理想情况下，应该在漏洞本身的信息发布之前将修复程序传播到终端设备。除了这样做的常规挑战之外，作为一个开放源码项目也使得这一点更加困难，因为开发本身是在开放的环境中完成的。

跟踪问题

我们通过几种方式来解决这个问题。首先，我们不使用常规的Zephyr bug跟踪系统来跟踪这些漏洞。我们有一个单独的JIRA实例，它被配置为支持禁运或隐藏的问题，直到达到禁运日期为止。由于在Github上，补丁的开发和其他变化是一样的，这就增加了这些补丁的复杂性。一般来说，开发人员会尝试在提交文本中描述已经修复的内容，而忽略解释问题是一个漏洞，或者如何解决这个问题的细节。这将使以后理解这些补丁变得更加困难，但是希望系统的其他部分能够在禁运解除后发现这些信息。

当每个漏洞被创建时，它将被分配一个CVE号。这些数字是从MITRE分配的，目前以块的形式分配给我们。他们正在开发一个API，允许我们按需以更自动化的方式分配它们。如果一个问题在Zephyr发布时仍然被禁止，发布说明将只包含一个CVE的引用，而没有提到修复。我们有一个漏洞页面，显示了在项目中发现的所有漏洞。对于仍然被禁运的CVE，在这个页面上只会有一个占位符。

我们的禁运期做了一些修改。最初，它相当短（60天）。虽然对于一个生产终端设备的项目来说，这已经足够了，但是它并没有足够的时间来为Zephyr的用户传播他们自己正在构建设备的修复。因此，我们将禁令期限延长到90天，目标是在30天内在Zephyr内修复，给最终用户60天的时间来应用和部署修复到他们自己的设备上。

为了让这些产品创建者在禁运结束前知道漏洞，我们创建了漏洞注册中心，个人可以在其中注册邮件列表来接收警报。理想情况下，这仅限于那些使用Zephyr制造产品的公司。

在禁运结束后，一些事情将会发生。首先，漏洞页面将被更新，以包含关于漏洞的更多细节。此信息与发布说明保持分离，因为发布说明与每个发布都是固定的，在发布之后不能更新。第二，CVE数据库本身也将更新，以包括发布的细节。

有许多站点监视CVE数据库，更新这些信息通常会生成报告，其中包含有关问题及其修复的信息。

实行这项工作

根据项目章程，这个安全团队由每个成员中的一个人组成。在过去，我们设置了一个轮换来确定谁将处理漏洞。不幸的是，这还包括了额外的工作监视静态分析，并变得有点难以应付。静态分析很重要，但并不完全与安全性有关，需要独立于安全团队进行处理。我们现在开始的是基于脆弱性本身的轮换。

安全程序是我们不断寻求改进的东西。在我们处理过程中，重要的是要了解改进过程的方法，最终目标是使Zephyr本身安全，并允许使用它创建安全的产品。

有关Zephyr安全通信或漏洞报告的更多信息，请访问：

https://www.zephyrproject.org/security/

点击这里阅读网站原文。