探索软件组合分析

已完成

软件组合分析(SCA)是一个自动化过程,用于识别应用程序中的开源和第三方组件、分析其安全漏洞、许可证合规性和代码质量。 随着新式应用程序越来越依赖外部依赖项,SCA 对于管理与软件供应链相关的风险至关重要。

什么是软件组合分析?

软件组合分析 是自动发现、编录和分析应用程序中使用的所有开源和第三方组件的做法。 SCA 工具检查包清单、依赖项锁文件、源代码和已编译二进制文件,以创建全面的软件材料清单(SBOM)。

核心 SCA 功能

依赖项发现:

  • 清单分析: SCA 工具读取包清单文件(package.json、requirements.txt、pom.xml、*.csproj)来标识声明的依赖项。
  • 锁定文件分析: 分析锁文件(package-lock.json、Pipfile.lock、Gemfile.lock)显示确切已安装的版本,包括可传递依赖项。
  • 二进制扫描: 高级工具扫描已编译的项目、容器映像和已部署的应用程序,以发现清单中未声明的嵌入依赖项。
  • 多语言支持: 综合工具支持数十种编程语言和包生态系统(npm、PyPI、Maven、NuGet、RubyGems、Go 模块)。

漏洞分析:

  • CVE 匹配: 将已发现的依赖项与常见漏洞和暴露(CVE)数据库进行比较。
  • 严重性评分: 计算常见漏洞评分系统(CVSS)分数,指示漏洞严重性从 0(无)到 10(严重)。
  • 漏洞利用情报:确定哪些漏洞存在已被攻击者实际利用的已知漏洞利用手段。
  • 修补程序建议: 建议特定版本升级,以在保持兼容性的同时解决漏洞。

许可证符合性:

  • 许可证检测: 通过分析许可证文件、包元数据和源代码标头来识别所有依赖项的许可证。
  • 策略强制: 自动标记违反组织许可证策略的依赖项。
  • 兼容性分析: 检测无法合法合并在同一应用程序中的冲突许可证。
  • 义务跟踪: 文档许可证要求,如归属通知、源代码披露或衍生工作限制。

质量评估:

  • 维护状态: 评估是主动维护还是放弃依赖项。
  • 社区健康: 评估参与者活动、社区规模和项目可持续性。
  • 安全做法: 验证项目是否具有负责任的披露流程和安全公告。
  • 更新建议: 识别过时的依赖项,并建议更安全、更最新的替代方法。

为什么 SCA 对于 DevOps 至关重要

现代软件开发实践使 SCA 不可缺少:

依赖项爆炸

应用程序包含数百个依赖项:

  • 直接依赖项: 典型的应用程序直接引用 20-50 个外部包。
  • 可传递依赖项: 每个直接依赖项都自带依赖项,创建包含 200-500 个包的依赖项树。
  • 多个生态系统: 应用程序通常合并多种语言生态系统中的依赖项(JavaScript 前端、Python 后端、Java 微服务)。
  • 容器依赖项: 容器化应用程序包括基础映像依赖项和应用程序依赖项。

手动跟踪是不可能的:

  • 规模: 在数十个应用程序中手动跟踪数百个依赖项是不切实际的。
  • 速度: 每天披露新的漏洞,使任何手动清单立即过时。
  • 复杂性: 了解可传递依赖项链及其交互需要自动分析。
  • 分布式所有权: 全球数千个独立开源项目维护的依赖项。

安全的重要性

正在积极利用依赖项中的漏洞:

  • 高调漏洞: 重大安全事件经常涉及利用常用开源包中的已知漏洞。
  • 供应链攻击: 攻击者入侵合法包,以将恶意软件分发给下游使用者。
  • 零天漏洞: 以前广泛使用的包中的未知漏洞可同时影响数千个组织。
  • 修补紧迫性: 关键漏洞需要跨所有受影响的应用程序快速识别和修正。

传统安全工具缺少依赖项漏洞:

  • 静态分析: 源代码扫描工具分析代码,但不分析依赖项代码。
  • 动态测试: 渗透测试可能会错过测试期间未触发的依赖项中的漏洞。
  • 手动评审: 安全团队无法查看数百个第三方包的源代码。
  • 专用检测: 需要专门用于识别依赖项漏洞的 SCA 工具。

符合性要求

违反许可证可能会带来重大风险:

  • 法律责任: 使用不符合许可条款的依赖项可能会导致诉讼和损害。
  • 强制开源:强 copyleft 许可证(如 GPL、AGPL)可能要求整个应用程序开放源代码。
  • 分发限制: 某些许可证禁止商业分发或施加使用限制。
  • 审核要求: 监管框架越来越多地要求组织维护准确的软件材料清单。

