了解公司对开放源代码软件组件的担忧

  • 8 分钟

新式软件开发从根本上取决于开源组件。 此依赖项对构建软件的组织（无论是商业销售、内部使用还是公共服务）带来了重大关注。 虽然开源提供了巨大的优势，但组织必须了解和管理相关的风险。

根本挑战

采用开源软件时，组织面临 关键的平衡行为 ：

开发人员需求： 开发人员希望自由使用开源组件，以实现更快的开发、新式框架、经过验证的库和当代开发实践。 限制开源使用可降低工作效率，使开发人员感到沮丧，并使得招聘才华横溢的工程师更加困难。

组织风险： 不受限制的开源采用可能会使组织面临安全漏洞、法律责任、作中断和合规性违规。 公司必须保护知识产权，维护安全，确保运营稳定，并履行法律义务。

解决方案： 成功的组织在 管理风险时找到增强开发人员能力的方法，从而在治理框架中启用开源使用，以识别和缓解潜在问题。

安全问题

安全风险代表了对开源软件最直接和最严重的担忧：

已知安全漏洞

开源组件经常包含安全漏洞：

  • 流行： 安全研究人员每年在开源组件中发现数千个新漏洞。 国家漏洞数据库（NVD）使用 CVE 标识符对漏洞进行目录。
  • 严重性范围： 漏洞的严重性可以从低影响问题到导致远程代码执行、数据被盗或完全系统攻陷的关键缺陷。
  • 披露计时： 在发现之前，漏洞通常存在多年。 在应用更新之前，使用受影响版本的应用程序仍然易受攻击。
  • 可传递依赖项： 漏洞可能不存在于直接使用的包中，而是存在于其依赖项中，从而使检测更具挑战性。

示例影响： 流行的 Java 日志记录库 Log4j 中的 Log4Shell 漏洞（CVE-2021-44228）影响了全球数百万个应用程序。 组织争先恐后地使用 Log4j 识别所有应用程序并部署修补程序，演示单个开源漏洞如何产生巨大的连锁反应。

恶意代码注入

供应链攻击面向开源软件：

  • 包劫持： 攻击者可以控制常用的包维护者帐户，并推送恶意更新，这些更新会窃取凭据、安装后门或挖掘加密货币。
  • 拼写错误： 具有类似于常用包的名称的恶意包会欺骗开发人员安装泄露的代码（例如“python-dateutil”与“python-datutil”）。
  • 依赖项混淆： 攻击者将恶意软件包发布到公共注册表，这些包的名称与内部私有包相匹配，从而利用包管理器的解析行为。
  • 维护者泄露： 攻击者通过网络钓鱼、凭据盗窃或社交工程入侵维护者帐户，将恶意代码注入受信任的包。

示例事件： npm 中的事件流包被泄露，以窃取加密货币钱包凭据。 Colors.js 和 Faker.js 的维护者故意添加无限循环，以抗议公司在没有财务支持的情况下使用，导致数千个应用程序无法正常运行。

无人维护和被放弃的项目

许多开源项目缺乏主动维护：

  • 项目放弃： 维护者失去兴趣、更改工作或缺乏时间来继续维护项目。 即使发现漏洞，废弃的项目也不会收到安全更新。
  • 单个维护者风险： 许多关键的开源项目依赖于单个个人。 如果这个人无法履职，项目可能会在一夜之间变得无人维护。
  • 资金挑战： 许多维护人员自愿工作。 如果没有资金，维持大型项目就变得不可持续，导致最终放弃。
  • 维护滞后时间： 即使活动项目对安全问题的响应时间可能很慢，在等待修补程序时应用程序也容易受到攻击。

组织影响： 依赖于未托管包的组织必须切换到替代项（需要重大重构）、分支和维护包本身（增加维护负担），或者继续使用易受攻击的代码（接受安全风险）。

质量和可靠性问题

