开源社区漏洞治理策略与实践

简介: 本次分享的主题是开源社区漏洞治理策略与实践,由安势信息的高坤分享。主要分为四个部分:1. 为什么要重视软件供应链安全时变量池分享2. 我们可借鉴的国外优秀探索3. SBOM的挑战4. 安势的探索及成果

开源社区漏洞治理策略与实践

内容介绍:

1. 为什么要重视软件供应链安全时变量池分享

2. 我们可借鉴的国外优秀探索

3. SBOM的挑战

4. 安势的探索及成果

 

01. 为什么要重视软件供应链安全时变量池分享

这两份数据是昨天刚刚获取的,分别来自 AquaSec 和 OSSRA 这两个安全组织的报告。如左图所示,纵坐标表示 Windows 系统每年的漏洞数量,按年统计。随着开源软件的广泛应用,开源已成为不可逆的趋势,漏洞数量呈现出明显的增长趋势。

截至目前,2024年尚未结束,但截至十月份的数据统计已超过2023年,因此数据漏洞已成为开源供应链安全治理中不可忽视的重要问题。其次,与开源相关的漏洞形势也不容乐观。

首先,84%的代码仓库存在漏洞,其中许多尚未被披露;

其次,74%的代码仓库存在高危漏洞。此外,高危漏洞数量较2022年增长了54%,从48%上升到74%,这一数据明显表明开源软件供应链安全事件频发。

这里有很多安全案例。

从2017年到2025年,我从事开源治理工作已有十几年刚开始做开源治理时,2014年心脏滴血漏洞爆发。当时公司要求我查找心脏滴血漏洞在哪些产品中使用了 OpenSSL 1.0.1,我们当时并不清楚,于是开始排查,从而建立了产品与开源软件之间的关系,包括开源软件的使用情况和暴露情况。

还有比较著名的案例是两年前,即2021年底的 log4j 2漏洞。除了这些漏洞之外,近几年我们发现一个趋势,恶意投毒的情况比以前多了很多。例如,NPM 的作者上传了一个带有后门的包,或者采取其他安全投毒手段进行恶意攻击。俄乌战争爆发后,一些乌克兰作者和亲西方的西方作者开始在俄罗斯使用的一些组件中投毒,这些问题现在在整个供应链安全领域是频发的。

在九月底的峰会上, BP 机事件也被提及。该事件涉及软硬件两条线。硬件方面,攻击者在 BP 机中植入炸弹,以色列在后台操纵,制造商并不知情。中间商通过一家匈牙利公司进行集成物流等操作,然后在中国台湾贴牌生产 OEM 产品,最终交付给伊朗真主党。真主党在黎巴嫩进行清关,再交给意大利的黎巴嫩真主党。软件方面,攻击者通过服务台和传呼机台远程控制 BP 机。整个事件表明,在软件和硬件供应链中存在诸多漏洞,只要解决其中任何一个漏洞,就能有效阻止此类事件的发生。

这是我当时分享的供应链管控要点,涵盖软硬件实体的供应链。

硬件方面, BOM (物料清单)管理至关重要。 BOM 最初源于硬件领域,而非 SBOM (软件物料清单), SBOM 是近几年才出现的概念。通过成分分析,可以识别硬件的合规漏洞信息。从刚才的图中可以看到,硬件供应链涉及集成商、原料供应商、物流、清关等环节,而软件供应链则从总台到黎巴嫩真主党手中,其中存在诸多问题。

例如,供应商是否进行了来料检测,分发商是否合规,在清关时是否进行了检验,软件方面是否进行了木马和后门扫描等。如果在后续组件中可以识别出问题,那么在总台环节,我们是否进行了网络安全防护,寻呼机台到寻呼机的传输过程是否被篡改或攻破。实际上,只要解决了中间任何一个环节的问题,整个事件就不会发生。

因此,整个供应链的管控包括总台的控制面,因为事件发生后,所有总台呼的手机,即这批 BP机进入黎巴嫩手中,是以色列的定点攻击。总台拥有大量 BP 机号,寻址时只针对黎巴嫩采购的这批,说明隐私泄露严重。哪些是真主党成员,哪些人身上有 BP 机等信息都很清楚。此外,软件漏洞管理、管道网络安全以及用户隐私保护等都是整个供应链需要严格管控的内容。

 

02.我们可借鉴的国外优秀探索

在软件供应链透明化方面,欧美地区尤其注重,不仅关注硬件,更侧重于软件供应链的透明化。软件供应链透明化的关键在于成分解析,类似于我们喝水时了解水中含有多少水、碱、钙、钠等成分,以及我们吃饭时了解食物的具体成分。

