· 阅读需 142 分钟


The current state of open source software security and methods to address and improve your cybersecurity posture


In Partnership With:



Open source software (OSS) has become an integral part of the technology landscape, as inseparable from the digital machinery of modern society as bridges and highways are from global transportation infrastructure. According to one report, typically 70% to 90% of a modern application stack consists of pre-existing OSS, from the operating system to the cloud container to the cryptography and networking functions, sometimes up to the very application running your enterprise or website. Thanks to copyright licenses that encourage no-charge re-use, remixing, and redistribution, OSS encourages even the most dogged of competitors to work together to address common challenges, saving money by avoiding duplication of effort, moving faster to innovate upon new ideas and adopt emerging standards.

开源软件(OSS)已成为技术领域不可或缺的一部分,就像桥梁和高速公路是全球交通基础设施施密不可分一样,已经和现代社会的数字机器紧密结合在一起。据报告显示,现代应用程序栈通常由 70% 至 90% 的现有开源软件组成,从操作系统到云容器,再到加密和网络功能,甚至是支撑企业或网站运行的应用程序本身。由于版权许可证鼓励免费重复使用、重新混合和重新分发,开源软件鼓励企业合作共同解决共同的挑战,即使是最激烈的竞争对手,也可通过避免重复工作来节省资金,并更快地创新和采用新兴标准。

However, this ubiquity and flexibility can come at a price. While OSS generally has an excellent reputation for security, the communities behind those works can vary significantly in their application of development practices and techniques to reduce the risk of defects in the code, or to respond quickly and safely when one is discovered by others. Often, developers trying to decide what OSS to use have difficulty determining which ones are more likely to be secure than others based on objective criteria. Enterprises often don't have a well-managed inventory of the software assets they use, with enough granular detail, to know when or if they're vulnerable to known defects, and when or how to upgrade. Even those enterprises willing to invest in increasing the security of the OSS they use often don't know where to make those investments, nor their urgency relative to other priorities.

然而,这种普遍性和灵活性是有代价的。 虽然 开源软件通常在安全方面享有盛誉,但这些作品背后的社区在降低代码缺陷风险中的应用开发实践和技术,或在他人发现缺陷时快速安全响应方面可能存在很大差异。 通常情况下,试图决定使用哪种 开源软件的开发人员很难根据客观标准确定哪些 开源软件比其他 开源软件更安全。 企业通常没有对其使用的软件资产进行良好管理的清单,没有足够详细的细节来了解它们何时或是否易受已知缺陷的影响,以及何时或如何升级。 即使那些愿意投资增强其使用的开源软件安全性的企业,也经常不知道在哪些方面进行投资,以及这相对于其他优先事项的紧迫性。

However, fighting security issues at their upstream source - trying to catch them earlier in the development process, or even reduce the chances of their occurrence at all - remains a critical need. We are also seeing new attacks that focus less on vulnerabilities in code, and more on the supply chain itself - from rogue software that uses "typosquatting on package names to insert itself unexpectedly into a developer's dependency tree, to attacks on software build and distribution services, to developers turning their one-person projects into "protest-ware" with likely unintended consequences.

然而,在上游源头上解决安全问题 - 试图在开发过程的早期发现它们,甚至减少它们发生的机会 - 仍然是一个关键的需求。我们也看到了新的攻击,它们较少关注代码中的漏洞,而更多地关注供应链本身 - 从使用“包名称上的域名仿冒将自己意外插入开发人员的依赖树”的流氓软件,到对软件构建和分发服务的攻击,再到开发人员将他们的单人项目变成可能会产生意想不到的后果“抗议软件”。

To address the urgent need for better security practices, tools, and techniques in the open source software ecosystem, a collection of deeply invested organizations came together in 2020 to form the Open Source Security Foundation (OpenSSF), and chose to house that effort at the Linux Foundation. This public effort has grown to include hundreds of active participants across dozens of different public initiatives housed under 7 working groups, with funding and partnership from over 75 different organizations, and reaching millions of OSS developers. This report presents analysis that we intend to use to help support that effort. You can see a complete copy of my prepared testimony at: Testimony to the US House Committee on Science and Technology - Open Source Security Foundation (openssf.org).

为了满足开源软件生态系统中对更好的安全实践、工具和技术的迫切需求,一系列深度投资的组织在 2020 年聚集在一起,成立了开源安全基金会 (OpenSSF),并选择将这项工作设在 Linux 基金会。这项公共努力已经发展到包括数十个不同公共计划的数百名积极参与者,这些计划位于7个工作组下,来自超过75个不同组织的资金和合作伙伴关系,并覆盖了数百万个开源软件开发者。本报告介绍了我们打算用来帮助支持这项工作的分析。您可以在以下位置查看我准备的证词的完整副本:美国众议院科学和技术委员会的证词 - 开源安全基金会(openssf.org)。

Brian Behlendorf


General Manager, Open Source Security Foundation


The Linux Foundation

Linux 基金会

Info Graphic

5.1 Average number of outstanding, critical vulnerabilities in an application. Ranges between 2.6 and 9.5 based on programming language.24% of organizations are confident in the security of their direct dependencies.59% of organizations report their OSS is somewhat or highly secure.
5.1 平均每个应用程序存在的重要漏洞数量。 根据编程语言的不同,重要漏洞数量的范围在 2.6 到 9.5 之间。24% 的组织对它们的直接依赖的安全性感到有信心。59% 的组织报告称,他们的开源软件在一定程度上或高度安全。
68.8 Average dependencies per project. Ranges between 25 and 174 based on programming language.18% of organizations are confident in the security of their transitive dependencies.SCA and SAST tools are the #1 and #2 tools used to address security concerns.
68.8 每个项目的平均依赖项。 根据编程语言的不同,依赖项的数量在25到174之间变化。18% 的企业对其传递依赖项的安全性感到有信心。软件组成分析(SCA)和 静态应用程序安全测试(SAST)工具是解决安全顾虑使用的排名第一和第二的工具。
97.8 Average number of days it takes to fix a vulnerability.49% of organizations have a security policy that addresses OSS.73% of organizations are searching for best practices to improve their software security.
97.8 平均修复漏洞所需的天数。49% 的组织拥有涵盖开源软件安全的安全策略。73% 的组织正在寻找提高软件安全性的最佳实践。
Increased incentives by employer is the #1 approach to improving OSS resourcing.More intelligent tools are the #1 way organizations intend to improve supply chain security.11% Average increase to an organization’s security
score in 2022.
雇主提供更多的激励措施是改善开源软件资源配置的第一途径。更加智能的工具是组织机构试图提高供应链安全性的第一选择。11% 组织在2022年的安全分数平均提高百分比



Open source software (OSS) has had a tremendous impact on the development and distribution of the software we depend on today. Through its collaborative and open way of both developing and sharing software components, OSS has served as a key engine for innovation and encouraged the widespread reuse and sharing of core software components. Today, nearly all applications are composed of components dependent upon other components, creating a supply chain that involves hundreds of components and multitiered dependencies.

开源软件 (OSS) 对我们今天所依赖的软件的开发和分发产生了巨大影响。通过其开发和共享软件组件的协作和开放方式,开源软件已成为创新的关键引擎,并鼓励核心软件组件的广泛重用和共享。 如今,几乎所有应用程序都由依赖于其他组件的组件组成,从而形成了一个涉及数百个组件和多层依赖项的供应链。

Organizations of all sizes are heavily reliant on software, and much of that software supply chain consists of open source software components. Because of this, open source software has cybersecurity implications: the software supply chain is an attractive entry point for people and organizations interested in theft, disruption, or exploitation for economic or political gain. The attack surface today is changing from those in traditional cybersecurity threat models. Defects in small libraries that are widely used across the software ecosystem can cause systemic risk, as we've seen with incidents such as Log4shell.

各种规模的组织都严重依赖软件,其中大部分的软件供应链包含开源软件组件。正因为如此,开源软件具有网络安全的影响:软件供应链是入侵者利用进行盗窃、破坏或为了经济或政治利益而开发的一个有吸引力的入口点。如今,攻击面正在从传统的网络安全威胁模型中改变。在整个软件生态系统中广泛使用的小型库中的缺陷可能会导致系统性风险,正如我们在 Log4shell 等事件中所见到的那样。

Security challenges


Addressing the security of open source software components requires a different approach from traditional approaches of securing proprietary, vendor-supported software. The more loosely structured and community focused nature of OSS development presents a more challenging environment for addressing software security. The distribution of OSS projects is bookended by a small number of large visible projects (like the Linux kernel and Kubernetes) to a very large number of small projects. Smaller projects typically have fewer contributors and resources, and are therefore more likely to adopt a minimalist approach to development and security.


The tremendous benefits and prevalence of OSS in organizational software, combined with the vulnerability of the OSS software supply chain, puts us at a crossroads. Organizations and companies that use open source software need to become more aware of what dependencies they are using, proactively and regularly monitoring all components for usability, trustworthiness, and vulnerabilities. Ultimately, open source software is a two-way street: consumers of open source software must contribute back to the OSS communities to ensure the health and viability of the dependencies they rely on. Merely using open source software, without contributing back, is not enough. What is required is both to 1) incorporate the nature of OSS dependencies into standard cybersecurity and development practices and 2) contribute back to the OSS communities that organizations rely on.


Research approach


This report focuses on OSS security perspectives and how to improve OSS security and sustainability.


Research began in March 2022 with fifteen interviews of open source software maintainers and cybersecurity experts. These qualitative interviews helped to shape the scope of the research and the design of the quantitative survey instrument.

研究始于 2022 年 3 月,进行了 15 次开源软件维护者和网络安全专家的访谈。这些定性访谈有助于塑造研究范围和设计定量调查工具。

A worldwide survey was fielded in April 2022, targeting the following roles:

  • Individuals who contribute to, use, or administer Oss
  • Maintainers, core contributors, and occasional contributors to OSS
  • Developers of proprietary software to use OSS
  • Individuals with a strong focus on software supply chain security

2022 年 4 月,针对以下角色进行了一次全球调查:

  • 贡献、使用或管理开源软件的个人
  • 开源软件的维护者、核心贡献者和偶尔的贡献者
  • 使用开源软件的专有软件开发人员
  • 强烈关注软件供应链安全的个人

The survey included four sections:

  • Screening questions and demographics
  • OSS security perspectives. Sample size is 539 and margin of error (MoE) is +/- 3.6% at a 90% confidence level.
  • OSS best practices for secure software development. Sample size is 72. Only OSS maintainer and core contributors were invited to complete this section of the survey. Because of the technical detail that was characteristic of this section, it was not addressed as part of this report and instead will be discussed in a separate report to be published in 2022 Q3.
  • Improving OSS security. Sample size is 433 and margin of err (MoE) is +/-4.0% at a 90% confidence level.


  • 筛选问题和人口统计学信息
  • 开源软件安全视角。样本量为 539,置信度水平为 90%,误差率(MoE)为 +/- 3.6%
  • 为安全软件开发提供最佳实践。样本量为 72,只邀请了开源软件维护者和核心贡献者完成本部分的调查。由于这一部分的技术细节较多,本报告没有对其进行讨论,将在2022年三季度发表的另一份报告中进行讨论。
  • 改进开源软件安全。样本量为 433,置信度水平为 90%,误差率(MoE)为 +/- 4.0%。

