2007年2月2日
第5卷，第1期

开放与封闭

哪种源代码更安全？

理查德·福特，佛罗里达理工学院

没有什么比在一群开发者中宣称操作系统A比操作系统B“更安全”更能引发争论的了。我从亲身经历中了解到这一点，因为我之前发表的关于这个主题的论文导致了大量针对我的激烈电子邮件——其中一些邮件实际上带有肢体威胁。尽管试图调查不同软件项目的相对安全性会产生热度（而非光亮！），但我们必须进行调查。

理解产品为何安全（以及为何不安全）是构建更好软件的关键垫脚石。

在涉足这些危险水域之前，我们应该澄清问题。在比较开源和闭源方法时，问题常常在无意识中被解读为Windows与Linux之争。虽然这是一个非常值得探讨的问题，但这样做是一种非常狭隘的世界观，因为它忽略了开源和闭源世界中的许多其他项目。尽管忽视Windows/Linux世界提供的数据点是愚蠢的，但它们仅仅是过程的例子。因此，让我们首先消除关于这个问题是关于这些特定平台的误解，并认识到它的真正广度。

考虑到这一点，我们的答案需要三个关键定义才能有意义：“什么是开源？”；“什么是闭源？”；以及，令人惊讶的是，“什么是安全？” 前两个我们可以很快处理；然而，第三个要微妙得多，因此我们将首先解决它。

什么是安全？

传统上，我们倾向于将安全视为维护信息的CIA（保密性、完整性和可用性）。这是一个有用的安全分类法，正因如此，它才如此普及。CIA方法的一个局限性在于，当我们考虑如何衡量安全性时，它并没有太大帮助。说一个产品比另一个产品更安全是什么意思？C比A更重要吗，A比I更重要吗？如何对安全性的这些不同方面进行排序？

文献综述很快表明，衡量安全性是一个棘手的问题，到目前为止，我们还没有很好地掌握它。这很遗憾，因为如果我们做到了，那么运行一个简单的实验，衡量各种开源和闭源项目的安全性，看看是否有一种方法始终比另一种方法更安全，这将是很诱人的。例如，如果从安全角度来看，闭源明显更好，那么我们就有了我们问题的答案。

有两种明显的衡量安全性的方法

CIA三要素中任何一个要素被违反的可能性有多大？
一个产品中实际存在多少个漏洞？

让我们来看看这两种方法。

问题在于，前者是受测软件的质量、针对该软件的攻击者的数量和类型，以及盒子的配置、管理和使用方式的组合。因此，如果“更安全”仅仅意味着衡量被攻破的概率，那么可能会得出结论，配备TCP/IP协议栈的MS-DOS比完全打补丁的Windows XP盒子更安全，仅仅是因为现在寻找MS-DOS机器的攻击者数量已经微乎其微。虽然这个衡量标准是务实的，但它告诉我们很多关于系统的普遍性以及攻击者的才能和数量。

放弃这种方法让我们剩下后一种方法：计算代码中的漏洞。即使在这里，如何进行也不是显而易见的，因为我们没有实际漏洞计数的直接衡量标准；我们只有关于公开披露的漏洞数量的信息。因此，像第一种方法一样，这种方法也没有提供安全性的客观衡量标准；它也考虑了外部因素（例如攻击者概况）。

这种方法的一个变体被称为“风险天数”，字面意思是计算漏洞披露和修复之间经过的时间。定义修复是一项艰巨的任务。关闭一项非关键服务是否算作暂时“修复”了问题，还是只有供应商支持的“官方”补丁才构成修复？这将取决于提供的服务和用户的需求。即使我们能在修复上达成一致，攻击者的数量也在确定总风险天数中起着关键作用。尽管如此，这种方法非常实用，因为它考虑到了在漏洞公开之前，实际利用漏洞相对罕见这一事实。¹ 然而，这是一个实用的衡量标准，因此，它并没有直接说明固有的安全属性，而是务实的属性。请注意，风险天数传统上是从漏洞公开之日算起的，而不是从已知漏洞被利用之日算起的。虽然有人可能会争辩说，在没有漏洞利用的情况下，了解漏洞是没有意义的，但通常很难确定漏洞利用何时变得“公开”，因为黑帽社区的许多成员对这些信息严加保密。因此，漏洞日期是最客观的——因此也是可重复的——衡量标准（即使它不如漏洞利用日期那么理想）。

