G.O.S.S.I.P 阅读推荐 2025-01-08 软件安全分析2030远景规划，从零基础到精通，收藏这篇就够了！

最新推荐文章于 2025-12-12 14:04:07 发布

原创最新推荐文章于 2025-12-12 14:04:07 发布 · 806 阅读

9 ·

CC 4.0 BY-SA版权

文章标签：

#安全 #人工智能 #网络

计算机同时被 3 个专栏收录

1722 篇文章

订阅专栏

程序员

1721 篇文章

订阅专栏

互联网

1347 篇文章

订阅专栏

一看标题便知，今天推荐的论文是一篇高瞻远瞩之作，这就是来自TOSEM的最新论文_Software Security Analysis in 2030 and Beyond: A Research Roadmap_

敢叫这样的名字，论文作者是有底气的——都是一众软件工程领域赫赫有名的研究人员。读这种文章，不能像读其他类型的技术论文那样钻研细节，而是要抓大放小，从字里行间去感受未来的研究趋势，然后做出自己的选择。当然不是教你亦步亦趋人云亦云，但是从社区的主流意见里面获取研究方向和研究选择，这类文章的参考价值非常重要。

论文主要分成了两个大的部分：软件安全分析的现状和软件安全分析的挑战与机遇（还是那么高瞻远瞩风格）。下面我们来学习一下领导讲话。

软件安全分析的现状

这部分主要总结了当前软件安全分析研究的几个热门分类，来看看你研究的是哪个方向：

形式化验证：这部分有点像是安全分析里面的“至上荣誉”：代码能被形式化验证，谁还需要Rust？而且近年来社区也确实从理论到实践有了很大突破，包括 seL4 microkernel 和 CompCert compiler 等实用的系统都已经问世了，但是要花费大量人力去写proof仍然是形式化验证的一个硬伤，而且大概是因为搞理论的人都不善于开发用户友好的工具？本领域的工具依然很难用。
静态分析：毋庸置疑，静态分析是软件安全分析领域工具化成熟度最好的方向，而就算如此，在面对复杂的软件代码时，静态分析的核心技术（例如数据流分析）依然力不从心；还有一个问题是静态分析目前的设计策略是发现“特定的错误”而不是发现“功能实现得不对”，遇到新类型的问题就得不停写新的匹配模式。
模糊测试（Fuzzing）：模糊测试这个并不年轻的安全分析技术最近10年可能是安全领域最火的方向，也许和它的运行策略不太容易受到代码的多样性影响有关，堆算力总归是能解决很多问题的。
动态符号执行：符号执行在2000年后在研究领域的火热程度，堪比今天的模糊测试，不过后来慢慢凉下去了，遇到的问题还是和静态分析遇到的类似，就是代码规模复杂之后就容易遇到状态爆炸，很难处理现实世界的代码。
机器学习驱动的安全分析：作者表示，尽管很多人都尝试用机器学习来全自动地替代传统的安全分析，而且一开始看起来效果很好，但是基本上后来都会被证明是只在测试集上有效果，所以现在更多的思路是用机器学习来辅助传统的安全分析，而不是搞替代。
安全防护：看起来很奇怪，为什么讨论安全分析的时候要讨论防护？实际上安全防护是另一种视角的安全分析，通常考虑的是“往后退一步”的安全分析——不一定能发现漏洞出现的第一现场，那就试图发现可能出现问题的地方附近，或者把每一个可能的危险都堵死。常见的stack canary和control flow integrity策略就是着这种思路。

软件安全分析的挑战与机遇

这部分是整篇论文的重头戏，我们把每个子章节稍微展开来介绍一下：

A 机器学习与安全

这个可能是现在关注度最高的一个细分领域吧，特别是如果把machine learning这个关键词换成AI可能就更加火爆了。尽管前面已经说了，AI取代传统安全分析的尝试一次次失败，但是总比经典的程序分析技术已经进入到成熟瓶颈期这种不温不火的局面要好。而且AI的出现还引入了新的问题：Security for Machine Learning（Sec4ML），这里面有三类问题：

