智能化软件开发微访谈·第二十九期：开源软件供应链风险分析与治理-CSDN博客

2024

Happy New Year!

CodeWisdom

智能化软件开发沙龙是复旦大学CodeWisdom团队参与组织的专注于代码大数据与智能化软件开发的学术和技术沙龙，面向相关领域的学术界研究者和工业界实践者，通过各种线上和线下交流活动促进学术研究与实践技术的发展。微访谈是智能化软件开发沙龙依托沙龙微信群开展的线上交流活动，其形式是围绕某一具体话题邀请嘉宾进行在线访谈并与微信群成员互动。

开源软件供应链风险分析与治理

智能化软件开发微访谈·第二十九期

背

景

介

绍

开源软件已经成为国民经济各行业发展的重要基石。据Gartner数据显示，99%的软件产品使用了开源软件。然而，商业软件以及开源软件自身都有可能包含以组件、源代码、二进制文件等不同形式存在的外部组成成分，从而导致日益复杂的供应链体系，由此引发各种风险。近年来，开源软件供应链事故也呈快速增长的态势，造成了越来越严重的危害。

开源软件供应链所面临的风险主要有哪些？学术界和工业界最关注的核心问题有哪些？在这些问题上的进展如何？软件成分分析在实践应用中还存在哪些问题和挑战？应该如何构建准确的开源漏洞知识库？开源软件供应链应用到特定领域将会面临什么样的挑战？

针对这些问题，本次微访谈邀请了来自学术界和工业界的多位专家，围绕开源软件供应链这一主题展开讨论，总结学术界研究及工业界实践现状、分析相关技术问题、展望未来的发展方向。

主

持

人

彭鑫

复旦大学计算机科学技术学院副院长，教授

访

谈

嘉

宾

刘杨

新加坡南洋理工大学（NTU）计算机学院教授，NTU网络安全实验室主任、HP-NTU实验室主任以及新加坡国家卓越卫星中心副主任

霍玮

中国科学院信息工程研究所第十研究室主任

吴敬征

中国科学院软件研究所研究员，

智能软件研究中心副主任

张源

复旦大学计算机科学技术学院教授

陈碧欢

复旦大学计算机科学技术学院副教授

陈森

天津大学英才副教授，特聘研究员，博导

梁广泰

华为云软件分析Lab负责人，

软件分析领域资深技术专家

刘波

华为软件工程高级专家、

openEuler开源社区软件供应链安全总架构师

薛植元

上海安势信息技术有限公司，创始人 & CEO

唐忱

苏州棱镜七彩信息科技有限公司,解决方案负责人

访

谈

主

题

开源软件供应链风险分析与治理

开源软件供应链所面临的风险主要有哪些方面？这些风险通过哪些途径被引入到软件产品中？目前学术界和工业界最关注的核心问题有哪些？在这些问题上的进展如何？

针对软件成分不清的问题，SBOM标准（如SPDX、CycloneDX等）被相继提出，旨在列出软件产品中所使用的所有依赖项。这些SBOM标准的异同点是什么？应该如何选择SBOM标准？软件成分分析技术是构建SBOM的主要途径之一。目前软件成分分析技术的主要技术流派有哪些？软件成分分析在实践应用中还存在哪些问题和挑战？

漏洞是开源软件供应链安全分析的基础数据。然而，很多开源漏洞的知识（如影响组件及其版本、补丁、PoC等）在公开漏洞库中并未披露或者被错误地披露，甚至很多漏洞没有收录在公开漏洞库中。为此，学术界和工业界应该如何面对和解决这一挑战？漏洞知识库是否应该通过开源的力量来共建？

开源软件供应链应用到特定领域（例如，操作系统、AI系统、智能汽车等）将会面临什么样的挑战？是否可以分享下领域应用的实践经验？

国际上开源软件供应链安全布局从2021至今涌现出已OpenSSF基金会为首汇聚104家企业和机构共享共建，Google和Microsoft加大供应链安全相关框架和工具链的开源开放力度和商业云服务推广。未来差距可能呈现拉大趋势。国内如何形成生态联盟，布局标准/框架/加大工具链的开源开放力度/顶级社区的席位等，避免未来潜在的业务连续性风险？

您对开源软件供应链治理的发展趋势有什么看法？有哪些难点和挑战需要被进一步解决？目前相关的厂商特别多，您对立志从事开源软件供应链的研究人员有什么建议？

访

谈

记

录

Question 1

刘杨：

供应链风险目前大家相对比较关注的主要是安全和版权许可两方面的风险，安全的角度，主要考虑的是供应链中隐藏的开源软件漏洞及恶意代码带来的可能的利用与攻击，而合规的角度，主要是在第三方组件的合规使用上，比如不违反第三方供应者的使用许可等。此外，第三方组件的质量和稳定性也逐渐成为大家关注的问题，包括开源组件的质量，可维护性，可持续性，社区健康度等。

这些风险产生的原因往往是多方面的，一方面用户在对开源成分使用时缺乏必要的安全和合规审查，另一方面在软件运维的过程中可能缺乏必要的依赖管理与更新维护。此外，目前随着DevOps的自动化程度逐渐提高，其中各个环节对应的安全与监控工具也逐渐力不从心，往往无法达到满意的准确度，这给DevOps的运维人员带来了相当多的人工确认与校验工作，而这些逐渐增加的人工成本也反过来造成了这些审查，管理与维护工作的质量下降。这些原因都可能是造成风险存留在软件产品中的原因。

目前业界关注的核心问题我认为主要在供应链的透明度，供应链相关数据的覆盖度与准确性，风险的定位与处置，对应的自动化方法及工具，以及开源软件使用的政策与标准这几个方面。

首先，如何正确的识别软件的供应链，即怎样精准识别软件中包含的第三方成分，引入方式，以及第三方成分中对应被使用的部分。其次，在识别第三方成分之后，需要与安全或合规数据进行关联进而识别风险，而这些安全与合规数据的准确性目前也是亟需解决的关键问题。在定位风险后，往往安全人员会将这些风险报告回给开发人员，而开发人员需要如何处置或规避这些风险，以及对应的优先级，也是目前广泛关注的问题之一。而在这些过程中，对应的自动化方法与工具，以及整个过程中的如何制定相应的政策与规范，也是目前在探索的核心问题。

在上面提到的问题上，业界目前也取得了一些不错的进展，比如SCA工具能力的提升，目前除了传统基于包管理器的SCA工具，基于克隆检测的SCA工具也不断涌现，准确性也在逐渐提升。数据方面，也出现了一些关于风险数据收集与准确性的工作，比如漏洞版本范围，多源漏洞数据的一致性，patch与POC的收集与确认，恶意代码的收集与攻击模式的分析等。程序分析的技术，比如可达性分析，污点分析等也逐渐应用到SCA检测后的漏洞影响分析及处置上。一些开源组织，比如OpenSSF, OpenChain，还有国内的开放原子基金会，OpenEuler等社区等也在不断提出新的倡议来推动第三方使用的规范使用等。

霍玮：

我认为，开源软件供应链所面临的风险主要有四个方面，版权风险，缺陷风险，投毒风险，断供风险。

版权风险通常由软件及其依赖间的许可证冲突引入。在图谱本体中，通过软件依赖关系、依赖版本可以搜索到所有依赖软件的许可证信息，和当前软件的许可证信息进行冲突分析，进而检测潜在的版权风险，版权风险会随着软件依赖关系链条传播。

缺陷风险主要由软件中的漏洞引入，潜在的缺陷风险可以通过对开发者、软件的画像结果进行评估。缺陷风险主要沿软件依赖关系链传播，但下游软件是否受缺陷风险影响需要根据依赖方式、依赖版本、依赖函数列表、漏洞影响版本、漏洞函数、修补函数等要素综合评估。

投毒风险由软件中的恶意代码引入，潜在的投毒风险主要通过对开发者稳定性、开发者数量、平台安全性等属性的画像结果进行评估。投毒风险的传播和缺陷风险的传播类似，主要沿软件依赖关系链传播，但下游软件是否受投毒风险影响需要根据依赖方式、依赖版本、依赖函数列表、恶意代码位置等要素综合评估。

断供风险可能由于多种原因引入，例如开发者停止维护、出现政策风险等，断供风险同样沿软件依赖关系链条传播。

目前学术界和工业界最关注的核心问题包括数据集的收集与构建，供应关系分析，风险分析技术等。

刘波：

大家好我也补充一下。

风险主要包括：开源许可证合规风险，漏洞风险，敏感信息泄露，投毒/恶意软件植入等

主要途径有：

1、开发人员在不知情的情况下引入了直接或传递性依赖软件。

2、软件开发阶段没有风险防控IT与管理要求，如开源选型，中心仓，软件成分分析，杀毒，恶意软件扫描等

最关心的核心是：SBOM软件物料清单，识别产品/公司的依赖软件，建立正反向的追溯链。还有就是fuzz 0 day漏洞挖掘

当前业界从2021年美国行政命令以来国际主流的SCA厂商，主流的公司包括国际和国内，开源社区已支持其能力。供应商也陆续要求发布软件包的同时提供SBOM清单。fuzz这块Google的oss-fuzz能力最强，还有漏洞悬赏机制配套等

吴敬征：

好的，我也谈下我的看法：

目前，全球97%的软件开发者和99%的企业使用开源软件。然而开源软件供应链蓬勃发展是一个双刃剑，在提高开发效率的同时，也面临了很多风险，目前主要的风险有以下几种：

1、上游源投毒风险。上游源投毒风险是由于攻击者通过在供应链社区中发布恶意软件包，从而实现窃取用户敏感信息及数字货币密钥、种植持久化后门、远程控制等一系列攻击活动。如何有效识别和预防供应链中的恶意代码注入、如何确保代码依赖和组件的完整性、以及如何提高软件供应链的透明度和可追溯性，是目前学术界及工业界在上游源投毒风险中最关注的问题，在这些问题上的进展包括开发更先进的检测工具、实施严格的代码审查流程、以及推广使用签名和其他安全认证手段来验证软件的完整性。此外，还在探索使用区块链等技术增强供应链的安全性和透明度。

