综述分析 | 2030年软件安全往哪走?6位顶会Fellow画出31个开放问题

论文先盘点了现有技术栈的现状——这是全文最短的部分，因为结论很清晰：

静态分析已实用化（Coverity/Cppcheck），但必须提前配置规则、必须指定"哪种API组合会触发哪种漏洞"，本质上还是需要人工写规范。

Fuzzing是过去十年最大的成功故事。Google的OSS-Fuzz已累计发现超过10000个漏洞，覆盖1000+开源项目。但灰盒Fuzz依赖覆盖率反馈，对没有可执行代码的场景（固件、CPS）无效。

符号执行（DSE/KLEE/angr）理论上可以系统探索所有路径，但路径爆炸和约束求解的瓶颈始终存在。微软/三星/富士通的实践案例存在，但离大规模普及还远。

ML漏洞检测则是被点名批评的那个：学术基准上数字很漂亮（CodeBERT声称89%准确率），但跨数据集测试时性能急剧下降——和恶意软件检测领域的"过拟合困境"一模一样。

这部分是全文最厚重的章节，6个开放问题分成两条线：

ML系统本身的安全（Security for ML）：

当软件系统从"人类编写"变成"机器学习生成"，安全分析的对象发生了根本改变——一个神经网络的"行为"从神经元权重中涌现，无法用传统程序逻辑直接推理。

O1（分析ML系统）：形式化方向是把ML模型转译成可验证的传统程序；实证方向是用统计方法量化模型鲁棒性。

O2（ML系统的漏洞类型）：数据投毒、后门攻击、成员推断、模型萃取——这些在传统软件领域根本不存在的新威胁类型，需要全新的分析方法。

O3（ML生成代码的安全）是最直接相关的：LLM会"幻觉"，会生成有漏洞的代码。如果程序员无脑接受AI补全建议，漏洞会以远超以往的速度涌入生产代码。

用ML来做安全分析（ML for Security）：

O5：ML漏洞检测的根本问题在于"泛化"——基准数据集上刷分高不代表真实代码库有效。LLM的幻觉问题在这里同样致命。

O6：安全工具的自动配置。Fuzz需要写driver，SAST需要集成进CI，这些都需要专家知识。LLM能否自动完成这些配置工作？初步结果（有团队用LLM把协议规范自动转成fuzzer输入格式）令人鼓舞。

O7（可靠评测）被单列为重要挑战：某些论文报告的6%假阳性率+7%假阴性率，在工业界根本见不到这种数字。更严重的是，这些模型无法区分有漏洞函数和打过补丁的函数——它们在拟合数据集特性，而非学习真正的漏洞模式。

今天的软件（递归地）由大量第三方组件构成。npm/Python/Go生态中，一个项目可能有几百个传递依赖，真实漏洞数远超CVEs记录的——因为有些项目根本不申请CVE。

O9（SCA在新时代）：当AI编程工具从海量来源抽取代码片段时，代码片段级别的溯源变得几乎不可能——这同时冲击了许可证检测和漏洞溯源。

O10（风险分析）：SCA工具识别出已知漏洞后，仍然需要人工判断"这个漏洞在本项目中是否可被利用"。静态分析在这步要么不精确，要么跑不动。

O11（SDLC全链路）：供应链攻击可以在开发（恶意提交/账户被黑）、构建（编译器被污染）、分发（typosquatting/注册表被入侵）、维护（上游废弃但下游还在用）任意环节发生。

O12-13（生态系统视角）：纵向研究（ecosystem安全健康度随时间如何变化）和生态级修复策略（哪些补丁需要反向移植、哪些下游受影响）。

O14（新系统的供应链）：预训练模型、数据集、云服务——这些在LLM系统中同样构成依赖链，而且更新极快（"快速且不可追踪的外部服务更新"），传统SBOM无法覆盖。

这是论文最有远见的部分。

Google的Android团队用Rust重写新代码后，内存安全漏洞比例从76%下降到35%。当内存安全漏洞减少，攻击者会转向下一类"低垂果实"：

O19（新兴漏洞类型）：当内存安全被解决，注入攻击（命令注入/反序列化）、数据竞争（TOCTOU）、信息泄露（侧信道）将成为主流——这些漏洞的检测需要安全工程师做大量威胁建模，无法靠自动化工具有效覆盖。

O20（输入验证与净化）：污点分析是标准方法，但净化代码本身可能引入新漏洞。更难的是：验证策略分布在代码库的多个位置，没有任何地方集中记录"应该验证什么"。

O21（敏感数据泄露）：侧信道不只存在于硬件——编译器优化（speculative execution）、软件架构设计都可能泄漏信息。定量信息流分析（QIF）而非二元非干扰分析是方向。

O22（分布式系统安全）：IoT/云/SaaS/区块链节点动态加入/退出，没有中央可分析实体。Byzantine类共识算法漏洞是特定于这类系统的典型问题。

O24（CPS）：物理测试太慢且设备可能损坏；虚拟测试需要关于物理环境的假设，而这些假设在实际运行中未必成立。这是CPS安全分析的根本困境。

O25-26（弹性计算/风险分层防御）："假设已被攻破"（Assume Breach）是核心思路。当前系统多依赖单层防护（一旦突破全部沦陷），理想方案是风险驱动的模块化隔离——WebAssembly沙箱、Intel MPK、ARM Memory Tagging、CHERI硬件标签——但这些技术的集成度还不够。

O27-28（组合漏洞与利用链）："奇怪机器"（Weird Machines）理论将漏洞利用重新定义为"为奇怪机器编程"——组合多个unintended behaviors构造可编程的攻击指令序列。防御策略必须能自动发现和阻止这类利用链。

O3：LLM生成代码的安全——这是当下最紧迫、影响最直接的问题

O7：ML漏洞检测的可靠评测——benchmark陷阱不解决，整个领域的进展都不可信

O14：新兴系统供应链——预训练模型/云服务进入依赖链，SBOM无法覆盖

O19：后内存安全时代——攻击者会转移战场，提前研究下一代漏洞类型是防御者的责任

O25-26：假设已被攻破的分层防御——单点防护失效后，行业需要新的默认安全架构

这篇综述的价值不在于给答案，而在于划边界：哪些是已解决的，哪些是正在解决的，哪些是未来十年必须回答的。6位作者覆盖了从理论（形式验证）到实践（CI集成）的全谱系，值得每个做软件安全研究的同学读原文。

点赞 + 收藏 + 分享！