静态程序分析技术的应用、市场、发展与机遇

忙了一年，终于在过年期间有时间写点东西，聊聊静态程序分析技术，都是过去这两年做产品过程中的一些观察和思考。

首先想说一下为什么这里用了静态程序分析这个词，而不是平时大家比较常见的SAST或者白盒等叫法，主要是因为从目前来看，静态程序分析技术如今的应用场景并不局限在解决针对源代码的漏洞挖掘问题，还能够解决代码质量和其他衍生的代码分析问题，以及在软件供应链安全的其他几类工具中也都有应用，所以讨论静态程序分析的范围要更大一些。

静态分析与动态分析

首先讨论下静态分析和动态分析的区别。自从编程语言诞生以来就有了程序分析技术，也是从程序分析技术诞生的第一天起就有了静态和动态的区别。其实静态分析和动态分析最开始的区别很简单，取决于做分析的时候是不是要让程序运行起来，基于这个最基础的不同，最终演化出了不同的技术发展路径和应用场景。静态分析的优势在于只分析代码，不需要把程序跑起来，因此不需要准备运行环境和交互用例，落地的成本是比较低的。成本低带来的第二个好处是可以比较方便的做大规模的自动化，并发和调度都比较简单。由于对代码的分析是基于逻辑推理，也不需要准备用于触发各类问题的测试用例，在算力支持的情况下对代码的覆盖率基本可以做到100%。但静态分析的劣势同样来自于只分析代码，由于现代程序的功能与逻辑越来越复杂，一般我们很难在静态分析的场景下完全还原出程序的所有行为。这个在计算复杂性理论里已经被证明过，在有限的多项式时间内穷举一个程序的所有可能状态是一个NP困难问题。因此困扰静态分析的难题是分析的准确性比较低，这个也是从业人员这几十年以来一直努力去优化解决的方向。

反过来说，静态分析的劣势就是动态分析的优势，由于分析的过程中程序处于运行状态，因此我们得到的各类数据都是真实可靠的，准确性得到了保证。但是动态分析自身的限制也比较大，对于大部分的程序来说，准备一个能够运行并且实时提取程序内部数据的分析环境是比较困难的，尤其是一些偏底层硬件的场景。此外由于分析工具无法理解对象程序的运行模式，需要人为的准备测试集，以此来触发程序的各种行为。这些前提都导致了动态分析的落地和使用成本比较高，一般情况下是作为专业人员人工分析的辅助工具存在。为了探索动态分析技术商业化的可能，研究人员通过限制分析对象的类型来降低使用门槛，提升自动化程度。比如网络安全领域常见的DAST漏扫工具，就是专门针对WEB应用的动态分析工具。由于把分析对象限制在了WEB端应用，分析环境比较好准备，各种测试集也可以基于漏洞Payload库来实现。当然DAST仍然有比较大的缺陷，比如对漏洞成因定位较为困难，因为动态分析只能够给出某个接口存在问题这样的结论，具体问题出自接口后的哪一行代码则需要人工的深入分析。为了解决这些缺陷，近两年诞生了基于插装的交互式测试工具IAST。此外，为了解决其他场景下的测试集生成的问题，Fuzzing技术也是现在比较受到关注的方向。通过异变算法来自动化生成测试集，Fuzzing技术一定程度上解决了人工准备测试集工作量过于庞大的问题，让动态分析技术能够应用到除WEB以外的地方，比如针对协议、基础软件、固件的测试分析。这些都是动态分析领域这么多年以来演化出的不同产品形态。

总的来说，静态分析和动态分析技术是两类互补的基础技术，能够以不同的视角和方式去帮助开发人员理解程序。由于各自的优劣势不同，演化出了不同的应用场景和产品类型。条件合适的用户可以搭配着使用，能够获得更好的效果。从产品化的角度来说，个人还是更看好静态分析技术在更大范围内的落地，主要是因为对于分析对象没有类型限制，在很多不同的行业都能够得到应用。低落地成本和高自动化的天然优势也比较适合不同规模的研发团队使用，从市场潜力上来说更大。

静态程序分析技术的应用场景

我们刚才提到了静态分析的先天劣势是受到计算理论的限制，准确性不高。虽然我们不能100%还原程序的行为，经过这么多年技术的发展，研究人员通过平衡分析的目标、准确性和完备性，仍然为静态分析技术找到了一些能够解决的比较好的问题，这其中的一部分被市场证明了具备比较好的应用价值，形成了成熟的落地场景。从所解决的问题来看，目前静态程序分析技术主要应用场景大致有以下几类：

