从 10 万 npm 用户信息被窃看开源软件供应链安全

如今，所有热爱开源的开发者可能都心怀担忧：开源软件的供应链安全问题如何解决？关于开源代码维护者因反俄给 node-ipc 库添加恶意代码、GitHub 封停部分俄罗斯开发者账号的讨论还未结束，10 万 npm 用户账号信息被窃再登 HN 热搜，开源软件供应链的安全性成为业界关注的焦点话题。

前段时间，ARM 开源项目宣布从 GitHub 迁移至 GitLab。当时，Arm 杰出工程师兼软件社区高级总监 Andrew Wafaa 解释道：“GitHub 其实是个黑箱，我们必须与之合作、或者把一部分工作交给对方来完成，而最终结果并不一定准确可靠，使得我们不得不规划更多审查。”本期《极客有约》，我们邀请到了极狐（GitLab）的解决方案架构部负责人 Gavin 和我们一起交流如何提高开源软件供应链安全性以及极狐 (GitLab) 的一些想法。

Gavin：该事件的引爆一方面源于 GitHub 的热度，由于 GitHub 是全球最大的开源软件协作平台，而且其本身的架构是闭源的，没有任何人知道其底层逻辑。此前，GitHub 已经有很多安全相关的事件被爆出，故而 GitHub 一直不遗余力在做快速应对，GitHub 也是在第一时间发布了问题的前因后果，证明不是自己的过错。

回到问题本身，这是一个典型的软件供应链安全问题，本身与 GitHub 的架构没有关系，问题原因是有攻击者偷窃了 GitHub 的某个高级用户账号的 OAuth 令牌，从私有仓库下载数据，其中影响最大的是窃取了 10 万的 npm 用户数据。

为什么说该事件与开源软件供应链安全相关，从整个问题逻辑上来讲，与 GitHub 并没有直接关系，是其合作伙伴非常重要的账号被盗导致的用户数据泄漏，但实际上已经对 GitHub 的品牌有一定影响，因为最终向用户呈现的是 GitHub。GitHub 的快速应对做得还是不错的，立刻让该令牌失效，又重置了所有受影响的用户。之后通过自查发现，由于 npm 与 GitHub 是完全独立的架构，所以本次泄漏不是由于 GitHub 技术原因导致的。此外，GitHub 的 SRE 团队又进一步的分析，因为两个服务之间做了整合，故在 GitHub 日志系统里可以查到 npm 的日志信息，通过分析发现，npm 日志中存在很多带有明文存放的用户密钥信息，这实际上非常危险，说明 npm 架构在数据库日志里没有对用户信息做加密。

Gavin：按时间来讲，“DevSecOps“这个概念出现的时间要比“软件供应链安全”要早一点。

DevSecOps 在 DevOps 中间加 Security，即安全，这也说明其是 DevOps 在安全方面的延伸。我们知道 DevOps 是一种文化，从实践角度来讲，其解决的是软件研发生产的全生命周期管理，包括需求设计、研发测试、发布到生产运营等阶段，所以 DevSecOps 就是在软件全生命周期流程中加入安全，进而保护整个全流程安全的实践过程。

软件供应链安全是 DevSecOps 的延伸，这个延伸点在哪里？实际上，软件供应链安全是一个更大的生命周期，在 DevSecOps 周期基础上，从软件供应链安全的角度，又有上游跟下游两个阶段，上游就是对入口的安全管控，比如依赖的开源软件、采购的商业组件，下游就是出口的安全管控，即该软件的安全分发，商用交付，包括可能做为另外一个更大软件的一部分的管理。

安全左移的概念稍微小一点，对照 DevSecOps 软件生命周期，传统的安全方式不叫左移，是右置，企业软件开发完成，在上线之前请专门的安全厂商做一次针对运行环境的全方位扫描。这意味着出现任何问题都要返工，在国内软件研发，基本上工期都是非常紧凑的，能按时上线已经不不易，上线之后发现安全问题导致返工，研发人员的幸福感基本就葬送在这里了。安全左移指的是将安全前置，从需求设计到开发、测试、编译到部署上线的每一个阶段，都要进行安全管理，包括安全扫描引擎、管理措施、管理规范。而且要通过自动化工具实现，最终是在保障安全的前提下让应用上线变得高效。

