[机翻] 共同成功建立更安全的开源社区（Google）

[will-ww]

原文地址：https://blog.google/technology/safety-security/shared-success-in-building-a-safer-open-source-community/

今天，我们加入了开源安全基金会 (OpenSSF)、Linux 基金会和行业领导者的会议，以继续推进1 月份白宫开源安全峰会期间讨论的开源软件安全计划。在这次会议上，谷歌宣布成立新的“开源维护团队”——一个由谷歌工程师组成的敬业团队，他们将与上游维护者密切合作，提高关键开源项目的安全性。除了这一举措，我们还贡献了想法并参与了关于提高开源软件的安全性和可信赖性的讨论。

在所有这些势头和进步中，重要的是要评估我们作为一个社区在过去一年半中取得的进展。在这篇文章中，我们将提供一些已启动的重要里程碑和项目的最新信息，并展望未来以及仍需完成的工作。

了解、预防、修复
一年多前，我们发布了Know, Prevent, Fix，它为软件行业如何解决开源软件中的漏洞提供了一个框架。当时，人们对这个话题越来越感兴趣，希望能在推进和改进软件供应链安全的事业中产生动力。

从那时起，景观发生了很大变化：

Log4j 和 Codecov 等关键开源库中的突出攻击和漏洞成为头条新闻，使人们对该问题的认识达到了一个新的水平，并统一了整个行业来解决这个问题。
美国政府在 2021 年 5 月的网络安全行政命令中正式推动了更高的安全标准。安全软件开发框架（一套针对软件开发的国家安全标准的指导方针）的发布引发了全行业关于如何实施这些标准的讨论。
去年 8 月，包括谷歌、苹果、IBM、微软和亚马逊在内的技术领导者投资 于改善网络安全——仅谷歌就承诺在未来五年内投入 100 亿美元来加强网络安全，其中包括 1 亿美元用于支持 OpenSSF 等第三方基金会。管理开源安全优先级并帮助修复漏洞。
鉴于这些变化，Know、Prevent、Fix框架被证明是有先见之明的：除了关于开源安全性的更多讨论之外，我们正在目睹业界在对这些讨论采取行动方面取得了真正的进展。特别是，OpenSSF 已成为推动安全工程工作、讨论和全行业协作的社区市政厅。

然而，这些成功也带来了新的挑战，我们相信下一步是增加可访问性。安全工具应该更容易被采用到常见的开发人员工作流程中，在整个生态系统中更加集成，并且更容易连接到项目中。所有这一切的基础是需要简化将项目与可用资金和资源匹配的过程，以实现安全性改进。

这篇后续博客文章讨论了谷歌在过去一年中与开源社区合作在安全目标方面取得进展的努力、吸取的经验教训以及行业如何在这一势头的基础上再接再厉。

知道
我们“知道”的目标是捕获更精确的漏洞数据，建立标准模式来跟踪数据库中的漏洞，并创建工具以更好地跟踪依赖关系。

在过去的一年中，社区对开源漏洞 (OSV)的投资产生了一种新的漏洞格式。该格式由多个开源生态系统（Python、Rust、Go）以及漏洞数据库（如GitHub 的安全公告（GHSA）和全球安全数据库）开发和采用。Google 还与 MITRE 就新的 CVE 5.0 JSON模式密切合作，以简化未来的互操作性。OSV.dev 还支持可搜索的漏洞数据库由于采用标准化格式，它将所有其他数据库中的漏洞汇总到一个易于搜索的位置。

在 Log4j 漏洞响应期间，Google 支持的Open Source Insights项目帮助社区了解了漏洞的影响。该项目分析开源包并提供依赖关系及其属性的详细图表。有了这些信息，开发人员可以了解他们的软件是如何组合在一起的，以及他们的依赖关系变化的后果——正如 Log4j 所示，当受影响的依赖关系在依赖关系图中的许多层很深时，这可能会很严重。今天，我们还将支持 Open Source Insights 的数据作为公共 Google Cloud 数据集提供。

