Standard Chartered Taps OpenAI Daybreak to Trace Multi-System Exploits

OpenAI

Isolated vulnerability scans fail against modern threats because AI models detect genuine exploit paths only when supplied with end-to-end architectural context across microservices.

AI-assisted summary of The Defender's Window at enterprise scale with Standard Chartered — original source. Check the original for full context.

Source published: 2026-09-30

Key ideas

Standard Chartered is evaluating OpenAI Daybreak to shift enterprise application security away from isolated CVE lists toward multi-repository, end-to-end exploit path analysis. (0:06)
Frontier AI models require rich architectural context—including deployment models, service dependencies, and solution intent—to move beyond syntax noise and reliably uncover systemic, exploitable flaws. (1:28)
Deploying AI security tools exposes foundational engineering gaps, notably out-of-date SDLC documentation and uncontrolled programming language sprawl, because AI acts as an amplifier of existing organizational discipline or chaos. (7:06)
OpenAI is developing a 'defense factory' capability designed for high-throughput bulk repository analysis and sandboxed exploit validation to assess blast radius across interconnected enterprise systems. (11:05)

Detailed notes

## Background Published by OpenAI on YouTube on September 29, 2026, this fireside chat features Matt Weaver, Head of Applied AI Architects at OpenAI, in conversation with Reuben Athaide, Head of Innovation, Applications & Assurance at Standard Chartered. The video highlights how the international bank implements OpenAI Daybreak to outpace threat actors and protect its global application architecture.

## TL;DR Standard Chartered is leveraging OpenAI Daybreak to transition from conventional, isolated vulnerability scanning to holistic, multi-repository attack path analysis. By feeding frontier models comprehensive architectural context—including deployment blueprints, dependency graphs, and solution intent—the bank uncovers systemic flaws that legacy static tools miss. To integrate these findings effectively, security teams partner directly with developers to provide evidence-based, automated remediation rather than overwhelming ticket queues. Ultimately, scaling this defense requires pristine engineering baselines and automated, sandboxed bulk execution to model attack paths and containment blast radiuses across complex microservices.

## Atmosphere & style The discussion adopts the polished, pragmatic atmosphere of an executive engineering fireside chat, balancing strategic tech optimism with hard-won operational realism. Weaver serves as an inquisitive and validating host, while Athaide delivers candid, measured insights that steer clear of AI hype to address the tedious realities of technical debt, developer fatigue, and documentation gaps. The exchange feels collaborative and grounded, offering an authentic glimpse into the practical friction and breakthrough moments of deploying frontier AI inside a highly regulated global bank.

## Bulletin - [00:06](https://www.youtube.com/watch?v=a75xDflRooI&t=6s) Standard Chartered is evaluating OpenAI Daybreak to shift enterprise application security away from isolated CVE lists toward multi-repository, end-to-end exploit path analysis. - [01:28](https://www.youtube.com/watch?v=a75xDflRooI&t=88s) Frontier AI models require rich architectural context—including deployment models, service dependencies, and solution intent—to move beyond syntax noise and reliably uncover systemic, exploitable flaws. - [07:06](https://www.youtube.com/watch?v=a75xDflRooI&t=426s) Deploying AI security tools exposes foundational engineering gaps, notably out-of-date SDLC documentation and uncontrolled programming language sprawl, because AI acts as an amplifier of existing organizational discipline or chaos. - [11:05](https://www.youtube.com/watch?v=a75xDflRooI&t=665s) OpenAI is developing a 'defense factory' capability designed for high-throughput bulk repository analysis and sandboxed exploit validation to assess blast radius across interconnected enterprise systems.

## Key takeaways - [00:06](https://www.youtube.com/watch?v=a75xDflRooI&t=6s) Frontier AI models fundamentally compress the time required to understand code architectures and discover viable exploit paths. - [00:06](https://www.youtube.com/watch?v=a75xDflRooI&t=6s) Modern threat actors target interconnected attack paths bridging APIs, identity layers, and trust boundaries rather than isolated vulnerabilities in single repositories. - [01:28](https://www.youtube.com/watch?v=a75xDflRooI&t=88s) Supplying holistic architectural context and system intent is far more critical for finding exploitable vulnerabilities than the specific choice of frontier model. - [01:28](https://www.youtube.com/watch?v=a75xDflRooI&t=88s) Feeding supplementary artifacts like architecture diagrams, runtime deployment models, and dependency maps allows AI to evaluate code against operational boundaries rather than static syntax alone. - [03:15](https://www.youtube.com/watch?v=a75xDflRooI&t=195s) Gaining developer trust requires collaborative AppSec-engineering triaging squads that validate AI findings against live deployment environments before raising tickets. - [03:15](https://www.youtube.com/watch?v=a75xDflRooI&t=195s) AI delivers the most engineering value when used to clarify root causes and assist with remediation rather than generating another dashboard of unverified alerts. - [05:28](https://www.youtube.com/watch?v=a75xDflRooI&t=328s) Enterprise security organizations must transition from restrictive gatekeepers to delivery enablers embedded directly within CI/CD pipelines. - [05:28](https://www.youtube.com/watch?v=a75xDflRooI&t=328s) Providing developers with shift-left virtual testing environments showing proof of exploitability drives organic, evidence-based issue prioritization. - [07:06](https://www.youtube.com/watch?v=a75xDflRooI&t=426s) AI amplifies whatever foundation it is introduced to, magnifying both well-governed engineering architectures and underlying technical debt. - [07:06](https://www.youtube.com/watch?v=a75xDflRooI&t=426s) Context-heavy AI adoption exposes hidden documentation gaps and architectural drift that traditional development workflows routinely overlook. - [09:28](https://www.youtube.com/watch?v=a75xDflRooI&t=568s) OpenAI Daybreak uncovered critical cross-codebase blind spots that legacy static and dynamic security tools consistently failed to detect. - [09:51](https://www.youtube.com/watch?v=a75xDflRooI&t=591s) Standard Chartered leverages centralized developer hubs to deploy self-service security tooling with automated checkpoints across diverse global markets. - [11:05](https://www.youtube.com/watch?v=a75xDflRooI&t=665s) Scalable enterprise defense requires bulk scanning and automated execution inside sandboxed environments to dynamically verify real-world exploitability. - [11:05](https://www.youtube.com/watch?v=a75xDflRooI&t=665s) Security assessments must model application interconnectivity to determine lateral movement potential and map the full blast radius of a potential breach.

## Detailed walkthrough ### [00:06](https://www.youtube.com/watch?v=a75xDflRooI&t=6s) Redefining the Defender's Window: Beyond Vulnerability Lists

Matt Weaver opens the discussion by zeroing in on the concept of the "defender's window" and asking what it specifically means for how a global institution like Standard Chartered protects its application landscape. Reuben Athaide explains that frontier AI models fundamentally compress the timeline required to comprehend complex software architectures and uncover actionable exploits. In a worldwide banking environment, defenders must identify and understand these vectors significantly faster than external adversaries can discover them.

Crucially, Athaide stresses that defending modern software is no longer about accumulating endless catalogs of Common Vulnerabilities and Exposures (CVEs) or scanning individual repositories in isolation. Threat actors do not evaluate systems by looking at isolated code assets or single repositories—the way traditional enterprise security programs typically do. Instead, attackers map end-to-end attack paths spanning disparate systems, interconnected APIs, identity layers, and distinct trust boundaries. Weaver agrees with this shift in philosophy, pointing out that Standard Chartered was among the first banks globally to evaluate OpenAI Daybreak to address this exact operational reality.

- **The Threat Landscape**: Frontier models drastically shorten the discovery time for both code comprehension and exploit generation. - **Flaw in Legacy Scanning**: Traditional security scanning evaluates single repositories and isolated assets, missing multi-hop attack vectors. - **Attacker Focus**: Adversaries exploit attack paths that bridge microservices, trust boundaries, APIs, and identity systems.

---

