论文分享 | 软件安全分析的现状与未来，从零基础到精通，收藏这篇就够了！_software security analysis in 2030 and beyond: a r-CSDN博客

本文链接：https://blog.csdn.net/leah126/article/details/144636697

引用信息： Bohme, M., Bodden, E., Bultan, T., Cadar, C., Liu, Y., & Scanniello, G. (2024). Software Security Analysis in 2030 and Beyond: A Research Roadmap.

背景

现如今，人类生活的方方面面都依赖于众多互联的软件系统的安全运行。伴随着人类对软件系统的日益依赖与软件系统的扩大化与复杂化趋势，软件工程的研究正在面临许许多多前所未有的挑战与机遇。

例如随着人工智能的不断发展，我们如何评估以人工智能为基础的软件系统？同时由于软件系统越来越依赖于整个软件供应链，我们如何将软件安全检测扩展到整个软件生态链条？未来的系统中会出现哪些漏洞？我们如何检测他们？假设我们无法发现所有的安全漏洞，我们该如何保护我们的系统？

为了回答上述问题，本文首先调查了软件安全领域的最新进展，接着讨论了未来的挑战与机遇，并提出了对软件安全领域的长期展望。

当前软件安全领域的研究进展

2.1 软件分析技术

2.1.1 形式化验证

形式化验证技术为软件系统提供最高等级的安全防护，它指的是通过一些形式化的证明去验证某个软件系统是否会出现特定类型的漏洞。

在过去十五年里，该领域有许许多多的成就，研究者基于形式化验证的方法构建了seL4微内核[1]以及CompCert编译器[2]。

但是该方法存在两个弊端：

1. 形式化验证比起直接分析代码本身需要更强的专业知识（通常需要多年的Phd级别的专业能力）。

2. 在一个软件系统中没有被形式化验证技术分析过的部分往往都会缺乏安全性，而要对整个软件系统的安全性进行形式化验证是十分困难的。

2.1.2 静态分析

静态分析是指在不直接运行代码的前提下对程序代码进行分析。比较著名的基于静态分析的软件分析方法有抽象解释[3]，该方法也可以用于形式化验证。

静态分析方法存在两个弊端：

1. 静态分析方法的扩展性是个很大的挑战，当面临较大规模的代码分析任务时，静态分析方法往往比较难实施。

2. 静态分析方法在运行前需要进行配置，这也就意味着静态分析方法往往只能报告特定类型的漏洞[4,5]（基于配置），而难以分析整个软件系统的健壮性。

2.1.3模糊测试[30]

模糊测试是一种较常用的测试方法，简单来说就是通过生成大量的随机的输入，并用这些输入去测试软件系统。

模糊测试分为黑盒测试，灰盒测试以及白盒测试，黑盒测试指的是完全不依赖于待测系统的内部知识，仅仅关注系统输入与输出的测试方法；白盒测试则需要依赖待测系统内部的知识（比较常见的白盒测试方法有动态符号执行）；灰盒测试介于两者之间。

模糊测试方法被成功运行在很多领域，例如编译器测试，数据库系统测试[6,7,8]等等。并且已经成功发现了许多真实漏洞。

灰盒测试是模糊测试中最常使用的方法，该方法通常以提高待测系统的代码覆盖率为目标，并且结合了各种各样的输入变异机制。比较著名的灰盒测试工具有AFL[9]和谷歌公司构建的OSS-Fuzz。

2.1.4动态符号执行

动态符号执行也被称为协同符号执行（concolic execution），白盒模糊测试（whitebox fuzzing）或者符号执行（symbolic execution）。它通过使用SMT约束求解器[10]去系统地探索程序路径，推断路径的可行性，并为每条路径生成实际的输入。

该技术同样面临扩展性问题，当面对复杂的软件系统时，该方法会出现路径爆炸以及约束求解难的问题[11]。

2.1.5 机器学习方法

当前机器学习方法也被大量运用在软件安全领域，目前的研究有利用机器学习方法协助静态分析去做传统数据流分析的[4]，也有直接利用机器学习技术做漏洞检测的。有相当多的实验证明后者在漏洞检测领域具有相当大的潜力[12]。

