如何应对开源组件⻛险？软件成分安全分析（SCA）能力的建设与演进

正文

请到「今天看啥」查看全文

不安全组件引入 ：在依赖引入的过程中，如果引入了有问题的组件，则相当于引入了⻛险，这也是目前最典型的供应链攻击手段，通过我们对各个源的安全调查和分析后发现，“投毒”的重灾区在 Python 和 NodeJS 技术栈（ 一个原因是因为前端的“挖矿”已经很成熟，容易被黑产滥用，另外一个原因是 Python 的机器学习库相当丰富，加上机器学习配套的计算环境性能强悍，导致“挖矿”的收益会比入侵普通 IDC 主机更高 ）。由于例子较多，这里就不一一列举了。

外部 CI/CD 流程构建 ：因为 CI/CD 平台有时候不能满足需求，或开发者出于其他因素考量，会使用非官方的 CI/CD 进行构建，而是自己上传打包好的 JAR 或者 Docker 镜像来部署，更有甚者会同时把打包工具链和源代码一起打包上传到容器实例，然后本地打包（极端情况下，有些“小可爱”的依赖仓库都是自己搭建的 Sonatype Nexus 源管理系统）。因为很多开源软件的使用者不会去做 CI/CD 的签名校验（ 比如说简单匹配下 Hash ），导致这类攻击时有发生。早在 2008 年的时候，亚利桑那大学的一个研究团队就对包括 APT、YUM 在内的 Linux 包管理平台进行了分析和研究，发现绝大多数源都不会对包进行校验，这些包随着分发，造成的安全问题也越来越广泛。

直接部署有问题的包 ：有些打包好的成品在使用的时候，因为没有做校验和检查，导致可能会部署一些有问题的包，最典型的例子是 Sonatype 之前披露的 Web-Broserify 包的事件，虽然这个包是使用了数百个合法软件开发的，但它会对收集目标系统的主机信息进行侦查，所以造成了相当大规模的影响。

2.3 过维护期的组件

在实际的生产环境中，有很多的开发者使用的运行时版本、组件版本以及 CI/CD 平台版本都是已经很久未更新的。当然，站在安全的⻆度上讲，安全团队希望所有的系统都用上最新版本的组件和中间件，但是事实情况是，基于业务自身的规划迭代，或者因为大版本改动较多容易引发兼容性问题，从而导致升级迁移成本过高等诸多原因，使得落地这件事情就变的不是那么容易。为了让安全性和易用性达到平衡，很多企业内部往往会进行妥协，通过其他手段收敛攻击面并且建立旁路的感知体系，来保证安全问题，也可以及时发现和止损。但是⻓久看来，引入过时版本的组件会引发诸多的问题：

• 维保问题 ：因为开源社区的人力和精力有限，往往只能维护几个比较主要的版本（ 类似于操作系统中的 LTS 版本，即 Long-Term Support，⻓期支持版本是有社区的⻓期支持的，但是非 LTS 版本则没有 ），所以一旦使用过时很久的版本，在安全更新这一部分就会出现严重的断层现象。如果出现了高危漏洞，官方不维护，要么就是自己编写补丁修复，要么就是升级版本，达到“⻓痛不如短痛”的效果，要么就是像一颗定时炸弹一样放在那里不管不问，祈求攻击者或者“蓝军”的运气差一点。
• 安全基线不完整 ：随着信息安全技术的发展和内生安全的推动，版本越新的安全组件往往会 Secure By Design，让研发安全的要求贯穿整个研发设计流程。但早期由于技术、思路、攻击面的局限性，这一部分工作往往做了跟没做一样。感触特别深的两个例子，一个是前几年 APT 组织利用的一个 Office 的 0day 漏洞，瞄准的是 Office 中一个年久失修的组件，这个组件可能根本连基本的 GS（ 栈保护 ）、DEP（ 数据区不可执行 ）、ASLR（ 内存地址随机化 ）等现代的代码安全缓解机制都没有应用。熟悉虚拟化漏洞挖掘的同学们可能知道，QEMU/KVM 环境中比较大的一个攻击面是 QEMU 模拟出来的驱动程序，因为 QEMU/KVM 模拟的驱动很多都是老旧版本，所以会存在很多现代化的安全缓解技术没有应用到这些驱动上面，从而引入了攻击面。其实，在开源软件的使用过程中也存在类似的情况，我们统称为“使用不具备完整安全基线的开源软件”。
• 未通过严谨的安全测试 ：现在的很多开源组件提供商，诸如 Sonatype 会在分发前进行一定程度的安全检测，但是时间越早，检测的范围越小。换句话说就是，组件越老出现的问题越多。毕竟之前不像现在一样有好用的安全产品和安全思路，甚至开发的流程也没有嵌入安全要求。而这样就会导致很多时候，新发布的版本在修复了一个漏洞的同时又引入了一个更大的漏洞，导致⻛险越来越大，越来越不可控。

