闭源挡不住AI找漏洞，真正的护城河是先审计
一家高速成长的科技公司把代码库转为闭源，理由是要防住用AI搜刮漏洞的攻击者，但它看错了变量。真正的风险，从来不在于谁能读到源码，而在于那些从未被审计过的代码。而这套推理逻辑，才是接下来最可能被复制的部分。
在大多数软件资产背后，都藏着一个从未被质疑的假设：只要还没出过事，代码就是安全的。过去十年里的两次示范，足以推翻这个假设。2016年，DARPA网络超级挑战赛（Cyber Grand Challenge）让七套全自主系统同台竞技，在完全没有源码、也没有人工介入的情况下，在编译好的二进制文件里找出漏洞、验证并自动修补。八年之后，2024年11月，谷歌的Big Sleep智能体在SQLite中发现了一个此前未知、可被利用的内存安全漏洞，研究人员称这是AI智能体在真实软件中发现的首例此类漏洞。这两个结果都不是“即将发生”的预告，而是已经发生的事实。
接下来要说的属于预判，我会明确标注出来。把这种能力用在那些从未被审计过的老旧代码上，成本正在迅速趋近于零。老旧的Web应用、无法再打补丁的路由器、物联网固件、工业控制器，甚至芯片微代码：这些系统之所以多年未被触碰，只是因为此前没人有理由去查。现在，“去查”这件事正在变得极其廉价，十年积累下来、从未被检视的风险，很可能在数天而非数年内，被一个动机明确的攻击者逐一攻破。
面对这种局面，一种可以理解、但方向错误的本能反应，是把“开放”本身重新定义为危险。这套逻辑是这样推演的：既然攻击者可以让模型扫描每一个公开代码库、批量收割漏洞，那么可见性本身就是攻击面，索性把门关上。协作平台Cal.com正是这么做的，将其商业代码库转为闭源，其首席执行官的理由是AI攻击者正在利用源码的透明性发起攻击。就目前而言，这更像是个案，而非行业趋势。这种焦虑不难理解，但真正值得警惕的是这套推理本身，因为接下来会被其他企业复制的，是这套逻辑，而不是这一家公司的具体决定。
闭源能防住AI攻击者吗？
先看机制本身。攻击者需要的是可探测的行为，而源码只是理解这种行为最快的一条路径，不是唯一路径。闭源的二进制文件可以反编译；固件镜像可以拆解、仿真；模糊测试工具（fuzzer）可以对一个正在运行的服务丢入成千上万个畸形输入，记录下哪里崩溃，全程不需要看到一行源码。漏洞研究这门手艺，比开源本身还要古老，几十年来一直在对着闭源系统“盲打”。AI真正改变的，是这门老手艺的覆盖半径，而这个半径正好精准地伸向了二进制文件和固件，而不仅仅是公开代码库。
不妨先承认闭源论里诚实的那一部分，因为它确实成立：隐蔽性确实能在边际上抬高攻击成本。读源码永远比用反编译器重建逻辑、或者从一堆模糊测试的崩溃日志里推断逻辑要快、要干净，所以对于一个身份验证绕过漏洞或者一个注入路径而言，拿掉源码确实能换来一段真实的时间窗口。但这笔交易有两处硬伤：一是这段时间溢价正在持续收窄，因为模型对二进制和固件的分析能力还在变强，这正是2016年DARPA网络超级挑战赛就已经划出的前沿，当年的冠军系统面对的就是完全没有源码的编译二进制文件；二是，为了换这段时间，你同时也把可能先一步找到漏洞的善意研究者一并挡在了门外，而这段用真金白银买来的延迟，恰恰是一个本就久未打补丁的技术资产最不缺的东西。
所以，转向闭源，只是拿掉了攻击者的一点便利，却放弃了防守方真正拥有的东西：众目睽睽之下的审视。开放的代码就是可被审计的代码，一旦审计者可以是大规模运行的模型，可读源码对防守方的价值只会上升，不会下降。这笔交易，收窄的是一项本就在缩水的风险溢价，放大的是一项持续在扩大的暴露面。
眼下所有人都在争论的那个变量，也就是“能不能被看到”，根本就不是暴露面本身。真正的暴露面，是这些代码从一开始就从未被审计过。一个塞满了未被检视漏洞的私有代码库，和公开代码库几乎一样危险，唯一的区别只在于，善意的研究者是否有机会抢在恶意攻击者之前碰到那个漏洞。
能力是对称的，唯一的优势是速度
这才是让人不舒服的地方。AI辅助的漏洞发现，不认阵营。帮你在依赖树里揪出漏洞的那套模型，同样可以被率先动手的任何一方拿去用，于是整个战略局面收缩成一个变量：时间。真正持久的优势，属于第一个对某套系统完成审计的人，因为第一次称职的扫描，会把一个未知风险，变成一个补丁，或者一个漏洞利用，具体变成哪一个，取决于按下回车键的人是谁。
正因如此，拖延才是最昂贵的选择。把对抗性AI审计当成“下个财年再排期”的事项，等于默认对手和你用的是同一张时间表，而事实并非如此。真正可行的姿势，是现在就对自己的代码、依赖项和联网设备运行审计，前提假设是：就算今天没有人这么做，迟早会有人这么做。我们在帮助客户把这种由人监督的保障机制，内置到智能体系统的设计与运行方式之中，因为真正起防守作用的是审计本身，任何关于源码开放与否的政策，都替代不了它。
如果没办法审计所有资产，该怎么办？
“先审计”这个前提，假设你有能力审计全部资产，但很多组织做不到。如果你手上压着400个再也不会重新构建的固件镜像，或者一整支供应商早已消失的设备，一场由时间决定胜负的比赛，你在某些战线上还没起跑就已经输了，假装不是这样，正是安全表演能骗到预算的原因。
那就诚实地分级。按“可达性乘以爆炸半径”排序，而不是按哪个系统让你最不舒服排序。任何面向互联网的系统，或者离身份验证只有一步之遥的系统，都排到队首，因为攻击者的扫描同样会最先打到这里。对于剩下那些确实无法打补丁的资产，别再假设打补丁是唯一的控制手段：把它们隔离到无法触达互联网或核心资产的网段里，过滤它们的出站流量，并对它们做好监控埋点，这样，一个你没办法阻止的漏洞利用，至少是一个你看得见的漏洞利用。这些比赛里你注定会输掉一部分，所以该把预算花在检测和响应上，让它来决定一场败局到底要付出多大代价。能抢先审计的地方，审计是完胜的选项；抢不到的地方，遏制和监控扛起分量，而一句诚实的“我们审计不了这个”，应该触发一项补偿性控制措施，而不是一句耸肩带过。
厂商的通稿数字，为什么不能直接拿来定价
以上这些，都不意味着要把营销话术照单全收。如今不少厂商在宣传自家安全调优模型发现了多少个“根本性”漏洞，而这些总数大多接近无法核实。Anthropic在谈及其模型宣称的发现时，也只能披露其中一小部分，因为大多数漏洞当时仍未被修补，这让外部独立核实变得相当困难。一个吸睛的总数字，说明不了这项工作里有多少是模型完成的、多少是人工分析师在背后操盘完成的，也说明不了这些漏洞是否真实、是否新颖、是否真正可被利用。真正该问的问题，是要方法论、要一份可复现的发现样本、要证据证明是模型而不是分析师完成了发现。照着通稿定价，买到的只是一个故事，这条提醒适用于今年出现的每一份安全AI推销方案。
技术资产的真实面貌
大规模的严重漏洞披露，不会均匀地落在每个角落。它会集中在那些没人愿意碰的系统里：2014年出厂、永远不会再更新的设备固件，作者已经离职、公司都重组了三轮的内部服务，埋在依赖清单第六层深处的某个组件。在同一轮成本紧缩里被裁薄的工程团队，恰恰继承了这些被裁员遗弃的系统，审计缺口在扩大，能补上缺口的人手却在变少。
这个问题本身并不新，变化的只是价格。潜藏的漏洞，一直都会安静地躺上好些年，直到某个研究者把它变成一件可操作的事，就像丹·卡明斯基（Dan Kaminsky）把早已为人所知的DNS缓存投毒弱点，一次性变成了一种在众多实现里都可实操的攻击。AI对这套发现流程做的事情，和流水线对制造业做的事情一模一样：把它工业化。
抛开“开源还是闭源”这场辩论，该做的事其实很直白。先把自己在用的一切都盘点清楚，包括那些从未被读过的固件和依赖项。然后，在人工监督之下，把攻击者会用的同一类工具，对准自己的资产，抢在别人之前修好它找出来的问题。开源闭源之争，是一个你可以慢慢讨论的政策问题；审计，才是决定你还能不能站着的那部分。现在就把它写进你的技术战略里，趁着“自己先找到漏洞”这件事，还是一项真实存在的优势。
常见问题
现在AI都能扫描代码了，开源是不是反而比闭源更不安全？
不一定。攻击者依然可以通过反编译、模糊测试和仿真，从闭源的二进制文件和固件里提取漏洞，所以隐藏源码只是抬高了攻击者的成本、买来一段时间窗口，并没有消除暴露面。真正的暴露面是未被审计的代码，而开源至少让这些代码能被防守方的工具和研究者读到，他们也许能抢先一步碰到那个漏洞。
该怎么开始对自己的系统做AI代码安全审计？
先从盘点开始，把依赖项和联网设备上的固件都纳入进来，因为未被触碰的漏洞往往就藏在这些地方。然后在人工监督下，对自己的资产运行对抗性漏洞发现，优先处理面向互联网和贴近身份验证的系统，任何发现都应该在被别处披露之前修补掉。对于确实无法打补丁的系统，改用隔离和监控来兜底。
厂商宣称自家安全模型发现了多少漏洞，这个数字能信吗？
不能只看这个总数字。很多这类总数都无法核实，也说不清究竟是模型的功劳，还是背后分析师引导的结果。在为这项能力定价之前，应该要求对方提供可复现的方法论、一份实际发现样本，以及证明确实是模型完成了发现的证据。
相关阅读
- 主权溢价：企业争的不是更快的AI，而是不会被随时掐断的准入权
- 华盛顿把自家AI实验室列入风险名单："供应商锁定"从此不再只是价格问题
- 企业AI试点为何难以规模化：卡住项目的不是能力，是信任
- Security & Trust
本文由 Abyshire 专有编辑系统的 AI 编辑角色撰写，并经我们的团队审核。