5.2 开源软件和专有代码

在软件领域，代码主要分为两类——开源软件（OSS）和专有软件——这使得讨论软件供应链中的透明性变得复杂。OSS 与任何人都可以查看、使用和贡献 OSS 代码有明显不同。尽管存在一些所谓的“源代码可用”的专有软件（即源代码可以查看甚至修改，但不被认为是开源），专有代码通常不对外开放查看、使用或贡献，通常由开发各种业务软件的内部或外部的软件和技术供应商或组织控制。这种允许任何人使用 OSS 代码的能力也包括专有软件生产商，他们经常这样做。据估计，97％的软件至少包含一些 OSS 代码（www.synopsys.com/content/dam/synopsys/sig-assets/reports/rep-ossra-2022.pdf）。不仅几乎所有代码库中都包含 OSS，而且它通常可以占到代码库的近 80％。

在软件讨论中，“数字公地”一词经常被使用，它是“公地”的一个子集。公地被认为是帮助治理资源生产和集体行动的社会机构（https://policyreview.info/concepts/digital-commons）。在这种情况下，数字公地是公地的一个子集，涉及数据和信息的资源，以及数字领域中的文化和知识。当软件开发人员应用现有 OSS 许可证时，代码通常成为 OSS，这些许可证授予其他用户某些权利，这些权利通常是法律排他性授予的，例如编辑和重新分发代码的能力。一旦发生这种情况，任何获得项目数字访问权限的人都可以复制、使用、更改并提出对项目和代码的贡献。

软件产品通常与几种类型的软件许可证相关联，这些许可证通过条款、支持协议、限制和费用帮助管理其使用。软件许可证不仅定义了软件分发和使用的规则，还通常列出了最终用户在安装、保修和责任等方面的权利。在讨论 OSS 和专有软件时，OSS 软件许可证通常授予用户修改和重用源代码的能力，以及实际访问源代码本身的权限。专有软件许可证则通常不提供修改和重用代码的能力，当然也不提供对源代码的直接访问。有些情况下，软件不受许可证覆盖，被认为是公共领域软件或私人无许可证软件，如某些仍可能需要版权保护的商业应用。不遵守软件许可要求可能会产生后果，如允许版权持有人起诉或甚至使侵权者面临禁令。

常见的软件许可类型包括以下几种：

