软件供应链安全的部分理解

文/程度

摘要

自从Solarwinds的供应链攻击事件，以及Log4j的漏洞对全行业安全造成影响，以及最近的SSH依赖库投毒攻击事件，软件供应链攻击开始被我们认识到。软件供应链安全事件最近几年也层出不穷，有APT攻击行为，也有开发者恶意行为，也有无意行为等。随着软件在数字化转型中的重要性日益提升，以及从供应链安全衍生出的软件供应链安全已成为信息安全领域的关键问题。本文将深入解读软件供应链安全的主要框架，分析核心问题，并基于当前市场格局探讨主流厂商的解决方案。通过全面剖析软件供应链安全的各个方面，为行业提供构建更安全、可靠的软件供应链安全的部分理解。

1. 软件供应链安全的问题现状

根据2023年Sonatype的软件供应链安全报告，可以看出开源项目虽然增速变慢，但是总体下载数量还在增长，已经超过了每年4万亿的下载次数。

图1 不同语言的开源项目的增长率

图2 所有开源项目每年的下载次数

1. 开源组件使用广泛但存在安全风险:

• 超过96%的已知漏洞下载有可用的修复版本,但开发者并未应用修复。

• 12%的Maven Central下载包含至少一个已知安全漏洞。

• 37%的漏洞组件下载是严重级别的。

图3 从Maven Central下载的有漏洞的Java组件统计

2. 恶意软件包攻击激增:

• 2023年发现245,000个恶意软件包,是之前几年总和的两倍。

• 恶意软件包成为软件供应链攻击的主要途径之一。

图4 每年发现的有威胁的软件包

3. 开源项目维护状况不佳:

• 8.6%的Java和JavaScript开源项目在2022年得到维护,但现在不再维护。

• 85%的Maven Central项目处于不活跃状态。

• 仅28%的组织能在漏洞披露后一天内意识到新的开源漏洞。

• 39%的组织需要超过一周时间来修复漏洞。

图5 开源漏洞修复周期

软件供应链安全面临着多方面的挑战，主要包括：

1.开源组件管理：

• 依赖复杂性：现代软件往往依赖大量开源组件，形成复杂的依赖树。

• 漏洞传播：一个底层组件的漏洞可能影响整个依赖链。

• 许可合规：需要确保所有使用的开源组件符合许可要求。

2. CI/CD管道安全：

• 配置错误：不安全的CI/CD配置可能导致未经授权的代码被引入。

• 凭证泄露：构建过程中的凭证管理不当可能导致敏感信息泄露。

• 供应链攻击：攻击者可能通过污染构建过程来植入恶意代码。

3. 制品完整性：

• 篡改检测：确保软件制品在分发和部署过程中未被篡改。

• 签名验证：使用加密签名来验证制品的来源和完整性。

• 来源追溯：能够追溯每个软件组件的来源和变更历史。

4. 漏洞管理：

• 检测及时性：快速识别新发现的漏洞对使用的组件的影响。

• 修复优先级：在大量漏洞中确定哪些需要优先修复。

• 影响评估：准确评估漏洞对整个应用程序的实际影响。

5. 合规性挑战：

• SBOM生成：生成和维护准确的软件材料清单(SBOM)。

• 监管要求适配：满足不断的法规要求（如美国政府的行政命令）。

• 跨境数据流动：在全球化软件开发中处理不同地区的数据保护要求。

2. 软件供应链安全框架解读

2.1 NIST安全软件开发框架 (SSDF, SP 800-218)

NIST安全软件开发框架(SSDF)是一套全面的指南，旨在帮助组织将安全实践整合到软件开发生命周期中。该框架围绕四大核心功能展开：

1. 准备组织(PO): 确保组织的人员、流程和技术准备就绪，能够执行安全的软件开发。

• PO.1 定义安全要求

• PO.2 实施角色和职责

• PO.3 实施支持性工具链

2. 保护软件(PS): 保护所有软件组件免受篡改和未经授权的访问。

• PS.1 保护所有形式的代码

• PS.2 提供软件发布完整性验证机制

• PS.3 归档和保护每个软件版本

3. 生产优质软件(PW): 生产具有最少安全漏洞的优质软件。

• PW.1 设计符合安全要求的软件

• PW.2 审查设计以验证符合安全要求

• PW.3 验证第三方软件符合安全要求