OSV 项目表明，如果没有精确的漏洞元数据，将 CVE 连接到漏洞补丁开发工作流程可能很困难。这将需要不同开发社区之间的合作才能获得进展的全部好处，但通过合作，OSV 可以在语言和项目生态系统中快速扩展。

我们认为下一个主要目标是降低用户的准入门槛。与开发人员工具和流程集成将把高质量的信息带到最有用的地方。例如，从代码编辑器（例如，在决定是否包含库时）到部署（例如，阻止易受攻击的工作负载部署），OSV 的发现无处不在。

防止
“预防”旨在帮助用户了解新依赖项的风险，以便他们可以就他们使用的包和组件做出明智的决定。

我们已经看到社区在漏洞预防方面的积极参与，特别是在安全记分卡项目中。记分卡评估项目对安全最佳实践的遵守情况，并分配开发人员在使用依赖项之前可以参考的分数。用户可以选择避免项目，例如，不使用分支保护设置或使用危险的工作流程（这使项目容易受到恶意提交），并倾向于遵循强大的安全实践的项目，例如签署他们的版本和使用 fuzzing。感谢 Cisco、Datto 和其他几个开源贡献者的贡献，现在有定期的记分卡扫描100 万个项目，记分卡已经从一个命令行工具发展成为一个自动化的 GitHub 操作，在对 GitHub 项目进行任何更改后运行。越来越多的组织正在采用记分卡，并且记分卡 GitHub Action 已安装在 1000 多个项目中，并且还在持续增长。随着采用率的提高，整个生态系统的整体安全性将得到改善。

此外，Sigstore通过创建用于签名、验证和保护软件的新工具来帮助防止攻击。近日，Kubernetes宣布正在使用 sigstore对其版本进行签名，这表明大规模的工件签名现在已经触手可及。随着采用的扩大，我们可以期待已发布的源代码和运行它的二进制文件之间的联系更加紧密。

Citi、Chainguard、DataDog、VMWare 等社区合作者为 OpenSSF 的SLSA 框架做出了积极贡献。该项目基于谷歌内部的 Borg 二进制授权(BAB)，十多年来一直在降低谷歌的源代码和生产攻击风险。SLSA 通过为保护源代码和构建系统完整性提供分步指南和实际目标，为组织提供了提高其整体软件供应链安全性的可行途径。SLSA 框架解决了软件物料清单 (SBOM) 的限制，它本身并不能提供有关完整性和出处的足够信息。使用 SLSA 出处和元数据创建的SBOM更完整，并解决了源代码和构建威胁向量。使用 SLSA 还可以帮助用户实现安全软件开发框架 (SSDF)要求。

在过去的一年中，针对开源开发人员对OSS-Fuzz服务的持续改进已帮助修复了500多个项目中的2300多个漏洞。谷歌还通过增加对Java和Swift等新语言的支持以及开发错误检测器来发现 Log4shell 等问题，大力投资扩大模糊测试的范围。

通过 Linux Kernel Self-Protection Project，Google 一直在提供源源不断的更改来彻底检查内部内核 API，以便编译器能够检测并阻止反复出现漏洞的脆弱区域中的缓冲区溢出。对于生态系统中保持最新 Linux 内核版本的每个人来说，这消除了一大类可能导致安全漏洞的缺陷。

展望未来，该领域的快速增长凸显了社区对软件供应链完整性的关注。用户正在寻找他们可以跨生态系统信任的解决方案，例如将部署的软件连接到其原始源代码的出处元数据。此外，我们希望加强对开发过程的审查，以确保以最安全的方式构建软件。

开源软件安全的下一个目标应该包括广泛采用最佳实践和可扩展性。随着越来越多的项目变得安全，增加这些工具的使用将成倍增加积极影响，但采用需要以跨生态系统的可扩展方式进行（例如，通过专注于提高集中式包管理器安全性的OpenSSF 安全包存储库工作组）。教育将成为加速从逐个项目采用到大规模生态系统转换的驱动力：更高的意识将为变革带来更大的动力。

使固定
“修复”旨在帮助用户了解他们删除漏洞的选项，启用有助于加快修复的通知，并修复受影响软件的广泛使用版本，而不仅仅是最新版本。

