从业者指南：安全入门

主要指标：

• OpenSSF 最佳实践徽章
• 图书馆年
• 发布频率

如果您还没有阅读 从业者指南：简介 - 解释指标时要考虑的事项，请现在暂停并阅读该指南。

安全性的强弱取决于其最薄弱的环节。我们使用的几乎所有软件中都可以找到开源软件包（Synopsis 2024），因此我们的开源项目的安全性可能会对其他项目、我们的用户和更广泛的生态系统产生深远的影响。

安全性可能是开源项目选择的一个重要因素，但任何软件组件的安全性都只能与其依赖项的安全性一样好（Imtiaz 2022）。安全性是选择项目所依赖的开源组件的重要考虑因素，同时也会影响其他人选择使用（或不使用）您的开源项目的原因。在此选择中，需要注意的是，流行的软件包遵循良好安全实践的可能性不会更高或更低（Imtiaz 2022）。

Synopsys 2024 年开源安全和风险分析报告发现，他们扫描的代码库中有 96% 包含开源软件，不幸的是，其中 84% 存在漏洞（74% 的严重性评级很高）。由于开源无处不在，开源项目安全会影响我们项目的健康和可持续性，从而影响整个软件生态系统。但是，请记住，安全风险通常可以被认为是可能性和影响的函数。可能性是可利用性的可能性，影响是软件部署环境中漏洞可能造成的损害，因此风险是每个开源采用者都需要根据其特定背景、情况和环境来确定的。

由于安全性是一个复杂且关键的话题，本指南仅用于 帮助您入门 提高项目安全性的道路上。 不是一个全面的指南 了解您需要了解的有关开源项目安全的所有信息。实践者指南系列的目标是帮助人们度过许多人在面对大量新指标时感到不知所措的阶段，这些新指标可以帮助他们找到一些方法来开始了解和改善项目的健康状况。在开始阅读本实践者指南后，您可以从下面的附加阅读部分中的综合指南链接以及本指南中的链接中了解更多信息。

第 1 步：确定趋势

安全性是一个复杂的话题，但你可以从查看几个关键指标开始。首先， OpenSSF 最佳实践徽章 标准创建了一个良好的工程基础，其中包含基本的安全实践。其次，当您使用过时的依赖项时，出现安全问题的可能性会增加四倍（Cox 等人，2015 年），因此使用 图书馆年 指标可以帮助你了解是否保持依赖项的更新。第三， 发布频率 帮助判断您的安全修复和其他更新是否及时发布，以便您的用户可以从您的安全更新中受益。

OpenSSF 最佳实践

- 开源安全基金会 （OpenSSF）提供了从多个不同维度评估开源项目的方法，以总结项目实践中可以改进的地方。虽然安全实践是一个重要组成部分，但 OpenSSF 最佳实践徽章 不仅仅是安全性，还为您的项目提供了一系列最佳实践建议。这不仅是评估您的安全实践并改进它们以满足徽章标准的好方法，而且还向您的用户发出信号，表明您遵循 OpenSSF 最佳实践。报告、安全和分析部分中的标准最适合理解和改进项目的安全性。

图片来源： https://www.bestpractices.dev/en/projects/63

图书馆年

- 图书馆年 指标解释了您所依赖的依赖项相对于这些依赖项的当前稳定版本的使用年限。该指标首次提出于“测量软件系统中的依赖项新鲜度”（Cox 等人，2015 年）。一般来说，Libyear 数字越低越好，因为它表示您正在保持依赖项的最新状态。

图片来源： https://github.com/nasirhjafri/libyear

通过将项目中使用的依赖项的当前版本与每个依赖项可用的最新版本进行比较，您可以更好地了解在更新依赖项时可能需要更加努力的地方。但是，更新依赖项的技术滞后通常是由使用最新版本与不破坏已经运行良好的解决方案之间的矛盾造成的，因此在某些情况下，由于不兼容或其他技术问题，开发人员可能会故意选择使用旧版本而不是最新版本（Zerouali 等人，2019 年）。

发布频率

及时发布安全更新、错误修复和新功能至关重要。在考虑发布频率时，不仅要包括重大发布，还要包括所有小更新，因为紧急安全修复通常在主要发布之外发布。

