开源软件漏洞治理的挑战与对策建议

摘要：自互联网时代来临以来，开源软件为新一代信息技术的创新发展做出了巨大贡献，同时，开源软件漏洞数量也在持续增加。由于开源软件的开放性和共享性特质，其影响范围与深度也日益扩大。通过分析开源软件和闭源软件的区别，指出了建立开源软件漏洞治理体系的必要性，从开源用户、开源社区、代码托管平台等主体出发，研究发现开源软件漏洞治理存在安全意识缺乏、安全资源投入有限、漏洞情报获取信息差等问题。基于此，提出营造安全氛围、推进开源项目高质量发展、建立开源公共服务平台等对策建议，以期为相关研究和实际应用提供参考。

内容目录：

1　开源软件漏洞治理背景及现状分析

1.1　开源软件蓬勃发展、应用广泛

1.2　我国开源社区起步晚，处于追赶阶段

1.3　漏洞数量稳步增加，影响范围扩大

2　开源软件漏洞治理的必要性分析

2.1　开源与闭源软件安全的差异性分析

2.2　开源与闭源漏洞的差异性分析

3　开源软件漏洞管理的挑战

3.1　开源用户安全意识缺乏

3.2　安全资源投入不足

3.3　漏洞情报获取存在信息差

3.4　开源社区的漏洞管理挑战

3.5　代码托管平台受攻击风险增加

4　我国开源软件漏洞治理建议

4.1　营造安全氛围

4.2　推进开源项目高质量发展

4.3　建立开源公共服务平台

4.4　开展关键信息基础设施安全治理

4.5　增强对开源漏洞数据的安全保护

4.6　推广先进技术应用

5　结语

当前，软件供应链攻击频发，攻击者利用供应链上下游的信任关系，以软件开发、分发和使用过程中的各个环节为攻击切入点。近年来，开源项目数量爆发式增长，开源软件（Open-Source Software，OSS）在全球软件生态中的地位日益增强， 成为攻击者的主要目标 之 一。2024年2月，在 Linux、Unix 等系统中，广泛用于处理 。xz 文件的套件 XZ-Utils 被隐秘植入后门，如未能及时发现，攻击者将能够侵入大量服务器。此外，存在超危漏洞的 Apache Log4j 等开源组件，由于其被大量组件直接或间接依赖，且依赖关系错综复杂，使得其影响范围遍及整个网络空间。2023年，纪守领等人针对 OSS 供应链的攻击事件，从攻击发生环节、攻击类型等方面进行了系统的分析。

目前，美、欧等主要经济体已将 OSS 安全、供应链安全纳入战略文件，以促进开源生态安全稳健发展。然而，OSS 发展与安全之间存在复杂的辩证关系，在 OSS 数量增长、应用加深的形势下，越来越多的安全问题不断涌现，开源生态各相关方面临的挑战加剧。

本文针对该问题，从 OSS 漏洞治理的必要性分析切入，深入挖掘 OSS 发展伴生的漏洞管理问题，探讨 OSS 漏洞管理面临的挑战，并提出相应的应对建议，以期推动 OSS 发展并提升安全的统筹管理效能。

01

开源软件漏洞治理背景及现状分析

1.1 开源软件蓬勃发展、应用广泛

当前，软件供应链攻击频发，攻击者利用供应链上下游的信任关系，以软件开发、分发和使用过程中的各个环节为攻击切入点。近年来，开源项目数量爆发式增长，开源软件（Open-Source Software，OSS）在全球软件生态中的地位日益增 强， 成 为 攻 击 者 的 主 要 目 标 之 一。2024 年2 月，在 Linux、Unix 等系统中，广泛用于处理 .xz文件的套件 XZ-Utils 被隐秘植入后门，如未能及时发现，攻击者将能够侵入大量服务器。此外，存在超危漏洞的 Apache Log4j 等开源组件，由于其被大量组件直接或间接依赖，且依赖关系错综复杂，使得其影响范围遍及整个网络空间。2023 年，纪守领等人  针对 OSS 供应链的攻击事件，从攻击发生环节、攻击类型等方面进行了系统的分析。

目前，美、欧等主要经济体已将 OSS 安全、供应链安全纳入战略文件，以促进开源生态安全稳健发展。然而，OSS 发展与安全之间存在复杂的辩证关系，在 OSS 数量增长、应用加深的形势下，越来越多的安全问题不断涌现，开源生态各相关方面临的挑战加剧。

