AI安全扫描在10周内发现17个漏洞

# 10周内AI安全扫描发现17个漏洞 来源：https://lalitm.com/post/perfetto-security-bugs-ai/ 过去几周，我收到Perfetto的trace processor安全漏洞报告的数量远超以往，而这一切都是由AI发现的。对此我感到非常高兴！这些漏洞几乎肯定是一年前不会被发现的，虽然trace processor并非安全关键组件，但堵上这些漏洞的感觉依然很好。 多年来，安全研究人员将时间集中在了最高风险的目标上：内核、密码学库、密码管理器。但大量代码虽然与安全相关，却并非真正的安全关键代码。根据我的经验，这类项目过去很少引起关注。如今，长尾中的系统也能获得从前得不到的关注。 ## 为什么会发生这种情况 Trace processor正是一个处于长尾中的项目。它是一个C++库（是的，如今Rust显然是更好的选择，但重写并不现实，见脚注1 https://lalitm.com/post/perfetto-security-bugs-ai/#fn:1），用于处理各种格式的记录trace。这些trace通常是你自己收集或测试基础架构中收集的，离线处理，因此“不可信输入”并不是什么大问题。 然而，有些人*确实*会处理并非自己收集的trace（例如用户bug报告、来自dogfood用户的自动收集）。对于这些情况，我们强烈建议对trace processor进行沙箱化（例如gvisor https://gvisor.dev/、sandbox2 https://developers.google.com/code-sandboxing/sandbox2 或minijail https://google.github.io/minijail/），或者对于更敏感的使用场景，使用虚拟机。 除了沙箱化，为了主动发现漏洞，我们主要依赖Google内部运行的fuzzing。这些fuzzer偶尔会暴露出真实、可操作的漏洞：我们设置它们传入任意trace字节（因为这是主要的“攻击面”），但随着时间的推移，这类漏洞变得越来越少，因为它们已经发现了大量容易发现的低级问题，我们很快就修复了。剩下的漏洞往往深埋在内部逻辑中，只有通过精心构造的字节序列才能触发，而fuzzer仅靠变异很难命中。 除此之外，几乎没有任何人力或资源，无论是安全专家还是我团队的人，愿意花大量时间在trace processor中寻找安全问题。Perfetto的其他部分（例如tracing服务、设备端profiler）总是更值得投入安全时间，因为它们在实际生产系统中活跃运行。 这一切在几个月前发生了变化。我们开始收到某个中央团队提交的漏洞报告，该团队似乎在Google的各种项目上运行基于AI的安全扫描。不幸的是，我必须对他们的具体做法含糊其辞，因为他们的工作似乎尚未公开。 从四月初开始，我们每周缓慢收到1个漏洞，但从四月底开始，增加到每周几个，有些日子甚至接连打开3到4个。这种情况持续到五月中旬，之后逐渐回落到每周1到2个，有些周甚至没有。 我还要说，这些漏洞的质量很高。它们描述得很清楚，通常已经给出了相关的攻击者模型，甚至还提出了最小的修复方案：基本上是我能从一个bug报告中期望的一切。这与curl（https://daniel.haxx.se/blog/2026/04/22/high-quality-chaos/）和Linux内核（https://www.theregister.com/2026/03/26/greg_kroahhartman_ai_kernel/）维护者所提到的他们收到的安全漏洞情况相符，尤其是过去几个月中质量如何急剧提升。 由于我只能看到提交给我的漏洞，而不是AI扫描器的原始输出，我不知道上游进行了多少分类处理。我猜想有一个人做了一次轻量检查，在报告到达客户端团队之前去除明显的噪音，但根据漏洞打开的速度和提报方式，我怀疑没有人对每个报告进行深入分类。 总共，我们收到了**21**个漏洞（17个真实问题，4个不可操作），可以分为以下几类： - **10个边界检查**：任意trace数据流入固定大小的缓冲区或未检查的数组索引，导致越界读写。 - **5个释放后使用**：反向指针、指针快照或哈希映射键比它们所引用的对象存活更久。 - **1个栈溢出**：当输入深度嵌套时，无限递归。 - **1个访问控制**：在某些罕见的代码路径上没有执行允许列表。 - **4个关闭为不可操作**：要么利用可能性纯粹是假设性的，要么修复需要根本性的设计变更，不值得为了微小的安全风险。 所有17个真实问题都已修复，几乎全部随Perfetto v56.02（https://lalitm.com/post/perfetto-security-bugs-ai/#fn:2）发布。 ## 收到报告的感觉如何 收到这些报告的实际感觉如何？没你想的那么糟。与OpenSSL或curl这类安全关键应用不同，在trace processor中，安全问题极不可能成为我必须放下一切去修复的P0。别误会，它仍然是优先事项，但属于那种我可以用几天时间找出正确答案、按照正常发布时间发布修复的优先事项，而不是急于发布CVE并要求所有人立即打补丁。 另外值得庆幸的是，由于大多数问题是机械性的，修复通常非常直接。以这个PR（https://github.com/google/perfetto/pull/5586）为例： - 在解析一些元数据时，我们将一个键字符串构建到固定大小的栈缓冲区中。 - 边界检查仅在debug构建中运行，而元数据名称直接来自trace。放入足够长的名字会导致缓冲区溢出。 - 修复很简单：将栈缓冲区替换为std::string。该代码路径非常冷（在trace中只出现一两次），因此额外的堆分配无关紧要。 实际上，这类问题是如此机械性，以至于我信任一个编码智能体在最少指导下就能修复：把写得好的报告喂给它，大约10分钟内就能得到一个10-20行的PR修复它。我逐行仔细审查，确保自己理解，但这些任务并不困难，而且明确处于AI能力的“锯齿状前沿”之内。 但我想强调的是，并非每个问题都是机械性的或可以留给AI；少数报告实际上更多指向设计问题而非函数实现错误。这个释放后使用（https://github.com/google/perfetto/pull/5593）就是一个好例子： - 问题是一个状态对象持有一个反向指针，当trace中出现某些数据时，该指针可能最终指向已释放的内存。 - 即时的悬挂情况很容易通过添加一个回调在释放时使反向指针失效来修补。但这是一个糟糕的黑客手段，使得相关对象的生命周期无法推理。 - 这里真正的问题是，你有一个子对象，其父对象可能在它之前消失，如果代码架构正确，这不应该发生。 - 正确修复意味着重构所有权模型，使得生命周期在构造上就是正确的。 有趣的是，这是一个我早已意识到的、已经想清理了将近一年但一直没时间解决的问题：安全漏洞只是给了我推动力和理由去完成它。这种情况也出现在其他几个漏洞中，让我深刻认识到，安全问题有时与更深层次的设计缺陷或粗糙代码相关，因此“安全扫描”的收益比它们直接发现的漏洞更广泛。 ## 这会持续下去吗？ 我担心的是这波漏洞能持续多久；考虑到它只进行了几个月，我对现状感到乐观，但很容易想象，如果再持续几个月，可能会变得精神疲惫。 但我怀疑这最终会归零。为什么？这与这些漏洞的提交模式有关。代码库的每个部分似乎都会得到一两天关注（以及相关的漏洞），然后转移到另一部分。重复很少，而且漏洞的节奏在最近几周尤其放缓了：五月初我们有很多（一周几个），但现在降到了一周1-2个。文件是有限数量的，所以直觉告诉我最终它们会被扫完。 一个重要考虑是，我们添加新漏洞的速度是否会快于扫描器发现旧漏洞的速度。我怀疑不会；迄今为止的17个真实问题是在扫描9年开发成果后发现的。即使这个数字在稳定之前翻三倍，扫描器仍在处理多年积累的代码。而在项目早期我们写了更多更快的代码，现在新代码的添加速度比以前慢了。 另一个问题是，新的模型发布是否会找到更复杂的设计问题，而不是我们现在发现的简单问题。修复这类问题需要更多时间和精力，因此如果收到很多这样的问题，会更加痛苦。对此我非常不确定，所以只能拭目以待！ ## 我们的处境 我觉得Daniel Stenberg（curl维护者）在这篇文章（https://daniel.haxx.se/blog/2026/05/11/mythos-finds-a-curl-vulnerability/）中说得很好： > 任何没有用AI工具扫描源代码的项目，都很可能在新一代工具中发现大量缺陷、漏洞和潜在的安全问题。 这对我来说非常真实。更广泛地说，我认为人们会有三种体验之一： 1. *不可信输入 + 安全关键*（例如curl、内核、OpenSSL）：许多复杂的报告，假阳性率高于其他类别，因为项目受到大量关注，关键代码路径上的低级漏洞可能已经被摘走了。不过，较少使用功能的代码路径（例如旧驱动程序）可能最终属于第二类。 2. *不可信输入 + 之前未审计*（例如trace processor）：一波机械性漏洞，节奏可控，个人压力低，因为项目不在安全关键代码路径上。Daniel和我都认为AI安全扫描器将在这一领域产生最大影响。 3. *无不可信输入*（内部工具、数学库、任何仅操作可信数据的项目）：你可能根本不会注意到这种变化。 我自己的情况完全属于第二类。但我不想过度从我的经验推论，因为有三件事使得这对我是可控的，但对其他人不一定适用：a) 我的全职工作就是维护trace processor；b) 有其他人负责运行AI扫描并首先发现漏洞；c) 报告似乎经过上游人类审查员的轻量过滤，足以去除明显噪音，但可能不是深入分类。 对我来说，这指出了生态系统中的一个缺口：大多数开源项目负担不起一个专门团队来为他们进行安全扫描，而告诉维护者在安全风险边缘时建立自己的管道，将只会让最有动力的项目去做。我猜想我们将在这个领域看到更多创新，包括来自大型AI实验室的。 总的来说，我对自己的经历持谨慎乐观态度：大多数漏洞是机械性的，少数推动了早该进行的设计清理，节奏可控。还有很多我不知道的东西：节奏能否保持，未来的模型是否会开始发现更难的设计问题。所以这应该被视为一个快照，而不是预测！