For more information about this research approach and sample demographics, see the methodology section of this paper. The data provided by Snyk is based on over 1.3 million projects and was collected from April 1, 2021 until March 31, 2022. Snyk's efforts were primarily focused on understanding how five key languages/ecosystems (.Net, Go, Java, JavaScript, and Python) are influencing the complexity of the software supply chain. This data was gathered from the use of Snyk Open Source, a static code analysis (SCA) tool free to use for individuals and open source maintainers.

更多有关此研究方法和样本统计信息的信息,请参阅本文的方法部分。 Snyk 提供的数据基于超过 130 万个项目,采集周期为 2021 年 4 月 1 日至 2022 年 3 月 31 日。Snyk 的工作主要集中在了解五种关键语言 / 生态系统(.Net、Go、Java、JavaScript 和 Python)如何影响软件供应链的复杂性上。这些数据是通过使用 Snyk 开源工具收集的,该工具是一个静态代码分析(SCA)工具,供个人和开源维护人员免费使用。

Open source software security perspectives


Initial questions in this survey were designed to understand organizational commitment to security that covers OSS development and use and beliefs about the security of the OSS and its dependencies in use. Responses to these questions suggest that organizations collectively have been slow to make software security a priority.


Many organizations do not have a security policy that covers OSS


One of the most startling findings of this research, as shown in Figure 1, is that only 49% of organizations have a security policy that covers OSS development or use. 34% of organizations indicate that they do not have a security policy for OSS development and usage, and 17% of respondents were not sure if their organization had a plan or not. If we prorate this 17% based on the existing distribution of responses, the number of organizations with a security policy covering OSS rises from 49% to 59%, and those without a policy rise from 34% to 41%.

这项研究最惊人的发现之一是,如图 1 所示,只有 49% 的组织拥有涵盖开源软件开发或使用的安全策略。34%的组织表示,他们没有开源软件开发和使用的安全策略,17%的受访者不确定他们的组织是否有计划。如果将这17%根据现有的回答分布来按比例分配,则拥有涵盖开源软件的安全策略的组织数量从49%上升到59%,而没有策略的组织则从34%上升到41%。

Figure 1

Figure 1: Organizations with a security policy covering OSS


Do you have an open source security policy in place for open source development or usage? (select one)




