当攻击快于组织响应：Ami谈AI时代的持续安全检验与防御重建

一、嘉宾背景

所提供的元数据将本期播客标为a16z /《The Ben & Marc Show》，时长为2766秒，约46分钟。受访者在材料中被称为Ami，嘉宾背景未提供可确认的姓氏、正式职务或所属机构。他在节目中谈及的具体工作，比未经确认的身份信息更能说明其判断从何而来。

Ami介绍了团队的漏洞研究、名为Atlas的漏洞检测框架，以及持续尝试不同模型的过程。他也讨论了Wiz安全产品的调查与处置能力，并引用客户环境中的PHP使用情况和补丁进度。这些内容表明，他从漏洞研究、产品工程和客户防御实践出发讨论安全问题，也解释了他为何反复关注模型费用、修复链条和实际攻击入口。它们仍不足以确认他的完整履历。

访谈围绕AI能力提升后，企业安全工作应如何重新组织展开。攻击者寻找和利用漏洞的速度只是其中一部分；防守方能否取得补丁、找到资源负责人、验证修改并完成部署，同样决定风险会持续多久。Ami的客户观察与产品实践提供了具体问题，但不能自动代表整个行业。讨论的价值，在于把攻击能力变化落实到这些可以检查、也可能受阻的工作环节上。

二、本期主要内容

Ami用“黑色十月”概括他观察到的一次异常汇合：漏洞发现与AI辅助攻击同时加速，一些此前被视为未来可能性的能力开始用于实际攻击。他声称，部分过去需要顶尖攻击者数周甚至数月才能完成的攻击，如今约二十分钟就能完成。这个数字反映的是他的观察；节目没有交代统一的计时起止点、样本选择或测量方法，不能据此认定所有网络攻击都已达到同样的速度。

AI开发平台是他用来说明攻击动机的例子。据Ami介绍，团队博客记录的十月遇袭平台从九家增加到十五家，他将这些平台成为目标归因于它们持有AI密钥。他描述的创业公司处境是：团队发现夜间异常时，攻击者可能已经取走秘密信息和客户密钥。吸引攻击者的关键，在于系统中是否存有可以直接利用的资源。不过，节目没有列出完整名单或比较样本，这一观察的范围仍限于他谈及的平台。

PHP案例呈现了防守端的另一种速度。Ami称，几乎所有客户都在某处运行PHP，最初两三天的修补比例达到约百分之五十。这个比例的分母并不明确，不能直接理解为全部受影响资产已有一半恢复安全。他同时指出，部分旧版本没有补丁。能够迅速修复一部分系统，并不意味着剩余系统的暴露也能随之消除。

补丁供应链还可能让企业在采取行动之前就陷入等待。Ami说，团队曾为PHP问题协调数月，但相关信息在准备完成前提前泄露；Linux内核修复传递到各发行版，也可能需要数周至数月。漏洞发现、攻击利用、可用补丁发布和实际部署，各有不同的进度。即使企业内部工单处理迅速，也无法消除上游尚未交付修复所留下的空窗。

客户的要求则在推动安全产品承担更多后续工作。Ami说，客户越来越希望产品不仅对漏洞排序，还能定位受影响代码、生成修复和拉取请求；不仅发出告警，还能完成调查、取证、根因解释和攻击者清除。这些要求都指向减少发现问题之后仍需人工衔接的步骤。Ami认为自动响应是必须考虑的方向，同时明确称它令人担忧。节目没有展开误判控制、操作授权与恢复机制，因此不能把这一方向当作无人值守处置已经成熟的证明。

三、核心观点：推理、例子与边界

Ami的一个核心判断是，安全结论会随攻击能力的变化而失效。应用即使没有改动，新模型也可能找出此前未被发现的攻击路径。他用门垫下藏钥匙作比喻：防守者认为足够隐蔽的位置，可能随着对手能力提升而暴露。持续测试因此不只是增加扫描频率，还要重新检验过去的安全判断所依赖的假设。昨天没有找到入口，不能成为今天无需复查的理由。

前沿模型的领先也只能提供有限的机会。Ami估计，在漏洞发现任务上，前沿模型相对开放模型的优势可能不超过三个月，并主张利用这段时间优先检查关键基础设施。这不是对所有模型能力差距的统一估计，也不意味着防守方拥有三个月的安全期。他同时承认，全球代码太多，防守者不可能全部检查。即便拥有更强的模型，也仍可能由攻击者先在尚未检查的代码中找到问题。

检查顺序因而比“全部扫描”的笼统要求更重要。Ami描述的红队流程先做确定性的暴露分析，检查互联网可达且无需认证的入口，再深入开展渗透测试和代码分析。普通端点可能投入几分钟，关键应用则可能投入十小时。这些时长是资源分配的示例，并非服务保证：调查应当深入到什么程度，取决于入口的可达性和系统的重要性，不宜平均用力。

他提到的移动应用案例说明了这种排序的意义：应用中硬编码的密钥导致了用户数据暴露，攻击路径并不依赖复杂漏洞。攻击能力提升，并不会降低简单错误的危害；可以直接取得的凭据，仍可能成为重要入口。不过，这个案例也不足以说明代码分析不重要。在他描述的分层流程中，外部检查用于发现实际可利用的路径，代码分析则帮助理解并消除问题。