2、继承性漏洞风险。继承性漏洞风险是由于开源开发模式的组件复用关系，当上游组件中存在漏洞时，该漏洞也会影响下游使用该组件的产品。在学术界和工业界，继承性漏洞的问题引起了广泛关注，继承路径分析、漏洞传播模型、依赖项管理、漏洞数据库和共享信息、漏洞管理策略等都是针对该风险的研究重点。针对继承性漏洞的解决方案包括自动化工具的使用，定期审查依赖关系，以及采用持续集成/持续交付（CI/CD）流水线进行自动漏洞检测。开源社区和工具提供商致力于开发更智能的漏洞检测工具，帮助开发者更轻松地管理和更新项目的依赖项。

3、合规性冲突风险。使用开源软件要遵循相应的开源协议，而在开发过程中，常常由于开源组件过多、许可证条款复杂等原因，造成违反开源协议，造成知识产权侵权。目前针对该风险的研究核心问题在于复杂项目中的多协议管理、专有软件与开源软件的集成以及协议的演进和变更等方面。针对该风险，很多开源团队采用了开源许可证管理工具，确保项目符合法规和行业标准。一些组织和项目还开展了定期的法律审核，以及向开发者提供相关合规性培训。

4、APT链路级攻击威胁风险。该风险是由于攻击者通过利用开源软件生态系统中的弱点，篡改源代码、分发恶意软件、滥用供应链软件依赖关系，从而破坏软件开发流程，威胁开源软件的完整性和用户安全。在学术界和工业界，针对APT攻击的技术和手法、威胁情报的分析与合作、威胁建模及仿真、网络和终端防护技术等问题都是被关注的核心问题。针对这些问题，对零日漏洞的研究、对抗社会工程学攻击的培训和技术工具的发展都在不断进行。开源社区和安全公司发布的威胁情报也有助于推动这方面的研究。一些国家和行业也建立了自己的威胁情报中心，促进跨组织的信息共享。

5、托管仓库数据泄露风险。在供应链云服务或托管环境中，由于配置错误、安全漏洞、身份验证问题或恶意内部行为，从而导致存储的敏感数据暴露给未经授权的访问者。针对托管仓库数据泄露风险，访问控制和权限管理、令牌和凭证管理、数据加密技术等成为核心研究问题。一些研究为了解决上述问题，设计了更智能和细粒度的访问控制机制，包括基于角色的权限、动态权限分配等方面的研究；提出了基于区块链的令牌管理系统，以提高令牌的安全性和可追溯性。

6、维护性中断风险。由于开源项目活跃度低、维护能力不足等原因，造成供应链中开源组件缺乏维护。项目的可持续性、社区治理、技术债务以及替代品挖掘都是维护性中断风险的核心研究问题。针对上述问题，研究者研究了通过代码重构和系统重写等策略来降低技术债务的有效性。这包括对重构技术和工具的探讨，以及确定何时进行重写以更彻底地解决技术债务问题。

陈碧欢：

开源软件供应链所面临的风险主要包括：1）由于漏洞传播或者恶意代码投毒导致的安全风险；2）由于开源许可证条款违反或者冲突导致的法律风险；3）由于软件项目断供、组件版本升级、组件冲突导致的维护风险。这些风险不仅通过软件项目所依赖的开源软件供应链来引入，而且还通过构造该软件项目的工具链（如IDE、编译构建工具等）来引入。

针对安全风险，主要关注于：1）细粒度的漏洞可达性和可触发性研究，从而减少组件级漏洞传播影响分析的误报率。目前漏洞可达性分析可以借助于函数调用图，但也受限于函数调用图分析本身的准确性以及跨语言的函数调用，我们也做了一些Java和Python的函数调用图增强工作来更好地支撑可达性分析；而漏洞可触发性分析相对难一些，涉及到POC构造和泛化等，我们也正在努力推进。2）恶意软件包检测研究，目前大多都通过机器学习分类和聚类算法来实现，在数据集上的表现都还可以，但在真实检测场景下误报率很高。我们也做了一个基于行为序列建模的检测工具持续监控NPM和PyPI新发布的软件包，目前检测到了900+NPM恶意软件包和700+PyPI恶意软件包，但误报率还比较高。3）漏洞检测与修复研究，这块偏传统安全的工作也很多。

针对法律风险，基本思路是先检测许可证，然后识别冲突或者违反。前者主要通过开源工具ninka来实现，后者大多通过预先建模好的冲突规则或者违反规则来实现。南开大学范玲玲老师和天津大学陈森老师的许可证冲突检测工具不需要预定义规则；北京大学周明辉老师也做很了多许可证推荐和兼容性分析的工作。针对维护风险，东北大学王莹老师做了很多依赖冲突检测的工作，我们组的黄凯锋博后也做了一些组件版本升级推荐的工作。

陈森：

我个人是做漏洞和恶意代码检测与验证的，所以我还是从这两个维度去聊一下开源软件供应链面临的风险。这些风险主要源于两类代码问题：一类是自主开发的代码中可能存在的漏洞，特别是开源场景下代码质量会因各种因素而参差不齐，代码漏洞问题更为显著；二是引入的第三方代码中潜藏的安全隐患，我们常说的开源第三方组件漏洞就是该类问题的典型展现。此外，恶意代码攻击也构成了重要的安全威胁，随着开源软件的发展，恶意代码种类和数量都再急剧增加。最后，合规性和许可证问题也是供应链管理的重要方面。

在工业界，主要关注点集中在漏洞检测、开源组件分析以及合规性与许可证的监控。这些方面是确保软件产品安全和合法性的基础。而在学术界，除了对漏洞检测的关注外，还特别重视漏洞的修复工作。据我了解，学术界在寻找高效的漏洞修复方案方面相对工业界更为活跃。在这方面，我与刘老师的合作研究在同行评议的时候得到了积极评价，例如icse23，ase23的工作都是做开源漏洞修复的工作。我们的基本理念是，在面对开源软件的漏洞时，不仅提供无漏洞的版本，同时也要考虑到软件的兼容性问题。

张源：

前面各位专家提到了很多，我重点提两方面风险。一方面是版本管理不善引入的不安全依赖，另一方面则是恶意投毒导致整个生态被污染。这些问题共同的影响就是不安全的第三方开源组件被开发者引入到了自己的产品中，给攻击者提供了攻击便利性。

当前学界和业界主要关注的是如何发现漏洞，如何验证漏洞是真实的、避免误报，以及如何及时对发现的漏洞进行治理。针对这些问题，目前主要的技术思路有软件成分分析、漏洞可利用性分析、漏洞自动化修复等，相关的研究也越来越多的出现在软工和安全的顶会中。可能下一步还是提高相关技术的效能和扩大覆盖的范围，也包括发现新型的供应链安全威胁。

薛植元：

其实主要分两类，一类是生产环节的供应链，还有一个是开发过程的供应链。

在传统汽车行业，有主机厂, Tier 1, Tier2这样一个供应的链条，那么对于从任何一个环节引入的缺陷，都有可能对最终用户造成非常严重的影响，所以我们需要对这些环节的质量都有所把控。手机也是有类似的供应链条的，从开发者到芯片厂商到单板再到设备制造商，最后到最终用户，中间有很多的环节，我们很难掌控，如何确保这些环节的安全、可信、合规是非常重要的。

另一个就是开发过程中的供应链，从源代码经过CICD平台的集中构建变成APK、JAR包这种依赖或者制品进行分发使用，有很多环节都会引入不同种类开源的风险。

主要有以下：

代码安全性：开源软件可能包含安全漏洞或恶意代码。由于任何人都可以贡献代码，恶意参与者可能会注入有害代码。

依赖性风险：开源项目通常依赖其他开源项目。如果这些依赖的项目不再维护或含有安全问题，它们可能成为攻击向量。

许可和合规性：开源软件可能有多种许可协议，若不正确遵循，可能会导致法律和合规性风险。对于我国大量的出海型企业，特别是涉及软件产品的出海企业，遵守出口国家相关的法律法规是非常重要的，比如美国的FDA在2023年10月就已经规范了医疗器械企业在提交pre-market材料时，需要提供机器可读的SBOM。欧盟的网络弹性法案也会在今年进入最后的立法程序。这都对我们企业提出了更高的治理要求。

质量控制与社区支持：开源项目的质量可能参差不齐，因为它们的维护和更新依赖于社区，可能没有统一的质量保证流程。而且如果社区活跃度下降，软件可能会迅速变得过时或存在未解决的问题。在衡量开源项目质量这一课题中，我们可以看到华为和国内一些高效都在积极进行探索，比如CHAOSS OSSCompass。

观点讨论

@彭鑫：@薛植元应该也有不少有害代码是无心之失？代码安全性是开源软件可能包含安全漏洞或恶意代码。由于任何人都可以贡献代码，恶意参与者可能会注入有害代码。

@薛植元：@彭鑫确实有不少代码是无心之失。从我们研究的结果看单个文件在开源社区被复用的次数接近100，也就是说可能开发或者贡献者无意中复制或者引用了带有漏洞的文件从而引入了漏洞

梁广泰：

前面专家已经分享的很充分了，我这边针对近期学术界和工业界尝试的一些技术方向进行下介绍吧：

1. 开源漏洞的发现：⽬前的技术主要围绕软件分析、模糊测试和深度学习模型三个⽅⾯。特别是将软件分析技

术与深度学习模型相结合的⽅法⽇益受到重视。⽬前这⼀领域正从传统的机器学习模型、序列模型、图模型

向⼤型语⾔模型发展，并已取得显著成果。

2. 公开漏洞精化：这⼀领域的⼯作主要是将公开漏洞数据库（如NVD）中的⾮结构化数据转换为结构化数据，

主要依靠分类模型和命名实体识别等传统⾃然语⾔处理技术。近期，有学者开始尝试使⽤⼤型语⾔模型来进⼀步提⾼效果。

3. 恶意成分检测：基于LLM的恶意成分检测技术，目前业界也在积极尝试推进。

观点讨论

