专访奇安信董国伟博士：目前开源安全的现状并不乐观，但其重要性已成各方共识

采访嘉宾 ｜董国伟

编辑 ｜ Tina

2022 年 7 月，奇安信集团对外发布了《2022 中国软件供应链安全分析报告》，对过去一年多来国内软件供应链各个环节的安全形势，进行了深入细致的分析。《报告》指出，尽管“Log4Shell”漏洞造成了空前的影响，但关键基础开源软件仍然没有引起足够的重视。2022 年底，我们借助“年终盘点”之机，采访了奇安信集团代码安全实验室高级专家董国伟博士，进一步了解开源安全的现状和应对措施。

InfoQ：您如何评价当前的开源安全现状？目前开源安全存在哪些关键问题？

董国伟：2021 年和 2022 年，我们连续两年发布了《中国软件供应链安全分析报告》，基于我们的产品和技术能力，在广泛测试、分析、统计的基础上，对开源安全的现状进行了总结。

总体而言，目前开源安全的现状并不乐观，存在的关键问题包括：

1、开源软件安全漏洞和缺陷持续增加。根据我们的分析统计，漏洞的增长速度、安全缺陷和高危安全缺陷的密度，以及典型缺陷的检出率均呈现出增长的趋势；国内企业开发的软件项目中，100%使用了开源软件，存在已知开源软件漏洞的项目占比 86.4%，平均每个项目存在 69 个已知开源软件漏洞，十几年前的古老开源软件漏洞依然存在于多个项目中。并且我们通过实例分析，也证实了“老漏洞”攻破最新主流产品的情况。

2、开源软件的运维安全需要重视。开源软件生态系统中，版本长时间不更新和更新非常频繁的开源项目，比例都在增加；企业开发的软件项目中仍然在使用 20 年之前老旧版本的开源软件。

3、关键基础开源软件更应该引起关注。关键基础开源软件指那些被其他开源软件广泛依赖的开源软件，它们一旦爆发漏洞，影响范围可能会很大，如 Log4j2 漏洞，根据我们的统计，开源生态系统中，这种软件大量存在，它们的安全性，如安全漏洞，应该引起更多的关注。

4、开源软件透明度低是引发一系列安全问题的主要原因。有许多包括开源软件在内的第三方来源的成分，我们并不知道其具体包括哪些内容，因此对其安全性的了解更无从谈起。在这种情况下，建议将软件物料清单（SBOM）作为软件供应链安全的抓手首先推进落地，通过软件物料清单（SBOM）的推广应用，牵引软件供应链上下游各个环节的协同。

InfoQ：如果开源安全性不足，会给大家带来哪些潜在威胁（会有比爆发出来的 Log4Shell 更严重的后果吗）？

董国伟：开源软件的安全性不足，会带来多种多样的潜在威胁，主要包括战术和技术两个方面，如漏洞、后门、恶意代码植入和欺骗、恶意依赖项、编译器破坏、依赖混淆、包完整性篡改、上游源代码删除、OSS 组件停止修复、未按时修复漏洞、包管理器恶意代码上传等，从造成的结果来看，包括数据泄露、勒索病毒、隐私泄露、恶意攻击、恶意挖矿等。

因为开源软件和自研软件在代码层面并没有本质区别，所以开源软件带来的安全威胁并不会比自研软件少。此外，由于研发人员对开源软件仅局限于功能使用，因此，对开源软件引入的安全威胁缓解，可能出现花费大量成本、修复出现错误、引入新的安全隐患等问题。

前面已经提到过，根据我们的统计，开源生态系统中存在大量依赖关系数量巨大的开源项目，比 Log4j2 组件依赖数多的组件也不在少数，这些作为“底座”的组件一旦爆发严重漏洞，其波及的范围可能比 Log4Shell 要大，完全有可能造成比它更严重的后果。

InfoQ：对于开源软件的漏洞所造成的损失，您认为是否应该有相关的问责机制？

董国伟：我们认为不应该简单地对所有开源软件漏洞所造成的损失，都按照统一的标准来处理。

一方面，开源生态之所以像今天这么繁荣，是因为开源软件采用的自由许可协议和一系列免责条款，大大激发了所有开发者的激情，开源社区在这方面做出了很大的贡献。正是这种机制，使得对开源社区和开源贡献者进行像针对其他软件开发商那样的强约束较为困难。目前国内正在研究的一些标准中，也未将开源贡献者作为一类供应方来管理。因此，开源软件的维护和自测等方面势必存在一些较为薄弱的环节，如果对开源开发者所无意引入的安全漏洞进行问责，会极大地打击他们的积极性，影响开源生态的正常发展。我们认为对于普通的开源软件漏洞，不应该进行问责。

另一方面，对于极少数开源开发者主动引入后门、植入恶意代码的行为，其实是在实施基于供应链的攻击了，我们认为应该进行必要的问责，从而抑制类似行为的发生。

