OpenAI 昨天说“防守窗口正在收窄”：真正该紧张的不是零日，而是仓库里那堆没人管的旧东西
昨天 OpenAI 发了一篇安全文章，标题叫《The Defender’s Window》。
里面有个细节很容易让人记住。
Greg Brockman 让 ChatGPT Work 用公开可用的 GPT-5.6 Sol 检查自己的个人网站。这个网站并不复杂：静态站点，AWS 托管，Cloudflare 在前面。
大约 15 分钟，模型找出了 13 个问题。
官方文章举出的例子并不是什么电影里那种“超级黑客漏洞”，而是很普通的安全债：邮件域配置不完整、前端依赖过旧、Cloudflare 到源站的一段链路仍然使用了不安全配置等。
后面模型又花了大约一个小时协助修复和调整这些配置。
我觉得这件事最值得关注的地方不是“AI 会不会黑客”。
而是：
以前因为人工时间不够而长期没人检查的那批低优先级问题，正在变得越来越容易被机器批量发现。
这会改变安全工作的优先级。
过去很多团队心里其实有一张默认风险表：
高危零日 立即处理
严重漏洞 尽快处理
旧依赖 有空再说
过度权限 等重构
DNS/邮件配置 以后再补
废弃服务 暂时别动
测试环境暴露 应该没事
这个排序有一个隐含前提：
攻击者的时间也是有限的
一个不显眼的小配置错误，如果单独利用价值不大，攻击者可能懒得看。
AI Agent 改变的恰恰是这个成本结构。
如果机器能够自动：
枚举
比对
检查配置
阅读代码
关联资产
发现异常
那么以前“不值得人工花时间找”的问题，会突然变得值得批量寻找。
这就是我理解的 Defender’s Window。
我会先还哪几类技术债
不是先买一套新的 AI Security 产品。
我会先清下面五类东西。
1. 身份和权限
这是我会排第一的。
检查：
- 离职账号；
- 长期不使用账号；
- 管理员权限；
- Service Account；
- API Key；
- 云 IAM；
- 数据库高权限用户；
- CI/CD 凭证；
- 第三方集成 Token。
很多严重事件最后并不是靠“神奇漏洞”完成，而是：
拿到一个本来就权限过大的身份
所以最值得问的不是：
这个账号会不会被盗？
而是：
如果它今天真的被盗，能做多大范围的事？
权限应该按 blast radius 设计。
2. 长期没人升级的依赖
依赖治理最怕这种状态：
能跑
所以不敢动
几年以后变成：
因为太老
更不敢动
我会至少维护：
组件
当前版本
最新安全版本
是否公网暴露
是否有已知漏洞
Owner
升级窗口
不需要第一天全部升级。
先让“没人知道它存在”变成“有人负责”。
3. 被遗忘的公网资产
最危险的系统有时候不是主站，而是：
old-admin.example.com
staging.example.com
test-api.example.com
legacy-vpn.example.com
没人维护，但 DNS 还在。
证书还在。
端口还开着。
甚至账号还是几年前的。
先做资产盘点：
Domain
Subdomain
Public IP
Cloud Account
Public Bucket
Load Balancer
VPN
Remote Access
资产不知道，就谈不上防守。
4. 网络和信任边界
很多内部系统默认：
能进内网 = 可信
这个假设越来越危险。
一旦某个账户、终端或服务失陷，过于平坦的内网会放大影响。
优先检查：
- 管理平面是否隔离；
- 生产数据库是否允许任意应用访问；
- CI Worker 能否访问生产；
- 测试环境能否访问真实数据；
- 服务之间是否使用独立身份；
- 网络策略是否按最小范围开放。
5. “一直知道，但一直没修”的配置
这一类非常真实。
例如：
这个Header以后补
这个Bucket反正没人知道
这个账号先共用一下
这套老TLS改起来麻烦
这个Secret后面再换
以前可以拖半年。
现在我会重新评估。
因为 AI 带来的不是单个漏洞威力突然变大，而是：
寻找、组合和验证问题的成本下降
OpenAI 文章里有一句话我觉得比“AI攻击”更重要
它强调的方向并不是只让 AI 生成更多 Security Findings。
目标应该是缩短：
发现问题
→确认问题
→生成修复
→验证修复
→安全发布
这条链路。
这点非常重要。
很多安全平台已经有一个老问题：
扫描器每天报 3 万个问题
最后真正修的很少。
如果 AI 只是让 3 万变成 30 万，防守反而更差。
所以我会把 AI 安全 Agent 的 KPI 定成：
有效修复数
而不是：
发现数
一个安全 Agent 最好不要拥有“无限修复权”
可以分三档。
自动修
适合：
- 明确依赖版本更新；
- 格式化安全配置；
- 静态检查可验证问题；
- 测试覆盖充分的低风险代码。
流程：
发现
→开PR
→CI
→自动合并/人工合并
提议修
适合：
- IAM；
- 网络；
- 数据库；
- 认证；
- 基础设施。
Agent 生成：
Change Proposal
Diff
Risk
Rollback Plan
人审批。
只报告
适合：
- 高影响生产系统；
- 可能造成业务中断；
- 证据不充分；
- 涉及合规。
不要为了“自治”强行自动化。
我更喜欢“安全不变量”这个概念
与其每天问：
有没有漏洞？
不如定义一组系统必须始终成立的条件。
例如：
生产数据库不能直接公网访问
CI Worker不能拥有生产管理员权限
任何长期API Key必须有Owner
所有生产Secret必须有到期或轮换策略
测试环境不能读取真实用户全量数据
关键写操作必须有审计
然后持续验证这些不变量。
security_invariants:
- id: prod-db-no-public-access
severity: critical
- id: service-account-no-admin
severity: high
- id: secrets-have-owner
severity: medium
AI 很适合帮助：
- 找证据；
- 读配置；
- 解释差异；
- 生成修复建议。
最终是否满足不变量，最好仍由确定性程序判断。
安全团队用 Agent，也要给 Agent 上安全边界
这是另一个容易被忽略的问题。
安全 Agent 为了检查系统，往往会被赋予：
- 代码仓库；
- 云配置；
- 日志；
- 资产清单；
- 漏洞信息；
- 权限信息。
这本身就是高敏能力。
所以必须限制：
Read Scope
Write Scope
Network
Secrets
Tenant
Environment
Approval
不要因为它叫“Security Agent”，就给管理员全权。
一个我会实际推进的 30 天计划
第 1 周：把资产找全
完成：
公网资产
代码仓库
云账户
高权限身份
关键依赖
Secret
先不追求完美。
先形成事实表。
第 2 周：定义 20 个安全不变量
不要写 200 条。
先写最关键的 20 条。
要求每一条都能回答：
怎么自动检查？
失败谁负责？
多久修？
第 3 周：让 AI 做“读和提议”
只允许：
扫描
分析
生成PR
生成配置Diff
不要直接生产修改。
第 4 周：挑 3 类低风险修复自动化
例如：
- 依赖补丁；
- 静态配置；
- 明确的代码规则。
验证误报和回滚。
再扩。
我反而不建议第一步做的事
不是一上来让 Agent：
自动扫描全公司
自动修复所有漏洞
原因是你可能连：
资产Owner是谁
哪些环境能改
哪些变更会停业务
都没整理清楚。
AI 会把执行速度放大。
治理没跟上时，速度越快，事故也可能越快。
最后
昨天那篇文章给我的核心信号不是“AI 网络攻击时代来了”这种大标题。
更实际的是：
技术债的安全折旧速度正在加快。
以前一个没人管的小问题可能躺几年。
以后，机器能更便宜地读代码、读配置、枚举资产、关联弱点。
防守方真正应该利用的窗口，就是趁同样的能力也开始普及，把那些“知道但一直没空修”的东西先清掉。
新安全时代最值得投入的，可能仍然是最老的几件事：
最小权限
资产清单
补丁
隔离
审计
安全发布
只不过现在，我们终于有机会让机器帮人把这些基础工作做得更快。
更多企业级 AI 应用、Agent、RAG 与模型工程化内容，我会继续整理在 智元界：
https://www.zyentor.com/