@陈碧欢：@梁广泰深度学习的可解释性问题在漏洞检测方面企业是咋看的？我们之前是把行为序列分成多段，多次喂给大模型。

@陈森：@梁广泰请问对于恶意成分分析，如果基于LLM的话，输入的粒度现在是如何的？

@梁广泰：@陈碧欢针对一些根据局部片段特征进行的漏洞分析是有一定效果的，同时是可以给出一定漏洞类型描述。这个漏洞描述会比较有帮助。

@梁广泰：@陈森片段级的检测目前比较多。

唐忱：

面临的风险包括：安全、合规、断供、攻击、木马、后门

引入方式包括：供应商携带、开发组件引入、互联网引入、内部引用

核心问题关注：安全、合规

进展：产业界最近几年大部分已完成从无到有的建设，这其中包括软件供应链治理体系、相关背景知识培训、自动化工具链、管理平台建设；国家也先后出台了一些标准，例如：软件供应链专题国标，软件成分清单专题国标。

Question 2

刘杨：

总的来说目前有三种相对主流的SBOM标准，SPDX, CycloneDX，及SWID，其中SPDX主要用于记录和交换软件包的许可信息，强调软件许可证的合规性，对许可证信息的支持相对比较丰富。CycloneDX则相对专注于应用安全和供应链风险管理，它对安全风险，比如漏洞信息等的描述能力相对较强。而SWID则是由ISO/IEC标准化，用于软件产品的唯一标识及元数据，相对而言SWID更强调提供全面的软件身份信息，包括名称、版本、制造商等，更适用于需要严格软件身份管理和合规性的环境。这些SBOM标准各有特点，但共同目标是提高软件供应链的透明度，帮助组织更好地理解和管理他们所使用的软件组件，而在使用SBOM标准时可以根据实际的场景进行选择。

目前软件成分分析技术主要分为三大块，首先是基于包管理器和构建工具的SCA，这里又能细分为安装前和安装后两个场景，安装前这些工具会通过解析依赖配置文件推理出将会安装的依赖，安装后则依赖包管理器直接列出所有的依赖。第二个是基于代码克隆分析的SCA，由于开发人员除了使用包管理器，也会通过直接的源码复制，或者直接将第三方组件的源码整包放在项目中，这些依赖无法直接通过包管理器识别，而克隆检测技术能够有效识别这类复用。第三块则是面向二进制的SCA工具，很多情况下源码无法直接获得，则需要对二进制软件包直接进行分析，这种往往通过对二进制包的一些签名特征来进行判断。

目前SCA在现实场景中还是存在着一些挑战，首先是准确性和覆盖范围，比如克隆检测的特征数据库对所有组件的覆盖程度，如何尽可能多地收集足够的组件是目前落地场景中的一个关键问题，尤其是在面向一些特定垂直领域的SCA分析上。其次，在组件数据逐渐补全的过程中，数据量级的增加也意味着SCA检测比对算法开销的增加，如何在尽可能地的复杂度下保证检测算法的准确性也是目前落地的一大问题。此外，目前的SCA工具往往无法避免大量人工确认的介入，目前而言，很多SCA工具为了保证风险尽可能被检出，会导致较高的误报率，从而需要引入较多的人工确认，如何有效降低SCA工具误报也是目前推动SCA工具的持续集成与自动化的关键问题。

霍玮：

这些SBOM标准都是为了提供关于软件构成的标准化信息，通过标准化地描述软件构成中的组件、版本信息、依赖方式与其他相关数据，帮助更好地理解、管理和保障软件供应链。SBOM之间的差异使得这些标准可能分别在不同的情景和场合下更适用，所以选择合适的SBOM标准可能需要考虑一系列因素，比如用户的具体需求：为什么需要SBOM、使用SBOM有什么目的，SBOM标准是否足够灵活、能够适应用户的需求，还要考虑到行业标准和合规性。总而言之，选择SBOM标准应该是一个涉及多种因素的权衡，需要综合的考虑。

软件成分分析技术主要分为静态分析和动态分析。静态分析在不运行程序的情况下分析源代码、字节码或二进制代码，识别和提取软件构成的组件信息。静态分析又可以进一步分为两类，第一类是类包管理器技术，一般通过各种开发语言的包管理器、工程属性文件等获取项目依赖的开源组件或间接依赖的开源组件，第二类是同源分析技术，通过库中代码生成特征、在相同粒度下与被检测项目进行特征匹配或相似匹配的方式，找到开源组件名称及对应的版本。另外，目前越来越多的使用深度学习技术，通过学习相似模型，达到跨架构、跨编译器等方面的同源分析。动态分析则通过在运行时监控和分析程序的执行，捕获软件的运行时行为、加载的动态库和依赖关系。

到目前为止，软件成分分析在实践应用中仍然面对着一些挑战。比如类包管理器技术在依赖关系复杂、传递依赖涉及多版本的决策实现时可能无法准确地获取第三方依赖信息，进而无法准确地完成分析；同时，由于开源组件之间相互依赖的关系很多，不可避免的增加了检测结果中开源组件的数量，这无疑会带来不小的负担。对于同源分析技术，它需要依赖足够大的库才能够达到精准的覆盖，这就导致需要存储海量代码生成的指纹；当然，匹配算法的选择也会影响到分析结果。至于动态分析技术，其有可能受限于功能测试或操作程序功能的广度和深度，导致一些边缘功能遗漏的情况。

观点讨论

@陈碧欢：@霍玮霍老师，动态分析在SCA现在用得多哇？感觉一些片段级的依赖引用就不行了

@陈森：前段时间听企业界的朋友介绍，他们在推动态方案，和静态是互补的关系。

@霍玮：@陈碧欢并不多，但我觉得可以跟静态互补一下，特别是分析哪些开源组件引入的问题带来的安全风险更大方面

@彭鑫：目前代码组成成分分析的粒度似乎还比较粗，当然细粒度成分分析比较难界定，可以先从粗粒度开始

吴敬征：

软件成分不清的问题推动了SBOM标准的提出，这些标准列出软件产品中所使用的所有依赖项的目的是增强整个软件供应链的透明度和可管理性。其最小的组成要素有三个部分：数据字段、自动化支持以及实践和过程，其中数据字段描述了软件的相关信息，主要包括SBOM数据创建信息和组件信息。

为了更好的推广SBOM的应用，相关的格式规范标准相继被提出，当前国际上最为流行的格式标准为Linux基金会提出的SPDX标准和OWASP提出的CycloneDX标准，两种标准都覆盖了SBOM创建信息、软件基本信息及成分组件信息，满足SBOM最小组成要素要求，但SPDX标准更聚焦许可证合规，且更细粒度的包含文件级和代码片段级信息，而CycloneDX标准则包含漏洞信息，更聚焦安全性信息，相对更适用于安全审计、漏洞管理等场景。此外，CycloneDX标准是一个全栈材料清单标准，其不仅支持软件的物料清单，还可支持服务物料清单、硬件物料清单等多种规范。

构建SBOM的主要方式是软件成分分析，挖掘记录软件引用的第三方组件信息，当前软件成分分析技术主要有两大手段，一是通过文件扫描，解析提取编程语言包管理器配置文件，生成软件依赖成分列表；二是通过大规模扫描软件程序源码，开展克隆检测，通过代码同源性分析，获取文件级和代码片段级引用信息。在软件成分分析的实际应用中，存在许多问题和挑战，这里列出几点：

1.对于无配置文件的软件，其依赖信息难以准确分析。很多开源软件源码并没有提供配置文件，所以其软件依赖成分难以准确地提取解析。

2.组件可达性未验证。部分软件的配置文件与软件源码并不对应，配置文件中记录的组件并没有被实际引用，此问题有希望通过分析软件程序调用关系图开展进一步分析验证。

3.缺少基准数据集。对于当前开源及商用的检测工具，没有一个基准数据集可以作为评价标准，去衡量各个工具的优劣。

陈碧欢：

各个SBOM标准之间的相同点在于他们的主要目标都是列出软件产品中所使用的依赖，包括许可证信息、版本信息、供应商等。SPDX更多关注于管理软件的许可证信息，而CycloneDX更多关注于软件中依赖的组件及存在的漏洞信息。选择SBOM的标准在于如何使用SBOM中的信息，以及是否有足够多的工具和库能够支持所选择的标准，这将直接影响到能否顺利地使用和维护SBOM。

软件成分分析是一种用于确定软件中所使用的各种组件及其版本、以及组件之间依赖关系的技术，可生成SBOM。该技术是软件供应链风险分析的基础技术，SBOM的准确性会极大地影响各类风险分析的准确性。根据组件的使用方式，即组件依赖引用、组件源代码拷贝或二次开发，软件成分分析可以分为基于包管理器的成分分析技术与基于代码指纹的成分分析技术。基于代码指纹的成分分析的主要思路是为每个软件包版本生成独特的代码指纹，然后将目标软件项目的代码指纹与这些软件包代码指纹进行匹配，从而确定所依赖的第三方软件包及其版本信息。代码指纹是在一定程度上反映代码词法、语义等特征的一种代码中间表示形式。代码指纹的选取设计对于软件成分分析的效果有着极大的影响。二进制代码的词法特征主要有指令、符号等，结构特征主要有控制流图、函数调用图、程序依赖图等；而源代码的词法特征主要有代码文本、符号、关键字等，结构特征主要有抽象语法树、程序依赖图等。目前的主要挑战是组件库的持续构建、基准数据集构建、二进制分析、以及分析效率与准确率。

陈森：

在处理软件成分不明确的问题时，不同的软件物料清单（SBOM）标准被相继提出以列明软件产品中使用的所有依赖项。然而，目前尚不存在一个广泛认可的“大一统”的SBOM标准？因此选择合适的标准需要根据具体的应用场景来判断。在决定使用哪种SBOM标准时，需要考虑多个因素，包括代码类型（如源代码或二进制文件）、编程语言特性（尤其是是否使用包管理器）、以及是采用静态解析还是动态分析方法等等。在软件成分分析的领域中，面临的主要问题和挑战包括1)缺乏统一的定义和精度问题。为了解决该问题， fse 23会议上分享了我们的工作成果。研究旨在为软件成分分析提供更清晰的定义和提高分析的准确度，这对于软件供应链的安全性和可靠性至关重要。2)不同的技术流派，如数据流派和技术流派，对精度的影响各不相同。