InfoQ：2022 年，您观察到整个行业开源安全有什么样的关键变化？

董国伟：过去的一年里，我们看到软件供应链安全的一系列国家标准、行业标准正在制定中，软件供应链安全相关的科研课题和建设项目逐渐增多，部分重要行业监管部门还出台了关于软件供应链安全的具体工作要求，面向软件供应链安全的社区、联盟、论坛等也在逐渐建立和完善中，软件供应链安全的重要性已经逐步成为各方共识。

同时，由于软件成分分析(SCA)工具的普及，开源组件的漏洞问题开始大量暴露出来。软件企业在面临如此多的安全漏洞时，也开始寻求减少修复时间的技术方案。因此，一方面，漏洞的危害性和影响性分析被反复提及，它们能够有效减少实际需要修复的漏洞数量；另一方面，漏洞的修复方案（尤其是缓解措施），也成为 SCA 检测工作所必备的功能，它们能够大量减少漏洞修复所需要的成本。

InfoQ：这一年，在您记忆中，有哪些关于开源安全的关键事件发生？软件安全企业相应地做出了哪些行动？

董国伟：根据我们的跟踪统计，几乎每个月都会发生有关开源安全的典型事件，涉及开源软件安全漏洞、开源生态系统安全等方面，例如

2021 年 11 月，热门 NPM 包 coa 和 rc 连续遭劫持，并被植入恶意代码，影响全球 React 管道。coa 库每周下载量约 900 万，用于 GitHub 上近 500 万个开源库中，rc 库每周下载量达 1400 万。

2021 年 12 月，Apache Log4j2 曝出 Log4Shell 漏洞(CVE-2021-44228)，Apache Log4j2 是 Java 应用最广泛的开源日志组件，广泛应用于政府、企业和公共服务机构的平台、应用和业务系统中，该漏洞覆盖范围广而且利用门槛低，对大量系统和机构造成了严重影响。

2022 年 3 月，俄乌冲突中，NPM 开源包 Node-ipc 的作者 RIAEvangelist 作为反战人士，在代码仓库中进行了“供应链投毒”，添加的恶意 js 文件能够在包使用者的桌面创建反战标语。Node-ipc 使用非常广泛，每周下载量超过 100 万次。

2022 年 4 月，以色列安全公司发现高通和联发科芯片的音频解码器存在三个漏洞（CVSS 评分为 9.8、7.8 和 5.5），来源于 11 年前苹果公司开发的开源无损音频编解码器 Apple Lossless。利用这些漏洞进行攻击，可获取受影响移动设备媒体、音频会话的访问权限及摄像头数据流等，漏洞影响范围包括数百万安卓设备。

2022 年 7 月公开(可追溯至去年 12 月)，攻击者通过在 NPM 上发布包时绕过双因子认证(2FA)，创建了 1000 多个用户账号，攻击者利用这些账号自动投放 1283 个包含挖矿脚本 eazyminer 的恶意模块，利用数据库、Web 等所在服务器的机器闲置资源进行挖矿。如果开发者安装了这些包，则会在被调用时挖掘门罗币。

这些事件中，最典型的还是 Log4Shell 漏洞事件。作为软件安全企业，比如奇安信在 log4j2 漏洞爆发前就已经收录了该漏洞影响的组件信息；漏洞爆发后，奇安信开源卫士把漏洞和这些组件信息关联，结合官方修复建议如升级版本或修改配置，立即生成知识库更新包，分发到客户的开源卫士管理端。同时，通过漏洞告警服务通知所有客户，给出了漏洞详情和修复建议。

InfoQ：您预测 2023 年，开源安全有着什么样的发展趋势？

董国伟：根据我们对相关事件的追踪，明年，开源软件和软件供应链依然是重要的攻击领域之一，攻击事件仍然会保持持续高发态势。

但另一方面，各行业对开源安全的认知也在不断提升，对这一领域的关注度在不断提高。2022 年 11 月初，国家标准《软件产品开源代码安全评价方法》完成立项，相关研究也正在推进，这说明国家层面已意识到开源软件安全的重要性，并着手规范应对此类问题。企业层面，也正在制定和完善内部的开源软件安全管理规定，规范开源软件的安全使用，减少其引入的风险，相信明年力度将更大。

InfoQ：开源软件供应链攻击主要有哪些类型？其中最薄弱的环节是什么？有哪些有效的实践可以最大程度地降低供应链风险？

董国伟：开源软件供应链攻击主要包括漏洞、后门、恶意代码植入和欺骗、恶意依赖项、编译器破坏、依赖混淆、包完整性篡改、上游源代码删除、OSS 组件停止修复、包管理器恶意代码上传等。

其中最薄弱的环节应该是开源软件自身及其依赖项中存在的安全漏洞。

目前，可以考虑从两个角度来降低开源软件带来的供应链风险。一是通过软件成分分析（SCA），有效发现软件中的开源组件等第三方软件成分，以及其依赖关系，并了解其历史漏洞、许可证违规等安全风险；二是对开源软件在使用之前，像自主研发的代码一样进行代码审计、安全测试等必要手段，尽量减少安全问题的引入。