对机器学习系统的分析：除了对这些系统传统的代码的安全分析，更重要的是对它们使用的模型的安全分析；
对机器学习系统的安全漏洞的定义：传统的软件安全分析技术虽然没有办法做到精确检测出所有漏洞，但是基本上把经典的软件系统的安全漏洞的类型都给定义好了，可是机器学习领域的安全漏洞仿佛是一个安全研究的盲区，大家似乎都还没有办法很系统地定义这里面出现的漏洞，更不要说怎么去检测了。
对机器学习系统生成的代码的分析：机器写代码和人写代码的风格可能相差甚远，犯错误的思路也许就差得更大了，

当然，for the people也要by the people，今天吸引投资人必须要有Machine Learning for Security（ML4Sec）才行。作者总结下来，用机器学习来辅助安全分析，有如下一些重要的目标：

ML辅助的安全设计：你没看错，ML介入首先要从安全设计就开始，不能等到代码开发阶段。
ML支持的漏洞检测：前面提到过，由于传统的静态安全分析的一个很耗时的工作在于“遇到新类型的问题就得不停写新的匹配模式”，那么ML可能在这个时候能够发挥很大作用，帮助安全分析工具的开发人员快速迭代出新的漏洞检测工具。
ML辅助的工具配置：我们以往使用安全分析工具的经验里面，有一个经常遇到的难点就是要根据实际的分析对象进行配置，而新手往往在这里就会吃瘪。ML可能在这个地方能够发挥比较大的作用。
正确性检查：在很多研究成果里面，基于ML的安全分析都有很漂亮的数据，但这些结果很难说真正具有soundness：只在特定的数据集上运行良好，没法解释原因，甚至换个数据集就有天差地别的表现，这种根本谈不上实用。

B 针对软件演化过程的安全分析

除了人人都在关心的AI，作者还呼吁大家特别要关心现代软件工程已经是一门可持续发展的学科的特点。也就是说，软件代码是增量的，搞安全分析也要特别考虑这一点。插一句，这一点上我们是完全赞同的，因为我们在2022年就写了一篇叫做_PEDroid: Automatically Extracting Patches from Android App Updates_的ECOOP论文，重点就是从代码更新的diff里面去找到安全问题（安全补丁）的蛛丝马迹。

C 软件代码供应链安全

去年中东的寻呼机爆炸事件不仅收获了一堆见过这种古董的老男孩的啧啧称奇，还让大家更为关注供应链安全。虽然软件代码的供应链安全只是供应链安全的一个很小的分支（那些传统制造业甚至看不上软件），但是现代软件代码生态环境和软件开发流程的先进性也不是那些传统制造业能比得了的（不服来战）。特别是开源软件搞了这么多年之后，台湾软妹子写的组件用到了土耳其抠脚大汉的底层库，然后被集成到了俄罗斯供应商的系统里面最后辗转卖给对面乌克兰企业去用的情况也不是不可能。怎么进行更好的软件组分分析（Software Composition Analysis，SCA）已经成了当务之急：除了更精确识别三方库中的1-day甚至n-day漏洞之外，SCA还要考虑如何应对AI生成的代码中的漏洞，以及面对当前越来越复杂的整个开发流程和生态环境（说实话，每个语言现在都搞出来一堆包管理器这个真是最让人诟病的一件事）。总而言之，开发者已经把这个生态环境搞得太复杂了，SCA必须快速跟上。

另一个大家总是提到（但是没人愿意费力去做）的事情是漏洞数据库的质量问题：现有的什么CVE、CNVD之类的数据库，（对于软件安全分析工具而言）基本上就没什么太大的参考价值。除了告诉你哪个软件（库）的大版本有一个什么问题，其余信息全部遮遮掩掩，甚至每个漏洞的信息组织模式都没法统一起来（如果CVE上报要求的是像学术论文投稿那样要LaTex排版并且有严格的格式要求，估计要刷掉一大票黑客？），所以也许只能期待未来老黄联手OpenAI或者微软、Google什么的能弄出来一个超强算力的AI，让AI来做这个费力的事情？