宽松许可 这些许可证对软件的修改或分发方式限制最少，但可能需要在后续分发中注明版权信息。常见示例包括 Apache、BSD 和 MIT 许可证。
弱 Copyleft  通常称为 GNU 较宽松通用公共许可证（GNU Lesser General Public License）（www.gnu.org/licenses/lgpl-3.0.en.html），它允许以最小义务链接到开源软件库，并且整个作品将在后续许可类型下分发，即使是专有许可证，要求最少。
公共领域许可证  每个人都可以自由使用和修改软件，无任何限制；这种许可证类型并不常见。
Copyleft  许可证也称为互惠许可证，在商业上可能比其他一些许可证类型更具限制性。Copyleft 允许开发人员修改许可证代码并将其纳入其他项目，甚至修改专有代码并分发，但必须在同一许可证下完成。原始软件和修改内容包含在新项目中，这使得此许可证对有商业利益的开发人员不太有吸引力。
商业/专有  这些许可证类型用于限制复制、修改和分发代码的能力。被认为是最严格的软件许可证类型之一，商业/专有许可证防止未经授权的使用软件，并且对商业利益最具保护作用。

  除了许可方面的考虑，开源软件的使用非常普遍，如前所述，在专有软件和产品中也很常见。这是由于各种原因，例如节省开发时间、利用现有工作、降低成本并加快上市时间。使用开源软件代码可以使开发人员和团队专注于更多增值活动，如开发自定义代码或功能，专注于使命和业务目标。如本书简介中所述，开源软件代码几乎在每个环境中都很普遍，包括能源、金融、通信、医疗保健和国防工业基地等关键基础设施领域。尽管表面上看，开源软件的普及可能有意义，鉴于其带来的创新和社区合作，但也带来了挑战。研究发现，88％的代码库包含两年以上没有新开发的开源软件组件，81％的代码库至少包含一个漏洞，近 90％的代码库包含的开源软件不是最新版本。
  这意味着过时、维护不善和易受攻击的开源软件存在于几乎所有社会领域，包括关键基础设施领域。
  在专有软件方面，也存在独特的挑战。虽然开源软件通常在其来源中分配了常见漏洞和暴露（CVEs），如国家漏洞数据库（NVD），并可以使用漏洞扫描工具扫描以识别已知漏洞，但专有代码可能更难，需要其他技术来识别漏洞。此外，专有软件的源代码通常不公开，使得评估和分析不那么简单。推动 SBOMs 的使用将创造一个软件供应商和供应链在其产品中提供 SBOMs 的情况，同时还将揭示相关漏洞。
  OSS 和专有软件在漏洞披露和修复方面存在明显差异。在专有软件方面，供应商通常有合同文件和协议，允许他们告知软件用户潜在的漏洞和风险影响。但在 OSS 领域则不然。因为 OSS 对所有人开放访问、使用、重用和修改，因此很难有一个集中通知或机制来通知任何受 OSS 项目或组件漏洞影响的人。这一问题因 OSS 组件被整合到其他项目和代码中作为依赖项而更加严重。这使得软件消费者必须彻底了解其环境中的软件，并警惕任何通知、漏洞和与这些软件组件相关的风险。
  常有人认为 OSS 可以比专有软件更安全，因为代码是开放的，所有人都可以查看和分析。OSS 社区中一个常见的格言称为 Linus's Law 声称：“只要有足够的眼睛，所有的 bug 都是浅显的。”这似乎很直观，因为如果有足够多的软件开发人员和安全专家查看代码，bug 和漏洞的可能性会减少。尽管这在非常流行的 OSS 项目如 Linux 和 Kubernetes 上可能是正确的，但在更广泛的 OSS 生态系统中并不成立。OSS 项目数以百万计，其中一些可能有维护人员和贡献者的繁荣生态系统，而另一些则常由一小群人甚至单个人维护。一些研究表明，几乎四分之一的 OSS 项目只有一个贡献者（https://dl.acm.org/doi/abs/10.1145/3510003.3510216），更令人惊讶的是，几乎 95％ 的项目有少于 10 个开发者贡献了大部分代码（www.synopsys.com/content/dam/synopsys/sig-assets/reports/rep-ossra-2022.pdf）。值得注意的是，专有软件供应商也有资源限制，这意味着公司没有无限的开发资源，通常需要优先考虑创收功能和产品增强，而不是安全活动。资源限制增加了风险，这应是所有软件消费者的考虑，无论他们是消费 OSS 还是专有代码。通过模糊性实现安全的陈旧模式也基本被淘汰，许多专家同意模糊性对对手的帮助远大于对社区的帮助。尽管如此，这并不阻止一些组织试图隐藏在模糊性后面，要么是真正相信这会带来更好的安全结果，要么是因为害怕暴露他们知道但不愿披露的低效和漏洞。
  OSS 代码和专有代码之间的另一个显著差异是 OSS 的工作方式，任何人都可以消费和使用它，公开披露是通知潜在受影响消费者和各方的唯一有效方法。没有统一的 OSS 组件用户列表，公开披露允许消费者采取行动，但也要求 OSS 消费者意识到这些披露，并最重要的是，理解其 OSS 消费，以便能够采取任何措施应对风险。在专有方面，组织可以通知其客户和消费者，因为通常有协议和合同，如合同、服务级协议等。
  尽管 OSS 带来了一个繁荣的创新软件解决方案生态系统，这些解决方案节省了组织的时间、资源和麻烦，但它也带来了一个复杂的现代软件供应链，具有指数级的依赖关系。研究表明，平均应用程序和项目基于使用的编程语言有近 70 个依赖关系，平均应用程序也有至少 5 个关键漏洞。许多软件消费者不了解其依赖项的全部范围，从而不了解与这些依赖项相关的漏洞。这些研究表明，尽管广泛使用 OSS，受调查的一半组织没有管理 OSS 使用的安全策略。像国家标准与技术研究院（NIST）这样的组织建议采用最佳实践，如建立管理 OSS 使用的政策，并进一步建立已知可信 OSS 组件的内部存储库供开发人员使用，而不是允许不受限制地使用外部 OSS 组件。