• PW.4 重用经过验证的安全软件

• PW.5 创建安全的源代码

• PW.6 配置编译、解释器和构建过程

• PW.7 审查和/或分析人类可读代码

• PW.8 测试可执行代码

• PW.9 配置软件以具有安全设置

4. 应对漏洞(RV): 识别剩余的漏洞并采取适当的响应措施。

• RV.1 识别和确认漏洞

• RV.2 评估、优先处理和修复漏洞

• RV.3 分析漏洞以识别根本原因

SSDF的一个关键优势是其灵活性和适应性。它不规定具体的实施方法，而是关注预期的安全成果，使得不同规模和类型的组织都能根据自身情况来应用这些实践。NIST 800-218框架基本沿用NIST 800-53以及CSF的框架的语境扩展，可以作为相对宏观的一种指导框架。同时也可以参照NIST 800-161进行比较。

总的来说，NIST 800-161和NIST 800-218虽然关注点不同，但它们在供应链安全和软件开发安全方面相互补充。组织可以结合使用这两个标准来建立更全面、更强大的安全策略。例如，可以使用800-161来管理整体供应链风险，同时使用800-218来确保供应链中的软件开发过程符合安全标准。

在实践中，这种结合使用像这样：组织使用800-161来评估和管理其ICT供应链风险，包括识别关键供应商和评估其安全实践。然后，对于涉及软件开发的供应商，组织可以使用800-218中的指南来评估和改进这些供应商的软件开发安全实践。这种方法可以帮助组织在整个供应链中建立一个连贯的安全框架，从而更好地管理风险和提高整体安全性。

图6 软件供应链和传统供应链的对照关系图

2.2 CNCF软件供应链安全最佳实践 (SSCP)

CNCF的软件供应链安全最佳实践(SSCP)提供了一个更加针对云原生环境的框架。它将软件供应链安全分为五个主要阶段，并且每个阶段也分为四个部分，验证（Verification）、自动化（Automation）、环境授权（Authorization）和认证（Authentication）。

1. 源代码安全：

• 要求签名提交：所有代码提交都应该经过数字签名，以确保其来源和完整性。

• 使用分支保护规则：实施严格的分支保护策略，限制直接推送到主分支的权限。

• 防止将认证信息提交到代码库：使用自动化工具检测和阻止敏感信息（如密钥、密码）被提交到代码库。

• 定义贡献政策和角色：明确规定谁可以贡献代码，以及贡献的流程和标准。

• 实施代码审查：要求所有代码更改在合并前经过同行审查。

• 使用静态代码分析工具：自动检测潜在的安全漏洞和编码问题。

2. 物料安全：

• 验证第三方工件和开源库：对所有外部依赖项进行安全性和完整性检查。

• 跟踪开源组件之间的依赖关系：维护一个详细的依赖关系图，以便于识别潜在的风险。

• 扫描软件漏洞：定期扫描所有依赖项，检查已知的安全漏洞。

• 许可证合规性检查：确保所有使用的开源组件符合许可证要求。

• 维护软件物料清单（SBOM）：创建并维护一个详细的组件清单，包括所有直接和间接依赖项。

• 实施漏洞管理流程：制定明确的流程来处理发现的漏洞，包括评估、修复和通知。

3. 构建安全：

• 自动化构建和CI/CD步骤：尽可能自动化构建过程，减少人为错误。

• 标准化项目间的管道：在所有项目中使用一致的构建和部署流程。

• 部署安全的编排平台：使用安全配置的容器编排平台（如Kubernetes）来管理构建环境。

• 隔离每个构建步骤的职责：确保每个构建步骤只能访问它所需要的资源。

• 实施最小权限原则：为每个构建步骤和工具分配最小必要的权限。

• 加密敏感数据：确保在构建过程中使用的所有敏感信息（如凭证）都经过加密。

• 记录和审计构建过程：保留详细的构建日志，并定期审计以检测异常。

构建安全是基于前两步的安全机制下，进行的更近一步的安全保证。前提是保证了相关的源代码和依赖库的安全前提下进行的构建安全规划。

图7 应用软件依赖样例图

4. 制品安全：

• 签名构建过程的每个步骤：为构建过程中的每个重要步骤生成数字签名。

• 验证每个步骤生成的签名：在后续步骤中验证先前步骤的签名，确保完整性。

