软件供应链安全: 学术洞见与产业方案的双向奔赴

===

“ 软件供应链安全，是学术界和工业界的共同热点，学术洞见和产业方案双向奔赴，有机会形成根技术和新质产品。”

前传：偶遇群星璀璨，开始追剧

2021年，我在B站ChinaSoft优秀青年学者论坛，看到复旦大学陈碧欢老师的软件供应链演讲，后续在一个厂商交流群满心欢喜加上他的微信。非常合拍的是，陈老师有很长一段时间，高频组织在线会议，大江南北、赤道两侧、东西半球、来自十多个顶尖名校的众多软件供应链学者，都出现在他组织的视频会议里面，我就幸福地追剧、提问、催更。我当然是CodeWisdom的铁粉，不过直到3月12日在开源生态与软件供应链研讨会，才现场见到陈老师真神和领军CodeWisdom的彭鑫教授本尊。研讨会内容很硬核，我整理一篇笔记，践行社区志愿者、知识搬运工职责。

感受：学术洞见与产业方案的双向奔赴

CodeWisdom有期微访谈，有个工业界的嘉宾感慨，学术界说的每一个坑，工业界都要踩一下。学术界的研究成果可以为产业界提供新的思路和技术基础，而产业界的需求和挑战也可以激发学术界的研究兴趣。

• 学术界通常于深入研究问题的根源，更多进行新理论探索、实验验证和基础研究，以解决更广泛、更深层次的挑战，推动领域的发展。从学术到解决方案周期长，但可以为未来的创新提供基础。

• 工业界更注重实用性和解决当前问题，倾向于快速实施或定制可行的解决方案，以满足市场需求和业务目标，解决方案的有效性和商业可行性通常比技术的原理更受重视。

这次研讨会也呈现了一个趋势，学术界和工业界的边界已经模糊，学术界的成果在工业界应用很广泛，工业界也和高校进行多层次的合作。

好奇：为什么积极参加学术活动？

走出校园快20年了，为何还回头关注高校和学术圈？原因就是第一性原理，溯源到本质问题，再去构建根本解，从我个人角度有两方面：

• 从源头校准问题定义及解法

• 学习并吸收学术界对所关注问题领域的术语规范、概念界定、理论构架。要保持严谨，不去偷换概念、朦胧实际问题，戒之慎之。

• 深入了解学术界的研究切入点、技术流派、核心算法,以及相关的开源基础软件资源。站在巨人的肩膀上，避免点错科技树，浪费宝贵精力。

• 在多重认知基础上研发根本解

• 在了解学术上游的基础上，我天天浸淫甲方研发现场，理解用户深层诉求，同时也熟悉乙方安全产品能力边界，三重认知有助于找到问题定位清晰、用户诉求强烈、厂商工具能力不匹配、尚未被解决的问题和机会。

• 啃文献、调代码、做产品、侃大山一样重要，踏实调研，研发根本解，做出能推广应用、兜底靠谱、体验舒服的解决方案，申请专利、发表论文、分享交流，此间不亦乐乎！

我从2021年初开始，以软件供应链分析为切入点，试水软件产业自身数字化的探索。选择的路线图是先基于逆向工程对软件供应链进行层层拆解，之后采用再工程幻化万千数字化场景，我认为此法门贴合第一性原理，3年后回首，实践证明亦如是。

宝矿：如果你是真剧迷？

巧合的是，上周学术界和工业界都发了两篇供应链、漏洞相关的合集帖，都很具代表性：智能化软件开发微访谈讨论汇编合集（第1-30期）,和关于漏洞闭环管理工具的杂谈| 总第237周， 如果您时间确实有限，可先看两篇，智能化软件开发微访谈·第二十九期：开源软件供应链风险分析与治理、以及银行业漏洞治理实践与展望--漏洞治理的道与术。

CodeWisdom的高频超乎我想象，陈老师那些天南海北的在线会议，内容都不在30期汇编合集里面，所以您若有空也可以往下瞅瞅本帖，每一章开头都有5个要点总结。

内容多，门槛高，若您有志于高质量发展，窄门就是捷径！

*以下内容根据会议笔记整理，顺序有所调整，错误疏漏难免，请以讲者的现场演讲内容和官宣为准，合议要点和主题要点由LLM生成。本场国防科技大学的余跃老师的OpenI主题，聚焦云计算和算力网，前瞻兼踏实，容我后期再专题笔记，学习跟踪。

目录

- 前传：偶遇群星璀璨，开始追剧

- 感受：学术洞见与产业方案的双向奔赴

- 好奇：为什么积极参加学术活动？

- 宝矿：如果你是真剧迷？

- 合议1：软件供应链安全如何变被动为主动？

    - 合议要点

- 合议2：大模型对供应链的机遇和挑战？

    - 合议要点

- 合议3：高校、企业如何分工合作、协同发展？

    - 合议要点

- 主题1：代码安全检测与验证关键技术 陈森 天津大学

    - 主题要点

    - 自主的代码安全架构设计

    - 代码安全关键技术研究聚焦安全左移

    - 静态应用安全测试SAST

        - 问题：大数据集和训练

    - 软件成分分析SCA

        - 问题：如何做代码克隆分析

        - 问题：漏洞的可达性分析。

        - 问题：识别脆弱函数

        - 问题：修复的版本选择

        - 问题：数据的质量问题

        - 问题：补丁提交commit定位

    - 代码安全技术演进

        - 问题：漏洞报告太多，哪些是需要修复的

        - 问题：poc的质量参差不齐，需要增强

        - 问题：恶意代码怎么检测并进行行为剖析？

        - 问题：POC触发漏洞有很多工作要做

        - 问题：漏洞函数如何定位，逆向捕捉

        - 问题：怎么看sonarqube？

        - 问题：依赖到什么程度才算依赖一个组件？