即使基于这个简短的讨论，也很清楚，准确衡量安全性对不同的人来说意味着不同的事情。因此，就本文而言，可以合理地接受我们（尚未）以有序的方式衡量开源/闭源过程的内在安全结果。这意味着我们确定哪种方法能带来更好安全性的“实验”方法已被排除在外：在科学成熟之前，我们将不得不独立地检查每种方法的优缺点，并尝试自行权衡它们。

开源，闭源

简单来说，开源过程可以被认为是一种提供产品/可执行文件的源代码的方法。相比之下，闭源方法限制源代码访问仅限于产品的开发者和其他选定的人员（通常在保密协议的约束下）。在两个世界中，都可以做出更精细的区分。例如，一些开源项目将开发限制在一小部分程序员中；另一些则允许任何人贡献。然而，源代码访问是这两种方法之间的关键区别。另请注意，这两种情况都不要求软件是免费的还是“收费的”——尽管开源世界在许可方面通常更友好。

也许对于开源社区来说很恰当，对开源的更精确定义因人而异。最简单地说，开源指的是提供程序源代码的做法。此外，大多数开源方法的支持者都会同意，分发的源代码应该在法律上是可修改和可再发行的（有一些许可证限制）。因此，用户有能力检查和修改他们使用的程序。（更完整的定义在https://open-source.org.cn提供。）

相比之下，闭源方法会封闭程序代码。因此，通常在法律上禁止衍生作品。两个阵营的支持者都可能反对我的定义的简单性：它们确实抓住了两种方法的本质，但未能捕捉到围绕它们形成的文化。

从文化上讲，闭源代表了传统的企业软件开发者。然而，当我们想到开源时，我们倾向于想到作为集体工作的志愿者、自由软件和社区项目。开源结构是流动的；闭源结构是僵化的。虽然这有点像漫画，但像所有好的素描一样，它确实捕捉到了一些运动的“感觉”。

内在安全属性

现在我们对问题有了理解，是时候从安全的角度来考察这两种方法的相对优点了。显然，其他人已经进行了这个过程（例如，对于略有不同的观点，请参阅Ross Anderson²）；然而，还有许多问题尚未完全解决。因此，我们首先考虑开发方法之间最基本的差异：可以检查开源项目的源代码。实际上，这对攻击者和防御者都有用。

从攻击者的角度来看，代码可用性意味着完全公开了特定功能的实现方式。此外，这意味着对弱点和设计决策的讨论常常公开进行（参见本文后面的“披露模型”部分）。因此，开源产品允许攻击者以白盒视角查看产品以及潜在的相关问题。当安全补丁可用时，攻击者可以很容易地确定到底修复了什么。

从防御者的角度来看，开源也有优势。也许最重要的是，它允许代码检查。因此，如果防御者真的想知道某个特定功能是否安全，他或她可以简单地检查代码——当然，前提是防御者具有必要的安全知识来发现问题。其次，人们普遍认为，由于许多人可以审查代码，因此代码的质量本质上更高——正如埃里克·S·雷蒙德在他现在著名的引言中所说，“只要有足够的眼球，所有漏洞都是肤浅的。”³ 最后，足够熟练的程序员可以关闭特定环境中存在问题的特性。因此，当发现漏洞时，用户不必等待官方补丁：任何人都可以对代码库进行必要的更改。

从攻击者的角度来看，闭源意味着只有给定社区的一小部分人可以访问代码。因此，要理解内部结构，攻击者必须对二进制文件进行逆向工程；这样一个过程既耗时，而且对于已经受到保护以防止这种逆向工程的软件来说，也是非常困难的。

此外，设计错误可能更难发现，因为仅使用编译后的代码来掌握大型应用程序的整体形式是非常困难的。