许可证复杂性:

  • 数百种许可证类型: 开放源代码生态系统包括数百个具有不同义务的不同许可证。
  • 兼容性问题: 不同的许可证具有相互冲突的条款,禁止它们一起使用。
  • 可传递许可: 必须跟踪和满足来自可传递依赖项的许可证义务。
  • 许可证更改: 项目有时会更改版本之间的许可证,需要持续监视。

SCA 工具的工作原理

SCA 工具使用多种方法来发现和分析依赖项:

发现机制

清单文件分析:

  • 特定于语言的格式: 工具了解每种语言的包清单格式(npm 的 package.json、Python 的 requirements.txt、Maven 的 pom.xml)。
  • 依赖项解析: 分析依赖项版本规范,包括范围、约束和解析规则。
  • 工作区扫描: 以递归方式扫描项目目录,以查找 monorepos 和多项目工作区中的所有清单文件。
  • 配置感知: 单独考虑特定于环境的依赖项(开发、测试、生产)。

依赖项锁定文件分析:

  • 确切版本: 锁定文件记录所有依赖项的精确版本,包括可传递依赖项。
  • 安装状态: 表示实际安装的依赖项,而不是抽象要求。
  • 确定性解析: 锁定文件可确保跨环境一致的依赖项版本。
  • 完成依赖项关系图: 包含完整可传递依赖项树及其版本解决方案。

二进制和工件扫描:

  • 已编译的项目: 扫描 JAR 文件、滚轮文件、DLL 和可执行文件,以识别嵌入的依赖项。
  • 容器映像层: 分析容器映像层,以发现基础映像组件和应用程序依赖项。
  • 文件系统扫描: 检查已部署的应用程序文件系统以查找清单中未声明的依赖项。
  • 指纹: 使用加密哈希识别特定包版本,即使没有元数据也是如此。

生成集成:

  • 生成工具插件: 与生成系统(Maven、Gradle、webpack、pip)集成,以捕获生成期间的依赖项信息。
  • 分辨率挂钩: 挂钩到依赖项解析进程,以记录安装的确切版本。
  • 工件生成: 在构建期间生成软件物料清单(SBOM)工件以供下游使用。
  • 管道集成:在 CI/CD 管道中作为自动化步骤运行,以分析每个生成。

分析功能

漏洞匹配:

  • 数据库查询: 查询国家漏洞数据库(NVD)、GitHub 顾问数据库和专有漏洞数据库。
  • 版本范围匹配: 确定特定包版本是否属于易受攻击的版本范围。
  • 修补程序验证: 验证已应用的修补程序是否确实解决了报告的漏洞。
  • 优先级: 按严重性、可利用性和业务影响对漏洞进行排名。

许可证标识:

  • 多个源: 从包元数据、许可证文件、源标头和自述文档中提取许可证信息。
  • 许可证规范化: 将各种许可证名称和标识符(SPDX、OSI)映射到标准化许可证类型。
  • 双重许可: 处理在多个备用许可证下发布的包。
  • 自定义许可证: 确定需要法律审查的非标准许可证。

可访问性分析:

  • 调用图构造: 生成调用图,显示应用程序实际执行哪些依赖项代码。
  • 死代码检测: 标识捆绑但从未实际使用的依赖项。
  • 攻击路径分析: 确定可从应用程序入口点访问易受攻击的代码路径。
  • 风险优化: 通过关注实际使用代码中的可利用漏洞来减少干扰。

持续监视:

  • 实时警报: 当新的漏洞被披露影响到您的依赖时,立即获取通知。
  • 计划扫描: 定期重新扫描应用程序,以检测未更改依赖项中新发现的漏洞。
  • 基线比较: 跟踪一段时间内漏洞和符合性状态的更改。
  • 回归防护: 当新的依赖项引入漏洞或许可证冲突时发出警报。

SCA 集成模式

有效的 SCA 实现涉及开发生命周期中的多个点的集成:

开发人员工作站

IDE 集成:

  • 实时反馈: 当开发人员将它们添加到项目中时,扫描依赖项。
  • 内联警告: 直接在 IDE 中显示漏洞和许可证警告。
  • 修正建议: 建议备用包版本或替换包。
  • 策略强制: 防止添加违反组织策略的依赖项。

预提交验证:

  • Git 挂钩: 在提交之前运行 SCA 检查,以防止引入易受攻击的依赖项。
  • 本地扫描: 在推送到远程存储库之前在本地分析更改。
  • 快速反馈: 在积极开发期间向开发人员提供即时反馈。
  • 早期检测:在到达共享分支和 CI/CD 管道之前捕获问题。

源代码管理