观点讨论

@陈碧欢：@陈森有提供基准数据集哇？现在每个工作都是自己的数据集还不放出来。。。

@陈森：提供了人工验证过的基准数据集

张源：

供应链安全风险难治理的主要原因之一就是复杂的软件组成关系难以被理清。SBOM是治理软件供应链安全的重要抓手。目前现有的几个SBOM标准共同的目的就是规范软件成分的身份信息格式，使得每个软件成分都有唯一的“身份证”，从而便于准确的分辨软件成分信息。而在具体实践过程中，这些不同的SBOM格式又对不同类型的信息各有侧重，比如说SPDX就包含许多细粒度的信息，而CycloneDX则更多的被用于漏洞扫描，至于具体应该选择哪个SBOM标准，则要根据业务需要来选择。比如粒度更细的SPDX更适用于资产管理场景，而CycloneDX则更适合用于风险预警场景。

说到软件成分分析技术，目前业界主要有基于配置文件和基于代码指纹匹配两种技术路线。基于配置文件的方案速度快，但效果依赖于包管理器与配置文件的规范程度，而基于代码指纹匹配的方案则不受这些限制，更多的被应用于二进制制品及包管理器不完善的语言，不过该方案也面临着开销大，难以大规模应用、准确性低等问题。当前成分分析技术主要面临着漏洞关联能力差的问题，虽然目前已有较为成熟的SBOM标准，但是各大漏洞库对于漏洞影响范围的描述方式依旧五花八门。因此，如何将分析出的软件成分与漏洞信息关联起来，依旧是一个难题，需要进一步去探索实践。

梁广泰：

针对软件成分分析在实践应⽤中的问题和挑战，我简单聊下：

1. 基于⼆进制的开源软件成分分析是业界的⼀⼤难点：和源码成分分析相⽐，⼆进制代码受编译环境、编译优化，⽬标的编译架构，编译混淆等因素影响，导致难度显著提升；

2. 随着开源LLM的出现，开源LLM也会成为软件组成成分分析里面的重要组件。如果针对这些开源LLM成分进行有效识别并进行漏洞预警，将会变成一个重要研究课题，值得业界关注并布局相关技术能力。

刘波：

SBOM的标准选择上Linux基金会旗下偏向推广于SPDX。部分公司和SCA厂商和SBOM工具会同时兼容格式。

标准是数据交换的一种手段，但的核心是要建立生态包括配套的解决方案，工具等所以我不在意选择那种标准。更关注那个生态好。

技术流派有：构建完通过构建框架依赖解析

、源码成分分析、二进制逆向成分分析

软件成分分析的问题与挑战：如何100%准确解析软件成分，不多，不少。困难在于语言多，包管理器多，仲裁规则不一，冗余依赖难排除，构建脚本植入式引入依赖，二进制反向依赖不准确等。

薛植元：

针对大规模扫描的场景我们遇到客户严苛的要求所以就多写了点。

SPDX是 Linux 基金会的一个开源、机器可读的 SBOM 项目。也是ISO承认的SBOM标准，其最初的主要目的是确保开发团队和公司在管理开源和专有代码时的合规性和透明度，是一种许可证管理格式。但是经过多年的发展，已经涵盖了开源组件相关的漏洞和许可证信息。特别是最新版本的 SPDX ，是根据 NTIA 的 "软件物料清单最基础要素 "标准设计的。CycloneDX (CDX)：这也是一种开源、机器可读的 SBOM 格式，由OWASP社区开发。它是一种轻量级 SBOM 格式，重点是便于在整个软件开发流程中采用和自动生成 SBOM。漏洞识别是 CycloneDX 最初的主要用例。SWID：与 SBOM 格式相比，SWID 标签更像是一种软件标识符。它通过存储软件版本的特定信息，为跟踪软件库存提供了一种简单而透明的方法。一般来说，只有 SPDX 和 CycloneDX SBOM 格式得到官方认可。SWID 格式主要用于软件识别，因为它提供的信息不如其他两种格式多。SPDX和CycloneDX这两种格式之间没有 "更好 "之分。选择哪一种在很大程度上取决于企业的具体需求。由于我们选择的格式决定了 SBOM 文档的结构以及与用户共享的方式，因此根据企业的需求选择正确的 SBOM 格式来生成 SBOM 非常重要。就我个人体感而言，目前选择SPDX的企业是更多的，SPDX的生态以及运营方式也比较好，是linux基金会在进行推广，同时SPDX也推出了相关ISO认证，这个在全球来讲是比较唯一的

SCA按照作用的风险划分：许可合规和漏洞是最主要的

场景或者算法划分：依赖、源码、二进制。

结合场景和风险，对于许可合规的最关注代码片段检测，关注漏洞和安全的最关注的是依赖检测。源码引入的场景）文件与代码片段：精度与效率，不仅与算法有关，也跟整个KB库，即开源元数据库的大小实效性准确性息息相关。代码片段的扫描效果是与算法和KB相辅相成的，代码片段的算法决定了什么样程度的代码克隆可以被检测出来，是几行代码，还是几十行代码，是仅仅copy paste 还是说做了细微的修改甚至是函数变量以及结构体的修改。除了这个，过去一直以来大型企业诟病的SCA代码片段本身最多的是过多疑似结果以及结果过于发散的问题，如何把代码片段，或者说大一点，在源码引入的情况下，把扫描结果做的尽可能收敛，这是后续SCA要解决的问题。除此之外，就是KB库的构建了，没有一个精准的KB库，即使算法再好，也无法精确的识别风险。KB库的构建第一步就是爬虫，第二部数据清洗，第三步数据挖掘，好的SCA的KB库至少要经过两到三轮的数据挖掘，才能提取出深层次的数据。我举个例子，许可证的识别，这个看似是一个很简单的问题，一般开源软件的许可证都会有一个license文件，可是如果你只去读license文件里面的license信息，那估计能够挖掘出来的许可证也就占50%左右，所以这里面设计到多种场景，多种算法的组合。再比如漏洞数据，如果仅仅通过NVD编号去跟版本号去匹配，那毫无疑问，无论是误报和漏报，都会高的吓人。带KB特征与算法特征互相作用的时候，比如说我们要做到代码片段的收敛，我们需要以目标为导向，去从海量的数据中去进一步提取特征，这就更加难了对于漏洞，大多数的SCA采用的是构建菲构建扫描的方式拉取依赖，我见过的层次50到60的非常多，还有100 200层以上的也不少，在这样的场景下，漏洞的治理是一个非常麻烦的事情，大的项目上万的漏洞如何治理的问题是一个挑战，因此漏洞的定位以及可达性也是工业界SCA的难题。

唐忱：

SPDX、CycloneDX都是描述软件成分清单的标准格式，目的一样

spdx更全，主要用于成分清单流转，能更好的支撑合规治理工作；cyclonedx更简约并包括漏洞信息，适合治理开源安全漏洞

企业或组织可按需选择相对应的标准，另外我国也正在编制国内的标准。

软件成分分析技术是构建SBOM的主要途径之一。目前软件成分分析技术的主要技术流派有哪些？

按技术类型可分为静态分析和动态分析。静态分析通过检查源代码、字节码或二进制文件来分析软件成分。静态分析技术包括静态源代码分析、静态二进制分析和反汇编等方法，用于识别和记录软件中的组件及其版本信息；动态分析通过运行软件并监视其行为来分析软件成分。

按对象可分为组件依赖分析，代码克隆分析。组件分析又可细分为对配置文件识别、对二进制依赖识别、对依赖文件夹分析；代码克隆分析可分为原文件克隆、文件克隆、代码片段克隆、语义克隆。

Question 3

刘杨：

目前已经有不少的工作致力于解决开源漏洞数据中漏洞信息不准，有效提升漏洞数据质量等问题。主要可以从几个方面吧，首先是漏洞的披露，需要通过建立更严格的漏洞报告标准和流程，确保漏洞信息的准确性和完整性，比如漏洞影响的软件及受影响版本范围的映射，漏洞函数，patch，POC等。其次我们最近的工作发现各个漏洞平台其实所包含的漏洞的范围各不相同，都包含的漏洞存在数据不一致，或者互相引用的问题，而一些平台独有的漏洞则相对信息较少，无法校验，这些问题的人工校验需要大量的人力和时间，而这需要引入更自动化，智能化，甚至群智化的解决方案，以及指定更完善的漏洞信息管理规范和标准。

至于建立公共的开源漏洞库，这本身是一件需要辩证看待的问题。一方面对于已经披露的漏洞，攻击人员在获取到漏洞的POC之后可以很容易利用并攻击一些还未修复的系统，这类漏洞信息需要尽早准确地告知安全人员，并尽快集成到安全扫描与审计工具中，这些信息的准确标注与校验通过开源的力量来共建显然是一件互惠的事情。另一方面，对于新出现的漏洞，绝大部分下游用户其实很难做到即时相应，比如我们之前的工作就发现Log4Shell漏洞在被修复后的一到两年内仍然在被不断用于攻击一些相对老旧的系统，对这类漏洞的处置或许需要从长远的角度看待对整个生态的影响，并且做好前置的防护工作后再考虑完整信息的公开，而实际落地时的规范与标准也需要安全从业人员的进一步思考。

霍玮：

在我们的研究过程中，我们确实发现公开的漏洞库存在信息缺失和错误的问题。根据我们的统计和分析，大约有70%的漏洞版本信息存在错标和误标的情况，而约80%的漏洞补丁在漏洞库中未能提供。这对我们了解漏洞、分析漏洞以及进行漏洞修复造成了较大的影响。

目前，学术界已经开始进行一些工作，以完善和校正公开漏洞库的信息。例如，针对Java的VERJava和针对C语言的VSZZ工具可以进行漏洞版本校正。在补丁识别方面，PatchScout和TRACER等工具可以自动识别和收集补丁信息。

