代码规模下的三大安全漏洞，现有工具覆盖不足

修复的时钟在加速

CISA 的论证直言不讳地指出了问题所在：威胁行为者"对 AI 的使用可能进一步缩短防守者在补丁发布和可能被利用之间的反应时间"。该指令中的补救时间表就遵循这一前提。暴露在公众视野中、被列入已知被利用漏洞（KEV）目录、可自动化且高危的漏洞只有三天的时间。风险组合较低的漏洞有 14 天或 60 天的时间。该指令用风险化漏洞管理模式取代了 BOD 19-02 和 BOD 22-01 中较为平坦的规则。

该指令约束联邦机构，不直接约束你的公司。但它背后的操作假设适用于所有人：从补丁发布到被利用的间隔正在缩小，因此补救速度现在是主要的安全指标，而不是事后的卫生检查。与此同时，你需要补救的代码库增长速度比以往任何时候都快。这两条曲线——缩小的时间窗口和扩张的代码——使得接下来的三个断层点从理论变成了紧迫的现实。

断层点 #1：AI Agent 在没有代码库上下文的情况下生成不安全代码

AI 编码 Agent 生成的代码在安全审查中失败的比率很高，而且生成量很大。Veracode 测试了超过 100 个大语言模型，发现 45% 的 AI 生成代码样本未通过安全测试，并引入了 OWASP Top 10 漏洞。大量的生成使情况更糟：Apiiro 对财富 50 强公司的研究发现，使用 AI 协助的开发人员的提交次数增加了 3 到 4 倍，而他们的团队发现的安全问题增加了 10 倍。

缺陷率并不是最有趣的部分。缺陷的类型才是。Apiiro 测量到权限提升路径增加了 322%，架构设计缺陷增加了 153%。这些不是 linter 能捕捉到的拼写错误。它们是来自不了解你的系统如何组合在一起的缺陷。

这就是上下文问题。从一个代码库片段出发的 Agent 不知道你的组织在 2024 年标准化了加强版认证中间件，不知道它刚才复制的已弃用加密助手之所以存在于你的代码库中，正是因为没有人完成移除它的工作，也不知道它调用的服务假设了一个位于两个代码库之外的验证层。所以它生成了一些看起来合理的东西。看起来合理的代码，如果忽视你的约定，就会让一个不安全的模式在生成速度下变成四十个不安全的模式。

你的安全编码指南不覆盖这一点，因为 Agent 从不阅读它们。你的代码审查流程也不覆盖：同样是 Apiiro 的研究表明，AI 协助的工作出现在更少但非常大的 pull request 中，稀释了审查人员的注意力。依赖于人眼发现的防御措施输给了一台不睡眠的机器。

断层点 #2：信心差距。你无法证明你的检测覆盖范围

这是一个问题，它悄悄地区分了真正的安全姿态和假设的安全姿态：上个月你的组织拥有的代码中，你的扫描仪实际看到的比例是多少？

大多数团队无法回答，诚实的答案通常是"某个人记得连接到 CI 的代码库"。这遗漏了仍在生产中运行的归档服务、最后两次收购带来的代码库、没有人将其分类为"应用程序"的内部工具，以及这些东西拉入的每一个传递依赖。扫描仪的发现描述的是被扫描的代码。它们对未被扫描的代码只字未提，而那正是事件喜欢开始的地方。我们在 Detection in One Repo Isn't a Security Posture 中深入阐述了这个论点：一个代码库中的发现是一个事实，而不是一个姿态。

数量的数学继续使这变得更糟。根据 GitHub 的分析，CVE 项目在 1999 年发布了 321 条记录，在 2023 年发布了超过 28,900 条，十年内增长了 460%。每个披露都会触发同样的问题：我们的哪些代码库包含这个，直接或间接？如果你的答案需要逐个检查代码库，你的覆盖信心是一种感觉，而不是一个数字。

对于 CISO 来说，这是最重要的差距，因为下游的一切都继承了它。优先级框架如 KEV 和 EPSS 只能排列你已有的发现。应用于 60% 的代码库的完美分类流程是一个 60% 的安全计划，只是有很好的文件。

断层点 #3：补救需要数周，因为没有流程能扩展到 10,000 个代码库

标准企业补救流程看起来是这样的：安全团队确定易受攻击的包，向拥有受影响服务的每个团队提交工单，然后等待。每个团队独立地查找升级、解决自己的依赖冲突、打开自己的 pull request、按自己的时间表关闭工单。验证意味着重新扫描并希望扫描覆盖与暴露相匹配（见断层点 #2）。

当"到处"意味着四十个代码库时，这种流程是可以接受的。在数千个代码库的规模下，它产生的单个 CVE 的补救时间表以周为单位，对有多少实例仍然存在没有中央视图。工作并不困难；这是同样的修复应用数百次。不能扩展的是协调：每个团队一张工单，每个代码库一个 PR，按电子表格报告状态。

