如何有效规避代码被“投毒”？

以下文章来源于 InfoQ， 作者赵钰莹

开源软件供应链当前面临的主要是两大风险：一是安全风险，一是许可证、版权、专利和出口管制等方面的法律合规风险。当然针对使用开源软件的企业来说，还有供应链风险及运维风险。这些风险如何更好地规避？开源协议、开源组织都做了哪些事情？企业如何自查内部开源项目的安全性？本期 《极客有约》，我们邀请到了 Zilliz 合伙人，首席布道师顾钧，上海安势信息技术有限公司资深解决方案架构师朱贤曼共同解答上述问题。（视频地址：https://www.infoq.cn/video/EgmPvTu4Ik9xeFJ8qToL）

InfoQ：开源软件供应链到底应该如何理解？

顾钧： 我觉得开源软件供应链和传统制造业类似，只是开源软件供应链会有很多新的挑战。传统制造业供应链的供应商承担的责任相对清晰，因为合作方之间会在成熟的法律条框下签订商业合同。但是，用户在使用开源软件时可能没有特别意识到已经对其形成依赖，该项目已经成为上游。传统意义上，可以将该开源项目理解为是供应商，但其又不承担供应商的职责。这个新的挑战就是，上下游之间没有强制的商务合作，没有法律条框可以限制使用过程，想要确保安全会有很多不确定的地方。

朱贤曼： 开源软件供应链面临的最大挑战就是企业自己都不知道用了哪些开源软件，大一点的公司可能开始关注到开源合规治理的内容，但是很多小公司可能还没有这个意识。

InfoQ：国内当前在软件供应链安全方面的意识形态大概是什么样的？

顾钧： 站在使用者的角度，Zilliz 开发服务的新一代向量数据库 Milvus ，希望提供给最终用户云服务，所以我们既是一个开源软件的供应商，但同时我们 Milvus 也引用了大量第三方开源组件，是供应链上的消费者。项目初期引用上游其他开源组件的时候，我们会有一些比较简单的规则，比如说考虑许可证的兼容性问题，加入到 Linux 基金会时也会有一些开源项目合规性检查，回溯其中引入的开源项目许可证的合规性。

站在用户的角度，明显分为两类：一类是动手能力较强的互联网类型的技术公司或者创业公司，可能没有那么严格的要求，不强制开源项目的开发团队提供一个质量保证的书面化内容，也不会尝试商务合同；另一类社区当中的用户，比如金融机构等，非常关心这个问题，尤其是想要投入到生产上的时候。我觉得国内目前有严格内部规范的企业，对开源软件供应链还是比较在意的，希望引入的开源软件有服务商提供质量保证。

朱贤曼： 国内企业做这件事的动力来源大部分都是外部压力，比如欧盟的运营商会在合同里面要求提供开源软件清单，写清楚项目中使用了哪些开源软件，且保证后续不会造成法律风险。国内的部分厂商是因为下游客户的要求，在合同里面签订相关条款，保证代码合规性，整个供应链环环相扣，这些是外部的压力。

此外，国家层面也在慢慢重视开源合规，国内有很多安全相关的法律法规，尤其是金融行业。

InfoQ：如果企业的业务在规划或正在做出海，会着重考虑这一块吗？

顾钧： 现在的厂商一般偏向于提供 SaaS 型云服务，像我们这样的创业团队是从基础软件开始做云服务，早期是在做基础软件，后来慢慢做云服务，再去做合规。海外则有很多上来就做 SaaS 相关云服务的公司，最重要的事情就是先把合规全部完成，这是很不一样的地方。

朱贤曼： 开源软件在出口管制层面的合规性要求，在美国是有法条规定的，如果不特别注意，可能会无意识当中触犯美国的出口管制条款。在中美贸易合规大背景下，企业可能就得额外关注这种合规性。所以，开源软件治理的驱动力是合规和安全，以及环境影响，比如国内之前发生的 GPL 诉讼，这会让很多公司逐渐关注开源合规并识别风险。

顾钧：GPL 开源协议和法律条款容易引人误会的地方是传统上，大家觉得要白纸黑字签署过才有法律约束，但开源协议是使用时默认代表接受整个协议，如果不接受就不能使用。

InfoQ：随着国内使用开源的人越来越多，大家对开源协议的理解程度大概是什么样子的？

顾钧： 开源协议的数量还是挺多的，GitHub 上也有一些专门的许可证选择器，帮助用户选择适合自己的许可证，基本上大家都会集中选择几大主流协议。

首先是 Apache 2.0，因为国内很多项目都加入了 Apache 软件基金会，很多新项目也是希望遵循这种方式进行治理，很多都默认选择了 Apache 2.0 许可证，所以对该许可证的解读会比较充分。

其次是 MIT 许可，因为 MIT 许可相对宽松，所以很多个人项目或者程序库型的项目，直接就选择了该许可。因为大家都比较容易理解。当然这之中可能会潜藏一些专利问题。整体上 MIT 因为最简单，大家都能理解，用的人也比较多。