Gavin：DevSecOps 从定义上来讲是指软件全生命周期每个阶段都要注入安全，如果将 DevOps 的工程实践跟安全联系起来且能保证速率，才是真正的 DevSecOps。如果没有通过 DevOps 的流水线集成全部的安全工具，即研发、测试、运维各阶段再安全方面都是各自为战，这就会造成运转缓慢，虽然每个阶段都在做安全，但实际上整个流程周期会特别长，作为开发、测试、运维人员，没有享受到工具带来的便利，只有管理带来的复杂，导致最终结果比较差。故最平滑的做法就是，先有 DevOps 的最佳实践，然后再在此经验基础上把安全工具嵌套进去，从而真正实现 DevSecOps 的价值。

Gavin：根据我的观察，欧美尤其是美国在整个安全领域，包括软件供应链的细分角度，领先国内至少四年。很多细分的安全工具，头部企业基本清一色都是欧美企业，国内很多企业在一些关键场景上也是采购国外的工具。

政策分析：

一、美国方面：

1、美国政府对安全领域大力支持，2021 年 4 月，美国正式制定软件供应链标准，由国家保护与计划局（CISA）和国家研究所标准与技术委员会（NIST）发布了论文“Defending Against Software Supply Chain Attacks”。

2、2021 年 5 月 12 日，美国总统拜登签署名为“加强国家网络安全的行政命令”（Executive Order on Improving the Nation’s Cybersecurity）以加强网络网络安全和保护联邦政府网络。

3、在 2022 年 2 月份，NIST 发布《软件供应链安全指南》，其中核心要求：

• 软件开发者应实施并证明采用了安全软件开发实践；

• 安全开发环境；

• 自动化工具确保代码完整性；

• 自动化工具检查漏洞；

4、2022 年 5 月中旬，由 Linux 基金会与开源安全基金会举办了开源软件安全峰会，集结多家科技巨头的高层主管，以及美国白宫等多个联邦机关官员参会，这次会议具体指出将解决开源软件的十大挑战，同时这些科技巨头也承诺，在未来两年内，将投入 1.5 亿元经费解决相关问题。本次峰会进一步指出开源软件十大问题：

• 安全教育

• 风险评估

• 数字签名

• 内存安全

• 安全应变

• 强化扫描能力

• 程序代码审核

• 数据分享

• 软件物料清单 SBOM

• 供应链改善

二、欧洲方面：

2021 年 5 月，英国政府宣布，正从治理 IT 供应链的组织及相关 MSP，寻求防御数字供应链攻击的建议和服务。

2021 年 5 月，德国通过了《信息技术安全法案 2.0》，作为对第一部法案的更新，该法案旨在“在日益频繁和复杂的网络攻击以及日常生活持续数字化的背景下提高网络和信息安全。”该法案影响到德国 IT 行业的许多领域，特别强调一点，针对供应商，即关键部件的制造商，也将承担一定的义务，以保护整个供应链。

2021 年 7 月，欧盟网络安全机构（ENISA）发布了一份题为《Understanding the increase in Supply Chain Security Attacks》的报告，分析了最近一年的软件供应链安全的信息。

三、国内：

国内软件供应链安全整体相对比较滞后，从国家标准角度来讲，我们在供应链方面有一些偏硬件的标准，软件供应链安全标准正在制定中，具体为：

• 2022 年 4 月《信息安全技术软件供应链安全要求》由 TC260（全国信息安全标准化技术委员会）制定

在行业标准方面，中国信通标准化由中国信通院牵头，也在做软件供应链产品方面的标准。具体为：

• 《软件供应链安全保障基本要求》 中国通信标准化协会标准

Gavin：站在软件供应链安全的角度，开源只是其中一部分，但目前绝大多数安全事件都是因为开源软件导致的，所以大家潜移默化会把软件供应链安全与开源软件漏洞紧密结合起来。