在工业界方面，一些商用漏洞库如Synk和VERACODE在公开漏洞库的基础上进行了信息补充和错误校正。

无论是学术界还是工业界，都高度关注公开漏洞库中信息缺失和错误的问题，并致力于解决这些问题。由于软件的不断涌现和开源代码的广泛应用，每年漏洞数量都呈指数级增长。在这种情况下，单个个人或组织很难完成对漏洞知识库的构建。因此，需要学术界和工业界共同努力，共同建设和完善漏洞知识库。开源的力量也是不可或缺的。但开源建设还需要资源的投入，需要有人对贡献的漏洞信息的准确性、完备性、敏感性等进行审核，这都是开源建设中需要解决的问题。

吴敬征：

在安全漏洞数据获取及管理的过程中，确实会存在例如安全漏洞数据不披露或者错误披露的问题，如果仅从开放漏洞库中获取相关数据，那么在安全分析及数据分析中就会变得被动，同时研究进展也会受限，因此面对开源软件供应链安全分析中漏洞知识的不足和不准确性等问题，学术界和工业界应该：

1、开展独立研究。学术界可以开展独立的研究，通过深入分析开源项目的代码库，主动发现和报告漏洞。这种方式有助于填补公开漏洞库中的空白，并提供更全面的安全分析。

2、促进协作。学术界和工业界可以促进更紧密的协作，共享漏洞信息。建立安全研究社区，使研究人员和从业者能够合作，共同解决漏洞信息不足的问题。

3、采用自动化工具。利用自动化工具，如漏洞扫描器、静态代码分析工具等，来更全面地发现和识别潜在的漏洞。这有助于提高漏洞发现的效率，特别是在大型项目中。

4、推动透明度。鼓励开源项目提高透明度，主动披露漏洞信息。这可能包括设立漏洞披露政策、提供负责任的披露渠道，以及积极回应安全研究者的发现。

5、利用人工智能技术。通过采用NER等相关算法，从厂商发布的安全公告或邮件列表文本中获取漏洞相关的知识，并实现数据校对功能，主动发现开放漏洞库中存在的数据问题。

漏洞知识库通过开源的力量来共建是大势所趋，这可以体现开源合作的优势和漏洞库社会化，漏洞知识库的开源共建的优点如下：

1、建立开源漏洞知识库可以促使学术界、工业界和开源社区共同建立一个开源的漏洞知识库，该知识库应该包含漏洞的详细信息、影响的组件及其版本、已有的补丁、PoC等。

2、可以采用开放标准，使其易于访问、搜索和贡献。这有助于更广泛地共享漏洞信息，提高漏洞发现和修复的效率。

3、通过社区的参与，可以实现更广泛的漏洞知识共建。社区成员可以通过提交漏洞报告、贡献补丁、分享PoC等方式，共同完善漏洞知识库。

陈碧欢：

漏洞知识库的不准确将会直接影响到安全风险分析的准确性。我们也分析了不少商业公司的漏洞库和开源的漏洞库，均存在着不小的质量问题。因此可以从两方面来应对该问题：1）制定并规范负责任的漏洞披露流程（例如，https://github.com/ossf/oss-vulnerability-guide/blob/main/maintainer-guide.md），明确漏洞的影响组件、版本、补丁等信息，以减少漏洞信息的错误披露；2）设计自动化工具来实现漏洞知识增强，提升已有漏洞知识库的准确性。我们组也提出了基于多源知识的漏洞知识增强工具来识别漏洞的补丁和影响组件信息，帮助修复了GitLab Advisory和GitHub Advisory中的许多漏洞质量问题。

漏洞知识库应当通过开源的力量来共建。OpenSSF OSV（https://osv.dev/list）、GItHub Advisory（https://github.com/advisories）、GitLab Advisory（https://advisories.gitlab.com）都已开始在推进开源漏洞库的构建。CCF开源发展委员会的王千祥老师和梁广泰老师也在推进国内的开源漏洞知识库建设。

陈森：

面对开源软件供应链安全分析中漏洞知识的不完整或不准确问题，我们的课题组也已经进行了一些深入的研究。我们发现，数据的质量问题是一个主要的障碍，而数据的准确性和完整性对于分析结果的影响是显而易见的。因此，作为数据质量提升的坚定支持者，我认为提高漏洞知识库数据的质量是解决这一挑战的关键。

开源社区无疑可以在构建和维护漏洞知识库方面发挥重要作用。然而，目前阶段，开源社区在这方面的努力可能还面临一些挑战。其中一个挑战是社区成员的目的可能并不完全一致。不同的贡献者可能有不同的动机和目标，这可能会影响漏洞数据的质量和可靠性。

鉴于这种情况，学术界和工业界需要共同努力，不仅要利用开源社区的力量，还要确保数据收集和共享过程中的目标一致性和质量控制。这可能包括建立标准化的数据提交和审核流程，以及提供适当的激励机制，鼓励高质量数据的贡献。通过这些努力，我们可以提高漏洞知识库的准确性和完整性，从而更有效地应对开源软件供应链安全分析中的挑战。

张源：

确实，漏洞信息的精炼和汇集是开源软件供应链漏洞治理的重要基础。要解决这一问题，至少面临两大挑战。

考虑到开源漏洞的庞大数量，补全漏洞信息必然要依靠自动化、智能化的漏洞信息精炼技术。然而，一方面漏洞信息的补全必然依赖于理解漏洞成因本身，但是如何理解漏洞成因是软件安全研究的固有难题。另一方面，漏洞信息的维度非常多样，涉及的研究领域非常广泛。目前，针对漏洞信息的精炼和补全问题，尚缺乏一套成熟的系统化的解决方法。因此，当前急需学术界针对各重点问题开展创新研究，展开技术攻坚，形成可落地的方案。

在学术界开展技术攻关取得一定效果的同时，另一个痛点问题是当前缺少一个统一平台，将各种先进技术合并起来，从而构建出一个高质量的漏洞信息中台。各个团队目前主要还是单兵作战，缺乏协同，各家单位的能力也缺乏整合，因此如何构建一个大规模、高质量的漏洞信息库还是困难重重。依靠社区的方式去构建漏洞信息库可能是一个很有价值的尝试。但是有一点，漏洞治理有其敏感性，在当前的国际背景下，漏洞数据可能进一步成为国家的重要网络安全资产。因此，在强调合作的同时，还应当具有一定的安全防范意识。一方面需要加强参与者的资格审核，另一方面还需要基于网络安全法等法规，健全完善相关协作机制和漏洞数据产权的保护。

梁广泰：

学术界和⼯业界应该如何⾯对和解决这⼀挑战？

利⽤⼤模型技术增强漏洞知识库：随着⼤模型技术的发展，利⽤这些技术对现有的开源漏洞库进⾏修正和增强成

为⼀个可⾏的⽅案。这些模型可以帮助检测和校正错误信息，填补缺失数据，从⽽提⾼漏洞库的完备性、准确性

和时效性。

漏洞知识库是否应该通过开源的⼒量来共建？

是。开源的⽅式能有效地降低各个⼚商的重复⼯作，提升漏洞库构建的效率，业界GitHub Advisory，OSV已经进

⾏了很好的实践。通过集体智慧和资源共享，可以更有效地收集、验证和更新漏洞信息。目前CCF开源发展委员会供应链安全工作组正在联合多家单位推进国内的精准开源漏洞库COSV的平台建设，该平台是采用开源模式来推进的，欢迎大家关注并积极参与贡献。

观点讨论

@陈碧欢：广泰是大模型积极拥护者我们也尝试过一些，主要取决于喂什么样的信息给它

@彭鑫：大家的建议考虑了不同的角度，既有社区建设和激励机制方面的，也有自动化技术方面的

@陈碧欢：我们之前给两个国外企业漏洞库反馈过质量问题，企业完全不理我们。。。Github和Gitlab的漏洞库回复得就很积极

刘波：

当前google给我们做了一个更好的实践，开源开放OSV开源漏洞库，统一了漏洞描述的标准格式schema包括漏洞影响的purl软件包，漏洞修复建议，0-day漏洞。等已收录8万+。CCF也在建立国内的COSV对标google的osv。加上漏洞悬赏机制，加强漏洞信息透明与共享。

薛植元：

开源的漏洞信息，因为分散，未经权威/官方核验等因素给使用者造成采集，加工，合并，校验等困难。那么如果尝试用开源的方式解决这一问题，就至少票要好以下两点:1统一信息发布源，规范漏洞信息的发布模式，规范发布信息的统一标识 (包括组件ID，对应的poc和补丁)保证信息，保证使用者可以轻松的或许到相关信息，并与自己的组件准确关联 2建立可以持续激励机制，保证提供规范正确开源漏洞知识的个人或者机构，能够获得对应的回报

唐忱：

七彩通过常年的数据积累发现，漏洞知识库互相之间存在信息不一致情况，漏洞信息存在错误报出的问题，这其中包括国内外漏洞权威机构。要提升漏洞的数据质量，一方面需要漏洞发布机构完善自身报送机制流程，加强数据校验；另一方面，可考虑通过产业界、学业界、开源生态共建统一的漏洞知识库解决各扫门前雪的现状。

Question 4

开源软件供应链应用到特定领域（例如，操作系统、AI系统、智能汽车等）将会面临什么样的挑战？是否可以分享下领域应用的实践经验？

刘杨：

目前我们在SCA在具体场景落地时也确实遇到了一些独特的挑战，比如在汽车领域的组件成分分析过程中，我们发现对C/C++的组件识别能力目前是刚需，而其中又有很多汽车领域独有的系统组件和应用软件，这些数据在通用的SCA工具的数据集中往往很难收集全，导致SCA的误报非常高。另一方面，这些领域往往又是需要打通从应用层到系统层的完整的供应链，这对SCA工具跨语言，跨平台的成分检测能力也提出了更高的要求。而在AI系统中，目前大家比较关注的是AI系统训练过程中的数据安全与合规性，比如代码大模型的训练数据中可能包含了漏洞代码，恶意代码，未授权代码，用户敏感信息等，这些数据可能会导致生成的代码中也存在类似的风险，如何检测和规避这类风险也是目前AIGC需要解决的一个关键问题。