本文针对该问题，从 OSS 漏洞治理的必要性分析切入，深入挖掘 OSS 发展伴生的漏洞管理问题，探讨 OSS 漏洞管理面临的挑战，并提出相应的应对建议，以期推动 OSS 发展并提升安全的统筹管理效能。

1.2 我国开源社区起步晚，处于追赶阶段

如今，全球 OSS 项目“马太效应”凸显，头部项目“断层式领先”，而我国 OSS 发展与国际发展相比仍存在明显差距，我国尚未形成较为成熟、有较强国际影响力的开源社区。

美国的 OSS 起源于 20 世纪 90 年代，与互联网的兴起和计算机科学领域的创新密切相关。许多著名的开源项目，如 Linux 和 Apache，起初是由美国的个人、组织创建和维护的。开源理念在美国的高校和企业中迅速传播，形成了强大的创新文化。而我国的 OSS 发展相对较晚，直到近年来，我国政府和企业进一步提高对开源的重视程度，才出现了规模较大的开源社区。

尽管如此，我国开源社区的项目数量和开发者数量在过去几年仍取得了较大增长，我国的科技企业巨头如华为、阿里巴巴和腾讯积极支持开源项目，国际影响力仍有进一步提升的空间。目前，国内的开源社区主要聚焦在国内发展，围绕国内开发者进行项目推进与生态建设，在打通语言、渠道障碍，发展成为连接全球开发者的桥梁方面投入不足。大多开源项目的文档仅使用中文，项目的待完成事务、拉取请求也都以中文为主，社区与开发者之间沟通的渠道大多采用微信群、微信公众号等国内社交网络，全球化渠道缺乏。这些手段无法让国外开发者了解、熟悉我国的开源项目，进一步阻碍了我国开源社区的国际化。

同样的，在安全能力建设方面，国外开源基金会组织建设相对完善，在 Linux 基金会及其联合其他厂商成立的开源软件安全基金会的支持下，做好了较为详细的工作划分，其在安全能力建设方面走在世界前沿，在数字签名、语言替换方面已取得成效，并将研究重点放在漏洞的挖掘与修复方面，具体投入如表 1 所示 。而国内基金会起步较晚，直到 2020 年开放原子基金会的建立才实现开源基金会零的突破，2022 年其下属开源安全委员会才成立。因此，我国基金会在安全能力建设工作方面仍较落后，细化工作尚未开展，整体规模较国际一流开源基金会存在较大差距，不利于我国开源基金会的长远发展。

表 1　开源软件安全基金会与 Linux 基金会的开源软件安全动员计划内容及投入

1.3　漏洞数量稳步增加，影响范围扩大

尽管 OSS 的代码透明性和协作性为创新提供了广阔的平台，但与此同时，漏洞的广泛存在也成为开源软件用户面临的持续且严重的挑战。当前，OSS 漏洞层出不穷，对开发者、用户等开源生态相关方造成了严重的危害 。

（1）OSS 漏洞数量持续处于高位。Synopsys 公司发布的《2023年开源安全和风险分析报告》显示，2022年，Black Duck 审计服务团队审计了涵盖 17 个行业的 1703 个代码库，其中 84% 的代码库至少包含一个已知开源漏洞，比《2022年开源安全和风险分析报告》增加了近 4%，且 48% 的代码库包含高风险漏洞。同时，Snyk 和 Linux 基金会2022年发布的开源安全调查报告显示，一个应用程序开发项目平均有 49 个漏洞和 80 个直接依赖项。此外，修补开源项目漏洞所需的时间也在稳步增加。2018年修补安全漏洞平均需要 4 天，而2021 年修补一个补丁大约需要 110 天 。

（2）OSS 漏洞影响范围扩大。Synopsys 公司《2023年开源安全和风险分析报告》显示 2022年仍存在大量早在2021年就已披露的漏洞，例如2021年影响最大的 Apache Log4j2 漏洞，GitHub 超过 8600 个 OSS 直接依赖 Log4j2 组件，最终超过 20 万个 OSS 受到了影响，全球近一半的企业存在被黑客攻击的风险 。然而，在开源项目所有者第一次发布 OSS 修补版本的一周后，仍有超过 80% 的间接关联 OSS 没有完成修补，同时基于 Apache Log4j2 漏洞的新变种也正在迅速衍生，并且很可能在未来一直存在并持续造成危害。