Google 通过我们的计划和服务支持开源创新、安全性、协作和可持续性，去年向开源提供了 1500 万美元。这包括 750 万美元用于在供应链安全、模糊测试、内核安全和关键基础设施安全等领域进行有针对性的安全工作。例如，250 万美元的安全资金用于Alpha-Omega 项目，该项目首次向Node.js 基金会拨款，以加强其安全团队并支持漏洞修复。

其他安全投资包括向SOS Rewards投资 100 万美元，向 Internet Security Research Group 投资 300,000 美元，以通过将Rust 整合到 Linux 内核中来提高内存安全性。剩余的资金用于支持安全审计、包签名、模糊测试、可重复构建、基础设施安全和安全研究。

除了财务投资之外，Google 员工每年还为数以万计的开源存储库贡献他们的时间、精力和代码。开源维护者经常提到的一个问题是时间有限。由于维护不足的关键开源组件存在安全风险，谷歌正在组建一个新的开源维护团队，这是一个由谷歌工程师组成的专职人员，他们将与上游维护人员密切合作，以提高关键开源项目的安全性。我们希望其他依赖开源的企业也能投入类似的努力，以帮助加速开源生态系统的安全改进。

下一个
过去一年取得的进展非常令人鼓舞：作为一个行业，我们聚在一起讨论、资助并在许多影响我们所有人的难题上取得进展。解决方案不仅被谈论，而且被构建、改进和应用。现在我们需要通过将这些解决方案与工具和语言生态系统集成来放大这一进步：默认情况下，每个开源开发人员都应该能够轻松访问端到端安全性。

Google 致力于继续与 OpenSSF 合作以实现这些目标。要了解有关 OpenSSF 基金会的更多信息并加入其努力，请在此处查看。

[wangleo61]

