渣打银行如何用前沿AI守住"防御者窗口"

在OpenAI的一场企业级安全对话中，渣打银行（Standard Chartered）安全负责人Ruben分享了他们如何借助前沿AI模型应对新一轮攻防博弈。核心议题围绕一个概念展开——"防御者窗口"（The Defender's Window）：当前沿模型让攻击者理解软件、识别漏洞的速度大幅缩短时，作为一家全球性银行，防御方必须比攻击者更快地看清哪些漏洞真正可被利用。

从"找漏洞"到"看清可利用性"

Ruben指出一个被很多安全团队忽视的关键转变：安全的重点不该是往一长串CVE清单里再添几条，而是理解"什么才是真正可被利用的"。

"攻击者最终并不是盯着代码仓库和资产看，"他强调，"他们看的是跨系统、跨API、跨身份、跨信任边界的攻击路径。"这意味着传统以仓库和资产为中心的安全项目，天然与攻击者的视角错位。前沿AI的价值，正在于它能够跨越架构、跨越大量微服务及其仓库，理解系统之间究竟发生了什么。

渣打是全球最早评估OpenAI安全产品Daybreak的银行之一。他们最初的动机很明确：想验证前沿AI能否提供传统方法给不了的风险洞察——能否理解跨仓库、跨架构、跨信任边界正在发生的事情。早期观察结果印证了这一判断：当系统能够跨架构、跨众多微服务去理解全貌时，发现的问题明显更多、更有价值。

CVE（Common Vulnerabilities and Exposures，通用漏洞披露）是一套由MITRE组织维护的漏洞标识体系，每条记录对应一个已公开的安全漏洞。大型企业的CVE积压动辄数万条，安全团队长期面临"发现得多、修复不过来"的困境。传统漏洞扫描工具以单个仓库或资产为单位评分（如CVSS分值），却无法回答一个实战中更关键的问题：攻击者能否将若干个低危漏洞串联成一条横穿多个系统的完整攻击链？这种"跨信任边界的攻击路径"视角，正是文中渣打所强调的转变核心——衡量风险的基准不是漏洞的理论严重程度，而是它在真实网络拓扑与身份体系中能否被实际利用。

上下文比模型选择更重要

这场对话中反复出现的一句话是"context is king"（上下文为王）。Ruben给出了一个颇具启发的结论：拥有足够的上下文，比选用哪个模型更重要。

那么在实践中，除了代码库之外还要喂给模型什么？他列举了几类关键信息：架构图与部署模型、资产的依赖关系、与之相连或被其调用的其他服务，以及这个组件最初的"方案意图"（solution intent）。提供的上下文越充分，结果就越好。

有意思的是，这一探索也暴露了SDLC（软件开发生命周期）中一些被想当然的环节。团队原本以为开发团队会持续维护架构文档等资料，实际却发现存在缺口——而这些缺口恰恰需要被补上，才能给AI提供准确的上下文。

SDLC（Software Development Life Cycle，软件开发生命周期）指从需求分析、设计、编码、测试到部署和维护的全流程。"左移（shift left）"这一概念源于将SDLC各阶段按时间轴从左到右排列后，把安全检查尽可能前移到编码乃至设计阶段，而非等到上线前或事后修复。渣打案例中暴露的架构文档缺口，是"左移"落地的常见障碍：如果开发团队不持续维护架构图与依赖关系说明，AI模型获得的上下文就会失真，生成的风险判断也会偏差。这一发现提示，AI辅助安全工具的效果上限，往往不由模型能力决定，而由组织的文档与知识管理成熟度决定。

让AI发现的结果"可信"

把AI工具引入安全流程，技术只是其中一环，更大的挑战在于团队如何运作、以及如何赢得开发团队的信任。

"只是做个演示给开发团队看是不够的，你需要硬证据。"Ruben说。渣打的做法是让应用安全团队与开发团队组成跨职能小组协同工作。任何发现都必须对照代码、对照架构部署、对照实际环境进行验证——这件事必须共同完成。

