智能化软件开发微访谈·第二十七期“程序分析”讨论汇编

 CodeWisdom

“智能化软件开发沙龙是由CodeWisdom团队组织的围绕智能化软件开发、数据驱动的软件开发质量与效能分析、云原生与智能化运维等相关话题开展的线上沙龙，通过微信群访谈交流等线上交流方式将学术界与工业界专家学者汇聚起来，共同分享前沿研究进展与业界实践，共同探讨未来技术发展方向。”

程序分析

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

背景介绍

程序分析通过自动化手段对程序的功能正确性或各种非功能属性进行分析，从而发现各种功能和非功能性缺陷或者在受限条件下证明程序的正确性。程序分析在软件质量保障中扮演着重要的角色，特别是在一些具有高安全性和高可靠性要求的软件系统中。此外，程序分析作为一种基础性技术也被广泛应用于各种软件测试和软件维护任务中。那么，程序分析技术包含哪些内容？经历了什么样的发展历程？当前的研究进展及实践应用状况如何？面临哪些问题和挑战？

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

主持人

彭鑫

复旦大学教授

嘉宾

孙军

新加坡管理大学（SMU）教授

Charles ZHANG（张川）

香港科技大学计算机科学与工程系教授、网络安全实验室主任

熊英飞

北京大学副教授

陈振邦

国防科技大学计算机学院教授、博士生导师

谢肖飞

新加坡管理大学助理教授

谭添

南京大学计算机科学与技术系副研究员

王迪

北京大学计算机学院助理教授

李弋

复旦大学计算机科学技术学院讲师

董震

海德堡大学博士，复旦大学计算机学院青年副研究员，中国计算机学会（CCF）软件工程专业委员会执行委员

梁广泰

华为云软件分析Lab负责人，软件分析领域高级技术专家

狄鹏

蚂蚁集团资深技术专家，中科院客座研究员，新南威尔士大学兼职高级讲师

访谈主题

程序分析

01

能否谈一下您对程序分析的理解？例如，程序分析技术包含哪些内容，有哪些应用场景，经历了什么样的发展过程，同时存在哪些不同的技术路线和流派？

02

已有理论证明一般的程序分析没有高效的解决方案。那么，在当前的计算模型下，我们围绕程序分析技术的改进做了哪些方面的努力，这些努力是否还有意义？特别是当软件系统变得越来越复杂的情况下，我们如何解决程序分析的可伸缩性以及效率和准确性的平衡问题？围绕这些方面有哪些值得探索的研究点？

03

程序分析技术当前在企业软件开发实践中的应用状况如何？经过多年的发展，目前已经形成了哪些有效的程序分析工具？为什么程序分析工具在软件开发实践中还没有得到充分利用，甚至存在一些抵制的声音？程序分析工具在软件开发实践中的应用存在哪些问题和挑战？

04

大模型表现出了很强的代码分析和理解能力，甚至可以直接完成缺陷检测和修复等任务。那么大模型技术与程序分析技术存在什么样的关系？大模型的出现会如何影响程序分析技术及其应用的 发展？同时，程序分析技术是否也可以在大模型的构建和应用上发挥作用？

05

您对程序分析今后的发展趋势和方向有什么看法？同时，您对程序分析技术的研究者、实践者以及软件工程及相关专业的同学们有什么建议？

Q&A记录

Question 1

主持人：能否谈一下您对程序分析的理解？例如，程序分析技术包含哪些内容，有哪些应用场景，经历了什么样的发展过程，同时存在哪些不同的技术路线和流派？

孙军：

程序分析对我来说包括任何分析计算机程序行为的技术。这里的程序行为大概指的是程序的正确性、安全性、性能、质量等等。

程序分析的技术有很多了，粗略的分一下的可以分为静态分析和动态分析。静态分析是把程序代码当文本或者数学公式来分析程序行为的方法，比如数据流分析，符号执行，抽象解释等等。而动态分析则需要运行程序，因此适用于已编译和可执行的程序，比如，各种测试的方法，检测运行时错误等等。

程序分析应用场景很多，比如编译器优化，软件维护和重构，安全性分析等等。程序分析早期主要是用来做编译器优化，当然现在更多是程序安全检查等。同时，它的发展一直受到计算机硬件性能的提升、新的分析算法和工具的出现等等因数的推动。

张川：

这个问题孙军我记得写过一个不错的summary。Ander Moller和Eric Bodden的课程、熊英飞老师的课件、南大的课件都是很好的内容。我们写了一个特别是关于数据流分析的survey，也推荐给大家。survey链接如下：https://maifile.cn/est/a2656953590674/pdf。

熊英飞：

程序分析一般指静态程序分析，主要是基于语法静态分析程序运行时可能出现的动态行为。静态程序分析是重要的基础性问题，其本质是形式系统的语义性质从语法出发的可计算性，早在计算机发明之前图灵针对希尔伯特的数学计划开展的停机问题研究就是标准的程序分析问题。在现代计算机的很多方面程序分析都发挥作用，比如用于设计编程语言的类型系统，保证编译优化的正确性，自动查找缺陷和漏洞等。

现代静态分析主要有两套路线，一套是从抽象解释理论出发，通过定义在抽象域上的运算迭代计算出程序的行为。另一套是从约束求解出发，借助现代约束求解工具的强大能力分析程序的行为。

除了静态分析程序行为，程序分析有时也指动态分析（运行时收集一些信息回答关于当前运行的问题，如有没有内存泄露），或者无关程序行为的分析（比如代码有多少行）。

关于程序分析的更多内容可以参考我的《软件分析技术》课程：https://xiongyingfei.github.io/SA/main.htm

陈振邦：

我这边主要就自动的程序分析给出自己的看法，我个人觉得通常程序分析技术的输入是代码，可以是源代码或二进制码，输出是关于输入代码的一个结论或分析结果。

从是否需要运行被分析程序的角度，程序分析可以分为动态和静态两大类，动态分析需要运行程序，通过分析运行信息来给出结果，例如传统的动态测试、fuzzing、运行时监控、运行时验证等技术。静态分析是在不运行程序的前提下，直接通过分析源代码或二进制码，来得到一些结论，例如程序解析、类型检查、数据流分析、别名分析、静态符号执行等等。近年来，也出现了动静结合的分析方法，以融合两类方法，提升分析效果。

程序分析技术广泛应用于多个领域，比较典型的场景包括编译器中的解析、类型检查和编译优化，软件缺陷的自动检测及修复，安全漏洞的自动发现及修复或利用等等。因此，程序分析一直是计算机领域比较受关注的通用技术之一，其应用场景也不断扩大。

观点讨论

@孙军：我之前写过一个介绍程序分析的小文章，大家有兴趣可以看看：https://zhuanlan.zhihu.com/p/396531255

@彭鑫：@孙军 这篇我看过，通俗易懂。

@彭鑫：@孙军 把程序当文本是指用NLP技术来分析代码？这个也算静态分析吗？

@孙军：@彭鑫 我理解算。

@彭鑫：@孙军 传统的代码文本分析好像只能做一点很粗糙分析，例如计算代码的“语义”相似度计算等。不像其他静态分析手段可以做得比较细。大模型出来之后可能稍微强一点了。

@孙军：@彭鑫 是，总的来说程序还是人这种一般智能的生物写的嘛，如果LLM确实理解能力不错，那我感觉基于NLP还是能做不少事情的。

@李弋：@孙军 但是NLP没有把程序的结构和程序的语义充分利用起来。我们读程序，也不像读小说那么直接。

@彭鑫：@孙军 主要是文本分析比较依赖于程序员的标识符等相对主观和不确定的信息，因此有些学者不是太认同。

@孙军：@彭鑫 我感觉这个问题可能可以通过训练一个专门做程序分析的大模型来解决的好一点，毕竟相对自然语言，编程语言还是更规范，底层的基础也更统一。

@彭鑫：@孙军 但是架不住程序员的随意性啊，比如中国程序员很多会用拼音缩写或者经常拼错单词。不过即使这种情况大模型如果见得多了可能也能看懂一点。

@孙军：@彭鑫 确实，不过相对自然语言里大家经常发表情图还是好一些。

@谢肖飞：@李弋 可能算是一种更粗粒度，更不准确的抽象。

@彭鑫：@李弋 大模型可能会有点了，产生的解释里能体现出对分支语句的理解。

@陈振邦：在较为系统的中文综述方面，有2019年中科院软件所张健老师和国内其他老师在软件学报上发表的综述《程序分析研究进展》，以及09年梅宏院士等老师在计算机学报发表的《软件分析技术进展》。另外，其实程序分析中一些常用技术也有一些比较好的中英文综述，比如符号执行的ACM Computing Survey综述A survey of symbolic execution techniques。

谢肖飞：

程序分析主要是指自动化分析程序行为的过程，用于自动分析程序的一些性质，例如正确性、安全性、稳定性、终止性能等属性。程序分析主要可以分为静态分析和动态分析。静态分析不真正执行程序，仅仅通过分析程序的源代码或字节码来分析程序的性质，例如数据流分析、控制流分析、抽象解释等。程序分析的方法和技术也随着编译技术的发展在不断进化, 例如静态分析从早期的简单语法和词法分析发展到现今的复杂的数据流和控制流分析。而动态分析则需要执行程序，它通常涉及监控系统运行时状态行为，例如通过程序插装来进行性能分析、测试、异常检测等。与代码相关的研究等都会或多或少使用程序分析技术，比如常见的应用场景有漏洞检测，程序优化，安全检测，逆向工程以及形式化验证等。

程序分析有许多不同的技术和方法，比如， 静态分析包括数据流分析，指针分析，控制流分析，定理证明，模型检测，符号执行，抽象解释，循环不变量分析等。而动态分析包括程序插装，模糊测试，动态符号执行，日志分析， sanitizer (例如AddressSanitizer, ThreadSanitizer, LeakSanitizer) 等。