InfoQ：像 OpenSSF 提供了 SBOM 软件清单，您认为这套方法对软件安全多大帮助？安全软件企业有类似方法吗？

董国伟：软件组成成分的透明度是软件供应链安全保障的基础，在充分了解的基础上更方便进行安全性的分析。

我们建议将软件物料清单（SBOM）作为软件供应链安全的抓手首先推进落地，通过软件物料清单（SBOM）的推广应用，牵引软件供应链上下游各个环节的协同，在此基础之上再采取更多举措逐步深化，实现软件供应链安全保障的目标。

软件安全企业的软件成分分析（SCA）工具能够方便的实现 SBOM 的自动生成功能，在目前软件开发普遍集成开源软件的情况下，此类工具对于提升软件透明度、开展安全分析具有重要作用。

InfoQ：您们是否有建议的“开源安全工具”或非开源“安全工具”？它们主要是通过什么方式去评估和保证开源软件安全的？

董国伟：建议的工具包括奇安信的开源卫士和代码卫士。

开源卫士是一款软件成分分析(SCA)工具，能够发现软件中的开源组件等第三方软件成分，以及其依赖关系，并给出相关成分的历史漏洞、许可证违规等安全风险。

代码卫士是一款代码审计工具，通过扫描开源软件的源代码，发现其中的安全缺陷和违反安全编码的情况，可以在使用开源软件前发现安全问题。

InfoQ：我们知道以前开源安全主要靠“Given enough eyeballs, all bugs are shallow” 以及一些零散措施。那么我们该倡导什么指导原则去做开源安全？

董国伟：目前随着软件开发企业对开源软件使用的增多，一般都有一套管理流程，虽然流程的细节各不相同，但一般都考虑从获取、评估、入库、维护、使用等环节建立系统的安全防护手段，例如在获取的时候，要求从官方的网站下载、评估其 MD5 等内容。

问题中提到的零散措施是保障这一系统工作的具体细节内容，例如评估时进行漏洞分析、代码审计等，也是不可或缺的部分。

因此，我们倡导的指导原则是建立系统化的适合开源软件使用全周期的安全评价体系，并将相应的具体工具和技术等措施贯穿其中。相信国标《软件产品开源代码安全评价方法》制定完成后将更加有力的促进该原则的落地和执行。

InfoQ：对比在开源项目发布和运行之后进行补救，“ Security by design ”也同样重要。我们的读者都是软件开发相关的人员，那么您认为作为开发人员，应该如何去提升软件安全？我们需要具备哪些必要的知识？

董国伟：作为开发人员，是自己研发软件代码安全性的第一责任人，无论是开源软件还是其他类型的软件。根据我们工作中积累的经验，建议开发人员学习和具备以下安全知识：

1、安全设计。软件的安全设计本身就有一套成熟的方法论，像威胁建模中的 STRIDE 模型等技术和工具，能够帮助开发人员在设计阶段了解系统可能面临的风险；

2、安全编码。学习自己常用语言的安全编码规范，并在软件开发过程中切实的实现，能够有效降低因编码不规范而引入安全缺陷的数量，同时会使用代码审计工具检测自主研发代码中不合规的情况；

3、安全缺陷分析。学习安全缺陷分析技术，能够在自动化工具的辅助下，对自己编写的代码进行缺陷分析，发现其中的安全问题，并根据修复建议进行修改。

InfoQ：未来几年，开源软件供应链安全演进方向是什么样的？（谈谈未来软件供应链发展的看法？）

董国伟：我们认为主要有三个方向：

1、针对开源软件的漏洞分析依然是重中之重。目前，开源软件安全漏洞是该领域攻击事件频繁发生的根源，但是开源软件数量、规模、关注者的急剧增长也是不争的事实。因此，针对开源软件的规模化、智能化漏洞分析技术需要进一步提升，并且漏洞相应的修复、升级等工作因开源软件的公开化和关注度高等特点，需要更加注意时效性。

2、SBOM 在业界的统一和推广是一个亟待解决的命题。SBOM 作为一项技术，近几年的研究非常火热，但是受厂商担心企业信息泄露等因素的影响，其在业界的推广进程并不大。特别是在国内，还没有一个统一的 SBOM 格式的标准，并且，SBOM 的使用和交付目前也没有相关政策法规的支撑。这些都是制约 SBOM 进一步实施的因素，需要在未来解决。

3、开源生态的安全也值得特别关注。当前的开源软件供应链安全事件中，有许多是关于开源包生态系统的，例如前面实例中提到的针对 NPM 包的劫持、针对 NPM 包的投毒，以及依赖混淆等安全问题，可见 NPM 之类的开源包生态也是供应链攻击的主要目标之一，因此，针对这些恶意软件的扫描和分析也应该成为未来的重点工作之一。