除了安全性之外，代码质量还会影响应用程序可靠性和可维护性：

可变代码质量

开源组件的质量差异很大：

  • 缺少质量标准： 开放源代码项目没有强制性的质量要求。 代码质量完全取决于维护人员技能、做法和优先级。
  • 有限的测试： 较小的项目可能具有最小的自动测试、边缘案例覆盖率不足或没有持续集成，从而增加了 bug 的可能性。
  • 文档差距： 文档不足使得组件难以正确使用，增加了集成错误和滥用的风险。
  • 性能问题： 组件可能无法针对性能、可伸缩性或资源效率进行优化，从而影响应用程序性能。

低质量组件影响：

  • 可维护性： 代码结构不佳使得调试和自定义变得困难。
  • 可靠性：测试不足会产生导致应用程序故障的 bug。
  • 性能： 低效的实现会影响应用程序响应时间和资源使用情况。

兼容性和稳定性

开源组件并不总是优先向后兼容性：

  • 中断性更改：主要版本更新经常会引入中断性变更，需要修改应用程序。
  • API 不稳定： 随着设计成熟，较年轻的项目可能会经常更改界面。
  • 依赖项冲突： 组件可能需要与其他组件冲突的特定依赖项版本。
  • 平台兼容性： 并非所有组件都适用于所有平台、浏览器或环境。

开源许可证创建组织必须遵守的法律义务：

许可证合规义务

每个开放源代码许可证都施加了要求：

  • Copyleft 要求： 某些许可证（如 GPL）要求派生作品使用相同的许可证，从而可能强制组织使用开源专有代码。
  • 归属要求： 大多数许可证都需要维护版权声明和许可证文本，这些文本必须出现在分布式软件中。
  • 源代码泄露： 某些许可证需要向接收二进制文件的任何人提供源代码。
  • 专利授予： 某些许可证包括与组织专利策略交互的专利授予或终止条款。

合规性失败可能会导致：

  • 法律诉讼： 版权持有人可以起诉违反许可证的行为，寻求损害赔偿和禁令。
  • 信誉损害： 许可证违规行为成为公开的，损害了开发人员社区的组织声誉。
  • 分发限制： 解决违规可能需要停止产品分发，直到达到合规性为止。
  • 强制开放源： 在极端情况下，组织可能需要使用违反 copyleft 许可证的开源专有代码。

许可证激增和兼容性

新式应用程序包含数百个具有不同许可证的组件：

  • 许可证清单： 组织必须跟踪哪些许可证适用于其应用程序中的每个依赖项。
  • 兼容性分析： 某些许可证不兼容 - GPL 下的软件不能与其他许可证下的软件组合在一起。
  • 许可条款解释： 法律团队必须解释许可条款并确定特定用例的义务。
  • 更改许可证： 项目维护人员有时会在版本之间更改许可证，这需要重新评估合规性。

挑战的规模： 企业应用程序可能可传递地依赖于 500-1,000 个开放源代码包，其中包含 20-40 个不同的许可证。 手动跟踪符合性是不切实际的，需要自动化工具和流程。

运营问题

除了安全和法律风险之外，开源还引入了作挑战：

依赖于外部基础结构

开源生态系统依赖于公共基础结构：

  • 注册表可用性： 应用程序从公共包注册表（npm、PyPI、NuGet）中提取依赖项。 注册表中断会阻止生成和部署。
  • 包删除： 作者可以取消发布包，破坏依赖于它们的应用程序。 “left-pad”事件揭示了这种风险：当删除一个只有 11 行的小包时，数千个 JavaScript 应用程序因此被中断。
  • 地理访问： 某些组织在受限访问公共包注册表的区域运行。
  • 网络可靠性： 网络连接缓慢或不可靠会影响生成时间，并可能导致生成失败。