代码风格分析

针对代码风格的分析技术相对来说比较简单，因为风格的检查往往不会涉及到上下的语义信息，主要是对代码进行语法检查。因此，对于代码风格的分析不需要引入复杂的程序分析技术，很多开源工具都可以完成的比较好。另外，由于对于代码风格的定义和要求往往因企业而异，业界也不存在统一的第三方标准，大部分有相关需求的企业往往参考大厂的成型代码风格（如Google的一系列code style）再进行调整，然后选择合适的开源工具来搭建自动化分析能力（如与Google C++ Style配套的cpplint、SonarQube等等）。

代码质量分析

针对代码质量的分析需求主要集中嵌入式研发领域，众所周知，由于所使用的场景较为底层，嵌入式软件对于代码运行的稳定性有着非常高的要求。同时，由于嵌入式硬件在算力、存储、内存等方面的限制，嵌入式软件对于运行效率、内存占用、代码体积都有着比较苛刻要求。在这样几方面需求的影响下，嵌入式软件对于软件代码质量的要求要显著高于其他领域。并且在嵌入式研发领域大家所使用的又是C/C++这类语法复杂、比较容易写出BUG的编程语言，能够对代码进行自动化质量检查的静态分析工具成为了该领域必备的研发支撑软件。

针对嵌入式领域C/C++代码的质量分析工具目前已经被广泛的应用在物联网、军工、航空航天、能源电力、医疗器械、轨道交通等行业，很多行业已经形成了比较权威的代码质量标准和规范，比如ISO26262、DO-178B/C、IEC62304、EN50128、GJB8114、MISRA-C/C++等。

对于代码质量的分析，从技术上来说要难于代码风格检查，部分代码质量规则会涉及到代码的上下文语义信息。同时由于已经形成众多权威的代码质量规范，软件研发企业往往对相关工具的检测完备性有着较高的要求。因此在该场景下，一般会选择成熟的商业化工具。由于过去中国在相关领域的研发从业者较少，这些产品绝大部分来自国外，比如QAC、Klocwork、Coverity等。

对于目前主流的代码质量规范来说，大部分的检测规则仍然属于比较简单的程序分析范畴，现有工具对于这些规则的误报率和漏报率都做的比较好。但是有一小部分比较复杂的规则对于程序分析技术有着较高的要求，比如和C/C++指针、内存相关的问题，这些问题往往涉及比较复杂的代码场景，横跨多个函数甚至模块，受到程序运行时状态的影响，因此这些问题也被称为运行时错误。由于运行时错误属于严重的程序BUG，会对C/C++程序运行的稳定性带来极大的影响，这类问题不仅仅在嵌入式研发领域受到重视，在其他使用C/C++作为主要研发语言的领域（比如基础软件）同样是研发团队非常关注的问题。

由于运行时错误的触发与程序运行时内存的动态状态有关，传统的代码质量分析工具在面对这类问题时，往往存在极高的漏报率和误报率。在过去，这类问题一般不在静态分析过程中解决，而是放在动态测试阶段进行检查。随着程序分析技术的进步，有部分静态工具通过引入符号执行、抽象解释、形式化等复杂程序分析技术，改善了检测相关问题时的漏报率与误报率，形成了独特的差异化竞争优势，比如Coverity、PolySpace、TIS等。

代码安全分析

代码安全分析是另一个商业化比较成功的静态分析技术落地场景，也就是我们大家熟知的SAST(Static Application Security Testing)或是白盒分析类工具。由于代码质量分析的需求比较集中在嵌入式开发领域，并且随着开发工具链和硬件的进步，大部分行业的软件研发从业人员如今并不会面对太多代码质量方面的困扰。反而随着网络安全产业的发展和网络安全攻击事件的日趋频繁，对于安全漏洞或是相关代码缺陷的分析成为了静态分析技术的另一个主要应用场景。当然这背后离不开这么些年来静态分析技术本身的进步，毕竟安全漏洞从分析难度来来说要远高于代码质量问题。近年来，随着DevSecOps理念的推广和漏洞治理难度的不断增加，安全左移成为了安全行业的热点方向之一。本来只是作为漏洞治理生态一环的SAST工具迎来的新的发展机遇，很可能会成为未来软件漏洞治理的主流手段之一。