此外,我们还需积极参与相关标准的制定,形成全球供应链的最佳业务实践。目前,在开源社区已形成一些共识和标准,如 SPDX 标准,它不仅描述软件的基本信息,还涵盖了AI数据集和模型的描述。 SPDX 已被 ISO 列为国际标准( ISO / IEC  5962:2021),广泛应用于软件供应链中。另外, Open chain 和 OpenSSF 这两个开源治理组织也制定了相关标准,如 Open chain 的5230合规标准和18974安全标准。 OpenSSF 还提供了许多应用实践,包括 CI 安全应用实践、安全设计方法、漏洞管理等。

在开源软件供应链框架方面,微软和谷歌分别贡献了优秀的实践。微软的框架主要关注开源软件的使用和安全管理,而谷歌的 SLSA 框架则侧重于开源软件供应侧,帮助在软件供应链中合入代码、选型依赖等。 S2C2F 框架则主要面向消费侧。这些框架都是微软和谷歌等公司基于自身实践贡献并开源的,同时配套了许多工具,为全球供应链的安全和透明化提供了有力支持。

 

03. 生成完整准确SBOM的挑战

实际上,刚才提到的一个关键词是 SBOM 。只有将 SBOM 做到精准,才能使开源软件供应链管理更加透明和便捷。

SBOM有什么挑战?

在技术实现过程中,不同高级语言的包管理器各不相同。例如, Java有 Maven , Node.js 有 NPM,Go 有 Go Modules ,Python 有pip 等,它们的配置文件格式和依赖解析规则也各不相同。

例如,在 Go社区开发云原生应用时,包管理器的规则并不是像 Java 的Maven 那样严格依赖版本号。 Go 的依赖管理非常复杂,存在许多开闭区间,例如将某个组件的版本范围指定为1.0-2.0。

这时,如果你进入如龙蜥社区这样的代码仓库,可能会发现某些组件在引入时是1.0版本,但在构建过程中,系统会自动动态加载最新版本。

例如,你可能在某个时刻镜像了最新版本,导致该包被升级。另外,还有一种规则称为最短路径,即依赖关系像族谱一样,层层递进。在这种情况下,孙子节点和父节点可能是同一个包,最短路径可能会选择最后一个节点,从而导致依赖路径发生变化。不同语言的包管理器维护的产量不同,规则也各不相同。

此外,对于相同的开源组件,如何证明某个社区是可信的、安全的?例如,龙蜥社区目前有数万个包,如何确保你获取的是最可信的版本?像 Tomcat 这样的组件,在开源社区中搜索,可能会找到与其相关的数百个组件和社区。

还有一些代码托管员和分发员各不相同,如何证明他们是可信的?有些高仿组件可能只是在原组件的基础上修改了少量代码,甚至添加了后门,就可能被误用。此外,尤其是现在使用一个小函数或仅包含35行代码的组件时,其实风险非常大。

如何管理这块?其实这取决于你如何使用它。但很多人认为自己没有使用,因此整个开源软件供应链的环境非常复杂,这也是其面临的挑战之一。

 

 

04.安势的探索及成果

如何精准完整地表达并生成所使用的开源组件,这是我们在此领域探索的一些成果和结果,也包含了我们在技术上的一些探索。接下来,我将向大家汇报一下。

首先,我们建立了一个组件身份识别体系,用于确定哪些组件是安全可信的。这是一项非常复杂的系统工程,我们在其中进行了许多探索,并开发了一些相关的工具和规则。例如,为了确保组件来源的可信度,我们会将来源不同于平台或存储的分发物进行规范化,并将其纳入数据库进行管理。假设数据库中有100个组件,我们会逐一核实其官网,确定代码托管平台或开源社区的官方开发网站究竟是哪一个。以Maven 仓库为例,我们需要确保仓库中的源码被正确编译成二进制文件并打包。

同时,我们还要分析组件的依赖关系,既要考虑该组件主动依赖的其他组件,也要关注可能依赖该组件的其他组件。为此,我们为每个组件分配一个唯一的 ID ,类似于每个人的身份证号,以便对其进行有效管理。即便同一个组件由不同的分发员管理,我们也会为其分配不同的 ID ,并建立这些 ID 之间的关联关系,明确它们之间的联系,如是否为同一组件的不同版本等。其次,如何选择最优的组件版本也是一个重要问题。

在同一个开源社区中,单一组件往往存在多个版本。开源项目虽然免费,但维护责任并不明确。有时,一个开发者可能同时维护多达50个版本,而这些工作可能只是兼职进行。例如, OpenSSL 在出现问题前,只有两名兼职人员负责维护,但全球却有大量系统依赖它。这种情况下,如果维护者没有及时披露漏洞或发布补丁,就可能导致安全隐患。我们曾遇到过类似情况, LVM 组件在不同社区的漏洞披露时间和补丁版本不一致。