但是机器学习方法同样存在不足之处，机器学习模型在面临不在其训练集中的代码时往往表现较差。并且机器学习模型通常只会报告它怀疑某个地方可能出现漏洞，并且存在误报或者报告信息不明确的情况，导致这类信息很难被开发者所利用。

2.1.6运行时保护机制

运行时保护机制通常运用在软件部署过程当中，旨在应对开发过程和测试过程中未能检测到的漏洞。该方法通常用于针对特定类型的漏洞，例如内存漏洞。

该方法虽然不能完全阻止攻击者攻击这些漏洞，但会增加攻击者的攻击难度。

常见的运行时保护机制有堆栈金丝雀（stack canaries ）[13]、控制流完整性（ control-ﬂow integrity）[14]、数据流完整性（data-ﬂow integrity）[14]、代码指针完整性（code-pointerintegrity）[15]和写入完整性测试（write integrity testing）[16]等技术。

2.2 漏洞检测方法

当前大部分的漏洞检测方法都聚焦于内存安全问题上[17]，尤其是对于基于C语言和C++开发的软件系统来说。这主要是由于内存安全问题十分重要并且可以很简单的获得oracles[18, 19, 20, 21]。

为了检测更多类型的漏洞，研究者们发明了差分测试以及蜕变测试方法，并在多个领域也取得了成功[7, 8]。

规格说明（Specifications）是一种很好的指导软件开发的方式，但是在实际软件开发时很难实施，尤其对于一些主流编程语言来说。

机遇与挑战

让我们向前看，未来的软件系统会变得更庞大，更互联，更分布式，更“快”，并且会更加依赖软件供应链，与我们的物理世界有深层次的交互。与之伴随而来的是更多的软件安全问题。

未来在软件安全领域会有更多我们未涉足的机遇，比如当前机器学习技术在软件安全测试领域展现出了非常大的潜力。除了技术方面的机遇之外，在软件安全的教育以及立法与监管领域也有很大的发展空间。

3.1 未来的软件系统

过去我们更关注软件系统的设计与实现，未来我们将更加重视软件系统的部署、更新、维护等方面，这意味着我们会更加关注整个软件供应链的安全。

未来的软件系统会变得怎么样呢：

1. 更加的动态化。未来的软件系统将会由更多的部分所组成，整个软件系统将高度依赖于这些组件之间互联，并且这些组件可能会在系统工作的任意时刻增加亦或是删除。这种动态化的软件系统想要进行安全检测是十分困难的。

2.更新迭代更迅速。现如今大多数的软件系统都有成熟的持续化集成部署（CI/CD）流水线，使得软件系统能够快速的进行测试、更新和部署。但是我们期望未来的软件迭代速度变得更快，从提交修改到漏洞修复全部都是自动化的。这种高度自动化也会带来很多新的安全问题。

3. 更加多样化，可能会集成机器学习组件（模型）。未来软件系统会由很多部分组成。各个部分的差异可能会很大，有些部分是内存安全的，有些部分是内存不安全的，有些部分机器学习模型（意味着不确定性），有些部分是传统的指令式的组件。

4. 更深入我们的物理世界。未来人工智能（AI）系统可能会更加深入人们的日常生活，例如自动驾驶系统。这在给我们带来更多机遇的同时也增加了更多风险。有时候一个漏洞可能会威胁人类的生命。

3.1 机器学习和安全

3.2.1 机器学习系统的安全

传统软件系统由人类用编程语言书写的指令组成，现有的大部分安全测试都是分析这些软件系统的指令。未来我们希望有更多的安全工具去分析软件系统中机器学习模型的部分。

3.2.1.1 机器学习系统的分析方法

1. 将机器学习模型翻译成传统的软件系统（由人类编写的指令组成），然后再用传统的分析方法去分析。

2. 跳过翻译部分，直接分析模型特征，通过采样等实验性的方法去分析模型的不确定性。

3.2.1.2 机器学习系统中的漏洞

1.在大模型的训练数据中注入脏数据以此改变模型的行为。

2.通过特定的输入对大模型进行越狱攻击，让大模型输出不正确的内容。

3.2.1.3 机器学习模型生成代码的漏洞

当前机器学习模型代码生成助手被大规模的使用，但是模型生成的代码不总是可靠的。因此如果开发者不仔细审查模型生成的代码就将其直接并入代码仓库中，可能会导致代码仓库受到污染。

