一个IAM权限漏洞从被发现到修复，平均需要14天。而真正的攻击，往往就发生在这14天里。
这不是效率问题，是架构问题。当成本优化已经实现"检测-自动修复"的闭环时，安全团队却还在用"检测-建工单-排队"的人肉模式。为什么同样的技术逻辑，在安全领域走得这么慢？
人物动作：谁在推动这场变革
云安全厂商Lacework在2023年的威胁报告中首次量化了这个痛点。他们的数据来自真实的企业环境：一个IAM主体被标记为拥有通配符S3权限后，从CSPM控制台弹出告警，到工程师真正动手修改策略，中间隔着整整两周。
这两周里发生了什么？告警进入队列、工程师创建工单、工单进入安全待办池、等待下一个冲刺周期、工程师切换上下文、登录控制台、阅读上下文、最后——四分钟的策略编辑。
政策编辑本身只需四分钟。十四天的暴露时间，全部消耗在队列深度、冲刺边界和上下文切换上。
这个发现催生了一个新的技术框架：DERA循环（检测-评估-修复-审计）。提出者试图回答一个具体问题：如果成本优化可以无人值守，安全为什么不能？
背后逻辑：评估门为什么是生死线
成本自动化的评估很简单：实例连续7天空闲？关机。安全自动化的评估要回答更难的问题。
这个IAM主体当前是否在活跃使用？有没有未完成的会话？是否在豁免清单上？如果修错了，能否回滚？
这些问题的答案决定了自动化是"修复漏洞"还是"制造事故"。没有评估门，系统同时扮演消防员和纵火犯。有了评估门，确定安全的案例进入自动通道，边缘案例进入极短的人工复核队列。
结果是什么？工单队列减少90%。不是通过让工程师更快，而是通过让机器处理机器能确定的事。
审计侧的成本同样被重构。SOC 2审计员要求"及时修复"的证据时，旧模式出示的是"周一创建工单，次周周五解决"——这个时间线无法被认定为有效内控。自动化修复生成的是带时间戳的审计记录，修复发生在检测后的分钟级而非天级。
行业影响：信任模型的根本转移
检测-工单模式的核心假设是"信任人类会在合理时间内响应"。这个假设在10个服务时成立，在100个服务×40个活跃IAM主体时崩溃。
人力审查的瓶颈无法与发现量同步增长。这不是工程师的问题，是架构的问题。
DERA循环的引入标志着信任对象的转移：从"信任人类会及时处理"转向"信任机器能正确评估"。评估门的存在让这个转移变得可接受——机器不直接行动，而是先通过多维度检查获得"确定性安全"的授权。
这个转移正在扩散。成本优化领域的闭环架构已成标配，安全领域的同类实践仍处于早期探索。两者的技术结构相同，差异只在评估逻辑的复杂度。
当评估能力追上，安全自动化的普及只是时间问题。而评估能力正在快速进化：会话状态检测、豁免清单管理、回滚机制设计——这些组件的成熟度决定了多少场景可以被"确定性安全"覆盖。
覆盖率的每一次提升，都意味着攻击窗口的同步压缩。14天到分钟级的跨越，不是渐进优化，是范式更替。
开放提问
当机器能够评估"什么可以自动修复"，人类的安全角色会转向哪里？是设计更精细的评估规则，还是处理机器无法归类的边缘案例？或者，评估权本身是否会成为新的权力中心——谁定义"确定性安全"，谁就控制了自动化的边界？
热门跟贴