更重要的是心态转变：不是只盯着"我们发现了什么"，而是聚焦于如何提升修复效率、拿到正确的安全结果。让开发者理解问题的根因，他们下次就不会再以同样方式构建应用；同时不是去"点名批评"，而是与他们一起修复，甚至用前沿AI来协助修复。"这不只是又一个仪表盘，"Ruben总结道，也不是往backlog里再堆一个任务。

用速度重塑安全的角色

像渣打这样的大型机构，拥有既定流程与治理体系，这些体系往往不是为当下所需的速度而设计的。如何建立组织内部的信心去跟上节奏？

Ruben的答案是改变安全在组织中的定位——历史上，安全一直被视为"守门人"或"拦路者"，现在要转变为"赋能者"。具体做法是把安全能力集成进流水线，并让开发者更早地获得访问权限，也就是"左移"（shift left）。他特别认同一个理念：在开发周期中为开发者提供一个虚拟测试空间，让他们能在运行时验证某个漏洞确实可被利用，看到证据后再按可利用性排序优先级。当开发者意识到安全团队是在帮助他们"更快且更安全地前进"时，信任自然建立。这与用agentic编码工具加速工作、避免形成传统负担的思路一脉相承。

打好地基：AI会放大它看到的一切

当被问到"该如何用不同于五年前的方式思考安全"时，Ruben给出了一个务实且值得所有安全领导者深思的建议：先把基础打牢。

他列出几项基础工作：减少技术债、降低技术复杂度（比如不要用太多种编程语言）、保持架构文档更新、建立稳固的身份与访问控制。原因很直接："AI被释放到一个环境里时，它会放大它看到的一切。"地基扎实的组织，才能真正从AI中获得最大收益。

令人稍感意外却也令人安心的一点是：测试过程中并没有冒出大量"离谱"的问题——他们发现的多是预期之内的东西。但确实有一类问题被挖了出来：那些传统工具此前无法识别的领域。这正是新方法最核心的价值所在。

全球化足迹下的团队与未来

渣打运营于全球众多市场，面对多种监管制度与系统，安全覆盖面极其庞大——远不止扫描代码仓库这么简单。

所幸其开发团队集中在几个枢纽，便于协调与协作。渣打对安全团队的定位是"用正确的工具赋能开发者去自助（self-serve）"，让他们能够安全地推进，同时在关键节点设置正确的检查。

对于OpenAI这类产品方，Ruben也提出了明确诉求：能够"规模化运行"。逐个仓库扫描并不可扩展，他希望能在沙箱环境中批量运行、检测漏洞。因为大量应用彼此互联，防御方真正需要理解的是"爆炸半径"（blast radius）——一旦某处被攻破，攻击还能蔓延到哪里。他对OpenAI提出的"防御工厂"（defense factory）设想表示了期待。

这场对话勾勒出企业级安全在前沿AI时代的转型缩影：从堆砌漏洞清单到聚焦可利用性，从充当拦路者到成为赋能者，从依赖模型到重视上下文与基础建设。防御者的窗口正在收窄，而如何跑赢这场竞速，考验的不只是技术，更是组织协作方式的重塑。

"爆炸半径（blast radius）"一词借用自爆炸物理学，在安全领域指当某一组件或账户被攻陷后，攻击者能够横向移动并影响到的最大资产范围。在微服务架构中，服务间通过API和内部信任关系紧密耦合，一个低权限服务的沦陷可能借助服务间调用链迅速扩散至核心数据层。"防御工厂（defense factory）"设想的本质，是将爆炸半径分析自动化并规模化——不再逐仓库孤立评估，而是在沙箱中模拟真实攻击蔓延路径，让防御方在攻击发生前就看清"如果这里被打穿，下一步会波及哪些系统"，从而按实际影响范围而非理论评分来排定修复优先级。