霍玮：

在这些特定领域上来讲，相关开源软件供应链最主要的特点就是规模大、供应关系复杂、木桶效应显著，比如说一个大型操作系统可能会用到上百万个开源软件包，在这样的情况下，要厘清整个系统相关的开源供应关系的工作量和难度也就非常大，另一方面，对这样一个复杂的开源软件供应链做漏洞管理、版权管理等安全工作的挑战也非常大。

在这些领域中，不可避免地会使用到商业闭源软件，这些闭源软件中同样有关联的一个开源软件供应链。比如说AI系统中会用到显卡相关的驱动软件和其他支持软件，智能汽车可能会用到非常多来自各个不同的供应商的软件，这些供应商是否愿意提供它们的完整软件物料清单来帮助我们对我们的系统形成一个完整的软件供应链视角，这一点还需要相关的软件供应链管理标准或者法规来做出约束。

在实践方面来说，针对这样供应关系复杂带来的挑战，作为系统的维护者，是很难去对系统开源软件供应链所有漏洞事件做出响应的，这个时候，维护者就需要找到系统攻击面相关的开源组件，按照攻击者攻击的难易程度划分优先级，根据这个优先级去做漏洞响应。

吴敬征：

目前，开源已覆盖软件开发的全域场景，引领新一代信息技术创新发展。但是针对特定的领域的开源团建供应链也会面临许多挑战，例如智能汽车需要满足极高的安全标准，防止恶意攻击和故障。开源项目需要加强代码审查和安全测试，确保系统的稳定性和安全性；医疗软件需要遵循严格的法规和合规性要求。开源项目需要建立合适的法律团队，确保其符合医疗保健领域的法规标准。物联网设备来自不同厂商，开源项目需要确保其能够与各种设备互联。制定通用的通信标准将是一个挑战等。详细的说，在特定领域还是遇到很多问题的，具体问题如下：

1、领域专业性不足。特定领域的软件可能需要深厚的领域专业知识，而开源社区中的贡献者不一定都具备这些专业背景。这可能导致在特定领域的开源项目中，缺乏足够深度的专业贡献。

2、社区参与度不足。一些特定领域可能缺乏大规模的开源社区支持，导致开发者和贡献者的参与度不足。这可能限制了项目的发展和创新。

3、安全性和隐私问题。特定领域的软件可能涉及敏感数据或个人隐私，因此安全性和隐私保护成为关键问题。开源项目需要更强调安全性，并采取相应的措施来保护用户数据。

4、行业标准和互操作性。在一些行业中，存在特定的标准和规范，开源项目可能需要与这些标准保持一致，确保软件的互操作性。这可能需要更多的协调工作，以满足行业要求。

5、持续集成和部署：特定领域的软件可能需要进行长时间的持续集成和部署，以确保稳定性和可靠性。这可能需要更先进的开发和测试工具，以满足特定领域的需求。

解决这些问题需要在特定领域建立更加专业的开源社区，吸引相关领域的专业人士参与，同时需要更有针对性地制定开发流程、测试流程和社区治理策略。不同领域的实践经验有所不同，例如医疗健康领域，开源项目需要遵循特定的医疗标准和合规性要求。实践中，开发团队需要密切关注并确保项目符合HIPAA（美国健康保险可移植性与责任法案）等相关法规标准。在安全性和隐私保护方面也要求甚严，由于涉及敏感患者数据，因此安全性和隐私保护至关重要。开源项目需要采取加密、访问控制等措施来保护患者隐私。在医学图像处理方面，开源项目可以应用于CT扫描、MRI等图像的分析和诊断。实践中，需要考虑算法的准确性、速度和可扩展性。另外，在智能汽车领域则更需要注重自动驾驶算法的精确性，在实践中，团队需要通过大规模仿真和实际道路测试来验证算法的性能和安全性。车辆之间的通信和与基础设施的互联是关键，因此开源项目需要考虑车辆通信协议的制定、安全性和实时性等问题。

陈碧欢：

我跟刘老师和霍老师的观点比较类似。

AI系统和智能汽车都具有复杂的软硬件技术栈。AI系统从底层的硬件、操作系统、驱动，到上层的深度学习库、AI应用，同样地，智能汽车从底层的硬件、操作系统、中间件，到上层的功能软件和应用软件，各层之间依赖复杂，生态各异。因此，厘清其软硬件供应链本身就是一个很大的挑战。我们目前做了一个针对AI系统的依赖缺陷分析，不少依赖缺陷都是各层之间的依赖兼容性问题导致的。

陈森：

我们在操作系统供应链和智能汽车供应链方面做了一些工作。对于操作系统，我们的主要关注点是评估漏洞是否真正构成威胁，即进行深入的漏洞POC验证。这不仅涉及识别潜在的漏洞，还包括评估这些漏洞在实际操作系统环境中的实际影响。在智能汽车领域，我们的重点是对固件的组件进行详细的成分分析。这项工作与汽车行业的特定漏洞数据集相结合，以确保我们的分析既全面又具有针对性。在这方面，我们特别强调场景适配的重要性。例如，智能汽车固件中可能包含一些特有的模块，这些模块在安全分析时需要特别考虑。这样的场景特定分析有助于更准确地识别和解决潜在的安全威胁。我们的实践经验强调了在应用开源软件供应链到特定领域时，必须考虑到每个领域的独特性和特定需求。

张源：

针对问题4，近几年，我们复旦白泽团队对无人驾驶安全领域展开了很多研究，也同相关企业进行过多次交流，那我就无人驾驶汽车系统为例，谈谈看法。

在与企业的交流过程中，我们发现，无人驾驶汽车是一个AI模型与各类软硬件系统高度耦合的信息系统。AI模型、软件系统和硬件系统互相影响，均有可能存在安全风险。因此，在无人驾驶系统中，供应链进一步复杂化，形式更加丰富，内涵进一步扩大。涵盖软件代码供应链、AI模型供应链，以及硬件系统的供应链等多个方面。因此，其供应链治理所需的技术领域需要进一步扩增，面临的挑战更多。

在供应链范围扩大的同时，关于供应链安全的定义和概念也进一步扩增。在系统各模块高度耦合的情况下，向以往一样，单独考虑软件代码的供应链安全已无法保证系统整体的安全。例如，某些代码软件层面的低安全风险，可能与模型产生联动，从而成为高安全风险。总体来看，无人驾驶系统的供应链安全分析更为复杂，进行系统性整体安全评测的难度更大。

梁广泰：

针对操作系统领域，很多软件都是基于C/C++开发的，没有很好的包管理软件，加⼤了供应链分析的难度。针对这

种情况，企业可以构建⾃⼰的可信中央仓，通过在组织层⾯规范三⽅库的引⼊流程，来弥补⼯具的不⾜。

刘波：

OpenEuler作为基础OS底座供应链安全已在2021提前布局规划，已在2022-2023年建设了SBOM ，可重复构建，敏感信息扫描，恶意软件扫描，签名，自动化发布部署等。详细可以看openEuler安全委员会社区发布 2023年CCF大会供应链安全分论坛分享。

薛植元：

最近在汽车行业遇到SCA的需求是比较多的，就以汽车为例，目前中国已经成为了全球第一大汽车出口国，不仅如此，中国还是全球汽车零部件供应链的中心，有一级二级供应商数千家，所以面临的开源治理挑战也应该是巨大的。而当面临软件定义汽车时代，我们面临的挑战是，如何在数亿行代码中找到开源风险，以及如何为开源风险治理定义优先级。一个典型的智能座舱，可能包含3到4个操作系统，我们为一个中国头部主机厂扫描过超过400G大小的代码库，结果是上万个代码片段以及数万个漏洞，在这样的结果中如何使软件开发人员快速定位风险，是最重要的。从代码片的收敛角度，我们开发了基于目录结构文件系统以及代码片三种特种相互作用的源代码扫描算法，使得相同开源项目和版本的扫描结果，无论是文件还是代码片都可以归一，这样大大提高了扫描效率和精度。从漏洞角度来讲，我们推出了漏洞定位以及可达功能。通过对CVE进行文件级别的定位，我们可以初步排查出用户代码库是否包含了漏洞所在文件，这基本上可以排除了超过50%的误报，进一步，我们通过AI算法提取出了漏洞所在的函数并通过程序分析中的AST以及Call graph算法提炼出漏洞函数在组件内、以及组件间的传播和调用关系，实现漏洞可达功能，这样基本上可以排除90%以上的误报，为客户节省了大量时间。

除此之外，以合规为导向，为国外主机厂提供100%完整的SBOM清单，是非常具有挑战的。德国智能汽车为例：SBOM 的完整性包含了子模块的SBOM、主机厂对于供应商的合规要求比较严格，需要自动化却分Declare 以及include license等，这对于算法和工程化的要求十分巨大，这不仅需要对组件下所有的目录结构文件系统做特征计算，更要处理相应的不同组件、文件超复杂的血缘关系

自由讨论

@黄凯锋·复旦大学：“除此之外，以合规为导向，为国外主机厂提供100%完整的SBOM清单，是非常具有挑战的” ——想请教一下薛总，目前汽车主机厂对于SCA的需求是用来满足内部代码质量管理的需要，还是有为了满足在某些国家合法销售的需求？关于SBOM目前比较主流的标准在用的是哪个？@薛植元

@薛植元：如果是国内主机厂，那做开源合规就是为了出口，以及满足ISO21434的要求（不能包含6个月之内的已知漏洞）；如果是国外的主机厂，比如德国，那就是为了满足整个欧盟极其严苛的知识产权保护，开源合规就是其中一条，当然ISO21434也是国际上通用的用来做汽车安全性认证的强驱动

唐忱：

操作系统方面，其生态内含大量开源软件、开源组件，需对其上游开源依赖实时监控，形成安全问题闭环机制。实践方面，华为OpenHarmony社区订阅了七彩威胁情报服务，每日获取上游的依赖版本更新信息、新型漏洞信息、漏洞修复更新等情报。

