毕业倒计时阅读笔记1-如何应对开源组件⻛险？软件成分安全分析（SCA）能力的建设与演进

在毕业之前准备抽空看一些技术文章并做笔记，第一篇就从美团的技术文章开始。原文链接： https://tech.meituan.com/2022/05/26/construction-and-evolution-of-software-component-analysis-capability.html

需要说明的是，本文只作为阅读笔记，遇到的不清楚的东西就查一下，对内容的理解可能有误差，补充知识是我的笔记，而不一定是重点信息。

1 - 基础知识补充

• SCA是什么
  • 软件成分分析（Software Composition Analysis，SCA）
  • 针对现有的软件系统生成粒度非常细的 SBOM（Software Bill of Materials 软件物料单）清单，过将该清单与风险数据库进行匹配，可以识别出被引用的风险组件
  • 举例： OpenSCA社区
• CI/CD平台
  • 自动触发构建、编译和打包的一系列流程自动化的工具集合，实现自动化软件开发生命周期（SDLC）
  • 持续集成CI（Continuous Integration）和持续交付/部署CD（Continuous Delivery/Deployment）
  • CI：自动且频繁地将代码更改集成到共享源代码存储库中
  • CD：持续交付强调软件可随时部署，但部署前需人工确认；持续部署则是进一步自动化，让符合条件的代码变更直接自动上线到生产环境。

2 - 文章

这篇文章主要介绍了软件成分安全分析在企业安全中的推行与应用，三个部分：开源组件风险（安全/业务视角）、SCA建设思路、问难和展望。读完感觉文章梳理得很清晰，也对安全运营的工作有了更多理解。考虑到文章写于三年前，在阅读过程中有在想：是不是现在已经把这块工作做完了。

2.1 - 安全视⻆下的⻛险

从通用漏洞风险、供应链相关的风险、过期维护的组件三个方面 ### 2.1.1 - 通用漏洞⻛险

2021 年数据：开源代码仓库存在漏洞仓库的占比增大 2020 年报告：恶意包（Malicious Packages）2019 年度上升幅度最快的威胁之一

2.1.2 - 供应链相关的⻛险

开源组件使用过程中风险分析：

• 开源软件的生产-构建-发布过程（只看蓝色部分）：作者–【push】–>源代码管理平台 –【进行自动化建构编译测试打包】–> CI/CD平台<– 【组件依赖】–> 打包完成后【分发】 –> 生产环境

• 分析这个过程中的风险：

• IDE 插件投毒 ：作者使用的， VSCode 的插件市场发起了“投毒”行为

• 提交缺陷代码：攻击者提交恶意代码

• 源代码平台被攻陷 ：Git平台缺少保护(自己搭设的Git)

• 代码 branch 被篡改导致打包结果不一致 ：代码仓库没有添加分支保护机制；攻击者会尝试新建不同的 branch 植入代码然后进行发布

• CI/CD 体系被攻陷 ：SolarWind 事件，供应链攻击，攻击者在 CI/CD 过程中嵌入了“后⻔”，通过了签名校验，再通过 OTA 分发补丁之后

• 不安全组件引入 ：依赖引入了有问题的组件，最典型的供应链攻击手段。

• 外部 CI/CD 流程构建 ：非官方的 CI/CD ，自己打包部署，部分开源软件的使用者不会去做 CI/CD 的签名校验

• 直接部署有问题的包 ：Web-Broserify 包的事件，虽然这个包是使用了数百个合法软件开发的，但它会对收集目标系统的主机信息进行侦查

2.1.3 - 过维护期的组件

• 生产环境中开发者使用很久不更新的组件和中间件。但是，基于业务自身的规划迭代，或者因为大版本改动较多容易引发兼容性问题，升级迁移成本过高
• 企业过其他手段收敛攻击面并且建立旁路的感知体系。

引入过时版本的组件可能会引发的安全问题： - 维保问题：开源的某些版本没人管 - 安全基线不完整 ：早期安全技术局限，现代化的安全缓解技术没有应用到旧驱动上 - 未通过严谨的安全测试 ：早期安全检测范围小，老组件问题多

2.2 - 业务视角下的风险

在实际的组件⻛险修复过程中有一些吐槽： - 兼容性问题 ：安全推动版本升级，业务想保稳定性，担心存在兼容性问题 - 安全版本的问题 ：业务需要安全核查安全版本，效率低 - 安全的尺度和评价标准不够透明 - 合规：业务违反开源协议

2.3 - SCA 建设的过程

2.3.1 - SCA核心功能

首先，文章分析了SCA 核心功能应包括： - 软件资产的透视：清晰所有的应用系统引用了哪些组件 - ⻛险数据的发现 ： - 安全团队收集⻛险相关的数据 - 基于安全威胁情报能力建设，实效性和可用性的双重服务级别协议（SLA，Service Level Agreement） - 除了漏洞，主动收集开源软件的基线信息：指开源项目的安全实践、维护状态、依赖关系等基本信息。 - ⻛险与资产关联基础设施的建设： - 基础设施去实现核心 APIs 能力； - 用户自定义函数（UDF，User-Defined Function）；复杂事件处理（CEP，Complex Event Processing） - 可视化相关需求 ：安全风险与业务对齐

2.3.2 - SCA建设阶段

整体建设分成三个阶段： 1. 数据盘点与收集：与基础架构团队一起做内部基础组件的数据资产盘点；建立一个单独的开源组件⻛险数据库。 2. SOP和PoC：通用的漏洞修复 SOP和PoC，其他团队测试 - SOP（Standard Operating Procedure，标准运营流程）就是操作流程手册 - PoC（Proof-of-Concept，概念验证）就是实际上手测一测 3. 平台化及配套稳定工作：上线用起来

文中给了一个建设流程图：

资产数据的采集： - 根据最开始的分析，进行数据采集，但是出现遗漏的异常场景（例如：业务灰度到一半后忘记继续，导致同一服务的部分实例仍在运行旧版本；直接在服务器上手工部署或使用非官方 CI/CD，系统侧完全看不到） - 因此，把视角下沉到主机的粒度考虑。 - 构建链路-主机维度的数据正反校验机制：通过主机实例（Docker 容器、虚拟机、物理机）本地的 HIDS Agent，完成文件信息、进程信息、环境变量、Shell-Log 等信息的分析，确定主机实例修复完毕。 - HIDS（Host‑based Intrusion Detection System）Agent

（应该就是对每一个主机进行自动化扫描检测，进行数据收集）文中给出详细的落地核心工程和结构关系图：

资产数据的采集–> 1.

数据总线传递给数据仓库和计算引擎，完成数据的交叉和分析工作，得出的结果便是存在哪些⻛险和⻛险进度。在这里，实时引擎一方面需要承担增量资产数据的分析，另一方面也会保存很多聚合的 CEP 规则进行分析。离线引擎则是完成存量⻛险的周期性发现和治理工作。

企业更加注重SCA与人工智能（如大语言模型）融合，自动生成漏洞修复建议已成为最新趋势。

2.4 - 困难与展望

遇到的问题： - 漏洞-资产关联规则缺乏一个成熟且有效的行业标准：

3 - 总结

这篇文章发表于2022年05月26日，现在过去三年了，技术和运营角度都会有很大的改进。