- 主题2：开源代码漏洞治理 张源 复旦大学

    - 主题要点

    - 供应链安全的重要性与挑战

    - 软件安全新视角

        - 问题：如何发现更多漏洞

        - 问题：如何验证漏洞严重性

        - 问题：如何开发漏洞补丁

        - 问题：如何部署漏洞补丁

        - 问题：如何及时捕获披露的漏洞

        - 问题：如何精确排查漏洞影响

        - 问题：如何有效定位漏洞补丁

        - 问题：如何快速修复相关系统

    - 漏洞挖掘是核心

    - 漏洞数据三要素

    - 漏洞数据增强：影响版本

    - 漏洞数据增强：危害性

    - 漏洞数据增强：修复补丁

    - 漏洞治理：部署补丁是主要方式

- 主题3：开源漏洞数据治理 吴苏晟 复旦大学

    - 主题要点

    - 数据分析

        - 问题：漏洞数据库补丁质量不理想

        - 问题：如何针对库、生态进行影响分析

        - 问题：如何确定漏洞影响的版本

    - Tracer: 基于多源知识融合的补丁追踪方法

    - Holmes：由CVE识别影响库及所属生态

    - Prism：开源漏洞影响版本的分析方法

    - 伏羲平台

- 主题4：龙蜥软件供应链安全体系 郑耿 阿里云

    - 主题要点

    - 龙蜥为什么关注供应链

    - 研发流程

    - 供应链安全架构

    - 体系落地

    - 体系参考了SLSA和S2C2F

    - SBOM作为体系构建抓手

    - 核心能力1：知识图谱

    - 核心能力2：统一签名服务

    - 核心能力3：可重现构建

    - 核心能力4：大规模代码克隆检测

    - 核心能力5：AI for代码安全

    - 未来规划

合议1：软件供应链安全如何变被动应对为主动防御？

合议要点

1. 安全左移,尽早防御和识别风险,减少攻击面。如编码阶段风险识别、CICD流程安全检测卡点等。

2. 供应链安全管理,识别各环节安全威胁,采取主动防御措施,如依赖准入评估、依赖链扫描等。

3. 针对未知漏洞,采取内生安全措施,使系统能在有漏洞情况下正常运行。

4. 对已知漏洞,建立跨企业的共享漏洞库、指纹库等,精确刻画漏洞根因,建立致病基因知识库。

5. 攻击造成后果时,总结攻击模式,根据模式改善防御,形成动态的管理和保障机制。

郑耿：主要是安全左移。例如：编码早期阶段识别风险；CICD自动化设置卡点，静态、动态分析设置卡点，目前误报率高，生产结合有差距；供应链管理，安全能力建设，识别体系环节每个点的安全威胁，根据分析结果做主动的防御措施和能力；安全能力建设，如软硬件结合缓解安全漏洞威胁，如可信执行能力，在更早期建设安全能力，增加攻击成本，降低安全风险。

李晓红：需要尽早防御，减少攻击面，主动识别评估，让攻击不能得逞。例如：对必要的依赖，要有可信的依赖源；依赖要做准入评估；自动化扫描，间接依赖链条也要早期发现；可利用漏洞，要能早预测；未知漏洞要有方法生成自动化测试并优化预测模型。

陈碧欢：内生安全，应对未知漏洞，有漏洞还能正常运行。

彭鑫：需要多种武器组合。例如，安全左移，cicd流程，嵌入工具，静态扫描，等等。@郑耿，工业界有多少种武器？

郑耿：针对不同产品线，有不同研发流程和工具；针对不同语言有编码规范，规范还翻译成扫描规则；也有商业扫描工具，但是假阳率比较高，需要安全工程师结合扫描结果进行人工代码级判断。

问：已知漏洞，同源漏洞如何发现？

郑耿：需要有商业数据库、自采数据库、自己挖掘的漏洞数据库，并将这些不同的数据汇集和清洗，基于这些漏洞库，对代码仓后台匹配扫描。

彭鑫：被动不可避免，被动正常，已知漏洞到了客户才暴露，如何稍微好一点、避免影响？横向类比，新冠病毒，国家防御体系高度联网，比对发现可以判断是已知的或新的病毒。软件漏洞却没做好，漏洞都是漏洞实例，报的也不准，漏洞实例真正的致病基因其实没多少，可能某一个致病基因就是某一个函数使用不对，同源漏洞、不同的漏洞致病基因是一致的，是否可以类比病毒防御体系，是可以建设国家引导、跨企业商业利益、有广泛共识的病毒库、指纹库、致病基因库。已知的不同语言的致病基因是差不多的，精确刻画漏洞的成因，业务上虽然比较难，但国家可以按照8/2原则做成标准。

陈碧欢：类似哪里冒一个新冠，要能很快感知到。

彭鑫：有些非技术原因，可能漏洞不报有利。有些厂商对上报漏洞不回复，下一个版本就悄悄修复了。