智能汽车方面，车机系统大量软件外包，车厂拿到的多为软件成品或固件，对二进制成分分析要求较高。

AI系统方面，大语言模型的代码生成的训练集大量使用开源代码，主要急需规范大模型的训练样本。

Question 5

霍玮：

我觉得一方面是跟跑，在顶级社区上增加贡献者，正如武延军老师他们所做的那样，另外一方面，还是要开发自主可控的、关键的基础软件，并借助产业界的力量，形成以基础软件为核心的软件生态。在软件生态形成的过程中，反思当前软件供应链风险的引入因素，建立机制和组织，最大程度的缓解，从而最大程度避免相关风险

吴敬征：

近年来，随着开源软件的广泛应用，其安全风险得到了广泛关注，为了增强软件供应链的安全性，国际上各组织推行了一系列框架、标准和要求。2021年，拜登发布14028号行政令，要求联邦承包商必须维护SBOM才可以与美国政府合作，随后，SBOM的最小组成元素发布，开源软件的透明度得到广泛关注。近年来围绕开源软件供应链安全和合规这一主题，各组织机构提出了多种方案。比如，Linux基金会推出多个项目，比如SPDX（目前国际最流行的SBOM格式规范标准），OpenChain（开源许可合规国际标准）等， Google提出SLSA框架，确保软件构建和部署过程的安全性，防止篡改源代码、构建平台以及构件仓库而产生的威胁。容易发现，当前供应链安全相关标准框架等都由国外主导，国内正在追赶，那么在之后的发展中，为缩短差距，力争占据主导地位，需要开展相关措施：

1.应积极组织并推动相关高知名度企业和机构形成生态联盟，共同应对开源软件供应链安全问题。通过共享资源、技术和经验，可以加速研发进程，提高整体竞争力。

2.为了规范和引导产业发展，应制定和完善相关标准和开发框架，比如软件物料清单格式规范标准、开源软件安全合规开发框架等。这有助于确保产品质量和技术规范，减少无序和混乱的发展态势。

3.应积极推动工具链的开源开放，借助社区的力量，鼓励更多人参与研发，同时也可以提高工具链的可用性和普及度。

4.国内知名企业或机构应积极争取国际顶级社区席位，参与制定相关规则和标准。在开源社区中拥有更多的话语权，能够更好地引导和规范国内开源软件供应链安全的发展。

5.建立完善的安全审查机制。对于开源软件供应链中的各个环节应建立完善的安全审查机制，确保产品的安全性和可靠性。同时，应加强与国际社会的合作，共同制定和执行安全审查标准。

陈碧欢：

Google在2021年发布了open source insights（https://deps.dev/），Microsoft在2022年2022年将Secure Supply Chain Consumption Framework (S2C2F)贡献给了OpenSSF。国内的CCF开源发展委员会的CCF开源供应链安全工作组在推动中国体系自主可控的开源供应链安全技术，中国信通院的信息通信软件供应链安全社区也在推送安全标准体系的建设。国内的SCA厂商也很多，但是似乎开源开放的力度略少，可能还是需要企业更多参与。

陈森：

国内各方对于开源软件供应链的关注是真切希望为这一生态的发展贡献自己的力量。我个人已经加入了一些开源社区，但我感到目前的参与程度还不够深入，这主要是因为社区的需求与个人研究之间的结合还不够紧密。在我们的课题组中，从博士到硕士，乃至本科生，他们都是推动这一领域发展的主力军。因此，如何让他们更深入地投入到开源社区的建设中，同样是我们需要重点考虑的问题。真正高效的共建是迫切的。

张源：

想要构建完善的供应链安全生态，单靠某一家或是某几家单位是难以实现的。为了应对竞争，弥补与国外的差距，我认为政府主管部门、企业和科研单位之间应构建完善的沟通机制，互通各自的工作进展，都有什么需求，通过合作一方面可以发挥各个单位和团队的特长，比如说政府的监管职能很难靠某个企业来推动，再比如单靠科研单位也往往难以实现将科研成果转化为成熟的工业级产品。另一方面，这种合作也可以填补各自的短板，减少重复的资源投入。

梁广泰：

我的建议是合理依托国内相关平台组织（如CCF开源发展委员会、开放原子基金会等），号召多家单位共同推进相关标准、基础设施类平台建设。快速形成合力。

基础设施类标准或平台尽量以社会公开、社区开源方式共建，为中国整个产业提供基础设置服务，避免各家单位重复造轮子。在基础设施之上，各家单位良性竞争，围绕具体子方向打造竞争力产品。

刘波：

不能否认国际走在前面，国际有开源/创新的土壤，国内这块不管教育还是体制上还是起步初期。

建议国家牵头如开放原子基金会，加大软件供应链安全工具链的开源开放力度。让更多的企业/大学一起共建。对于根技术如fuzz引擎，通过智能化手段漏洞挖掘技术，二进制成分分析等技术进行突破。

薛植元：

目前国内的标准团体尽管五花八门，但是感觉并没有形成合力，以及没有有效的成果产出。建议不要重复造轮子，起初先多多参与国际合作，学习并贡献国际化标准基金会的工作，使得国内厂商贡献和参与的权重逐渐加大，不至于被随意取代。在参与的过程中，逐渐形成自身特有的协作模式，但千万不要闭门超车，亦需要引入国际力量来参与，形成相互认证、兼容、协作的生态，只不过比重和侧重不同。开源本身就带有强烈的国际化色彩，单独一个国家大概率很难完成如此艰巨的任务。

唐忱：

国际社区里能参与要提升参与程度，一方面紧跟新型技术演变，一方面提升国际社区话语权。打铁还需自身硬，也需要提升国内的软件供应链标准化、规范化、生态的成熟度，这是一个大工程，政用产学研需要合作协同。

Question 6

刘杨：

总体而言，随着安全漏洞和攻击事件的增多，开源软件供应链的安全性和合规性将会变得越来越重要，而对相关工具的检测能力也将提出更高的要求，尤其是在大模型被广泛应用于程序开发之后，对于更细粒度的程序识别与检测能力有了更高的要求。其次，在识别之后，对于开源组件的来源、安全性、合规性的透明度和可信任性也将逐渐成为关注焦点。此外，开源治理不是简单地通过某一方的努力就能快速见效的事情，这需要各方利益相关者，比如学术界，工业界，以及政府监管部门，从标准，方法论，工具，到监管各个层面的互相配合。

难点和挑战其实之前已经讲了很多，主要在数据的完备性，SCA的准确性，以及风险处置上，数据方面，如何解决组件数据，漏洞数据，许可信息等数据的完整，准确，可靠，尤其是一些细分的垂直领域，是目前需要解决的重点。准确性方面，如何有效降低误报，减轻人工负担，从而加速SCA工具的持续集成及自动化也是一个重点问题。风险处置上，由于风险发现和修复往往是两拨不同的人员，需要进一步结合安全和开发的实际情况，提出更妥善的风险处置措施。

从研究人员的角度，首先软件供应链的不仅是单一的技术问题，研究人员需要在数据分析、机器学习和网络安全等方面增强自己的能力，以应对不断变化的技术挑战。供应链治理还涉及法律、管理和政策等多个领域，研究人员需要注重跨学科和领域的学习和思考。此外，研究人员还需要积极与业界合作，了解实际问题和需求，使研究更具应用价值。最后，研究人员需要比较清楚地了解开源生态系统的运作机制，最好能够参与到开源中来。

霍玮：

近几年来，开源软件供应链安全成为关注的焦点，且被推到了一个前所未有的高度。开源软件供应链因具有开源软件使用广泛、依赖关系普遍且复杂、开源许可体系繁杂、开源托管平台很大程度上依赖于国外等特点，其安全问题更加突出和显著。且目前开源软件自身的安全状况持续下滑、开源项目维护者对安全问题的重视度和修复积极性较低、企业因使用开源软件而引入安全风险的状况更加糟糕。

但另一方面许多机构和企业更加关注开源软件供应链安全，一些机构和企业基于规范的流程，在开源安全治理工具的辅助下开展相关工作。这些经验、方法和工具还需要进一步的持续推广和应用。

对立志从事开源软件供应链的研究人员的建议：

深入了解行业痛点，更好地理解行业的实际需求，着眼于解决当前供应链领域的难题，从而为开源软件供应链治理贡献自己的一份力量。

软件供应链安全治理并非纯粹的技术问题，而是是人、流程和知识的问题，在解决软件研发过程的供应链安全问题时，需要贴合SDLC（软件开发生命周期）考虑供应链安全风险，软件供应链上每一个环节的安全问题，都有可能成为黑客攻击的切入口。

开源软件供应链各个环节的风险识别技术需基于新的场景和模式进行相应的补充和优化，例如物联网和人工智能场景，当前对其分发市场的研究仍处于初级探索阶段, 新的场景在攻击面上也会有多样的变化, 带来了新的挑战。研究人员要持续关注最新领域，最新动态。结合新型技术，例如知识图谱、人工智能、深度学习、LLM等技术帮助实现开源软件供应链的知识分析、管理和评估。

吴敬征：

在开源软件供应链治理的发展趋势方面，我们可以预见到一系列变化和演进，这些趋势将在未来对整个开源生态系统产生深远的影响：

1.推进标准化和规范化。随着开源软件供应链的复杂性和规模的不断增加，标准化和规范化将成为治理的重要方向。这意味着统一的规则和标准将被制定，以确保供应链各个环节的合规和安全。

2.提高安全性和可靠性。安全性和可靠性一直是开源软件供应链的核心问题之一。未来，越来越多的组织将致力于开发和采用各种技术和工具，以确保开源软件的安全性和可靠性。

3.提高开放性和透明性。随着对开源软件供应链的信任需求不断增加，开放性和透明性将更加重要。这意味着供应链的可见性和可审计性亟需提高，增加软件透明度并减少潜在的风险。

在面对开源软件供应链治理的未来发展，我们必须充分认识到一系列难点和挑战，这些问题需要创新性的解决方案，以推动整个生态系统向更健康和可持续的方向发展。目前的难点及挑战主要有以下几点：