最后是 GPL，名声大，受到的攻击就比较多，很多人的错误解读，造成了 GPL 的评价特别两极分化。GPL 协议的开源项目近期国内不是特别多，大家一般不会选择 GPL，但是会有一些项目选择 AGPL。

朱贤曼： 近几年，国内对许可证的理解程度要好很多，中大型企业都会关注，很多公司已经成立了专门的开源治理办公室，但实际业务当中会发现仍有很多问题需要解决。根据我目前的了解，国内对 GPL 还是能不用尽量不用，毕竟需要承担更多的合规业务。对商业应用比较友好的是 Apache，宽松、不需要开放源代码、条款也相对严谨，如果商业公司使用，法务风险相对较低。AGPL、SSPL 这种一般很多公司直接禁用。一般的分发概念，需要实际发布代码，以前的分发是寄光盘，现在可能是把源代码包上传到应用商店，但 AGPL 的分发可能通过远程访问云服务就算，这个范围就大了，所以很多公司不会选择这两种协议。如果公司内部有类似开源办公室这种角色，制订规则的时候一般会将这两者禁用。企业在对外发布开源项目时，如果希望商业化之后保留一个商业版本、一个社区版本，可能会选择类似 GPL 的许可，一方面可以收集到用户意见，也就是开源的反馈意见，用于改进商业版，同时也不希望被直接白嫖。

InfoQ：国内在供应链管理方面有没有比较好的软件工具可以推荐的？

朱贤曼： 供应链是一个系统工程，肯定不是单一工具可以解决的，需要一整套的工具。因为这个链条很长，很多都需要 DevOps 这一套工具链。但如果想知道开源治理部分的潜在风险，最基本的是要知道到底使用了哪些开源软件，由于现在软件使用的开源软件数量众多，调用关系错综复杂，且层层依赖，靠人工去梳理基本不太现实，所以一般稍大点的公司都会引入专业的 SCA 工具，用于梳理企业的产品中使用了哪些开源软件，这些开源软件存在怎样的安全风险和许可证风险。

InfoQ：发生漏洞事件之后，可以做哪些事情尽量降低不好的影响？

顾钧： 从开发人员的角度讲，如果发现了一个漏洞，首先要找到可行的绕过方法，在用户不需要进行系统更新、不需要改动任何代码的情况下将问题危害降到最低，找到方法后尽快公布，通知用户漏洞详情，如果没有也需要告知用户漏洞信息，毕竟对用户来讲是非常危险的，哪怕连夜完成修复，比较严谨的大型公司也很难将新的修复版本上线生产环境。因为这类公司有自己的流程且不易打破，连夜赶出来的修复版本也没有经过完善的测试，对企业来讲是不可取的。

朱贤曼： 如果是开源软件出现漏洞，我们一般建议升级版本，成本相对来说偏低，当然企业内部一般会有完备的应急预案，肯定不是随便发版升级的。

InfoQ：如果一个开源项目总是频繁发布漏洞修复信息，是应该使用还是尽量少用？

顾钧： 我觉得这个问题挺有趣的。首先肯定要看开源软件本身的代码质量以及 Issue 里的反馈，对开源项目本身有一个整体评判。如果觉得软件不行就不要使用，如果用户反馈比较积极，经常更新漏洞信息说明真的有很多人在用，经常有用户给出反馈，说明项目质量在稳步提高。此外，也要注意频繁升级带来的成本。

朱贤曼： 我在做行管时，如果软件频繁出现安全漏洞升级信息，不建议使用。当然也分情况，开源软件同类型的项目很多，要多方面综合考虑，但是一般不建议选择频繁出现漏洞，或者漏洞版本很多的开源软件，建议选择基金会支持或者商业公司主导的项目，当然这种项目也曾出现过较大漏洞，但相对来说可能会有保障一些。

InfoQ：开源项目有什么样的措施保证安全性？

顾钧： 代码托管在 GitHub 上，平台就有专门的工具扫描依赖，如果有比较严重的安全性问题会提示是否升级到新的版本。软件升级本身是一个复杂的过程，有时升级太快会引入一些新的问题，如果只是一些简单修复，对其他的影响不大，我觉得是需要积极升级的。当然有时候，这种修复也可能会引入新的问题。企业在生产当中要具体问题具体分析。

InfoQ：开源项目背后的商业公司在整个过程中起到什么样的作用，或者说会引入一些什么样的风险吗？

顾钧： 早期来看，很多开源软件都是社区驱动的，要保证项目长期发展，光靠社区志愿是很难的，没办法要求太高。只有商务合同或者有现实利益分配时，才能确保需要的项目按时交付，个人业余时间做的项目出现在依赖上，无法提出太多要求。如果开源项目成立自己的商业公司，用户可以与其签订法律合同，提出 SLA 或问题修复时效相关的承诺，这些开源软件背后的公司扮演了一个让供应链更牢固的角色。