由于不同编程语言的安全漏洞从代码形态上来说存在着比较大的差异，SAST工具往往也因为擅长分析语言的不同而具备不同的差异化竞争优势。对于偏底层的C/C++类语言来说，安全漏洞的形成往往是源于代码对于内存的错误操作，攻击者通过组合多个代码缺陷能够获取部分内存区域的读写权限，从而获得劫持程序运行逻辑的能力，进而实现提权等攻击行为。因此对于C/C++类语言来说，代码安全分析的重点就在于如何发现代码中与内存、指针相关的代码BUG，比如空指针解引用、UAF、double free、数组越界、栈/堆溢出等等。由于这些代码BUG即使没有形成可利用的漏洞，也会严重影响程序运行的稳定性。因此在代码质量分析的场景下，这些BUG类型也具备非常重要的意义，针对C/C++语言的代码质量分析和代码安全分析需求在这里存在一定的重叠，部分工具也具备解决两方面问题的能力。由于C/C++语言从编译到语法都比较复杂，针对C/C++的静态代码分析技术也是比较困难的一部分，仅有少部分的工具具备成熟的C/C++代码安全分析能力，比如Coverity、PolySpace、Infer、CSA等等。

虽然在2022年重新夺回了TIOBE年度编程语言的江湖地位，C/C++在国内的使用普及度仍与Java相去甚远。对于Java的分析能力依旧是在国内市场考察一款静态分析工具成熟度的重要指标。与C/C++不同，由于Java的主要应用场景是在服务器侧，针对Java的静态分析工具主要关注如何在代码中寻找与攻防相关的代码漏洞，比如XSS、各种注入、命令执行、路径穿越、密码学误用等等。这些代码漏洞往往具备比较复杂的上下文场景，触发条件也受到程序状态的影响，同时由于Java语言的灵活性，不同项目所使用的各类库也不尽相同，传统的静态分析工具在面对这类问题时往往存在比较高的误报率与漏报率，需要使用者付出比较多的精力进行二次开发和调优才能达到相对比较好的效果。从检测安全漏洞的角度来看，SAST与其他几类开发安全产品（DAST、IAST等）的能力产生了重叠，不过正如上文所说，由于静态分析与动态分析技术各有所长，在大部分的场景下这些不同类型的测试分析工具是互补的关系。由于应用场景更加普遍，因此针对Java的静态分析工具相对可选择空间较多，比如Fortify、Checkmarx、Sonarqube、FindSecBug、CodeQL等等。

上文中说过，在有限的算力下，静态分析技术无法做到对代码的100%分析，尤其是针对代码安全这样一种较为复杂的代码分析场景。在平衡分析效率、分析精度的过程中，通过选取不同的底层分析技术框架，各类工具演化出了不同的能力优势和场景优势。一部分工具通过牺牲分析精度获得了更简单的使用场景和更快的分析速度，比如Checkmarx和Sonarqube，整体的分析能力围绕着模式匹配进行搭建，辅以少量的数据流分析，从使用上来说不需要参与编译，不需要获取字节码，使用更方便，效率更高，但是在面对一些复杂代码场景时分析精度会极具下降，比较适合用在IDE侧或者快速分析场景。另外一些工具追求更高的分析精度，比如Fortify，有着更强的数据流引擎，分析时对于CPU和内存等运算资源消耗更大，分析时间也更久。此外，还有一部分工具专注于提供更强的灵活性，比如CodeQL，通过将代码分析过程抽象成代码解析和规则匹配这两个部分，将大部分的规则匹配工作交给用户来完成，配合上其强大的DSL接口，方便用户基于自己项目的业务逻辑实现效果更好的检测规则。

除了C/C++与Java之外，其他的语言随着应用场景的增加，相关的分析需求也愈发强烈，尤其是在服务器侧使用较多的Python和Go。不过目前来说整体的底层技术积累和基础设施建设仍然不如C/C++和Java成熟。

软件成分分析

软件成分分析（SCA）是近两年开发安全领域新出现的方向，随着供应链安全概念的持续升温，软件成分分析貌似已经成为该领域参与者最多的方向。软件成分分析从概念上来说非常好理解，通过对软件代码/工程进行自动化分析，判断软件中包含哪些组成部分，除了自研代码之外，最需要辨识的就是繁杂的三方组件。在完成对软件成分的分析后，形成具备标准格式的SBOM清单（Software Bill of Materials），之后基于SBOM延展出开源协议合规治理，开源漏洞治理等不同的价值输出。

软件成分分析是典型的易于入门但是难于专精的方向，基础的SCA功能基于软件项目自带的依赖关系管理（npm、maven等）实现，梳理清楚依赖关系后基于公开的License和漏洞数据库来完成后续的功能，整体上落地比较容易，不容易出现误判。在这个层面有非常多的工具可以选择，比如OWASP Dependency-Check、SCANOSS、OSSKB等。