1.可持续性的挑战。许多开源项目面临着人力和资源的有限性，项目的可持续性成为一个突出的挑战。如何确保项目能够长期稳定地运行，吸引和保持活跃的贡献者，是需要深入思考的问题。

2.安全和合规平衡的难题。在开源项目中，确保软件安全性和合规性之间的平衡是一个复杂的难题。如何在保证项目安全性的同时遵循法规、标准和隐私要求，需要制定明晰的策略和技术手段，避免在追求安全性时牺牲合规性。

3.供应链的可见性难以实现。由于开源软件供应链的多样性和复杂性，对供应链的可见性难以实现。使用者难以了解开源软件的成分组件信息，当前市面上的软件成分分析工具也并不能做到精准分析，增加了治理的难度。

4.知识共享和学习曲线。开源项目的治理经验和最佳实践需要得到更广泛的共享，但建立这种共享机制并降低新项目和贡献者的学习曲线并非易事。创造性地构建一个有效的知识传递平台，以促进经验和智慧的分享，将是一个关键的挑战。

5.开源项目的法律和法规适应性。随着数字时代法规的不断演进，开源项目需要不断适应新的法规和法律环境。这包括了解、采纳和遵守适用的法规，从而确保项目的法律合规性，同时避免可能的法律纠纷。

6.社区治理的复杂性。开源项目通常由多个参与者组成，包括开发者、用户、组织等，其治理涉及到复杂的社会和组织动态。解决社区治理问题需要深入了解各方的需求，建立高效的沟通机制，以及制定公正合理的决策规则

对于立志从事开源软件供应链的研究人员，我建议可以深入了解开源软件的发展历程、现状和趋势，了解行业当前的难题和挑战，从行业需要切入，掌握相关的技术并能够保持对最新技术的了解和应用，积极参与到开源社区和开源项目中，同时还需关注相关法规和政策的变化，确保所从事的研究和实践符合法规和政策的要求。另外，研究人员还应注重研究成果的实践应用，与实际场景结合起来，共同推动我国开源软件供应链的治理和发展。

陈碧欢：

开源软件已经全面渗透到各个国民经济重点行业并成为行业发展的重要基石，并已经上升为国家级战略。因此，开源软件供应链风险分析与治理未来可能会成为国家基础设施。目前被动的（即事后的）风险分析做得比较多，但是风险治理做得相对较少（例如受漏洞影响后如何自动修复漏洞或者如何自动升级到兼容的安全版本等）；此外，主动的（即事前的）防御工作做得也被比较少。对于研究人员来讲，可以多看看企业的实践分享和报告，找准痛点问题再去做相关的研究工作，并试着去做落地应用。

陈森：

在开源软件供应链治理领域，我主要关注两个核心方面：漏洞POC验证和恶意行为剖析。这两方面对于深入理解和有效管理供应链安全至关重要。

首先，漏洞POC验证的重点在于减少误报并真实地展示潜在风险。这一过程不仅涉及到识别漏洞，更重要的是评估这些漏洞在实际环境中可能造成的影响。这有助于确保资源得到有效分配，优先解决那些最有可能被利用的漏洞。其次，恶意行为剖析的目的是让安全分析人员更深入地理解恶意攻击链和恶意行为的本质。通过这种深入的剖析，可以发现攻击者的策略和技术，从而为开发更有效的防御策略提供基础。

张源：

当前开源软件供应链的整体发展趋势是体系化和规模化。与传统安全产品单打独斗的情况不同，软件供应链的治理需要构建供应链全流程的安全体系，通过多种工具和系统的协同工作，来保障软件生产、发布、运维和治理的各个生命周期的安全。这也就意味着相关技术和工具要在效果和运行开销上均具备出色的表现，这也是传统安全研究很多难以被应用于供应链治理场景的原因。

对于立志从事开源软件供应链的研究人员，我建议大家应多从实际问题和需求出发。一些表面上的工程和实现问题后面可能有广阔的科研价值。比如我们在漏洞情报采集的过程中，发现当前漏洞信息中许多重要的信息存在缺漏，比如说开发人员最关注的补丁信息。基于这个发现，我们研究出了针对漏洞补丁信息的自动化增强技术。

梁广泰：

关于发展趋势的一些看法：

1. LLM技术将会越来越广泛的应用到开源供应链安全治理场景，包括公开漏洞自动分析、隐匿漏洞补丁识别、0day漏洞分析、恶意成分识别等；

2. 围绕基于LLM的软件体系如何布局合理必要的SCA技术，将会很快成为一个研究热点，具体问题包括：如何为LLM提供安全可靠的水印技术防止LLM被滥用；如何进行开源LLM版本溯源；如何针对LLM模型进行漏洞关联、预警；如果面向LLM提供license合规方面的检测等。

刘波：

开源软件供应链安全如安全一样是永恒的话题，对个人是一个长期积累和发展好方向。可以多看看业界前沿技术，论文，优秀的开源项目，要善于洞察，给出分析结论/提炼个人总结建议/实践/创新点，总结分享给他人才是技术理解的升华。

技术上和新业务场景陆续涌现例如 SBOM--》XBOM 包括运行时 O-BOM， AI产品都AI-BOM等。

薛植元：

AIGC的发展给开源软件供应链安全带了了更多的挑战。首先，AIGC给出的代码会给我们提供有高危漏洞和许可证风险的代码，这在我们日常研究中已经发现了很多。但是我们无法阻止大模型的大趋势，如何在企业的开源治理中避免这类风险就变得至关重要。而且大模型会对开源代码进行微调，但是可能出现的变化更具多样性，这就给SCA工具带来了更大的挑战，尤其是代码片段扫描，甚至需要语义理解的能力。同时，我们也在对AIGC能对SCA工具带来的潜在价值进行探索。比如进行组件推荐，大模型比人类更了解的不同指标（安全性、活跃性、社区健康度等），AIGC 能够就哪个组件更适合使用提出建议。其次，AIGC 有能力发现项目中的漏洞，SCA 产品可将其作为附加功能，帮助降低误报和漏报率，尤其，AIGC在未来自动化修复漏洞方面，将会发挥巨大的作用

尽管厂商很多，但是能解决实习需求的非常少，具有核心技术护城河的就更少了，尤其中国，大多数厂商在做同质化的基础功能。另外，在经济寒冬之下，未能获得市场价值的公司未必可以持续长久。因为，个人建议，想要从事开源软件供应链研究的朋友，尽可能从实际应用场景以及中国的产业背景出发，利用先进技术但同时又要注重实际落地效果。几个相关技能，在这里推荐大家了解一下：1、开源社区协作与分发的方式。这是进行合规治理的基础，也是从源头去提取SCA工具源数据特种的基础 2、人工智能与大数据技术。面对超过万亿行代码的处理与特种提取，甚至是提取之后再提取，没有大数据以及AI的辅助是不可能做到的 3 程序分析基础。AST 数据流控制流等技术，会赋予传统文本分析为基础的SCA以语义分析的能力，无论是漏洞的可达性分析亦或者是AIGC代码生成的分析都需要使用程序分析技术来作为基础技术 4. 软件知识产权。开源的生态基础是许可证，而对于开源合规治理来说，权利与义务是如何体现在复杂的计算机程序代码中的，这绝对不仅仅是法律的范畴，更加是一个包含了软件工程的跨学科难题。

自由讨论

@彭鑫：@薛植元 AIGC给出的代码会给我们提供有高危漏洞和许可证风险的代码，这在我们日常研究中已经发现了很多：确实，一度还有一些人认为因为代码会越来越多被大模型生成，所以代码质量会越来越高

@薛植元：我们的调研发现 AIGC目前生成的T2级别以上片段引入风险远超开发者自身写的。

@唐忱：@彭鑫为啥生成的会高很多呢，是因为开发人员写的时候人为解决了很多吗？

@薛植元：国外高科技大厂国内部分，都会禁止这样的片段引入这是开发规范的一部分。但是AIGC不会，所以从开源代码中通过上下文敏感的等技术学习来的。

@彭鑫：@薛植元其实就是说大模型生成代码时倾向于能抄就抄？尽量把别处的代码搬过来改改就提供给用户？

@唐忱：那就是人编写的多了一块开发者的规范约束但是感觉只限大厂

@薛植元：@彭鑫这一块通过我们的调研和测试发现接近30%的AIGC生成代码都有T2级的代码clone 比例还是很高的。我们简单的认为这跟用来训练的代码数据集大部分是开源代码相关以及用到的DSL 上下文敏感技术强相关

唐忱：

从个人视角看，软件供应链治理将来会向规范化、标识化、AI化发展。首先，国家针对相关领域正在出台一系列标准，包括软件供应链的专题国标，软件成分清单的国标，软件供应链中的供需双方会越来越规范；其次，国内的开源生态也在发展壮大，例如一些开源社区已经在着手研究软件供应链的细粒度标识化问题；最后一些新型技术将会在软件供应链治理中发挥重要作用，甚至改变现有治理规则和体系。

需要解决的问题包括：供应链识别准确性、漏洞准确性、供应商的识别。对软件供应链的研究人员建议多应用新型技术和科研成果，解决目前产业界的实际问题。

自由讨论

@冯大为：感谢各位老师的精彩分享，不知各位老师对于开源智能模型中潜在的安全问题如何看待？是否有相应的技术手段可以识别、追踪、修复开源智能模型中潜在的安全问题？如何建立开源智能模型的供应链安全机制？

@彭鑫：开源智能模型中潜在的安全问题有哪些？除了一般的软件漏洞问题，是否还有数据带来的危害传播（例如有毒数据进入训练语料后对模型以及此后微调等产生的后续模型版本的影响）？

@陈碧欢：这块的安全问题定义是不是也还不是特别清楚。

@冯大为：智能模型的安全问题确实如@陈碧欢(复旦大学) 老师所说还没有清楚的定义，但诸如数据投毒、隐私泄露、提示注入、对抗攻击等是被验证过的一些安全风险~

访谈结束