因此如何提升模型生成的代码的安全性和如何审查模型生成代码是未来非常重要的课题。

3.2.2 机器学习辅助安全测试

目前，基于机器学习的软件安全分析方法在漏洞检测，代码分析等领域展现出了极大的潜力。

3.2.2.1 机器学习辅助软件设计

目前的多模态模型不仅可以分析文本，也可以分析图片。这种多模态大模型的能力很适合设计软件系统。

我们未来能否用多模态大模型设计更安全的软件系统？在系统架构层次提升软件系统的可靠性。

3.2.2.2 机器学习辅助漏洞检测

目前已经存在的静态分析方法需要大量人为制定规则，并且这些规则的指定需要对编程语言有较为专业的知识。

当用大量的代码做训练集去训练一个机器学习模型，该机器学习模型就能对该语言有较为深入的认识。因此我们可以采用机器学习模型去做代码分析。

目前有许多基于深度学习和大模型的软件安全分析方法，但是大模型存在的幻觉现象导致此类方法的可信度存在很大的问题。

3.2.2.3 工具配置助手

当前大部分的软件分析测试工具在设计的时候都是通用的，当面临特定领域内的问题时需要进行额外的配置。这在无形中为该类工具的使用造成了不小的门槛。我们能否利用机器学习模型编写工具驱动等方式辅助我们做此类工具的配置工作？

3.2.2.4 效果评估

我们如何评估基于机器学习的软件分析方法的可行性？如何将他们与传统的分析方法进行比较？虽然当前机器学习方法在某些软件分析问题上有比较好的效果，但是其仍然存在很多不足，例如机器学习模型很难区分软件漏洞和软件补丁。

未来我们需要进一步分析为什么机器学习的方法能够有好的效果。同时也应该发展出更新、更可靠的评估方法去系统性的分析基于机器学习的分析方法的有效性。

3.3 对快速更新的软件系统的安全分析

当前软件系统的更新迭代越来越快，相对应的软件分析工具应该也该变得越来越敏捷。这意味着软件分析工具应该更专注于软件系统的新增部分，而不是整个软件系统。未来软件分析的时间应该从小时级降低到分钟级。

并且软件分析工具在分析当前版本的软件系统时可以很好的利用以前版本的表现作为oracle。

3.4 软件供应链

现在的软件系统由越来越多第三方的组件组成，这些组件构成了软件供应链。这些第三方组件往往差异很大。

未来软件系统将面临更多问题，因为漏洞可能在软件供应链的任意部分被引入。

3.4.1 软件组成分析

软件组成分析（Software Composition Analysis, SCA）指的是自动化的识别软件中的第三方组件，基于此可以分析这些第三方组件的漏洞信息以及许可证信息。目前的软件组成分析大多基于系统源代码的克隆检测[22, 23]或者二进制分布[24, 25]。

3.4.2含机器学习模型

生成代码的软件组成分析

随着机器学习模型（下称ML）生成代码的普及，SCA变得更加复杂，因为ML辅助编程工具从大量来源生成代码片段，这些零散代码的使用使得SCA难以识别代码片段的来源。未来SCA需要细化到代码片段级别（如软件基因技术[26]），以确保供应链的安全。

3.4.3 风险分析

尽管现有的SCA工具可以分析出软件系统中三方插件的漏洞，但是很难分析出多个组件之间相互协作是否会产生新的漏洞。

当前现有的静态分析技术有助于识别已知漏洞的影响但是缺乏动态验证确认漏洞在实际环境中的危险。

当前的静态分析技术缺乏可扩展性和准确性。

3.4.4 软件开发过程中的工具支持

在整个软件开发过程中，从设计到实现再到部署维护各个阶段都可能出现安全问题，因此我们需要构建全链路的安全检测工具支持。

3.4 软件供应链生态系统

软件系统中三方组件通常都用包管理器统做分发并在特定生态系统中重用。常见的包管理器有NPM、PIP、Maven等。

目前新的生态系统在不断涌现，如分布式系统、以大语言模型为基础的系统、云服务平台等等。这些新兴系统同样也带来了许多的软件安全问题。

3.5.1 对于生态系统安全的长期研究

目前对于生态系统的研究聚焦于识别漏洞以及漏洞的传播。