02

开源软件漏洞治理的必要性分析

与闭源软件相比，OSS 具有不同的开发模式和信任主体。在漏洞管理中，开源和闭源漏洞在识别、修补及响应速度方面的举措也存在差异，因此需要在现有漏洞管理体系的基础上针对 OSS 进行补充，建立区别于闭源漏洞的治理方法。

2.1　开源与闭源软件安全的差异性分析

2.1.1　模块化开发下，开源组件数量多

与闭源软件相比，OSS 通常采用模块化设计，将功能划分为相对独立的模块或库，这种模块化的设计使 OSS 使用了更多的依赖库，程序通常直接或间接地依赖于成百上千个软件包和库，比如，Kubernetes 依赖大约 1000 个软件包。然而，持续跟踪这些软件包需要耗费大量的基础设施和人力资源。即使将内部使用的所有开源包放在一个代码托管平台上作为私有仓库，用以辅助管理开源使用的软件包，跟踪全部的依赖更新依然困难重重，庞大的更新流令人望而却步。

2.1.2　开源项目关联复杂，涉及大量开发者和供应商

OSS 中各种组件和库往往相互依赖，形成了一个错综复杂的网络。这种复杂的依赖关系树是 OSS 发展的基础，同时也是其脆弱性的潜在来源。与闭源软件相比，OSS 的供应商可以是由来自全球各地的独立开发者、组织、研究机构等组成的。这种开放性使得 OSS 的依赖关系更加分散，需要验证的上游组件贡献者数量巨大。在闭源软件中，通常只需对少量软件开发公司或组织进行管控，而在 OSS 中，需要管控数十、数百，甚至数千个项目和其贡献者。这使得确保整个依赖关系树的安全和可信性变得更为复杂，每个实体都可能对整个系统的安全性产生影响。

2.2　开源与闭源漏洞的差异性分析

2.2.1　漏洞识别

OSS 的代码是公开的，任何人都可以查看和审查代码。因此，漏洞通常更容易被发现和报告，也更容易被修补。而闭源软件的代码是私有的，外部人员无法直接查看代码。这可能导致漏洞不易被发现和报告，同时，漏洞修补能力取决于供应商的安全能力。

2.2.2　漏洞修补责任

OSS 漏洞修补是协作性的过程，责任分散在多个利益相关者之间。开源项目的维护者和贡献者通常承担对漏洞进行处置的职能，他们通常会接受漏洞报告，分析漏洞，编写修补程序，并发布修补程序或更新。使用 OSS 的用户也需要采取措施保障安全使用，用户往往会积极报告漏洞，测试修补程序，并确保及时升级版本。这种分散的责任体系可能有助于加速漏洞修补进程，也可能导致一些漏洞被忽视或较慢地修补。相比之下，闭源软件由供应商集中管理，漏洞修复过程更加可控。

2.2.3　响应速度

在安全事件发生后的响应方面，OSS 通常具有更快的响应速度。开源安全事件往往波及范围广，影响范围大，受重视程度高，在多家头部企业、广大用户的协同下，可以迅速提供补丁和更新。相比之下，闭源软件的安全事件通告依赖于软件提供商的策略和时间表，应急响应处置也受限于供应商本身的安全能力。

03

开源软件漏洞管理的挑战

3.1　开源用户安全意识缺乏

开源社区中的许多开发者更加注重功能开发和代码优化，而对于安全性的关注较为有限，因此在 OSS 的选型和持续运营过程中存在安全意识缺乏这一主要问题，这会导致 OSS 漏洞管理存在版本混乱、无人维护，漏洞发现与修补滞后及安全事件爆发后应对不当等后果。

（1）版本混乱、无人维护。在用户的 OSS 生态中，可能存在大量的开源组件，版本混乱和无人维护的问题日益凸显。用户可能使用同一组件的多个版本，难以有效地进行漏洞管理和更新。同时，某些开源组件因缺乏维护者而长时间未被修补，增加了被攻击的风险。

（2）漏洞发现与修补滞后。在选择 OSS 组件时，用户往往更注重功能、性能和成本等因素，而对于软件的安全性关注不够。这会导致用户选择包含高危漏洞或已经停止维护的版本，忽略定期检查和更新开源组件，使得已知漏洞得不到修补，增加了安全风险。