郑耿：站在厂商角度，龙蜥是厂商，申报CVE的比较多，主要是固件驱动，其实影响不大，优先级不高。在此呼吁：是否大家报漏洞的时候顺便修一下{全场大笑}。

陈碧欢：开源社区有隐藏漏洞的约定，例如要求commit不能包括cve信息，做“负责任的漏洞修复”。

陈森：左移好，越早越好；检测、修复都是单点存在，建议检测和修复要动态连接起来。以log4j为例，检测到修复时间跨度很大。全方位的防护离不开动态保障机制，也包括管理。攻击造成后果，理解攻击和恶意包的形式很有帮助，攻击可以总结出模式，可以根据攻击模式改善防御，可以根据28原则总结基础的攻击模式。

张迅晖：技术方面主动防御，开源生态研究，log4j2项目只有2个志愿者维护，也有没人维护的，生态不健康。软件健康度需要有模型进行预警。

彭鑫：评估很困难，小作坊不一定质量差，例如，汽车的小部件，质量总体可以的。

提问：CVE难直接对应到组件；是否有通用的排查方法。

彭鑫：CVE类似发动群众报信息，鱼龙混杂，更多的是从出问题的单点来报，没有细究背后的根本原因，需要超过单个企业的专业力量，例如国家力量，根据新暴露的漏洞去研究致病基因，例如访问内存模式问题，要有人去做致病基因或模式分析的事情，未来软件是信息化基础设施，出了问题，企业捂住几个漏洞可能还不够，大家有一致的目标，超出商业利益，互通有无，在信息层面抬高拉平，企业在其他场景更高质量水平上竞争。

合议2：大模型对供应链的机遇和挑战？

合议要点

1. 定义大模型供应链的安全性,包括训练数据、微调、推理等环节的数据安全和伦理安全问题。

2. 大模型生成代码便捷,但可能导致开发者对代码细节推敲不足、代码质量下降,以及代码克隆扩散的风险。

3. 黑客可能利用大模型生成攻击代码,加大了潜在安全威胁。大模型对代码语义理解存在一定缺陷,在漏洞识别等方面还有局限。

4. 需要明确大模型适用于辅助的开发任务边界,找到大模型与传统开发方式的最佳结合点,避免过度依赖。

5. 大模型生成代码可能存在许可证和版权问题。利用大模型可能会扩大系统攻击面,需要控制和管理风险。

郑耿：大模型也有供应链，它的安全怎么定义？因为LLM的训练、微调、推理引入而数据安全、伦理安全等问题，也需要关注。

李晓红：做次科普。LLM使开发者生产代码方便，审查代码也支持；LLM作为强大的知识库，解决了一些问题；供应链管理，LLM对合规性、漏洞依赖性，可以做一些支撑工作；大模型提升了效率，但它在质量安全方面也引入漏洞，有些代码未经审查、存在错误，另外LLM有时效性，要不断更新；对LLM过度依赖也可能会导致创新受限。

彭鑫：围绕软件开发，开发侧的挑战之一是傻瓜式使用大模型的危害，程序员会有依赖心理，人工写代码是决策过程，推敲一件事再往下写，llm一下子生产出来了几十行代码，测试也能通过，但是细节的推敲跳过了，囫囵吞枣照单全收会有问题，例如重复克隆的问题扩大传播。第二，是过于聪明的黑客，可以使用大模型利用漏洞，poc的源代码可能都是现成的；第三，大模型对代码语义的理解强，精确性不理想，漏洞判别涉及语义，LLM有一些效果，是机遇的一方面。

陈森：一个有趣的问题，如果我们问llm，llm刚才生成的代码有没有漏洞，它会怎么回应？{全场欢乐}，大模型不宜直接替代任务，LLM有助于语义理解，但是精确语义理解LLM还有局限，需要找到结合点；安全逻辑问题，LLM不是那么容易理解；大模型供应链的建模也有挑战。

张迅晖：一大挑战是要找准结合的点，利用好LLM的能力，精确的任务LLM表现比较差。智能软件开发，利用chatgpt api，做大模型软件应用市场，是一个机遇。

陈碧欢：确定哪些事情给大模型做，是比较重要的问题。

陈森：利用大模型，有可能导致攻击面变大，如何控制是个问题。

郑耿：大模型的产生的代码，是否有license问题？它可以生成和开源项目一样的代码。

合议3：高校、企业、厂商如何分工合作、协同发展？

合议要点

1. 企业内部对项目有不同阶段定位,如早期科研探索、预研验证可行性、业务结合产出落地等,注重最大化产出价值。

2. 学校理论创新发挥引领作用,企业关注产品研发落地,两者需要紧密合作、分工协作、共同推进,如共建平台、共享数据等。

3. 供应链安全是重要的系统性课题,需要平台企业、安全企业、研发企业、应用企业等多方密切合作。

4. 学术界和工业界要加强有效沟通,促进相互了解,共享成果和待解决问题,在特定主题上形成吸引力与合力。

5. 可借助开源社区、专业委员会、校企合作赛事等形式,促进学术界和企业界的深度交流与合作。

郑耿：企业内部对项目有精细合理的定位层级，例如，早期是和科研大所合作，先孵化；之后可以定位为预研，做简单的poc，验证可行性；之后就是和业务结合，成果输出，可执行性和陆续落地；最后是实际落地产出价值的比较完善的项目。