观点讨论

@熊英飞：@谢肖飞 定理证明是指手写证明么？

@谢肖飞：@熊英飞 我理解自动手动都包含吧，最好能自动化。

谭添：

我理解程序分析是基于程序设计语言的语义，通过计算、逻辑推导得出程序运行时行为、性质的一类技术。程序分析最开始应该是脱胎于编译技术，为编译器优化提供必要的程序行为信息。在最近二十年，学术界与工业界发现程序分析对软件开发以及软件质量保障，尤其是在故障检测、安全漏洞分析、程序理解等方面的应用具有重要作用，因此得到了更广泛的应用。程序分析近年来的研究许多也发表在向软件工程、系统安全等领域，也体现了这一趋势。

王迪：

各位老师对程序分析的内容和场景说得挺全了，我从个人理解说说发展过程吧。

我感觉是有一个特殊到一般、再一般到特殊的发展过程。比如最开始可能人们在编译器中研究了可达定义分析、活跃变量分析，后面逐渐抽象出了数据流分析、抽象解释等理论。同样的在面向对象语言上的程序分析中，人们提出了各种不同敏感度的指针分析，比如kCFA、mCFA、kOBJ等，后面逐渐形成了基于Datalog的程序分析框架。

随着软件规模越来越大、越来越复杂，又由于程序分析理论上没有最优解决方案，我认为目前的一个趋势是程序分析的目标越来越细分。比如对于上亿行规模的代码库，这种场景下的程序分析可能需要针对语言特性、代码库特性、所需要的具体分析任务进行设计，并侧重分析算法的并行化、去中心化、模块化等。又比如对分析结果可解释性比较看重的场景，可能需要在分析中考虑非形式化的信息，比如程序运行的日志、程序中的注释等。

李弋：

我也就个人的认识，谈一下。在很多时候，我们会看到不同说法，最常见的就是“软件”分析和“程序”分析。

我们有必要先来明确一下程序分析的对象。严格来说，软件是程序的一种可执行的形态，包括二进制以及可解释执行的中间表式或源码。而程序，既包括源代码、中间表示形式和二进制代码，也包括描述执行过程的算法和模型等比较抽象的表示形式。

一旦分析对象确定后，我们进一步来明确什么是程序分析。程序分析是一个比较泛的概念，不同的人有不同的看法。程序分析包含静态分析和动态分析，应该是大多数人都认同的。但程序验证、模型检验和测试等领域，大家的分歧就会比较大了。

程序分析的根本目的，应该是得到给定程序的一些性质。从这个角度出发，静态分析、动态分析、程序验证、模型检测和测试都是程序分析的范畴，只是解决的问题和具体的技术途径不一样。当然，这些不同的领域之间也有交叉和融合。

程序分析最早，也是最核心的目标，就是保证程序的正确性。最开始，主要的应用领域是编译器开发，用来保证生成代码的正确性和优化生成代码的性能。现在，跟开发人员相关的就是发现代码中的bug，或者一些不好的写法。很自然地，程序的安全性越来越重要，也成为程序分析的一个重要应用领域。

从软件工程的角度出发，对于遗留软件，通过程序分析的技术来理解程序，生成程序的描述，从而帮助开发/维护人员来理解程序。华为基于程序分析的技术来打造程序的数字地图，就是一种典型的引用。更激进地，已知程序输入和输出的规范情况下，程序生成也是一个很热的研究方向，可以应用到遗留代码的重构。

如果把芯片的设计看成是基于基本电路的编程，那么程序分析的最成功的应用领域就是集成电路/芯片的设计和制造。因为流片的成本(早期很高)和错误修复的成本很高，所以EDA工具在对VHDL/Verilog的程序的分析和优化方面做到了极致，也提出了很多分析的工具。Synopsys如今也是程序分析工具的一个主力厂商。

在后面的讨论中，主要围绕静态分析的理论和技术来进行。

最早主要是在syntax(语法)层面进行模式(特征)匹配，早期的杀毒软件就是这么干的。这种扫描的代价很低，可以支持大规模的扫描。缺点是很难通过syntax的特征来表示属性，误报率非常高。但是，程序的坏味道，主要在syntax层面上来进行。否则，程序的变换就会把原来的写法给消除掉了。

现在主流的程序分析都是基于semantics(语义)。大家最为熟悉的就是数据流(Data Flow)分析了，还有基于约束的分析(Constraints Based)，抽象解释(Abstract Interpretation, AI)，以及类型(type)和作用系统等主要的分析方法。

Cousot和一帮人提出/证明了AI is all you need，连模型检验(Model Checking)也没有放过。换言之，抽象解释为程序分析提供了理论基础，把程序分析从艺术变成了技术。

观点讨论

@张川：领域比较大，好多turing awards。

@李弋：@张川 大部分是做程序理论的人？

@熊英飞：@李弋 好奇Constraints-based是什么？是指约束求解，还是指Principles of Program Analysis那本书里的一章？

@李弋：@熊英飞 这里说的是ppa里的，不是您指的那个更大的约束求解。

@熊英飞：@李弋 哦，那个本质还是普通的抽象解释。那本书感觉就是把同一个东西换不同的语法写了好多遍。

@李弋：@熊英飞 不同的表现形式，可以用于不同的场合。从教材的角度，感觉是教学生们从不同的角度看问题。

董震：

我这个说的有点笼统，程序分析是针对某个属性展开的程序行为分析活动。属性可以具体到一个变量是否存在赋值的情况，也可以是用户需求的某项要求等。

程序分析发展成熟，积累了很多技术包括静态分析、动态分析、符号执行、模型检查等，应用场景包括漏洞挖掘、隐私数据分析、合规检查等。

从稳健性上看，形式化方法如程序验证、模型检查技术在全局状态空间上验证某个属性，更加稳健，这类型的分析相对成本高昂，伸缩性差些。从实用性上讲，基于“近似”分析的技术（如静态污点分析），以及基于部分行为的动态分析技术（如动态污点分析）更加实用些。

个人感觉，不同的应用场景需要不同的程序分析技术，每个类型的技术都值得去探索拓展。

梁广泰：

程序分析是一种以程序为研究对象，采用各种技术手段来理解和优化程序行为的过程。它可以被广泛应用在多个领域，企业内部落地效果较好的领域包括: 代码缺陷与修复、开源成分分析、安全漏洞挖掘、恶意代码分析、代码搜索与推荐、代码自动生成、运行时性能瓶颈剖析等等。按照企业届落地的广泛程度(我本人所感知到的)排序如下: 

程序分析技术可以分为多种不同的流派，主要包括以下几种：

1. 静态程序分析：这种分析方法主要基于程序源代码或二进制代码。它可以检测出代码中的潜在错误、漏洞、风格问题等。

2. AI相结合的程序分析：近年来，随着机器学习技术的发展，人们开始尝试将机器学习方法应用于程序分析中。这种方法主要通过学习程序运行特征，自动发现程序的运行模式和规律，进而预测程序的性能、错误、漏洞等。

3. 动态程序分析：这种分析方法需要实际运行程序，因此也称为运行时分析或实际运行性能分析。它可以检测出程序在实际运行中的行为特性、性能瓶颈、内存泄漏等。这种分析方法通常需要使用性能剖析Profiling技术、debugging、插装等技术。随着云原生、微服务等技术的不断发展，动态程序分析技术也有着广阔的应用前景。例如，利用动态分析技术对微服务进行性能测试、安全漏洞检测等。

4. Fuzzing技术: 一种基于黑盒或灰盒的测试技术，通过自动化生成并执行大量的随机测试用例来发现产品或协议的未知漏洞。

5. 形式化方法：这种分析方法使用数学模型描述程序行为，以便进行精确的分析。它可以应用于安全性、正确性、性能等多个方面的分析。这种分析方法通常需要使用一阶逻辑、模型检查、自动定理证明等技术。

程序分析技术的发展过程是一个不断扩展和深化的过程。随着计算机科学的不断发展，新的分析技术不断涌现，而现有技术也不断被应用到更广泛的领域中。同时，由于程序分析的复杂性和多样性，没有哪一种分析技术可以完全适用于所有情况，因此多种分析技术的结合使用成为一种趋势。

狄鹏：

自从有了程序就有了程序分析，09年梅宏院士就在计算机学报聊过《软件分析技术发展》，软件学报2019年发表过的多位专家合作的《程序分析研究进展》，这两篇论文，之前陈老师也提到了。对程序分析技术做了描述和定义。其实、广义上说，程序分析就是把程序白盒化的过程。最早是编译优化的前置分析，像SSA也是一种分析。很多编译优化技术，都是依赖程序分析结果的。后来主要应用到软件质量，安全，代码理解等不同的方向，才有了如今程序分析的百花齐放。

程序分析技术的发展，其实前面几位老师都讲的很清楚了，包括动态静态分析的发展历程。其实翻翻看09 和19年的两篇论文，程序分析在大类技术方向上并没有明显变化，主要是随着应用场景不断发展和壮大。我倒是非常期待LLM能给程序分析带来新的活力。 我们在几年前，就在看ML能给分析带来什么，随着LLM将ML的门槛降低，程序分析可能也会有新的技术变化。我最近拜读了很多各位老师在LLM应用到分析技术的paper ：） 

Question 2

主持人：已有理论证明一般的程序分析没有高效的解决方案。那么，在当前的计算模型下，我们围绕程序分析技术的改进做了哪些方面的努力，这些努力是否还有意义？特别是当软件系统变得越来越复杂的情况下，我们如何解决程序分析的可伸缩性以及效率和准确性的平衡问题？围绕这些方面有哪些值得探索的研究点？

孙军：