（3）安全事件爆发后应对不当。一些用户在安全事件爆发后缺乏适当的应对机制。由于不具有应急预案、演练及响应的培训，使得 OSS 用户无法及时通知下游用户、修补漏洞，或者应对措施不够完备。

3.2　安全资源投入不足

开源组件的漏洞全生命周期的管理不仅要求用户对组件进行升级或替换，还涉及系统的重构和兼容性问题。因此，漏洞管理需要投入大量的经费和资源，但实际上，从软件开发、测试到漏洞响应等阶段投入的资源十分有限，存在的具体问题如下：

（1）开发阶段缺乏开源安全设计。这通常意味着在软件开发阶段未充分考虑选用 OSS 引入的安全风险，极易使整个系统的安全性受到威胁。安全设计还包括威胁建模，有助于识别潜在的威胁和攻击手段，从而在开发阶段采取相应的安全对策。而缺少威胁建模意味着系统可能无法有效地预防或减轻已知和未知的安全威胁。

（2）测试和验证不足。有限的经费可能使得测试和验证环节的资源不足。缺乏足够的测试资源可能导致漏洞无法识别，修复漏洞后无法充分验证修复的有效性，增加了潜在问题的风险。

（3）缺乏专业安全响应团队。缺乏专业安全响应团队可能使得对安全事件的响应不够及时，并且可能导致对漏洞的重要性和紧急性判断不准确，影响修复的优先级和速度。此外，开源项目漏洞修补往往需要多个开发者和贡献者共同协作，专业人员的缺失将大幅提升协作难度，严重降低漏洞修补效率。

3.3　漏洞情报获取存在信息差

在 OSS 生态中，国内外开源社区、OSS 开发者和用户在获取漏洞情报方面存在着信息差的问题。一些国家将漏洞情报视为战略资源，不愿意与其他国家共享信息，甚至还将其作为战略手段，刻意不与别国共享信息以制造信息差。因此，用户可能难以在开源社区中获取到有用的漏洞情报。同时，开源社区中处于核心位置的个人和组织控制、管理着开源社区的信息发布渠道和方式，导致其他个人、组织无法及时获得有关漏洞的信息，漏洞未被及时发现和修补，从而增加了软件安全风险。

究其深度原因，是由于我国企业在国际开源社区中的投入仍有不足。投入更多的技术人才和资金，能够使得我国企业在国际开源社区中的竞争力、话语权提高，与国外企业同步获取漏洞相关最新信息，避免企业在应对漏洞引发的安全事件时处于被动地位。同时，我国企业在国际开源社区中缺乏统一的声音和行动，在漏洞情报获取方面需要团结一致，提高影响力。

3.4　开源社区的漏洞管理挑战

开源社区每天都会收到大量项目的海量漏洞更新，因此，国际开源社区已经逐步将尽可能多的安全工作自动化，在漏洞管理中取得较大进展，具体管理举措如表 2 所示。然而，社区所面临的信息噪音和自动化管理所引发的技术、更新与维护、社区参与度和法律隐私等挑战日益显著。

表 2　国际开源社区漏洞管理举措

续表

（1）信息噪音问题。开源社区的准入门槛降低，使社区参与者激增的同时，也让更多的噪音有了可乘之机，这导致源源不断的无用消息充斥社区，用户在海量信息中难以获取准确的漏洞情报。这一问题的根本原因在于社区无序的信息流，包括但不限于开发者讨论、用户反馈、无关紧要的变更和无效的漏洞报告。

（2）管理自动化挑战。虽然 GitHub 等平台推动了漏洞管理的自动化，但这也给开源社区带来了技术、更新和维护、社区参与度和法律隐私方面的挑战。在技术方面，自动化漏洞管理需要先进的技术支持，如静态代码分析、动态分析等。这些技术需要大量的研发和测试，以确保其准确性和可靠性。在更新和维护方面，随着 OSS 的发展，新的漏洞类型和攻击方式也不断出现。为了保持自动化系统的有效性，需要不断更新和维护。另外，在自动化过程中，可能会涉及法律和隐私问题。例如，在静态代码分析中，可能会涉及代码注释和其他敏感信息。为了应对这些挑战，开源社区需要不断改进和完善其自动化系统，并加强与社区用户的合作与沟通。

3.5　代码托管平台受攻击风险增加