具体模式也很多，主要考虑怎么和生产结合，最大化价值产出的投入。例如，前沿的学术探索，我们和彭老师合作；开源合作也是不错平台，依托开源基金会等形式，在开源社区做合作探索；另外，关于漏洞的本质特征研究，大家都很关注，行业的安全厂商会用它来卖钱，涉及利益，厂商一般不会去开源合作。

陈碧欢：CCF也发挥了很好的作用，如CCF供应链安全小组，希望以开源的方式共建平台。

李晓红：学校理论层面创新，方案落地，标准规则制定，学校起到引领作用；企业关心产研落地，高校做完的研究去落地，高校有经费支持，企业提供社会服务。产学合作前提是发展软件供应链有前景，基础数据能够共享，现在cve、nvd是不是很全的，要有人去整理，也有人不愿意分享。大家为了一个共同的目标，去共享。高校很好的项目做完研究，如果没有持续更新的数据去落地，研究也会被阻碍，总的来说，校企要共建、分工。

彭鑫：产学研非常重要，供应链是重要的话题。世界运行依托软件，托付给软件越多，链条越复杂，威胁越大。平台企业，安全企业，研发企业，应用企业，要密集合作。对高校来讲，我们对工业界在实际应用中碰到的问题全貌、什么在企业中更重要，拿捏清楚比较难。站在工业界视角，供应链体系什么都需要，哪怕有些模块比较简单，但是完整的东西要先出来；工业界目标更明确，有上线的压力，需要探索不同的可能性，好用的拿来先用了再说。学术界可能对单点研究比较深，有论文、单点工具，也在做平台，例如伏羲平台里面软件供应链治理覆盖刚起步，大家要加强合作。

AI领域比较好，大家都在这个领域做事，领域进展大家都看得见，马上可以转化为生产力。供应链是个大课题，要把体系梳理清楚，要先区分什么地方是空白要去研究，什么地方已经很成熟不要再去碰，如果有成熟解决方案就不要再重复研究了。供应链看上去人人发文章，每人都在取得突破，都超过前人，但谁也不知道成果效果怎么样，心里没底，业界也不知道学术界的成果能帮助我到什么程度。

陈碧欢：每个sca都有专有的benchmark，都说自己好，如果有联盟就挺好的。

彭鑫：联盟挺好的，把各自开源的微服务变成演练和验证的基础，实践验证，大家一起建设公认的尺子，大家都自然而然承认成熟到什么程度了，避免各说各话。

陈森：学术界和工业界要加强有效沟通，目前机制没有健全。学术界参与社区，但没有很强的动机去参与，学术和工业两个领域相互了解动机也不强。只有工业界和学术界加强沟通，在一个平台上相互了解彼此，共享成果和待解决的问题，学术界渴望了解工业界的软件供应链做到什么程度了，有哪些痛点，目前还缺乏合适的条件和机会。

陈碧欢：CCF有组织类似软件供应链走进高校、厂商的活动。

陈森：要定义清晰的主题，吸引大家一起来搞一搞，高校行是否可以就一个领域，明确一个主题，例如SCA分析到什么程度了，大家就有很强的动力去专注参加。

彭鑫：学术界其实非常开放，高校最没有利益诉求，最想把问题梳理清楚，把卡点问题解决，问题特别吸引学术界的人。工业界不是特别透明，例如，有时候也请大厂来分享，但是分析的深度有限，因为工业界限制会比较多，感觉很体系化、什么问题都解决了，但是高级别的痛点是需要继续开放讨论的。

郑耿：有个例子，工业界成立容器安全联盟，就是希望建立机制，最大化的安全厂商的主观能动性，

张迅晖：我们组织开源校园大赛，组织企业把关心的问题发布到平台，学生接收、解决真问题。这样可以帮企业解决关心的、真正需要解决东西，也可以帮学生找工作、进行适配。另外，我们还有国产os专区、大家都可以去分享、互动某一个领域的进展。

主题1：软件供应链代码安全检测与验证关键技术 陈森 天津大学

主题要点

1. 构建自主的代码安全防护架构,包括底层自主静态分析框架,上层搭建自主供应链安全分析平台,覆盖SAST、SCA、PoC等技术。

2. 静态分析SAST面临漏报高、误报高等挑战;恶意代码检测则需剖析恶意行为语义。产学研合作有助于获取高质量数据集。

3. SCA代码相似性比对即克隆检测是一个难点,需准确定义特征,结合语义信息;漏洞可达性分析和脆弱函数识别也具有挑战性。

4. 需解决数据质量问题,如补全CVE描述、提交commit信息等,可借助大模型等AI技术进行数据增强。

5. 报告的漏洞需动态验证判断是否需要修复;恶意代码行为剖析需语义建模;POC生成及漏洞触发自动化也有待突破。

开源软件是软件供应链发展重要推手，提升软件供应链自主权和安全性成为国家战略，也面临卡脖子风险，需要检测与验证开源和闭源代码的漏洞和恶意代码。

自主的代码安全架构设计

底层推出自主的动静态分析框架，支撑代码安全的相关研究，上层基于SAST/SCA/PoC，搭建自主供应链安全分析平台，进行代码安全的检测和验证。

代码安全关键技术研究聚焦安全左移

问题：漏洞检测漏报率高、误报率高

问题：恶意代码检测的恶意行为剖析难

静态应用安全测试SAST

问题：大数据集和训练

产学研合作有契机，学术界开放的数据集不大；企业界的数据量大，案例鲜活。