持续检验还意味着持续分配计算资源。Ami指出，不同模型家族、版本及网络安全专用变体，在能力、速度和成本上各有差异，需要不断评估，并按任务组合使用。他描述的Blue Agent流程先进行确定性检测，再使用成本较低的模型，逐步升级到更强的模型，避免每个事件都调用最昂贵的模型。这种安排把昂贵的推理留给需要深入确认的事件。但节目没有提供测试结果，说明前序环节是否会漏掉本应升级处理的问题；成本上的合理性仍需由检测效果验证。

扫描费用让“持续”二字面临更具体的约束。Ami举出五百万美元的代码扫描例子，并称部分客户在扫描上花费数千万美元，而新模型和新代码还会带来重新检查的需求。这些数字来自他的举例和支出陈述，节目没有提供账单或收益对照。他也明确承认，如何在外部探测、内部分析、磁盘与运行时观察之间有效分配预算，仍未解决。持续检验因此不能简单等同于每次模型更新后，都重新执行最昂贵的全量扫描。

预算之外，防御还取决于系统如何设计。Ami强调沙箱、隔离，以及网络、进程和镜像层面的限制，要求设计者预先考虑漏洞出现后的后果。他批评安全工作在报告和配置检查上耗费过多时间，主张把注意力放在实际攻击路径、关键风险、缓解措施、检测、响应准备和长期隔离上。这一批评指向工作能否降低风险，并不足以支持取消所有合规工作。同样，他对容器逃逸的强烈表述，也不能据此推成任何容器都必然可被突破的结论。

节目中的威胁预测则需要单独看待。访谈者预测，大量无需认证即可利用的远程漏洞可能再次出现，甚至可能出现互联网蠕虫；Ami则断言，AI攻击已经超过人类能力。但讨论没有提供系统性的能力比较，也无法确定未来事件的频率。这些判断支持重新检视依赖一次扫描、单一模型或采购工具的防御方式，尚不足以确定攻击能力最终会增长到什么程度。

四、学习与应用

Ami对新公司的建议，是从一开始就为自动修补设计完整流程，贯通工单接收、开发、测试、CI/CD和运维。落实这一建议，可以先选择一个责任清楚、能够测试的服务，逐一检查发现问题之后，每个环节是否都有明确的输入、负责人和完成条件。生成补丁只是中间步骤；修改经过验证并部署到系统中，才能缩短暴露时间。这种做法更适合仍有机会设计开发流程的新团队，不能据此假定所有旧系统都能立即实现自动修复。

遗留企业面临的障碍，往往先在上下文和责任归属上。Ami提到大量旧软件、数千名开发者、资源归属不清，以及未被记录的组织知识。由此推导出的准备工作，是先明确受影响资源由谁管理、如何测试、谁决定上线、出现问题时由谁处理。这些是根据其诊断整理出的实施步骤，并非节目提供的现成部署规范。前期梳理可能缓慢，但能减少代理执行时缺乏判断依据、结果无人接手的断点。

对于暂时无法修复的问题，红蓝协同可以提供过渡办法。Ami描述，Red Agent从外部测试应用，同时利用内部上下文；工程团队若无法立即修复，相关发现可以用于完善Blue Agent的检测。实际采用时，可为同一问题同时保留修复任务、检测方案和责任人，避免把“已有告警”误认为“问题已消失”。检测只能提供发现异常的机会，能否及时处置仍取决于后续流程；缺少可执行的响应，红蓝协同也可能只是增加待处理信息。

针对LLM-jacking攻击，Ami建议为AI密钥设置使用限额，以约束密钥被盗后的费用损失。限额需要结合正常业务需求设定：过低可能影响合法使用，过高则会留下较大的滥用空间。它约束的是攻击者取得密钥后可能产生的费用，无法阻止入侵，也不能消除已经发生的数据泄露。

系统是否必须直接面向互联网，也需要重新审视。Ami主张，尚未做好防御准备的系统应退出公网。落实到具体决策，需要确认外部访问的业务必要性、哪些入口可以收窄，以及限制访问会怎样影响使用者。隔离与下线可以减少外部可达性，也可能增加运维和服务交付负担，因此需要逐个系统判断，不能将这一主张直接变成不加区分的全面断网。

讨论延伸到联网的物理基础设施时，发现问题与解决问题之间的距离更加明显。Ami介绍，Scan for Good通过扫描帮助公共服务机构发现问题，并鼓励它们持续开展红队扫描，同时承认这无法解决它们的全部困难。对资源有限的机构，一次扫描可以帮助确定下一步，但仍需有人理解发现、组织修复并维持后续检查。评估这类安全服务时，需要明确发现由谁接手、暂时无法修复时如何降低风险，以及哪些工作仍需机构自身承担。扩大扫描覆盖，不能替代这些执行条件。

来源

• 原始节目：Cyberattacks Used to Take Months. AI Can Do It in Minutes.