作者:新思科技高级内容策略师Fred Bals
开源是软件设计各个开发阶段越来越受欢迎的选择。这是有道理的。开源具有诸多优势,例如灵活性、成本效益和共享维护成本。但是,我们需要加强开源漏洞监控,并针对许可问题进行研究。
新思科技的黑鸭审计服务团队每年为其客户进行数千个代码库的开源审计。这些审计需求主要来自合并和收购交易,并最终成为我们年度《开源安全和风险分析》(OSSRA)报告的匿名数据的关键来源。
近期发布的2019年OSSRA报告审查了1200多个商业代码库的数据结果,这些代码库用于希望评估其开源许可证合规性和安全风险的企业和组织。
审计发现,2018年扫描的代码库中有超过96%的代码库是开源的,超过99%的代码库包含超过1,000个由开源组件构成的文件。开源代码与代码库中代码总数的比例在2018年为60%,高于2017年的57%。这些数字反映了经审计的代码库通常来自业务是构建软件的公司。这些公司的价值通常体现在其拥有的专有代码,它们代码库中开源代码与专有代码的比例往往较低。
相比之下,Forrester和Gartner等分析师指出,超过90%的IT企业在任务关键型的工作中使用开源软件,而且开源占据了90%的新代码库。根据2019年红帽(Red Hat)“企业开源状态”报告,超过69%的受访企业认为他们使用开源至少“非常重要”(40%非常重要,29%极其重要)。
无论您参考哪组数据,很明显开源组件和库是每个行业中几乎所有应用程序的支柱。大多数企业拥有数千种不同的软件,从移动应用程序到基于云的系统,再到本地运行的遗留系统。该软件通常是商业现成软件包、开源软件和定制代码库的混合体。漏洞影响所有软件。
然而,很少有公司能够充分追踪他们在代码中使用的开源组件,并且没有采用开发人员使用开源所做出的选择所需的策略、流程和工具。因此,开源带来的所有好处也可能带来各种风险。
正如红帽报告指出的那样,安全被认为是阻碍一些企业允许开源使用的主要障碍。有趣的是,同一份报告将安全性视为IT决策者在使用开源时所看到的最大好处之一。这种看似矛盾反映了两种现状:人们担心非托管开源代码可能会在开源和专有解决方案中引入漏洞;人们意识到正确管理开源 - 包括使用可信来源和自动化工具来发现和修复安全问题 - 可以大大减少开源风险的潜力。
所有软件,无论是专有软件还是开源软件,都存在可能存在漏洞。企业需要识别和修补这些漏洞。开源社区在发布补丁方面做出了示范性的工作,通常比专有软件快得多。
但无论是专有软件还是开源软件,相当大数量的企业都没有及时应用补丁,而暴露在风险之中。不修补的原因是多种多样的:有些企业被无休止的可用补丁所淹没,无法确定需要修补的优先级;有的缺乏应用补丁的资源;有的需要平衡风险与财务成本之间的关系。
未修补的软件漏洞是企业面临的最大的网络威胁之一,软件中未修补的开源组件增加了安全风险。 2019年OSSRA报告指出,2018年审计的代码库中有60%至少存在某种开源漏洞。 新思科技在2018年为其黑鸭 KnowledgeBase™知识库增加了7,393个开源漏洞。过去二十年,该知识库已经报告了超过50,000个开源漏洞。
开源的某些特性使流行组件中的漏洞很容易受到攻击。商业软件的发布者可以自动向用户推送修复,补丁和更新。但与商业软件不同,您需要负责追踪使用的开源的漏洞和修复程序。
无处不在的开源为攻击者提供了一个有利的环境,因为漏洞是通过国家漏洞数据库(NVD)、邮件列表、GitHub问题和项目主页等来源披露的。如前所述,许多企业没有保留其应用程序中使用的开源组件的准确、全面和最新的清单。例如,美国参议院常设调查小组委员会的一份工作人员报告指出,Equifax缺乏完整的软件库存是导致其2017年大规模数据泄露的一个因素。
现在有数千个开源许可证,如果不遵守这些许可证,可能会使企业面临诉讼风险和损害知识产权风险。无论是使用开源计划认可的流行许可证还是其它许可证,企业只有在确定由这些许可证管理的开源组件后才能管理和遵守许可证要求。 2019年OSSRA报告中详述的经过审计的代码库中有32%包含可能导致冲突或需要进行法律审查的自定义许可证。 68%的代码库包含许可证冲突的组件。
除了安全和许可风险之外,操作风险是开源使用不太严重但仍然不可忽视的后果。今天使用的许多开源组件都被放弃了。换句话说,他们没有开发人员社区贡献、修补或改进它们。如果组件处于非活动状态且没有人维护它,则意味着没有人正在解决其潜在的漏洞。 2019年OSSRA报告指出,85%的被审计代码库包含超过四年没有更新或在过去两年没有开发活动的组件。
开源为使用它的组织提供了许多好处 - 但只有在正确管理开源以识别任何安全和法律合规性问题时。为了防范开源安全和合规风险,企业应该:
创建和执行开源风险政策和流程。只有少数开源漏洞 - 例如影响Apache Struts或OpenSSL的漏洞 - 可能会被广泛利用。考虑到这一点,企业应将其开源漏洞管理和缓解工作的重点放在CVSS(通用漏洞评分系统)评分和漏洞利用的可用性上,不仅仅是漏洞披露的“零天攻击”,而是贯穿开源组件生命周期。
必须让开发人员了解管理使用开源的必要性。企业实施自动化流程、追踪代码库中的开源组件及其已知的安全漏洞、以及版本控制和重复等操作风险,并根据问题的严重性确定问题的优先级。
执行其开源软件的完整清单。在代码库中使用完整、准确、及时的开源清单至关重要。清单应涵盖两个方面:源代码;如何在生产中部署或用作应用程序中的库的任何商业软件或二进制文件中使用开源的信息。
了解开源的已知漏洞。国家漏洞数据库(National Vulnerability Database)等公共资源是公开披露开源组件漏洞信息的可靠平台。但是,不要仅仅依靠NVD来获取漏洞信息。还需要查看其它资料。这些资料提供影响代码库的漏洞的早期通知,理想情况下,还会提供安全性洞察、技术详细信息以及升级和修补程序指南。
监控新的安全威胁。当应用程序完成开发时,追踪漏洞的工作还未结束。只要应用程序仍在使用中,企业就需要持续监控新威胁。
识别许可风险。不遵守开源许可证可能会导致企业面临诉讼和危害知识产权的重大风险。教育开发人员了解开源许可证及其义务。让法律顾问也参与教育过程,当然他们还有审查许可证和遵守法律义务。
确保审查开源是并购尽职调查一部分。如果您正在进行收购,请了解目标公司正在使用的开源,它可能没有适当地管理好这些开源。不要犹豫,询问有关其开源使用和管理的问题。如果软件资产是公司估值的重要组成部分,请让第三方来审核开源代码。
最重要的是,如果企业不知道自己正在使用什么软件,那就无法提供修补方案。如果您无法充满信心地说在内部和外部应用程序中使用的开源组件是最更新的,应用了所有关键补丁,那么就该重新评估现有的开源管理策略和流程了。
好文章,需要你的鼓励
很多人担心被AI取代,陷入无意义感。按照杨元庆的思路,其实无论是模型的打造者,还是模型的使用者,都不该把AI放在人的对立面。
MIT研究团队提出递归语言模型(RLM),通过将长文本存储在外部编程环境中,让AI能够编写代码来探索和分解文本,并递归调用自身处理子任务。该方法成功处理了比传统模型大两个数量级的文本长度,在多项长文本任务上显著优于现有方法,同时保持了相当的成本效率,为AI处理超长文本提供了全新解决方案。
谷歌宣布对Gmail进行重大升级,全面集成Gemini AI功能,将其转变为"个人主动式收件箱助手"。新功能包括AI收件箱视图,可按优先级自动分组邮件;"帮我快速了解"功能提供邮件活动摘要;扩展"帮我写邮件"工具至所有用户;支持复杂问题查询如"我的航班何时降落"。部分功能免费提供,高级功能需付费订阅。谷歌强调用户数据安全,邮件内容不会用于训练公共AI模型。
华为研究团队推出SWE-Lego框架,通过混合数据集、改进监督学习和测试时扩展三大创新,让8B参数AI模型在代码自动修复任务上击败32B对手。该系统在SWE-bench Verified测试中达到42.2%成功率,加上扩展技术后提升至49.6%,证明了精巧方法设计胜过简单规模扩展的技术理念。