LLM OOPSLA结合大模型和传统，赋予大模型特殊漏洞检测能力，不是通用的检测方法，即对某一种漏洞类型有效。

软件成分分析SCA

二进制比代码难一点，主要进行语义的相似性比对。

问题：如何做代码克隆分析

基于克隆比包管理器要更容易一些，关键是属性特征定义要准确。JaCC做软件成分分析，函数级、基于类的相似性比对等方法，可以试验并排除不敏感的类特征。例如，java类特征的定义，可以基于语义特征，cfg、dfg特征；要注意不是所有代码都有用，要筛选、做测试，留下有用的信息；精确识别第三方组件的特征；代码的变异点对特征来说变了，还需要设定不同语义结构改变的权值、阈值。

问题：漏洞的可达性分析。

问题：识别脆弱函数

正着做脆弱函数的PoC难，不容易到达触发函数。我们提出逆向、反着做可达性分析，先识别出脆弱函数，再查询调用它的函数；难点之一在找到脆弱函数，提交commit可以知道那些函数改变，但不一定是引起漏洞的函数，需要明确change里面那些是脆弱函数。

问题：修复的版本选择

修复的难点：找到没有漏洞安全版本、并且兼容性没问题的版本；这是多目标优化问题求解。

典型现象：log4j高危漏洞，一年后，还大量存在下游版本中。

问题：数据的质量问题

做了SAST, SCA, 可达性分析之后，是否就完美了？数据质量还有大问题。

SCA数据缺失，导致漏洞源头、类型、影响、原因等不准确。

提出利用ai解决数据增强问题，cve的描述信息经常会缺失，影响上层应用。利用深度学习算法补全cve信息，上报cve后官方也接受了我们的补全，甚至官方因此增加了必填项的强制要求。

问题：补丁提交commit定位

脆弱函数追踪，需要patch信息支撑，和之前的版本比对，找出change，这部分陈碧欢老师已经有成果。

cve缺少patch信息，界定commit是否是patch的commit。提出借助大模型理解commit代码语义，补全cve的patch信息，并实现端到端模型，训练大模型，匹配出修复patch的commits，并做ranking，再优化判断。

代码安全技术演进

问题：漏洞报告太多，到底哪些是需要修复的

问题：POC的质量参差不齐，需要增强

SAST，精确性难保证，上报太多，到底哪些需要修复，需要动态安全漏洞验证方法（高精度）；

漏洞poc，质量不同，不同平台的信息差异性非常大，poc数据虽然很对的，但是数据需要增强。

另外poc的数量是远远少于cve的数量的，设想利用poc生成找不到的poc，帮助做漏洞验证。

sca检出的漏洞，移植到其他项目、架构、平台是否也可以触发漏洞。

问题：恶意代码怎么检测并进行行为剖析？

恶意包容易识别，特征比较突出。

恶意行为剖析比较难，要把恶意行为的表征建模出来，告诉用户恶意包干了什么事情。

目前主要分析python，把恶意包常见的攻击模式构建出来。基于代码语义建模和攻击序列建模，进行恶意行为剖析，显著提升恶意行为的解释性和可理解性。

问题：POC触发漏洞有太多步骤要做

提问：poc到漏洞触发发有很长的路要走

poc形式很多，可以是step，输入一个文件、命令、文本，poc形式不是单一，验证漏洞的方式是不一样的。有些需要人工，有些输入一些信息完整。验证自动化方法。

问题：漏洞函数如何定位，逆向捕捉

提问：漏洞触发函数，逆向定位函数，是怎么做的？基于规则，规则不是那么普适性，限定了漏洞类型。

确定脆弱函数不是复杂，也不过分追求健壮。采用了加、减两种方法。一是，削减冗余代码，我们发现并定义了很多类别，如构造函数。第二，漏洞修复时，不一定发布整个版本，可以在大版本周期内，进一步分析脆弱函数的引用情况，补全信息。

问题：怎么看sonarqube？

sonar是sast的一种方式，c、cpp，sast工作类别非常多，基于程序分析进行漏洞检测的类别非常多。

问题：依赖到什么程度才算依赖一个组件？

基于源代码的依赖分析，依赖多少才算，没有明确定义。

主题2：开源代码漏洞治理 张源 复旦大学

主题要点

1. 供应链安全的重要性与挑战：手机厂商面临的供应链安全问题突显了安卓系统上下游供应链的复杂性，特别是在收集上游数据和判断下游厂商是否修复漏洞方面的难题。

2. 软件安全新视角：供应链安全被视为传统软件安全的延伸，它不仅关注自身代码的安全性，还关注上游集成下来的问题，为软件安全领域带来了新的机遇。

3. 漏洞挖掘的核心地位：在不同层次上开展的漏洞挖掘工作是系统安全攻防技术的核心，涉及多种技术手段，如动态、静态分析、模糊测试、符号执行和大模型等，以适应不同的漏洞挖掘任务。

4. 漏洞数据的三要素：影响版本、危害性和修复补丁是公开漏洞库中的关键信息，但普遍存在准确性和完整性问题，需要通过技术手段进行数据增强和精确分析。

5. 漏洞治理与补丁部署：有效的漏洞治理依赖于补丁的正确部署，这要求上游和下游软件都能及时应用补丁。自动化迁移补丁和跨语言分析工具的开发，以及对补丁集成性的检测，是提高补丁部署效率和准确性的关键。