嗯，确实程序分析，在理论上已经知道很多东西是不可判定的。那么这就变成了一个我们要求的软件质量和我们的所能付出代价的平衡的问题。我们做各种各样的软件分析肯定是可以越做越精确，当然同时花的代价越来越大。我理解现在当前的现状，应该是绝大多数软件已经达到了一个安全和质量相对比较平衡的状态啊，我感觉这样可能也就够了。同时，作为计算机科学家，我们肯定是要不停的尝试去看有没有更好的办法，高效的来保证程序的正确性，安全性等等啊，这个努力还是值得肯定的。

观点讨论

@彭鑫：@孙军 这里充分体现了engineering的特性，就是不求“完美”只求“足够好”，同时充满各种权衡。

@孙军：@彭鑫 对，这个大概可以理解是一个代价（纵轴）和质量的指数关系吧。根据不同的需求选合适的点吧。

张川：

这些努力仍然有现实意义。的确，许多精度的算法如上下文敏感分析、路径敏感级别程序分析理论上的复杂度较高，但由于程序本身有一些特性异于这些算法依赖的通用图模型，这些算法在实际中仍有相当的提升空间。例如近年的稀疏程序分析、并行化程序分析、选择性路径敏感、按需分析等等技术增强了程序分析的可伸缩性，可以极大程度缓解原算法在实际中的落地难度。

面对越来越复杂的软件系统，针对程序分析的可伸缩性、效率和准确性问题，我认为在实际中，效率和准确性并非不可兼得。我们不应该只讨论理论算法，更要从软件工程的实际场景出发寻找可落地的解决方案，如何更好的调度现实中有限的硬件资源和分析算法完成程序分析任务将是未来的探索方向。我们最近一两年提出的程序分析数据库化是指程序分析系统应该如数据库系统一样以磁盘为基础而不是以内存为基础。我们的Clearblue程序分析平台可以将千万行的程序预处理储存，同等高精度分析只需要几十MB的内存，从而使建立全系统镜像和分析成为可能。我前几年提出了CODA requirements: 持续分析（Continuous), 开放定制（Open)，二进制入口(Dark Code)，框架中间件理解（Assembled)。我觉得程序分析技术在这些方向上都还大有可为。例如针对复杂软件系统存量代码数量大、每次变更少的特点，我们可以设计增量分析算法避免重复调用高复杂度的全程序分析，从而提高生产环境的程序分析实际效率。针对软件系统供应链复杂的特点，我们可以设计程序分析结果持久化算法，建立持久化数据服务，使得依赖供应链的程序可以快速得到分析结果。这些技术的发展将能够保持现有的精度下，进一步提升程序分析的性能，从而能够“又好又快”完成分析任务。针对硬件资源不能在一台机器无限向上堆砌的特点，我们可以设计分布式分析，将程序分析任务分布到多台计算机上，实现分布式计算，以提高分析的可伸缩性。针对一些特定领域的难解问题，如对条件和数值域敏感的整数溢出、缓冲区溢出问题，我们可以结合不同的程序分析技术，如抽象解释、符号执行、甚至模糊测试等等，以解决程序分析中的复杂问题。

观点讨论

@彭鑫：@张川 看来程序分析“系统”的工程化优化空间还很大。

@董震：@张川 很赞同，张老师的增量分析的策略，非常实用。

@彭鑫：@张川 程序分析数据库化 👍一些企业已经开始把程序分析的结果作为一种“代码地图”持久化保存，并用于故障定位、影响范围分析、架构看护等各种应用。

@谢肖飞：@张川 数据库化后面是不是可以进一步被 AI 大模型更好的吸收？

@梁广泰：@彭鑫 程序属性图很适合通过数据库来保存。

熊英飞：

目前理论证明的是对任意程序分析算法，一定存在程序没法给出正确答案。因此，仍然可能对大部分程序都高效给出高质量分析结果的。作为类比，SAT是第一个被发现的NPC问题，按说算法至少是指数复杂度，但大多数实际问题上SAT Solver都能快速给出答案。

过去程序分析的研究主要是在保证健壮性的情况下寻找更好的抽象域，但随着程序分析工具越来越多用于软件工程工具，类似编译系统那样的强正确性保障变得不是那么关键，那么打破这个限制之后还有一些机会可以去做。在健壮性范围之内，已有分析技术也更多关注上近似（用于证明程序正确性），而相对较少关注下近似（用于证明程序有Bug），这方面也应该有一些机会。另外，实际中的系统往往存在一些很难通过逻辑精确刻画的部分，比如没有源码的模块，程序员的意图等，如何将传统逻辑分析技术和概率结合也是一个未来方向。

观点讨论

@孙军：不过这两年SAT貌似又遇到瓶颈了。

@熊英飞：@孙军 确实，不过感觉程序分析的发展水平还没到SAT目前的程度，还有很大的进步空间。

@张川：@熊英飞 我们已经在考虑有没有FPGA 的 SAT solver，还是占用很多时间。

@孙军：@张川 这个硬核。

@熊英飞：@张川 张老师提了新的软硬结合的发展空间！

陈振邦：

我主要就静态分析方面给出自己的看法。虽然对于非平凡性质的程序分析没有银弹，但程序分析技术的的改进仍具有重要意义。首先，程序分析是程序自动理解的基础，自动理解在很多场景下能解决或帮助解决问题，这一点从程序的分析应用场景越来越多就可以说明。其次，从技术的角度，出现了很多新形态的程序，比如并发、实时、包含AI构件的程序以及相关的性质，需要研究相应的程序分析理论和方法。最后，从应用的角度，因为在一般意义上不可判定的问题，在不同问题空间，程序分析技术其实是在Soundness、Completeness以及可终止性方面做权衡，需要根据问题的特点设计或选择最适合的程序分析技术，这一点也需要研究。

在应对权衡挑战方面，我认为主要有几种思路：1）针对某些或某类的性质给出高效的分析方法，例如稀疏值流分析，可以提高分析效率；2）针对某类程序的分析优化，不用考虑所有的复杂特征，可以有效提升效率；3)组合分析方法，比如基于摘要的分析方法，可在保证一定精度的前提下，缓解效率方面面临的挑战；4）综合不同类型的分析方法，以达到更好的效果，例如动静态结合的方法、不同动态或静态方法的结合。

从研究的角度，我个人认为有以下一些方面可以值得研究：1）程序功能的自动理解与分析，这个其实也是长期困扰大家的软件规约问题，我觉得可能大模型的出现在这个方面可以起到推进作用；2）面向程序的自动权衡策略，当前研究大部分是面向某类性质的，在此基础上，如果能做到面向某个程序的最优权衡，可能可以进一步提升分析效果；3）程序分析基础平台与基础设施，这也是非常非常重要，并且值得不断研究与积累。

谢肖飞：

许多程序分析问题，例如停机问题、程序不变量生成，都已经被证明是不可判定的。 复杂的大型软件也对程序分析造成了很大的挑战。例如静态分析中符号执行，模型检测就很难用到大型程序，而动态分析也会遇到编译困难以及输入覆盖率低等挑战。

我所知的一些常见的缓解方法主要有：1） 通过抽象解释的方法来近似程序的行为，从而可以忽略一些细节而简化复杂度。2）通过启发式方法对一部分可以处理的程序进行分析。我们之前对循环分析的工作就是对循环分类然后尝试提出不同的策略与方法来逐类突破；符号执行中比如KLEE 也有许多启发式的搜索策略来遍历程序状态。3）结合静态和动态分析来利用两者的优势，避免它们的缺点。比如我们ICSE’20年关于UAF检测的一个工作就是先用静态分析找可疑点，这里为了效率可以容忍高误报率，之后用动态测试来确认和发现真正的UAF。今年ASE23上我们关于程序终止性分析也是提出了一种动静结合的方式使得能找到现实程序的不终止情况。4）最近也有一些尝试用机器学习的方法来辅助测试、污点分析以及符号执行求解搜索等，其主要依靠大量数据来学习与预测。当然这些缓解方法都没有提供一个完备的方案，但是在具体场景下仍然能提供一个“足够好”的方案。

面对越来越复杂的系统，我个人觉得上述的几种方法仍然可以在不同的场景下能提供不同的帮助。同时还可以考虑通过将大型系统分解为更小、更容易分析的部分，再进一步独立分析这些部分并组合它们的结果。对于经常更改或者相似的代码，也可以只分析变化的部分，而不是每次都分析整个程序，从而达到各方面的一个平衡。 另外我个人觉得随着大模型的出现，其可以很好的帮助缓解这个问题，也是未来的一个研究热点，这个在后面问题还可以再继续讨论。

谭添：

我们一直在围绕程序分析技术做改进，希望研究出更加实用、有效的技术。从结果上看，我认为这些努力是有意义的，我们取得的效果（可伸缩性、准确性）一直在提高。比方说我们一直在研究的指针/别名分析，是比较公认的基础程序分析技术。近二十多年来提升指针分析精度的最有效的技术之一就是上下文敏感（context sensitivity），主要通过克隆方法体提升精度，但克隆也造成了显著的性能负担，导致其可伸缩性一直有瓶颈，限制了它的使用场景。我们今年的工作Cut-Shortcut就提出绕过上下文敏感，通过图重写的方式，既可以获得上下文敏感的精度，也完全摆脱了它的性能负担，得到了更好的可伸缩性/准确性的一个平衡。

我觉得探索程序分析技术的一个关键是需要沉下心，去观察、研究当前技术对于现实程序的分析效果，找出真正的瓶颈。同时也需要去观察程序的行为和特征，从特征出发能使得提出的技术更有针对性，更容易获得更好的效果。

王迪：

我简单从语言设计的角度谈一种平衡高效性和准确性的方法。我们可以把类型系统看作一种与语言设计相结合的程序分析。类型的好处是具有良好的模块性，类型检查的效率一般是很不错的，但其弱点在于常见的类型系统分析的性质太简单。但是Rust语言提供了一个很好的范例：我们知道内存问题的分析是比较难的，但Rust通过语言设计，规范了内存使用的若干模式，并相应地设计了能高效进行内存安全检查的类型系统，这其实是一种比较巧妙的平衡高效性和准确性的方法。在对国产编程语言的需求日益蓬勃的今天，这种方法也不失为程序分析技术协同新兴语言发展的机会。