[01:28](https://www.youtube.com/watch?v=a75xDflRooI&t=88s) Context is King: Feeding Architecture and System Intent into Daybreak

Standard Chartered turned to frontier AI to uncover systemic risks that traditional static application security tools routinely miss across complex microservice ecosystems. Early findings revealed that the model's ability to detect genuinely exploitable flaws depends entirely on the richness of the surrounding architectural context. Athaide highlights that possessing holistic context across multiple repositories matters far more than the specific model being run: without broad environmental context, static analysis produces noise, but with it, the AI surfaces genuinely exploitable paths.

When Weaver asks what feeding context looks like in practice beyond basic source code, Athaide details the supplementary inputs injected alongside codebases. The model receives architecture diagrams, deployment models, inter-service dependencies, linked external services, and the original "solution intent" of the application. Supplying this architectural awareness allows Daybreak to evaluate code not merely as static syntax, but against its intended operational boundaries and runtime connectivity.

```mermaid flowchart TD accTitle: Daybreak Context-Driven Security Model accDescr: Flowchart showing how architectural context and multi-repo code feed into OpenAI Daybreak to produce actionable exploit paths. subgraph ContextInputs["Architectural Context"] A["Architecture Diagrams & Deploy Models"] B["Connected APIs & Service Dependencies"] C["Original Solution Intent & Boundaries"] end subgraph Engine["Frontier AI / Daybreak"] D["Multi-Repo Exploit Path Analysis"] end subgraph ActionableOutput["Security Outcomes"] E["Validated Exploitable Vectors"] F["Root-Cause Remediation Guidance"] end ContextInputs --> D D --> ActionableOutput ```

- **Model Agnosticism vs. Context**: Having complete cross-system context provides far higher diagnostic value than picking one frontier model over another. - **Key Context Artifacts**: Architecture deployment models, dependency trees, interconnected service maps, and documented solution intent. - **Holistic Detection**: Multi-repository visibility enables discovery of logic flaws that cross microservice boundaries.

---

[03:15](https://www.youtube.com/watch?v=a75xDflRooI&t=195s) Building Cross-Functional Trust and Actionable Remediation

Introducing AI-generated findings into an enterprise requires earning the engineering organization's trust rather than merely showcasing automated demos. Athaide emphasizes that simply handing development teams a list of AI findings without substance creates friction. To build genuine confidence, Standard Chartered established cross-functional working groups pairing Application Security (AppSec) specialists directly with software developers. Every AI-identified issue is collaboratively validated against the actual codebase, architectural deployment patterns, and the live environment before being flagged for action.

A critical lesson in winning over engineers is shifting the focus away from simply pointing out flaws toward accelerating remediation and delivering clean security outcomes. Athaide and Weaver note that developers dread "another dashboard" or an ever-expanding backlog of security tickets. Instead, frontier AI is used to assist developers in understanding the root causes of vulnerabilities and generating automated fixes, ensuring that teams learn from architectural oversights and do not reintroduce similar patterns into future builds.

- **Collaborative Triaging**: Cross-functional squads composed of AppSec and software engineers jointly validate findings against code and live deployment environments. - **Eliminating Dashboard Fatigue**: The goal is assisting in remediation rather than adding unverified tasks to developer backlogs. - **Root-Cause Education**: Frontier AI provides contextual explanations so developers understand the underlying flaw and avoid repeating architectural mistakes.

---

[05:28](https://www.youtube.com/watch?v=a75xDflRooI&t=328s) Shifting Left and Transforming Security from Gatekeepers to Enablers

A major hurdle for large financial institutions is modernizing governance structures and entrenched processes that were never designed to move at the speed of frontier AI. Athaide reflects on how security teams have historically been perceived across the industry as "gatekeepers or blockers." To overcome this perception, the security apparatus must reposition itself as an enabler that integrates automated verification directly into continuous development pipelines.

By shifting verification left into the developer's everyday workflow—such as providing virtual testing environments where engineers can observe real-time evidence of whether a flaw is genuinely exploitable—developers gain autonomy. When engineers see undeniable, evidence-based exploit paths firsthand, prioritization occurs organically. Weaver notes that pairing this with agentic coding tools allows developers to move faster safely without the friction of traditional compliance bottlenecks.

- **Mindset Transition**: Evolving the security function from an obstructive gatekeeper into a delivery enabler. - **Shift-Left Virtual Testing**: Integrating validation spaces directly into CI/CD pipelines so developers can test code in-flight. - **Evidence-Driven Prioritization**: Developers willingly prioritize fixes when presented with tangible proof of exploitability rather than theoretical risk scores.

---

[07:06](https://www.youtube.com/watch?v=a75xDflRooI&t=426s) Strengthening Engineering Foundations to Maximize AI Impact

Reflecting on long-term shifts in the cybersecurity space, Athaide underscores that effectively deploying AI requires getting core software engineering fundamentals in order first. AI does not magically solve organizational disorder; rather, "AI when it's released into an environment it'll amplify whatever it sees." Organizations with clean architectures and disciplined engineering practices will extract massive value from frontier models, whereas those with unchecked complexity will see their underlying issues magnified.

To prepare for frontier security tooling, enterprises must actively pay down technical debt, prune redundant programming language sprawl, maintain pristine identity and access management (IAM) controls, and keep architectural documentation strictly up to date. Athaide shares that one of the most eye-opening discoveries during their recent implementation journey was uncovering hidden documentation gaps within the software development life cycle (SDLC). Teams took it for granted that architectural documentation was current, only to discover substantial omissions when attempting to ingest that context into Daybreak.

- **The AI Amplifier Rule**: AI amplifies both high-quality foundations and existing architectural chaos with equal intensity. - **Core Prerequisites**: Reducing technical debt, consolidating programming language diversity, and enforcing strict identity and access governance. - **SDLC Blind Spots**: Implementing context-heavy AI tools exposed neglected baseline tasks, specifically out-of-date architecture documentation across microservices.

[09:28](https://www.youtube.com/watch?v=a75xDflRooI&t=568s) Uncovering Blind Spots in Traditional Tooling

Reuben Athaide reflects on the initial results produced by the new AI evaluation approach, pointing out that what they discovered strongly resonated with their practical expectations. While engineering teams naturally expect certain classes of issues to exist or already be queued for remediation, the true value of the approach lies in its ability to illuminate blind spots. Traditional static and dynamic security tooling routinely fail to detect subtle or context-dependent vulnerability patterns. By leveraging OpenAI's frontier model capabilities through Daybreak, the bank successfully surfaced critical issues across codebases that legacy scanners had consistently missed.

[09:51](https://www.youtube.com/watch?v=a75xDflRooI&t=591s) Securing a Global Bank via Developer Self-Service

Matt Weaver shifts the discussion to the sheer scale of Standard Chartered's operations, noting that operating across numerous international markets and fragmented regulatory regimes requires securing an enormous, intricate footprint of diverse systems that goes far beyond simply scanning isolated code repositories. He asks Reuben how the bank thinks about team structure and future readiness to counter modern, rapidly evolving threats.

Reuben explains that while Standard Chartered maintains a vast global market presence, their software development organizations are strategically concentrated within a select few centralized hubs. This concentration makes direct coordination and close collaboration much more manageable. However, the overarching philosophy for enterprise security is not to act as a gatekeeping bottleneck, but rather to function as an enabler. The goal is to provide developers with automated, high-fidelity self-service tooling so they can build securely at pace, backed by automated guardrails and checkpoints embedded throughout the software delivery lifecycle.

```mermaid flowchart LR accTitle: Developer Self-Service Security Model accDescr: Flow showing centralized developer hubs using self-serve tooling with integrated security checks to deploy securely.

subgraph DevHubs ["Centralized Development Hubs"] Dev["Engineering Teams"] end

subgraph SecurityPlatform ["Security Enablement"] Tools["Self-Service Tooling"] Checks["Automated CI/CD Checks"] end

subgraph Target ["Global Enterprise"] Prod["Secure Multi-Market Production"] end

Dev --> Tools Tools --> Checks Checks --> Prod ```

- **Operational Concentration:** Concentrated engineering hubs simplify cross-functional collaboration and standard enforcement across dozens of international operating regions. - **Core Security Mandate:** Enabling developers to "self-serve and go securely" with built-in checkpoint verification rather than manual approvals.

[11:05](https://www.youtube.com/watch?v=a75xDflRooI&t=665s) Scaling with the Defense Factory and Understanding Blast Radius

As the discussion draws to a close, Matt asks Reuben what top capabilities he wants to see incorporated into OpenAI's roadmap to make the defender's mission easier. Reuben highlights that inspecting repositories one by one is fundamentally unscalable for an enterprise of Standard Chartered's breadth. Instead, defenders need the capability to orchestrate high-throughput, bulk analysis within secure, sandboxed execution environments to dynamically validate whether theoretically identified vulnerabilities can be actively exploited.

```mermaid flowchart TD accTitle: Enterprise Defense Factory Workflow accDescr: Process showing bulk sandboxed scanning determining exploitability and mapping blast radius across interconnected systems.

A["Enterprise Code Repositories in Bulk"] --> B["Sandboxed Execution Environment"] B --> C["Automated Exploit Validation"] C --> D["Interconnected Application Topology"] D --> E["Blast Radius Assessment & Breach Containment"] ```

Because modern enterprise applications do not operate in isolation, Reuben emphasizes that testing must model complex interconnectivity to determine full "blast radius"—clarifying where an attacker could navigate if a single service is compromised. He notes that the sneak peek provided of OpenAI's upcoming "defense factory" aligns precisely with what his team envisioned. Matt confirms that OpenAI will soon get Reuben and his team onboarded to the defense factory.

Wrapping up the fireside chat, Matt invites the audience to connect with Reuben for questions during the post-event drinks, before handing the stage over to Claire Lawler, Account Director for the Digital Natives team in EMEA, to kick off the next session.

- **Defensive Automation Needs:** Enterprise defenders require bulk repository scanning and automated exploit execution in sandboxes rather than manual, single-repo analysis. - **Blast Radius Analysis:** Modern tooling must map inter-application dependencies to determine lateral movement potential and overall containment scope. - **Upcoming Rollout:** OpenAI plans to grant Standard Chartered early access to the upcoming Defense Factory capability.

## Notable quotes > [00:06](https://www.youtube.com/watch?v=a75xDflRooI&t=6s) frontier AI models fundamentally compress the timeline required to comprehend complex software architectures and uncover actionable exploits — Reuben Athaide

> [00:06](https://www.youtube.com/watch?v=a75xDflRooI&t=6s) Threat actors do not evaluate systems by looking at isolated code assets or single repositories — Reuben Athaide

> [01:28](https://www.youtube.com/watch?v=a75xDflRooI&t=88s) possessing holistic context across multiple repositories matters far more than the specific model being run — Reuben Athaide

> [03:15](https://www.youtube.com/watch?v=a75xDflRooI&t=195s) developers dread "another dashboard" or an ever-expanding backlog of security tickets — Reuben Athaide

> [05:28](https://www.youtube.com/watch?v=a75xDflRooI&t=328s) historically been perceived across the industry as "gatekeepers or blockers" — Reuben Athaide

> [07:06](https://www.youtube.com/watch?v=a75xDflRooI&t=426s) AI when it's released into an environment it'll amplify whatever it sees — Reuben Athaide

> [07:06](https://www.youtube.com/watch?v=a75xDflRooI&t=426s) AI amplifies both high-quality foundations and existing architectural chaos with equal intensity — Reuben Athaide

> [09:51](https://www.youtube.com/watch?v=a75xDflRooI&t=591s) self-serve and go securely — Reuben Athaide

> [11:05](https://www.youtube.com/watch?v=a75xDflRooI&t=665s) inspecting repositories one by one is fundamentally unscalable for an enterprise of Standard Chartered's breadth — Reuben Athaide

## Mentioned Matt Weaver, Reuben Athaide, Claire Lawler, OpenAI, Standard Chartered, OpenAI Daybreak, Defense Factory

## Video description Matt Weaver, Head of Applied AI Architects at OpenAI, and Reuben Athaide, Head of Innovation, Applications & Assurance at Standard Chartered, discuss how the global bank is using OpenAI Daybreak to stay ahead of attackers.

[Source](https://www.youtube.com/watch?v=a75xDflRooI)

中文简报

渣打银行借助 OpenAI Daybreak 追踪跨系统漏洞利用孤立的漏洞扫描难以应对现代威胁，因为 AI 模型只有在获取跨微服务的端到端架构上下文时，才能检测出真正的漏洞利用路径。渣打银行正利用 OpenAI Daybreak，从传统的孤立漏洞扫描转向全面的多代码库攻击路径分析。通过为前沿模型提供详尽的架构上下文（包括部署蓝图、依赖关系图和解决方案设计意图），该银行能够发现传统静态工具遗漏的系统性缺陷。为了有效落实这些分析结果，安全团队直接与开发人员合作，提供基于实证的自动化修复方案，而非堆积大量工单。从根本上说，扩大这一防御体系的规模需要高度规范的工程基准，以及自动化的沙箱批量执行能力，以模拟跨复杂微服务的攻击路径并控制潜在影响范围。渣打银行正在评估 OpenAI Daybreak，以促使企业应用安全从孤立的 CVE 清单转向多代码库的端到端漏洞利用路径分析。 (0:06) 前沿 AI 模型需要丰富的架构上下文（包括部署模型、服务依赖项和解决方案意图），以排除语法层面的干扰噪音，可靠地发现系统性、可被利用的缺陷。 (1:28) 部署 AI 安全工具会暴露基础工程能力的短板，尤其是过时的 SDLC 文档和缺乏管控的编程语言泛滥，因为 AI 会放大组织现存的严谨秩序或混乱状态。 (7:06) OpenAI 正在开发一种“防御工厂”（defense factory）能力，旨在进行高吞吐量的批量代码库分析和沙箱漏洞利用验证，以评估互联企业系统中的影响范围。 (11:05)

Reading summary

Frontier AI models are drastically shortening exploit discovery timelines, compelling enterprise defenders to abandon isolated vulnerability catalogs in favor of context-rich, multi-repository attack path analysis. Standard Chartered's implementation of OpenAI Daybreak demonstrates that defense at scale depends on coupling architectural context with developer self-service tooling rather than manual compliance gatekeeping. Context-Driven Exploit Mapping Across Repositories (1:28) Reuben Athaide explains that modern adversaries do not inspect codebases or CVE lists in isolation; instead, they target multi-hop attack paths spanning microservices, APIs, and identity systems across trust boundaries. Traditional security scanners evaluate isolated repositories and routinely miss systemic, cross-boundary risks. Standard Chartered deployed OpenAI Daybreak specifically to analyze these interconnected paths across complex enterprise environments. Early findings showed that frontier AI's diagnostic precision relies heavily on surrounding context rather than the underlying model selection alone. To eliminate noise and identify genuinely exploitable flaws, the bank feeds Daybreak architecture diagrams, deployment models, dependency maps, and documented solution intent alongside source code, allowing the AI to assess software against its runtime connectivity. Engineering Discipline as an AI Amplifier (7:06) Athaide underscores that frontier AI tools do not solve foundational organizational disorder, noting that AI amplifies whatever engineering conditions it encounters. Extracting tangible security value requires organizations to maintain disciplined software practices, including reducing technical debt, curbing programming language sprawl, and enforcing rigorous identity and access management controls. The deployment process also exposed critical software development lifecycle gaps. Standard Chartered teams discovered that architectural documentation was frequently out-of-date across microservices—an omission that only became apparent when attempting to ingest systemic architectural context into Daybreak. Transitioning Security into Developer Self-Service Enablement (3:15) To prevent security from functioning as a bureaucratic blocker across dozens of global markets, Standard Chartered concentrates development within regional engineering hubs equipped with automated self-service guardrails. Rather than burdening developers with unverified alert backlogs and dashboard fatigue, cross-functional squads pairing application security specialists with engineers collaboratively validate findings against live deployments. By embedding virtual testing environments directly into CI/CD pipelines, engineers receive undeniable, empirical proof of whether a vulnerability is exploitable. Athaide and Matt Weaver observe that developers readily prioritize remediation when shown tangible attack paths, while AI-generated root-cause explanations help prevent teams from reintroducing identical architectural oversights into future builds. High-Throughput Bulk Sandboxing and Blast Radius (11:05) As enterprise security scales, Athaide notes that manual, single-repository analysis becomes fundamentally unviable. Defenders require high-throughput automation capable of ingesting enterprise code in bulk and executing tests inside sandboxed environments to confirm dynamic exploitability. Beyond verifying single exploits, modern defense requires mapping interconnected application topologies to evaluate blast radius—identifying precisely how far an adversary could navigate laterally if an initial service falls. Weaver confirmed that OpenAI is preparing to onboard Standard Chartered into its upcoming 'defense factory' framework to support this bulk sandboxing and lateral reach analysis. While frontier models expose subtle vulnerabilities missed by legacy scanners, scaling AI-assisted defense requires institutions to remediate documentation blind spots, shift from manual approval gates to developer self-service, and deploy high-throughput sandbox infrastructure to validate lateral blast radius.

精炼阅读摘要

渣打银行（Standard Chartered）与 OpenAI 探讨了如何借助前沿 AI 模型重塑企业防御窗口。双方指出，企业安全防护必须从传统的单代码库扫描和漏洞清单罗列，转向依托全局架构上下文与自动化沙盒验证的多跳攻击路径分析。重塑防御窗口与攻击路径视角 (0:06) 渣打银行的 Reuben Athaide 指出，前沿 AI 模型大幅压缩了理解复杂软件架构和挖掘可利用漏洞所需的时间，这要求防御者识别系统风险的速度必须快于外部攻击者。现代安全防护的重点不再是积累无休止的通用漏洞披露（CVE）清单，也不是孤立地对单个代码仓库进行常规扫描。攻击者在渗透系统时，往往会通过跨越微服务、API、身份层和信任边界的多跳路径寻找薄弱点。传统企业安全工具如果仅对孤立资产进行静态检测，必然会遗漏这种端到端的系统性攻击路径。OpenAI 的 Matt Weaver 提到，渣打银行是全球首批评估 OpenAI Daybreak 工具以应对这一现实挑战的银行之一。架构上下文驱动精准漏洞挖掘 (1:28) 在复杂微服务体系中，静态应用安全测试工具常常产生大量噪音并遗漏上下文关联漏洞。Athaide 强调，决定 AI 检测实际可利用漏洞能力的关键因素，并非单纯选用哪个前沿模型，而是模型所接收到的跨仓库与架构上下文的丰富度。在实践中，仅向 Daybreak 输入基础源代码远远不够，银行还注入了架构部署模型、服务间依赖拓扑、关联外部服务以及应用的原始设计意图。这些上下文信息让模型能够跳出代码语法本身，依据系统的运行边界和动态连通性展开推理，从而排查出跨越微服务边界的深层逻辑缺陷。协作分流与消除告警倦怠 (3:15) 在企业内部推行 AI 生成的安全结果时，首要挑战是赢得工程团队的信任。Athaide 认为，仅仅向开发人员推送 AI 漏洞清单不仅无法解决问题，还会加剧流程摩擦与“面板倦怠”。为此，渣打银行组建了由应用安全专家与软件工程师组成的跨职能小组，在代码库、架构部署模式以及真实生产环境中对 AI 发现的每一个问题进行联合验证。双方的合作核心不再停留于指出缺陷，而是利用前沿 AI 解释漏洞的根本成因，并自动生成修复方案，帮助开发团队在消除技术隐患的同时，避免在后续迭代中重复出现同类设计缺陷。安全左移与开发者自助服务 (5:28) 安全部门过去常被开发团队视作流程卡点或阻碍者。Athaide 提出，安全机制必须转变为赋能工具，将自动化验证能力直接融入开发者的日常 CI/CD 流水线中。通过在流水线中提供虚拟测试环境，开发人员能够直观看到漏洞可被真实利用的证据，从而自发地按优先级修复问题，无需依赖抽象的风险评分或繁琐的合规审批。针对渣打银行跨多个国际市场但研发团队集中于少数区域中心的运营现状，安全团队的核心目标是提供高保真自助工具和内置检查点，确保开发人员在保持敏捷交付的同时兼顾系统安全。夯实工程基座与防御工厂构想 (7:06) Athaide 指出，AI 会同等放大组织内部既有的工程优势与架构混乱，因此部署前沿安全模型的前提是夯实软件工程基准，包括偿还技术债务、收敛编程语言冗余以及严格管控身份访问管理（IAM）。在引入 Daybreak 的过程中，银行发现团队此前普遍忽视了微服务架构文档的过时问题。展望未来，Athaide 认为按仓库逐个排查的方式无法支撑跨国银行的庞大规模，防御者需要一种能够在安全沙盒中执行批量代码分析并自动化验证漏洞利用的技术，以此评估单点失效后横向移动的“爆炸半径”。Weaver 确认，OpenAI 即将安排渣打银行团队试用正在研发中的“防御工厂”（Defense Factory）功能。该对话阐明了大型金融机构利用 AI 实现自动化威胁排查的实施路径，但其效果高度依赖企业底层的代码规范与最新的架构文档。关于批量沙盒验证及跨系统爆炸半径分析等防御工厂构想，仍有待在后续实际投产中验证其性能与可行性。

Detailed notes — zh

## Background 该视频由 OpenAI 于 2026 年 9 月 29 日发布在 YouTube 官方频道。视频内容为 OpenAI 实用 AI 架构师负责人 Matt Weaver 与渣打银行创新、应用与保障负责人 Reuben Athaide 的炉边对谈，重点探讨这家跨国金融巨头如何借助 OpenAI Daybreak 等前沿 AI 工具在攻防博弈中抢占先机、守住“防御者窗口”。 ## TL;DR 在本次对谈中，渣打银行分享了将前沿模型引入大型金融机构安全防御体系的实战经验。Reuben Athaide 指出，现代安全治理的重心已从机械堆砌 CVE 清单转向利用架构拓扑、依赖关系及设计意图等全量上下文，精准锁定具备真实可利用性的攻击链路。渣打银行将安全团队从传统“把关人”重塑为通过 CI/CD 与自服务工具链赋能研发的敏捷角色，并通过确凿证据链与 AI 辅助修复机制建立跨部门技术互信。最后，双方深入探讨了 AI 作为“系统底座放大器”的治理现实，并展望了借助大规模沙箱与 OpenAI“防御工厂”（Defense Factory）应对微服务集群爆炸半径的未来演进方向。 ## Atmosphere & style 整场对谈洋溢着务实、严谨且极具行业穿透力的技术极客氛围，没有空洞的 AI 营销话术，处处透露出大型跨国银行在复杂生产环境中摸爬滚打出的工程洞察。Matt Weaver 的提问循序渐进、切中痛点，Reuben Athaide 的回答则坦诚犀利，既敢于指出传统静态扫描与单纯做 Demo 的局限，又冷静道出“基础不牢、AI 反成混乱放大器”的反直觉真知灼见。两位资深专家的交流节奏紧凑、同频共振，让听众在浓厚的实战攻防视角中，真切感受到前沿科技重构企业安全范式时的紧迫感与落地力量。 ## Bulletin - [01:06](https://www.youtube.com/watch?v=a75xDflRooI&t=66s) 渣打银行成为全球首批评估 OpenAI Daybreak 的金融机构，测试表明在微服务集群中提供完整的系统上下文比挑选特定基座模型更关键。 - [00:06](https://www.youtube.com/watch?v=a75xDflRooI&t=6s) 防御策略正从死板罗列 CVE 漏洞清单转向验证端到端“实际可利用性”，重点防范攻击者跨系统、API 与信任边界的渗透路径。 - [07:05](https://www.youtube.com/watch?v=a75xDflRooI&t=425s) AI 在企业安全中扮演“放大器”角色，若底层架构、技术栈规范与 IAM 权限混乱，AI 将成倍放大暴露的问题而非带来防御红利。 - [11:06](https://www.youtube.com/watch?v=a75xDflRooI&t=666s) OpenAI 正在构想“防御工厂”（Defense Factory）概念，旨在通过隔离沙箱环境对海量企业资产进行批量漏洞利用验证与爆炸半径评估。 ## Key takeaways - [00:06](https://www.youtube.com/watch?v=a75xDflRooI&t=6s) 前沿模型大幅缩短了黑客逆向理解系统和构造漏洞利用的时间，倒逼跨国金融机构争夺防御者窗口。 - [00:06](https://www.youtube.com/watch?v=a75xDflRooI&t=6s) 网络防御核心转向精准识别“真正具备可利用性”的缺陷，因为黑客从不局限于单个代码仓库的单点边界。 - [01:06](https://www.youtube.com/watch?v=a75xDflRooI&t=66s) 渣打银行在早期测试 Daybreak 时发现，当 AI 穿透架构层并掌握微服务联动逻辑时，风险研判的信噪比迎来质的飞跃。 - [02:27](https://www.youtube.com/watch?v=a75xDflRooI&t=147s) 有效上下文不仅是源代码，还必须囊括高维物理与逻辑部署拓扑、动态调用依赖以及业务团队最初的“设计意图”。 - [03:14](https://www.youtube.com/watch?v=a75xDflRooI&t=194s) 打消开发团队对 AI 幻觉和虚警疑虑的关键在于“硬核证据”，必须让 AppSec 专家与一线开发者对照拓扑共同实测复现。 - [04:21](https://www.youtube.com/watch?v=a75xDflRooI&t=261s) 安全团队应杜绝沦为单纯的催办看板，而应将前沿 AI 延伸至底层根因透视与辅助代码修复环节。 - [05:26](https://www.youtube.com/watch?v=a75xDflRooI&t=326s) 安全团队需从阻碍业务的“把关人”转型为“赋能者”，通过 CI/CD 左移和轻量化虚拟验证环境让开发者即时获得可利用性证据。 - [07:05](https://www.youtube.com/watch?v=a75xDflRooI&t=425s) 落地高阶 AI 前必须夯实底层基础工程，包括缩减历史技术债务、收敛语言栈复杂度、同步动态架构蓝图与强化 IAM 控制。 - [08:36](https://www.youtube.com/watch?v=a75xDflRooI&t=516s) AI 深度推演暴露出传统 SDLC 中长期被忽视的短板，倒逼团队修补架构文档与代码脱节的隐性断层。 - [09:28](https://www.youtube.com/watch?v=a75xDflRooI&t=568s) 面对全球化多监管环境，渣打银行通过集中化研发中心为工程师配备自服务安全工具链，兼顾交付速度与自动化安全卡点。 - [11:06](https://www.youtube.com/watch?v=a75xDflRooI&t=666s) 单仓孤立扫描无法应对真实企业级风险，防御方迫切需要在隔离沙箱中批量验证潜在链路并评估整体爆炸半径。 ## Detailed walkthrough ### [00:06](https://www.youtube.com/watch?v=a75xDflRooI&t=6s) 防御者窗口与可利用性漏洞的认知重塑对谈伊始，OpenAI 实用 AI 架构师负责人 Matt Weaver 便直奔主题，向渣打银行（Standard Chartered）创新、应用与保障负责人 Reuben Athaide 提问：对于像渣打这样体量的全球性银行而言，当前业界热议的“防御者窗口”（Defender's Window）究竟意味着什么，他们又是如何保护旗下复杂应用生态的。Reuben 直言，前沿模型（Frontier Models）的爆发从根本上改变了博弈规则——攻击者理解软件系统、挖掘并设计漏洞利用（Exploits）的时间成本被断崖式缩短。作为一家跨国金融机构，渣打银行必须比外部攻击者更快地摸清这些潜在威胁的全貌。更为关键的是防御视角的转变。Reuben 强调，现代安全防御的核心早已不是在代码仓库里搜刮传统的通用漏洞披露（CVE），而是要精准辨别哪些缺陷是“真正具备可利用性”（actually exploitable）的。传统的安全治理项目往往紧盯单个代码仓库或孤立资产，然而黑客在发起攻击时根本不会受限于单点边界。攻击者眼中只有跨系统、跨 API、跨身份标识（ID）以及跨信任边界（trust boundaries）的完整攻击路径。 ```mermaid flowchart LR accTitle: 传统安全视角与攻击者视角的差异对比 accDescr: 对比传统安全项目仅关注单一代码库与资产，而攻击者着眼于跨API与信任边界的攻击路径。 subgraph Traditional["传统安全视角"] direction TB T1["独立代码仓库"] T2["单一服务器资产"] T3["罗列 CVE 漏洞清单"] end subgraph Attacker["攻击者与新型防御视角"] direction TB A1["跨微服务与 API 调用"] A2["穿透信任边界与身份认证"] A3["构建端到端漏洞利用路径"] end Traditional -.->|"范式升级"| Attacker ``` ### [01:06](https://www.youtube.com/watch?v=a75xDflRooI&t=66s) OpenAI Daybreak 的实战评估：上下文胜过模型选择 Matt Weaver 对此高度共鸣，指出如果仅仅是在原本就冗长的 CVE 清单上再添一笔，对提升防护能力毫无助益。他提到渣打银行是全球首批评估 OpenAI Daybreak 的金融机构之一，而 Daybreak 预计将成为未来防御者生态的关键一环。在谈及引入 Daybreak 的初衷时，Reuben 透露，渣打银行最初布局该方向，就是想验证前沿 AI 是否能够洞察到传统静态扫描和传统手段完全无法触及的架构盲区——尤其是在交错复杂的微服务集群、海量代码仓库和多重信任边界之间。渣打银行在早期测试中获得的核心发现是：当 AI 系统能够穿透架构层、掌握多套微服务代码仓库之间的联动逻辑时，模型给出的有效研判会迎来爆发式增长。这印证了一条核心经验：“上下文至关重要”（context really matters）。Reuben 指出，在实际落地中，提供足够全面、准确的系统上下文，其重要性甚至远远超过了企业究竟选用哪一个具体的前沿基座模型；缺乏上下文的模型只是盲人摸象，而拥有完整上下文的模型才能准确锁定那些真正能被攻击者利用的高危链路。 - 传统静态代码分析容易陷入单仓局部视野，遗漏跨系统协同带来的安全缺口。 - 在微服务架构普及的银行体系中，上下文的丰富度直接决定了安全分析的信噪比与准确率。 ### [02:27](https://www.youtube.com/watch?v=a75xDflRooI&t=147s) 何谓真正的“上下文”：架构、依赖与设计意图针对“上下文即王道”（context is king）的共识，Matt Weaver 进一步拆解细节：行业内普遍在尝试用前沿模型做静态代码分析，但在实际工程落地中，除了将代码库输入给模型之外，渣打银行到底还投喂了哪些深层信息来辅助模型推理？ Reuben 详细列举了他们注入的核心上下文要素。首先是高维度的系统架构图与实际部署架构模型，确保模型理解组件在物理和逻辑层面的位置；其次是服务间的拓扑依赖关系，厘清当前资产正在与哪些外部服务互通或被谁调用；最后，也是最容易被忽视的一点，是系统的“设计意图”（solution intent）——即业务团队最初构建这套组件的原始目标与业务假设。只有把部署架构、依赖拓扑和设计初衷全部打包呈现给模型，模型才能在代码语义之外具备宏观视野，交付真正高质量的风险研判。 - **系统架构图与部署拓扑**：明确网络位置、隔离区与信任边界。 - **动态与静态依赖关系**：梳理各微服务、网关与底层资产的调用连线。 - **业务设计初衷（Solution Intent）**：辅助模型辨析预期业务行为与异常利用行为之间的差异。 ### [03:14](https://www.youtube.com/watch?v=a75xDflRooI&t=194s) 跨职能协作与建立开发团队的技术信任技术落地之外，组织机制与人性的考量往往更为棘手。Matt Weaver 指出，安全负责人有责任在推广颠覆性工具时赢得团队的信任。AI 生成的漏洞分析容易被质疑为幻觉或虚警，渣打银行是如何让研发团队信服这些 AI 发现的？这种转变又如何重塑了团队的组织方式？ Reuben 直言不讳地指出，光是在会议室给研发团队放演示 Demo（"just doing a demo and showing it... isn't good enough"）根本解决不了信任问题，工程师只认“硬核证据”（hard evidence）。为了打消疑虑，他们改变了原先安全团队单向扔报告的模式，建立了由应用安全（AppSec）专家与一线开发团队紧密结合的跨职能联合小组。AI 挖出的任何潜在可利用路径，都必须由安全专家与开发者坐在一起，拿着代码、对照架构部署拓扑并在实际环境中共同跑通验证。这种基于硬核事实的协作过程，逐步在原本存在隔阂的部门之间搭建起了技术互信。 ### [04:21](https://www.youtube.com/watch?v=a75xDflRooI&t=261s) 赋能修复而非单纯报警：超越“另一个看板” 谈及让整个软件工程社区达成共识的阻力，Matt 提出很多大企业的安全困境在于：安全往往被视为安全团队自己的杂事，缺乏研发部门的自发支持。渣打银行在探索过程中，摸索出了一套让工程师真正接纳新思维的方法论。 Reuben 强调，安全团队绝不能扮演“只会挑刺”的角色，敲响警钟不是目的，真正的价值在于提升漏洞修复的效率，并达成实质性的安全成果。一方面，利用前沿模型深入剖析问题发生的底层根因（root cause），开发人员一旦彻底理解了设计陷阱，在未来的编码中就会主动规避同类架构缺陷；另一方面，也是最为关键的一点，渣打银行直接将前沿 AI 能力延伸到漏洞修复（remediation）阶段，由 AI 辅助提供针对性代码修补方案。Matt Weaver 极力赞同这一做法，感叹这避免了沦为“又一个催办看板”，没有只是机械地给研发人员的待办清单（backlog）追加沉重负担。 - 转向赋能型安全：从单纯“通报漏洞”转为“协助高效修复”。 - 根因透视反哺架构：让开发者掌握根因，从源头杜绝相似脆弱代码反复出现。 - AI 深度介入修复：直接利用前沿 AI 辅助编写修复方案，释放工程交付压力。 ### [05:26](https://www.youtube.com/watch?v=a75xDflRooI&t=326s) 改变安全团队的“看门人”定位与敏捷左移话题重新回到“防御者窗口”带来的时间紧迫感上。Matt Weaver 提出疑问：渣打银行这样历史悠久、体量庞大的全球银行，往往背负着复杂的既定流程与繁复的合规治理要求，原本的机制并非为如今这种极速迭代的 AI 节奏而设计，渣打银行如何能在组织内部建立信心，更新陈旧流程并跟上所需的速度？ Reuben 坦言，长期以来，防御者与安全部门在各种组织里几乎都被当成“把关人”（gatekeeper）甚至业务推进的“拦路虎”（blocker）。破局的核心在于将安全团队的心态彻底重塑为“赋能者”（enablers）。在实践层面，渣打银行将安全能力全面集成进 CI/CD 流水线，践行彻底的安全左移（Shift Left），让工程师在研发早期就能自主调用这些能力。他们借鉴了在研发周期中构建轻量化虚拟验证空间的思路，让开发者在编码运行的过程中即时对可利用性进行实测。工程师能够亲眼目睹漏洞确实可以被成功利用的客观证据，进而心服口服地依据“可利用性级别”而非教条的漏洞评级来排定修复优先级。当开发者切身感受到安全工具是在帮助他们“既安全又飞快地向前跑”时，抵触情绪便会烟消云散。 ```mermaid flowchart TD accTitle: 安全左移与漏洞验证工作流 accDescr: 展示开发人员在虚拟验证空间中实时检测、获取可利用性证据并协同优先修复的闭环流程。 subgraph Pipeline["研发流水线集成（安全左移）"] P1["代码编写与组件集成"] P2["虚拟运行空间动态测试"] end subgraph Validation["AI 与证据链验证"] V1["前沿 AI 注入系统上下文"] V2["提取漏洞可利用性确凿证据"] end subgraph Action["敏捷协同与修复"] A1["依据可利用性排定优先级"] A2["AI 协同生成修复方案并消除隐患"] end P1 --> P2 P2 --> V1 V1 --> V2 V2 --> A1 A1 --> A2 ``` ### [07:05](https://www.youtube.com/watch?v=a75xDflRooI&t=425s) 夯实底层架构：AI 时代的放大器效应与治理基石 Matt Weaver 结合双方在登台前讨论的话题感慨道：安全领域永远是防御者与威胁主体之间的军备竞赛，双方都在争抢微弱的领先身位；但在前沿 AI 降临的当下，这种博弈是否需要完全颠覆传统认知？现如今的思考方式与五年前究竟有何根本不同？ Reuben 给出了一个看似反直觉却极其深刻的见解：在拥抱高精尖 AI 之前，最紧迫的反而是回归基础——“必须先把底层地基彻底夯实”（you've got to make sure that you've got your foundations down right）。在实测中他们清晰地看到，AI 实际上是一个“放大器”（AI will amplify whatever it sees）——如果企业自身的系统底子坚实，AI 就能最大化赋能防御；反之，若系统本身混乱不堪，AI 暴露出的问题也将成倍扩散。因此，渣打银行聚焦于几项扎实的基础工程： - **大力缩减技术债务**：清理历史包袱，理顺遗留资产。 - **收敛技术栈复杂度**：坚决精简和统一开发语言，避免语言泛滥造成治理黑盒。 - **动态更新架构蓝图**：保障架构文档时刻反映生产现状，为 AI 分析提供真实的上下文土壤。 - **坚固身份与访问控制（IAM）**：打造坚不可摧的身份与权限底座，守好最底层的信任防线。 ### [08:36](https://www.youtube.com/watch?v=a75xDflRooI&t=516s) 半年实践的意外发现：SDLC 隐性短板的显性化在谈及过去约半年内将生成式 AI 引入安全流程的历程时，Matt Weaver 询问 Reuben 是否遭遇了某些始料未及的意外收获或教训。 Reuben 分享道，最大的意外其实正是源于对“上下文重要性”的深刻认识。过去在软件开发生命周期（SDLC）中，大家往往默认开发团队会按部就班地维护好系统架构图、依赖清单等基础资产；但当真正把 AI 接入、强依赖上下文去进行深度推演时，团队才惊讶地发现，日常被视作理所当然的基础工程其实存在大量脱节和断层，很多架构细节根本没有随代码同步更新。这一发现迫使他们回过头去直面并补齐 SDLC 中的这些基础短板。与此同时，令人欣慰的是，测试并没有像某些人担忧的那样发现大量完全不可控的离奇风险，而是有力验证了只要基础底座扎实，前沿 AI 便能成为防御者手中最为可靠的倍增器。 ### [09:28](https://www.youtube.com/watch?v=a75xDflRooI&t=568s) 超越传统工具：全球化银行的安全自服务理念在回顾应用 OpenAI 方案的实际成效时，Reuben Athaide 指出，团队发现该方法所捕获的问题切中了现实痛点，有效补全了传统安全工具未能覆盖的盲区。面对渣打银行（Standard Chartered）跨越全球众多市场、受制于复杂多样的监管体系（regulatory regimes）以及跨业务部门繁复异构系统的庞大体量，Matt Weaver 强调，安全工作绝不仅仅是“扫描代码仓库”（scanning code repos）那么简单。针对如此庞大而复杂的业务版图，Matt 探询了渣打银行如何构建面向未来的安全团队架构以应对层出不穷的新型安全威胁。针对全球化运作带来的治理挑战，Reuben 阐述了渣打银行的团队组织架构与核心安全理念。尽管业务触角遍布全球各地，但其软件研发团队相对集中在少数几个核心研发中心（hubs），这大幅降低了跨地域协作与沟通的阻力。在安全职能定位上，安全团队的核心目标是赋能（enabling）研发人员，为他们配备能够实现“自服务”（self-serve）的安全工具链，使开发者能够在日常流程中自主、安全地推进交付，同时在全流程的关键节点嵌入自动化检查与防护卡点。 ```mermaid flowchart LR accTitle: 渣打银行开发者自服务安全工作流 accDescr: 展示开发团队通过集中化研发中心使用自服务工具并经由自动化安全卡点完成交付的流程 subgraph Hubs["集中化研发中心"] Dev["研发团队"] end subgraph Enablement["安全赋能与交付"] Tooling["自服务安全工具链"] Checks["全流程安全卡点与检查"] Deploy["安全上线交付"] end Dev --> Tooling Tooling --> Checks Checks --> Deploy ``` - **传统检测盲区弥补**：新方法在实际落地中表现亮眼，成功挖掘并修复了传统安全扫描工具长期无法检出的深层隐患。 - **研发布局与协作**：虽然渣打银行服务于全球多国市场且面临各异的监管要求，但通过将研发力量聚焦于核心 Hub，有效保证了开发与安全协同的敏捷性。 - **安全自服务哲学**：安全团队不再做阻碍创新的审批官，而是转向通过提供恰当的工具链，支持开发者“自给自足地安全前行”（self-serve and go securely）。 --- ### [11:06](https://www.youtube.com/watch?v=a75xDflRooI&t=666s) 应对爆炸半径：大规模沙箱与“防御工厂”（Defense Factory）随着前沿模型（Frontier models）在网络安全攻防领域的快速迭代，Matt 询问渣打银行作为企业级防御者，希望 OpenAI 在未来产品中提供哪些核心能力。Reuben 坦言，此前双方在交流中达成的共识正是渣打银行最为迫切的需求：**规模化（scale）**。在真实的企业环境中，逐个代码库（repo-by-repo）单独扫描的方式完全不具备可扩展性。银行内部存在数以千计相互依赖与调用的业务应用，一旦某一环节失守，评估其“爆炸半径”（blast radius）以及横向移动渗透的潜在路径至关重要。为了彻底验证系统弱点，Reuben 强调必须能够在隔离的沙箱环境（sandboxed environment）中对海量资产进行批量（bulk）利用验证与渗透模拟。他高度评价了 OpenAI 正在构想的“防御工厂”（Defense Factory）概念，认为该方案将是解决大规模依赖关系与连锁突破风险的关键武器。Matt 对此给予了积极回应，表示期待尽快为 Reuben 团队开通 Defense Factory 的访问权限。对谈接近尾声，Matt 感谢了 Reuben 的精彩分享，并邀请现场参会者在随后的酒会环节继续与 Reuben 深入交流，随后将舞台交接给欧洲、中东及非洲地区（EMEA）数字原生客户总监 Claire Lawler 开启下一场议程。 - **规模化验证痛点**：单仓孤立检测无法反映真实风险，必须具备在沙箱环境下对整个代码资产库进行大规模并发检测与模拟利用的能力。 - **评估爆炸半径（Blast Radius）**：面对复杂的企业微服务与互联系统，防御方急需掌握单点被攻陷后黑客可能扩散至何处（"where else does it go"）。 - **防御工厂（Defense Factory）落地**：OpenAI 正在研发能够自动化批量分析攻击路径与防御加固的防御体系，渣打银行将作为早期先锋团队介入试用。 ## Notable quotes > [00:06](https://www.youtube.com/watch?v=a75xDflRooI&t=6s) actually exploitable — Reuben Athaide > [01:06](https://www.youtube.com/watch?v=a75xDflRooI&t=66s) context really matters — Reuben Athaide > [02:27](https://www.youtube.com/watch?v=a75xDflRooI&t=147s) context is king — Matt Weaver > [03:14](https://www.youtube.com/watch?v=a75xDflRooI&t=194s) just doing a demo and showing it... isn't good enough — Reuben Athaide > [07:05](https://www.youtube.com/watch?v=a75xDflRooI&t=425s) you've got to make sure that you've got your foundations down right — Reuben Athaide > [07:05](https://www.youtube.com/watch?v=a75xDflRooI&t=425s) AI will amplify whatever it sees — Reuben Athaide > [09:28](https://www.youtube.com/watch?v=a75xDflRooI&t=568s) scanning code repos — Matt Weaver > [09:28](https://www.youtube.com/watch?v=a75xDflRooI&t=568s) self-serve and go securely — Reuben Athaide > [11:06](https://www.youtube.com/watch?v=a75xDflRooI&t=666s) where else does it go — Reuben Athaide ## Mentioned Matt Weaver, Reuben Athaide, Claire Lawler, OpenAI, Standard Chartered, OpenAI Daybreak, Defense Factory, CVE ## Video description Matt Weaver, Head of Applied AI Architects at OpenAI, and Reuben Athaide, Head of Innovation, Applications & Assurance at Standard Chartered, discuss how the global bank is using OpenAI Daybreak to stay ahead of attackers. [Source](https://www.youtube.com/watch?v=a75xDflRooI)

Source quotes

[0:06] Reuben Athaide: actually exploitable [1:06] Reuben Athaide: context really matters [2:27] Matt Weaver: context is king [3:14] Reuben Athaide: just doing a demo and showing it... isn't good enough [7:05] Reuben Athaide: you've got to make sure that you've got your foundations down right [7:05] Reuben Athaide: AI will amplify whatever it sees [9:28] Matt Weaver: scanning code repos [9:28] Reuben Athaide: self-serve and go securely [11:06] Reuben Athaide: where else does it go

Source quotes

[0:06] Reuben Athaide: frontier AI models fundamentally compress the timeline required to comprehend complex software architectures and uncover actionable exploits [0:06] Reuben Athaide: Threat actors do not evaluate systems by looking at isolated code assets or single repositories [1:28] Reuben Athaide: possessing holistic context across multiple repositories matters far more than the specific model being run [3:15] Reuben Athaide: developers dread "another dashboard" or an ever-expanding backlog of security tickets [5:28] Reuben Athaide: historically been perceived across the industry as "gatekeepers or blockers" [7:06] Reuben Athaide: AI when it's released into an environment it'll amplify whatever it sees [7:06] Reuben Athaide: AI amplifies both high-quality foundations and existing architectural chaos with equal intensity [9:51] Reuben Athaide: self-serve and go securely [11:05] Reuben Athaide: inspecting repositories one by one is fundamentally unscalable for an enterprise of Standard Chartered's breadth

Original transcript

[0:06] Ruben, we've heard a lot today about the [0:09] defenders window, so I'd love to start [0:11] the conversation there. What does it [0:13] mean for standard charted and how you're [0:15] protecting your applications? [0:16] >> Right. I mean um for for standard [0:19] charted I guess when we you know with [0:21] with um frontier models uh what we've [0:24] seen is that it obviously makes the the [0:27] time to understand software and the time [0:30] to figure out and identify exploits as [0:33] well a lot shorter and and as such as a [0:36] as a bank in a global scale uh you need [0:39] to be able to understand what are these [0:42] exploits a lot faster than than the [0:44] attackers. Um, so it isn't really about [0:47] finding vulnerabilities in code, but [0:49] it's about understanding what is [0:51] actually exploitable because attackers [0:53] at the end of the day, they aren't [0:54] looking at repos and assets, which is [0:56] what a lot of security programs look at. [0:58] They look at attack parts across [1:00] systems, across APIs, across IDs, and [1:02] across trust boundaries. So that's [1:05] really key. [1:06] >> Got it. Couldn't couldn't agree more [1:07] that it's not just about adding to a [1:10] longer list of CVES. Um, Standard [1:12] Charted have been one of the first banks [1:14] in the world to evaluate Daybreak, which [1:16] we believe is going to be a critical [1:17] part of the Defender ecosystem. So, I'd [1:20] love to hear a little bit about how [1:22] you've been using Daybreak so far. What [1:24] kind of results are you seeing? Uh, how [1:26] has it really been incorporated into the [1:27] way that your teams are working? [1:28] >> Sure. Um we we started looking down this [1:31] track because we wanted to see whether [1:33] Frontier AI was able to give us uh more [1:36] insights into risks that the traditional [1:39] approaches would not be able to provide [1:41] us with. Uh would it be able to [1:43] understand what uh what's happening [1:46] across different repositories, what's [1:48] happening across architectures and and [1:50] trust boundaries. So that's why we [1:52] started looking into this. Um and what [1:55] we found initially our our earlier [1:58] observations are that when the system is [2:00] able to understand across architecture [2:04] uh across you know we have a lot of [2:06] microservices across microservices [2:08] repositories what exactly is going on [2:10] you get a lot more findings. So it's a [2:12] lot it's it's a lot better to have that [2:14] context around. So so context really [2:17] matters. It it's more important to have [2:19] that context than which model you pick. [2:21] uh because with that context then you're [2:23] able to uh find a lot of things that are [2:25] truly exploitable. [2:27] >> That's really interesting. So we we we [2:28] hear a lot about kind of taking these [2:30] frontier models and using them for [2:31] static code analysis and trying to [2:33] identify exploits that way. But uh can [2:35] you just expand and maybe double click [2:36] into that for me when you say like [2:37] giving it more context and I agree [2:39] context is king. What in practice does [2:42] that look like? What what else are you [2:43] feeding into the model at the time that [2:45] you give it the codebase to help it do? [2:47] So things like um the architecture the [2:50] architecture diagram what is the what is [2:52] the architecture deployment model of [2:54] what we're looking at uh what are the [2:56] dependencies um what are you know other [2:59] services that are connected or or being [3:01] used uh by by this asset across u and [3:04] what what was the solution intent of of [3:07] this uh item right so these are all the [3:09] things that we're giving it the more [3:11] context that you're able to provide it [3:12] with then you get better results [3:14] >> got it that makes sense and you know [3:16] we've been talking a bit about the role [3:18] that your team is playing by applying [3:19] Daybreak. Uh, and there's a lot more [3:22] things to consider beyond just the tech, [3:23] right? How the team actually operates [3:26] um, and you, I guess, have a [3:27] responsibility to earn the trust of the [3:28] team in using these new tools. So, what [3:30] are you learning about how to make these [3:33] AI generated findings trustworthy and [3:35] how is that changing the way that you [3:36] organize the teams that are working on [3:38] these challenges? Um yeah, I mean [3:42] just just doing a demo and showing it to [3:44] the development team is isn't good [3:46] enough, right? You need hard evidence. [3:48] So working collaboratively with with the [3:51] development team is where where I think [3:52] we're going and that's what we've been [3:54] able to do. uh is working in um in a [3:57] cross functional group with uh [3:59] application security as well as the [4:01] development team together on on trying [4:04] to you know run this because anything [4:06] that we find needs to be validated [4:08] against the code needs to be validated [4:11] against the architecture deployment and [4:13] against the environment right so in [4:16] order to do that we need to do it [4:18] together in a collaborative manner so [4:20] that's what we're trying to do [4:21] >> got it and I'm sure that many others in [4:22] the room today are facing similar [4:24] challenges is that uh security is not [4:26] just the security team's problem but [4:28] requires buyin from the entire software [4:30] engineering community inside the [4:32] organization. So are there any lessons [4:33] that you learned of like what worked [4:34] well or how did you uh win them over or [4:38] get them to start to adopt this way of [4:40] thinking into the way that they're [4:41] building products and services inside [4:42] the bank? [4:43] >> Um [4:45] it's it's not just focusing on hey we [4:47] found something right. Um it it's about [4:50] how do we kind of get better efficiency [4:54] on remediation [4:56] um and getting those uh those the right [4:59] security outcomes. So one them [5:01] understanding the root cause of why [5:02] something happened and then they may not [5:04] you know they they'll do different do it [5:06] differently next time around and won't [5:08] build their applications that way. Uh [5:11] and and the other is also just work you [5:14] know not trying to call it out trying to [5:16] work with them to remediate. So also [5:18] using the frontier AI to do the [5:20] remediation so it's not just about [5:22] another dashboard, right? [5:23] >> Yeah. And not just adding another task [5:25] to the backlog. [5:26] >> Yeah. [5:26] >> Um I think the coming back to the [5:28] defenders window for a second, you know, [5:30] there's a sense of urgency which which [5:32] we certainly feel. I'm sure that many in [5:33] this room also feel a sense of urgency [5:35] to to address the challenge in front of [5:37] us. But uh an organization like Standard [5:40] Charted uh you know is large, has [5:42] processes, has governance uh which maybe [5:45] isn't designed to move at the speed that [5:46] we're now trying to. So I'd love to know [5:49] like how are you uh building confidence [5:51] inside the organization to move at the [5:54] speed that's required uh and get those [5:56] other teams and and maybe update the [5:58] processes that need to be involved. [6:00] >> Yeah. I mean um I I think historically [6:04] like security and I think anywhere [6:07] defenders security has always been [6:08] looked as as a gatekeeper or as a [6:10] blocker. So it's just trying to change [6:12] that mindset to be more enablers. [6:15] um whatever we build and we do it's it's [6:18] integrated into the pipeline. Um and one [6:21] of the key things is to have it have the [6:25] developers have access to that earlier. [6:27] So it's like shifting left and allowing [6:29] them to have access to that earlier. So [6:30] some of the things that you spoke about [6:32] uh this morning as as early this [6:34] afternoon as it resonated is like about [6:36] having a sort of you know a virtual area [6:39] space in their development uh cycle [6:43] where they can test this out as it's as [6:45] it's running and and know for a fact [6:48] that you know this is something that's [6:49] exploitable. they see the evidence that [6:51] it's exploitable and then they um [6:54] prioritize based on exploits, right? So [6:57] then when they know that you are trying [6:59] to help them and enable them to go [7:01] faster safely, you you you build you [7:04] build that trust. [7:05] >> Yeah, I think it goes hand inhand with [7:08] kind of providing uh enabling them with [7:10] agentic coding and tools to accelerate [7:12] the work and and make sure it's not a [7:14] huge traditional burden. Um the other [7:17] thing I think you I mean having worked [7:18] in the security space for a very long [7:20] time. We were just discussing before we [7:21] came on stage um there's always been [7:23] this uh I guess race between defenders [7:27] uh and and threat actors uh and always [7:29] trying to stay ahead. Um this moment [7:31] though feels like it requires like [7:33] thinking differently. So I'm curious, [7:35] how are you thinking differently maybe [7:37] than you were five five years ago about [7:39] the security space and what do you think [7:40] other security leaders in this room [7:42] should be thinking differently uh to to [7:44] rise to the moment? [7:45] >> Actually to be quite honest a few things [7:47] that we still need to do and it's quite [7:50] evident when you um when you go through [7:52] and do this testing that we have been [7:54] doing is that you have to make sure that [7:56] you've got your found your foundations [7:58] down right. So you need to focus on your [8:00] foundations. Try to make sure that any [8:02] technical debt is reduced. Reduce any [8:05] technology complexities. Uh so not [8:08] having too many languages like reduce [8:10] that. um making sure that your [8:12] architecture is up to date because that [8:13] will make sure that'll enable you to [8:15] have the right context to provide and [8:18] have a solid identity and access control [8:21] because ultimately AI when it's released [8:23] into an environment it'll it'll it'll [8:26] amplify whatever it it sees right and [8:30] the the organizations that have the [8:32] right foundation and if it's solid [8:34] they'll be able to make the most out of [8:36] it. [8:36] >> Yeah, that that makes total sense. And [8:38] is there anything that's been surprising [8:39] as you've been on this journey over the [8:41] last kind of uh six months or so uh [8:44] adopting Genai into the security [8:45] processes? Is there anything any [8:47] learnings or lessons that kind of you [8:48] weren't expecting that you think others [8:50] might benefit from through that uh [8:52] experience? I mean uh well the the the [8:55] most part it has been about that context [8:57] and how important that is which kind of [8:59] leads you to some of the things that you [9:01] take for granted in the SDLC that you [9:04] think that development teams are doing [9:06] like keeping the architecture up to date [9:07] and stuff like that and then you find [9:08] there are gaps in that and so that that [9:11] has to get uh addressed. Um so you know [9:14] that's been a a little bit of surprise [9:16] but um not otherwise actually one of the [9:19] things that's been comforting is to know [9:20] that um you know because there's there's [9:23] this push that hey have you found [9:25] something that is uh out of the ordinary [9:28] right and there hasn't been a lot of [9:30] that you know so we it you know what we [9:32] found resonates we expect some of those [9:34] things to to be there or some of those [9:36] things to be fixed but it's um yeah it's [9:40] uh it's just that there are certain in [9:43] areas that traditional tooling did not [9:46] pick up on and that's been the the key [9:49] thing that we've been able to pick that [9:50] up with this method. [9:51] >> That makes sense. And you know, one of [9:53] the fascinating things for me about [9:55] working with Standard Chartered is that [9:56] you operate in so many markets uh around [9:58] the world, so many regulatory regimes [10:00] that apply, therefore many uh different [10:03] systems uh across the different parts of [10:05] your business. Uh that's a huge [10:07] footprint to secure. So it's not [10:08] necessarily just about scanning code [10:10] repos. Um, I'd love to get your [10:12] perspective as you kind of reflect on [10:14] the the the size and complexity of the [10:16] organization. Uh, how might you [10:19] structure your team? How are you [10:20] thinking about uh kind of building into [10:22] the future as you uh continue to build a [10:24] team that is able to respond to these [10:26] new threats? [10:27] >> Um, we yeah, we are a global [10:31] organization and um do have a lot of [10:34] different markets. uh our development [10:38] teams are pretty much concentrated in in [10:40] a few hubs. Uh that makes it a little [10:42] bit easier to to kind of uh coordinate [10:45] and collaborate with them. Um but the [10:48] way that we see ourselves in security is [10:50] is is enabling the developers with the [10:52] right tooling to be able to do it to [10:54] self-s serve and I think ultimately [10:56] that's what we need to be able to do to [10:57] self to get themselves served and um and [11:00] be able to go securely but we'll have [11:02] right checks along the way. [11:05] >> Got it. That makes total sense. And then [11:06] maybe just a final question from me [11:09] before we wrap up. Um, as as we uh [11:13] embark on uh kind of building out more [11:15] products as we uh continue to advance [11:17] the capability of Frontier models in [11:20] this space, uh I'd love to know uh what [11:23] what what would you like to see from [11:24] OpenAI uh that would make uh your work [11:27] as a defender easier? Would you take the [11:30] feedback from Matt and the team uh to to [11:32] incorporate into the product? Um I I I [11:35] think you've um you gave us a good uh [11:37] sneak peek earlier uh on where you're [11:40] going with it and that's exactly what we [11:42] were thinking as well in some of the [11:44] conversations that we've had. Uh we do [11:46] want to be able to like as you're moving [11:48] the product is to be able to run it at [11:50] scale. So just doing uh a scan on a [11:55] handful of repos or repo by repo is not [11:58] scalable. So being able to run something [12:01] in uh in a sandboxed environment and do [12:04] it at at bulk uh to to see if there are [12:06] any exploits because you the the fact of [12:09] the matter is that you have a lot of [12:10] applications that are connected to each [12:12] other. So you want to understand what is [12:13] that blast radius and you know if you if [12:15] one gets breached where else does it go. [12:17] So I think what you're thinking about [12:20] with the defense factory would would be [12:22] really good. Well, I'm looking forward [12:23] to get to getting you access uh set up [12:26] soon uh to the defense factory. Um so we [12:29] could I'm sure continue the conversation [12:31] all day, but uh I'm watching the clock [12:33] and our our time is up. So thank you so [12:35] much uh for joining us today, Reuben. Uh [12:37] and I'm sure that Reuben will be [12:38] delighted to to answer any questions if [12:40] you if you want to find him uh after the [12:42] sessions today. Uh we'll be having some [12:44] drinks afterwards. So please do come [12:45] find him and ask questions. But with [12:47] that, right now we're moving straight on [12:49] to our next session. Uh so please [12:51] welcome my colleague Claire Lawler who's [12:53] our fantastic account director for the [12:55] digital natives uh team in AMIA to the [12:57] stage. Thank you.