从开源软件管理角度，通常会有有三个主体：个人，企业，基金会，不同的开源项目会选择包含其中的一个或者三个主体，并不是每一个项目都要加入基金会才能运作的。而基金会的价值之一就如何保证用户的利益以及如何保证项目贡献者的利益，开源协议在这两个点发挥着重要作用，既能够保护使用者的利益，同时也能够保护生产者的利益。

Gavin：回归到法律相关，开源软件供应链相关主要有两大问题：

第一类是 License 违规使用，一些 License 会对使用者带来一些约束。比如之前很多云厂商通过售卖 MongoDB 云服务盈利，一定程度了影响了 MongoDB 的业务发展，所以 MongoDB 再 2018 年修改了 License 协议，改成了更加严格的 SSPL，根据协议，云计算厂商在 MongoDB 的基础上共享，要么从 MongoDB 获取商业许可证，要么面向社区开源相关源代码。

第二类，如果企业将产品出海到欧美市场，尤其是一些软硬结合的高科技产品，根据美国或者欧盟的法律要求，需要提供对应的供应链清单，比如产品中采用了哪些开源软件，包含了哪些商业软件，采购的商业软件的构成是什么样子？采用了哪些开源软件？版本是什么？这些版本存在哪些漏洞。如果提供不出来，可能在招投标层面会受到很多限制。如果发现违规使用 License 协议，甚至会被诉讼。

针对第一类问题，企业需要对自身开源软件的使用进行合规管控，由法务部门制定相关开源软件引入的规范，然后由信息化部门落实在软件生产的日常管理中。

针对第二类问题，企业需要建立相应的软件供应链安全管理机制，同时引入软件成分分析工具，甚至构建软件供应链安全的平台，提前对自身软件进行分析。

Gavin：第一类行业的头部企业，主要从品牌保护的角度出发，会实时关注安全技术的发展动向，即使引入最先进的安全管理技术，第二类，涉及到强监管的行业，如金融行业；第三类是出海企业，不做这件事情，产品就卖不出去，或者在竞标环节处于下风；第四类是医药领域，对用户信息数据安全非常严格，但是医药信息化相对来讲没有那么快，DevOps 做得还一般，实现 DevSecOps 自动化工具可能还有一段路要走，但是目前是一个不错的切入点。

Gavin：首先，国内目前开源环境下，大家贡献相对较少，专门做开源软件的公司也很少，需要激励大家增加开源贡献，把国内的社区、开源软件项目做大做强。从社区角度来讲，我们需要建立相对公平的态势，不断提高开源项目的价值、热度与采纳度；其次，站在平台社区的角度，社区平台需要做一些事情，让大家了解如何合理合规使用开源项目，需要告诉大家满足合规安全的开发规范是什么，只有让广大开发者真正去使用起来，才能体会到软件供应链安全和相关服务带来的价值。比如极狐 (GitLab) SaaS 版本，会给用户一到两个月的旗舰版试用期，在试用期里可以体会如何通过一体化的 DevSecOps 解决方案实现端到端的安全，开箱即用，非常方便。如果让用户体会到产品的价值，在一定程度上也会帮助整个软件供应链安全的推广。

Gavin：开发层面主要有引入 License 不合规的软件、开源软件的漏洞、测试不充分（缓存溢出、SQL 注入、跨站脚本）、密钥硬编码；交付层面是制品库被篡改；运维层面是针对服务器、网络方面的攻击， DDOS 等。

Gavin：这是一个非常有意思的问题，依赖混淆攻击的攻击方法特别简单，主要针对 JavaScript、Node.js 包等，攻击者盲猜 npm 库的命名规则，上传一个带有漏洞的版本到外网的官方 npm 库中，版本号用最新的，这样企业在自动构建的时候，会从外网下载这些带有漏洞的版本号最新的最新依赖库，从而导致被攻击。其整个攻击原理非常简单，解决途径也非常简单，最直接的就是管理好用户，不要连外网，只从自己的内部工具下载，这样肯定就没有问题了。其次，如果有外网，就需要对制品过程做一些配置，不允许制品下载的过程去访问外网，避免到外网下载恶意版本。另外，从管理角度来讲，需要加强对包命名的规范，不要轻易被攻击者猜到。