• 使用TUF/Notary管理工件签名：采用The Update Framework (TUF) 或 Notary 等工具来管理和验证工件签名。

• 实施不可变的工件版本控制：一旦工件被创建和签名，就不应该被修改。

• 安全存储工件：使用安全的存储系统来保存构建工件，限制访问权限。

• 实施工件扫描：在发布前对工件进行安全扫描，检查潜在的漏洞或恶意代码。

5. 部署安全：

• 确保客户端可以验证工件和元数据：提供机制让最终用户验证下载的软件的完整性和真实性。

• 确保客户端可以验证文件的"新鲜度"：实施机制确保用户能够检查他们是否拥有最新版本的软件。

• 使用The Update Framework (TUF)：采用TUF来提供安全的软件更新机制。

• 实施安全的配置管理：确保部署环境的配置是安全的，并且经过版本控制。

• 自动化部署过程：使用自动化工具进行部署，减少人为错误和安全风险。

• 实施蓝绿部署或金丝雀发布：使用这些技术来逐步推出更新，便于快速回滚。

• 监控和日志记录：持续监控部署环境，并保留详细的日志以便于审计和问题排查。

SSCP与NIST SSDF相比，更加聚焦于云原生环境和DevOps实践，为现代软件开发提供了更具操作性的指导。SSCP的核心理念是将安全考虑融入软件开发和部署的每个阶段，从源代码管理到最终部署。它强调了自动化、最小权限原则、持续监控和改进的重要性。通过实施这些实践，组织可以显著提高其软件供应链的安全性，减少安全漏洞和潜在的供应链攻击风险。

2.3 其他相关框架

• SLSA (Supply chain Levels for Software Artifacts)：Google提出的框架，定义了四个递进的安全级别，帮助组织逐步提高其软件供应链安全性。

• OpenSSF Scorecard：自动化工具，用于评估开源项目的安全实践，涵盖了代码审查、依赖管理等多个方面。

• BSA安全软件框架：侧重于软件开发生命周期的安全实践，包括安全设计、安全编码、测试和验证等方面。

这些框架各有侧重，但都致力于提高软件供应链的整体安全性。组织可以根据自身需求和能力，选择合适的框架或综合多个框架的优点来指导实践。

3. 软件供应链安全产品技术分析

图8 软件供应链安全厂商全景图

3.1 源代码安全

1. 平台解决方案：

• GitHub Advanced Security：

• 提供代码扫描、秘密扫描和依赖审查等功能。

• 与GitHub的开发工作流深度集成，提供无缝的安全体验。

• GitLab安全功能：

• 包括SAST、DAST、容器扫描和依赖扫描等多种安全工具。

• 支持自动化安全测试和漏洞管理。

2. 新兴厂商：

• Arnica：

• 使用行为分析来识别潜在的安全风险。

• 提供实时代码扫描，即时发现并通知开发者安全问题。

• 自动化权限管理，基于历史访问模式动态调整权限。

• Jit.io：

• 开源安全编排平台，支持集成多种安全工具。

• 提供预定义的安全计划，帮助团队达成特定的安全目标。

• 支持多种合规框架，如AWS FTR和OWASP Top 10。

3.2 构建与流水线安全

1. 软件成分分析(SCA)：

• Snyk：

• 拥有自己的漏洞数据库，支持多种编程语言和包管理器。

• 提供自动修复PR功能，简化漏洞修复过程。

• 支持许可合规检查和SBOM生成。

• Semgrep Supply Chain：

• 使用可达性分析来减少误报，聚焦于实际可利用的漏洞。

• 提供依赖搜索功能，方便快速定位特定依赖的使用情况。

• 支持SBOM导出，便于合规管理。

• Endor Labs：

• 使用程序分析技术进行深度依赖分析。

• 提供多维度的风险评估，包括漏洞可利用性、修复可用性等。

• 支持生成带有VEX信息的SBOM，提供更丰富的漏洞上下文。

2. 恶意依赖检测：

• Socket：

• 提供实时依赖检测，快速识别潜在的恶意包。

• 对依赖进行风险评估，包括行为分析和能力评估。

• 与GitHub深度集成，直接在PR中提供依赖安全反馈。

• Phylum：

• 利用大数据和机器学习技术分析开源包的安全性。

• 提供开源沙箱(Birdcage)，限制包的网络和磁盘访问。

• 持续监控主要开源生态系统，提供全面的威胁情报。