然而在现实的应用场景中，这样的SCA能力可能无法满足用户的需求。基于业务场景，用户可能会提出针对代码片段/二进制文件的进阶依赖关系分析，以及从代码层面对依赖关系进行精细化分析的需求。这些需求就需要引入静态分析技术的帮助，因为涉及到代码层面的特征提取和语法/语义分析。在这些领域，已经有部分商业化工具进行了探索并取得了一定的突破，比如BlackDuck、Jfrog、Snyk等。

其他延展场景

除了上述几个大家比较熟悉的落地场景以外，静态分析其实在一些其他的领域也有应用，只是场景比较聚焦没有形成成熟的商业化场景。同时，我们也注意到有部分的创业公司或是科技巨头已经开始探索静态分析技术新的应用方向，比如利用静态分析技术挖掘软件代码中的隐私合规问题、解决数据安全领域的数据标注问题、对海量代码进行上下文行为分析、对海量代码进行可视化呈现等等。

静态分析类产品的市场环境

随着安全左移以及DevSecOps概念的普及，全球范围的开发安全市场这两年迎来了快速的增长。根据不同外媒的估计，2022年全球DevSecOps市场的体量在40亿美金左右，并且在接下来的十年间将会维持30+%的高复合年增长率，其中静态分析或是SAST仍然是占比最大的一类产品。回到国内市场，根据信通院和其他机构发布的白皮书推算，目前国内的SAST市场规模差不多接近10亿人民币，这里面应该没有包括在代码质量这个领域的工具的销售情况。从与全球市场的对比来看，我们国内的相关市场正处于早期的增长之中，还未迎来爆发。

市场成熟的滞后与很多因素有关，包括了国内研发行业对于研发支撑类工具的理解和接受程度不高、付费意愿和习惯还未养成等等，此外也因为中国的软件研发行业在过去十数年间主要聚焦于上层应用软件的开发，较少关注底层基础软件的开发，因此对于代码质量和安全的需求不够强烈，整体上市场成熟进度落后全球市场。近几年，随着中国整体社会数字化程度的不断提升以及国际局势的快速变化，中国的软件研发行业正在发生巨大的变化。信创、基础软件、新能源、物联网这些对软件质量与安全要求比较高的领域迎来了快速的发展，推动了静态分析类工具及相关技术在中国的普及。而国产化替代的大趋势也为国产的静态分析产品提供了快速追赶的窗口，中国与全球的差距正在逐步缩小。

回到市场规模来看，静态分析类产品存在巨大的市场潜力。与动态分析技术相比，静态分析技术不需要准备运行环境、不挑选软件类型、具备良好的自动化和规模化能力、能够衍生出的价值也足够丰富。静态分析技术天然具备了成为一种普适性研发支撑技术的潜力，相关的产品也具备成为平台型产品的能力。换句话说，任何规模任何领域的软件研发团队，都存在从静态分析技术中受益的可能性，只要找到合适的产品形态和商业模式。

其实从全球范围来看，已经有部分产品开始往平台化的方向进行转变。比如SonarQube，作为老牌的开源代码分析平台，从最开始的代码风格分析，经过多年的发展拓展到代码质量分析，在这两年又通过并购的方式切入了代码安全市场，通过在收费版本中提供代码安全分析能力，实现了营收的快速增长，年收入接近3亿美金。还有Snyk，作为开发安全领域的头号明星选手，从单一语言JavaScript的SCA功能起家，不断的通过自研并购的方式引入新的技术能力，逐步形成了具备SCA、SAST、容器、IaC等多维度分析能力的平台型产品，估值一度接近100亿美金。

静态分析类产品的落地

刚才我们提到了国内的市场仍然处于早期起步阶段，需求的快速提升有赖于大环境的演化。但是从产品侧来看，现有的静态分析类产品均存在巨大的提升空间，产品力的提升能够帮助厂商占据更多的竞争优势，对于整个产业的发展也同样有着重要的推动作用，无论国内还是国外的市场都是如此。

目前国内常见静态分析类产品还是以国外厂商为主，开源的Sonarqube，Infer和CodeQL等，商用的Coverity，Fortify和Checkmarx等。国内厂商还在努力缩小和国际一流产品的差距。

然而即使以国际一流产品为参考，他们在国内的场景落地仍然存在相当的不足，主要体现在以下几个方面：