由于目前各种生态系统的不断迭代更新以及新兴生态系统的不断出现，这一种类的研究应该定期重复并总结。

我们应该发展新的技术去探究单个项目的安全漏洞如何影响整个生态系统。

3.5.2 生态系统安全漏洞修复

如果当前软件系统依赖一些存在已知漏洞的第三方插件时，我们应该提升我们软件系统的安全性？有些第三方插件的开发者可能会及时修复存在的漏洞并发布新版本。但是有时候这些插件的使用者并不想要更新这些插件。因为对于一个复杂系统来说，更新一个部分可能会造成未知的灾难。

有时候如果更新过程失败不能回退也会造成灾难性的问题。所以我们未来需要研究如何能在更新修复漏洞的同时最小程度的影响宿主系统。

3.5.3 新兴系统的软件供应链

如何做好新兴系统的依赖管理？新兴系统的软件供应链因为其复杂的依赖关系难以管理。比如一些预训练模型、云服务的依赖难以追踪。

新兴系统的快速更新可能会引入新的漏洞。

对于物联网系统，我们需要更强大更透明的安全检测技术。

3.6 漏洞数据的质量

3.6.1 漏洞元数据

如何追踪并对漏洞做唯一标识？当前，漏洞由CVE编号机构（CNA）分配一个称为“公共漏洞和暴露”（CVE）的唯一标识符，并记录在漏洞数据库中。除了CVE之外还有许多其他的漏洞数据库，如Open Source Vulnerability Database (OSVD), 和National Vulnerability Database (NVD)。

然而，目前并没有通用的标准的机器可读的漏洞描述格式。我们应该发展能够在软件系统中追踪漏洞并且能够及时更新漏洞元数据数据库的技术。

3.6.2 SCA工具基准测试

我们应该如何评估SCA工具的能力？尤其是在一些闭源代码组件展主导的领域：如汽车、物联网。当前SCA工具的评估数据集十分匮乏。所以有时候即使某工具在测试集上表现很好在实际使用中效果也并不好。

在某些特定领域，如汽车、区块链等领域想要收集好的数据集是十分困难的，这对SCA工具的有效评估是一个很严重的问题。

3.7 开源软件供应链治理

3.7.1 监管问题

多国政府采取制定软件材料清单（SBOM）相关法规，以增强软件产品的安全保证。

软件材料清单主要用来描述软件的各种成分以及相关漏洞信息，目前已经有对应的SBOM生成工具被集成到安全审计工具当中。

但是目前开源项目对于SBOM采用率仍然很低。并且目前的SBOM工具往往都是针对组件或者库一类级别的，缺乏代码片级别的。

3.7.2 社会技术挑战

如何给软件的安全性设定一个通用的评判标准？除了SBOM之外，有一些组织如Open Source Security Linux Foundation (OpenSSF)为一些开源库设定了分数，这些分数说明了开源库的可信度。并且现在也有一些工具可以评估第三方库。

但是许多开源项目并没有采用这些标准和工具，有些是因为资源限制，有些事因为工具十分难用。由此可以看出如何平衡安全保证和开发效率也是一个很重要的问题。

3.8 除了内存漏洞之外的漏洞

目前的漏洞检测方法大多针对内存漏洞。我们发现使用Rust语言或其他一些内存安全的编程语言开发软件系统可以在一定程度上缓解内存安全问题。

随着内存安全问题的缓解和我们的检测工具越来越有效，攻击者可能会更关注其他类型的漏洞。

3.8.1 新兴的漏洞类型

目前内存安全问题是很好被检测到的，但是其他类型的漏洞如注入攻击、数据竞争(例如TOCTOU)，信息泄露需要更多的理论知识去建模。

3.8.2 输入验证和清除

我们如何确保用户的恶意输入不会影响我们的系统安全？我们需要验证用户输入并且清除用户的恶意输入，从而避免类似指令注入这一类的攻击手段。

同时，软件系统中额外引入的输入验证和清除部分同样也会引入新的漏洞。

用户的输入基本都是字符串，为了更有效的处理用户的输入我们需要更有效的字符串处理技术。

3.8.3 敏感信息泄露

我们如何检测、量化并减少用户的信息泄露？用户的信息可能被系统的任何行为泄露。这些系统行为包括侧通道（side channels），这里的侧通道指的是利用系统的执行时间，内存占用等信息来推断用户的敏感信息。