• Datadog GuardDog：

• 开源解决方案，使用Semgrep进行静态分析。

• 支持Python和npm包的扫描。

• 可集成到CI/CD流程中，自动扫描新引入的依赖。

3. CI/CD安全：

• OX Security：

• 引入PBOM(Pipeline Bill of Materials)概念，提供软件开发全生命周期的可见性。

• 提供工作流自动化和安全姿态管理，确保CI/CD流程的安全。

• 基于OSC&R框架构建，提供全面的供应链威胁防护。

• Cycode：

• 使用eBPF技术检测构建过程中的攻击。

• 提供构建强化功能，防止恶意依赖和篡改。

• 包括代码泄露检测功能，降低源代码泄露的风险。

• Tromzo：

• 提供产品安全运营平台(PSOP)，整合软件资产清单和CI/CD管道可见性。

• 提供CI/CD姿态管理，确保构建服务器和仓库的安全配置。

• 使用专有的Intelligence Graph来识别关键软件资产和高风险漏洞。

3.3 制品安全与部署

1. 容器安全：

• Chainguard：

• 提供安全优先的容器基础镜像，减少攻击面。

• 支持在构建过程中生成SBOM。

• 提供持续验证功能，确保部署后的容器仍符合安全要求。

• Aqua：

• 提供全面的容器安全解决方案，包括镜像扫描和运行时保护。

• 支持对各种容器环境的动态分析，包括VM和无服务器容器。

• 与多种容器注册表和Kubernetes平台集成。

• Rapidfort：

• 引入RBOM(Real Bill of Materials)概念，通过容器优化减少漏洞警报。

• 自动优化容器，只包含必要的组件。

• 提供优化后的详细分析，说明移除了哪些文件、包和漏洞。

2. SBOM与代码来源：

• Chainguard Enforce：

• 提供基于SLSA和NIST框架的策略管理。

• 支持合规自动化，自动生成SBOM。

• 提供生产环境洞察，实时查看部署状态。

• Legit Security：

• 提供ASPM(应用程序安全姿态管理)工具，实现从代码到云的可追溯性。

• 支持多种SBOM格式，如CycloneDX。

• 提供SBOM聚合和差异分析功能。

• Apiiro：

• 引入XBOM(Extended Bill of Materials)概念，提供更全面的软件组件视图。

• 使用风险图谱来检测开源解决方案中的恶意包。

• 提供开发者行为分析，识别潜在的内部威胁。

结论

软件供应链安全是一个多维度、全生命周期的挑战。通过对主流框架的深入理解、核心问题的准确把握，以及对市场解决方案的分析，我们可以得出以下几点结论：

1. 综合框架应用：没有一个单一的框架能够解决所有软件供应链安全问题。组织需要根据自身情况，综合运用NIST SSDF、CNCF SSCP等框架，建立适合自己的安全实践。

2. 全面风险管理：软件供应链安全不仅仅是技术问题，还涉及流程、人员和治理等多个方面。组织需要采取全面的风险管理方法，从源代码到部署的每个环节都要考虑安全因素。

3. 自动化和持续性：鉴于现代软件开发的快速迭代特性，安全措施必须是自动化和持续的。这包括自动化的漏洞扫描、依赖分析、SBOM生成等。

4. 生态系统协作：软件供应链安全是一个共同责任。开源社区、商业供应商、安全研究人员和最终用户需要加强合作，共同提高整个生态系统的安全性。

5. 平衡安全与效率：虽然安全至关重要，但不应成为创新和效率的阻碍。优秀的软件供应链安全解决方案应该能够无缝集成到开发流程中，最小化对开发者工作的干扰。

6. 重视新兴技术：人工智能、机器学习等新兴技术正在改变软件开发和安全领域。组织应该密切关注这些技术的发展，并探索如何利用它们来增强供应链安全。

7. 合规性驱动：随着各国政府和行业组织对软件供应链安全的关注度提高，合规要求将成为推动组织采取行动的重要因素。然而，合规不应该是终点，而应该是持续改进的起点。

未来，随着软件在社会各个领域的深入应用，软件供应链安全的重要性将继续提升。我们可以预见，更多创新的解决方案将会涌现，帮助组织应对这一复杂的挑战。同时，行业标准和最佳实践将进一步成熟，为组织提供更清晰的指导。

声明：本文来自安全喷子，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。