![频繁发布的项目的发布频率][https://github.com/chaoss/wg-data-science/blob/main/practitioner-guides/images/releases.png?raw=true]

请记住，解释此指标可能具有挑战性，因为不同类型的项目和不同的情况会影响项目是否需要更频繁或更少的发布节奏。拥有一致的发布频率可以表明项目更稳定或更成熟。

第 2 步：诊断

开始诊断项目安全实践中的潜在问题的一个好方法是开始研究 OpenSSF 项目徽章标准。在进行过程中，它可能看起来像这个例子：

图片来源： https://www.bestpractices.dev/en/projects/40

如前所述，这包括安全最佳实践，也包括更通用的软件工程最佳实践，以各种方式改进您的项目。在每条建议下，您都会找到需要回答的问题，这些问题符合获得徽章所需的标准。

例如，以下是安全部分下的一些问题：

无论你是否决定追求这个徽章， 标准 使用的，特别是在安全和报告部分，是思考如何理解和改进项目安全性的好方法。还有其他选项可以对您的项目进行安全自我评估，包括 CNCF 的自我评估 用于他们的项目。

诊断的下一步可能是查看您的 Libyears 报告，重点关注最过时的依赖项。当您使用过时的依赖项时，发生安全问题的可能性会增加四倍（Cox 等人，2015 年），因此保持依赖项的更新是提高项目安全性的重要因素。如前所述，依赖项落后于当前版本有时是有充分理由的：重大更改、与您的软件/其他依赖项不兼容或其他技术问题。在这种情况下，诊断需要深思熟虑并彻底检查是否有充分理由不更新依赖项。

要判断您是否及时发布补丁，您应该查看过去一年中创建的安全补丁。如果您在发布每个安全补丁时都发布了补丁，那么您可能处于相当良好的状态。如果安全补丁堆积如山，没有在发布时发布，那么您可能应该查看为什么会发生这种情况，看看是否可以改进发布流程，以便在修复漏洞时更频繁地发布补丁。

第 3 步：根据需要收集其他数据

步骤 1 和 2 中使用的示例提供了一个起点，可以通过使用其他工具和指标进行扩展。诊断过程的下一步是运行 OpenSSF 记分卡它通过详细的检查帮助您找到项目在源代码、构建、依赖项、测试和项目维护类别中可能存在漏洞的区域。

您可能会注意到，本指南中没有针对解决安全漏洞时间的指标。这非常重要，但很难衡量，因为您需要能够将安全问题与错误和其他问题区分开来，同时还要将漏洞的初始报告与修复的变更请求联系起来。有很多方法可以做到这一点，但具体怎么做取决于您的工具。虽然它可能不是最好的入门指标，但您应该考虑将其作为下一步措施之一进行测量。下面的其他指标为测量这一点提供了一个良好的开端。

附加指标：

• OpenSSF 记分卡 （不是 CHAOSS 指标，而是收集多项安全指标的工具）
• 变更请求
• 缺陷解决持续时间
• SPDX 文件
• 上游代码依赖

第四步：做出改进

改善安全实践的最佳起点之一是保护代码存储库。这包括管理访问、分支保护、管理贡献等。 OpenSSF 源代码管理平台配置最佳实践 指南列出了一系列建议，并附有针对 GitHub 和 GitLab 实施这些建议的链接。

另一个好的起点是为你的项目创建一个详细的安全策略文档。这通常在 安全.md 文件位于存储库的根目录中。本文档旨在提供报告安全漏洞的说明，以及记录您如何响应这些报告，包括管理 禁运。本文档将帮助您满足 OpenSSF 最佳实践徽章中的报告标准要求。有很多地方可以找到创建安全策略的详细说明，因此我们不会在这里重复这些详细信息。例如， OpenSSF 的 OSS 漏洞指南 包含有关此文件应包含的内容的更多详细信息以及实施安全策略的模板和说明，这不仅仅是创建文档，还包括有关基础设施和管理安全过程的其他要求的详细信息。

如上所述，当您使用过时的依赖项时，出现安全问题的可能性会增加四倍（Cox 等人，2015 年），因此保持依赖项的更新是提高项目安全性的重要因素。依赖项需要深思熟虑并彻底检查是否有充分的理由不更新依赖项，同时测试较新的版本以确保在更新依赖项时不会破坏其他内容。虽然有充分的理由避免更新某些依赖项，但在大多数情况下，依赖项不会更新，因为很难跟踪它们应该何时更新。像 依赖机器人 or 翻新机器人 可以帮助识别并自动更新某些依赖项。

良好的安全修复文档有助于提高对可用安全修复的认识（Imtiaz 等人，2022 年），确保这些修复及时发布非常重要。如果您经常制作安全补丁，但没有快速发布，那么您可能应该看看为什么会发生这种情况，看看是否可以改进发布流程，以便在修复漏洞时更频繁地发布。您的发布说明或其他文档包含有关安全修复的详细信息也很重要，以强调更新对使用您的软件的人的重要性。

如前所述，按照 OpenSSF 最佳实践徽章标准进行操作是提高安全性的好方法。 各级别标准页面的详细视图 包含更多详细的解释和链接，可以帮助您在每个领域取得进步。

第 5 步：监控结果

由于安全性是一个非常复杂的主题，因此很难监控。但是，您可以随着时间的推移监控一些事项，以查看您为改善安全性而采取的措施是否产生了影响。以下是监控进度的一些建议：

• OpenSSF 记分卡：您的总体得分是否有所提高？您是否提高了您认为需要改进的某些个别领域的得分？
• 图书馆年份：您的图书馆年份数字是否有所提高？
• 发布：每次创建安全补丁时，您是否都会发布一个版本？

注意事项和注意事项

• 由于安全是一个关键主题，本指南仅用于 帮助您入门 提高项目安全性的道路上。 不是一个全面的指南 了解您需要了解的有关开源项目安全性的一切。您可以从下面的附加阅读部分中的链接了解更多信息。
• 您可能会注意到，本指南中没有针对解决安全漏洞所需时间的指标。这非常重要，但很难衡量，因此我们建议将此指标作为您的下一步措施之一。有关更多详细信息，请参阅步骤 3。

补充阅读

• 我们有一个 短片 （<4 分钟）专门介绍 CHAOSS YouTube 频道上的本指南。
• CHAOSScast 剧集 关于本指南。
• OpenSSF 的网站 包含各种非常详细的指南、培训和其他资源。
• - CNCF 安全指南 该文档远不如 OpenSSF 指南全面，但如果您刚开始提高安全性，它可能会更有帮助。
• OpenSSF 的 OSS 漏洞指南 包含指南以及模板和专注于制定和实施安全策略的运行手册。

反馈

我们很乐意收到反馈，以了解更多有关人们如何使用 CHAOSS 从业者指南以及我们如何随着时间的推移对其进行改进的信息。请完成此 简短的调查 提供您的反馈。

合作者

以下人员为本指南做出了贡献：

• 黎明福斯特
• 马特·杰蒙普雷斯
• 艾米丽·福克斯

案例

• Cox, J.、Bouwers, E.、Van Eekelen, M. 和 Visser, J.（2015 年 XNUMX 月）。 测量软件系统中依赖项的新鲜度。在 2015 IEEE/ACM 第 37 届 IEEE 软件工程国际会议 （第 2 卷，第 109-118 页）。 IEEE。
• Imtiaz, N.、Khanom, A. 和 Williams, L. (2022)。 公开还是偷偷摸摸？快还是慢？轻还是重？：调查开源软件包的安全版本. IEEE 软件工程学报, 49（4），1540 1560。
• 新思科技（2024 年）。 开源安全和风险分析报告.
• Zerouali, A.、Mens, T.、Gonzalez-Barahona, J.、Decan, A.、Constantinou, E. 和 Robles, G. (2019)。 用于测量组件存储库技术滞后的正式框架及其在 npm 中的应用. 软件杂志：演化与过程, 31（8），e2157。

CHAOSS 从业者指南是 MIT 授权的动态文档，我们欢迎您的反馈和意见。您可以在以下位置建议对本文档进行修改 https://github.com/chaoss/wg-data-science/blob/main/practitioner-guides/security.md