对于防御者来说，情况同样是双刃剑。当使用闭源产品时，用户在功能更改或安全补丁方面完全受代码开发者的摆布。因此，当漏洞被公布时，防御者的选择是有限的。披露模型的差异在一定程度上缓解了这种情况，但最终，用户仍然只能信任供应商。自助不是一个实际的选择；无法在内部筛选代码，以查找在特定环境中令人担忧的结构。当然，如果闭源产品的代码泄露，这些问题会更加复杂；那么攻击者就拥有了这种方法的许多好处，而几乎没有缺点。

这些基本属性是用相当粗略的方式描绘的，但本质上，它们概括了这两种技术在攻击者和防御者方面的系统性差异。篇幅限制了对这些差异的彻底考察，因此我们将注意力转向似乎影响最大的两个方面：漏洞披露模型和信任/验证。

披露模型

开源和闭源过程之间的一个关键区别是它们通常共享的漏洞披露模型。由于开源的本质是开放性，当漏洞被修复时，攻击者很容易看到到底修复了什么，并反向推导出漏洞以及（可能）一个可用的漏洞利用程序。在闭源世界中，甚至可能不清楚是否存在漏洞或漏洞是否已被修复。

正因如此，从“风险天数”的角度来看，开源往往表现不佳，“风险天数”是指计算漏洞披露和“批准”修复之间的时间。有些人可能会觉得这不公平，但实际上，历史表明，漏洞/漏洞利用程序公开可用与其补丁之间的时间窗口是一个困难且危险的时期。此外，虽然完全有可能（并且在几个开源社区中 практикуется）在补丁可用之前对安全漏洞披露进行封锁，但在开源社区中，不披露的做法仍然比闭源社区更少见。此外，包含开源组件的许多不同的Linux发行版使问题更加复杂。如果组件由其创建者更新，那么等待所有使用它的发行版都准备好发布经过验证的补丁是不切实际的。

披露模型的差异是开源过程难以解决的问题。虽然可以争辩说用户可以在问题出现时修复问题（因此，一旦问题被披露，用户就可以编写补丁供自己使用），但这有点牵强附会。大多数用户不是程序员，而那些是程序员的人通常也不是安全专家。因此，闭源在这种方面受益于其“封闭”的性质——其世界观侧重于保守某些“秘密”。

相反，开源世界是建立在信息交流的基础上的。在这个问题上改变开源世界观，特别是关于安全性的问题，确实是解决方案的关键，但在某种程度上与文化相矛盾。尽管几个开源项目在这个领域取得了稳固的进展（漏洞越来越多地在私下而非公开论坛中讨论），但一旦补丁发布，就很容易确定补丁的确切细节。这使得为以前的版本开发漏洞利用程序变得简单得多。

信任信任

肯·汤普森的论文《反思信任信任》今天和1984年首次发表时一样重要。⁴ 汤普森阐述了我们在决定与安全相关的问题时所做的信任假设。最终，他认为，我们信任的东西比我们可能意识到的要多得多。当考虑开源/闭源安全性时，同样的论点也成立。

传统上，安全人员倾向于将攻击者视为恶意内部人员或第三方。然而，也有可能将软件供应商——作为一个整体——视为不可信的（因为有人怀疑供应商是恶意的或不称职的）。那又怎样？

这种信任焦点的转变可能有点令人吃惊，但并非完全牵强附会。它甚至不需要供应商有不当行为。考虑一个善意（但愚蠢）的供应商，他在安装过程中禁用了关键的安全软件，目的是在安装结束时恢复它。这样的供应商可能会在不知不觉中将用户置于风险之中。索尼用于DRM（数字版权管理）目的的rootkit等事件也强调了有时对供应商的错误信任。在每种情况下，项目的闭源性质都使用户处于危险之中，因为除了逆向工程之外，没有办法确定软件的真实功能。

还有不道德的供应商故意将广告软件偷偷地塞到你的电脑上，伪装成“实用程序”的问题。供应商并非天生值得信赖，任何盲目地假设他们值得信赖的人要么是在否认现实，要么就是天真。