拉取请求验证:

  • 自动检查: 对所有拉取请求运行 SCA 分析,以检测依赖项更改。
  • 审阅批注:将结果作为拉取请求批注发布,供审阅者查看。
  • 合并阻止:防止合并导致严重漏洞或许可证冲突的拉取请求。
  • 依赖项更改跟踪: 清楚地记录每个拉取请求引入的依赖项更改。

GitHub Dependabot 集成:

  • 自动更新: 当依赖项安全更新可用时自动创建拉取请求。
  • 漏洞警报: 接收 GitHub 安全警报,以获取易受攻击的依赖项。
  • 依赖项关系图: 在 GitHub 的依赖项图功能中可视化依赖项关系。
  • 查看工作流: 利用 GitHub 的评审和审批流程进行依赖项更新。

CI/CD 管道

构建时扫描:

  • 管道步骤: 在 CI/CD 管道中添加 SCA 扫描作为自动化构建步骤。
  • 质量门:无法满足安全性和合规性要求的生成。
  • SBOM 生成:与生成输出一起创建材料项目软件帐单。
  • 审计跟踪: 记录扫描结果以用于合规性和取证目的。

部署入口:

  • 预部署验证: 在部署到生产环境之前扫描项目。
  • 特定于环境的策略: 对生产部署应用比开发部署更严格的策略。
  • 回滚触发器:自动回滚被发现包含严重漏洞的部署。
  • 部署审批: 需要手动批准具有已知但接受风险的部署。

运行时监视

生产扫描:

  • 部署的应用程序分析: 扫描实际部署的应用程序以检测运行时依赖项。
  • 容器注册表扫描: 持续扫描存储在注册表中的容器映像。
  • 无服务器函数分析: 扫描部署的无服务器函数及其依赖项。
  • 偏移检测: 确定预期和实际部署的依赖项之间的差异。

持续漏洞监视:

  • 持续监视: 监视已部署的应用程序,了解影响当前依赖项的新漏洞。
  • 事件响应: 在生产环境中发现严重漏洞时触发事件响应工作流。
  • 修补程序规划: 生成修补程序部署计划,以解决已部署应用程序中的漏洞。
  • SLA 符合性: 跟踪修正时间范围,以确保符合安全 SLA。

SCA 工作流最佳做法

成功的 SCA 实现遵循经过验证的工作流:

建立基线

初始清单:

  • 全面发现: 对所有应用程序运行 SCA 工具,以创建完整的依赖项清单。
  • 风险评估: 了解当前对漏洞和许可证符合性问题的暴露。
  • 优先级: 确定哪些应用程序和漏洞需要立即注意。
  • 基线文档: 将当前状态记录为用于衡量改进的基线。

定义策略

安全策略:

  • 漏洞严重性阈值: 定义可接受的严重性级别(例如,没有严重性、有限的高级别)。
  • 修正时间范围: 建立 SLA 以修补不同的漏洞严重性(7 天内严重,30 天内高)。
  • 异常进程: 创建工作流,以便在即时修正不可行时接受风险。
  • 豁免跟踪: 保留已接受的风险及其业务原因的审计踪迹。

符合性策略:

  • 许可证允许列表: 指定始终可接受的许可证(MIT、Apache 2.0、BSD)。
  • 许可证拒绝列表: 禁止与业务模型不兼容的特定许可证(专有软件的 GPL)。
  • 审批工作流: 要求对具有某些许可证的依赖项进行法律审查(LGPL、MPL、自定义许可证)。
  • 归属要求: 定义如何在分布式软件中提供许可证归属。

自动化实施管控

管道集成:

  • 自动扫描:在每个生成和拉取请求上自动运行 SCA 检查。
  • 质量门: 配置用于阻止违反策略的生成或部署的管道关卡。
  • 自动修正: 使用 GitHub Dependabot 等工具自动为安全更新创建拉取请求。
  • 报告: 生成符合性报告,以便审核和管理可见性。

持续改进

指标跟踪:

  • 修正的平均时间(MTTR): 测量发现后修补漏洞的速度。
  • 漏洞减少: 跟踪随时间推移减少的漏洞计数。
  • 合规性率: 监视满足许可证策略的依赖项百分比。
  • 覆盖: 确保 SCA 工具扫描所有应用程序和依赖项。

流程优化:

  • 误报管理:优化工具,通过配置和异常减少误报。
  • 开发人员培训: 教育开发人员安全依赖项选择和管理。
  • 策略演变: 根据新兴威胁和业务需求更新策略。
  • 工具评估: 定期评估新的 SCA 工具和功能。

软件组合分析为管理依赖于开源组件的现代应用程序中的安全和合规性风险提供了自动化功能。 下一单元探讨如何实现集成到 GitHub 中的特定 SCA 工具 GitHub Dependabot。