激动人心 发件人: Will ***@***.***> 发送时间: Tuesday, May 17, 2022 10:28 AM 收件人: ***@***.***> 抄送: ***@***.***> 主题: [kaiyuanshe/ONES] [机翻] 共同成功建立更安全的开源社区（Google） (Discussion #90) 原文地址：https://blog.google/technology/safety-security/shared-success-in-building-a-safer-open-source-community/ 今天，我们加入了开源安全基金会 (OpenSSF)、Linux 基金会和行业领导者的会议，以继续推进1 月份白宫开源安全峰会<https://blog.google/technology/safety-security/making-open-source-software-safer-and-more-secure/>期间讨论的开源软件安全计划。在这次会议上，谷歌宣布成立新的“开源维护团队”――一个由谷歌工程师组成的敬业团队，他们将与上游维护者密切合作，提高关键开源项目的安全性。除了这一举措，我们还贡献了想法并参与了关于提高开源软件的安全性和可信赖性的讨论。 在所有这些势头和进步中，重要的是要评估我们作为一个社区在过去一年半中取得的进展。在这篇文章中，我们将提供一些已启动的重要里程碑和项目的最新信息，并展望未来以及仍需完成的工作。 了解、预防、修复 一年多前，我们发布了Know, Prevent, Fix<https://opensource.googleblog.com/2021/02/know-prevent-fix-framework-for-shifting-discussion-around-vulnerabilities-in-open-source.html#fn1>，它为软件行业如何解决开源软件中的漏洞提供了一个框架。当时，人们对这个话题越来越感兴趣，希望能在推进和改进软件供应链安全的事业中产生动力。 从那时起，景观发生了很大变化： Log4j 和 Codecov 等关键开源库中的突出攻击和漏洞成为头条新闻，使人们对该问题的认识达到了一个新的水平，并统一了整个行业来解决这个问题。 美国政府在 2021 年 5 月的网络安全行政命令中<https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/>正式推动了更高的安全标准。安全软件开发框架<https://csrc.nist.gov/Projects/ssdf>（一套针对软件开发的国家安全标准的指导方针）的发布引发了全行业关于如何实施这些标准的讨论。 去年 8 月，包括谷歌、苹果、IBM、微软和亚马逊在内的技术领导者投资<https://www.whitehouse.gov/briefing-room/statements-releases/2021/08/25/fact-sheet-biden-administration-and-private-sector-leaders-announce-ambitious-initiatives-to-bolster-the-nations-cybersecurity/> 于改善网络安全――仅谷歌就承诺在未来五年内<https://blog.google/technology/safety-security/why-were-committing-10-billion-to-advance-cybersecurity/>投入 100 亿美元来加强网络安全，其中包括 1 亿美元用于支持 OpenSSF 等第三方基金会。管理开源安全优先级并帮助修复漏洞。 鉴于这些变化，Know、Prevent、Fix框架被证明是有先见之明的：除了关于开源安全性的更多讨论之外，我们正在目睹业界在对这些讨论采取行动方面取得了真正的进展。特别是，OpenSSF 已成为推动安全工程工作、讨论和全行业协作的社区市政厅。 然而，这些成功也带来了新的挑战，我们相信下一步是增加可访问性。安全工具应该更容易被采用到常见的开发人员工作流程中，在整个生态系统中更加集成，并且更容易连接到项目中。所有这一切的基础是需要简化将项目与可用资金和资源匹配的过程，以实现安全性改进。 这篇后续博客文章讨论了谷歌在过去一年中与开源社区合作在安全目标方面取得进展的努力、吸取的经验教训以及行业如何在这一势头的基础上再接再厉。 知道 我们“知道”的目标是捕获更精确的漏洞数据，建立标准模式来跟踪数据库中的漏洞，并创建工具以更好地跟踪依赖关系。 在过去的一年中，社区对开源漏洞 (OSV)<http://osv.dev/>的投资产生了一种新的漏洞格式<https://ossf.github.io/osv-schema/>。该格式由多个开源生态系统（Python<https://github.com/pypa/advisory-database>、Rust<https://github.com/RustSec/advisory-db>、Go<https://github.com/golang/vulndb>）以及漏洞数据库（如GitHub 的安全公告（GHSA）<https://github.blog/2022-02-22-github-advisory-database-now-open-to-community-contributions/>和全球安全数据库<https://github.com/cloudsecurityalliance/gsd-database>）开发和采用。Google 还与 MITRE 就新的 CVE 5.0 JSON<https://github.com/CVEProject/cve-schema/blob/master/schema/v5.0/docs/versions.md>模式密切合作，以简化未来的互操作性。OSV.dev 还支持可搜索的漏洞数据库<https://osv.dev/list>由于采用标准化格式，它将所有其他数据库中的漏洞汇总到一个易于搜索的位置。 在 Log4j 漏洞响应期间，Google 支持的Open Source Insights<http://deps.dev/>项目帮助社区了解了漏洞的影响。<https://security.googleblog.com/2021/12/understanding-impact-of-apache-log4j.html>该项目分析开源包并提供依赖关系及其属性的详细图表。有了这些信息，开发人员可以了解他们的软件是如何组合在一起的，以及他们的依赖关系变化的后果――正如 Log4j 所示，当受影响的依赖关系在依赖关系图中的许多层很深时，这可能会很严重。今天，我们还将支持 Open Source Insights 的数据作为公共 Google Cloud 数据集<https://console.cloud.google.com/marketplace/product/bigquery-public-data/deps-dev>提供。 OSV 项目表明，如果没有精确的漏洞元数据，将 CVE 连接到漏洞补丁开发工作流程可能很困难。这将需要不同开发社区之间的合作才能获得进展的全部好处，但通过合作，OSV 可以在语言和项目生态系统中快速扩展。 我们认为下一个主要目标是降低用户的准入门槛。与开发人员工具和流程集成将把高质量的信息带到最有用的地方。例如，从代码编辑器（例如，在决定是否包含库时）到部署（例如，阻止易受攻击的工作负载部署），OSV 的发现无处不在。 防止 “预防”旨在帮助用户了解新依赖项的风险，以便他们可以就他们使用的包和组件做出明智的决定。 我们已经看到社区在漏洞预防方面的积极参与，特别是在安全记分卡<https://securityscorecards.dev/>项目中。记分卡评估项目对安全最佳实践的遵守情况，并分配开发人员在使用依赖项之前可以参考的分数。用户可以选择避免项目，例如，不使用分支保护设置<https://github.com/ossf/scorecard/blob/main/docs/checks.md#branch-protection>或使用危险的工作流程<https://github.com/ossf/scorecard/blob/main/docs/checks.md#dangerous-workflow>（这使项目容易受到恶意提交），并倾向于遵循强大的安全实践的项目，例如签署他们的版本<https://github.com/ossf/scorecard/blob/main/docs/checks.md#signed-releases>和使用 fuzzing<https://github.com/ossf/scorecard/blob/main/docs/checks.md#fuzzing>。感谢 Cisco、Datto 和其他几个开源贡献者的贡献，现在有定期的记分卡扫描100 万个项目<https://github.com/ossf/scorecard#public-data>，记分卡已经从一个命令行工具发展成为一个自动化的 GitHub 操作，在对 GitHub 项目进行任何更改后运行。越来越多的组织正在采用记分卡<https://blog.envoyproxy.io/security-scorecards-envoy-automating-supply-chain-analysis-7b8fd9829169>，并且记分卡 GitHub Action 已安装在 1000 多个项目中，并且还在持续增长。随着采用率的提高，整个生态系统的整体安全性将得到改善。 此外，Sigstore<https://www.sigstore.dev/>通过创建用于签名、验证和保护软件的新工具来帮助防止攻击。近日，Kubernetes<https://kubernetes.io/>宣布正在使用 sigstore对其版本进行签名<https://blog.sigstore.dev/kubernetes-signals-massive-adoption-of-sigstore-for-protecting-open-source-ecosystem-73a6757da73>，这表明大规模的工件签名现在已经触手可及。随着采用的扩大，我们可以期待已发布的源代码和运行它的二进制文件之间的联系更加紧密。 Citi、Chainguard、DataDog、VMWare 等社区合作者为 OpenSSF 的SLSA 框架<http://slsa.dev/>做出了积极贡献。该项目基于谷歌内部的 Borg 二进制授权<https://cloud.google.com/security/binary-authorization-for-borg>(BAB)，十多年来一直在降低谷歌的源代码和生产攻击风险。SLSA 通过为保护源代码和构建系统完整性提供分步指南和实际目标，为组织提供了提高其整体软件供应链安全性的可行途径。SLSA 框架解决了软件物料清单 (SBOM) 的限制，它本身并不能提供有关完整性和出处的足够信息。使用 SLSA 出处和元数据创建的SBOM<https://slsa.dev/blog/2022/05/slsa-sbom>更完整，并解决了源代码和构建威胁向量。使用 SLSA 还可以帮助用户实现安全软件开发框架 (SSDF)<https://csrc.nist.gov/Projects/ssdf>要求。 在过去的一年中，针对开源开发人员对OSS-Fuzz<https://github.com/google/oss-fuzz>服务的持续改进已帮助修复了500多个项目中的<https://github.com/google/oss-fuzz/tree/master/projects>2300多个漏洞。<https://bugs.chromium.org/p/oss-fuzz/issues/list?q=opened%3E2021-02-01%20Type%3DBug-Security%20status%3AVerified&can=1>谷歌还通过增加对Java<https://google.github.io/oss-fuzz/getting-started/new-project-guide/jvm-lang/>和Swift<https://google.github.io/oss-fuzz/getting-started/new-project-guide/swift/>等新语言的支持以及开发错误检测器来发现 Log4shell 等问题<https://security.googleblog.com/2021/12/improving-oss-fuzz-and-jazzer-to-catch.html>，大力投资扩大模糊测试的范围。 通过 Linux Kernel Self-Protection Project<https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project>，Google 一直在提供源源不断的更改来彻底检查内部内核 API，以便编译器能够检测并阻止反复出现漏洞<https://google.github.io/security-research/pocs/linux/bleedingtooth/writeup.html>的脆弱区域中的缓冲区溢出。对于生态系统中保持最新 Linux 内核版本<https://security.googleblog.com/2021/08/linux-kernel-security-done-right.html>的每个人来说，这消除了一大类可能导致安全漏洞的缺陷。<https://lwn.net/Articles/864521/> 展望未来，该领域的快速增长凸显了社区对软件供应链完整性的关注。用户正在寻找他们可以跨生态系统信任的解决方案，例如将部署的软件连接到其原始源代码的出处元数据。此外，我们希望加强对开发过程的审查，以确保以最安全的方式构建软件。 开源软件安全的下一个目标应该包括广泛采用最佳实践和可扩展性。随着越来越多的项目变得安全，增加这些工具的使用将成倍增加积极影响，但采用需要以跨生态系统的可扩展方式进行（例如，通过专注于提高集中式包管理器安全性的OpenSSF 安全包存储库工作组）。<https://openssf.org/blog/2022/04/19/your-favorite-software-repositories-now-working-together/>教育将成为加速从逐个项目采用到大规模生态系统转换的驱动力：更高的意识将为变革带来更大的动力。 使固定 “修复”旨在帮助用户了解他们删除漏洞的选项，启用有助于加快修复的通知，并修复受影响软件的广泛使用版本，而不仅仅是最新版本。 Google 通过我们的计划和服务支持开源创新、安全性、协作和可持续性，去年向开源提供了 1500 万美元。这包括 750 万美元用于在供应链安全、模糊测试、内核安全和关键基础设施安全等领域进行有针对性的安全工作。例如，250 万美元的安全资金用于Alpha-Omega 项目<https://openssf.org/community/alpha-omega/>，该项目首次向Node.js 基金会<https://openjsf.org/blog/2022/04/19/nodejs-18-released/>拨款，以加强其安全团队并支持漏洞修复。 其他安全投资包括向SOS Rewards投资 100 万美元，向 Internet Security Research Group 投资 300,000 美元，以通过将<https://security.googleblog.com/2021/10/introducing-secure-open-source-pilot.html>Rust 整合到 Linux 内核<https://security.googleblog.com/2021/04/rust-in-linux-kernel.html>中来提高内存安全性。剩余的资金用于支持安全审计、包签名、模糊测试、可重复构建、基础设施安全和安全研究。 除了财务投资之外，Google 员工每年还为数以万计的开源存储库贡献他们的<https://opensource.googleblog.com/2020/08/open-source-by-numbers-at-google.html>时间、精力和代码。<https://opensource.googleblog.com/2021/08/metrics-spikes-and-uncertainty-open-source-contribution-during-a-global-pandemic.html>开源维护者经常提到的一个问题是时间有限。由于维护不足的关键开源组件存在安全风险，谷歌正在组建一个新的开源维护团队，这是一个由谷歌工程师组成的专职人员，他们将与上游维护人员密切合作，以提高关键开源项目的安全性。我们希望其他依赖开源的企业也能投入类似的努力，以帮助加速开源生态系统的安全改进。 下一个 过去一年取得的进展非常令人鼓舞：作为一个行业，我们聚在一起讨论、资助并在许多影响我们所有人的难题上取得进展。解决方案不仅被谈论，而且被构建、改进和应用。现在我们需要通过将这些解决方案与工具和语言生态系统集成来放大这一进步：默认情况下，每个开源开发人员都应该能够轻松访问端到端安全性。 Google 致力于继续与 OpenSSF 合作以实现这些目标。要了解有关 OpenSSF 基金会的更多信息并加入其努力，请在此处查看<https://openssf.org/getinvolved/>。 ― Reply to this email directly, view it on GitHub<#90>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AO5RA3ZRB53RK27OF3TIPUDVKL745ANCNFSM5WDLKCKQ>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[wangleo61]

Secure Software Development Framework SSDF
NIST.SP.800-218.SSDF-table.xlsx

[wangleo61]

https://csrc.nist.gov/Projects/ssdf

[wangleo61]

安全的软件的开发框架非常值得我们静下心来学习，对于促进开源软件的安全会起到很好的指导作用

[wangleo61]

Uploading https:nvlpubs.nist.gov:nistpubs:SpecialPublications:NIST.SP.800-218.pdf…