Endor Labs Station 9 研究团队与来自 Adobe、HashiCorp、Discord 和 Palo Alto Networks 等公司的 20 多位 CISO 和 CTO 合作，总结了因依赖开源软件而引入的 10 大安全和运营风险。
“尽管软件供应链严重依赖 OSS，但该行业缺乏一致的方式来理解和衡量 OSS 的风险。OSS 中的风险管理从许可证管理开始，然后演变为 CVE，但我们仍然缺乏包含安全、法律和应用程序弹性的整体 OSS 风险管理方法。”
![]()
十大 OSS 风险具体包括：
| 风险 |
描述 |
类别 |
| OSS-RISK-1 已知漏洞 |
组件版本可能包含易受攻击的代码，由其开发人员意外引入。漏洞详细信息已公开，例如通过 CVE。漏洞和补丁可能可用也可能不可用。 |
Security |
| OSS-RISK-2 合法包的妥协 |
攻击者可能会破坏作为现有合法项目或分销基础架构的一部分的资源，以便将恶意代码注入组件，例如，通过劫持合法项目维护者的帐户或利用包存储库中的漏洞。 |
Security |
| OSS-RISK-3 名称混淆攻击 |
攻击者可能会创建名称类似于合法开源或系统组件名称的组件（brand-jacking），暗示为 trustworthy authors（品牌劫持）或使用不同语言或生态系统中的通用命名模式（combo-squatting）。 |
Security |
| OSS-RISK-4 未维护的软件 |
组件或组件版本可能不再积极开发，因此，原始开源项目可能不会及时（或根本不）提供功能性和非功能性错误的补丁 |
Ops |
| OSS-RISK-5 过时的软件 |
一个项目可能会使用旧的、过时的组件版本（尽管存在更新的版本）。 |
Ops |
| OSS-RISK-6 未跟踪的依赖项 |
项目开发人员可能根本不知道对组件的依赖性，例如，因为它不是上游组件的 SBOM 的一部分，因为 SCA 工具未运行或未检测到它，或者因为没有使用包管理器建立依赖。 |
Security, Ops |
| OSS-RISK-7 许可证风险 |
一个组件或项目可能根本没有许可证，或者与预期用途不兼容，或其要求没有或无法满足。 |
Ops |
| OSS-RISK-8 不成熟的软件 |
开源项目可能不应用开发最佳实践，例如，不使用标准版本控制方案，没有回归测试套件、审查指南或文档。因此，组件可能无法可靠或安全地工作。 |
Ops |
| OSS-RISK-9 未经批准的变更（可变） |
组件可能会在开发人员无法注意到、审查或批准此类更改的情况下发生更改，例如，因为下载链接指向未版本化的资源，由于版本化资源已被修改或篡改，或由于不安全的数据传输。 |
Security, Ops |
| OSS-RISK-10 依赖不足/过大 |
一个组件可能提供很少的功能（例如 npm micro packages）或很多功能（可能只使用其中的一小部分）。 |
Security, Ops |
Endor Labs Station 9 的首席安全研究员 Henrik Plate 称，包括 Log4Shell、Heartbleed、Shellshock 在内一些高影响漏洞以及恶意软件组件的扩散正在显着改变组织对开源的看法。“众所周知，开源软件通常比专有软件性能更高、更安全。但也很明显，开源软件是 comes as-is，没有任何形式的保证，使用它的任何风险都由下游用户承担。这正是业界应该意识到这些风险的原因。”
不过 Plate 也声明，该报告无意批评开源项目；目标是帮助专业人员查明上游组件最严重的安全和操作风险，并部署最佳补救策略。该组织表示将定期更新这份 Top 10 榜单，并提供了一些减轻风险的措施：
- 定期扫描代码以发现
- 检查一个项目是否遵循开发的最佳实践
- 使依赖项保持最新并在使用前检查代码特征
- 评估和比较软件构成分析工具
- 使用符合开源许可条款的组件
详情可查看完整报告。
延伸阅读：