李弋：

我写的比较碎，所以比较长。

Rice定理和其它计算理论的结果，说的是一般问题没有有效的算法。也就是说，我们没有一个一站式解决方案来搞定程序分析问题。但实际应用中，除了工具厂商，也没有面临一个普遍问题，更多的是在特定领域方面的程序分析。

举个例子，SAT问题是NP完全(NPC)问题，也就是说没有有效的求解算法。更具体的话，2-SAT就是一个P问题，3-SAT是一个NPC问题；2/3混合到什么程度算是NPC问题，至今没有搞定。如果搞定了，那么就证明了P和NP的划分了。八卦一下(几十页的论文没有仔细看过)，好像之前有人利用GPT证明了P不等于NP。

也就是说，在当前的计算模型下，我们的努力还是有回报的。万一我们关注的是一个非常具体的问题，跟2-SAT一样，那我们就可以很幸运的找到一个一劳永逸的解决方案。即便不是，我们也可以对问题的案例进行分类，试图分而治之；复杂性领域把那些难计算的记做kernel，可以应用随机/近似算法来逼近，有的问题在算力允许的情况下，可以做到给定精度(不能无误差)的近似。

简单总结一下，不要搞一揽子解决工程，要具体问题具体分析。这也是为啥静态分析工具也是百花齐放。

现有软件的复杂性，除了是规模大，还有就是处理的事务的复杂；在程序上，主要体现在变量/函数间的依赖关系复杂。当然，这种复杂并不是所有的代码都复杂，通常只是核心的代码比较复杂。在很多时候，我们关系的性质，可能和这些复杂的处理完全没关系，譬如指针变量的访问，和复杂的业务数值计算就没有一点关系，但如果不做任何区分的话，就会引入无畏的计算。程序分析会引入稀疏分析的方法，例如svf框架。抽取程序中相关的变量和语句，有个专门的名字叫program slicing。

静态分析通常是计算每行代码的不动点。更加细致的考虑，求循环的不动点时，每条语句的后置和依赖语句的前置条件的改变并不相同，worklist算法的求解效率还可以得到改进。

由于程序的组件化，依赖关系可以分成不同的连通区域。很自然，我们就会考虑模块化的分析方式。通过构造/生成函数的摘要，可以看做是denotational semantics的具体表示，一个函数只需要分析一次即可。

由于依赖关系的精确化，我们完全可以对没有依赖关系的模块并行计算，加快执行。南大的左志强等人最近的工作，就利用图计算系统，把程序分析的任务进行分解，通过图计算来实现大规模的扩展。

更进一步，考虑到程序开发的连续性，我们只需要计算可能受变更影响的代码，从而实现增量分析，降低每次分析的计算代价。

考虑到程序执行对状态的修改通常是局部的，提出了Reynold等人提出了Separation Logic，换言之，很多计算都是局部的。Infer的开始版本，就是基于Separation Logic来构造，还加上了Bi-Abduction的推理方法。O’Hearn等人进一步扩展为Concurrent Sepration Logic，为并行程序分析提供了理论基础。

在精度方面，因为AI对于可靠性(Soundness)的要求，导致误报必然出现。为了降低误报，就需要提高抽象域的表示能力，能够更加精准地刻画每条语句的前后置条件的表示。很不幸，虽然线性约束的表示还不能精确刻画变量间的依赖关系，但是某些操作的计算已经是指数的了。当然，当变量的个数没那么多时，指数的计算好像也是可以承受的。因此，有人研究混合抽象域的计算，根据代码片段精度的要求，使用最优的抽象域。华为在今年的胡杨林基金提出的一个题目，就是如何支持混合抽象域的分析。前提是要支持他们现在使用的一个商业分析的框架。抽象域目前主要是手动构建的，从理论上提出了如何构造完备的抽象域，通过对抽象域的扩展，保证分析精度的下降不是因为计算的不完备，而是因为join和widenning等策略引入的；为了满足不同的需求，有人提出了自动的抽象域分解/扩展的方法。

分析的精度，很多时候是要求我们对某些信息，譬如上下文、执行路径和具体的对象等信息是否敏感，就是我们之前说的具体问题具体分析。实际上不是所有的点都要敏感，南大等提出了需求驱动的敏感分析方法。Charles在路径敏感分析时，引入tunnel，从而消除一些path condition。

基于抽象解释理论，在一般情况下，一定会产生误报。除非我们回退到Concrete Domain，也就是蜕变到动态分析，后果就是状态爆炸而导致不可计算。幸运地，误报的量并没有大到不可计算，所以有人提出分析具体错误点的根因，也就是post-moterm分析方法，从而可以来验证一个具体的错误是否为错误。Cousot基于AI打造了responsibility analysis来分析安全问题。针对一个特定的实例时，符号计算可以用于构造路径满足的条件，基于SAT/SMT的求解可以帮我们给出可能的例子。最近，大规模SMT求解取得了很大的进展，中科院在这块做出了很好的结果。

另外，如果引入人的因素，我们还可以进一步降低误报。Astree就是可以结合人的反馈，从而为分析增加更多的约束条件，其实就是领域知识，从而消除误报，号称可以做到零误报。

对于程序分析领域，一个重要的问题就是如何来表示程序的性质。目前比较多的是用一阶逻辑或者高阶逻辑，但逻辑也有其自身的局限，很多性质并不能表示。也有很多人用代数的方式，特别是从范畴论的角度来研究Lambda演算的域表示。

以前，我们关注的是程序的正确性，而实践中，我们更关心的是那些错误。因此，O’Hearn等人提出了Incorrect Logic，从under-approximation的角度来研究那些可能出错的语义，从而降低误报。Hoar Logic和Incorrect Logic构成了dual，还有人把under和over相结合，提出了Unified Logic模型。

当前一个关键的问题，就是我们如何来自动化的学习和表示程序的特性。ETH提出了基于机器学习/深度学习的方式来自动分析程序的性质，在大算力的前提下，可以降低人的成本。

董震：

有很多程序分析问题是非常有挑战的，比如精准的指针分析是NP难问题，模型检查技术出现的状态爆炸问题等。目前大部分探索工作采用tradeoff的策略，牺牲一些分析结果的精准度来换得实用性。

之前一个会议上，澳洲Oracle一个lab尝试通过并行计算的方式来解决可伸缩性的问题，但是会上专家普遍认为这些提升的算力与解决这些问题的所需的算力水平不在一个数量级上，不是很看好这个方向。

个人觉得还是从实用性上入手比较好，尤其是当前系统越来越复杂，新的语言特性不断推出，完美的解决程序分析中的问题确实比较难，根据实际问题逐步细化，得到可用解就好。

梁广泰：

围绕程序分析技术的改进主要在以下几个方面进行：

1.     工具和框架的优化，进一步封装底层代码分析能力，降低工具能力拓展门槛：这些工具和框架可以帮助开发者更轻松地应用程序分析技术，同时减少误用和滥用。具体来说，比如提供更加灵活的DSL引擎，方便广大非软件分析背景的工程师来轻松描述待检测程序的模式或属性，提高工具能力扩展效率；

2.     误报过滤技术：面对高误报场景，如何利用NLP、AI等技术进行误报告警的识别和过滤，也是企业一直比较关系的课题；误报告警的自动化过滤将极大提升静态告警的排查效率，提高工具的使用效率；

3.     程序分析与AI技术的深度融合：程序分析技术在面对复杂代码逻辑或多因素场景时，往往无法精准判断某个对象类型或值范围，针对相关场景，很多学者尝试利用AI技术来辅助决策，这类技术可以AI for 程序分析；除此之外，随着LLM的技术快速发展，AI应用将会加速发展，而AI应用构建过程中也会存在一系列特有问题，如海绵样本、数据泄漏、误判偏见或幻觉等问题，围绕这些问题，业界也在积极采用程序分析技术来尝试发现或辅助解决这些问题。

狄鹏：

我们常用莱斯定律来悲观的看待程序分析，程序分析最大的难点的确是在效率和准确的平衡上。分析的计算量一方面是随着代码量级在增长，一方面随着系统复杂度也在飞速提升。Yannis 在2020年PLDI 就论述过分布式Java分析的复杂度。包括程序隐式行为的未知性，框架建模的不完善，分布式存储和通信的影响等。我在工业界从事这方面的工作，发现Yannis说的每一个坑，我都要踩一下。这的确是非常大影响了分析的可扩展性和效率。

我是非常赞同Charles的观点的。很多努力都有它的价值，而且我们也在努力的克服这些困难。并不是所有问题 都要有“must”答案的，“may”的结果也有其应用的价值，而且可能更大。

Question 3

主持人：程序分析技术当前在企业软件开发实践中的应用状况如何？经过多年的发展，目前已经形成了哪些有效的程序分析工具？为什么程序分析工具在软件开发实践中还没有得到充分利用，甚至存在一些抵制的声音？程序分析工具在软件开发实践中的应用存在哪些问题和挑战？

孙军：

我理解是各个大厂还是大概都有自己的软件分析的团队、平台、工具、方法的。只要各个大厂的软件还有安全的需求，我感觉程序分析还是必须要有的。

至于为什么软件分析在软件开发实践中还没有统得到充分的利用，我们也需要承认软件分析本身是一个有门槛或者不是太能让普通程序员接受的一个东西。这就要求我们必须做更简单易用的程序分析工具。当然我认为更好的方法是把程序分析需要做的这些东西尽量的做到编译器里面，甚至在设计编程语言的时候就已经把很多需要程序分析的这些东西尽量做到语言里，通过语言设计从根子上提高程序质量，这样程序分析起来代价会小很多。当然，设计安全的编程程序语言的时候，有一个很大的问题是怎么平衡程序正确性，安全性和程序员需要付出的思考成本的问题。