代码托管平台是基础设施的重要组成部分，也是一些敏感资产和数据的保管者。越来越多的攻击者为了追求源代码，对平台进行攻击以试图获得源代码的访问权，如 GitHub 在2014年遭受大规模分布式拒绝服务攻击，以及在2020年遭受源代码存储库泄露。这些事件突显了代码托管平台在全球范围内成为攻击目标的现实性。由此可知，开源代码托管平台的安全性对于全球开发者和开源社区至关重要。

对于平台进行攻击会使平台托管的全部代码都置于风险中，可能带来以下问题：

（1）用户或项目隐私被泄露。攻击者可能获取用户或项目的敏感信息，包括源代码、开发者凭证等，这可能导致代码的泄露，攻击者还可以利用开发者凭证进行社会工程学攻击，进一步获取更多敏感信息或进行其他恶意活动。

（2）阻碍项目的正常运行。攻击者还可能修改或植入恶意代码到项目中，会对项目的功能、性能或安全性产生严重影响，攻击者还可能试图通过拒绝服务攻击使平台服务不可用。这会导致开发者无法访问其代码库，影响项目的开发和维护。

（3）造成信任危机。当平台自身安全受到侵犯时，用户和开发者对于该平台的信任将受到严重损害。这可能导致用户流失、项目迁移，以及对开源社区整体信心的削弱。即使后续恢复正常，开发者和组织对平台的信任降低仍会持续，影响其在开发社区中的地位和声誉。

04

我国开源软件漏洞治理建议

4.1　营造安全氛围

安全氛围的建立不仅是对漏洞管理本身的一种有效策略，也是使 OSS 项目可持续发展的关键。通过推广安全文化、加强安全意识、促进协作和透明度，可以更好地应对漏洞问题，确保 OSS 的安全性和稳定性。

（1）倡导并推广 OSS 安全文化，将安全性融入软件全生命周期的各个阶段。通过博客、社交媒体等渠道宣传 OSS 安全的理念，使负责软件开发工作的相关人员有更强的安全认识。

（2）加强安全意识，开展安全培训与教育。通过在线培训、研讨会和工作坊等方式传递安全最佳实践和漏洞管理的重要性，以培养安全意识。

（3）在各组织内设立完善的安全问题跟踪机制，确保漏洞的报告、处理和解决能够有序进行。该机制应能够及时更新漏洞状态，追踪解决方案的进展，并及时通知相关开发者和社区成员。

4.2　推进开源项目高质量发展

当前开源代码量爆炸式增长，开源社区的漏洞修补速度难以追赶漏洞数量的增加，因此国际代码托管平台已将漏洞修补权限下放至项目运维组织，开源安全逐渐进入“谁负责运维项目，谁掌握漏洞信息”的时代。因此，宜推动我国开源项目的发展以保安全，激励我国有基础、有优势的企业开发高质量开源项目，围绕项目不断壮大开源生态，以点带面，带动国内先进项目的涌现，掌握更多一手漏洞信息。同时，深化国际合作，弥补国内已有平台的不足，探索国际化发展路径，加速形成面向全球的开源平台，吸引国内外优质企业及用户入驻，增强社区活跃度，在学习和发展中不断提高影响力，脱离对国外成熟开源平台的依赖。

4.3　建立开源公共服务平台

鉴于企业在 OSS 安全中存在的安全意识模糊、漏洞信息掌握不及时和技术能力不足等问题，由各地区、各行业汇聚开源安全治理经验，建设公共服务平台，协助企业进行全面的开源资产识别和风险评估，建立开源技术安全管理机制，降低安全成本。该平台应提供先进的安全检测工具以发现源代码缺陷引发的安全漏洞，并提供修补建议等。此外，还可以构建完备的知识库，为软件全生命周期安全提供全流程的安全知识库，并设置开源代码安全评估机制，对流行开源代码进行检测，提供安全检测报告并根据风险将其纳入黑白灰名单管理，为用户选用提供参考。平台概念如图1所示。

图 1　开源公共服务平台概念

4.4　开展关键信息基础设施安全治理

建议关基运营者面向关键信息基础设施开展 OSS 专项治理：一是提高 OSS 资产透明度，充分利用软件成分分析等新工具，建立关键信息基础设施 OSS 资产清单，并理清开源组件之间的依赖关系，以掌握 OSS 使用情况；二是提高安全风险可见性，组织开展开源代码漏洞系统性识别和软件产品供应链安全检测工作，分类分级梳理风险点；三是建立应急处置机制，制定完备的风险应急处置预案，完善 OSS 的漏洞跟踪和响应等机制，以快速精准采取措施。通过以上专项治理，实现 OSS 安全风险可知、可控和可防。

