当今Software 中的七大薄弱环节

一个关键点在于区分SBOM（Software ）与SCA（Software 分析）。SBOM相当于组件清单或目录，而SCA则评估这些组件是否存在漏洞、过时或风险。二者结合能为组织提供必要洞察，助力其做出明智决策、更快响应安全问题，并强化整体风险管理。

现代发展的迅猛速度，加之对第三方和开源代码的高度依赖，已催生出严重的漏洞。威胁行为者正利用七大主要薄弱环节：

当开发者优先考虑速度时，他们往往会直接使用大型开源库而不进行全面代码审查。单个组件可能引入额外的传递依赖。若仅监控顶层代码，就可能遗漏被注入到这些隐藏传递依赖中的恶意代码。

这种模式在开源生态系统中屡见不鲜。一个被入侵的软件包可能通过依赖链层层扩散，在无人察觉的情况下被下载数百万次。近期涉及加密恶意软件的npm供应链攻击事件，就生动展现了这种情况在现实中的发生过程。

最佳做法：

• 扫描所有开源软件包及其完整的依赖链，在漏洞、过时组件或隐藏的恶意软件进入您的代码库之前将其识别出来。
• 持续监控随时间变化的依赖项，因为安全组件可能因新出现的CVE漏洞或恶意更新而变得存在风险。
• 使用可信的软件源并验证软件包完整性，以确保您下载的软件包未被篡改。
• 实施策略以标记或阻止高风险许可证，确保不兼容或病毒式许可证条款不会混入您的构建中。
• 延迟使用新发布的软件包，直至其经过审核，以降低将未经审查或恶意版本引入环境的风险。

许可问题如今对工程领域的影响已不亚于法律领域。病毒式许可协议（如GPL）可能强制要求最终应用程序采用相同许可协议发布，这可能导致企业丧失自身知识产权（IP）。由于许可条款可能随时变更——即便是早期合规版本亦然——因此必须实施持续监控。

最佳做法：

• 使用自动许可证检测工具，在开发初期就标记高风险或不兼容的许可证。关于其重要性的深入解释详见此文：《许可证检测在开源安全中的关键作用》。
• 持续追踪许可证变更，及时发现可能影响合规性或知识产权暴露的变动。
• 在组件进入代码库之前，对其进行审查或阻止那些采用限制性或病毒式许可的组件。
• 保持所有在用许可证的清晰清单，以简化审计和风险评估流程。

尽管法规要求共享软件物料清单（SBOM），但仅提供高层次清单远远不够。要实现有效的风险缓解与预防，必须包含详细数据点，包括作者、贡献者、发布频率及维护状态等信息。

最佳做法：

• 通过重新扫描组件来增强SBOM报告，使其包含更新的许可证数据、漏洞状态及其他关键元数据。具体操作示例详见CycloneDX SBOM报告验证与增强部分。
• 使用自动化工具验证并丰富软件物料清单（SBOM），确保信息完整、准确且可操作。
• 要求供应商提供完整的软件物料清单深度，包括传递性依赖项及所有相关元数据。
• 随着组件演变或新漏洞出现，持续更新并监控软件物料清单（SBOM）库存。

您所依赖的每个供应商都将成为供应链的一部分。若其交付过时或存在安全隐患的组件，您将直接承担相应风险。完整的软件物料清单（SBOM）——包括传递性依赖项——能让您快速掌握风险敞口，而非在安全事件发生后才匆忙追查供应商。近期发布的《Supply Chain依赖项漏洞》一文，深入探讨了团队如何强化这一环节的管控能力。

由于人工智能的快速普及，团队常绕过常规限制，这已成为主要攻击途径。攻击者将恶意代码植入机器学习模型、PICO文件或开源库中。在Pytorch等环境中，用户可能误拉取错误库，这种"拼写劫持"行为十分常见——此类库会传播恶意软件，最终在工程师设备上实现完整的远程代码执行。

容器扫描必须超越仅关注漏洞的局限。现代安全防护还需检测恶意软件、加密货币挖矿程序以及公开容器镜像中发布的快速传播威胁。近期对 Container -2024-0Container 的分析表明，此类问题极易被忽视。