朱贤曼： 我非常认可顾老师的观点，站在企业的角度，选择开源软件，我会建议考量这些因素。如果自己没有支持能力，建议选择有商业背景的公司，可以购买公司提供的服务。有时免费的才是最贵的，有人帮助对整个项目兜底，至少能够解决很多问题，这是值得做的方式。

InfoQ：请两位分享开源软件供应链可能面临的风险或者问题？

顾钧： 我觉得从早期许可证的角度来讲，很容易出现类似 MIT、BSD 这种过于宽松的协议，因为其不带专利所有权。代码虽然是开源的，但不代表不能就这些代码申请专利。开发者可以在代码开源之前，先递交专利申请。如果开源项目的协议是 Apache 2.0，提交代码时已经默认授权用户在项目范围内使用专利，这也是相对安全的。类似 MIT 或者 BSD 这些可能就没有这个显式过程，会有另外的方式去弥补，比如通过 CLA 的方式将专利授权给项目用户使用，这是从许可证兼容性和专利层面的考量。

另一个显著问题是需要将企业内部流程或者习惯做法更加规范化。因为之前开源的 JavaScript 生态当中的一些开源项目，作者直接往 npm 站点上传所谓的“有毒”代码，正常情况不应该在生产环境中直接下载 mpn 包做升级，肯定有测试环境，验证升级没问题再搬到生产环境，用户需要有这样的流程。

朱贤曼： 一般来说，开源软件的风险可能来自四个方面：一是安全风险，其中又分为开源软件本身的安全漏洞导致的风险和目前关注度很高的软件供应链攻击的风险，个人建议不信任所有从外面下载的组件；二是法律风险，其中又分为许可证本身的协议，如果未履行开源合规义务，可能会造成侵权而遭到索赔、诉讼、产品下架、商誉受损等风险。另外一个是专利方面的风险，一种是本身的创建者 / 贡献者实现的专利，有可能预埋专利陷阱，另一种是第三方专利维权风险。此外，还有商标侵权及出口管制方面的风险；三是供应链断供风险，比如俄乌事件后，可能 GitHub 直接就不允许俄罗斯开发人员下载代码了，甚至把俄罗斯账号的代码提交删掉了。还有上次 faker.js 删库事件，导致后续版本和代码更新都没有了；四是运维风险，如果企业自己没有能力支撑，没有商业公司帮忙的话，维护成本很大。

InfoQ：请两位老师简单分享开源软件供应链常见的攻击类型。

顾钧： 首先是专利，比如潜水艇专利，预留专利埋坑，这类是很不容易防范的，因为专利审核对一般公司来讲需要一些代价。其次是恶意代码，现在主流的开源软件分发方式就是 npm、GitHub，从公开站点获得开源软件后一定要做验证，这能够帮助大家减少很多麻烦。

朱贤曼： 一种是恶意代码，前段时间也有新闻提到可以在 GitHub 上把恶意代码装上去且不留下任何记录，这是很恐怖的，我们还是比较信任 GitHub 上面下载下来的内容，因为我们认为这是官方网站。另外一种最近提的比较多依赖混淆攻击，npm 包管理器的设计存在一些问题，比如用户创建了一个私人组件，其版本是一个范围，如果同名组件更新源码，但其中存放了恶意代码，也会自动拉取过来，同名组件的代码就跑到用户环境中了，企业内部在引入组件时则需要做更多校验，我们建议企业建立自己的开源软件库，在组件进来之前有个准入机制，做测试验证，保证所使用的组件都是受信任的。当然这个成本是相对较高的，但确实很有必要。

InfoQ：关于断供问题怎么解决？

顾钧： 开源本身不限制地域，但是承载开源这件事情的通常是一个商业实体，商业实体会受到所在地区的出口管制法，或者其他制裁条例的限制。很多时候，我们现在用到的开源软件，包括自己的开源软件都托管在 GitHub 上，GitHub 是美国的公司，必然会受到美国的出口管制法的限制。从这个角度来讲，企业内部可以建内部代码库，所依赖的东西可以将其放在内部代码库上，万一有一天访问不了 GitHub，总有个备份的源码池可以获得这些代码。从国家角度来讲，对此一直在做准备。目前来讲，我觉得大家都有各自的解决方法，似乎影响没有那么大。

朱贤曼： 我个人觉得，相比许可证合规和安全风险来说，断供风险只是开源众多风险之一，相对来说还是影响比较小的，开源治理更多的是许可证的法律法务的合规和安全性。

讲师介绍：

顾钧，Zilliz 合伙人、首席布道师，LF AI&Data 基金会 TAC 成员，开放原子基金会开源导师。北大毕业 16 年以来专注于数据库、大数据技术，尤其对 OLTP 平台与场景有着丰富的经验，先后任职于工商银行、IBM、摩根士丹利、华为等企业。运营的视频号 ID 为「JUN 不断向前」，不定期更新开源领域的热门趋势及重要内容解析。

朱贤曼，上海安势信息技术有限公司资深解决方案架构师，十余年软件开发经验，先后从事出口管制合规、合规相关系统设计和实施、开源软件合规等工作。