综上所述，从安全团队的视⻆看来，⻛险无处不在。但是在一个非安全业务的安全公司，往往业务对于⻛险的理解和要求，跟安全团队的看法可能大相迳庭。

3. 业务视⻆下的安全研发⻛险

实际上在业务同学看来，他们也十分重视信息安全的相关工作，有些公司的业务技术团队甚至成立了专⻔的安全团队来协助研发同学处理安全相关的问题。可⻅业务不是排斥甚至抵制安全工作，而是缺乏合理和可操作的安全指导，进而导致业务同学不知道产品有什么⻛险。在实际的组件⻛险修复过程中，我们也收到了很多业务同学的反馈和吐槽。总结起来主要有以下几种情况：

• 兼容性问题 ：在推动以版本升级为主要收敛手段的⻛险修复中，业务提出最多质疑的往往是兼容性问题，毕竟稳定性对于业务来说非常重要。所以一般情况下，我们在推动升级时，往往会推送安全稳妥且稳定性最高的修复版本，作为主要的升级版本。但这种问题不是个例，每次遇到此类型推修的时候，业务都会问到类似问题。考虑到本文篇幅原因，这里就不再进行展开。
• 安全版本的问题 ：跟上一个问题类似，业务同学在引入组件时也会考虑安全性的问题，但业务同学由于缺乏一些安全知识，导致自己对于“安全版本“的判断存在一定的出入，所以业务同学会把这个问题抛给安全同学。但是安全同学很难100%正确回答这个问题，因为开源组件太多，绝大多数企业不能像Google、微软一样把市面上所有的组件安全性全都分析一遍，所以一般只能现用现查。一来一去，会拉低这一部分的质量和效率。所以这一部分需求也是重要且急迫的。
• 追求“绝对安全” ：有些业务同学也会直接问，到底该怎么做，才能安全地使用各种组件？话虽直接，但是能够体现出背后的问题：安全的尺度和评价标准不够透明。让安全问题可量化，并且追求标准透明也是非常急迫的工作，考虑到这更像是运营层面的问题，在此也不展开叙述了。
• 合规问题 ：很多业务因不了解开源协议，导致违反了开源协议的约束，引发了法务或者知识产权问题。

从实际情况来看，业务同学并不排斥做安全工作，很多时候是因为缺乏一个有效的机制，我们需要告诉他们引入的软件依赖是否安全，需要完成那些操作和配置才能让开源组件用起来更加安全。作为安全工程师，我们需要站在业务的视角去设身处地地想想，这些问题是不是真的不能够被解决。由于业务和安全双方都有关于组件安全相关的需求，恰好 SCA 这项技术可以很好地满足业务和自身的需求，所以在整个 SCA 建设的过程中，我们需要不断去挖掘这些需求。

4. SCA 建设的过程

其实，SCA 并不是一项很先进的技术，只是在现代的研发过程中随着流程的标准化、组件的丰富化、开源社区的活跃以及开发成本的降低等诸多原因，使得一个项目中纯自己写的代码占整个项目中全部代码的比例变得越来越低了。也就意味着供应链问题产生的影响会越来越大，随着 DevSecOps 的火爆，就重新带火了 SCA 这一传统的技术。

根据很多企业内部的实践，以及业界对于 SCA 技术的理解，我们认为 SCA 比较核心的功能主要包括以下几点：

