开源技术如何应对最大威胁
2011-04-10 10:21:18 
阿炯
资深Linux和开源新闻工作者和分析师Brian Proffitt近日发表博文称，法律问题所引起的 “暗流”一直困扰着开源世界。同时提出一个问题：专利和版权转让，哪个对开源构成的危险更大呢？ 
Brian Proffitt
一条15000年以前因冰川冲刷而形成的、河床高低不平的河流对于游泳者来说相当危险，你不知道在什么时候，一个突如其来的暗流就可以把你淹没。这条河表面看起来很平静，很温和。但事实并非如此。
这些年来，法律问题所引起的 “暗流”一直困扰着开源世界。在云计算、移动、服务器领域，这个问题越来越严重。所有由开源社区协助研发出的成功技术正面临着一些爱打官司企业的威胁。
这个听起来或许有些可怕甚至有些可疑，但绝不荒谬。正如有一头熊在你的房间里，你肯定不会视而不见，并希望它能尽快离开。同时你也会给动物控制中心打电话求救。
让开源从业者感到“惧、惑、疑”，是他们发起各种困扰开源的法律问题的主要目的。让开源从业者惧，从而演变成一种恐吓，这些厂商手上就可以获得一个靠发放许可证而盈利的渠道。
为了“保护”知识产权而进行的软件专利诉讼是他们最惯用的法律手段。但我相信，任何的法律问题可以归属为版权和版权转让的问题。
不久前，在开发者向厂商所管理的项目提交代码的过程中，开源社区厂商们因版权转让性质问题而遭到强烈声讨。
版权转让的基本过程是这样的：假设我是一个开发者，编写了一些很出色的代码，想提交到X工程中(X工程归属X公司所有)。如果x公司认可我编写的代码，并想把这些代码用到 X工程的最新版本中，他就会和我签订协议，让我把这些代码的版权转让给他。这样他们就可以把我的代码作为X工程最新版本的一部分进行发布，并在法律上对这些代码具有完全的控制权。即便他们很信任我、并与我保持合作，也要经历这样一个过程。
绝大部分情况下，这个版权转让看起来很合理。毕竟，我希望我的代码能成为X工程某发行版的一部分， X公司不想被一堆的版权所困扰也是合理的。 但是有时版权转让犹如一个权谋政治家，让人头晕目眩、搞不清状况。尤其在开源这块土地上。举个例子，Canonical是一家曾在过去被这个问题连续困扰的公司。开发者和开源软件倡导者曾为那种看似简单易懂，但实际却包含诸多模糊限制的协议进行过深入的讨论。这些限制不应该被隐藏起来，以协议中的第6条为例：
“Canonical will ordinarily make the Assigned Contributions available to the public under a 'Free Software Licence,' according to the definition of that term published by the Free Software Foundation from time to time. Canonical may also, in its discretion, make the Assigned Contributions available to the public under other license terms.”
这条协议内容令人不安。因为这个“ordinarily”看起来相当模糊。难道它指的是在某种特定的环境下，他们将按照其他软件许可协议来使用和发布此代码？第二句话表达更加模糊，好像在表明：Canonical确实决定按照其他协议来发布该代码。 之前Canonical已经公开说明了这种忧虑。Shuttleworth(Canonical创始人)在一年前的一个采访中表示，Canonical的“contributor agreement”和其他厂商的没有什么不同。
为什么又把这个提出来了呢？
版权转让问题是几星期前，我在印地安那州LinuxFest上与OpenNMS成员Taurus Balog和Software Conservancy 成员Bradley Kuhn开始很长交谈的一个导火索。这次交谈长达数小时。
在这次交谈中，我开始思考，哪个对开源构成的危险更大呢？是专利还是版权转让呢？
对于这个问题，我需要思考一段时间，我希望在未来与大家分享我的结论和其他观点。最后得到的结果也可能是，专利和版权转让对开源社区来说具有同样的危险。这个问题好似在问狮子和熊哪个更危险一样。
美国通过立法保护开源软件安全性
2022年9月下旬消息，美国通过两党立法将开源软件安全再次列入重点考量，称为《保护开源软件法案》 (Securing Open Source Software Act)，目标就是保护关键基础设施。美国参议员 Gary Peters (D-MI) 和国土安全和政府事务委员会主席兼高级成员 Rob Portman (R-OH) 提出了两党立法，希望通过增强开源软件安全性来帮助保护联邦和关键基础设施。
Gary Peters 表示：“开源软件是数字世界的基石，Log4j 漏洞证明了我们对它的依赖程度。这一事件对联邦系统和关键基础设施公司 —— 包括银行、医院和公用事业机构 —— 构成了严重威胁，因为美国人每天都依赖这些公司提供基本服务。这项常识性的两党立法将有助于保护开源软件，并进一步加强我们对网络犯罪和对全国网络不断发起攻击的外国对手的网络安全防御。”
Rob Portman 也说道：“正如我们在 Log4shell 漏洞中看到的那样，我们每天使用的计算机、手机和网站都包含容易受到网络攻击的开源软件，两党合作的《保护开源软件法案》将确保美国政府预测并减轻开源软件中的安全漏洞，以保护美国人最敏感的数据。”
据称，这项重要的立法将是美国有史以来第一次将开源软件列入公共基础设施。《保护开源软件法案》将指导 CISA（网络安全和基础设施安全局）开发一个风险框架来评估联邦政府如何使用开源代码。
CISA 还将评估关键基础设施所有者和运营商如何自愿使用相同的框架。这将确定在使用开源软件的系统中降低风险的方法。该立法还要求 CISA 聘请具有开发开源软件经验的专业人员确保政府和社区携手合作，并准备好应对 Log4j 漏洞等事件。此外，该立法要求管理和预算办公室 (OMB) 就开源软件的安全使用向联邦机构发布指导，并在 CISA 网络安全咨询委员会下设立软件安全小组委员会。
美国政府软件要求提供安全软件开发认证表
作为改善网络安全持续努力的一部分，拜登 - 哈里斯政府宣布已批准了一份安全软件开发认证表。
该表格由 CISA 和管理和预算办公室 (OMB) 于 2024 年 3 月 11 联合发布，任何提供政府将使用的软件的公司都需要填写该表格。它将有助于确保该软件是由优先考虑安全性的公司开发的。 Endor Labs 首席安全顾问兼 CISA 网络创新研究员 Chris Hughes 表示：“表格中的要求代表了一些基本的安全开发实践，希望向联邦政府出售软件的供应商如果想参与联邦监管的生态系统，就应该能够满足这些要求。”
表格中的要求之一是软件必须在安全的环境中开发。这包括分离生产和开发环境，最大限度地减少代码中不安全产品的使用，跨环境强制执行多因素身份验证，加密敏感数据，实施持续监控和警报等防御实践，以及定期记录、监控和审核信任关系。“分离开发和生产环境、实施日志记录和 MFA 等做法是任何现代安全软件开发环境中都应该存在的关键安全控制措施。”另一个要求是通过使用自动化工具监控第三方代码并维护内部代码和第三方组件的来源，真诚地努力维护可信的供应链。它还需要定期使用自动化工具来检查安全漏洞，包括制定披露和解决已知漏洞的策略。
然而 Hughes 认为，这种形式缺少一些元素。例如，它不需要使用威胁建模或内存安全，而这正是 CISA 一直在推动的事情。他表示，它还允许首席执行官指定其他人在证明上签字，以便在出现问题或证明造假时作为潜在的替罪羊。“一方面，我们听说网络安全需要成为董事会的议题，CISA 甚至呼吁高管层参与其有关安全设计 / 默认的出版物；但另一方面，这种形式允许将这一关键认证活动委托给某人组织中的其他人，并可能使其无法被最高管理层/首席执行官和执行领导团队看到。”
Hughes 认为，最难满足认证要求的软件生产商是那些尚未实施安全软件开发实践的软件生产商。“他们需要评估当前的开发实践，找出缺陷并实施纠正计划。这当然需要时间和资源，而规模较小的初创公司和不成熟的组织获得这些时间和资源的机会有限，尤其是面对对上市速度、收入、投资者回报、功能速度等方面的竞争需求。”
CISA 的在线表单提交存储库(https://softwaresecurity.cisa.gov)预计将于 2024 年 3 月下旬提供。
CISA联合指南警告开源项目中的内存安全漏洞
继《计算机业界相关安全话题》中的相关说明后，CISA与联邦调查局、澳大利亚信号局的澳大利亚网络安全中心和加拿大网络安全中心合作，于2024年6月下旬制作了一份联合指南，为企业提供有关选定开源软件 (OSS) 中内存安全风险规模的调查结果。
本指南以内存安全路线图为基础，为软件制造商提供了一个创建内存安全路线图的起点，包括解决外部依赖项（通常包括OSS）中的内存安全问题的计划。探索关键开源项目中的内存安全也符合 2023 年国家网络安全战略和相应的实施计划，该计划讨论了对内存安全的投资以及与开源社区的合作，包括建立跨机构开源软件安全倡议（OS3I）和对内存安全编程语言的投资。该指南发现在所分析的关键开源项目中，有 52% 的项目包含用内存不安全语言编写的代码，占这些项目总代码行数的 55%。在最大和最受欢迎的项目中，内存不安全代码的情况更为明显；按代码行数计算，前 10 个最大的项目使用内存不安全语言编写的代码中位数为 62.5%，其中有 4 个项目使用内存不安全语言的比例超过 94%。
依赖性分析结果显示，用内存安全语言编写的项目往往依赖于用内存不安全语言编写的组件，凸显了内存安全漏洞的普遍性。例如，对一些项目进行的依赖性分析表明，看似安全的项目往往包含了用不安全语言编写的模块，用于实现密码学和系统接口等功能，从而导致这些项目继承了潜在的漏洞。
该指南认为开发者亟需转向 Rust 等内存安全编程语言，以大大减少人为错误的机会。并建议企业和其他接触内存不安全代码的开源代码用户，应使用内存安全语言过渡现有项目并启动新项目，以增强软件安全性。CISA鼓励所有组织和软件制造商审查指南中的方法和结果，以便：减少内存安全漏洞、做出安全和明智的选择、了解 OSS 内存不安全风险、评估降低这种风险的方法、以及继续努力推动软件制造商采取降低风险的行动。完整内容可查看此处。