不知道(英文应该是错了,坐标轴上是Don't know)

Having a security policy covering OSS indicates that you have a security action plan that includes the many OSS components in use. Without a software security policy, organizations may expose themselves to a significant amount of financial and reputational risk because they may not be evaluating software before its inclusion and/or may not be prepared for the inevitable updates due to software vulnerabilities (OSS or not).


Note that we intentionally did not have any special requirements on how the security policy covering OSS was stated. Some organizations have a single policy on software, and then only have specific statements for OSS in the relatively few cases where OSS would be sensibly different. This would be an application of the so-called "Hellekson's Law" ("a more specific policy can be improved for the general case by removing delimiters that narrow the policy scope, "e.g., deleting "open source" from an "open source software" policy typically improves it). For our purposes this is fine. We simply let the respondents identify whatever applied to their organization.

请注意,我们有意没有对涵盖开源软件的安全策略有任何特殊要求。一些组织只有一个关于软件的策略,然后仅在开源软件有相对少的情况下才有特定的声明。这是所谓的“Hellekson 定律”的应用(“通过删除缩小策略范围的分隔符,例如,从“开源软件”策略中删除“开源”,可以改进通用情况下的更具体策略)。对于我们的研究目的来说,这是可以接受的。我们只是让受访者确定他们所在组织适用的情况。

The one benefit of the distribution shown in Figure 1 is that we can statistically compare and contrast the characteristics of organizations with a security policy against those without one. Understanding these comparative differences helps us describe the OSS security journey that organizations are on.

图 1 所示的分布的一个好处是,我们可以对拥有安全策略的组织与没有安全策略的组织进行统计学比较和对比。了解这些比较差异有助于我们描述组织在开源软件安全方面的旅程。

Small organizations shoulder disproportionate OSS security risk


This survey included organizations of various sizes (based on the number of worldwide employees). The survey sample was distributed by organization size as follows: small organizations (44%, 1-499 employees), medium organizations (20%, 500-4,000 employees), large organizations (35%, 5,000+ employees), and 1% don’t know or are not sure.

本次调查涵盖了各种规模的组织(根据全球员工人数划分)。调查样本按组织规模分布如下:小型组织(44%,1-499 名员工),中型组织(20%,500-4,000 名员工),大型组织(35%,5,000 名及以上员工),1% 不知道或不确定。

The measure of security policy covering OSS by organizational size is shown in Figure 2. Immediately noticeable is the difference in distributions between organizations with 1-499 employees and those with 500 employees or more. Just 41% of small organizations have an OSS security policy, compared to 56%-57% of larger organizations. This significant difference indicates that small organizations behave differently than larger organizations when it comes to OSS security policy adoption.

按组织规模衡量涵盖开源软件的安全政策的情况如图 2 所示。立即显着的是,1-499 名员工的小型组织和 500 名员工以上的组织之间的分布差异。只有 41% 的小型组织拥有开源软件安全政策,而大型组织的开源软件安全政策采用率在 56%-57% 之间。这个显著的差异表明,小型组织在开源软件安全政策采用方面的行为与大型组织不同。

Figure 2

Figure 2: A distribution of OSS security policy by organization size

图 2:按组织规模分布的开源软件安全策略

Do you have an open source security policy in place for open source development or usage? (select one) by Enterprise size




Don't know: 

1 to 499 Emp: 
员工数 1~499

500 to 4999 Emp: 
员工数 500~4999

5000+ Emp: 
员工数 5000+

Source: 2022 Open Source Supply Chain Security Survey.

One reason that small organizations are OSS security challenged is economies of size. Small organizations have small IT staff and budgets, and the functional needs of the business often take precedence so that the business can remain competitive. Lack of resources and time were the leading reasons why organizations were not addressing OSS security best practices.

小型组织开源软件安全面临挑战的原因之一是规模经济。小型组织拥有较少的 IT 人员和预算,业务的功能需求通常具有优先性,以使业务能够保持竞争力。缺乏资源和时间是组织未能解决开源软件安全最佳实践的主要原因。

While it is disappointing that 44% of small organizations do not have an OSS security policy, an additional concern is that close to 30% of larger organizations also do not have an OSS security policy. Small organizations can rationalize increased financial, reputational, and legal risk, but this becomes tenuous for medium organizations and insupportable for large organizations with 5000+ employees. Medium and large organizations likewise complain about not enough having resources or time to address OSS security needs. Surprisingly, a lack of awareness about security best practices is more often identified by large organizations as a reason for not attending to OSS security needs than lack of time.

虽然令人失望的是,44% 的小型组织没有开源软件安全策略,但更令人担忧的是,接近 30% 的大型组织也没有开源软件安全策略。小型组织可以理性地解释为增加财务、声誉和法律风险,但对于 5000 多名员工的中型和大型组织来说,这变得岌岌可危。中型和大型组织同样抱怨没有足够的资源或时间来应对开源软件安全需求。令人惊讶的是,大型组织更常常将缺乏安全最佳实践的意识视为不关注开源软件安全需求的原因,而不是时间不足。

Many Organizations score poorly on OSS security


We asked organizations how secure their open source software is today. Responses to this question are shown in Figure 3. Overall, 59% of organizations feel their OSS is either somewhat secure or highly secure. For organizations with an OSS security policy, this value rises to 70%. It falls to 45% for organizations without a security policy.

我们询问了组织关于他们的开源软件安全性的评估。这个问题的回答如图 3 所示。总体而言,59% 的组织认为他们的开源软件在某种程度上是安全的或者非常安全的。对于有开源软件安全策略的组织,这个比例上升到了 70%。而对于没有安全策略的组织,这个比例则下降到了 45%。

Figure 3

Figure 3: OSS security today

图 3:当今的开源软件安全情况

How secure is your open source software today? (select one) by Do you have an open source security policy in place for open source development or usage?


Weighted Avg of responses
Score range: 0 -100





Highly Insecure:

Somewhat Insecure:

Neither Insecure or Secure:

Somewhat Secure:

Highly Secure:

Don’t Know:

Source: 2022 Open Source Supply Chain Security Survey.

A simple weighted average of all responses shows a composite score of 65 for all organizations, which is a poor grade. Organizations with an OSS security policy score a 70, and organizations without a policy score a 58.

简单的加权平均所有回答的分数显示,所有组织的综合分数为 65 分,这是一个不好的分数。拥有开源软件安全策略的组织得分为 70 分,而没有策略的组织得分为 58 分。

The secure development of OSs is also at risk


Similarly, Figure 4 shows how secure the process for developing or using OSS is today. Using the same responses shown in Figure 3, the results are nearly identical. Across all organizations, 59% believe that their development processes are somewhat secure or highly secure. This value rises to 73% for organizations with an OSS security policy and falls to 47% for organizations without.

同样,图 4 展示了开发或使用开源软件的过程的安全性。使用图 3 中展示的相同回答,结果几乎相同。在所有组织中,59% 的人认为他们的开发过程是相对安全或高度安全的。对于拥有 OSS 安全策略的组织,这个值升至 73%,而对于没有安全策略的组织,则下降至 47%。

Figure 4: Security of OSS development and use today

图 4:如今的开源软件开发和使用的安全性

How secure is your process for developing or using open source software today? (select one) by Do you have an open source security policy in place for open source development or usage?


Figure 4

Weighted Avg of responses
Score range: 0 -100





Highly Insecure:

Somewhat Insecure:

Neither Insecure or Secure:

Somewhat Secure:

Highly Secure:

Don’t Know:

Source: 2022 Open Source Supply Chain Security Survey.

The similarity of this distribution when compared to Figure 4 also yields a weighted average of 65 and organizations with the security policy score 71 and organizations without a policy 58.

与图 4 相比,这个分布的相似性也产生了一个加权平均值为 65,安全策略得分为 71,没有策略的组织得分为 58。

Across organizations, there is a belief that the security of OSS development and use will improve to a weighted average score of 72 by the end of 2022 and 77 by the end of 2023. Later in this report, you will see that an organizational cornerstone of their OSS security strategy is for the vendor community to provide security tools with greater intelligence. Other key elements of their OSS security strategy include a more complete understanding of best practices for secure software development and greater CI/ CD automation to eliminate manual actions and opportunities that expose the pipeline to security risks.

跨组织而言,人们认为到 2022 年底,OSS 开发和使用的安全性将提高到加权平均分数为 72,到 2023 年底将提高到 77。在本报告的后面部分,您将看到,组织制定的 OSS 安全策略的基石是让供应商社区提供更具智能的安全工具。他们的 OSS 安全策略的其他关键要素包括更全面地了解安全软件开发的最佳实践,并实现更多的 CI / CD 自动化以消除手动操作和可能导致安全风险的机会。

Who drives OSS security policies?


Figure 5 superficially creates a conundrum: how do organizations without a top-down OSS security policy have people responsible for defining OSS security policy? Additionally. not having an OSS security policy doesn't mean that groups aren't addressing OSS security in ad hoe ways.

图 5 表面上制造了一个难题:没有由上而下的开源软件安全策略的组织如何有负责定义开源软件安全策略的人?此外,没有开源软件安全策略并不意味着各组没有以临时方式解决开源软件安全问题。

Across organizations, just 31% vest responsibility for defining an OSS security policy in the hands of a CIS and/or security team. The second leading choice of multiple teams at 16% suggests that instead of policy being established by a CIS, it evolves across the Software Development Life Cycle (SDLC) based on the focus of the team. Because a security focus should exist across the CI/CD pipeline, multiple teams are needed to implement OSS security policy. Reliance on open source maintainers at 13% overall can be workable 1f the maintainers are either part of the organization or known to the organization - but it sdems recklessly optimistic to put trust in OSS projects with unknon provenance.

跨组织而言,仅有 31% 的组织将定义 OSS 安全策略的责任归属于 CIS(计算机信息安全)和 / 或安全团队。16% 的多个团队作为第二选择表明,政策的制定不是由 CIS 确定的,而是根据团队的重点在软件开发生命周期 (SDLC) 中逐步形成。由于在 CI/CD 管道中应存在安全重点,因此需要多个团队来实施 OSS 安全策略。总体上依赖于开源维护者的 13% 可能是可行的,前提是维护者要么是组织的一部分,要么已知于组织,但是如果信任来源未知的 OSS 项目,这种做法似乎过于乐观。

Figure 5

Figure 5: Responsibility for OSS security policies
Who is responsible for defining your open source security policy? (select one) by Do you have an open source security policy in place for open source development or usage?





Security team and /or CISO:

Multiple teams:

Open source maintainers:

No one:

Developer or care contributor:

Operations or Bite Reliability Engineers (SREs):

Contributors from other teams:

Don’t Know:

Source: 2022 Open Source Supply Chain Security Survey.

The percentages in Figure 5 are especially revealing. Across organizations with an OSS security policy, 80% vest the definition of an OSS security policy with the CISO/security team, multiple teams, or open source maintainers. This contrasts with organizations without an OSS security policy where 40% of these same groups are involved with OSS security in some capacity.

在图 5 中的百分比特别说明了问题。在有开源安全策略的组织中,80%的组织将开源安全策略的定义授予CISO/安全团队、多个团队或开源维护人员。这与没有开源安全策略的组织形成对比, 在没有开源安全策略的组织中,同样的团队有40%以某种方式参与开源安全。

Perhaps one positive indicator in Figure 5 is that only 30% of organizations without an OSS security policy admit that no one is addressing OSS security. This means that 70% of these organizations are addressing OSS security in part through ad hoc means, suggesting that organizations without an OSS security policy are not completely adrift and have some grassroots activities to address OSS security needs.

或许在图 5 中令人欣慰的一个指标是,仅有 30% 的没有开源安全策略的组织承认没有人在处理开源安全。这意味着 70% 的这些组织通过一些临时手段部分地解决了开源安全问题,表明没有开源安全策略的组织并非完全漂泊无助,有一些基层活动来解决开源安全需求。

Organizations are not effectively managing the security of their dependencies


Dependencies are a characteristic of modern development. Direct dependencies are typically components or services called directly by your code. Indirect or transitive dependencies are essentially dependencies of your dependencies (in typically many tiers).


Vulnerabilities exist in component code for many reasons. Contributing factors include the programming language used, the CI/CD process in use, the education and skill of the developer in developing secure software, and the scope of testing. Complicating matters is that vulnerability management is not a perfect science. Vulnerability scanning normally identifies many false positives based on the information available to the scanning tool. Conversely, an actual vulnerability in a component may not matter if the code linked to the vulnerability is never executed and/or will only provide trusted data to the vulnerable code.

组件代码存在漏洞的原因有很多。其中的因素包括使用的编程语言、使用的 CI/CD 过程、开发人员在开发安全软件方面的教育和技能以及测试的范围。复杂化问题的是,漏洞管理并不是一门完美的科学。漏洞扫描通常会基于扫描工具可用的信息识别出很多误报。相反,如果与漏洞相关的代码从未被执行,或者只会向漏洞代码提供可信数据,那么组件中的实际漏洞可能就不重要了。

What is known is that organizations are not well-positioned to manage their vulnerabilities. Only one response in Figure 6 indicates that organizations are confident in the security of their direct dependencies.


Figure 6

Figure 6: Vulnerability concerns across direct dependencies
图 6:对直接依赖项的漏洞担忧

How concerned are you that the direct dependencies your software relies on might be malicious or compromised? (select one) by Do you have an open source security policy in place for open source development or usage?




Source: 2022 Open Source Supply Chain Security Survey.

Direct dependencies are easy to track but we struggle with indirect dependencies

We don’t have good controls to address this & it concerns me

We have strong controls & I’m confident in the security of our direct dependencies

We don’t have good controls to address this but it doesn’t concern me

Don’t Know:

Across all organizations, only 24% have confidence in the security of their direct dependencies. This value rises to 36% for organizations that have an OSS security policy but falls to just 9% of organizations without such a security policy. Organizations reporting that dependencies are easy to track (37%) may be correct in understanding their dependencies, but this doesn't mean that these dependencies are collectively secure.

所有组织中,只有 24% 的组织对其直接依赖项的安全性感到有信心。对于有开源安全策略的组织,这个值上升到 36%,但对于没有安全策略的组织,这个值只有 9%。 报告依赖项项易于跟踪的组织(37%)可能正确地理解了它们的依赖项,但这并不意味着这些依赖项总体上是安全的。

Snyk - Dependencies drive complexity

Snyk - 依赖关系驱动复杂性

Dependencies are one of the key components driving much of the conversation about the software supply chain. Professionals in both development and security teams are increasingly aware that securing their enterprise does not depend entirely on their organization. Instead, we are having to look further and further, down the rabbit hole of "Where did this code come from?" It's hard enough to understand where everything originated when you're trying to test code written in-house. When you add dependencies two, three, or more levels deep, it becomes daunting to even consider the problem.


The libraries we call in our code, the code snippets we pull from the internet, and the tools we include in container configurations are all examples of direct dependencies. In each of these cases we are relying on third-party code explicitly to fulfill a specific need or purpose.


Measuring the number of dependencies per project, therefore, makes a good starting point for understanding how complex the problem of tracking dependencies really is. As shown in Figure 7, the average number of dependencies per project stretches from Python, with 25 dependencies per project, to JavaScript's 173 per project.

因此,衡量每个项目的依赖关系数量是了解跟踪依赖关系问题的复杂性的好起点。如图 7 所示,每个项目的平均项数量从 Python 的 25 个到 JavaScript 的 173 个不等。

Does that mean JavaScript is inherently more complex than .Net (49 dependencies), Go (56 dependencies), or Java (40 dependencies)? Not necessarily. In the case of JavaScript, each dependency often has a single purpose and small scope, rather than a library that fulfills multiple purposes with a large scope.

这是否意味着 JavaScript 本质上比 .Net(49 个依赖项)、Go(56 个依赖项)或 Java(40 个依赖项)更复杂?不一定。在 JavaScript 的情况下,每个依赖项通常只有一个目的和小的范围,而不是一个具有大范围的多个目的的库。

Neither approach is more or less secure than the other but knowing which dependencies you rely on (and how trustworthy they are) is an important part of vulnerability management. Sadly, only 24% of the respondents in this survey felt they had strong controls in place to handle the security of their dependencies.

这两种方法都不比另一种更安全,但了解你依赖的依赖项(以及它们的可信度)是漏洞管理的重要组成部分。不幸的是,在此次调查中,只有 24% 的受访者认为他们已经采取了强有力的措施来处理其依赖项的安全性。

Figure 7

Figure 7: Average dependency count per project by language
图 7:按语言每个项目的平均依赖项数量


Source: 2022 Open Source Supply Chain Security Survey.

Average dependencies per project

Recent efforts by the US Government to encourage, and even mandate, organizations to create a Software Bill of Materials (SBOM) is evidence of how important it is to have a handle on dependencies. Tracking direct dependencies is a significant issue by itself. Indirect, or transitive, dependencies mark the real start of complexity. Each of the libraries referenced in a project incorporates additional code to perform its own function, and each of those third-party libraries may rely on other libraries as well. Organizations who want a complete accounting of their transitive dependencies should be requiring SBOMs from their suppliers and investing in tools to consume these SBOMs.

美国政府最近鼓励甚至强制要求组织创建软件清单(SBOM)的努力,证明了掌握依赖项关系的重要性。追踪直接依赖项本身就是一个重大问题。而间接或传递性依赖项才是复杂性的真正开始。每个在项目中引用的库都会包含额外的代码来执行其自身的功能,而每个这样的第三方库可能也依赖于其他库。想要完整记录传递依赖关系的组织应该要求其供应商提供 SBOM,并投资于消费这些 SBOM 的工具。

Figure 8 is patterned directly after Figure 6, except that it focuses on transitive dependencies. Transitive dependencies are objectively more difficult to evaluate as the level of dependency increases. The result is that fewer organizations believe that their transitive dependencies are secure

图 8 直接复制了图 6 的结构,不过它专注于间接依赖项。随着依赖程度的增加,间接依赖项的评估变得更加困难,因此,越来越少的组织认为它们的间接依赖项是安全的。

Figure 8

Figure 8: Vulnerability concerns across transitive dependencie
图 8:跨传递依赖项的漏洞问题

How concerned are you that the indirect (transitive) dependencies your software relies on might be malicious or compromised? (select one) by Do you have an open source security policy in place for open source development or usage?
您担心您的软件间接(传递)依赖项可能存在恶意或被攻击的风险吗? (选择一项) 您是否为开源开发或使用制定了开源安全策略?

Figure 8 shows that just 18% of organizations are confident in the security of their transitive dependencies. Once again, this value rises to 27% for organizations that have an OSS security policy but plummets to just 5% for organizations without a security policy.

图 8 显示,只有18%的组织对其传递依赖项的安全性有信心。同样,这个值对于制定了开源安全策略的组织上升至27%,但对于没有安全策略的组织则下降至5%。

A recent discussion with David A. Wheeler, a leading authority on OSS security, yielded this insight, "I think many organizations often don't update their OSS software, even when the older version of the OSS has widely-known vulnerabilities. That's not unique to OSS, many organizations also often don't update old versions of proprietary software with widely-known vulnerabilities

与开源软件(OSS)安全方面的权威专家大卫·A·惠勒(David A. Wheeler)的最近一次讨论得出了这样的见解:“我认为许多组织经常不更新他们的开源软件,即使旧版本的开源已经被广泛知晓的漏洞所影响。这不仅仅是开源的问题,许多组织也经常不更新旧版本的专有软件,而这些软件也有广泛已知的漏洞。”

Snyk - Dependency creates vulnerability

Snyk - 依赖关系创建了漏洞

How many vulnerabilities are there in my project? We estimated this by totaling known vulnerabilities in a particular project combined with the known vulnerabilities of its dependencies (presuming that the vulnerabilities in the dependencies were exploitable). The Net projects in our data had 23 vulnerabilities per project on average, with Go at 34, Java at 90, JavaScript having 47, and Python at 36. This covers both errors introduced in development and vulnerabilities in transitive dependencies. According to Snyk's data, approximately 40% of all vulnerabilities are from these transitive dependencies. We further broke down the count of vulnerabilities per project in Figure 9 to highlight the effect of severity by language.

我的项目中有多少漏洞?我们通过汇总一个特定项目中已知的漏洞以及其依赖项的已知漏洞数量来估计。假设依赖项中的漏洞是可利用的。我们的数据中,.Net 项目平均有 23 个漏洞,Go 项目有 34 个漏洞,Java 项目有 90 个漏洞,JavaScript 项目有 47 个漏洞,Python 项目有 36 个漏洞。 这包括开发中引入的错误和传递依赖项中的漏洞。根据 Snyk 的数据,大约 40% 的漏洞来自这些传递依赖项。我们在图 9 中进一步分解了每个语言的漏洞计数,以凸显严重性的影响。

A large part of the value of SCA tools is finding where vulnerabilities are being introduced by the use of known bad libraries. Is your code incorporating an older version of a library with known vulnerabilities? Is the package still maintained or is it abandoned? Did you accidentally get a library pretending to be the one you actually wanted? These are just a few of the potential issues that could get a package flagged.

SCA 工具的很大一部分价值在于发现由于使用已知存在漏洞的库所引入的漏洞。您的代码是否正在使用一个存在已知漏洞的旧版库?该软件包是否仍在维护中或已被放弃?您是否意外获取了一个假冒您实际需要的库?这些也只是可能会导致软件包被标记的一些潜在问题。

Knowing the number of vulnerabilities in your own project helps you understand how your efforts compare to global numbers. Organizations that see data far different from the baseline number of vulnerabilities in a project can investigate the causes of a disparity. It could be as simple as different ways of measuring the same metric. On the other hand, the difference in numbers could indicate poor coding practices or a large number of old libraries being part of a standard. Without policies and standards that require vulnerability tracking, you may never know.


Figure 9: Average count of vulnerabilities by language and severity

图 9:按语言和严重程度划分的平均漏洞数量

Figure 9

Vulnerability Severity






Source: 2022 Snyk user data.
来源:2022年 Snyk 用户数据。

Tracking vulnerabilities introduced by transitive dependencies is one of the hardest challenges in DevOps today. Think about a project that has fifty dependencies; if the average project has five critical vulnerabilities, just the first level of dependencies could lead to 200+ critical vulnerabilities. Each layer down expands the problem dramatically. Luckily, most vulnerabilities are tightly constrained by the factors needed to exploit them.

跟踪由传递依赖引入的漏洞是当今 DevOps 面临的最大挑战之一。考虑一个有 50 个依赖项的项目;如果平均每个项目有 5 个严重漏洞,那么仅第一级依赖关系就可能导致 200 多个严重漏洞。每一层依赖都会大大扩大问题的规模。幸运的是,大多数漏洞都受到利用所需因素的严格限制。

How organizations are addressing and prioritizing their cybersecurity needs


A key finding of this research is that security, as it applies to OSS, is a rapidly evolving domain. Each of the primary threat vectors (source threats, build threats, and dependency threats) identified in the SLSA (Supply Chain Levels for Software Artifacts) model will require multiple actions on the part of most organizations to address. However, because OSS security is also rapidly evolving, increased functionality and tool consolidation should help reduce the complexity that organizations face in addressing software supply chain security needs.


This section of the report describes how organizations are addressing how vulnerabilities in code are found, how security of OSS components is evaluated, what security-focused tools are being used, and what security-related activities are most important.


Figure 10

Figure 10: Finding vulnerabilities in your dependencies
How do you find out about vulnerabilities in your dependencies? (select all that apply) by Do you have an open source security policy in place for open source development or usage?

图表 10:发现依赖项中的漏洞

Source: 2022 Open Source Supply Chain Security Survey.
来源:2022 年开源供应链安全调查。

Industry vulnerability notifications

Automated monitoring of packages for known vulnerabilites

Notifications form package maintainers

Industy blogs and news site

Through an external security audit

We find out when they are exploited in the wild

Trust groups


Don’t Know

Organizational approaches to identifying vulnerabilities in dependencies


A common question in addressing OSS security is how to comprehensively identify vulnerabilities across your dependencies. Figure 10 shows that there are four commonly used techniques to identify vulnerabilities. The leading approach practiced by 53% of organizations is to subscribe to one or more vulnerability catalogs from CISA (US-CERT), NIST (NVD), MITRE (CVE), security product & service vendors, and/or catalog aggregators (like FIRST) that aggregate content from leading worldwide sources. These subscriptions have the advantage of pushing vulnerability notifications to their subscribers.


The second leading approach is automated monitoring — or scanning of packages for known vulnerabilities — and is practiced by 49% of organizations. One challenge with this approach is that it’s often difficult to map vulnerability reports to the component(s) containing the vulnerabilities. For example, there may be a vulnerability reported in some component foo, but often there are many components and forks named foo so users often can’t be confident when a report is relevant. While it’s a best practice to scan code formulaically based on time, changes to the code base and the identification of relevant vulnerabilities, a comprehensive approach to this technique is still on the horizon.


Notifications from package maintainers are leveraged by 47% of organizations and can provide a conduit to keep packages updated when supported by maintainers. Industry blogs and news sites are used by 43% of organizations and can facilitate the timely delivery of information for a better sense of importance.


Snyk - How long will it take to fix?

Snyk - 需要多长时间来修复?

Once a vulnerability has been identified, the next logical question is “How long is this going to take to fix?” The answer is all too often, “I don’t know. It’s complicated.” Unsurprisingly, the question becomes even more complex when we apply it to the software supply chain. Our dependence on third-party code, especially transitive dependencies, often make that question difficult or impossible to answer.

一旦发现漏洞,下一个合理的问题是“修复需要多长时间?” 答案往往是:“我不知道。这很复杂。” 不出所料,当我们将其应用于软件供应链时,这个问题变得更加复杂。我们对第三方代码的依赖,尤其是传递依赖,经常使得这个问题难以或不可能回答。

Looking at the average time to fix by language in Figure 11, we see that Snyk’s data shows that Go has the best time to fix at 49 days, while .Net is the obvious laggard at 148 days to fix a vulnerability. While some maintainers might be able to fix vulnerabilities in days or hours, there have been a few vulnerabilities that took years to remediate.

观察图 11 中按语言分组的平均修复时间,我们可以看到 Snyk 的数据显示 Go 语言具有最佳的修复时间,为 49 天,而 .Net 则是明显的落后者,需要 148 天来修复漏洞。虽然一些维护者可能能够在几天或几小时内修复漏洞,但也有一些漏洞需要数年时间才能修复。

Figure 11

Figure 11:
Average time to fix by language

图 11:


Source: 2022 Snyk user data.
来源:2022 年 Snyk 用户数据。

We expect that popularity and awareness influence the time to fix. A popular project is more likely to attract other collaborators, and additional collaborators can speed up incident response time. In addition, if a project is popular, awareness by users (including via technical press news) is likely to be larger.


A popular project can affect a significant portion of all projects. As an example, the Spring Framework library is found in 9% of all Java projects. The team responsible for Spring Framework responded quickly to fix the Spring4Shell remote code execution vulnerability when it was identified in the spring of 2022. But what if that vulnerability had existed in a less responsive yet popular package?

一个受欢迎的项目可能影响所有项目的重要部分。例如,Spring 框架库在所有 Java 项目中都有 9%的使用率。当在 2022 年春季发现 Spring4Shell 远程代码执行漏洞时,负责 Spring 框架的团队迅速做出了修复。但如果该漏洞存在于一个反应较慢但受欢迎的软件包中会怎样呢?

Figure 12

Figure 12: Finding vulnerabilities in your code
How do you find out about security vulnerabilities in your code? (select all that apply) by Do you have an open source security policy in place for open source development or usage?

图 12:发现代码中的安全漏洞

We find them in CI when a SAST tool runs
我们在 CI 中运行 SAST 工具时发现它们

We find them when using Software Composition Analysis (SCA) tools or services

We find them in our IDE using an extension for static code analysis
我们在 IDE 中使用静态代码分析扩展程序时发现它们

They get identified during peer review

Publication in the National Vulnerability Database

We use a command-line tool to detect them

Through an external security audit

We find out when they are exploited in the wild

Bug bounties help disclose them

We don’t


Don’t Know

Organizational approaches to identifying vulnerabilities in code


Finding security vulnerabilities in code requires multiple approaches, much like finding vulnerabilities in dependencies. Figure 12 identifies the leading ways that developers find security vulnerabilities. The leading approach used by 39% of organizations, of the options included in the survey, is to use a SAST (Static Application Security Testing) tool. SAST tools are immensely useful during development because they can be configured to run automatically as part of a CI (continuous integration) process and can often identify specific line(s) of code responsible for a vulnerability.

发现代码中的安全漏洞需要多种方法,就像发现依赖项中的漏洞一样。 图表 12 显示了开发人员发现安全漏洞的主要方式。在调查包括的选项中,39% 的组织使用 SAST(静态应用程序安全测试)工具,这是最常用的方法。SAST 工具在开发过程中非常有用,因为它们可以配置为作为 CI(持续集成)过程的一部分自动运行,并且通常可以确定负责漏洞的具体代码行。

The second leading approach practiced by 33% of organizations, among the survey options, is to use an SCA (software composition analysis) tool. Use of these tools can be automated, and they typically address manifest scanning and binary scanning to identify known security vulnerabilities, licensing issues, or quality problems. While this capability is more closely associated with finding vulnerabilities in dependencies, including SCA in the build process helps OSS security activities to shift left.


Finally, a SAST tool can be used within an IDE providing the developer with a more immediate, hands-on, and configurable approach to manual security testing. What this approach lacks in automation is more than compensated for in direct and timely developer involvement. Figure 12 shows that 30% of organizations leverage this approach.

最后,SAST工具可以在集成开发环境(IDE)中使用,为开发人员提供更直接、及时和可配置的手动安全测试方法。虽然这种方法缺乏自动化,但直接且及时的开发人员参与可以弥补这一不足。图12显示,30% 的组织利用这种方法。

Although just 29% of organizations use peer review to help identify vulnerabilities in code, peer review and a reliance on multifunctional teams is a best practice and cornerstone of agile development.


Although this particular survey question did not offer tool choices other than SCA and SAST, Figure 14 does and confirms the leading popularity of SCA and SAST tools.

尽管此项调查问题未提供除SCA和SAST之外的工具选择, 但图14提供了其他工具的流行度, 并确认了SCA和SAST工具的领先流行度。

Snyk - Dependencies in the real world

Snyk - 现实中的依赖关系

When talking about direct and transitive vulnerabilities, the actual pervasiveness of transitive vulnerabilities is easy to overlook or dismiss. As observed earlier, nearly 40% of the vulnerabilities we detect originate in third-party code. Two examples of recent, high profile vulnerabilities, Log4Shell and Spring4Shell, give us an opportunity to compare the nature of direct vs. transitive dependencies in the real world.

当谈到直接和传递性漏洞时,我们容易忽视或忽略传递性漏洞的实际普遍性。正如先前观察到的,检测到的近40%的漏洞源于第三方代码。最近出现的两个备受关注的漏洞 “Log4Shell” 和 “Spring4Shell” 为我们提供了比较现实世界中直接依赖和传递性依赖性质的机会。

Last Christmas, Log4Shell was the bane of security teams and developers across the globe. The log4j-core project has been used extensively to enable logging in millions of projects. Because of this, nearly 52% of the vulnerabilities we detected were present because of a direct dependency on the log4j-core code base. (It’s important to note that we counted direct dependencies first, so a project with both direct and indirect dependencies would be counted as direct.)

去年圣诞节,Log4Shell 是全球安全团队和开发人员的噩梦。log4j-core 项目已被广泛使用,在数百万项目中启用日志记录功能。由于这个原因,我们发现的近52%的漏洞存在于直接依赖 log4j-core 代码库的项目中。(需要注意的是,我们首先计算直接依赖项,因此既有直接依赖项又有间接依赖项的项目将被视为直接依赖项。)

In contrast to Log4j, over 90% of the Spring Framework core was transitive, called by code one layer or more removed from the developer. The Spring Framework can be described as the ‘plumbing of enterprise applications’, which helps explain why it’s a transitive dependency so often. This is a very common example of how vulnerable code gets incorporated into projects, and why it’s important to track transitive vulnerabilities.

与 Log4j 相比,超过90%的Spring框架核心是传递性的,Spring框架由代码调用而距离开发人员一层或更多层。Spring 框架可以被描述为“企业应用程序的管道”,这有助于解释为什么它经常是一个传递性依赖项。这是一个非常常见的漏洞代码被纳入项目的例子,也是为什么跟踪传递性漏洞很重要的原因。

Prerequisites to using OSS


Using open source components can help to reduce cost, speed time to market, and free staff up to engage in more innovation and value- added activities. There is no “right way” to evaluate the security of OSS packages, but Figure 13 indicates that on average organizations use three of the approaches listed.

使用开源组件可以降低成本,加速产品进入市场的时间,以及释放员工从事更多的创新和增值活动。虽然评估开源软件包的安全性没有“正确的方法”,但是图 13 表明了组织平均使用列出的三种方法。

The most common approach used by 44% of organizations is to have developers examine source code. A review of source code can speak volumes about the quality of the code, which is highly correlated with its security.


A second approach relied on by 40% of organizations is to assess the community that supports the project or component. An active community and an organized approach to contribution and maintainership are seen as positive signs for a project.


The third most popular strategy, observed at 36% of organizations, is using third-party tools to help developers find and vet components.

第三种最受欢迎的策略,在36% 的组织中观察到,是使用第三方工具来帮助开发人员查找和审核组件。

A variety of additional manual activities are used by organizations, including reviewing the frequency of releases/ commits (35%), analysis of registry/package manager information (33%), and reviewing usage statistics such as repository ratings or download statistics (30%). These help establish the viability and commitment of the community to the component.


Figure 13

Figure 13: Reviewing the security of OSS packages
图 13:审查开源软件包的安全性

How do you check the security of the open source packages that you use? (select all that apply)

Source: 2022 Open Source SupplyChainSecuritySurvey.
来源:2022 年开源供应链安全调查。

We use tools to examine its source code

We check that the project has an active community

We use a tool like Snyk Advisor, Libaries.io, or similar tools to serach for open source packages
我们使用像 Snyk Advisor、Libraries.io 或类似的工具搜索开源包

We look at the frequency of releases/ commits/ etc.
我们查看发布 / 提交等的频率

We use the information in the registry or package manager

We look at repository ratings or package downloads statitics

We manaually review/ inspect its source code

We check  that the project has a responsible disclosure policy (such as a SECURITY.md)
我们检查该项目是否有负责任的披露策略(例如 SECURITY.md)

We ask others if they believe the security of the project is adequate

We don’t check it

Don’t Know

Using multiple security testing tools is an OSS best practice


On average, organizations in the study used between two and three security testing tools. Using third-party tools can significantly improve your OSS security posture because of their scope, scalability, automation potential, and coverage across the SDLC. As budgets, resources, and time allows; using more tools can be advantageous since they all add value in different ways.

平均而言,研究中的组织使用了两到三种安全测试工具。使用第三方工具可以显著改善您的 OSS 安全状况,因为它们的范围、可扩展性、自动化潜力和覆盖整个 SDLC。在预算、资源和时间允许的情况下, 使用更多工具可能是有利的,因为它们都以不同的方式增加价值。

Figure 14 shows that preference is higher for SCA tools (47%) than for any other tool category. The ability of SCA tools to identify vulnerabilities and license compliance across an organization’s portfolio of components and dependencies, in a highly automated way, is immensely valuable.

图 14 显示,对 SCA 工具的偏好高于任何其他工具类别(47%)。SCA 工具在高度自动化的方式下,可以识别组织组件和依赖项组合中的漏洞和许可证合规性,这是极其有价值的。

Figure 14: Security tools in use when developing OSS

图 14:在开发 OSS 时使用的安全工具

What security tools do you regularly use when developing open source software? (select all that apply) by Do you have an open source security policy in place for open source development or usage?


Figure 14

Software Composition Analysis (SCA) tools

Static Application Secuirty Testing (SAST) tools
静态应用程序安全性测试 (SAST) 工具

Infrastructure as Code (IaC) tools
基础设施即代码 (IaC) 工具

Web Applications Scanners
Web 应用程序扫描器

Security Test Cases in software quality testing

Infrastructure as Code scanners

Fuzz Testing tools

Threat modeling tools

Cloud Secruity Posture Mgmt (CSPM)


Don’t Know

Other than SCA tools, additional choices become complex based on the organization’s approach to DevOps and preferences regarding security testing. SAST tools (37%), IaC tools (36%), and web application scanners (32%) all effectively compete for developer and security team attention. Web application scanners and fuzz testing tools together make up the dynamic application security testing (DAST) tool domain. Realistically, the use of both SAST and DAST tools makes sense because both help organizations find vulnerabilities. However, IaC tools are invaluable in helping to script and automate CI/CD activities, eliminating many of the manual and ad hoc activities that consume time that could be better spent elsewhere.

除了 SCA 工具之外,根据组织的 DevOps 方法和安全测试偏好,其他选择会变得复杂。SAST 工具 (37%)、IaC 工具 (36%) 和 Web 应用程序扫描程序 (32%) 都有效地争夺了开发人员和安全团队的注意力。Web 应用程序扫描程序和模糊测试工具共同构成了动态应用程序安全测试 (DAST) 工具域。实际上,同时使用 SAST 和 DAST 工具是有意义的,因为两者都可以帮助组织发现漏洞。但是,IaC 工具在帮助编写脚本和自动化 CI/CD 活动方面非常宝贵,消除了许多耗时的手动和临时活动,省下的时间可以更好地花在其他地方。

An honorable mention goes out to the remaining tools on the list. Some of these tools are relatively new, but each of them offers a unique value proposition that adds value to improving OSS security.


Examining the tool use profiles of organizations with a security policy versus those without provides an overview of where organizations often start their OSS security journey, and what this journey looks like as it matures.


The most important ways to improve OSS security


The data in Figure 15 is likely the most important collection of key findings in this report. When asked which of the following activities are important to improving the security of OSS, organizations were permitted to give multiple responses.

图 15 中的数据可能是本报告中最重要的关键发现集合。当被问及以下哪些活动对提高开放源码软件的安全性很重要时,允许各组织作出多重回答。

The most important activity — confirmed by 59% of organizations — identified a desire to have vendors add increased intelligence to, and to be responsible for, security tooling. There are two ways to interpret what this means. The first is that end user organizations view the vendor community as a force multiplier, because more intelligent tools can ease the burden on developers or security professionals in exchange for licensing fees. Organizations and vendors both perceive this as a win-win scenario assuming competitive market dynamics. An alternative way to interpret this is that end-user organizations are struggling to understand how to address security concerns and welcome the opportunity to share/grant this responsibility to vendors and service providers who have more extensive expertise.

最重要的活动, 得到59%的组织证实, 确定了让供应商增加安全工具智能并负责安全工具的愿望。有两种方法可以解释这意味着什么。第一种解释是,最终用户组织将供应商社区视为力量倍增器,因为更智能的工具可以减轻开发人员或安全专业人员的负担,以换取许可费。假设市场动态竞争激烈,组织和供应商都认为这是一个双赢的局面。另一种解释方式是,最终用户组织正在努力了解如何解决安全问题,并乐于与具有更广泛专业知识的供应商和服务提供商共享 / 授权这种责任。

Another way to look at this is that end user organizations have scarce resources, and more intelligent tools are expected to provide higher value in a transparent way (meaning having no or inconsequential impact on developer productivity). This is the most seamless way to improve software security without material changes to process models.


The second most important activity is to source comprehensive best practices/certifications for secure software development (cited by 52% of organizations). The strong interest by end user organizations in best practices for secure software development is exciting to see. This suggests that these organizations are invested in understanding how to address OSS security. The good news is that there are already several trusted sources who can address this need:

  • There are a variety of sources to identify best practices/ certifications for evaluating projects themselves. This includes the OpenSSF Best Practices badge, the OpenSSF Scorecards project, the CNCF paper on best practices for supply chain security, and SLSA (https://slsa.dev)
  • This also suggests an interest in encouraging developers to learn best practices & acquire certifications. The good news is that these are available. For example, OpenSSF’s developing secure software (LFD121) provides both a training course and certification of completion for individuals who pass the final exam. This course is sponsored by the OpenSSF which is part of the Linux Foundation.


  • 有多种来源可以确定评估项目本身的最佳实践/认证。这包括OpenSSF最佳实践徽章,OpenSSF记分卡项目,CNCF关于供应链安全最佳实践的文件和SLSA(https://slsa.dev)。
  • 这也表明鼓励开发人员学习最佳实践和获得认证的兴趣。好消息是这些都可用。例如,OpenSSF 的安全软件开发(LFD121)提供培训课程和通过期末考试获得认证的个人证书。该课程由 OpenSSF 赞助,是 Linux 基金会的一部分。

Figure 15: Activities for improving the security of open source software

图 15:改善开源软件安全的活动

Which of the following activities are important to improving the security of the open source software supply chain? (select all that apply)


Figure 15

Added intelligence to existing software security tools (SAST, DAST, SCA, SBOMs, IaC scanners, CSPM)
增加软件安全工具的智能化(SAST,DAST,SCA,SBOM,IaC 扫描程序,CSPM)

Comprehens ive best practices/ certification for secure software development
全面的安全软件开发最佳实践 / 认证

More automation to eliminate pathways to compromise security and reduce developer fatigue

Security audits

Increased incentives by employers to contribute to open source projects

Peer review of source code

Required use of MFA by developers and releasers

Vulnerability reporting system that is low-touch and low-latency

Identification of mission-critical software to be hardened against attack

Cryptographic signatures

Use standardization to reduce the complexity and difficulty in addressing open source software security

Use of memory safe programming languages

Verification through the use of reproducible builds

Use of SBOMs
使用 SBOMs

Globally unique identification of specific software components/ releases
全球唯一标识特定软件组件 / 发布版本


Don't know or not sure

Source: 2022 Open Source Supply Chain Security Survey.
来源:2022 年开源供应链安全调查。

In third place for most popular activities around secure software development, we see a tie between increased automation to reduce attack surfaces and security audits, which were cited by 49% of organizations. The use of IaC tools can provide a reliable path to increased automation of CI CD activities. These tools have proven to be popular across organizations in this survey, and in the right hands, they can be extremely effective. Security audits are also a valuable way to gauge the current state of security for some or all of the organization’s applications. However, security audits — as measured through the eyes of maintainers who participated in the survey — were not valued nearly as highly. While security audits can be invaluable at comprehensively assessing an organization’s security risks, the organization must be positioned to act upon the findings of that audit — which seems a bridge too far for organizations without a security policy. However, note that there were only 72 maintainers participating in this survey, and 78% of them had not participated in an external security audit. It’s possible that security audits are so rare that few software developers have experienced them (and thus can only guess about their advantages).

最受欢迎的安全软件开发活动,增加自动化以减少攻击面和安全审计并列第三,这两项活动被 49% 的组织提到。使用基础架构即代码(IaC)工具可以提供可靠的路径来增加 CI CD 活动的自动化。

这些工具在本次调查中已被证明受到组织的欢迎,在正确的使用下可以非常有效。安全审计也是衡量组织某些或所有应用程序当前安全状态的有价值方式。但是,从参加调查的维护者的角度来衡量安全审计,它们的价值远不如前两项。虽然安全审计可以全面评估组织的安全风险,但组织必须有能力对审计结果进行行动 - 这对于没有安全策略的组织来说似乎过于困难。但请注意,本次调查只有 72 名维护者参加,其中 78%的人没有参加过外部安全审计。安全审计可能非常罕见,以至于很少有软件开发人员经历过它们(因此只能猜测它们的优势)。

Increased incentives by employers to encourage OSS contributions by employees were identified by 41% of organizations. While this is a fantastic idea and would tremendously help create a closed-loop environment for OSS, this point will be discussed in more detail in the next section of this paper.


The IT industry must take a more active rol to improve OSS securit and sustainability

IT 行业必须承担更积极的角色,以改善开源软件的安全性和可持续性

Open source software has thrived as an alternative engine of innovation for organizations and developers alike. The pervasive use of OSS is testimony to the impact that it has had on the IT industry. However, OSS security and quality requires a full lifecycle commitment which creates additional investments in resources, time, and developers when compared to current practice. This section of the report introduces a variety of OSS security and sustainability challenges and solicits advice from organizations on how to address them.

开源软件作为组织和开发人员等的替代创新引擎而蓬勃发展。 开源软件的广泛使用证明了它对 IT 行业的影响。 然而,开源软件的安全性和质量需要完整生命周期的承诺,与当前实践相比,这会导致在资源、时间和开发人员方面产生额外的投资。 报告的这一部分介绍了各种开源软件安全和可持续性挑战,并征求组织关于如何解决这些挑战的建议。

Improving the security of oss development


Organizations and developers are no strangers to the importance of best practices for secure software development. The significance of best practices for OSS development was initially voiced in Figure 15 as the 2nd most important activity for improving OSS security. Best practices have been voiced again by 73% of organizations in Figure 16 as the leading way IT industry organizations can improve the security of OSS development. IT industry organizations (such as the Linux Foundation) have taken this responsibility seriously and are delivering best practices content across a variety of channels.

通过提供最佳实践来改善开源软件开发的安全性,这再次表明了最佳实践的重要性。IT 行业组织(例如 Linux 基金会)已经认真对待这一责任,并通过多种渠道提供最佳实践内容。 组织和开发人员对安全软件开发最佳实践的重要性并不陌生。 在图 15 中, 开源软件开发最佳实践的重要性最初被表述为提高开源软件安全性的第二重要活动。 图 16 中,73% 的组织再次表示最佳实践是 IT 行业组织提高开源软件开发安全性的主要方式。 IT 行业组织(如 Linux 基金会)认真对待这一责任,并通过各种渠道提供最佳实践内容。

The 2nd leading improvement, identified by 61% of organizations, is providing tools for analyzing and remediating security vulnerabilities in OSS components. This need is being addressed as part of the OpenSSF’s open source Software Security Mobilization Plan. This plan was released at the Open Source Software Security Summit II in Washington DC on May 12-13, 2022. This plan is available at https://openssf.org/oss-security-mobilization-plan/.

第二个主要改进是为分析和修复开源软件组件的安全漏洞提供工具,61% 的组织认可这一点。这个需求正在 OpenSSF 的开源软件安全动员计划中得到解决。该计划于 2022 年 5 月 12 日至 13日在华盛顿特区举行的 “开源软件安全峰会 II” 上发布。该计划可在 https://openssf.org/oss-security-mobilization-plan/ 获取。

Figure 16: How organizations can improve the security of OSS development

图 16:IT 行业组织可以如何提高开源软件开发的安全性

What are some of the ways that IT Industry Organizations could improve the security of developing open source software? (select all that apply)

以下哪些方法是 IT 行业组织可以提高开源软件开发安全性的方法?(选择所有适用项)

Figure 16

Source: 2022 Open Source Supply Chain Security Survey.
来源:2022 年开源供应链安全调查。

Define best practices for secure software development

Provide tools for analyzing and remediating security vulnerabilities of the top 500 open source components
提供分析和修复前 500 个开源组件的安全漏洞的工具

Provide more training in secure and memory safe programming for the broader open source software community

Provide funds to support maintainers for analyzing and remediating security vulnerabilities of the top 500 open source code components
为支持分析和修复前 500 个开源代码组件的维护者提供资金

More formal processes for evaluating the security of incoming software

Provide funds to more nascent projects that show significant potential

Other (please specify)

Don't know or not sure

The 3rd ranked improvement identified in Figure 16 by 53% of organizations is to provide more training in secure and memory safe programming. Sadly, many software developers have not been trained on how to develop secure software. As noted earlier, there are some courses available today, including one from the OpenSSF, and there is interest in expanding these courses further. Virtually all languages are memory safe by default. C, C++, and Assembly are the only remaining languages in common use that are not memory safe by default. Training courses and books on alternative programming languages are readily available.

在图 16 中被 53% 的组织认可的改进方法是提供更多安全和内存安全编程方面的培训,该方法是排名第三的改进建议。不幸的是,许多软件开发人员并没有接受过如何开发安全软件的培训。正如前面提到的,今天已经有一些课程可用,包括来自 OpenSSF 的课程,并且有兴趣进一步扩展这些课程。几乎所有语言默认情况下都是内存安全的。默认情况下,几乎所有语言都是内存安全的。C、C++ 和汇编是常用的唯一默认不内存安全的语言。关于替代编程语言的培训课程和书籍随时可用。

Improving open source software resourcing


OSS resourcing is a growing challenge because of the need to improve the security and quality of OSS components. The Open Source Software Security Mobilization Plan, put forward by the OpenSSF, aims to address the following:

  • Secure OSS production. Focus on preventing security defects and vulnerabilities in code and open source packages in the färst place.
  • Improving vulnerability discovery and remediation. Improving the process for finding defects and fixing them.
  • Shorten ecosystem patching response time. Shorten the response time for distributing and implementing fixes.


  • 安全的的开源软件生产。专注于防止代码和开源包中的安全缺陷和漏洞。
  • 改进漏洞发现和修复。改进发现缺陷并修复缺陷的过程。
  • 缩短生态系统补丁响应时间。缩短分发和实施修补程序的响应时间。

This plan is estimated to cost in the vicinity of $70 million to $110 million per year and is designed to provide a blueprint and services including education, training, tools, and processes to secure the top OSS projects. While this plan will provide a useful model for OSS projects in general, there are millions of ongoihg OSS projects. How will funding for many of these projects be accomplished?

这个计划的预计成本大约为每年 7,000 万至 1.1 亿美元,旨在提供一个蓝图和服务,包括教育、培训、工具和流程,以保障顶级开源项目的安全。虽然这个计划将为一般的开源项目提供有用的模型,但仍有数百万正在进行的开源项目需要资金支持。那么这些项目的资金来源将是如何解决的呢?

Figure 17 addresses this dilemma. The leading response shared by 63% of organizations suggests that employers should provide or increase an incentive to contributors of meaningful OSS projects. If end-user organizations elected to "give back" to the oss communities they depend on, it would attract more contributors and improve the security and quality of those OSS components.

图 17 解决了这个困境。63% 的组织表示,最重要的反应是雇主应该提供或增加对有意义的开源软件项目贡献者的激励。 如果最终用户组织选择 “回馈” 他们依赖的开源软件社区,它将吸引更多的贡献者,提高这些开源软件组件的安全性和质量。

Figure 17

Figure 17: The most important ways to improve OSS resourcing
图 17:提高开源软件资源的最重要方式

What are the three most important ways that open source project resourcing can be improved? (select all that apply)

Source: 2022 Open Source Supply Chain Security Survey.
来源:2022 年开源供应链安全调查。

Employers should provide or increase an incentive to contributors for meaningful contribution to open source projects including dependencies

Industry adoption of standards for interoperability across tools to make it less painful for developers to build pipelines and workflows

Cloud service providers should sponsor free or deeply discounted tools and services to open source projects

Employers should give contributors access to security analysis tools they're used to using at work

Employers should contribute to a Linux Foundation fund that redirects 100% of this fund to open source projects of merit
雇主应向 Linux 基金会基金捐赠资金,将该基金的 100%重新分配给有价值的开源项目


Don't know or not sure

Industry adoption of standards for interoperability across tools and discounted resources provided by CSPs (Cloud Service Providers) to OSS projects resonate across 51% of organizations in this study. Interoperability concerns were frustrating and are a characteristic of immature markets. The fragmented nature of today's software security markets suggests that consolidation will occur and help address this problem although the timeframe is unknown.


The concept of cloud service providers providing support for secure OSS development is intriguing. Having access to a portfolio of tools adept at secure software development at deeply discounted prices would be a win for developers. It could also be a win for CSPs as an on-ramp to more conventionally priced runtime services. However, whether this idea has been vetted with CSPs is unknown as is their overall receptivity to the idea.

云服务提供商为安全的开源软件开发提供支持的概念令人感兴趣。以深度折扣价格获得一系列适用于安全软件开发的工具组合对于开发者来说是一种胜利。对于云服务提供商而言,它也可能是一个通向更常规价格的运行时服务的入口。 然而,该想法是否已经经过了云服务提供商的审查,以及云服务提供商对该想法的整体接受程度尚不清楚。

44% of developers at organizations also embrace having their employer establish a sandbox for developing OSS projects using the same tools they are already familiar with. This is also an intriguing idea and would qualify as yet another perk provided by an employer to their employees who contribute to material OSS projects.

44% 的组织开发人员赞同让雇主建立一个沙箱,使用他们已经熟悉的相同工具进行开源软件项目的开发。这也是一个有趣的想法,可以作为雇主提供给为重要的OSS项目做出贡献的员工的另一个福利。

Although the ideas presented as responses in Figure 17 are speculative, they all reflect the realization that secure OSS development will require additional investment which needs to be provided by the community that benefits from the value derived from OSS.

尽管图 17 中呈现的想法都是推测性的,但它们都反映了这样一个认识:安全的开源软件开发需要额外的投资,而这些投资需要由受益于开放源码软件价值的社区提供。

Snyk - Broken Containers

Snyk - 损坏的容器

Vulnerability management is complicated enough to start with, but the advent of containers, virtual machine images, IaC, and microservices complicate it even further. While many organizations are still improving how to handle vulnerabilities in their own code, and starting to examine direct and transitive dependencies in depth, fixing the vulnerabilities introduced by containers is still a struggle. Container images (among other constructs) are often "black boxes" that organizations do not examine further.

漏洞管理本来就很复杂,但容器、虚拟机镜像、IaC 和微服务的出现使得漏洞管理更加复杂化。虽然许多组织仍在改进如何处理其自己的代码中的漏洞,并开始深入研究直接和传递依赖项,但修复由容器引入的漏洞仍然很困难。容器镜像(以及其他构造)通常是组织不进一步检查的“黑匣子”。

Returning to our examples of recent vulnerabilities, as of the time of this writing, only 8% of container projects with Spring Framework dependencies have fully remediated the Spring4Shell vulnerability. In contrast, Log4Shell has been resolved in nearly 25% of all containers.

回到我们最近漏洞的示例,截至本文撰写时,只有 8% 的容器项目使用 Spring Framework 依赖项已经完全解决了 Spring4Shell 漏洞。相比之下,几乎 25% 的容器已经解决了 Log4Shell 漏洞。

Because containers can be ephemeral, the act of creating and destroying containers provides an opportunity for implementing updates that could occur rapidly and significantly improve existing vulnerability dynamics. Changing the code in one container configuration could potentially result in hundreds of updated containers. The flip side is that one container configuration forgotten or missed can also easily result in the same number continuing to be vulnerable. This later challenge is one readily resolved through the use of SBOMs.


Improving OSs sustainability


OSS sustainability is an important topic for anyone who depends on OSS. For small OSS projects maintained by a single person, challenges exist. Sustainability requires continuity over time. To achieve this requires the successful ability to transfer maintainer responsibilities to additional maintainers.


Figure 18 helps prioritize key activities to help address OSS sustainability. Across organizations, 64% report that maintainers should plan for their own retirement by bringing new maintainers into the project. This is the preferred path forward but requires attention to nontechnical activities focused on process and communication. Adding a second maintainer to a project and transferring responsibility from the original maintainer are likely to be some of the most difficult activities a project must overcome.

图 18 有助于优先考虑能帮助解决开源软件的可持续性的关键活动。在各个组织中,64% 报告称维护者应该通过引入新的维护者来规划自己的退休计划。这是未来的首选方案,但需要关注流程和沟通等非技术活动。向项目添加第二个维护者并从原始维护者转移责任可能是项目必须克服的一些最困难的活动之一。

Recognizing the challenges of transferring project responsibility, 58% of organizations believe that if a project reaches its end of life the retiring maintainer should clearly identify on the repo that the software is no longer being maintained.


An alternative path for transferring maintainership responsibility is to find a foundation or IT industry organization that will create a new home for the project. 55% of organizations endorsed this path forward although it may prove to be nearly as complex as independently finding a new maintainer.

转移维护责任的另一种选择是寻找一个基金会或IT行业组织,为项目创建一个新的家。55% 的组织支持这种前进的方式,尽管它可能证明几乎与独立寻找新的维护者一样复杂。

Figure 18: Improving OSS sustainability How should open source software sustainability be addressed if the maintainer(s) on a project decide to retire? (select all that apply)

图 18:提高 OSS 的可持续性 如果项目的维护者决定退休,应如何解决开源软件的可持续性问题?(选择所有适用项)

Figure 18

Source: 2022 Open Source Supply Chain Security Survey.
来源:2022 年开源供应链安全调查。

Encourage retiring maintainers to request and add new maintainers to the project

Encourage retiring maintainers to clearly identify on the repo that the software is no longer being maintained

Look for ways to transition the project to an independent foundation

Look for ways to transition the project to a large scale user of the project

Look for ways to raise funding to encourage the current maintainer to continue


Don't know or not sure

Conclusions and recommendations


Too many organizations are not prepared to address OSS security needs


Across the 500+ organizations participating in this OpenSSF survey, at least 34% did not have an OSS security policy in place (Figure 1). The percentage of organizations without a security policy is likely to be around 40% after prorating those respondents who didn't know the status of an OSS security policy for their employer. OSS use is pervasive across end-user organizations and IT vendors/service providers (who somewhat evenly comprise our sample) and the 60/40 yes/no split on having an OSS security policy persists across virtually all 22 industries represented in our sample. This indicates that not having an OSS security policy is not specific to certain industries or organization types but instead is widely found across business environments.

在参与本次 OpenSSF 调查的 500 多个组织中,至少有 34%没有制定开源软件(OSS)安全策略(图 1)。在按比例计算那些不知道其雇主的 OSS 安全策略状况的受访者后,没有安全策略的组织比例可能达到 40%左右。OSS 在终端用户组织和 IT 供应商 / 服务提供商中普及(它们在样本中几乎均衡),而在我们样本中代表的几乎所有 22 个行业中,60/40 的有 / 无 OSS 安全策略分布均存在。这表明,没有 OSS 安全策略不是特定于某些行业或组织类型,而是广泛存在于商业环境中。

Small organizations must prioritize developing an OSS security


In the wake of numerous high-profile attacks across the software supply chain over the last several years, this finding is disappointing. Every organization needs to have a CISO and OSPO (open source Program Office) or a person or persons vested with key CIS and OSPO responsibilities. We recognize that small organizations with less than 500 people were significantly more likely to not have an OSS security policy (Figure 2). Small organizations, therefore, need to prioritize and limit their CISO and OSPO agenda so it can be achievable with a partial FT. Once key CISO and OSPO capabilities are resident in the organization an OSS security policy will follow.

在过去几年中,软件供应链中发生了许多备受瞩目的攻击,这一发现令人失望。每个组织都需要有一位 CISO(首席信息安全官)和 OSPO(开源项目办公室)或一位或多位负责关键 CIS 和 OSPO 职责的人员。 我们认识到,少于 500 人的小型组织更有可能没有开源软件安全策略(图 2)。因此,小型组织需要优先考虑并限制其 CISO 和 OSPO 议程,以使其成为部分全职任务。一旦关键的 CISO 和 OSPO 能力在组织中得到了落实,OSS 安全策略就会随之而来。

Using additional security tools is a leading way to improve osS security


There are at least 10 tool categories that have a focus on addressing OSS security. Organizations on average use 2.8 security tool categories among the survey options. SCA and SAST tools are the leading tools used to address OSS security among those options (Figure 14). The use of IaC tools (which indirectly address security) and web application scanners (part of the DAST category) round out the portfolio that many organizations use.

至少有 10 个工具类别专注于解决开源软件安全问题。在调查选项中,组织平均使用 2.8 个安全工具类别。软件组成分析(SCA)和 静态应用程序安全测试(SAST)工具是解决开源软件安全问题中最常用的工具(见图 14)。使用 IaC 工具(间接解决安全问题)和 Web 应用程序扫描器(动态应用程序安全测试 DAST 类别的一部分)是许多组织使用的其他工具。

The security tools market has numerous tool categories because the overall domain extends from source code management through build, package, delivery, and deployment. This is basically the entire software lifecycle. Software security must be managed across each step and accomplishing all of this with just two or three tool categories is not feasible. Therefore, organizations should take a closer look at adjacent and complementary security tools markets and determine where incremental tools can add the most value.


Figure 14 also shows that organizations with an OSS security policy have a higher frequency of security tool use than those organizations without an OSS security policy. This same dynamic is in place based on organizational size where large organizations have a higher frequency of security tool use than small organizations. Security tool use is therefore one of the most obvious and powerful ways to improve your OSS security posture.

图 14 还显示,具有开源软件安全策略的组织比没有开源软件安全策略的组织更频繁地使用安全工具。同样,大型组织比小型组织使用安全工具的频率更高。因此,使用安全工具是改善开源软件安全状况的最明显和最强大的方法之一。

Collaborate with vendors to create more intelligent security tools


Adding greater intelligence to existing software security tools is viewed by organizations as one of the most important ways to improve OSS security across the supply chain (Figure 15). While tool vendors may see this more as business as usual, tool users see this as a critical requirement to empower existing resources. Because most end-user organizations are resource constrained in IT, a critical objective is to find ways that existing developers can be more productive without adding to their workload. Increased tool intelligence and automation are examples of how to improve software security in a way nearly transparent to developers.

对于组织来说,将现有软件安全工具加强智能化是提高整个供应链中的开源软件(OSS)安全性的最重要途径之一(图 15)。虽然工具供应商可能认为这是日常工作,但工具用户认为这是赋予现有资源的关键要求。 由于大多数终端用户组织在 IT 方面受到资源限制,因此一个关键目标是找到在不增加工作量的情况下提高现有开发人员工作效率的方法。增强工具的智能化和自动化就是如何在几乎不影响开发人员的情况下提高软件安全性的例子。

Implementing best practices for secure software development is the other leading way to improve OSS security


Understanding best practices for secure software development is identified repeatedly as the leading or a leading way to improve the security of the open source software supply chain (Figures 15 and 16). A primary reason why there is so much interest in best practices is that developing secure software encompasses the entire breadth of the software lifecycle. At each waypoint, from source code management, build services, and packaging to software delivery and deployment there are numerous best practices that need to be followed. This includes literally hundreds of best practices. The Linux Foundation has developed an outstanding free course and certification on developing secure software (LFD121) which can be found on OpenSSF.org.

理解安全软件开发的最佳实践是提高开源软件供应链安全的主要或领先方法之一,这在图 15 和 16 中被反复提到。人们对最佳实践如此感兴趣的一个主要原因是,开发安全软件涵盖了软件生命周期的整个广度。在每个航点,从源代码管理、构建服务和打包到软件交付和部署,都需要遵循许多最佳实践。这包括数百种最佳实践。Linux基金会开发了一个关于开发安全软件(LFD121)的优秀免费课程和认证,可以在 OpenSSF.org 上找到。

Use automation to reduce your attack surface


Infrastructure as Code (IaC) tools provide a way to script manual activities so that they can be automated (Figure 15). Reducing or eliminating manual command line-driven CI/CD activities provides fewer ways for developers to skirt policy, bend rules, make mistakes, and expose CI/CD activities to external threats. Use of IaC tools and lad scanners provides organizations with a way to streamline and automate CI/CD activities while simultaneously eliminating some threat vectors, While there will always be use cases for manual intervention by developers, minimizing the need for this is a best practice.

基础设施即代码(IaC)工具提供了一种脚本手动活动的方式,使它们可以自动化(图 15)。减少或消除手动命令行驱动的 CI/CD 活动为开发人员提供了更少的方法来绕过策略、改变规则、犯错误以及将 CI/CD 活动暴露给外部威胁。使用 IaC 工具和漏洞扫描工具为组织提供了一种简化和自动化 CI/CD 活动的方式,同时消除了某些威胁向量。虽然开发人员总是会有手动干预的用例,但最小化对此的需求是最佳实践。

Consumers of open source software should give back to the Communities that support them


The introduction to this paper mentioned that open source software is at a crossroads. Those open source projects that experience significant growth must evolve from their modest and somewhat informal origin to address a more demanding and security conscious community of users. This transition does not come easily because it requires increased resources, time, processes, and security. The use of open source software has often been a one-way street where users see significant benefit with minimal cost or investment. In order for larger open source projects to meet user expectations it will be important for organizations to give back and close the loop to improve open source software sustainability. Employers need to provide additional incentives to employees who have material maintainer or core contributor open source roles or responsibilities. This would also serve to encourage a higher level of participation by developers in open source projects to ensure the flow of new talent.




The objective of this research was to understand the following:

  • The current state of open source software security
  • Security practices across the open source software supply chain
  • Secure development practices
  • How the security and sustainability of open source software can be improved


  • 开源软件安全的当前状态
  • 开源软件供应链中的安全实践
  • 安全开发实践
  • 如何改善开源软件的安全性和可持续性

This research project was initiated in 2022 01 at the request of the OpenSSF. The primary research vehicle would be a survey of OSS developers, maintainers, core contributors, and security professionals. However, the research was preceded by interviews with fifteen OSS maintainers and security subject matter experts. These qualitative interviews were performed to ensure that the survey included key security topics important to the OSS community.

该研究项目应 OpenSSF 的要求于 2022 年 1 月启动。主要的研究工具将是对开源软件开发人员,维护者,核心贡献者和安全专业人员的调查。然而,在研究之前,对十五名开放源码软件维护者和安全主题专家进行了访谈。进行这些定性访谈是为了确保调查包括对开放源码软件社区很重要的关键安全主题。

Interviews occurred in March 2022 and the survey was fielded in April 2022. Data was analyzed and this report was drafted as well as peer reviewed in May 2022.

访谈在 2022 年 3 月进行,调查在 2022 年 4 月进行。于2022 年 5 月 进行了数据分析,起草了本报告并进行了同行评审。

All Figures in this survey include results that are rounded to the nearest whole integer percent value. Therefore, totals for segmentation data may not always add to 100%.

本调查中的所有图表结果均按最接近的整数百分比值四舍五入。因此,分段数据的总和可能不总是 100%。

This was a long survey with an average time to complete of 20+ minutes. The completion rate for this survey was under 50%. This explains why there is some variation in the sample size for the above segmentation variables.

本调查为长篇问卷,平均完成时间超过 20 分钟。本次调查的完成率不足 50%。这就解释了上述分段变量样本大小存在一定变异性的原因。

Compretensstive screening enteria were to ensure respondents wouildi have a thigh probability of being able to answer all survey questions. Screening criteria included involvement im open source software, experience in the development or use of open source software, employed or looking for employment, and respondents who self-identify as a real person.


The qualitative dimension of this project included in-depth interviews with selected individuals across industries and in federal cybersecurity policy development or involvement with maintaining open source software.


About the Authors


Stephen Hendrick


Stephen Hendrick is Vice President of research at the Linux Foundation where he is the principal investigator on a variety of research projects core to the Linux Foundation's understanding of how open source software is an engine of innovation for producers and consumers of information technology. Steve specializes in primary research techniques developed over 30 years as a software industry analyst. Steve is a subject matter expert in application development and deployment topics including DevOps, application management, and decision analytics. Steve brings experience in a variety of quantitative and qualitative research techniques that enable deep insight into market dynamics and has pioneered research across many application development and deployment domains. Steve has authored over 1,000 publications and provided market guidance through syndicated research and custom consulting to the world's leading software vendors and high-profile startups.

斯蒂芬·亨德里克是 Linux 基金会的研究副总裁,他是许多研究项目的首席调查员,这些项目对 Linux 基金会了解开源软件如何成为信息技术生产者和消费者创新引擎至关重要。亨德里克 先生专注于基于 30 多年软件行业分析师开发的主要研究技术。他是应用开发和部署主题的领域专家,包括 DevOps、应用程序管理和决策分析。亨德里克 先生拥有多种定量和定性研究技术的经验,能够深入洞察市场动态,并在许多应用程序开发和部署领域开创了研究。亨德里克 先生已经撰写了超过 1000 篇出版物,并通过综合研究和定制咨询向世界领先的软件供应商和高知名度的初创企业提供市场指导。

Martin Mckeay


Martin Mckeay is Snyk's Senior Editorial Research Manager, where he works with teams across the company to build reports that increase the knowledge base of security professionals and developers. With over twenty years as a security professional, Martin started his career in help desk operations, continuously building to more complex and diverse roles over the years. Over the last seven years, Martin has developed the skills to turn data into intelligence and translate 'geek speak' into language understandable by mere mortals.

马丁·麦基是 Snyk 的高级编辑研究经理,他与公司各个团队合作,制作报告,以增加安全专业人员和开发人员的知识库。马丁在安全专业方面已经有超过 20 年的经验,他的职业生涯始于帮助台运营,多年来不断发展到更复杂和多样化的角色。在过去的七年中,马丁已经开发了将数据转化为情报的技能,并将 “极客语言” 翻译成普通人可以理解的语言。



This document was authored with the support and collaboration of the following individuals and organizations: Stephen Augustus (Cisco), Brian Behlendorf (Linux Foundation), Hilary Carter (Linux Foundation), Randall Degges (Snyk), Brian Demers, Michael Dolan (Linux Foundation), Kim Lewandowski (Chainguard), Oleg Nenashev (Dynatrace), Mike Milinkovich (Eclipse Foundation), Megan Moore (Synk), Nick O'Leary (FlowForge), Christina Oliviero (Linux Foundation), Ashwin Ramaswami (Plaintext Group), Clark Roundy (Eclipse Foundation), Jed Salazar (Chainguard), Melissa Schmidt (Linux Foundation), Robert Scholte (Apache), Micah Silverman (Snyk), Daniel Stenberg (WolfSSL), Kate Stewart (Linux Foundation), Liran Tal (Synk), Adolfo Garcia Veytia (Chainguard), Derek Weeks (Linux Foundation), David A. Wheeler (Linux Foundation), Sarah Wills (Snyk).

本文档得到以下个人和组织的支持和合作:Stephen Augustus(思科)、Brian Behlendorf(Linux 基金会)、Hilary Carter(Linux 基金会)、Randall Degges(Snyk)、Brian Demers、Michael Dolan(Linux 基金会)、Kim Lewandowski(Chainguard)、Oleg Nenashev(Dynatrace)、Mike Milinkovich(Eclipse 基金会)、Megan Moore(Synk)、Nick O'Leary(FlowForge)、Christina Oliviero(Linux 基金会)、Ashwin Ramaswami(Plaintext Group)、Clark Roundy(Eclipse 基金会)、Jed Salazar(Chainguard)、Melissa Schmidt(Linux 基金会)、Robert Scholte(Apache)、Micah Silverman(Snyk)、Daniel Stenberg(WolfSSL)、Kate Stewart(Linux 基金会)、Liran Tal(Synk)、Adolfo Garcia Veytia(Chainguard)、Derek Weeks(Linux 基金会)、David A. Wheeler(Linux 基金会)和 Sarah Wills(Snyk)。



This report is provided "as is." The Linux Foundation and its authors, contributors, and sponsors expressly disclaim any warranties (express, Implied, or otherwise), including implied warranties of merchantability, noninfringement, fitness for a particular purpose, or title, related to this report. In no event will the Linux Foundation and its authors, contributors, and sponsors be liable to any other party for lost profits or any form of indirect, special, incidental, or consequential damages of any character from any causes of action of any kind with respect to this report, whether based on breach of contract, tort (including negligence), or otherwise, and whether they have been advised of the possibility of such damage. Sponsorship of the creation of this report does not constitute an endorsement of its findings by any of its sponsors.

本报告按“原样”提供。Linux 基金会及其作者、贡献者和赞助商明确声明不提供任何形式的保证,包括但不限于对本报告的适销性、非侵权性、特定用途适用性或标题的默示保证。在任何情况下,Linux 基金会及其作者、贡献者和赞助商均不对任何其他方因与本报告有关的任何形式的间接、特殊、偶然或后果性损害负责,无论是基于合同违约、侵权(包括疏忽)还是其他原因,并且无论他们是否已被告知可能出现此类损害。赞助本报告的创建不构成任何赞助商对其调查结果的认可。

Back Cover

Founded in 2021, Linux Foundation Research explores the growing scale of open source collaboration, providing insight into emerging technology trends, best practices, and the global impact of open source projects. Through leveraging project databases and networks, and a commitment to best practices in quantitative and qualitative methodologies, Linux Foundation Research is creating the go-to library for open source insights for the benefit of organizations the world over.

成立于 2021 年的 Linux 基金会研究院探究开源合作不断扩大的规模,提供对新兴技术趋势、最佳实践和开源项目的全球影响的洞察。通过利用项目数据库和网络,并致力于量化和定性方法的最佳实践,Linux 基金会研究院正在创建开源洞见的去处,以造福全球组织。

Copyright 2022 The Linux Foundation
This report is licensed under the Creative Commons Attribution-NoDerivatives 4.0 International Public License.
版权所有 2022 Linux 基金会
本报告受到 知识共享 署名-禁止演绎 4.0 国际公共许可证的许可。

To reference this work, please cite as follows: Stephen Hendrick and Martin Mckeay, “Addressing Cybersecurity Challenges in open source Software,” foreword by Brian Behlendorf, Linux Foundation and Snyk, June 2022

斯蒂芬·亨德里克和马丁·麦基,“应对开源软件中的网络安全挑战”,前言由 布莱恩·贝伦多夫 所著,Linux 基金会和 Snyk,2022 年 6 月

Snyk is a developer-first security company that helps software-driven businesses develop fast and build securely. Snyk provides a platform to secure all of the critical components of today’s cloud native application development. Snyk is securing the industry leaders such as Google, Salesforce, Asos, BBC, and Asurion. For more information or to get started with Snyk for free, visit https://snyk.io.

Snyk 是一家以开发人员为先的安全公司,帮助以软件为驱动的企业快速开发和安全构建。Snyk 提供一个平台来保护当今云原生应用程序开发的所有关键组件。Snyk 正在保护行业领袖,如 Google,Salesforce,Asos,BBC 和 Asurion。有关更多信息或免费开始使用 Snyk,请访问 https://snyk.io。