• 软件资产的透视 ：企业内部需要对所有的应用系统引用了哪些组件这件事情有着非常清晰的认知，在考虑尽量多的情况下，尽量覆盖绝大多数的场景（ 业务应用系统、Hadoop 作业等数据服务、Puppet 等运维服务等 ），并且研究它们的开发流程，分析哪些阶段可以引入 SCA 能力做⻛险发现。
• ⻛险数据的发现 ：现在是一个数据爆炸的时代，安全团队每天需要关注的安全⻛险信息来源五花八⻔，但是需要尽可能多地去收集⻛险相关的数据，并且做上下文整合，使之可以自动化和半自动化地运营起来。但仔细想一下，除了追求⻛险数量，能否更进一步追求更强的实效性，达到先发制人的效果？通过企业内部多年的安全威胁情报能力建设，同时追求实效性和可用性的双重 SLA 是可行的。除此之外，需要关注的⻛险，不能仅仅局限于漏洞和“投毒”这两个场景，还需要对开源软件的基线信息进行收集。
• ⻛险与资产关联基础设施的建设 ：前面的两个方向是数据维度的需求，考虑 SCA 落地不单单是信息安全部⻔的事情，在实际落地过程中，还需要跟业务的质量效率团队、运维团队建立良性的互动机制，才能让安全能力深入到业务，所以需要建设相关的基础设施去实现核心 APIs 能力的建设，对业务进行赋能。虽然听上去很简单，但实际上开发的东⻄可能是 UDF 函数，也可能是某些分析服务的插件，甚至可能是 CEP（ Complex Event Process 复杂事件处理，一种应用于实时计算的分析技术 ）的规则。
• 可视化相关需求 ：既然有了⻛险，安全团队及业务相关团队的同学除了自己知道之外，还需要让负责系统开发相关同学也了解⻛险的存在，并且要及时给出解决方案，指导业务完成修复，同时安全团队也需要通过获取运营数据，了解⻛险的修复进度。

正所谓“罗⻢不是一日建成的”。虽然现在确定了 SCA 建设需求和建设的方向，但落地仍然需要分阶段完成。正如建设其他的安全子系统一样，安全团队需要按照从基础数据/SOP 开始建设，然后是平台化系统化的建设，进而完成整个 SCA 能力的落地。所以在实际操作过程中，应该将整体建设分成三个阶段进行：

• 第一阶段 ：数据盘点与收集，在项目建设前期，信息安全团队应当跟企业内部的基础架构相关的团队，完成企业内部基础组件的数据资产盘点，旨在从基础技术和信息安全的视⻆实现对研发技术栈、研发流程链路的摸排，在合适的位置进行数据卡点，从而获取相关数据，完成对资产数据的采集。另一方面，信息安全部⻔在现有的威胁情报经验和数据上，对组件数据进行数据封装和整合，建立一个单独的开源组件⻛险数据库，旨在收集来自于全量互联网上披露的⻛险，方便与后面的资产数据进行联动。
• 第二阶段 ：SOP（ Standard Operating Procedure，标准运营流程 ）和概念验证建设，信息安全团队通过自己的漏洞修复经验进行 SOP 的固化，通过不断地调优，完成一个通用的漏洞修复 SOP，通过实际的演练和概念验证（ PoC，即Proof-of-Concept ）证明，该 SOP 可以在现有的技术条件下很好地完成⻛险修复这一部分工作。同时结合 SOP，对之前收集的资产数据和⻛险数据进行查漏补缺，完成对数据和数据链路的校验工作，保证系统高可用。在这个阶段，SCA 的服务提供方需要开放部分的核心 API 给部分业务的质量效率团队，帮助他们进行测试并收集反馈，让其融入到自己的⻛险治理环节。
• 第三阶段 ：平台化及配套稳定工作的建设，当 SOP 初步成型并且完成了概念验证之后，应当需要建设对应的平台和子系统，让这一部分工作脱离手动统计，使其接近 100% 线上化。得益于内部 SOC 的模块化设计，可以在现有的平台上轻松构建出 SCA 相关的子系统，完成能力的数据。针对终端用户可视化⻛险这一问题，SCA 子系统会提供核心的 APIs 给面向研发同学端的 SOC 平台完成⻛险信息的同步。为了保证服务的高可用，后续还会建设配套的数据链路检查机制，不断完善数据的可用性。

请到「今天看啥」查看全文