观点讨论

@李弋：@孙军 Clang里就提供了csa和tidy。

张川：

在企业软件开发实践中，程序分析技术已经得到了一定程度的应用。一些常见的程序分析工具包括静态代码分析工具如Pinpoint、Clang Static Analyzer (CSA)、Infer、Coverity、SonarQube，以及动态代码分析工具如Profiler和Valgrind等。这些工具在帮助提高代码质量、安全性和性能方面发挥了重要作用。

然而，程序分析工具在软件开发实践中的确受到了不小的阻力。首先，学习和适应成本可能是一个挑战，使用这些工具需要学习和适应新的技术和工具。在企业内开发和维护程序分析工具更需要经验丰富的技术专家，而这些人才目前在企业内部是比较少的。其次，误报率和漏报率是一些工具的问题，即可能会产生大量的误报或漏报，这降低了工具的可用性和可信度。此外，集成和部署工具也可能面临一些挑战，包括安装、配置和与现有开发环境的集成。特别是在现有高精度程序分析工具中，程序分析过程目前往往需要干预编译环境来获取程序分析的中间代码，企业中复杂多变的构建环境往往导致集成不成功，这对好的算法落地构成了不小的挑战。

除此之外，企业内部不同类型的软件项目可能会面临不同的问题和挑战。首先工业软件在企业内部的软件远比现有程序分析工具论文中评估的项目要巨大，常常会达到千万行甚至上亿行，并且每日更新也会达到上万行，这需要更高效的程序分析算法或是解决方案来支持更大体量的代码。其次，当下的云原生开发涉及复杂的软件供应链、severless、微服务程序，已有的程序分析实现需要很多额外工作集成来支持这样的组织方式，即便可以集成，也很难一次分析这么多软件供应链上游的库代码，因此我们也需要新的算法应对新的软件开发模式。除此之外，企业关注的问题常常为业务问题而非程序分析关注的传统意义上的经典安全问题。例如，在安全敏感的项目中，程序分析工具可能需要通过特定业务逻辑发现潜在的安全漏洞和弱点。在性能敏感的项目中，工具可能需要能够分析和优化代码的性能瓶颈。若通过程序分析的手段解决，则需要程序分析的软件工具提供高度可定制化的能力。解决这些问题和挑战需要持续的研究和创新。同时，与开发人员和软件开发组织的密切合作也是至关重要的，以了解他们的需求并提供有效的解决方案。通过进一步的研究和实践，我们可以期待程序分析技术在软件开发实践中发挥更大的作用。我们相信以数据为驱动，以API/DSL为主要交互方式的程序分析会极大的缓解这些矛盾。

熊英飞：

程序分析工具在开发实践中没有广泛应用这个说法是不对的。

编译器就是一个典型的程序分析工具，编译优化的正确性一直是通过程序分析保证。而王迪老师刚刚也说过，程序设计语言的类型系统本质也是定义了一个（带标注的）程序分析过程。

如果特定到用程序分析找缺陷上，可能更多看是找什么样的缺陷。效果好的基础缺陷查找方法已经集成到编译器中了（如：Java编译器对未初始化变量的检测）。在编译器之外，留给独立的缺陷查找工具的机会就只有现有技术还处理不好的缺陷类型，那么这些工具大家不爱用也是很自然的事情。

从研究的角度来看，未来应该继续发展程序分析，让更多的缺陷类型能稳定高效地检测。至于这样的检测工具是叫做编译器还是叫做程序分析工具，其实并不重要。

观点讨论

@李弋：@熊英飞 在编译器里，只能有Must，如果may多的话，大家估计也会把这个功能关掉。

@熊英飞：@李弋 对。所以能稳定出must的都被编译器集成了，留给独立缺陷检测工具的空间不多。

@狄鹏：还真不全是，编译器可以有may的，后面保守优化就可以。

@熊英飞：@狄鹏 李老师应该是指编译器直接提示代码错误的情况，比如Java编译器提示有未初始化的变量。

@李弋：@狄鹏 在编译的优化，如果不能保证正确性的话，还是要给大家讲清楚的。像以前的ICC，就会说这个特性可能会有问题。

@李弋：@熊英飞 所以程序分析实际上是把编译器的要求给降低了，不用那么保守，可以大胆冒进，再事后验证。

@张川：compiler 主要是 translation，和 Program analysis的目的略有不同。

@陈振邦：@熊英飞 还有功能相关的。

@狄鹏：有些优化 may 是反着用的，所以还是可以搞得。

陈振邦：

如果我们把动静态分析技术都考虑，应该说都在工业界应用广泛，我也主要就静态方面给出观点。我个人了解到，比较出名的静态分析工具产品方面，国外的有Coverity、Fortify、K9、Infer等，国内的有Pinpoint等。我了解到这些工具其实存在大量用户，包括很多安全关键领域的工业部门、国内大的头部公司等。我可能了解的不多，但还没听说程序分析工具在软件开发实践中被抵制的情况。在应用中存在的问题方面，我个人了解到一些的问题主要包括：1）静态分析的误报和漏报问题，这个比较普遍；2）部分程序的分析问题；3）软件框架的问题；等等。当然，这些问题都与应用场景相关，比如在某些安全关键的场景下，要求不能漏报，误报说是可能可以堆人力解决；与之相反，有些大的公司的开发过程中，认为误报是最大的问题。总体而言，我认为在不同的场景下，设计或选择最合适的技术和工具是关键，当然这需要比较强程序分析的背景。

谢肖飞：

据我了解，许多大型企业已经将程序分析技术集成到他们的开发和测试流程中，特别是在CI/CD流程中。例如国内华为，阿里，腾讯，字节等大公司都在软件开发上进行了大量的投入，不同的程序分析技术被用于提供安全审查、代码质量检查、性能分析等。目前已经有很多开源和商用的程序分析工具，支持不同语言和特性。比如C语言上， Clang/LLVM 集成了许多程序分析算法， Yulei 老师开发的SVF很好用, 还有 Eric Bodden 组开发的Phasar,  CPPCheck, 以及一些形式化验证工具如 CPAChecker 和 CBMC等，Java语言上常用的是 Soot, FLOWDROID 等。一些商业工具比如SonarQube，Pinpoint等。

个人认为软件分析工具没有被充分利用的主要原因包括：1）程序分析的伸缩性是个比较大的问题，如问题2所说，对于大型复杂软件静态分析很难直接使用  2）尽管已经有一些工作来缓和这些问题，但是很难保证通用性。一些启发式策略可能只在一些场景下使用，而在其它场景却无效 3）误报率高，静态分析由于引入抽象近似，往往具有较高的误报率。4）动态分析方法运行时间久，要求可编译可运行，并且需要人撰写可执行的驱动，提高了分析门槛。5）程序分析是一些基础技术，但如何将这些技术转化到不同的应用开发场景中仍需要很多代价。并且程序分析工具的开发、应用以及维护需要程序分析相关专家，其具有较高的学习成本。这些也是程序分析工具所面临的一些问题和挑战。

谭添：

我并没有在企业界工作，所以我的回答主要来自于我与工业界同仁的交流以及我自己使用程序分析技术的体验。目前来说，我感觉似乎更简单的一些程序分析技术（比如过程内的分析、甚至是基于语法的分析技术）反而是使用得更广泛。这些技术的主要特征是：运行速度快、准确度较高、分析结果易于理解、有成熟的工具支撑。所以我认为能够真正被企业广泛接受和应用的程序分析技术应当具备以上的特征。实际上学术界研究出了许多能力强得多的技术，但因为没有做到以上几点，对开发人员而言，并不是一个顺手的工具。

在这一方面我们也一直在努力，我们开发了Java程序分析平台“太阿”（https://github.com/pascal-lab/Tai-e），希望能把学术界最新、更强的程序分析技术集成进去，同时也把平台本身打造得更好用。而做到后面这一点并不容易，需要投入很多精力，设想开发人员真正的使用场景，去做相应的适配和功能开发。

观点讨论

@熊英飞：@谭添 我们去年软件分析课上的同学们已经用了太阿，大家评价是比SOOT好太多了。

王迪：

我对企业开发实践的经验有限。我自己观察到的小样本中，基本上都用上了语法级的分析（比如Linter），可以以很小的成本来提升代码质量。Facebook公司的一些项目的开发中会使用MIRAI（Rust静态分析工具）和Infer（Java/C/C++/Obj-C静态分析工具）来辅助程序员开发。

程序分析工具的广泛应用（特别是在软件开发过程中的应用）主要还是平衡高效性和准确性的问题。目前一些简单的分析（例如过程内的数据流分析）在开发环境里的集成已经挺不错了，但对复杂一些的分析，比如跟指针相关的分析，就比较难在分析速度快的前提下保证误报率低。另外，程序分析方面的研究在一个工业级的编程语言上落地、跟上语言版本更新的步伐、为程序员提供良好的反馈和解释在工程上也是个挑战。

李弋：