目前对于信息泄露的关注点从是否泄露转移到了泄露多少并用channel capacity [27] 和 Shannon entropy [28, 29]等指标来衡量。

未来我们希望能够自动化的识别出更多的侧通道，并通过诸如自动化合成攻击(通过结合多个攻击手段合成攻击)等手段评估漏洞的危险性。最终达到减轻用户信息泄露的目的。

3.9 完全虚拟的软件系统

过去的软件安全分析大多聚焦于单体化的，仅仅跑在机器上的软件系统。然而现如今的软件系统越来越去中心化，并且与我们物理世界连接的越来越紧密。基于此我们需要研究出新的软件安全分析方法。

3.9.1 分布式系统的安全问题

分布式的软件系统运行在多台机器上。我们如何对它们进行安全分析？我们如何在分布式系统互相通信的时候尽可能的减少信息泄露？

分布式系统难分析的原因主要有以下三点：

1. 分布式系统是动态变化的，计算节点可能会随时被添加或者删除，这会增大分析的难度。

2. 同时分布式系统有时候会缺少一个可以分析或者测试的中央代理。

3.并且分布式系统还存在一些特定领域的漏洞，例如拜占庭将军问题（Byzantine generals problem），即去中心化的各方需要在没有可信中央方的情况下达成共识。

3.9.2 数据隔离在云系统中的重要性

目前大量用户将他们的信息保存在云平台上。因此在云系统中保护敏感数据的安全是一个关键问题。

云平台通过访问控制规则来保护数据。这些规则制定了谁可以访问哪些数据。形式化验证技术通常被用于验证控制规则的正确性，并在实践中展现了良好的效果。

当前云计算平台的安全技术还存在不少挑战。例如约束求解器需要增强，以处理云计算平台中的复杂约束。相对应的分析工具可以采用差分测试技术而不用用户自己编写断言。

3.9.3 网络物理系统

网络物理系统（Cyber-Physical Systems, CPS）指的是软件系统和物理设备紧密结合的系统。例如物联网系统、自动驾驶汽车技术。

CPS的安全分析十分重要，因为这些系统一旦出问题往往会对人造成生命危险。

CPS的安全分析当前以下存在困境：

1.在虚拟场景下进行分析可能难以模拟现实场景，导致在实际使用中效果较差；

2.在现实场景中分析可能会出现检测速度慢和容易被打断等问题。

3.10 弹性计算

弹性计算（Resilient Computing）是一种假设系统始终存在漏洞的设计理念，通过深度防御实现多层次保护。它确保即使遭遇攻击，系统仍能正常运作。关键技术包括风险分析、分层隔离，以及利用WebAssembly和内存保护等新兴工具来增强系统的安全性和恢复能力。

3.10.1 风险导向的隔离

目前一个软件系统中的子系统的隔离通常是系统进程级别的隔离。这会造成计算效率低下等问题。

未来我们应该发展由风险导向的隔离策略。对于高风险组件应该加强隔离力度例如代码片级别的隔离，对于低风险的组件可以采用低级别的隔离力度。

3.11 突现行为与漏洞组合

在安全测试领域攻击和防御是一种动态竞争的关系，随着防御技术的进步，新的攻击技术也在不断进步。但是在这种竞争中，防御措施一定要占据领先地位才能保证软件系统的安全。

突现行为（Emergent Behaviors）指的是在复杂系统中，当不同部分或层次相互作用时，出现的意外或无法预测的行为。这些行为并非系统设计者所预期。

3.11.1 识别跨越不同层的突现行为

我们如何识别那些结合了不同层（防火墙层、操作系统层、应用层）漏洞的突现行为？复杂的软件系统通常都是有层次结构的，其中低层向高层提供抽象接口。但是由于这些接口的误用可能会导致无法预料的突现行为。

3.11.2 发现和防御攻击链

我们如何发现和防御一组突现行为，以防止攻击者利用多个漏洞攻击系统？软件系统中的一个突现或者意外行为可能不会构成安全漏洞，但是将一连串的突现行为组合在一起则可能形成一个安全漏洞。

为了防御这种攻击我们需要实现能够自动搜索合成攻击链的技术，一旦发现了攻击链就可以很好的缓解它所带来的危险。

