王旭|蚂蚁王旭：开源项目是如何让这个世界更安全的 Kata|项目|社区|

_原题为 蚂蚁王旭：开源项目是如何让这个世界更安全的

在前不久的上海外滩大会上，蚂蚁资深技术专家、Kata Containers创始人王旭向参会者分享了开源、开放协作与软件安全可信的话题，本文根据演讲内容编辑整理而成。

【王旭|蚂蚁王旭：开源项目是如何让这个世界更安全的】

文章图片

今天，我想在这里和大家探讨开源与安全的话题。在过去，人们一直有一些疑问：开源是否比闭源更安全？开源项目如何保证自己的安全？如何通过开源社区促进业界改善安全性？
这里，我将以Kata Containers项目以及蚂蚁基础设施团队的实践为例，对这些问题做一些探讨，来看看社区和业界是怎么做的。
开源项目如何保证安全性？首先是开源比闭源更安全吗？
你可能从哪里听说过：开源软件相比闭源软件的一个优越性在于，开源软件更安全。
开源运动的一位颇具话题性的早期领军人物Eric S·Raymond ，在他的著作《大教堂与集市》中写道：
“在一群足够多的beta测试者与共同开发者的情况下，几乎所有问题都可以被快速定位，并且由某个人迅速解决。 ”
“有些所谓安全系统，只有在其不为人所知时才是安全的，当心这些虚假的隐秘性。 ”
这些论点几乎是无可辩驳的。然而，争论就在于——开源是否意味着更多专业的review ，更多的人看到代码甚至是发现漏洞了，他们是否会第一时间来帮助开源项目改善质量而非第一时间利用漏洞进行入侵？开源项目是如何第一时间处理漏洞的？
下面让我们来看一个例子。
这是Kata Contaienrs 项目的 VMT 流程图，描述了项目漏洞事件响应团队接收到安全报告后是如何处理的。

文章图片

所谓VMT ，是 Vulnerability Management Team ，这是一个应对安全事件的“特权”工作组，成熟的、社区化的开源项目都有这样一个核心团队。当安全研究人员发现在他们的研究中发现项目存在安全漏洞的时候，会向VMT工作组发出报告，而VMT收到之后，会在寻求修复方案的同时，对问题进行评估、去权威机构分配CVE编号，在patch merge之后，还需要确保主要用户的安全，然后再对外公开修复信息。
这里的一个关键点是，开源项目VMT团队和安全人员的配合。只有规范运作的开源项目和白帽子们良好互动，才能真的做到第一时间修复漏洞、保护用户，而不是放出0-day漏洞。这中间的响应流程，即使对于“开源”软件，也是不开放的。
所以，这里我们的结论是——不是你把代码放在 GitHub 上开源了，安全就随之而来了，你要有吸引安全人员的活跃社区和可以响应问题的机制。这里我们知道，有些个人化的开源项目是没有这样的响应机制的，这样的开源项目并没有让用户得到安全，相反，一旦有大量用户使用，得到的是很多惊险。
VMT机制保证了开源项目本身的安全，那么，在一个庞大的开源社区，比如云原生社区，它由数量繁多的开源项目组成生态，关于社区的整体安全性，还会有哪些有趣的互动呢。
如何提升开源社区的安全水位开源的一个便利之处就是，如果你觉得哪里不够好，可以自己去弥补。在云原生 landscape 里，搜一下安全相关的品类，立刻可以得到一大片的开源安全组件或工具：

文章图片

需要说明的是，这些项目不是预先设计的目标，而是社区互动产生的结果。它们反映了一个自组织生态里的演化规律，而不是操作守则。在开源协作里，这样的项目会自然的涌现出来。
这里，我想以Kata Containers为例，来介绍下如何开发一个开源项目并融入社区。
首先我先来简单介绍一下 Kata Containers——
Kata Containers 首先是一个容器运行时引擎，在生态中的位置和 runc 是一致的。但是，和 runc 不同的是， Kata 用轻量级虚拟化技术来做隔离，这个强隔离带来的不仅是安全隔离，也包括性能隔离和故障隔离。
不过我要强调的一点是， Kata 仍然是一个容器引擎，在系统中是完全对等替换 runc 的，对云原生应用来说，它是完全透明的，即使从性能和开销角度说，我们也已经对它进行了很多轻量化的改造。
所以，我们说，它同时兼有虚拟机和容器两者的优点， secure as VM, fast as containers 。
三年来， Kata Containers最让我感到骄傲的，是通过开源社区，我们撬动了社区里的其他大玩家，提升了整个云原生世界的安全水位，利用开放协作提升了云原生领域的安全性、改善了社区的信任。
Kata创立之前的虚拟化容器技术的发展并不快。 2015年上半年，我们就开源了 hyperContainer 和 runV ， Intel 也同时开源了 clear containers 。不过，当时我们的影响还是非常有限的，想加入CNCF都被拒之门外，但我们还是在 Kubernetes 社区里制造了一些影响。比如在 2016 年的时候，我们和 kubernetes node 团队一起推动了 CRI 接口，来抽象化容器引擎。