在供应商不可信的情况下，开源至少提供了一种机制，通过该机制，相关实体可以在合理范围内验证（记住汤普森论文的含义）一切都很好。在许多情况下，对项目的整个代码库进行审计是不合理的，但我可以提供一个难以反驳的例子：投票软件。

坦率地说，将选举的合法性委托给单个供应商的想法是可怕的。由于利害关系如此重大，投票软件必须通过源代码检查来验证——谁会信任投票的黑盒方法？显然，对于此类软件，开源方法至少提供了一种机制，通过该机制可以验证软件的真实性。在所有情况下，输入的每一张选票是否都与计算出的每一张选票相符？虽然在开源世界中这个过程并非易事，但在闭源场景中，这确实非常具有挑战性，在闭源场景中，人们必须求助于对系统进行逆向工程。因此，在某些情况下，似乎开源方法显然更胜一筹。

在安全软件中可以找到一个有趣的对立面。考虑杀毒软件。虽然许多杀毒软件是基于签名的，但存在许多不同形式的通用病毒防护，它们试图应用不同的技术来阻止新病毒。这种软件很重要，因为它为抵御快速蠕虫病毒提供了第一道防线，蠕虫病毒可能在其首次发布后几分钟内就变得具有流行性。一般来说，这种软件在理论上是不安全的——它本质上是启发式的，并且可以被具有足够知识的攻击者绕过。在这种情况下，开源方法可能不如闭源方法有吸引力。至少让攻击者的生活更加艰难。如果这听起来像是隐蔽式安全，请稍等片刻：它就是。

隐蔽式安全？

“隐蔽式安全”的想法在软件工程师中声名狼藉。我仍然记得多年来导师们反复向我灌输的观点，即隐蔽式安全根本不是安全（我希望当这些优秀的科学家阅读这篇文章时会联系我，看看他们在我的教育中哪里出了问题），但我认为整个论点在很大程度上是情境性的。例如，密码是“可接受”的隐蔽式安全的完美例子：它们只有在攻击者不知道它们的情况下才有用。

再次，让我用一个例子来说明我的立场：DRM软件。任何时候，当试图保护软件免受未经授权的复制时，都会遇到隐蔽式安全的想法。本质上，如果计算机可以运行该软件，那么几乎可以肯定可以复制它。同样，对于受版权保护的文档，如果一切都失败了，我总是可以拍一张屏幕照片。几乎所有的DRM软件在某种程度上都是隐蔽式安全：门槛设置得恰到好处。诀窍是确保它足够高，以阻止大多数攻击者。同样，如果源代码可用，Microsoft Windows Vista备受争议的内核补丁保护提供的保护价值要小得多。这将允许攻击者绘制绕过它的最快路线。

一个对立面再次突出了我所谈论的情境：加密。作为计算机科学家，我们可以使加密变得任意难以破解，只要考虑到当前已知的技术即可。如果破解代码涉及分解一个非常大的数字，我可以很好地预测攻击者需要花费多少精力，而这个时间实际上并不取决于攻击者对我的软件或算法的了解。对于此类软件，实现安全性的最佳途径是发布算法并让其得到独立验证。那么，区别是什么呢？

这些情况之间的区别很简单：确定性。在加密软件的情况下，结果是确定的。了解关于机制的一切并不会损害结果的安全性。相比之下，对于杀毒软件，系统是启发式的。因此，有些东西受益于披露，有些东西则不然。在这两种情况下，这很明显。不幸的是，这是例外，而不是规则。问题在于，许多系统包含启发式和确定性方面。

对于文字处理器，问题是不同的。你可能希望你的文字处理器可靠地工作，但事实是它包含错误，并且可能存在安全漏洞。闭源方法使得除了开发者之外的任何人很难找到这些错误。开源方法意味着任何接受过安全编码实践培训的人都可以很容易地发现弱点。这两种属性都是双刃剑，目前尚不清楚哪一种能提供最佳的长期结果。

结论

这个话题之所以有趣，部分原因是它很困难：双方都有令人信服的论点。通过更好地理解问题的细微之处，不同的方面开始变得清晰起来。两种开发方法都有内在属性：哪一组属性最适合特定的应用程序是情境性的。