D 内存安全之上

大家老是看到什么新闻说目前软件的很大比例的漏洞都是来自内存安全问题，但是这让人怀疑是不是Rust基金会搞的鬼。内存安全问题那是历史积累的老问题了，越来越多的新问题现在都和内存安全没什么关系了（web安全选手狂喜？不是），现代软件的攻击面可能更多来自于对数据本身的威胁（权限检查问题）、用户输入的验证不够仔细等更加high level的点。也许内存安全问题永远不会完全消失，但是这么多年一直搞use-after-free大家也都乏味了，安全分析工具也需要增加新的卖点，不是吗？

E 更加多元化的系统

和上个世纪的计算机系统相比，现在的软件运行环境远不止是“都通网了”这么简单，更多元的系统运行结构才是软件安全分析的新挑战：分布式系统、IoT环境、SaaS模式、区块链智能合约，这些让开发人员都会头疼的东西，经典的安全分析工具来了都会傻眼。更要命的一点是由于环境的分布，数据也散布在不同的节点中，而数据安全也已经成为现代软件安全里面的关键要素，请问怎么去分析……安全分析工具要做的事情真是太难了吖！

F 防御性计算（Resilient Computing）

这个地方的Resilient Computing很容易让人想到“弹性计算”，但是这和云计算里面概念（特别是那些云厂商想要卖给你的“弹性计算服务器”）完全不同，而更多的是讨论如何在“假定敌人已经攻进来了”的情况下还要保证纵深安全，所以权且翻译成“防御性计算”。当然目前计算机系统的防御也基本上都是这种策略，你不太可能（比攻击者）提前识别出所有的漏洞并且及时修复，因此只能做一些通用的防护策略，这其中我们专栏经常介绍的网格化管理区域隔离（compartmentalization）就是目前很常见的研究主题，尤其是结合各类新型的硬件特性来提升效率。

G 复杂攻击手段识别

这个标题又是很难翻译（Emergent Behaviors and Vulnerability Composition），结合文章的细节，主要是讲的怎么样去识别那些更加“组合性”的安全攻击：由于现在很多的攻击都不是只依靠一个漏洞，而往往是组合了一堆问题（可能每个问题都还不至于高危，甚至很多开发人员往往都嗤之以鼻觉得不是漏洞），最后击穿整个系统。而传统的软件安全分析技术要识别这类攻击就更加困难，单纯去分析每个环节好像都不太看得出来异常，最后莫名其妙就被攻陷了，很像跟高手下棋，一步一步被引入陷阱给将死了。

H 安全教育

论文的这部分是我们要重点表示支持的，因为作者提到了两个关键的目标，第一个是让安全成为程序开发的必修课，这一点必须是推广到每个计算机科学专业的学生，甚至所有程序开发人员，因为太多的人搞不清楚安全的特征，要么就追求绝对安全，要么根本不知道安全威胁是何物；第二个是推广软件安全分析工具的使用，这个一方面需要培养开发人员使用安全分析工具的习惯，不要停留在无视编译器warning的原始阶段，一方面也得需要工具开发者的努力（降低误报！！！）才行。

I 法律与政策

最后，果然是只有法务部门才是终极武器（迪士尼和任天堂笑而不语）。错了，本文作者当然是留了私心的，这里讨论的是要求监管部门如何制定法律法规去强迫开发者保证安全，保证不了安全就要学安全，学不会安全就要付费咨询我们专业的安全研究人员，这才叫知法懂法守法对不对。立法者就应该治一治那种你免费给他们报告漏洞还爱理不理的样子，让他们以后高攀不起！

总结一下，这篇没有图、没有表格、没有方法也没有实验的论文读下来，让人快速就能够对本领域的希望和失望都有所了解。如果你想入行软件安全分析这个大坑，那么在2024年2025年你就一定要好好读读这篇前瞻性的论文（或者更应该叫做白皮书才对）！