供应链安全的重要性与挑战

2019开始，手机厂商交流是提出面临的难题，供应链安全重要。安卓系统是典型的上下游供应链系统，厂商都会定制化，如何尽可能多地收集上游数据，并判断下游厂商是否修复漏洞了？

软件安全新视角

软件供应链安全代表新的的机会，扩展了传统安全的维度。

传统软件安全：关注自身代码

供应链安全：上游集成下来的问题

问题：如何发现更多漏洞

问题：如何验证漏洞严重性

问题：如何开发漏洞补丁

问题：如何部署漏洞补丁

问题：如何及时捕获披露的漏洞

问题：如何精确排查漏洞影响

问题：如何有效定位漏洞补丁

问题：如何快速修复相关系统

传统安全做了很多工作，扫描、测试、修复漏洞，但是很多问题难做到落地，例如误报率非常高。

供应链安全给传统安全也带了了新的机会，例如，通过从上游源头、中游依赖链路、下游系统三个层面着手，全局供应链数据分析，分析上下游的依赖关系,更好地评估和发现这些上游漏洞在下游系统中的具体危害和影响面，可以更精准地识别下游的漏洞。

漏洞挖掘是核心

各个层次都有开展，内核、系统框架、新应用，有传统安全漏洞分析，也有业务逻辑相关的漏洞挖掘。

使用了多种技术，传统的动、静态分析、模糊测试、符号执行和大模型，主要是技术适配，让技术更好地服务于漏洞挖掘任务。

经典案例是人脸识别，被评为最有价值漏洞。人脸识别移动端录制、云端识别，依赖于端云协同，会出现不一致，导致任意登录。

通过智能化模糊测试，在多种关键系统组件中发现未知软件漏洞；利用移动OS访问控制缺陷检测工具，发现并预警最新手机系统的多个高危漏洞。

漏洞数据三要素

1 影响版本，公开漏洞库普遍存在漏洞影响版本信息错误的现象，人工审核有问题。

2 危害性，公开漏洞库普遍缺乏用于评估漏洞危害的信息，poc在漏洞数据库中的比例为4%，漏洞触发严重依赖于版本、配置等环境信息，缺poc，开发不愿意修改，漏洞难复现

3 修复补丁，公开漏洞库普遍存在补丁数量少，质量低。cve是社区自发性维护

漏洞数据增强：影响版本

传统方法的问题

修复前后的commit区间的所有commit都是受影响的，没有分析每个commit。

代码克隆分析，函数和修复前后的函数对比，如果修复是细微差异，就难发现。

相关工具包括V-SZZ, ReDeBug， MVP， V0Finder

思路：漏洞指纹

目标：可以有漏报，但是要精确

目标指纹刻画精确，严格符合漏洞特征的，才判断是受影响版本

漏洞数据增强：危害性

poc只针对一个版本，往往是针对最新版本开发的；需要验证低版本或者调整poc；

基于导向式模糊测试的poc迁移技术，漏洞的执行路径应该一致，可以指导低版本poc的迁移，但要注意代码重构以及代码细微差异会带来明显变化的场景。

漏洞数据增强：修复补丁

漏洞库不保含补丁信息；

漏洞数据增强，类似搜索引擎的思路

1 漏洞补丁和漏洞描述存在多维度的关联性，如漏洞类型、影响、位置，有助于定位补丁的commit；

2 漏洞描述和补丁关联弱时，引入排序模型，把commits和漏洞进行关联排序，猜出漏洞关联度高的补丁commit

漏洞治理：部署补丁是主要方式

漏洞挖掘、数据增强基础上，希望无论上游软件还是下游软件，都去部署补丁，才能让整个软件变得安全；怎样让上下游都部署补丁，是治理漏洞最关键的手段。

上游采用多分支开发和维护，有很多分支需要做补丁的迁移，在上游修复漏洞。

下游以手机为例，有多产品、多版本，内部的漏洞管理业非常复杂。

实证研究：超过80%的分支没有部署补丁，超过80%的补丁迁移需要人工参与

自动化迁移补丁：基于一个补丁，去修复其他分支；

首先要从开发者角度理解补丁的语义，如何修复漏洞；例如是函数误用、输入限制，进行危险函数替换和验证，提高成功率。

有些分支和补丁不符合前置条件，还是需要手工迁移。

下游：下游最主要的问题是不知道补丁打了没有

需要工具，可以直接对制品进行分析，需要跨语言分析能力

需要检测很多厂商的定制化修改的代码，而且需要检测细微的变化，如‘>’变成‘<’；要更聚焦于漏洞提供修复建议。

厂商交流，如何判断手机操作系统是否打了补丁，开发了两个工具，在下游内核取得好效果

* LLM: PDiff、BScout：提出了一种基于语义分析的补丁存在性检测新方法，基于污点分析等方法提取补丁的控制流和数据流语义信息，通过对上游补丁和下游内核提取语义特征向量,然后对比相似度,来判断补丁是否被集成。

【思】非常接近企业实际应用场景，实际需求都是有的，高校有的是各种金刚钻，企业缺底层的金刚钻，这些往往安全厂商提供，但是高校的工具估计更加独立、灵活，也值得甲方和高校共同去打磨，没准就能迭代出用户喜爱的新的根技术。

问题：如何移除和漏洞修复无关的代码