不幸的是，一种方法明显优于另一种方法的情况寥寥无几。大多数软件都有些不安地介于两者之间。在这种情况下，软件背后团队的组成、理念和培训远比项目是开源还是闭源更重要。两种方法都可以做得好，也都可以做得不好。

了解每种方法的优势和劣势是改进流程的第一步。与其关注非此即彼的决策，不如最终更富有成效地两者兼顾，在适当的地方使用每种方法。软件工程是一门年轻的学科；时间会回答我们是否在充分了解我们的假设和缺点的情况下接近这个问题。

参考文献

Arbaugh, W. A., Fithen, W. L., McHugh, J. 2000. 漏洞窗口：案例研究分析。《IEEE计算机》33（12月）：52-59。
Anderson, R. J. 2002. 《开源与闭源系统中的安全性——玻尔兹曼、科斯和摩尔之舞》。在开源软件经济学会议上发表。
Raymond, E. S. 1999. 《大教堂与集市》。Sebastopol, CA: O’Reilly。
Thompson K. 1984. 《反思信任信任》。《通讯》27(8): 761-763。

理查德·福特于1992年毕业于牛津大学，获得量子物理学博士学位。从那时起，他广泛从事计算机安全和恶意移动代码预防领域的工作。之前的项目包括IBM研究中心的计算机病毒免疫系统工作，以及在担任Verio工程总监期间开发世界上最大的Web托管系统。福特是佛罗里达理工学院的副教授，在那里他是安全科学中心的主任。他的研究兴趣包括恶意移动代码、行为蠕虫预防、安全指标和计算机取证。福特是Reed-Elsevier的《计算机与安全》、《病毒公告》的执行编辑，也是《IEEE安全与隐私》专栏的联合编辑。

最初发表于Queue杂志第5卷第1期—
在数字图书馆中评论这篇文章

更多相关文章

Jinnan Guo, Peter Pietzuch, Andrew Paverd, Kapil Vaswani - 使用保密联邦学习实现可信赖的AI
安全性、隐私性、问责制、透明度和公平性原则是现代AI法规的基石。经典的FL在设计时非常强调安全性和隐私性，但以透明度和问责制为代价。CFL通过将FL与TEE和承诺相结合，弥补了这一差距。此外，CFL还带来了其他理想的安全属性，例如基于代码的访问控制、模型保密性以及推理期间的模型保护。保密计算（如保密容器和保密GPU）的最新进展意味着，现有的FL框架可以无缝扩展，以低开销支持CFL。

Raluca Ada Popa - 保密计算还是密码计算？
通过MPC/同态加密与硬件飞地进行的保密计算提出了涉及部署、安全性和性能的权衡。关于性能，您心中的工作负载非常重要。对于简单的工作负载（如简单的求和、低阶多项式或简单的机器学习任务），这两种方法都可以在实践中随时使用，但对于丰富的计算（如复杂的SQL分析或训练大型机器学习模型），目前只有硬件飞地方法在许多实际部署场景中足够实用。

Matthew A. Johnson, Stavros Volos, Ken Gordon, Sean T. Allen, Christoph M. Wintersteiger, Sylvan Clebsch, John Starks, Manuel Costa - 保密容器组
此处介绍的实验表明，Parma（Azure容器实例上驱动保密容器的架构）增加的额外性能开销不到底层TEE增加的额外性能开销的百分之一。重要的是，Parma确保容器组在证明报告中扎根的所有可达状态上的安全不变性。这允许外部第三方与容器安全地通信，从而支持广泛的需要保密访问安全数据的容器化工作流程。公司获得了在云中运行其最机密工作流程的优势，而无需在其安全要求上妥协。

Charles Garcia-Tobin, Mark Knight - 使用Arm CCA提升安全性
保密计算具有通过将监管系统移出TCB来提高通用计算平台安全性的巨大潜力，从而减小TCB的大小、攻击面和安全架构师必须考虑的攻击向量。保密计算需要平台硬件和软件方面的创新，但这些创新有可能增强对计算的信任，尤其是在第三方拥有或控制的设备上。保密计算的早期消费者将需要就他们选择信任的平台做出自己的决定。