随着软件系统越来越复杂，越来越多的人意识到静态分析可以帮助开发人员提高产品的质量和安全性。静态分析的市场需求越来越大，根据QY Research的调查报告(https://www.orbisresearch.com/reports/index/global-static-code-analysis-software-market-research-report-2023)，2022年的市场大约有994M$，预计2029年会达到1699M$。

程序分析经过这么多年的努力，已经有很多的静态分析工具，例如：WuKong、Klockwork和Helix QAC(Perforce)、CppDepend(CoderGears)、PVS-Studio、Coverity(Synopsys)、Polyspace(MathWorks)、Fortify(HP)、Parasoft、SonarQube、Veracode和DeepSource等等，开源的有TscanCode(腾讯)、CPPCheck、Infer和基于基于Clang的CSA和Clang-tidy等等。一些工具提供非常多的性质检查，一些工具有太多的参数选择，即便专业人士用起来也挺麻烦。

工具这么多，说明静态分析的工具没有最好。谷歌和Meta(原Facebook)在Communication of ACM上总结了公司内部使用静态分析的经验和教训。总体上来说，正确地看待和使用静态分析工具，能够提高软件的质量。

为了更好地利用这些分析工具，Sahar Mehrpour分析了如何找到更多缺陷的途径，比如说要清楚工具的能力，可以多个工具一起使用(提高查准-交叉验证和查全-取结果的合集)等。据说华为在实践中就是多个工具一起使用。大量的误报成为使用静态分析工具最大的阻力(虽然我们自己也开发程序分析工具，但学生也很少用工具对自己的代码进行检查)。谷歌为了推行程序分析，提出了打造程序分析的生态，要在工具链和使用政策上打造整体解决方案。

在实践当中，最大的问题是误报导致的后果；但如果提高精度，则会导致计算代价太高。另外一个问题，则是软件规模比较大的话，分析时间会很长。软件规模问题，对于开发公司而言，在整个开发生命周期里看，通过增量分析可以在一定程度上绕过去；对于评测公司而言，这个问题就比较麻烦了；只能通过借助于更多的计算资源和分析的并行化来解决。精度的提高，是大家一直在努力的方向。

董震：

企业的应用情况了解不多，但是总体感觉程序分析技术在企业的应用还是很广泛的，比如微软的SLAM，SAGA，脸书的infer等。

但是了解实际应用中的一些抱怨，比如误报、漏报、适用范围窄（需要特定环境、不支持多语言）、计算成本高等问题。在与卡巴斯基合作的一个项目中，就有领域专家抱怨上面的问题，他们更倾向于人工观察分析，并且在某行情况下反而更高效。

梁广泰：

程序分析技术在大型企业内部软件开发实践中有着广泛的应用。基于软件分析技术的代码质量门禁、开源代码治理、代码搜索、代码编程智能助手等服务，已经成为了企业软件开发作业平台中不可或缺的一部分，对软件研发的效率和质量都发挥了重要技术保障。

随着各国基础设施平台追求自主可控、企业云化数字化转型等背景，围绕开发人员提供先进的研发工具能力具有了新的历史使命。华为云为广大开发人员提供了端到端研发工具平台CodeArts，该平台上的很多智能化特性的打造都离不开程序分析技术的支撑。如在IDE中进行各类代码资源的推荐与补全、代码缺陷实时检测与修复、代码（含单元测试代码）自动生成、开源漏洞追踪及治理等。

程序分析工具在软件开发实践中的应用存在以下问题和挑战：

分析结果的高误报率：程序分析工具的输出结果可能受到多种因素的影响，包括源代码的质量、工具的精确性和环境配置等，其准确性可能难以保证。

对程序运行的依赖：很多程序分析工具需要程序在运行过程中才能收集到足够的信息来进行有效的分析，而企业内部的很多项目的运行门槛较高，需要特定的运行环境和依赖包的支持，往往无法大规模批量化进行。

对开发人员的要求较高：使用程序分析工具需要开发人员具有一定的专业知识，包括对工具的理解、对程序行为的洞察力等，这可能需要开发人员投入较多的时间和精力。

技术支持的难度：程序分析工具的技术支持和维护可能具有一定的难度，需要专业的技术人员和维护人员来进行操作和管理。

狄鹏：

我们抛开编译优化的领域，从软工、安全的视角来看程序分析的工业应用。我一直认为程序分析都不是孤立存在的，它在绝大多数情况，都是起核心辅助的作用。比如测试白盒化，本质就是需要程序分析。 所以程序分析是软件开发的工具，是工业界的基础设施。我们正视技术的待发展所导致的工业应用问题，所谓“抵制”是源自对技术的不了解。这让我想起了，我刚刚加入蚂蚁，去布道技术。有个非常有研发经验的同事直接问，“不就是把程序所有的执行路径可能性都列举一下嘛，很难吗？”还真难，我们正常万行级的程序，想要枚举这些路径都要让CPU跑上亿年。但是，往往不做这个研究的人，是不了解该技术的难点到底在哪的，即使他已经写了二十年的程序。

程序分析本身是一个非常有门槛的技术，不可能让每一个开发者都了解 sound和complete的区别。但是很不幸，程序分析的普及难度也在于此，就是每一个程序员其实都需要程序分析，都期待 像分析在编译中应用一样， 无感，门槛低，可参与，可做主。Google在2017年Tricorder: Building a Program Analysis Ecosystem 就讲过， 如何把分析更好的融入到工业应用中。它提了几个非常有技术牵引力的概念，比如让程序员全民参与，比如要让使用者来定义分析的结果好坏等。 其实，我们团队一直再向这些方向构建我们的程序分析基础设施。 

这里打个广告，蚂蚁下半年计划开源程序数据化DataLog分析引擎。该系统类似CodeQL（非开源），我们在过去两年做了很多技术攻关，能让程序员写SQL一样查询程序分析信息。本月蚂蚁已经开源了CodeFuse代码大模型，其中的代码数据质量筛选，就是通过该引擎完成的。哎呀，和前面梁老师和彭老师提到的程序分析数据化，又呼应上了。 

Question 4

主持人：大模型表现出了很强的代码分析和理解能力，甚至可以直接完成缺陷检测和修复等任务。那么大模型技术与程序分析技术存在什么样的关系？大模型的出现会如何影响程序分析技术及其应用的 发展？同时，程序分析技术是否也可以在大模型的构建和应用上发挥作用？

孙军：

我感觉大模型出来以后，未来的编程模式肯定是不一样的，至少说程序员可以很大程度的从一部分底层的编程的实践里解放出来这儿。而就是说程序员可以更关注于高层的程序设计、程序架构等等这些问题。这样我觉得是可以很大程度的减少程序员在底层编程的时候犯的错误。从而造减轻程序分析的压力。同时，就刚才提到的，我们也可以考虑设计一门更针对大模型生成的更安全的编程语言。从而从根子上减少各种各样安全问题。

观点讨论

@熊英飞：@孙军 这个思路有意思啊。以前设计编程语言给人用，现在设计语言给机器用。

@孙军：@熊英飞 是啊。人的思考有成本，机器没有，语言就可以设计的更安全了。

@王迪：@熊英飞 或者设计个语言人和机器交互使用。

@孙军：@王迪 这个就是编程语言啊。

@王迪：@孙军 我可能是想说让机器用的那部分还能自我生成一些内容

张川：

近半年来，大模型在计算机领域受到了广泛的关注，并在各种与程序有关的任务中表现出惊人的效果，特别是在代码生成、解释和缺陷修复等任务上。然而，如果聚焦于程序分析的其他任务，特别是静态缺陷检测，我认为目前的大模型尚不具备对通用大规模代码进行深度分析的能力。虽然大模型在一些领域特定程序的分析上取得了不错的效果（比如智能合约上的缺陷检测），但本质上还是得益于“数据的重叠效应”。具体来说，大模型在进行预训练时见过相似或相同的漏洞类型，从而在智能合约这种程序结构相对简单、代码规模相对小的程序上能取得一定的效果。然而，对于其他语言和更大规模的代码，比如百万行/千万行的 C/C++/Java 代码，我认为现有的大模型还无法进行端到端的分析。但不可否认的是，现有的大模型技术和程序分析技术是存在优势互补的关系的，在程序分析这个领域内，两者都不可以互相替代。

大模型的出现可能会使得程序分析领域出现一种新的分析模式（neurosymbolic program analysis）。经典的程序分析技术，除了基于模式匹配的分析，大多数方法都是基于符号化推理的技术，包括用各种图表示抽象程序语义或者用逻辑公式抽象程序执行状态，这些过程都是一种 symbolic analysis，好比人在调用左脑的逻辑思维能力从细节上理解程序的语义。然而，在大量数据上进行预训练得到的大模型具备了从经验角度理解程序功能的直觉。不同于符号化分析，大模型也可以对程序中的自然语言成分，包括注释、函数名和变量名进行理解，从而得到一些 high-level 的语义信息。一个非常经典的例子在一些资源管理的库函数中，函数名往往有特定的 token，比如 create、init、free、destroy 等等，这些自然语言成分使得大模型能模拟人通过右脑思考的过程，通过经验、直觉理解程序的功能。在过去多年的研究中也出现了大量的利用各种机器学习技术辅助程序分析的尝试，但我相信大模型自身具备的特殊的强大的能力，特别是文本理解和代码解释的能力，使得它有希望在各个具体的程序分析子问题上发挥它不寻常的价值。

最后，作为程序分析的研究者，我们更希望程序分析技术在大模型的时代浪潮下体现出更大的价值。正如上面所说，大模型在一些特定的程序分析任务，比如大规模通用程序的静态缺陷检测上，依然存在很大的局限。因此一个值得探索的问题是，对于某些特定的任务，比如静态缺陷检测的某些子问题，可以考虑通过静态分析技术产生数据，并选择合适的基模型（比如 Code Llama）进行 fine-tuning。另外，我们通过尝试发现现有的模型在各种推理类任务上做得并不好，特别是程序分析中的约束求解和图可达性问题，尚未得到有效的现象论证用大模型做这些推理任务的可行性，这些或许也是值得探索的问题。最后，从终端应用层面上，现有代码大模型的主要应用领域依然是各种代码生成问题，包括代码补全和合成、程序修复等等，但是生成代码的正确性依然是未知数。具体而言，我们需要关注不同维度的正确性：语法的正确性、语义的正确性（程序语言角度无 bug）、实现与设计的一致性、甚至性能上的最优性等等。因此，程序分析技术在大模型驱动的软件开发中一定会有更大的需求，也能发挥更大的价值。

熊英飞：

目前从我们的经验来看，大模型对于一些表层的性质能很好的捕获，所以我们预期在一些需要大量人力定义表层性质的领域，比如检测很多不同类型的安全漏洞，大模型或许能起到比较好的作用。不过多数程序分析的研究都是关注需要通过较深推理才能得出的结论，比如指针分析可能要关联很多函数分析指针的传递关系，这些问题直接交给大模型通常做不好。毕竟从本质上来说，Transformer架构针对一个问题只能完成固定次计算，无法解决需要大量计算的计算密集型任务。

我们也很关注大模型是否能用到后面这种计算密集的任务上，不过目前似乎没有看到相关的论文。

陈振邦：

大模型的出现与现有程序分析技术两者之间是互相补充的关系。例如，一方面，我刚才也提到了，大模型在程序规约方面可以为已有代码分析提供帮助，降低写功能规约的工作量；另外，在分析扩展性与精度的权衡方面，我认为大模型也有可能可以提供一些指导和帮助，例如我们选择不同的抽象模型来分析验证程序时，可以考虑用fine-tuned大模型来做推荐；然后，在误报消除方面，大模型也可以发挥作用，目前也出现了一些工作。我认为，大模型的出现会进一步推动程序分析技术的应用与发展。另外，传统的程序分析技术也可以在大模型的应用方面发挥作用，我认为这主要的场景在代码大模型的应用场景，例如对于代码大模型推荐的代码是否正确可信，我们可以考虑使用分析验证的手段来提升大模型生成制品的可信。

观点讨论

@李弋：@陈振邦 假定LLM自己具有程序分析能力，如果让LLM自己分析自己生成的代码，可能像alpha-go那样自我锻炼么？

@熊英飞：@李弋 这个好像有挺多论文了，是可以有提升的。相当于给了模型更多思考时间。

@陈振邦：@李弋 这个有意思，不过我觉得如果具备这个能力，是不是在生成之前就先分析一下。另外，功能方面的理解我觉得可能一直会是个问题。

@李弋：如果human-in-the-loop，引入一点外部推力，做些正确/错误的标注。LLM就不是一个完全闭环了。

谢肖飞：

和陈老师观点一致，我也认为代码大模型和程序分析将是一种互补关系。一方面，代码大模型可以被认为是一种特殊的“静态分析”技术，其可以快速并且较准确的对程序代码进行分析，比如数据流分析等。大模型可以更容易的集成到不同领用中，与传统的静态分析相比，开发人员的学习成本大幅度下降，开发人员只需要学习如何与大模型进行交互，再将大模型集成到自己的任务中。最近的很多工作已经证实大模型在代码修复，漏洞分析以及缺陷检测等不同任务中已经可以打败很多传统的基于程序分析的方法。我个人觉得未来许多需要静态分析的需求会直接通过大模型来满足，当然一些特殊的场景与任务仍可能需要定制化的静态分析。

另外一方面，传统的程序分析技术也可以更好的帮助与大模型的交互，比如可以基于程序分析的结果来构造与任务相关的 prompt，像代码修复、漏洞检测等，此外，与静态分析类似，大模型也会有一定的缺陷，比如幻觉，误报，以及输入长度有限等。目前很多动静结合的思路仍然可以迁移过来，比如使用大模型进行静态分析，动态分析方法来确认结果的正确性，从而可以缓解幻觉与误报等问题。我们最近也在探索将大模型应用在一些比较难的任务中，比如循环不变量分析，终止性分析等。有些结果出乎意料的好，大模型对于这些程序可以较好的分析与推理。 同时，也有很多的例子在一本正经的胡说八道，在给一定的提示后又能够修正，这些检查与提示可能可以通过传统程序分析自动化获得。

程序分析在大模型的构建和应用上能发挥一定作用，尤其是代码大模型的构建。当前代码大模型主要还是直接训练代码的，但已经展示了较强的代码分析能力。对于一些比较难的问题，如果可以先做一些简单的程序分析并把这些信息也加入训练过程中，我个人觉得可能可以进一步提升模型对代码理解和分析的能力。

谭添：

如果将大模型看作和程序分析一样的黑盒，输入为程序，输出为程序性质或行为，那么大模型确实展现出一些传统程序分析技术的能力。但是目前就我的感觉，大模型分析结果的可靠性以及能分析的程序规模还无法与传统程序分析相比。另一方面，大模型也能给出一些抽象层次更高的关于程序行为的结论（但就我个人使用体验来看，可靠性相当存疑），而这一点传统程序分析目前并不擅长。所以合理的方式应该是两种技术互补。

王迪：

一方面，大模型技术的出现为程序分析算法的设计提供了非常充足的非形式化信息，特别是对代码的理解方面。这样在设计数据驱动型的程序分析算法时，通过与大模型的交互来降低分析的误报率，这应该有一定的潜力。另一方面，程序分析技术当然也可以用在人工智能软件的开发中，不过我在这里瞎聊一下，就是大模型技术的出现可能意味着一些新的编程范式会出现。想像一种编程语言，它既允许用户通过大语言模型通过自然语言描述一些需求，同时也允许用户在这些需求中插入一下传统编程语言支持的逻辑，那么对于这种新型编程语言，我认为程序分析技术也大有可用之处，一是新范式可能需要对一些新型的性质进行分析，二是在设计新语言的时候，我们就可以把需要的程序分析纳入进去，形成一个可信又自然的新语言。

观点讨论

@熊英飞：“Natural language programming is a bad idea.”——迪杰斯特拉。

@王迪：@熊英飞 Dijkstra的literate programming是专业程序员的自我修养。不过natural language programming可能是让非程序员也能进行特性领域编程的一个路子吧。

李弋：

大模型给人最深刻的印象就是百事通，可以为我们提供丰富的领域知识。因此，当被分析的程序是处理某个领域的问题时，可以通过大模型来生成更加具体的约束，从而避免计算中的因为抽象引入不合理的元素。

程序的性质，特别是基于语义的分析，都是抽象归纳和推理出来的。按照目前的LLM所用的生成式的网络架构，大模型是很难推理出来可能得性质。但是，如果大模型见过类似的情形，应该可以给一个/些可能的结果，可能会对我们有帮助。

虽然说，基于逻辑的推理的序列，也可以看做是一个推理的生成序列。目前来看，LLM还没有面向推理做精细的调整，还不具备我们人类专业人士所具备的推理能力。

就程序分析而言，大模型和经典的程序分析比，就是业余运动员和职业运动员的对比。但是因为LLM见多识广，程序分析如果能过作为一个专业的agent，可以给LLM从语义上提供程序的信息；LLM结合其它的agent，譬如具有抽象能力的agent，说不定可以找到自动化的途径。

正如陈老师说的，程序分析用于验证LLM生成的代码。如果大家写代码用LLM越多，那么程序分析的市场就会越大。

现在的LLM，经常会给出一些莫名奇妙的错误，表现的也不稳定。针对这种基于概率的计算，程序分析也在取得一些进展。北大的熊老师组，就做了一些连续的工作。相信也能对LLM的程序质量的提高有所帮助。更进一步，如果基于一些基本的元素构造构造神经网络也看成是一种编程，程序分析的思想和方法可能也可以运用一下。好像最近也有不少的工作。

董震：

大语言模型确实给程序分析带来很多机会，大模型的积累了很多领域知识，这些知识可以很好的帮助程序分析优化求解空间，很多传统难题可以得到缓解，进而提高程序分析技术的实用性。

另一方面，程序分析也可以解决大语言模型应用上的一些难题，比如大语言模型的上下文长度受限，难于把超长的代码喂给大模型，而程序分析可以根据问题提取必要信息，缩短上下文长度，提高大语言模型的应用性。

梁广泰：

大模型技术与程序分析技术将会更加深入的进行结合，两者将相辅相成，将携手在很多传统软件工程场景中带来有效性的大幅提升。

核心观点：越偏向代码功能特性理解的业务场景下，LLM发挥的价值将会越明显。

理由：软件程序一方面在基于严谨的语法来体现业务逻辑，另一方面要通过合适的命名来保证代码自身的可读性。这些用来体现命名的元素，如类名、方法名、属性名、注释等，可以很大程度上帮助理解代码的功能性特性。而大模型技术恰恰“善于”利用这些命名元素来理解代码的功能性特性。越是需要对代码功能进行理解的场景下，大模型技术发挥的作用越明显，比如代码搜索场景，基于LLM的表征学习技术可以在高维空间中更加精准映射每个代码片段所实现的功能，从而支撑我们进行更高级别（如type4）的代码搜索技术。然而针对type1-3的代码克隆，更多需要的是在代码树空间上的局部匹配而非语义理解，因此该场景下LLM能够发挥的作用比较有限。

随着LLM的技术快速发展，AI应用将会加速发展，而AI应用构建过程中也会存在一系列特有问题，如海绵样本、数据泄漏、误判偏见或幻觉等问题，围绕这些问题，业界也在积极采用程序分析技术来尝试发现或辅助解决这些问题。

语言大模型也具备代码生成等能力，针对生成的代码可能存在 高危license侵权问题、安全漏洞问题、甚至幻觉问题（出现原本不存在的三方库api调用等），针对上述场景，可以应用软件分析技术进行问题缓解。如利用开源片段引用分析技术，进行高危license片段的识别和过滤；利用静态安全漏洞检测技术进行漏洞代码片段识别；基于api知识图谱技术进行幻觉识别并自动矫正等。

狄鹏：

LLM在端到端的文本类任务效果斐然，像代码生成，测试用例生成，缺陷检测修复等。大模型和程序分析是紧密结合的，一方面大模型需要程序分析提供数据，也就是我们做程序数据化，信息化的来由。我们甚至还在尝试将开发者的整个研发流程信息，通过程序分析的能力串联起来，从程序到需求的自然语言描述有机结合起来。这个是一个能改变研发生态探索，很有魅力。

另一方面，我们也行思考如何把LLM本身应用到程序分析里。在编译器领域，ML in compiler 已经有很多年的研究了，LLM会注入新的活力。在AIOps领域，动态运维方面， AI也给程序分析带来了很多不一样的启发。

还有，LLM的模型安全，LLM围栏祛毒，也都需要程序分析能力的介入。今年PLDI，LMQL: Programming Large Language Models 也从语言视角对LLM做了新的研究，如果这个方向有所发展，会给程序分析在LLM领域的应用开一个新的窗。

Question 5

主持人：您对程序分析今后的发展趋势和方向有什么看法？同时，您对程序分析技术的研究者、实践者以及软件工程及相关专业的同学们有什么建议？

孙军：

我感觉我也没有什么好的建议，程序分析本身是一个很有意思的。这里研究题目门槛很高，但是里面各种各样的问题也很有意思。只要编程还在，我感觉程序分析的需求还是有的。如果一定要给什么建议的话，我感觉最近的一些把编程和大模型相结合的尝试，比如说像最近比较流行的LangChain这样的架构，我感觉很值得大家关注或者去尝试。

张川：

在LLM的趋势之下，越来越多的行业会有软件的深度参与。在LLM还不会停止胡说的情况下，程序分析和验证会变得越来越重要。所以这是一个越来越重要的行业 （Bertrand Meyer). 像之前说的，程序分析（静态分析）必须走数控库系统的道路，也将会包涵几乎计算机系所有方向，所以只要有天赋加努力，吃喝不愁。