比如, Fedora 社区比 Debian 社区晚发布了一个版本的补丁,这可能与社区自身的版本发布节奏和维护及时性有关。因此,我们需要在体系中识别并使用最新且最优的版本,以确保系统的稳定性和安全性。此外,统一标识也是我们关注的重点。正如之前提到的,每个人都希望拥有一个唯一的ID,类似于身份证号,以便通过这个ID识别出组件所属的“家族”。

在技术领域,生成唯一ID的方法有很多,例如UUID(Universally Unique Identifier)、Snowflake算法等。这些方法可以为每个组件分配一个独特的标识符,从而实现精准的识别和管理。

还有,数据关联也是我们关注的重点.我们通过组建相关的数据特征,构建组件的画像,分析其生产过程中的各种数据,如社区活跃度、代码合作机制等。社区活跃度可以通过观察社区内成员的讨论情况来评估,一个活跃的社区通常能更快地响应和修复漏洞;

代码合作时,是否有对应的委员会机制和代码审查机制也是关键因素,这些机制可以确保代码质量和安全性;

同时,是否有一套完善的安全漏洞管理体系也至关重要,包括漏洞发现、报告、修复和通知等环节,以及是否设立了专门的漏洞邮箱等。这些数据的关联分析有助于我们全面了解组件的安全性和可靠性。而业界的标准往往更多地定义了过程,如是否建立了安全组织、制定了安全策略、进行了安全设计、建立了漏洞管理体系等,这些都是我们在实践中需要关注和落实的。目前,我们已经在客户中心和项目中配合这些标准进行落地实施。

这是我们刚才提到的体系,目前我们已经取得了一些成果。通过 AIGC(人工智能生成内容)技术,我们生成了具有区分性的CID( Component ID ,组件 ID )和 VID ( Version ID ,版本 ID ),即为同一个组件的不同版本分配了唯一的标识符。我们利用这些  ID 建立了知识图谱,图中的每条线代表一个组件版本与其他组件之间的关系。

例如,如果一个组件依赖于另一个组件,我们就会用一条线连接它们,并用不同颜色的线表示不同的关系。当某个组件出现漏洞并被修复时,如果另一个组件也修复了相同的漏洞,这表明它们之间存在共同的代码。此外,我们还会分析组件之间的父子关系,识别出名称相同但关系不同的组件,进而确定哪个是最核心、最可信、最官方的组件。

通常,被调用次数最多、大厂下载次数最多且应用最广泛的组件,其安全性相对较高。这是我们目前的探索方向,通过知识图谱识别出更可信的组件。

未来,在软件供应链领域,我们将绘制类似于星云的图谱,因为全球有成千上万个组件。我们要识别出哪些组件是“恒星”,哪些是“行星”,从而更好地管理和保障软件供应链的安全。

关于这个应用场景,我就不详细讲解了,只是大致将其分类为软件供应链管理、安全漏洞追踪、许可证合规性管理以及组件画像健康度评估等几个方面。这些分类涵盖了我们刚才讨论的组件标识的应用场景。

目标是站在客户角度实现业务价值,对吗?使用开源社区和开源软件产品可以实现更准确、更快速、更高效和更实时的业务操作。这里有很多例子,比如某个组件的代码迁移了,上个月我们爬取时该组件还存在,但这个月官网已变成404,不再维护,也找不到了。这种组件非常多,该如何标识并在库中存储呢?但如果客户已经在产品中使用了这个组件,而社区已不再维护,该如何处理呢?

我们刚才讨论了统一 ID 标识的问题,接下来我将重点介绍与安全强相关的特性——漏洞可达性分析。漏洞可达性分析在业界应用广泛,其痛点主要体现在以下几个方面。首先,漏洞不仅仅是组件自身的问题,还涉及到依赖关系。

由于软件供应链的复杂性,一个组件可能被多个下游组件依赖,因此下游组件也可能存在漏洞。从漏洞触发的角度来看,传统的ICA(软件成分分析)厂商可能会产生大量误报,而不精确的告警会导致开发人员在排查时浪费大量时间。因此,我们希望通过漏洞可达性分析,准确判断漏洞是否可被触发,从而提高漏洞管理的效率和准确性。

在右图,我们展示了漏洞可达与不可达的概念。漏洞可达性分析的核心在于判断漏洞是否可以通过软件的调用链被触发。例如,log4j组件被其他组件调用时,如果log4j存在漏洞,那么这个漏洞就可能是可达的,因为调用它的组件可能会触发该漏洞。

