Mythos时代:安全防线必须前移至运行时
安全历史上,防御者曾依赖时间差——漏洞披露到武器化利用平均需两年半,但到2026年已缩短至数小时,前沿模型Mythos是主因。这带来双重挑战:未知攻击(零日漏洞无CVE可查)与已知漏洞洪流(报告泛滥导致优先级混乱)。静态代码扫描无法解决任一问题,唯有基于运行时执行的监测,实时观察代码与智能体的行为,才能在不依赖CVE的情况下阻断未知威胁,并过滤出真正可利用的漏洞,使优先级排序从猜测变为精准。

在安全行业的大部分历史中,防御者曾因时间而受益。漏洞被披露,补丁随之发布,而攻击者需要数月甚至数年才能构建出可靠的利用程序。这一时间差正是整个“扫描-修补”模式赖以存在的基础。
然而,这一缓冲已不复存在。根据“零日时钟”(Zero Day Clock)的数据,从漏洞发现到武器化利用的平均时间已从2018年的大约两年半骤降至2026年的数小时,而前沿模型(如Mythos)正是这一变化的推手。同一套系统既能发现你代码中的缺陷,也能编写出针对该缺陷的有效利用程序,并且两者都能以机器速度完成。

这同时引发了两个方向相反的问题。
第一个问题是“未知攻击”。前沿模型能够在你应用程序、AI智能体、它们调用的工具或其依赖中发现零日漏洞,且没有CVE编号或补丁可供参考。当攻击目标是一个持有API密钥、数据库访问权限并能执行代码的智能体时,从发现到入侵的时间差将缩短至数秒。由于漏洞从未被编目,扫描无从谈起。
第二个问题是“已知漏洞洪流”。同样的能力在发现新漏洞的同时,也会生成数以千计的漏洞报告。原本已难以管理的积压任务如今更是雪上加霜。团队只能凭直觉而非风险优先级进行修补,而花在那些在生产环境中永远无法触达的漏洞上的每一小时,都是从真正可利用漏洞上挪走的时间。
请注意,这两个问题都无法通过检查静态代码来解决。扫描器无法标记尚不存在的零日漏洞,也无法判断某个已知CVE在你的运行系统中是否真正可达,因此它只能标记所有内容并称之为尽职调查。两种情形下的盲区相同:检查工件而非行为的工具,根本不了解你的软件在运行时实际做了什么。
这就是为什么在后Mythos时代,唯一有效的防御方法是基于执行的监测。与其询问代码可能存在什么问题,不如观察代码和智能体在运行时、实时中实际执行的操作——每一次提示、每一次工具调用、每一个API请求、每一次库调用、每一个被访问的资源。
观察执行过程无需CVE即可解决未知问题,同时也能缓解已知漏洞洪流。首先,你可以像阻止零日漏洞一样阻止不当行为,从而为修复争取时间。其次,一旦你能看到哪些函数实际运行且可达,就能将环境中真正可利用的漏洞与仅存在于纸面上的数千个漏洞区分开来。不可达的CVE曾耗费大量管理成本,但采用这种方法,其实际成本为零;而可达的漏洞则获得你的关注。优先级排序不再靠猜测。

过去,“预防”意味着在恶意事物运行之前将其拒之门外。但在攻击按需生成、速度超过任何人类响应的世界里,“预防”必须意味着在行为发生时识别并阻止它。控制点从边界和流水线移至运行时。
时间线不会倒退。唯一能跟上前沿模型速度的防御,是存在于模型利用程序最终必须运行之处的防御。