3.12 软件安全教育

软件安全教育主要分为两方面：

1. 将软件安全教育和相关工具的使用纳入计算机、电子系等专业学生的必修课；

2. 将软件安全工具（动态分析工具和静态分析工具）的使用纳入软件工程师的必修课。

3.13 法律制定

我们需要有效的法律和监管机制去守护我们的软件安全。为了平衡非技术因素和技术因素对软件安全带来的影响，我们需要立法者、软件安全从业人员、软件安全研究人员以及相关企业多方协作来制定合理有效的法律法规。

参考文献

[1] Gerwin Klein, Kevin Elphinstone, Gernot Heiser, June Andronick, David Cock, Philip Derrin, Dhammika Elkaduwe, Kai Engelhardt, Rafal Kolanski, Michael Norrish, et al. 2009. seL4: Formal veriﬁcation of an OS kernel. In Proceedings of the ACM SIGOPS 22nd symposium on Operating systems principles. 207–220.
[2] Xavier Leroy, Sandrine Blazy, Daniel Kästner, Bernhard Schommer, Markus Pister, and Christian Ferdinand. 2016. CompCert - a formally veriﬁed optimizing compiler. In ERTS 2016: Embedded Real Time Software and Systems, 8th European Congress.
[3] Patrick Cousot. 1996. Abstract interpretation. ACM Computing Surveys (CSUR) 28, 2 (1996), 324–328.
[4] Goran Piskachev, Lisa Nguyen Quang Do, and Eric Bodden. 2019. Codebase-adaptive detection of security-relevant methods. In Proceedings of
the 28th ACM SIGSOFT International Symposium on Software Testing and Analysis. 181–191.
[5] Goran Piskachev, Ranjith Krishnamurthy, and Eric Bodden. 2021. Secucheck: Engineering conﬁgurable taint analysis for software developers. In
2021 IEEE 21st International Working Conference on Source Code Analysis and Manipulation (SCAM). IEEE, 24–29.
[6] Vu Le, Mehrdad Afshari, and Zhendong Su. 2014. Compiler validation via equivalence modulo inputs. , 216–226 pages.
[7] Manuel Rigger and Zhendong Su. 2020. Testing Database Engines via Pivoted Query Synthesis. In 14th USENIX Symposium on Operating Systems Design and Implementation (OSDI 20). USENIX Association, 667–682. https://www.usenix.org/conference/osdi20/presentation/rigger
[8] Xuejun Yang, Yang Chen, Eric Eide, and John Regehr. 2011. Finding and understanding bugs in C compilers. In Proceedings of the 32nd ACM SIGPLAN conference on Programming language design and implementation. 283–294.
[9] Michal Zalewski. [n. d.]. Technical “whitepaper” for aﬂ-fuzz. http://lcamtuf.coredump.cx/aﬂ/technical_details.txt.
[10] Leonardo De Moura and Nikolaj Bjørner. 2011. Satisﬁability modulo theories: introduction and applications. Commun. ACM 54, 9 (2011), 69–77.
[11] Cristian Cadar and Koushik Sen. 2013. Symbolic Execution for Software Testing: Three Decades Later. Communications of the Association for
Computing Machinery (CACM 2013) 56, 2 (2013), 82–90.
[12] Yaqin Zhou, Shangqing Liu, Jingkai Siow, Xiaoning Du, and Yang Liu. 2019. Devign: Eﬀective vulnerability identiﬁcation by learning comprehen-
sive program semantics via graph neural networks. Advances in neural information processing systems 32 (2019).
[13] Crispan Cowan, Calton Pu, Dave Maier, Jonathan Walpole, Peat Bakke, Steve Beattie, Aaron Grier, Perry Wagle, Qian Zhang, and Heather Hinton.1998.Stackguard: automatic adaptive detection and prevention of buﬀer-overﬂow attacks… In USENIX security symposium, Vol. 98. San Antonio,
TX, 63–78.
[14] Martín Abadi, Mihai Budiu, Ulfar Erlingsson, and Jay Ligatti. 2009. Control-ﬂow integrity principles, implementations, and applications. ACM Transactions on Information and System Security (TISSEC) 13, 1 (2009), 1–40.
[15] Volodymyr Kuznetzov, László Szekeres, Mathias Payer, George Candea, R Sekar, and Dawn Song. 2018. Code-pointer integrity. In The Continuing Arms Race: Code-Reuse Attacks and Defenses. 81–116.
[16] Periklis Akritidis, Cristian Cadar, Costin Raiciu, Manuel Costa, and Miguel Castro. 2008. Preventing memory error exploits with WIT. In 2008 IEEE Symposium on Security and Privacy (sp 2008). IEEE, 263–277.
[17] Laszlo Szekeres, Mathias Payer, Tao Wei, and Dawn Song. 2013. Sok: Eternal war in memory. In 2013 IEEE Symposium on Security and Privacy. IEEE, 48–62.
[18] Cristian Cadar, Daniel Dunbar, and Dawson Engler. 2008. KLEE: Unassisted and Automatic Generation of High-Coverage Tests for Complex Systems Programs. In USENIX Symposium on Operating Systems Design and Implementation (OSDI 2008) (San Diego, CA, USA). 209–224.
[19] Cristiano Calcagno, Dino Distefano, Jérémy Dubreil, Dominik Gabi, Pieter Hooimeijer, Martino Luca, Peter O’Hearn, Irene Papakonstantinou, Jim Purbrick, and Dulma Rodriguez. 2015. Moving fast with software veriﬁcation. In NASA Formal Methods Symposium. Springer, 3–11.
[20] Clang Static Analyzer [n. d.]. Clang Static Analyzer. https://clang-analyzer.llvm.org.
[21] Koushik Sen, Darko Marinov, and Gul Agha. 2005. CUTE: A concolic unit testing engine for C. ACM SIGSOFT Software Engineering Notes 30, 5 (2005), 263–272.
[22] Yaroslav Golubev, Viktor Poletansky, Nikita Povarov, and Timofey Bryksin. 2021. Multi-threshold token-based code clone detection. In Proceedings of the 28th IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER’21).
[23] Yu-Liang Hung and Shingo Takada. 2020. CPPCD: A Token-Based Approach to Detecting Potential Clones. In IEEE 14th International Workshop on Software Clones (IWSC’20).
[24] Menghao Li, Wei Wang, Pei Wang, Shuai Wang, Dinghao Wu, Jian Liu, Rui Xue, and Wei Huo. 2017. Libd: Scalable and precise third-party library detection in android markets. In 2017 IEEE/ACM 39th International Conference on Software Engineering (ICSE). IEEE, 335–346.
[25] Xian Zhan, Lingling Fan, Sen Chen, Feng Wu, Tianming Liu, Xiapu Luo, and Yang Liu. 2021. Atvhunter: Reliable version detection of third-party libraries for vulnerability identiﬁcation in android applications. In 2021 IEEE/ACM 43rd International Conference on Software Engineering (ICSE). IEEE, 1695–1707.
[26] Yueming Wu, Chengwei Liu, and Yang Liu. 2023. The Software Genome Project: Venture to the Genomic Pathways of Open Source Software and Its Applications. arXiv preprint arXiv:2311.09881 (2023).
[27] Celina G. Val, Michael A. Enescu, Sam Bayless, William Aiello, and Alan J. Hu. 2016. Precisely Measuring Quantitative Information Flow: 10K Lines of Code and Beyond. In 2016 IEEE European Symposium on Security and Privacy (EuroS&P). 31–46. https://doi.org/10.1109/EuroSP.2016.15
[28] Michael Backes, Boris Köpf, and Andrey Rybalchenko. 2009. Automatic Discovery and Quantiﬁcation of Information Leaks. In 30th IEEE Sympo-sium on Security and Privacy (S&P 2009), 17-20 May 2009, Oakland, California, USA. 141–153.
[29] Quoc-Sang Phan, Lucas Bang, Corina S. Pasareanu, Pasquale Malacaria, and Tevﬁk Bultan. 2017. Synthesis of Adaptive Side-Channel Attacks. In 30th IEEE Computer Security Foundations Symposium, CSF 2017, Santa Barbara, CA, USA, August 21-25, 2017. IEEE Computer Society, 328–342.[30] Marcel Böhme, Cristian Cadar, and Abhik Roychoudhury. 2021. Fuzzing: Challenges and Reﬂections. IEEE Software 38, 3 (2021), 79–86.https://doi.org/10.1109/MS.2020.3016773