熊英飞：

程序分析作为在发明计算机之前就被图灵等先哲研究的问题，在软件理论中处于基础性地位，程序分析的改进意味着上游的编程语言设计、编译器实现、软件开发支撑工具等都能得到系统性的改进。目前这个基础性问题所依赖的理论仍然是很多年前提出的抽象解释理论，在很多方面都存在局限。比如刚刚提到，只能处理确定的部分，无法处理只能拿到部分信息或概率信息的非确定的部分。另外，主要关注是否满足属性这一方面的分析，对于程序的效率等量化属性难以处理。在设计层面的支持也很不足，选择不同抽象域对分析效率和精度的影响几乎没有工具能帮助预估。在这个领域是还有很多机会做出抽象解释这样的基础性创新的。我国现在从事程序分析的研究人员也逐渐多了起来，不过感觉多数人是在应用层面做一些针对应用的改进工作。可能还需要大家多思考这些应用层面的问题反映了底层基础理论和算法的什么缺陷，从而有一天提出中国的程序分析基础理论和算法，主导科技进步。

陈振邦：

我认为程序分析后续的发展有如下一些趋势：1）更智能化的权衡策略；2）能力更强的基础设施；3）更多的应用场景。我认为程序分析对计算机方面的理论和工程能力的要求都比较高，可能门槛相对较高一些。对于研究和实践者，我觉得先要夯实一些基础，比如离散数学、数据结构、抽象代数、数理逻辑、编译、抽象解释、约束求解等方面，其次我觉得对于研究人员可能可以从某类具体问题或背景入手开始，逐渐在扩展到基础的分析理论和方法。同时，随着当前国内对于程序分析人才的需求量越来越大，其就业前景个人也比较看好。