落地成本高

目前的主流静态分析类产品还是被设计为一种专业人士使用的高门槛工具，常见的开源工具和商业化产品均具备比较强大的自定义能力。丰富的自定义配置能力也意味着若想发挥出工具的真实效果，需要用户投入较多的人力和时间成本进行运营优化，在厂商无法提供有力技术支持的情况下，这对于大部分的国内用户显得有些难以做到。太高的落地成本是阻碍静态分类工具打开市场的第一道门槛。

产品形态陈旧

目前在国内常见的几款商用静态分析工具均诞生于十多年前。大家都知道过去十年是互联网迅速发展的十年，在这十年间软件的研发体系发生了很大的变化，传统的瀑布式研发流程已逐渐被DevOps敏捷研发所替代，IDE之类的研发基础设施也经过了多轮的迭代与进化。而在这十年间，这些静态分析工具的形态却没有太大的变化。任何试图在流水线中集成这些工具的用户一定遇到过这样那样的麻烦，更不用说在应用现代化的场景下去做各类DevOps工具的协同、实现容器化部署、弹性伸缩、算力调度，几乎是不可能完成的工作。作为软件研发体系的一环，静态分析工具必须要跟随着生态的变化而找到自己的发展方向，这也是为什么Sonarqube和Snyk能够成为这个领域后起之秀的原因。

分析精度不足

虽然静态分析技术在近二十年间有了长足的发展，但是很少有厂家能够将这些在论文中大放异彩的前沿技术落地在商业化的产品中，现实世界的软件代码和benchmark往往有着天壤之别。此外，随着分析技术不断的进步，人们对于静态分析技术的期望也在不断提升。简单的问题早已被解决，无论是影响程序稳定的恶性BUG还是影响程序安全的高危漏洞，在现实世界软件代码中隐藏的越来越深，软件架构越来越复杂。传统工具的分析能力无法应对这些复杂的代码场景，过高的误报率导致用户的使用成本大幅提升。能否解决现代化软件架构下的分析精度问题，已经成为用户评估此类产品的首要指标。

静态分析技术与开源治理

开源治理是最近安全行业颇为热门的一个话题，随着开源社区的蓬勃发展，各类软件中自研代码的比重正在逐步降低。而Log4j2等事件的发生也一再提醒研发与安全人员，你所维护的软件中最有可能遭受攻击的部分往往来自于第三方代码。毕竟开源的特性决定了针对这些项目进行漏洞挖掘从难度上来讲要更低一些，一旦有所发现之后能够造成的攻击范围也更广，这样的好事哪个黑客会拒绝呢。

从整个生态的角度来看，开源项目的安全治理可以大致分为两个部分，一个是开源项目自身的安全管理，也就是如何提升开源项目的代码质量，减少潜在的0day漏洞，另一个是如何管理软件中使用的开源代码，防止引入1day漏洞，也就是大家熟知的SCA类工具的能力。在中国，目前大家的目光还是主要聚焦在后者上。相较之下，对于开源项目自身的安全治理一直是一个被忽视的部分，当然这主要是因为中国在全球开源生态中参与度仍然不高，这其实是一件比较被动的事情。不过随着全球局势的变化，国内对于自建开源生态、化被动为主动的意图也愈发明晰，今年也会有相关的标准法规落地，用于推动在软件中更多的使用由中国开发者维护的开源项目。自建生态的好坏咱们暂且不论，保证供应链安全是目前国家最重要的政策方向之一，因此在开源领域占据主动必然是未来的工作重心，作为安全行业的从业人员，应该及早在这个方向进行储备。

当我们讨论开源项目自身的安全治理时，问题又回到了静态分析的范畴内。目前比较主流的静态分析工具都有相关的开源扫描计划，而类似linux内核这样的知名开源项目也是天然的Benchmark，每天都有无数的人用这些项目来测试静态分析工具的能力。虽然我们经常说开源的项目会受到整个社区的维护和监督，代码质量较高，出现漏洞的概率一般会低于私有的自研代码。但这仅限于部分受到广泛关注的开源项目，事实是目前有非常多开源项目的维护人员少的可怜，更不要说做漏洞治理了。有相当一部分的组件类开源项目本身吸引话题的能力有限，但是由于独特性和优秀的性能一直被其他更大的开源项目引用，是当前开源生态的重要组成部分。针对这类开源项目的安全治理由于缺乏人手，一直处于空白状态，正适合静态分析类工具的发挥。