4.5　增强对开源漏洞数据的安全保护

在进行 OSS 漏洞管理的同时，对 OSS 资产及漏洞数据的安全性保护需同步开展。在当前数据分类分级管理的背景下，开源资产清单和漏洞数据是企业识别和维护 OSS 资产的关键工具，应纳入分级分类管理体系。同时，还需要从存储、安全访问与传输、日常维护3个方面采取措施。在存储方面，一是对数据进行加密存储，以防止未经授权的访问和数据泄露；二是采用先进的加密算法，确保数据在存储介质上的安全性。在安全访问与传输方面，一是对访问权限实施严格的控制策略，确保只有授权人员可以查看和修改漏洞数据；二是确保漏送数据的机密性和完整性，包括使用安全的传输协议对数据进行加密传输，防止中间人攻击和数据窃取。在日常维护方面，一是需要定期审计，及时发现潜在的安全问题，并采取相应的纠正措施；二是定期备份，防止数据丢失或损坏。

4.6　推广先进技术应用

综合应用先进技术提高漏洞发现、事件响应效能：一是建议使用静态和动态代码分析工具，对源代码进行全面审查，及时发现潜在的漏洞，提前预防安全事件的发生；二是使用软件成分分析工具对软件进行开源成分分析，生成准确、完整的 SBOM，追踪和记录软件中所有开源组件，了解每个组件的版本、来源、许可证和安全性；三是搭建漏洞溯源与处置平台，利用 SBOM、软件成分分析工具，联动威胁情报预警，在获取漏洞情报时进行快速的漏洞定位与影响分析。

应用上述先进技术，有助于组织更全面地对软件供应链风险进行管理。开源成分分析提供了开源组件的详细信息，自动化的漏洞溯源和处置则提供了对已知漏洞风险的定期检测评估，共同促进了组织更有效地管理其软件资产，及时响应安全威胁。

05

结语

OSS 漏洞管理对我国 OSS 的发展与安全具有极其重要的意义，本文深入探讨了 OSS 漏洞管理面临的风险挑战，并提出了一系列应对措施，旨在加强对漏洞的监测、预防和修复。在未来，我们将继续关注 OSS 漏洞管理的进展，努力为OSS 的健康有序发展提供坚实的安全基石。

引用格式：赵相楠 , 杨文钰 , 李昊燕 , 等 . 开源软件漏洞治理的挑战与对策建议 [J]. 信息安全与通信保密 ,2024(5):80-90.

作者简介

赵相楠，男，硕士，工程师，主要研究方向为网络安全防护体系及攻防技术、软件供应链安全等；

杨文钰，女，硕士，工程师，主要研究方向为开源软件安全、软件供应链安全；

李昊燕，女，博士，工程师，主要研究方向为开源软件漏洞管理、供应链安全管理；

何　佩， 女，学 士，工 程 师，主要研究方向为信息安全、开源软件安全；

阿合买提·雨三，男，学士，工程师，主要研究方向为软件供应链安全、网络安全、Web 安全、内网安全。

选自《信息安全与通信保密》2024年第5期（为便于排版，已省去原文参考文献）

转载自丨 信息安全与通信保密杂志社

作者丨Cismag

编辑丨王萱

相关阅读 | Related Reading

金融机构使用开源软件的潜在风险和应对策略

乐于参与开源贡献代码是好事，但是需要先注意一下这些问题

开源社简介

开源社（英文名称为“KAIYUANSHE”）成立于 2014 年，是由志愿贡献于开源事业的个人志愿者，依 “贡献、共识、共治” 原则所组成的开源社区。开源社始终维持 “厂商中立、公益、非营利” 的理念，以 “立足中国、贡献全球，推动开源成为新时代的生活方式” 为愿景，以 “开源治理、国际接轨、社区发展、项目孵化” 为使命，旨在共创健康可持续发展的开源生态体系。

开源社积极与支持开源的社区、高校、企业以及政府相关单位紧密合作，同时也是全球开源协议认证组织 - OSI 在中国的首个成员。

自2016年起连续举办中国开源年会（COSCon），持续发布《中国开源年度报告》，联合发起了“中国开源先锋榜”、“中国开源码力榜”等，在海内外产生了广泛的影响力。