相反,如果某个函数与log4j组件没有任何调用关系,那么这个函数中的漏洞就是不可达的。这也是我们分析组件BOM及其SBOM关系的重要性所在,因为只有了解组件之间的依赖关系,才能准确判断漏洞的可达性。此外,我们通过构建调用图(如Cloud Graph)来识别漏洞的传播路径,从而实现漏洞可达与不可达的分析。

目前,我们已经实现了函数级漏洞可达性分析。主要通过程序分析挖掘漏洞特征,并结合开源社区的相关信息。在开源社区中,开发者可能并不总是清楚某个问题是否为漏洞,有时会将其标记为bug。通过分析社区中的PR(Pull Request)与Issue的关联,如果某个Issue被标记为漏洞,那么与之相关的PR代码很可能也包含了漏洞。

此外,通过比较不同Commit之间的差异(Diff),可以识别出可能的漏洞补丁。开源社区的开发流程和节奏也会影响漏洞分析,一些资深开发人员或安全专家可能会直接指出某个问题是Bug或漏洞。社区安全人员通常负责安全相关事务,并设有安全邮箱等联系方式。通过工程手段和AI技术,我们可以对社区中的自然语言描述进行分析,辅助漏洞可达性分析。与传统的晦涩难懂的License文本不同,社区中的描述更符合自然语言的特点,可以使用一些简单的LLM(Large Language Model)方法进行解析。

未来,我们将不断深化和加强这方面的研究和应用。

 

目录
打赏
0
2
2
0
1007
分享
相关文章
龙蜥社区漏洞管理治理策略与实践
本次分享的主题是龙蜥社区漏洞管理治理策略与实践,由阿里云龙蜥社区漏洞管理的张世乐分享。主要分为四个部分: 1.龙蜥社区 2.龙蜥操作系统 3.针对漏洞的治理策略
构建坚不可摧的系统安全防线:策略、实践与未来展望
系统安全是维护社会稳定、保障企业运营和个人隐私的重要基石。构建坚不可摧的系统安全防线需要从多个维度出发制定全面的安全策略并付诸实践。未来随着技术的不断进步和应用场景的不断拓展,系统安全将面临更多的挑战和机遇。只有不断创新和完善安全技术和策略才能应对日益复杂的安全威胁和挑战确保系统的安全和稳定运行。
云原生技术专题 | 解密2023年云原生的安全优化升级,告别高危漏洞、与数据泄露说“再见”(安全管控篇)
2023年,我们见证了科技领域的蓬勃发展,每一次技术革新都为我们带来了广阔的发展前景。作为后端开发者,我们深受其影响,不断迈向未来。 随着数字化浪潮的席卷,各种架构设计理念相互交汇,共同塑造了一个充满竞争和创新的技术时代。微服务、云原生、Serverless、事件驱动、中台、容灾等多样化的架构思想,都在竞相定义未来技术的标准。然而,哪种将成为引领时代的主流趋势,仍是一个未知数。尽管如此,种种迹象表明,云原生的主题正在逐渐深入人心。让我们一起分析和探讨云原生技术和架构安全体系的升级和改良,以期发现新的技术趋势和见解。
600 1
云原生技术专题  |  解密2023年云原生的安全优化升级,告别高危漏洞、与数据泄露说“再见”(安全管控篇)
带你读《“DNS+”发展白皮书(2023)》——(五)治理相关进展(1)
带你读《“DNS+”发展白皮书(2023)》——(五)治理相关进展(1)
106 0
带你读《“DNS+”发展白皮书(2023)》——(五)治理相关进展(2)
带你读《“DNS+”发展白皮书(2023)》——(五)治理相关进展(2)
带你读《“DNS+”发展白皮书(2023)》——(五)治理相关进展(3)
带你读《“DNS+”发展白皮书(2023)》——(五)治理相关进展(3)
OpenSCA用开源的方式做开源风险治理:Why? What? How?
OpenSCA是什么?为什么会有OpenSCA?使用OpenSCA能解决什么问题?点击详阅~
590 0
OpenSCA用开源的方式做开源风险治理:Why? What? How?
《云上大型赛事保障白皮书》——第六章 云产品稳定性治理与风险管控——6.2 北京冬奥稳定性治理实践——6.2.2 智能风险管控工具--Aspara ServiceStack-CloudDoc
《云上大型赛事保障白皮书》——第六章 云产品稳定性治理与风险管控——6.2 北京冬奥稳定性治理实践——6.2.2 智能风险管控工具--Aspara ServiceStack-CloudDoc
154 0
AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等