缓解策略包括：

  • 专用注册表：在组织控制下的专用注册表中的镜像公共包。
  • 供应商包： 在源代码管理中包含依赖项，以在生成过程中消除外部依赖项。
  • 缓存： 缓存包以减少重复下载并提高生成可靠性。

更新管理负担

保持最新依赖项需要持续努力：

  • 持续更新： 新包版本会不断发布。 组织必须评估更新、测试兼容性和部署更改。
  • 安全紧迫性： 严重安全漏洞需要立即更新，可能会中断计划内的工作。
  • 中断性变更：主要更新可能需要更改代码，从而增加维护负担。
  • 测试要求： 每个依赖项更新都需要回归测试，以确保没有任何中断。

没有系统更新过程：

  • 依赖项偏移： 应用程序落后于当前版本，累积了技术债务。
  • 安全风险： 未修补的漏洞仍可被利用。
  • 更新雪崩：延迟更新会造成大量更新积压，导致更新的应用变得越来越困难且风险越来越大。

平衡自由和控制

组织必须制定在开发人员授权与风险管理之间平衡的策略：

治理方法

成功的组织实现平衡治理：

预审批流程：

  • 包评估： 安全和法律团队在首次使用之前查看包，评估安全历史记录、许可证兼容性和质量。
  • 已批准的包列表： 维护开发人员可以自由使用的预批准的包的特选列表。
  • 异常进程： 允许开发人员请求审批未在批准列表上的包，并由相应的团队进行评估。

自动扫描：

  • 漏洞扫描： 自动扫描依赖项是否存在已知漏洞，立即向开发人员发出警报。
  • 许可证检测： 确定所有依赖项的许可证，并标记不兼容或与许可证相关的许可证。
  • 质量指标： 使用自动化代码分析来评估依赖项质量。

开发人员教育：

  • 安全意识： 训练开发人员在选择依赖项时考虑安全性。
  • 许可证理解： 帮助开发人员了解不同用例的许可证影响。
  • 最佳做法： 共享用于评估开源组件的准则。

持续监视：

  • 新漏洞： 监视现有依赖项中新披露的漏洞。
  • 许可证更改： 跟踪项目何时更改许可证。
  • 维护状态： 确定依赖项何时未得到维护。

发布开放源代码的组织的担忧

发布自己的开源软件的组织面临其他挑战：

业务模型注意事项

通过开源软件盈利需要谨慎的策略：

  • 开放核心模型： 在销售专有扩展或企业功能时，以开源的形式提供基本功能。
  • 支持和服务： 免费提供开源软件，但销售支持合同、咨询或培训。
  • 托管服务： 开源软件，但销售托管服务。
  • 双重许可： 为开源项目提供开放源代码许可证下的软件，并为专有软件提供商业许可证。

贡献管理

已发布的开源项目接收外部贡献：

  • 贡献评审： 组织必须审查社区对质量、安全性和与项目方向的一致贡献。
  • 参与者许可： 建立确保参与者为其贡献授予必要权利的过程。
  • 维护者资源： 响应问题、查看拉取请求和管理社区需要专用资源。
  • 方向冲突： 社区的愿望可能与组织优先事项冲突，需要外交来管理。

封闭的开源方法： 某些组织公开发布代码，但限制谁可以进行更改。 社区成员可以通过问题或拉取请求来建议更改，但只有组织维护人员可以提交更改。 这提供了透明度，同时保持对代码质量和方向的控制。

知识产权保护

组织必须仔细考虑开源内容：

  • 竞争优势： 避免提供竞争差异的开源代码。
  • 安全问题： 不要发布公开安全机制或漏洞的代码。
  • 计时决策： 有时，最初保留代码专有并开放源代码具有战略优势。
  • 专利注意事项： 确保开放源代码许可证包括适当的专利授予或保护。

了解这些公司问题对于有效地实现开源软件至关重要。 接下来的单元详细介绍开放源代码许可证，帮助你了解不同许可证创建的法律义务，以及如何评估组织对许可证的影响。