Gavin：这里讲一些低成本，简单好用的方法给到大家。首先，引入开源软件扫描引擎工具，利用这些工具对现有的第三方开源软件进行 License 扫描、漏洞扫描，有专业的商业软件，也有一些入门级的开源软件；其次，对于一些关键开源软件，如 MySQL，Redis，尽量关注其版本发布说明，软件升级除了增加功能之外，最重要的就是为了解决安全漏洞；第三，代码里面不要硬编码任何用户信息、密钥、Token，可以通过写一些脚本实现；最后，如果采用容器技术的话，我们可以引入一些容器镜像扫描工具保证镜像的安全。

Gavin：这涉及到选型过程。首先，企业需要建立真正适合自己的管理体系标准，管理好入口，满足一定要求才能引入该软件；其次，软件工具的采买要把涉及到赔偿的法规作为引入层采购的条款，这是非常重要的；第三，需要拿到采购的软件自身以及上游的软件引用清单，一定要清楚具体引入了什么软件以及对应的版本信息；最后，做整体审查，包括自己的代码和上游代码，实时关注漏洞信息，尤其是关键组件出现问题一定要第一时间解决。

Gavin：这个问题从乙方提供平台工具的角度来讲，大概分为两个流派，第一类是做安全工具厂商起家的，先有安全工具，然后再集成到 DevOps 体系中，安全工具厂商通常由多种工具解决软件供应链安全中的局部安全问题，随着 DevSecOps 兴起，安全工具厂商需要与客户的 DevOps 解决方案体系融合，慢慢形成 DevSecOps 平台类型的解决方案及产品；第二类是做 DevOps 起家的厂商，先有 DevOps，然后再整合各类安全的工具，比如极狐 (GitLab)，我们有 DevOps 端到端工具，支持云原生的 Kubernetes 和 CI/CD，在这个基础上又收购了专业解决安全的软件厂商，包括一些测试工具，同时我们又集成了其他商业工具，先有 DevOps 再有 Sec 工具。从软件供应链平台角度来讲，类似极狐 (GitLab) 这样的 DevSecOps 厂商很少。

Gavin：最近一两年，企业在引入与扩大使用云原生技术的时候，关注点已经向安全方面考虑。对于安全话题，我们要始终保持敬畏的，因为这是有一定的行业壁垒，需要专业的人经过时间的积累，才能形成不错的解决方案和比较优秀的产品。云原生厂商或者云原生延伸的安全更多在于云原生技术本身的安全，比如，如何保证网络安全？如何保障 Kubernetes 集群的安全？对于在云平台上面部署的应用的安全防护，从软件供应链的角度，开发阶段可以引入 SCA、SAST、License 检测等检测工具，发布阶段需要确保制品的安全性，在运行态，可以引入如 IAST、DAST 的检测技术，这背后是一整套安全体系，对应需要一系列的安全工具集。

Gavin：这个问题很大，我结合个人看法提几点粗浅的看法。第一点是尽快出台国家标准，包括行业标准的建立，由政府机构牵头，要集合行业专家的智慧；第二点是需要出台行业评测体系化的指导意见；第三点是打磨更多产品出来，并且在更多的行业推广起来，尤其是头部客户，需要将最佳实践分享出来引领其行业在安全方面不断向前发展。

嘉宾介绍：

Gavin WANG（王斌峰）   极狐 (GitLab) 公司 解决方案架构部负责人

Gavin 致力于帮助企业开展 DevOps 实践、云原生转型、远程办公、软件供应链安全的技术咨询工作，参与过 DevOps 一体化平台、混合云管理平台、人工智能平台、微服务运维平台、数据技术中台、架构设计项目，曾拜访逾 100 家终端用户，熟悉多个行业的转型痛点及业务诉求。