核心在于理解漏洞，补丁不是简单的codediff，那样很难做到精确，可以理解内在后建模（不同语言、软件建模是不一样的），分析危险函数，通过危险函数分析补丁，更好地理解漏洞和补丁；基于补丁语义分析，可以检测漏洞，分析补丁、分析影响版本。很多技术都有tradeoff， 需要叠加在一起，组合使用，才能更好地落地、扩展。

问题：业务逻辑型漏洞应对，例如闰年漏洞

漏洞不包含业务逻辑型漏洞，但是不全面。业务逻辑型漏洞的识别比安全漏洞更难识别，很多取决于业务本事，包括认证的逻辑，和业务相关，更难检测。

主题3：开源漏洞数据治理 吴苏晟 复旦大学

主题要点

1. 开源漏洞数据库的现状：当前漏洞数据库中开源软件漏洞补丁的质量存在问题，补丁覆盖率低，且常有遗漏，这影响了下游分析的准确性和有效性。

2. Tracer：多源知识融合的补丁追踪：Tracer是一种新提出的方法，通过结合多个数据源，如NVD、Debian和RedHat，来自动追踪和识别CVE的补丁信息，提高了漏洞数据库的完整性和准确性。

3. Holmes：精确识别影响库及生态系统：Holmes工具使用学习排序技术，从多个来源收集证据，对组件进行相关性排序，以识别每个漏洞真正影响的库及其所属生态系统，解决了现有SCA工具的不足。

4. Prism：细粒度的漏洞影响版本分析：Prism方法专注于分析漏洞影响的具体版本，通过精确的方法确定受影响和未受影响的版本，提高了风险分析的精度。

5. 伏羲平台的高质量知识汇聚：Tracer、Holmes和Prism等工具作为伏羲平台的一部分，提供了高质量的知识汇聚，支持高精度的风险分析和技术使能，为漏洞治理提供了强有力的支撑。

数据分析

问题：漏洞数据库补丁质量不理想

问题：如何针对库、生态进行漏洞影响分析

问题：如何确定漏洞影响的版本

每个厂商背后都有庞大的漏洞库，但是否能够支撑下游分析？

针对开源软件漏洞补丁开展了实证研究，以了解当前漏洞数据库中开源软件漏洞补丁的质量和特征。研究发现当前漏洞数据库中开源软件漏洞补丁的质量并不理想。补丁缺失情况较为普遍，当前漏洞数据库中漏洞的补丁覆盖率仅为 41.0% 左右。对于有多个补丁的漏洞，当前漏洞数据库经常会遗漏一些补丁。

Tracer: 基于多源知识融合的补丁追踪方法

针对当前漏洞数据库中补丁信息缺失和不准确的问题，提出了一个基于多源知识的方法Tracer来自动追踪CVE的补丁信息，输入是CVE的ID，输出是安全补丁。Tracer可以极大地补充或增强当前的漏洞数据库，也有助于用户更准确、更快速地识别到补丁，也适用于多补丁的场景，能召回、查准CVE，也能发现漏洞遗漏生态的情况。

*LLM：Tracer提出一种基于多源知识融合的补丁追踪方法,根据NVD，debian, redhat为基础构建引用网络,针对这些网络节点做补丁识别，综合分析漏洞报告、代码仓库、补丁注释等多源异构信息,从而精准定位漏洞对应的修复补丁代码。

Holmes：由CVE识别影响库及所属生态

现有的软件组成分析(SCA)工具依赖漏洞数据库来识别软件应用程序使用的易受攻击的库,但手动维护这种漏洞数据库的"受影响库"和"所属生态系统"信息是一项费力且容易出错的工作。现有的极值多标签学习方法由于标签库有限且未考虑生态系统因素,导致预测漏洞影响库的效果不佳。

对现有几个主流漏洞数据库中"受影响库"和"所属生态系统"两个字段的质量进行实证评估,发现存在明显的不一致性和不准确性。

提出Holmes工具,通过学习排序(learning-to-rank)技术,从多个来源收集各种关于库和生态系统的证据,证据范围cve、组件库、源码以及其他元数据，根据这些证据数据对每一个组件进行计算，对全量组件进行相关性排序,从而识别出每个漏洞真正影响的库及其所属生态系统。

Prism：开源漏洞影响版本的分析方法

更细颗粒度的工作，对于漏洞,确定其影响和未影响的版本信息是非常重要的,但由于需要安全专业知识和大量人工努力去确认每个版本,而版本数量通常很多,因此在公开的漏洞数据库中,这种受影响版本信息的质量都非常低下。

伏羲平台

Tracer, Holmes, Prism, 属于伏羲平台的“高质量知识汇聚”，为高精度风险分析和高精度使能技术提供支撑。

问题：CVE中没有细颗粒度信息，如何定位危险函数？

补丁和修改方法有共性，根据漏洞修补和类型、修改了哪些代码，关键变量是什么，可以进一步分析出危险函数。

主题4：龙蜥软件供应链安全体系 郑耿 阿里云

龙蜥的方案很成熟，领先，特地说明引用、借鉴、参与的行业实践，踏实谦逊

主题要点

1. 龙蜥对供应链安全的关注：由于操作系统(OS)的安全稳定性至关重要，且生态系统复杂，依赖众多软件包，龙蜥特别关注供应链安全，以确保整体软件生态的可靠性和安全性。