现在把这与新的时钟对比。CISA 的指令给联邦机构三天的时间来处理最高风险等级的漏洞，并要求机构到 2026 年 12 月 7 日按这种方式运作。联邦命令往往会成为企业期望：通过 FedRAMP 环境、合同语言、董事会问题和网络保险人。当你的 CEO 读到美国政府在 72 小时内补丁其最高风险被积极利用的漏洞时，"我们已经在推出的第三周了"就不再是一个可接受的状态更新。

还有一个更微妙的成本。知道补救需要数周的团队会做出理性但糟糕的决定：他们放弃升级、固定旧版本，并积累正好会把下一个披露变成紧急状况的待办事项。

为什么你当前的工具不覆盖这些差距

这都不是在说你的扫描仪很糟糕。这是在说标准栈中的每个工具都在风险不尊重的边界内运作。

按列读表格，每个工具都赚到了它的预算。按行读表格，三个断层点恰好坐在接缝处：在代码合并之前、在无人扫描的代码库中，以及在检测和完成之间的协调层中。

关闭差距的样子：通用代码搜索加协调变更

所有三个断层点的共同分母是无法将你的代码库当作一个可查询、可更改的表面。解决这个问题的能力很朴素：跨你拥有的每个代码库的通用代码搜索，配合在任何地方一次性对发现结果进行操作的能力。

具体来说，这意味着三件事。完整覆盖：每个代码库，包括存档和收购的代码，都被索引和可搜索，所以覆盖信心是一个查询结果，而不是一个假设。精确答案：给定一个 CVE、一个易受攻击的函数签名或一个风险模式，得到每个发生位置的详尽列表，而不是采样。协调变更：修复被生成、应用并跟踪为来自一个地方的跨每个受影响代码库的 pull request，所以补救状态是一个仪表板，而不是电子表格。

这是我们在 Sourcegraph 构建的层，最清晰的说明是公开的：当 CVE-2025-55182（React2Shell，CVSS 10.0）爆出时，我们记录了用单个搜索在企业代码库中追踪漏洞，然后用批量变更而不是工单队列在每个受影响的代码库中修复和跟踪它。同样的索引回答"这在哪里到处存在？"也给了 AI Agent 断层点 #1 使其饥渴的代码库上下文，你的实际模式和约定，而不是合理的猜测。

准确地说范围：通用代码搜索不替代你的 SAST、SCA 或秘密扫描仪。它们仍然是检测规则。它是它们下面的覆盖和操作层，栈中使"到处"成为真实单词的部分。

你如何在代码库规模上优先考虑漏洞补救？

按影响范围和可利用性一起优先考虑：漏洞涉及多少个代码库、服务和团队，按它是否被积极利用（KEV 状态）和在生产中可达来加权。暴露半径使优先级从严重性分数的辩论变成了一个指标，它需要首先知道漏洞的确切位置。

CISA 的四个风险变量——资产暴露、KEV 状态、利用自动化和技术影响——对于内部 SLA 来说是一个合理的起始指南，CISA 的 SSVC 决策模型形式化了相同的逻辑。代码库规模下的区别是分析单位：你不是在分类一个代码库中的发现，你是在分类一个有足迹的模式。

三个断层点是一个问题穿着三套衣服。AI Agent 生成不安全代码因为它们看不到整个代码库。检测覆盖无法被证明因为没有人能看到整个代码库。补救需要数周因为没有什么能对整个代码库采取行动。我们在应用安全姿态讲解器中写过实践中修复根本问题意味着什么。要想对跨代码库安全可见性有更深入的、厂商中立的了解，请阅读 The codebase visibility and security framework。

什么是漏洞补救？

漏洞补救是通过补丁、升级依赖、更改代码或移除易受攻击的组件来永久消除已识别的安全缺陷，然后验证修复的过程。它不同于缓解，缓解通过补偿控制降低可利用性，而不移除根本缺陷。

漏洞补救和缓解有什么区别？

补救移除根本原因：修复后易受攻击的代码或组件就消失了。缓解阻止利用路径而缺陷仍然存在，使用诸如 WAF 规则或网络隔离之类的控制。缓解争取时间；补救结束暴露。成熟的计划两者都用，按那个偏好顺序。

你如何自动化漏洞补救？

从一个完整的、可查询的每个代码库的索引开始，这样受影响的代码就能被详尽地定位。生成一次修复，然后从单个工作流将其应用为跨所有受影响代码库的跟踪 pull request，进行中央监控合并状态。重新运行原始查询以验证零个剩余实例。

CISA BOD 26-04 要求什么？

BOD 26-04，2026 年 6 月 10 日发布，要求联邦机构按风险化时间表补救漏洞：对于公开暴露、已知被利用、可自动化且高危的缺陷，快则三天（加上取证分类）。机构必须到 2026 年 12 月 7 日实施新的流程。它取代了 BOD 19-02 和 BOD 22-01。

解除你组织的阻碍。更快地发货。

使用 Sourcegraph，企业的代码理解平台。