作为行业的一员，蜚语安全一直关注着针对开源项目的漏洞治理。通过自研的静态分析工具Corax，我们已经累计在linux内核、FreeBSD等项目中发现数百个高危的代码缺陷，并协助社区完成了修复。在2023年，我们会开启一项针对这些“关注度低但是重要”的开源项目的扫描计划，帮助他们提升代码质量，降低安全风险，希望为整个开源生态的安全建设贡献绵薄之力。

静态分析技术与软件供应链安全

随着开源热门起来的还有软件供应链安全这个概念。参考NIST 800-161系列指南的内容，软件供应链安全其实是一个比较庞大的体系，覆盖了人员管控、研发基础设施管理、软件成分管理、软件代码安全、代码可信等十数个不同的维度。国外这两年也涌现了不少软件供应链安全方向的创业公司，比如Snyk、Shiftleft、Apiiro、Chainguard、Cycode等等，基本上每个点都有人在做。国内在这一块主要还是集中在代码安全治理上，做SAST、IAST、SCA、ASoC、Fuzzing的都有，以SCA居多。从代码安全治理的角度来看，这几种不同类型的工具各有所长，在合适的场景下可以互相配合，提升整体的分析效率和漏洞治理水平。

静态代码分析是SAST所使用的主要技术，同时也是整个开发安全类产品共同的技术底座，在其他几类产品中都有比较好的应用场景。像IAST、SCA、Fuzzing这样的工具，其实自诞生以来就有一些比较难以解决的问题。比如IAST和Fuzzing对代码的覆盖率问题、不同类型软件Fuzzing驱动的自动化生成、SCA针对代码片段的扫描能力、SCA针对依赖关系的精细化分析等等，这些问题来自于这些产品在市场化落地过程中客户侧天然的需求，也因为具备较高的技术难度成为不同竞品之间的差异化竞争点。而引入静态分析技术是解决这些问题的一种比较好的技术路径，通过静态分析技术来提升动态分析的效果，也是学术界比较热门的探索方向。

代码是一种特殊的数据资产

最后还是说回静态分析技术本身，在上文我们提到过静态分析技术具备非常大的市场潜力，有相当多可以延展的应用场景。我们可以从代码这种数据资产的持续治理角度来思考这个问题。随着整个社会的数字化转型，软件在现代社会的重要性愈发凸显，软件或是代码已经成为了一种非常重要的数据资产类型。不同于普通的数据，我们在过去其实比较忽视针对软件这种特殊数据资产的治理，其实对于很多的研发型企业，软件或者代码可以说是最为重要的一类数据资产。对于代码的持续治理是多维度的，并不仅局限于代码质量或代码安全这些传统的应用场景，还可以拓展到数据安全、隐私合规、代码可信、业务安全、研发效能等不同维度。通过持续的治理，企业能够获取大量与安全、研发、业务、人员相关的重要信息，帮助提升整体的研发效率和业务水平。

不同于常规的数据资产，代码具备独特的结构和解析方式，传统的数据治理技术很难被直接应用在代码上，必须要结合静态程序分析这样针对性的技术，我们才能够从代码中提取出我们希望获得的信息。这也预示了静态分析产品在未来的发展方向，即从单一场景向多维度代码分析能力平台的演化。

再结合市场侧的需求来看，这些方向应该具备比较好的探索前景：

更强的代码分析能力

软件规模的提升和多样性的提升，对底层分析引擎的能力提出了更高的要求。新一代的代码分析技术应该能够解决更复杂的代码场景。

寻找新的应用场景

除了传统的代码风格、代码质量和代码安全外，静态分析技术还有很多值得探索的新的应用场景，比如数据安全标注、端侧代码的隐私合规问题、海量代码的逻辑可视化、代码变更依赖分析、API业务安全等等。

更低的使用门槛

在产品落地侧同样有非常多的工作可以做，理想的目标是打造一款能够让不同水平研发人员都能够使用的静态分析产品，让更多的人能够从静态分析技术中获益。

更强的自动化能力

目前的产品仅仅做到了分析的自动化，其实从代码治理的角度而言还有很多的环节可以通过自动化来降低用户的使用成本，比如自动化BUG修复、自动化代码生成等等。在这些方向上，最近很火的生成式AI模型有着非常好的应用前景。

与其他工具的协同能力

配合Gitlab、Jira等研发管理平台，静态分析技术可以与其他开发安全类的产品实现流程联动，形成互补，提升彼此的分析能力，最终提升整个开发安全侧对漏洞的治理水平。（束骏亮）

声明：本文来自蜚语安全，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。