2. 研发流程中的安全评审机制：龙蜥在研发流程的每个步骤中都实施了评审机制，包括开源评估、三方依赖风险评估、编码质量评估等，确保了从源头到交付的全过程安全可信。

3. 供应链安全架构的三重目标：龙蜥的供应链安全架构旨在实现成分透明可追溯、可评估和可信任的目标，通过基础数据、原子能力和功能产品等多层次的安全体系来构建。

4. 体系落地与参考标准：龙蜥的供应链安全体系落地实施了安全态势洞察、风险防护、可信生产流程和主动安全能力建设等措施，并参考了SLSA和S2C2F等国际安全标准和框架。

5. 核心能力建设与未来规划：龙蜥在知识图谱、统一签名服务、可重现构建、代码克隆检测和AI代码安全等方面进行了核心能力建设，未来将继续完善基础数据、加强工具评估分析和全生命周期管理，以及探索AI在代码安全中的应用。

龙蜥为什么关注供应链

os安全稳定和关键，生态复杂，依赖2400个软件包，依赖知识图谱非常复杂。

研发流程

每一个步骤都有评审机制。开源评估评审，三方依赖风险评估，编码质量评估，安全可信构建，制品安全性测试和签名，可信分发，运营威胁感知，cve修复

供应链安全架构

安全目标

成分透明可追溯：组件精准；关系清晰完善；追溯能力强

可评估：依赖组件可评估，开发过程可评估，交付软件可评估

可信任：供应链组成信息可信任；风险监控与管理可信任；软件供应链可信任

安全体系

基础数据：漏洞、软件、SBOM，license

原子能力：单独的安全合规能力

功能：面向业务场景、具体业务需求的上游安全、研发过程安全、风险管理

产品：向社区用户提供安全能力支撑

安全治理：社区、行标、国标

体系落地

安全态势洞察：我的供应链是什么，有什么风险，整体情况是什么

已知安全风险防护：快速修复，缩短MTTR, 被动，有了基本防护能力

可信生产流程：生产流程保证研发安全可信，可审计，可追溯。这是slsa最高等级，但没有定义主动防御能力，需要持续供应链演进能力。

主动安全能力建设：主动防御能力，整体评价模型，供应链管理持续演进和迭代的能力。

体系参考了SLSA和S2C2F

推荐视频：

Introducing the Secure Supply Chain Consumption Framework (S2C2F) ，Adrian Diglio, Principal PM Manager of Secure Software Supply Chain (S3C), Microsoft，{目前观看次数才百来次，还是很推荐！}

An Overview on SLSA， Tom Hennen, Google & Joshua Lock, Vmware，{我曾吐槽顶级SLSA也不足以保证甲方供应链安全，这不郑老师说还有S2C2F，很高兴。}

SBOM作为体系构建抓手

基础数据建设

上游信息包括CHAOSS指标，OSS-COMPASS模型，龙蜥实际需求，共同组成龙蜥上游健康度模型

核心能力1：知识图谱

龙蜥sbom是3万多文件，上百万关系节点。

采集数据，组织成图谱，利用图谱查询api，及时发现安全合规风险。

以log4j为例，很多项目未修复，很多组件还依赖它。原因之一是企业对底层资产梳理能力不足，图谱可以可视化关系传播，影响面，影响半径，快速定位，快速修复。

供应链安全图谱项目：谷歌发起的供应链知识图谱项目，项目地址：github.com/guacsec/guac，谷歌主导，龙蜥使用并贡献。

核心能力2：统一签名服务

研发各个阶段相对离散，需要解决签名平台、秘钥、工具集等分散问题和响应的安全风险，需要向下屏蔽签名技术的复杂性，提供简单、透明、安全、高度集成的签名标准服务，让用户专注签名，不需要证书、秘钥、接口认证等复杂性。对标openssf的https://www.sigstore.dev/项目。

核心能力3：可重现构建

solarwinds事件编译构建系统被攻破，solarwinds在其下一代构建系统中，增加的可重现构建的能力。

可重现构建能够及时发现开发者或构建系统是否被攻破,从而防患于未然,避免开发者受到威胁/胁迫。

实现可重现构建需要三步::确保构建系统完全确定性;记录构建环境;让用户能够重建近似环境并验证编译结果是否匹配。

核心能力4：大规模代码克隆检测

1 谷歌、openjdk专利诉讼。谷歌引用了openjdk9行代码和api，是否天价赔偿？

2 连续修复5-6个netfilter cve问题，细究发现编码风格是高度一致，再深入分析发现都是同一个人写得代码。

代码克隆检测能力，再往上做安全检查能力。

和复旦大学进行学术合作，主要是SAGA代码克隆检测工具，源码比对和识别，克隆检测后处理。

核心能力5：AI for代码安全

借助大模型，发现源码里面是否有安全风险。

可疑代码抽取，大模型判断分析，缺陷诊断能力

未来规划

• 基础数据完善

• 安全能力建设

• 工具评价分析，攻击面管理能力

• 漏洞利用、防御、环节能力，减少漏洞影响面

• 全生命周期知识图谱，加入流转信息

• 服务能力开源

• AI结合探索

提问：是否要用知识图谱

使用知识图谱，有一些好处。例如：便于影响面分析，爆炸半径分析；识别软件生态核心组件，引导关键组件更大投入；合规相关的能力，证书污染，影响半径是什么，如何去修复；软件升级和修复策略，依赖的版本v1升到v2，升级影响分析；底层使用阿里云图数据库。