谢肖飞：

我认为今后程序分析会与大模型有更多的结合，可以预见到大模型会更加深入地融入到程序分析中，用于提高程序分析的效率和准确性，对于一些不是特别复杂的任务可能已经足够好。同时随着DevOps和CI/CD流程的流行，程序分析将会被用于软件开发过程中进行实时反馈和持续的代码质量监控。对复杂软件系统的分析与拆解，仍然还是未来程序分析的一大挑战。

我个人的建议可能是可以尝试将大模型与传统程序分析结合起来，大模型可能不能完全代替程序分析，但是大模型在某一环可能可以帮忙解决一些问题。最后还是要考虑更加实用的一些技术，没有一个最好的技术，在特定任务下需要更好的平衡。张老师的数据库化是一个很好的思路，同时也能为大模型积累更多的有用的数据。

谭添：

程序分析的许多研究工作并没有得到很好的应用，我认为这其中一个主要原因是这些研究出来的高深技术并没有很好地适配到软件生产环境中，这应该是我们未来努力的一个方向，这也可以使这个领域的技术更好地发挥应有的价值。

而另一方面，我觉得程序分析是一项即有趣又枯燥的技术。它的很多思想、算法非常非常有趣；但分析真实程序时，分析器往往会输出大量枯燥的信息，然而这些枯燥的信息中却又能找到改进甚至突破的线索。所以祝愿大家在品尝乐趣的同时能够克服枯燥，一起推动这项技术的发展。

王迪：

程序分析今后我感觉还是会朝着细分领域发展，就是对某个特定的编程语言、对某种特性的程序性质、对某种要求的程序规模、或者是对分析本身的性质要求（比如可增量、可并行）的程序分析。这意味着有可能程序分析的发展又进入了一次特殊到一般、一般到特殊的循环，在这里面可能会涌现一些新的理论问题。比如我们在做量化程序分析方面的研究，即分析的性质考虑给运行路径赋予权重并分析这些权重满足的性质，这种权重主要包含两类：概率权重（来源于随机性、不确定性）和资源权重（时间、内存等资源消耗的度量）。量化程序分析在评估软件的性能和鲁棒性方面有很多应用。我们在通用量化程序分析理论基础方面做了一些工作，但离一个成体系、可广泛应用的分析框架还有距离。

个人建议的话，就是程序分析领域还是要理论与实践并重，立足于解决软件工程中真实存在的问题。另一方面就是把语言设计和程序分析结合起来，另辟蹊径地发展程序分析技术和国产编程语言。

李弋：

首先，我们的程序分析理论并不完美，很多人还在不断的探索新方式，构造新工具。我们在理论上应该持续探索。

第二，由于算力和存储能力的提升，深度学习大获成功，基于深度学习、机器学习和统计学习等理论，尝试自动化的学习程序的特性，为程序分析提供更有力的工具。

第三，强化学习通过反馈，不断地提高学习的效率和性能，也可以和程序分析结合，为构建自动化的程序分析工具提供指导作用。

第四，应该持续打造程序分析的平台，提升分析的基本能力。

最后，基于分析平台的提供的基本能力，针对特定的分析问题，自动构造针对特定问题的分析工具；甚至在分析的过程中，根据具体的情况来自适应地选择合适的方法和策略。

程序分析处理的对象是程序语言写的代码，需要了解程序语言的工作机制和特性。也就是说，需要掌握足够的程序理论。

其次，程序分析是处理很难的问题，我们要对很多计算理论的知识有所了解，所以计算理论和复杂性肯定是要掌握的。如何来处理这些问题，那么随机算法和近似算法就必须要掌握。

如果想更进一步，那么一阶逻辑及各种扩展、Lambda演算最好也要掌握。当然category theory、topology也要了解。形式化专委的王戟主任就呼吁大家要学好数学。

董震：

总体上感觉，程序分析很大程度上会跟着编程语言走。程序分析是解决程序中的问题，当前主流的系统采用什么语言，针对该语言的特性的程序分析的需求就越多，比如Rust、python语言热度高，那么针对他们的程序分析也会相应增加。

随着新语言不断推出，程序分析面临的问题也会改变，比如概率编程，数据驱动的模型应用，都会给程序分析带来新问题，有些组开始做基于训练数据的模型分析，这些都是值得关注的点。

另一方面，程序语言总是“讨好”开发者的，为提高开发者的效率，程序语言会变的更加灵活，反而给程序分析带来更大挑战，完美解决程序分析问题变的更加具有挑战。

总后一点，从业者需要对程序分析的有基础的了解，根据不同的问题选择合适的分析技术。同时，要清楚分析技术的边界，避免产生不匹配的期望，对程序分析产生误解，导致程序分析的价值得不到发挥。

梁广泰：

程序分析是一个不断发展和演进的领域，未来有着广阔的发展前景。以下是我对程序分析今后发展趋势和方向的几点看法：

1.程序分析技术将更加紧密地与人工智能和机器学习技术进行结合，并可能会存在四种形态：

a. AI for 程序分析：基于通用AI技术思路来解决传统软件分析问题；完全不需要传统程序分析技术，如comment注释生成、代码功能理解等场景；

b. AI in 程序分析：在程序分析过程中引入AI技术解决一些不确定性问题，如进行特定变量在复杂场景过程中的类型推断；

c. 程序分析 for AI: 为AI编程过程 提供 程序分析技术，发现AI程序中的特有问题，如针对AI代码特有的缺陷类型进行分析； 

d. 程序分析 in AI: 在面向研发场景的大模型服务中，应用程序分析技术进行代码相关训练集的过滤、提示词生成、生成结果质量增强等。 

2.可观测性技术/可视化技术的发展：可视化技术可以让开发人员更直观地了解程序的运行情况和问题，未来可视化技术将会在程序分析中得到更多的应用和发展。

3.交互式程序分析技术：当DevOps平台高度自动化流水线后，围绕一个软件项目的静态程序分析结果和动态监控信息将进一步打通。基于动静态程序分析相结合的软件缺陷分析技术将得到进一步推广与应用。

狄鹏：

前面各位老师对发展趋势的聊了很多趋势和见解。我建议每个学计算机的新同学，应该去看看熊老师的分析课件，去bilibili看看李樾、谭添的视频。然后就会被程序分析魅力吸引了，希望有很多的同学能加入到程序分析的基础设施建设上来。

观点讨论

@彭鑫：@狄鹏 我再追问个问题，在蚂蚁这样偏互联网的企业，程序分析如何与微服务系统的特性以及与此相关的智能化运维技术相结合？

@狄鹏：@彭鑫 是的 ，在智能运维的应急架构 和 故障定位，快速止血等环节 都有程序分析的大量应用。tracing 的动态信息和 静态分析的结合应用，是常态。AI的引入是提升技术的高度。

访谈结束

CodeWisdom

一个有知识的软工公众号

发现智能化编程之道