2026-10-22 每日思考

今天最扎我的一条不是哪个模型发布，而是 AWS 说他们的蜜网在 PHP2Shell 公开披露之前就抓到了在野利用。做安全检测工具的人看到这句话，应该会先愣一下。

我最近在做的 AI 代码审查工具还在 MVP 阶段，主要盯安全漏洞和性能问题。这个项目做得越久，我越确信一件事：代码审查的价值不在"发现问题"，而在"发现问题的时间点"。一个 SQL 注入，在 PR 阶段被拦下和在线上被利用之后被复盘出来，是同一条 finding、完全不同的两个产品。所以当我看到"披露前已在野利用"时，我第一反应是——我的工具默认假设错了。我一直隐含地假设"漏洞是新的、攻击是滞后的"，但现实是攻击方可能比公开情报跑得更早，那我给出的"高危"标签，可能只是把一个已经在被利用的东西重新描述了一遍。

这背后有个更硬的技术逻辑：AI 代码审查的检测能力，本质取决于它能拿到的上下文。静态分析能看到的只是代码本身，而"这个依赖版本是否已被在野利用""这段逻辑是否匹配某个已知攻击模式"属于外部情报，模型的参数里没有、训练数据里也滞后。所以纯模型驱动的审查工具，天花板不在推理能力，而在情报的时效性。这也是为什么我最近在考虑把漏洞情报源（CVE、在野利用观测、蜜网数据）作为一等公民接进流水线，而不是让模型"凭知识"判断。模型负责理解代码语义和攻击面，情报负责回答"现在危不危险"，两者缺一不可。

第二个让我警惕的是 ego-lite 那类"把登录态共享给 Agent"的工具。它单日近 400 星，说明需求真实——大家确实想让 Agent 替自己操作网页。但会话凭证的共享，等于把"身份"交给了不可完全审计的执行体。我在自己的审查工具里也遇到过类似张力：为了让 Agent 能跑测试、能读配置，就得给它更多权限；权限一多，审查工具本身就成了攻击面。这个矛盾没有漂亮解法，只能靠最小权限和可回滚设计硬扛。

给同行的建议很具体：如果你在做任何 AI 辅助的安全或代码质量工具，先把"情报时效"当成和"模型能力"同等重要的工程问题，别把在野利用数据留到 v2。预测一句：未来一年，"Agent 权限审计"会独立成一个品类，因为现在大家都在给 Agent 放权，还没人认真收权。