A janela dos defensores: palestra sobre cibersegurança

Ver no idioma original →

Autoria: OpenAI · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: The Defender’s Window: Cyber security keynote · Canal: OpenAI · 47:01 · Assistir no YouTube

Tópicos: Agentes de IA, Cibersegurança e segurança de software, Governança e regulação de IA, Open source e ecossistemas de software

Resumo

A palestra apresenta a “janela dos defensores”: o período em que organizações podem usar modelos de IA avançados para encontrar e corrigir vulnerabilidades antes que invasores explorem essas falhas. A OpenAI descreve seus modelos e programas de acesso, além de iniciativas para apoiar a defesa de infraestruturas críticas e projetos open source. Os palestrantes mostram fluxos de trabalho para identificar, validar e corrigir vulnerabilidades, com agentes, ferramentas de desenvolvimento e ambientes isolados. A mensagem central é que a defesa contínua exige colaboração entre empresas, governos, pesquisadores, mantenedores e equipes de segurança, e que as organizações devem começar a agir agora.

Pontos-chave

• A “janela dos defensores” é uma oportunidade temporária para usar modelos avançados na defesa antes que capacidades semelhantes se disseminem.
• Encontrar vulnerabilidades não basta: é necessário validar os achados, encaminhá-los às equipes responsáveis e confirmar que as correções funcionam.
• A OpenAI apresenta a defense factory como uma abordagem para integrar agentes, skills, ambientes de desenvolvimento e fluxos de segurança em uma defesa contínua.
• Daybreak oferece níveis de acesso a modelos para atividades autorizadas de segurança, incluindo trabalho defensivo e testes de red team.
• O Codex Security pode analisar repositórios, incorporar contexto específico, propor patches e apoiar a revisão e a abertura de PRs.
• A execução em ambientes isolados, com controles de rede e monitoramento, ajuda a supervisionar agentes com capacidades avançadas.
• A iniciativa Patch the Planet apoia a segurança de projetos open source em colaboração com pesquisadores e mantenedores.
• A palestra defende uma resposta conjunta de empresas, governos, parceiros tecnológicos, pesquisadores e comunidades de software.

Capítulos

Início	Capítulo	Resumo
00:05	Abertura e contexto sobre IA	Emanuel Mariel apresenta a agenda e descreve o crescimento das capacidades de IA e seu uso por empresas.
03:10	A janela dos defensores e a resposta coletiva	A palestra enquadra a diferença entre as capacidades dos modelos e a necessidade de mobilizar empresas, governos e parceiros.
08:27	A defesa contínua e a defense factory	Matt explica como a OpenAI reuniu equipes para fortalecer suas defesas e criar um modelo de trabalho baseado em agentes.
14:08	Capacidades e avaliação dos modelos	Lee apresenta os modelos de cibersegurança, uma avaliação de exploração de vulnerabilidades e exemplos de achados validados.
17:46	Salvaguardas e níveis de acesso Daybreak	A apresentação aborda medidas para reduzir o uso indevido e descreve os níveis de acesso voltados a equipes de segurança.
23:38	Demonstração de análise e correção de código	Vanessa demonstra como analisar um repositório, fornecer contexto, validar um achado e gerar um patch com o Codex Security.
32:57	Escala com CLI e SDK	A demonstração mostra como usar CLI e SDK para executar análises em vários repositórios e integrar verificações a CI.
35:01	A defense factory interna da OpenAI	Lou descreve a equipe multifuncional, os ambientes isolados e os processos de validação e encaminhamento de vulnerabilidades.
42:23	Operacionalização e próximos passos	A OpenAI explica que está transformando a arquitetura interna em produtos e recomenda que as equipes comecem a experimentar as ferramentas disponíveis.
45:28	Colaboração para proteger sistemas	Matt retoma a defense factory e conclui defendendo ação imediata e colaboração entre equipes, pesquisadores, parceiros e mantenedores.

Citações

A janela dos defensores é essa diferença entre as capacidades maiores dos modelos que estamos lançando e os modelos de pesos abertos que avançam rapidamente. — 03:43

Precisamos transformar os achados em correções. É das correções que precisamos, não dos achados. — 11:33

A janela dos defensores está aberta. Não ficará aberta por muito tempo, mas está aberta agora, e precisamos aproveitá-la. — 13:37

Não esperem por nós. Todas as peças estão aqui. — 43:25

Conceitos e entidades

• defenders window (conceito): Período em que defensores podem aproveitar modelos avançados para encontrar e corrigir falhas antes que as capacidades de ataque se ampliem.
• defense factory (conceito): Abordagem de defesa contínua que combina agentes, modelos, ambientes isolados e fluxos de trabalho de segurança.
• continuous defense (conceito): Processo contínuo de descoberta, validação, encaminhamento e correção de vulnerabilidades.
• Daybreak (ferramenta): Programa que oferece acesso a modelos para atividades autorizadas de cibersegurança, com níveis voltados a diferentes necessidades.
• Codex Security (ferramenta): Ferramenta apresentada para investigar vulnerabilidades em código, propor correções e apoiar fluxos de remediação.
• Patch the Planet (conceito): Iniciativa da OpenAI e da Trail of Bits para ajudar a proteger projetos open source amplamente utilizados.
• Exploit Gym (conceito): Avaliação que mede se um modelo consegue transformar vulnerabilidades conhecidas em exploits funcionais.
• OpenAI (empresa): Empresa que organizou a palestra e apresentou seus modelos, programas e práticas de cibersegurança.
• Trail of Bits (empresa): Empresa parceira da iniciativa Patch the Planet para apoiar a segurança de projetos open source.
• GPT-6 Astra (modelo): Modelo apresentado na palestra como um avanço em tarefas profissionais, engenharia de software e cibersegurança.

Tradução completa (pt-BR)

00:05 Boas-vindas a todos. Bem, estamos aqui juntos nesta tarde. Meu nome é Emanuel Mariel. Sou gerente-geral para Europa, Oriente e África. Vou fazer uma breve introdução, por alguns minutos, e depois passar a palavra ao restante da equipe. Temos uma agenda bem cheia. Logo depois, teremos uma sessão de uma hora. Em seguida, teremos algumas conversas informais, muito interessantes. E então vou encerrar. Mas, basicamente, o propósito de hoje é entender as

00:35 mudanças que estão por vir, aprender uns com os outros e garantir que aproveitemos ao máximo todo o conhecimento que temos nesta sala. Estamos em um momento muito interessante. É quase um privilégio. Vemos essas capacidades de IA crescendo. Quer dizer, acabamos de ver o problema matemático de Navier-Stokes ser resolvido algumas semanas atrás. Lançamos o GPT6 Astra, que é um dos modelos mais capazes

01:07 que já lançamos. Desculpem, o modelo mais capaz que já lançamos. E, quando olhamos para esses números, vemos que, além do progresso científico que estamos fazendo, as empresas estão usando cada vez mais a nossa tecnologia, a tecnologia de IA. Há 26% mais usuários ativos semanais usando o Codex para fins de marketing. No setor jurídico, 108%, 108 vezes mais. Vemos isso em toda parte. Estive em Berlim na terça-feira e passei algum tempo com

01:37 uma empresa de médio porte chamada Stadler. Ela tem 650 funcionários e relatou que, com seus 145 agents trabalhando junto aos 650 funcionários, conseguiu obter ganhos de eficiência de 30% a 40%. As empresas estão aproveitando e se beneficiando dessas capacidades. Pequenas e médias empresas, grandes corporações, em todos os setores. Mais de 1 bilhão de pessoas usam o GPT semanalmente, como usuários ativos semanais.

02:09 Mas, com o crescimento dessas capacidades, também surge a grande questão que todos temos: a confiança. No fim das contas, tudo se resume à confiança. A segurança sempre esteve no centro das prioridades da OpenAI. Com os incidentes recentes, demos ainda mais ênfase a

02:40 questões de segurança. Por exemplo, aumentamos significativamente a equipe de segurança. Estamos investindo muito em computação para segurança. No início de agosto, suspendemos por algumas semanas os treinamentos mais recentes que estávamos realizando. E, no fim das contas, temos hoje o Astra, o modelo mais alinhado que já lançamos. A segurança é um elemento essencial, essencial — desculpem — da confiança. Para nós, na OpenAI, a segurança dos

03:10 modelos é uma parte disso; e, quando digo “nós”, incluo a nós mesmos. Para todos nesta sala, também há a segurança no mundo exterior, a cibersegurança. E é por isso que estamos aqui hoje. A confiança não se limita aos modelos; ela também depende do que fazemos como equipe e como ecossistema nessa área de segurança. Viajei bastante nas últimas duas semanas, encontrando muitos clientes. Há seis meses, as conversas não eram sobre cibersegurança. Há seis dias, todo mundo

03:43 começou as conversas falando de preocupações com cibersegurança. Todo mundo. Então, junto com o incrível impulso que vemos na IA em todo o mundo, também percebemos ameaças emergentes. E o que chamamos de janela dos defensores é essa lacuna que vemos entre as capacidades crescentes dos modelos que estamos lançando e o que vem dos

04:13 modelos de pesos abertos que estão avançando rapidamente. Essa janela é o momento que temos para agir, para que os defensores — todos vocês — possam aproveitar as melhores capacidades enquanto isso. Esses modelos de pesos abertos não estão tão atrás, e sabemos disso. É por isso que estamos aqui e também por que é muito raro: quando convidamos 150 pessoas, normalmente não aparecem 150 pessoas,

04:43 mas hoje todos vieram. Acho que há uma preocupação, e todos percebem que isso exige o esforço de todo o ecossistema. Não será um evento só da OpenAI. Não será apenas um evento do governo. É um esforço de todo o ecossistema. Por isso, publicamos esta carta algumas semanas atrás. Sim, há telas nas laterais. Desculpem se vocês não conseguem ver daqui. Só queria garantir que soubessem: há telas nas laterais. É um esforço de todo o ecossistema. Temos 100 pessoas, 100 empresas. A maioria das empresas

05:14 que estão na sala hoje também está neste gráfico; elas assinaram a carta. A carta diz, basicamente, que precisamos nos unir como um grupo, como um ecossistema, para resolver esse problema, certo? E todos temos um papel a desempenhar. Isso começa com vocês, líderes das empresas: é preciso garantir que esse tema da cibersegurança se torne a prioridade número um da empresa. E acho que estamos começando a ver isso. Estive nos Estados Unidos algumas semanas atrás e lá já era a prioridade número um

05:46 e, na Europa, sinto que estamos um pouco atrasados, mas ainda estamos correndo para alcançar os demais. Mas, claramente, essa é a primeira coisa: precisa vir de cima e ser a prioridade número um na agenda das empresas. Depois, precisamos de parceiros de tecnologia — Darktrace, Check Point, obrigado por estarem aqui hoje, aliás. Precisamos de vocês, das suas capacidades, do seu conhecimento e das suas equipes para conectar os modelos que temos às organizações e às empresas, para que possamos implementá-los e agir a tempo. É uma questão de timing. Precisamos agir rápido.

06:21 Depois, vêm os governos. Os governos são muito importantes porque são realmente os facilitadores, os aceleradores desta iniciativa. Acabamos de anunciar ontem que vamos trabalhar com a Ucrânia e ajudar na defesa cibernética. Ela teve que enfrentar 6.000 ataques no último ano, e nossos modelos vão ajudá-la a se defender. Mas não só na Ucrânia, também na Europa. A agência de cibersegurança da UE, a ENISA, informou há três semanas

06:51 — ou há duas semanas. Tudo aconteceu nas últimas semanas, basicamente. Fico repetindo “semanas”: na semana passada, há duas semanas, há três semanas. Agora, a Ana informou que estavam usando nosso modelo para encontrar vulnerabilidades. Encontraram várias vulnerabilidades que não esperavam, com o nosso modelo, aliás, em pequena escala. E depois vem a nossa parte. “Nós” quer dizer OpenAI. Queremos mesmo garantir que toda infraestrutura crítica

07:23 possa se beneficiar desta tecnologia. Não é uma questão de dinheiro. Não deveria ser uma questão de dinheiro. Todos, seja um hospital ou uma empresa de serviços públicos, deveriam poder se defender. Deveriam poder usar nossa tecnologia, nossos modelos de cibersegurança, para se defender com nossas capacidades de acesso confiável. É claro que foi por isso que, mais uma vez, há duas semanas, lançamos esse fundo de US$ 1 bilhão, para incentivar e

07:56 garantir que o dinheiro não fosse o problema, certo? E o que vemos hoje é que, quando unimos todos nós — os líderes, os parceiros de tecnologia, os governos e as nossas capacidades, a nossa tecnologia —, temos uma ótima oportunidade de aproveitar a janela dos defensores. Falando nisso, e sobre a janela dos defensores, provavelmente sou a pessoa menos indicada para falar sobre isso quando temos Matt aqui, que está vindo ao palco

08:27 para nos contar mais sobre o assunto. Só queria agradecer muito a vocês. Vocês vão me ver de novo no final. Muito obrigado pela atenção e tenham uma ótima tarde. Obrigado. >> Olá a todos, e obrigado por estarem aqui hoje. Sou Matt. Sou o chefe de engenharia de cibersegurança da OpenAI e hoje vou falar um pouco sobre como colocar em prática as capacidades dos modelos de cibersegurança. Alguém sabe o que é isto? A Barreira do Tâmisa. Obrigado. Então, isto

09:00 provavelmente não era algo em que vocês estavam pensando ao vir para esta conferência hoje. Mas, há mais de 40 anos, ela ajuda a proteger o centro de Londres contra inundações provocadas pelas marés. São enormes comportas de aço que podem se fechar atravessando o rio. Essa proteção nos permitiu ir trabalhar, manter os serviços públicos seguros e nos reunir em salas como esta. Não pensamos nisso porque alguém se responsabiliza por ela. Mas muitos de vocês sabem exatamente como é isso. Vocês protegem sistemas dos quais as sociedades dependem: hospitais, redes de transporte, fornecimento de energia, e todas as nossas

09:30 empresas dependem dessa infraestrutura digital. À medida que essa dependência cresce, a cibersegurança se torna mais importante. E agora a IA está mudando o que é possível. Essa mesma sensação, esse peso, ficou muito claro para a OpenAI muito recentemente. Neste verão, ficou muito claro o que estava por vir. Nossos modelos de fronteira estavam encontrando falhas que passaram despercebidas. Modelos amplamente disponíveis também estavam se tornando mais capazes. Então, neste momento, acreditamos que os defensores estão um passo à frente.

10:00 Podemos usar esses modelos para corrigir vulnerabilidades antes que os invasores as explorem. Então, precisamos agir internamente na OpenAI. O que fizemos foi reunir nossa equipe de segurança, nossa equipe de engenharia aplicada e também nossa equipe de pesquisa. Juntamos todos, e o objetivo era simplesmente fortalecer nossas próprias defesas. Não sabíamos exatamente como faríamos isso, mas sabíamos que precisávamos fazê-lo. Esse esforço se tornou o ponto de partida de algo que chamamos de fábrica de defesa. Os modelos deram capacidades aos agents. As skills deram a eles workflows repetíveis. E os ambientes de desenvolvimento

10:32 permitiram que eles executassem software para podermos testar e validar essas mudanças. Os agents precisam do próprio ambiente. Precisam investigar vulnerabilidades. Precisam testar correções. E nossa ambição é avançar rumo à defesa contínua. Lou vai contar um pouco mais sobre nossa própria fábrica de defesa daqui a pouco, nesta sessão. Agora estamos vendo modelos descobrirem vulnerabilidades que ficaram ocultas por décadas. Nossos modelos ajudaram a identificar uma falha de 23 anos no OpenBSD. Na Polônia, nossos modelos cibernéticos encontraram

11:03 vulnerabilidades no MicroTalk que afetam versões lançadas desde 2013. Muitas pessoas nesta sala usam sistemas muito mais antigos que 23 anos. E ainda há uma quantidade enorme de coisas que precisamos descobrir, e prevemos que provavelmente encontraremos mais à medida que nos aprofundarmos nisso. Mas o mais importante é que encontrar coisas não é muito interessante por si só. Já temos muitas ferramentas que apresentam descobertas há bastante tempo, e isso desencadeia todo um outro processo, no qual é preciso validar: está realmente correto? É uma duplicata? Já estamos acompanhando isso? O risco já foi aceito? Precisamos transformá-las em

11:33 correções. O que queremos são correções, não descobertas, para proteger nossas instituições. Essa é a lacuna que precisamos fechar, e também precisamos verificar se a correção funciona. E precisamos fazer isso rápido. As mesmas capacidades que nos permitiram encontrar essas vulnerabilidades também facilitam para os invasores explorá-las. Não podemos presumir que continuaremos na dianteira, mas sabemos que estamos à frente por enquanto. Uma coisa de que me orgulho muito é que isso também se tornou uma prioridade nacional. Então, é algo que o governo está analisando. Temos a iniciativa Cyber Shield, que busca usar agents para

12:05 encontrar vulnerabilidades, avançando rumo à correção automatizada em infraestruturas críticas. Dá para pensar nisso como uma fábrica de defesa nacional, certo? Outros governos ao redor do mundo também estão analisando isso. Temos muito orgulho de que o governo do Reino Unido esteja fazendo isso. Acreditamos que toda organização precisa ter sua própria fábrica de defesa. Mas também sabemos que a OpenAI tem uma vantagem que a maioria das organizações não tem. Temos equipes de segurança dedicadas. Temos profundo conhecimento técnico e acesso à IA de ponta.

12:36 Governos, empresas de serviços públicos e projetos de software open source. É muito incomum que eles tenham o mesmo acesso que nós. E o que precisamos realmente assimilar é que a segurança deles é a nossa segurança. Por isso publicamos esta carta aberta. 500 organizações a assinaram e pediram uma resposta coletiva. Precisamos colocar IA capaz nas mãos dos defensores que não necessariamente têm recursos para fazer isso sozinhos. Além disso, anunciamos o fundo de um bilhão de dólares de que falamos há pouco,

13:07 mas esse fundo subsidia o acesso ao Daybreak e ajuda defensores de infraestruturas críticas, serviços essenciais, organizações sem fins lucrativos e projetos de software open source a corrigir vulnerabilidades graves. Isso dá aos defensores uma vantagem inicial. Mas precisamos juntar todas essas partes. Nossos modelos de ponta fornecem a capacidade. Nosso programa Daybreak dá acesso aos defensores elegíveis. E o Codex Security coloca essas capacidades em prática em testes defensivos e ofensivos autorizados. A fábrica de defesa é uma estrutura para reunir essas partes em uma

13:37 defesa contínua. Vamos apresentá-las hoje e, no fim, voltaremos a este mapa. Mas, em última análise, é disso que trata o evento de hoje. Queremos compartilhar o que os modelos de ponta podem fazer. Queremos mostrar como colocá-los em prática e como incluí-los nas suas próprias operações. E queremos analisar nossa abordagem de pesquisa para mostrar também como criaremos sistemas mais seguros no futuro. A janela dos defensores está aberta. Não ficará aberta por muito tempo, mas está aberta agora, e precisamos aproveitá-la. Vou passar a palavra para Lena, que

14:08 vai subir ao palco e mostrar um pouco mais do que nossos modelos de ponta são capazes de fazer. Meu nome é Lee, e lidero nosso programa cibernético de entrada no mercado em toda a região EMEA. Passei os últimos seis meses trabalhando com as maiores e mais críticas organizações da Europa para melhorar suas capacidades defensivas. Hoje vou mostrar como criamos os melhores e mais seguros modelos de cibersegurança e como podemos disponibilizá-los para

14:39 vocês. No início do mês, lançamos o GPT-6 Astra, nosso modelo mais inteligente até agora. É um grande avanço para tarefas do dia a dia, incluindo engenharia de software e trabalho profissional, e é particularmente bom no uso de computadores. Isso significa que você pode delegar muitas tarefas administrativas que normalmente faria por conta própria e deixar o modelo executá-las no seu computador. Mas também representa um grande salto em cibersegurança. Nós o treinamos para encontrar mais vulnerabilidades, incluindo zero-days,

15:10 e investigar problemas de segurança com mais profundidade, tornando-o um red teamer mais capaz. Mas capacidade é apenas parte da história. Também precisamos continuar tornando essa inteligência mais econômica, para que as pessoas possam usá-la em grande escala. Para ver nosso progresso nessas duas frentes, usamos várias avaliações. Uma das formas de medir isso é com o Exploit Gym. Ele testa se um modelo consegue transformar uma vulnerabilidade de software conhecida em um exploit funcional em diferentes aplicações. O mecanismo JavaScript do Chrome

15:42 e o kernel do Linux. Para pontuar, o modelo precisa fazer o exploit funcionar. Apenas provocar uma falha não basta. Na parte inferior, você pode ver o número de tokens de saída usados. E, no eixo lateral, a porcentagem de desafios concluídos com sucesso. Neste gráfico, você pode ver o resultado do GPT-5.6, que chegou a cerca de 30% de conclusão. Já o Astra chegou a cerca de 40% mais conclusões bem-sucedidas, mas usou muito menos tokens para isso. E esse é o progresso

16:14 que queremos destacar: realizar mais dessas tarefas difíceis usando muito menos tokens de saída. Para os defensores, isso abre a possibilidade de fazer testes de segurança mais completos com os recursos de que dispõem. Então, como isso se traduz na prática? Em colaboração com nossos pesquisadores, nossos modelos ajudaram a descobrir duas vulnerabilidades antes desconhecidas no mecanismo JavaScript do Chrome e a conectá-las em uma cadeia de exploits. Uma falha permitia corrupção de memória, e uma segunda fazia com que essa

16:44 corrupção ultrapassasse outra camada de proteção. A parte difícil foi entender como essas vulnerabilidades funcionavam em conjunto. Nossos pesquisadores validaram essas descobertas e as relataram ao Google, que então lançou uma correção. Este é apenas um exemplo concreto de como essas ferramentas já estão ajudando a tornar muito mais seguro o software que usamos todos os dias. E estamos levando esse trabalho além de exemplos individuais. Patch the Planet é nossa iniciativa com a Trail of Bits para ajudar a proteger software open source amplamente utilizado, incluindo projetos como Python,

17:15 curl e Go. Financiamos pesquisadores especialistas em segurança e damos a eles acesso aos nossos modelos e ao Codex Security. Eles trabalham diretamente com os mantenedores para investigar as descobertas, desenvolver e testar patches e coordenar a divulgação. Só na primeira semana, 37 patches foram integrados. Em um desses projetos, o AIOHTTP, os mantenedores corrigiram oito problemas relatados em poucas horas. É um progresso real para essas pequenas equipes que mantêm o software de que

17:46 todos dependemos. Mas as mesmas capacidades que ajudam os defensores também podem ser usadas indevidamente. À medida que os modelos se tornam mais capazes, nossas salvaguardas precisam avançar junto com eles. E o Astra é nosso primeiro modelo a atingir o limiar de criticidade cibernética, o que cria oportunidades reais para os defensores e uma responsabilidade de gerenciar os riscos com cuidado. Como Sam já disse, não devemos assumir riscos em nome da humanidade. As pessoas precisam continuar no controle. E, para fazer isso com nossos modelos cibernéticos, usamos várias camadas de proteção, incluindo

18:18 treinando os modelos para recusarem solicitações prejudiciais, detectando e bloqueando abusos e monitorando comportamentos perigosos. Juntas, essas medidas nos ajudam a colocar ferramentas poderosas nas mãos dos defensores, dificultando seu uso indevido. E, com Astra, reforçamos essas camadas com uma detecção melhor de uso indevido para fins cibernéticos e de tentativas de contornar as proteções. Também incluímos restrições mais rigorosas para contas de maior risco e monitores que examinam o raciocínio e as ações do modelo. Isso nos ajuda a identificar quando um modelo vai

18:49 além das instruções e nos permite intervir. E essa responsabilidade se estende ao que vamos construir a seguir. A segurança precisa estar à frente da capacidade. Por isso, já pausamos anteriormente o treinamento de modelos de fronteira enquanto intensificamos a pesquisa em monitoramento e alinhamento. Precisamos atingir os limites de segurança exigidos antes de avançar ainda mais as capacidades. Mas, além dessas proteções, Astra é nosso modelo mais alinhado até agora. Veja uma maneira de testarmos isso. Damos ao modelo uma tarefa difícil que inclui um

19:19 alvo fora do escopo que o modelo poderia explorar como atalho. Sem essas proteções de produção, Soul explorou esse alvo com sucesso em cerca de 48% dos casos. Mas, com Astra, não vimos nenhuma exploração bem-sucedida desse alvo nesse teste. Isso é importante porque queremos que os modelos respeitem os limites que definimos, mesmo quando a tarefa fica realmente difícil, e é um avanço significativo para garantir que possamos delegar trabalhos mais complexos com mais confiança, mantendo as pessoas no controle.

19:50 Agora, quero falar sobre como realmente desenvolvemos essas capacidades. Começamos com as habilidades de programação e raciocínio dos nossos modelos de fronteira e, em seguida, acrescentamos treinamento especializado em cibersegurança, incluindo a compreensão de vulnerabilidades, o desenvolvimento de exploits funcionais e a verificação dos resultados. Disponibilizamos essas capacidades em dois níveis do Daybreak: Red e Blue. Daybreak Red é nosso nível mais alto de acesso cibernético e dá a equipes de segurança aprovadas acesso a esses modelos especializados para red teaming avançado e desenvolvimento de exploits armamentizados.

20:22 Pense em pegar uma falha e transformá-la em um exploit funcional, ou combinar pontos fracos para ver até onde um atacante poderia chegar. Mas dar a um agent esse nível de capacidade também significa que precisamos deixar claros os limites. Precisamos incluir informações sobre o que ele tem permissão para testar, a que pode ter acesso e também permitir que sua equipe veja o que ele está fazendo. Hoje, as equipes muitas vezes precisam construir toda essa infraestrutura de apoio por conta própria: o ambiente de execução, os controles de rede, o monitoramento e a coleta de evidências. E

20:52 isso tira tempo do trabalho de segurança. Por isso, hoje estamos anunciando o Codex Security Red, uma maneira gerenciada de realizar testes de penetração nas suas aplicações, com todo o escopo, os controles e a supervisão integrados diretamente ao workflow. Veja como vai funcionar. Você começa no Codex e define o escopo da avaliação e as regras de engajamento. Em seguida, os agents de investigação são executados em um ambiente hospedado pela OpenAI, cada um em seu próprio sandbox isolado.

21:22 Sua equipe acompanha a atividade deles pelo painel, onde as descobertas e as evidências de apoio podem ser reunidas para análise. Quando esses agents interagem com sua própria aplicação, as solicitações de saída passam por controles de rede, com um agent guardião analisando o tráfego. Isso nos permite conectar a investigação ao seu ambiente, controlando a que os agents podem ter acesso e o que podem fazer. Assim, você pode testar o que um atacante realmente conseguiria fazer, mantendo visibilidade e controle total sobre toda a avaliação.

21:55 Para sua equipe, isso significa começar com menos infraestrutura para construir e manter. Estamos reunindo o ambiente de execução, o monitoramento e as descobertas em uma única visualização, para que você possa dedicar mais tempo a investigar essas fragilidades e corrigi-las. Isso também incorpora proteções ao workflow, com ambientes isolados e verificações das solicitações de saída que ajudam a gerenciar os riscos de usar modelos tão capazes. Também dá à sua equipe mais capacidade para testar aplicações e investigar possíveis caminhos de ataque. O objetivo é

22:27 facilitar a realização de avaliações completas e repetíveis com a equipe que você já tem. Por fim, isso oferece os controles necessários para você se sentir confiante ao executar o modelo. Você pode definir o escopo do que o modelo pode acessar e bloquear e restringir atividades no nível da rede. E, para a maioria dos defensores, o ponto de partida é Daybreak Blue. Ele oferece nossos modelos gerais de fronteira com proteções adaptadas para permitir trabalhos de segurança autorizados. Por exemplo, revisar código, investigar alertas, encontrar

22:58 vulnerabilidades e criar correções. Isso ajuda suas equipes a encontrar novos problemas e a lidar com o backlog de vulnerabilidades. Inclui GPT6 Soul e agora também Luna; em breve, incluirá GPT6 Astra, trazendo nossas capacidades mais recentes para o trabalho defensivo do dia a dia e dando a você a opção de escolher o tamanho de modelo mais adequado para a tarefa. Agora, vamos ver outro workflow prático. Vanessa, uma de nossas engenheiras de implementação em cibersegurança, vai mostrar como o Codex Security investiga uma descoberta e, em seguida, propõe uma correção. Vanessa.

23:38 >> Olá a todos. É incrível ver pessoalmente algumas pessoas que encontrei pelo Zoom em San Francisco, talvez quando vocês estavam numa chamada tarde da noite e eu, numa chamada de manhã cedo. É fantástico estar aqui hoje. Também é legal ser a única americana falando hoje. Então, isso é um pouco diferente. Hoje, vamos percorrer um workflow prático de como usar o Codex Security pelo plugin local. Vou mostrar um pouco como vocês podem usar isso pelo Daybreak

24:10 e como podemos começar a abordar a segurança de software usando também o plugin e a CLI, além de mostrar como são esses workflows de ponta a ponta para um engenheiro de segurança típico que está começando a usar o Codex para trabalhos de segurança. O que vocês estão vendo agora é o Codex, o aplicativo para desktop. Baixamos uma versão local do Ladybird. É um navegador open source pré-alfa que está em alta no GitHub há algum tempo. Também fizemos uma parceria com eles por meio do Patch the Planet como parte disso. Então,

24:41 quando recebemos a permissão deles para fazer esta demonstração, eles passaram a trabalhar com o Patch the Planet para também reforçar a segurança do projeto. Hoje, vamos acessar a seção de segurança do Codex. Como podem ver, ela está vazia. Vamos imaginar que estamos iniciando nosso primeiro conjunto de verificações para repos que nos pertencem. Vamos dar uma olhada em como é essa configuração. Há duas opções aqui. Uma é avaliar toda a base de código. A segunda é também analisar alterações. Isso pode ser um PR

25:12 ou alterações não commitadas, ou até mesmo uma revisão específica. Mas hoje vamos fazer uma verificação completa. O motivo é que, normalmente, queremos executar uma verificação de segurança completa no repo na primeira vez que o inicializamos, para identificar vulnerabilidades novas na base de código que talvez tenham passado despercebidas pelas ferramentas de segurança existentes. Quero chamar a atenção para algumas coisas realmente importantes aqui. Uma delas é nossa recomendação de usar raciocínio alto ou extra alto para essa verificação inicial.

25:43 De modo geral, você deve usar o modelo de fronteira mais avançado disponível. Neste caso, podemos usar Soul ou até mesmo Astra. O que queremos fazer aqui é iniciar uma verificação, novamente usando raciocínio alto ou extra alto com um modelo de fronteira. O que quero destacar é o contexto. Essa é a diferença entre as ferramentas de segurança existentes nesse espaço e o que um modelo de raciocínio oferece por trás dos panos: a capacidade de fornecer contexto ao scanner e ao modelo para que ele entenda

26:15 o que precisa procurar no seu ambiente. Neste exemplo, vamos analisar os vetores de ataque. Vamos indicar áreas para o modelo focar e também fornecer contexto adicional de segurança. Eu pensaria nisso também como o contexto empresarial que você gostaria que o modelo conhecesse. Isso pode incluir desde controles compensatórios até uma lógica de negócios específica que você esteja considerando, ou mesmo coisas como a forma como você define fraude. Tudo isso pode ser incluído como contexto na verificação. Então, vamos começar iniciando-a. E

26:46 Você pode ver que o Codex agora está executando uma varredura completa. O que ele faz nos bastidores é inicializar um modelo de ameaças do repo. Neste caso, ele analisou 28.000 arquivos, identificou ameaças e gerou um modelo de ameaças. Em seguida, apresentou vulnerabilidades candidatas e as validou para, por fim, apresentar este relatório. Vamos dar uma olhada. No momento, há uma vulnerabilidade de cache compartilhado de JavaScript por meio do Code Cache. Temos um resumo aqui e podemos ver o caminho exato da tag

27:17 com base nos arquivos que o Codex determinou serem vulneráveis; depois, ele validou a vulnerabilidade real. Certo? Então, passamos de “isso pode ser uma vulnerabilidade” para “certo, validamos isso no código-fonte e acreditamos que é um verdadeiro positivo”. E aqui podemos ver o impacto: alto impacto e alta probabilidade. Mais uma vez, esses resultados são determinados pelo contexto que você forneceu. Então, quando pensamos no contexto adicional que incluímos na varredura ou no contexto que você quer

27:48 fornecer por meio de outros arquivos, isso pode ajudar a informar o impacto da vulnerabilidade. Mas, dando um passo atrás, não estamos interessados apenas em apresentar vulnerabilidades. Sei que muitos de nós que trabalhamos com segurança já atuamos como profissionais da área — eu atuo há muitos e muitos anos. Não estamos interessados apenas em receber uma lista bruta de vulnerabilidades. Nosso objetivo é, em última análise, corrigir os problemas e reduzir os riscos. Então, o que queremos fazer é gerar um patch. Quero fazer uma pausa aqui por um segundo. O motivo

28:19 pelo qual isso é tão poderoso é que o Codex e o Codex Security são uma extensão dos agents de desenvolvimento de software que lançamos como parte dos recursos de engenharia de software. E parte disso consiste em usar os recursos de engenharia de software desses modelos para ajudar a determinar não apenas quais são as vulnerabilidades, mas também quais patches são eficazes. Neste caso, podemos gerar um patch. Você pode ver que, nos bastidores, ele está invocando a skill de correção de achados, que faz parte do plug-in e também

28:50 da nossa CLI. Agora temos um patch aqui. Podemos revisá-lo e ver exatamente o que foi afetado e qual código precisa ser corrigido. Podemos aplicar esse patch localmente no repo e, em seguida, verificar a correção para garantir que a vulnerabilidade não esteja mais presente. Essa é uma parte do processo. Mas, ao pensar em como orientar essas varreduras e nas vulnerabilidades mais amplas que encontramos na base de código, a maneira de fazer

29:21 isso é por meio de um arquivo security.md. Eu pensaria nele, fundamentalmente, como um agents.md, mas voltado à segurança: ele fornece contexto no nível do repo sobre o que mais preocupa você. Neste exemplo, há uma skill que você pode invocar com facilidade. Mas você também pode fornecer seu próprio contexto aqui. Isso ajuda a orientar o agent, durante as varreduras, sobre o que você considera mais importante, quais podem ser os ataques de ameaça e como você define limites de confiança

29:52 ou lógica de negócios. Portanto, esse é um componente central de como queremos redefinir o que significa segurança, fornecendo contexto ao agent. Aqui, já revisamos isso e está tudo certo. O que queremos fazer é incluir isso em um commit no repo. Agora temos um repo no Ladybird que foi varrido. Ele tem um arquivo security.md incluído em um commit para execuções futuras. Mas isso não resolve o problema mais amplo de como corrigir vulnerabilidades em maior escala

30:23 nem de como interagir com as ferramentas e os sistemas existentes. É aqui que queremos aproveitar a extensibilidade do Codex. Fazemos isso pedindo ao Codex que use os resultados da varredura e subagents para gerar patches para os achados, agrupá-los e, em seguida, abrir tickets no Jira, abrir PRs em nosso nome para revisão e notificar os engenheiros relevantes no Slack. É realmente

30:54 interessante, porque parte do que estamos vendo é a capacidade de se comunicar e interagir com outras partes interessadas da organização. Muitas vezes, uma pessoa pode ser responsável por executar a varredura, enquanto outra é responsável por fazer a triagem. O que vemos aqui são workflows ampliados para ajudar você a se comunicar com outros engenheiros e realizar o trabalho. Aqui, estamos seguindo um fluxo semelhante ao que vimos antes, quando percorremos um workflow de correção de ponta a ponta, só que, neste exemplo, iniciamos sub

31:25 agents. Esses subagents seguem exatamente o mesmo fluxo. Eles analisam o código, identificam a vulnerabilidade, geram um patch e, em seguida, vão validá-lo. Agora podemos ver que o Codex está abrindo tickets no Jira e PRs no GitHub. Assim, temos tickets e PRs abertos, e podemos ver que alguém foi notificado de que há um ticket para revisar referente a um achado de uma varredura de segurança do Codex. Se

31:56 entrarmos nesta varredura, veremos um ticket para alguém revisar e um PR em rascunho. O Codex gerou isso para um engenheiro revisar. Podemos, como fizemos antes, examinar no Codex o código afetado e a correção recomendada. Podemos verificar se isso funciona e se não há efeitos posteriores. Também podemos ajustar isso especificamente para o pipeline de CI de vocês, para garantir que não haja alterações incompatíveis. Basicamente, garantindo que vocês

32:27 saibam que todas as verificações estão aprovadas e que nenhum teste de CI está falhando ao abrir esses PRs, para facilitar o trabalho do engenheiro e permitir que ele se concentre no próprio código. Podemos simplesmente dizer: “Está pronto para revisão, parece bom para mim”, e então fazer o merge deste PR. Essa é uma das maneiras de ampliar e aprimorar esses workflows. Não é a única. Nos últimos seis meses, conversei pessoalmente com mil clientes, e uma grande

32:57 parte disso é pensar em escala. É muito, muito fácil fazer isso em um repo com sete vulnerabilidades, mas como fazer quando você tem 10.000 repos? A solução para isso é a CLI e o SDK. O que vocês viram no plug-in do Codex são skills diferentes, skills combináveis que desenvolvemos depois de conversar com muitas equipes e observar seus próprios workflows. Pegamos a experiência local dessas skills no plug-in de segurança do Codex e as disponibilizamos em uma CLI

33:29 que permite executar testes de forma mais programática. Aqui, vocês podem ver que é possível executar uma varredura em massa, definir quantos workers serão iniciados para essa varredura e passar um arquivo repositories.csv com vários repos do GitHub ou de outros sistemas de controle de código-fonte que vocês tenham; então, é possível iniciar essas varreduras. Mais uma vez, passamos de uma experiência local e interativa para outra mais voltada à escala programática. A CLI também pode ser usada no

34:00 CI de vocês. Assim, vocês podem usar esses componentes para, por exemplo, verificar se há componentes vulneráveis no repo, procurar vulnerabilidades em uma atualização de versão de uma dependência ou fazer uma verificação de CI falhar quando um PR for aberto. Estamos pensando em como ajudar vocês de forma programática em toda a empresa. Estamos muito, muito animados para continuar trabalhando com todas as empresas aqui e ajudar a

34:30 melhorar essa experiência. Tudo é open source, o que é incrível. Queremos trabalhar com o ecossistema mais amplo para acelerar a segurança. Com isso em mente, vou passar a palavra ao Lou, que vai explicar um pouco mais sobre como temos abordado internamente a fábrica de defesa. Muito obrigado a todos. >> Maravilhoso. Muito obrigado, Vanessa.

35:01 Então, meu nome é Lou e sou o CTO de campo na área de cibersegurança, especificamente na OpenAI. Vou deixar minha água aqui e pegar meu controle de apresentação. O que tenho o privilégio de conversar com vocês hoje é sobre o que temos feito internamente na OpenAI para desenvolver o que chamamos de nossa fábrica de defesa. Vou entrar em alguns detalhes sobre o que temos feito e como temos feito isso. E aguardem, porque, no final, também vou falar brevemente sobre alguns anúncios de produtos. É uma pequena prévia antecipada. Teremos o Dev Day na semana que vem, e depois também sairão mais anúncios sobre cibersegurança nas próximas semanas.

35:32 Como já foi mencionado, agora vivemos neste mundo com agents, em que eles avançam rapidamente, e precisamos adaptar nossos sistemas e serviços internos para que também sejam baseados em agents. Como Matt mencionou na introdução, declaramos internamente um alerta vermelho na OpenAI e mobilizamos 250 pessoas de diferentes áreas — engenharia, segurança e pesquisa —, reunindo-as em uma equipe multifuncional para desenvolver, na prática, a primeira versão da nossa fábrica de defesa e avançar rumo à ideia do que chamamos de defesa contínua.

36:05 Vou começar percorrendo um ciclo com o qual muitos de vocês provavelmente estão familiarizados, mas esse foi o ciclo que adotamos e ao qual aplicamos esses agents. A primeira parte, naturalmente, é o inventário: entender nossa superfície de ataque, nossos endpoints etc., tudo que poderia ser uma possível superfície de ataque. Na segunda parte, começamos a executar nossos diferentes modelos de cibersegurança em todo o nosso ambiente. Fizemos a descoberta e, como mencionamos aqui, encontrar problemas em nossa tecnologia é a parte fácil. Mas também começamos a fazer validação dinâmica. Ou seja, permitir que esses agents

36:37 validem as correções antes de encaminhá-las aos desenvolvedores ou para a remediação. Como parte desse processo, também fizemos a atribuição de responsáveis. Analisamos nossos sistemas internos, como Slack, PagerDuty etc., e nosso código-fonte, para descobrir exatamente a quem encaminhar esses problemas para remediação. E, como parte da remediação, não nos limitamos a corrigir os problemas: também validamos as correções. Elas realmente resolvem o problema que esperávamos?

37:09 em termos da pilha tecnológica? As ferramentas de segurança tradicionais que vocês têm na organização continuam exatamente as mesmas. Fizemos integrações com todas elas. As principais eram, naturalmente, o código-fonte e o acesso às aplicações, as ferramentas de segurança com as quais todos vocês já estão familiarizados e, algo fundamental, também os workflows, porque, para fazer essas vulnerabilidades avançarem por esse pipeline, precisamos atribuí-las. Precisamos transferi-las entre equipes e verificar o status. Então, o que há de novo? O que há de novo são, na prática, os agents e, naturalmente, as skills adaptadas às diferentes organizações em que vocês trabalham. Nós

37:41 também publicamos algumas dessas skills como parte do plug-in e da CLI do Codex, que podem servir de inspiração para vocês. Mas, naturalmente, suas skills serão um pouco mais específicas para a organização de vocês. A última parte, que também é fundamental para nós, é ter um ambiente isolado onde possamos executar esses agents — especialmente para aplicações, nas quais podemos executar a aplicação junto com o agent e permitir que ele faça iterações e valide determinados aspectos. Portanto, a estrutura da nossa fábrica de defesa interna precisa

38:11 ser executada dentro de uma rede. No nosso caso, é a nossa rede. Quando se trata de transformar isso em produto, sobre o que falarei um pouco mais adiante, naturalmente será preciso executá-lo na rede de vocês, com acesso a todos os sistemas internos, mas, algo fundamental, mantendo o código-fonte, a propriedade intelectual e tudo o mais em segurança dentro da rede. Esses agents eram executados em ambientes. Acreditamos que também faz sentido que isso seja feito em uma máquina virtual. Há várias abstrações diferentes para isso, incluindo contêineres. Mas a máquina virtual oferece um alto grau de isolamento e também nos dá acesso ao kernel, para usar o kernel também para

38:43 monitorar diferentes interações dos agents, monitorar o uso de ferramentas e as chamadas e, ainda assim, permitir que o agent reescreva arquivos etc., enquanto monitoramos tudo isso. Por cima disso, há um contêiner de desenvolvimento, que criamos com base no padrão aberto da Microsoft e que permite empacotar todas as dependências, ferramentas etc. dentro desse ambiente de desenvolvimento, proporcionando reprodutibilidade. Assim, os agents trabalham em um ambiente que é sempre o mesmo, todas as vezes, mas isso também oferece, basicamente, a possibilidade

39:14 de adicionar hooks. Então, do ponto de vista da segurança, vocês podem executar nele um sensor Falcon, conectá-lo ao Wiz e fazer o monitoramento. Também podem fazer isso. E, naturalmente, por cima disso, vem o agent com todas as suas skills. Isso permite, na prática, executar esses agents em toda a organização e em escala, porque vocês podem ampliar essa estrutura. Foi o que também fizemos internamente como parte dos nossos esforços. Passando a algumas métricas diferentes do que alcançamos: com a validação dinâmica, conseguimos reduzir nossa taxa de falsos positivos para menos de

39:45 1%. Para muitas organizações, esse número é muito mais alto: 50%, 60%, sabe, por cento. Na atribuição de responsáveis, chegamos a cerca de 90%. Ainda há trabalho a fazer, mas isso significa que, entre as vulnerabilidades que encaminhamos às equipes, a taxa de aceitação é de 90%; nos outros 10%, atribuímos o problema à equipe errada ou foi preciso encaminhá-lo a outra equipe. E, no caso das correções feitas por esses agents, também tivemos uma taxa de reversão de correções inferior a 1%. Ou seja, a grande maioria dessas remediações também foi bem-sucedida.

40:19 Para descer mais um nível e entrar nos detalhes, isso significou, na prática, reunir diferentes entradas dos nossos vários sistemas e o contexto em um ambiente que executava o Codex e esses agents, produzindo então um resultado para a validação dinâmica. É nesse ponto que pegamos uma vulnerabilidade encontrada por um scanner, uma ferramenta ou pelo Daybreak e a validamos. Então, ela é uma duplicata? É algo que já foi reportado? É possível acessá-la a partir dos nossos sistemas internos?

40:49 O mesmo vale para todos os diferentes workflows. Na atribuição de responsáveis, novamente, analisamos os sistemas internos, o PagerDuty, o GitHub etc. Quem são os diferentes responsáveis por essas vulnerabilidades, para que possamos mapeá-los e encaminhá-las com sucesso às equipes correspondentes? Espero que vocês estejam começando a perceber um padrão. Basicamente, foi assim que isso funcionou ao longo de todo o processo, do início ao fim. E o último ponto que vou mencionar é, naturalmente, a remediação verificada. Ou seja, aplicar as correções e, novamente, executá-las no próprio ambiente, disponibilizando uma aplicação para o agent, que pode

41:20 ter um alto grau de confiança de que a correção foi realmente aplicada e resolveu o problema por completo. A forma como fizemos isso internamente foi, naturalmente, com uma equipe extremamente numerosa, porque a OpenAI leva muito a sério o que consideramos ser um período em que os modelos de cibersegurança estão se tornando incrivelmente poderosos. Por isso, quisemos executar todos esses modelos em nossa infraestrutura e fizemos isso formando essa equipe multifuncional. Estamos adotando um padrão semelhante com alguns dos nossos clientes, reunindo essas equipes multifuncionais

41:51 para executar esses modelos de cibersegurança e fazer um grande esforço para avançar o fluxo de remediação de ponta a ponta. Isso permite que vocês aprendam sobre o próprio processo, identifiquem possíveis problemas de transferência, gargalos para a organização específica de vocês, e então reduzam essa fila de pendências, buscando, por fim, incorporar essa defesa contínua, em que os agents realizam o máximo possível desse processo. Em última análise, é assim que queremos — ou estamos propondo — usar essa vantagem do defensor: concentrando esforços para encontrar e corrigir essas vulnerabilidades e dando aos agents seu próprio

42:23 ambiente e, por fim, avançando rumo à defesa contínua. Uma coisa que estamos fazendo agora na OpenAI é transformar isso em produto. Estamos testando em nós mesmos e usando internamente. Mas vários clientes já têm uma versão inicial dessa arquitetura e também estão explorando isso conosco. Se tiver interesse, teremos prazer em conversar com você sobre o assunto. Obviamente, a capacidade é limitada neste momento. Estamos trabalhando com um pequeno grupo de clientes, mas isso também será disponibilizado nas próximas semanas e meses. Mas o principal que quero que você leve disso é que a OpenAI lançou modelos. Além disso, nós

42:54 adicionamos ferramentas, mas agora estamos tentando encontrar maneiras de colocar isso em operação para nossos clientes. Esse é um feedback consistente que recebemos de todos os lados: “Maravilha. Vocês nos deram esse modelo. Como podemos colocá-lo em ação? Como podemos realmente obter resultados com isso na nossa organização?” Esse é um dos grandes focos da OpenAI nas próximas semanas e meses. Muito obrigado. Agora vou passar a palavra de volta para Matt, que vai encerrar

43:25 falando sobre nossos novos modelos de cibersegurança. Mostramos como colocar isso em ação no Codex e trouxemos vocês conosco na jornada de como construímos um esforço contínuo para criar nossa fábrica de defesa. Vou explicar como vocês também podem começar a juntar todas essas peças. Uma lição que quero que vocês levem é que, como L falou, vamos transformar isso em um produto, mas não esperem por nós. Todas as peças já estão aqui. Não temos tempo a perder. Aprofundamos mais o trabalho em prevenção, identificação e correção de vulnerabilidades. Mas sabemos

43:55 que as equipes de segurança têm responsabilidades que vão muito além disso. Os clientes já podem usar nossos modelos e ferramentas para criar workflows de investigação e resposta. Também podem usá-los nas operações de segurança. Nosso objetivo é aprender junto com eles, compartilhar o que funciona e transformar isso em produtos, como faremos com a fábrica de defesa. Seja qual for o ponto em que você esteja nessa jornada hoje, há um próximo passo prático. Primeiro, se ainda não fez isso, inscreva-se no programa Daybreak e disponibilize essas ferramentas para você

44:25 usar. Em segundo lugar, comece com o plugin de segurança do Codex. Vanessa mostrou como ele funciona, e você já pode ver como começar aos poucos, com um único repositório. É fácil chegar a dezenas de milhares, centenas de milhares, executando isso no CI. Por fim, use a CLI e o SDK. Você pode começar a criar suas próprias ferramentas de segurança, personalizá-las para o seu contexto e desenvolvê-las para os clientes. Uma coisa que consideramos bastante importante é o que Lou mencionou sobre o ambiente em que isso é executado, certo? E sobre ter esses ambientes nos quais os agents

44:57 podem executar, validar e testar. Uma sugestão minha é começar a explorar os contêineres de desenvolvimento e como empacotar tudo isso em um ambiente que possa ser executado de forma reproduzível. Depois de fazer isso, você poderá executar testes internos com confiabilidade, e isso também fornecerá um contexto claro do sistema e da responsabilidade. Falamos um pouco sobre este diagrama. Comecei com ele e também quero terminar com ele. Esta é a fábrica de defesa. Ela reúne vários aspectos das ferramentas abertas. Estas

45:28 são as peças que vocês podem combinar. Os modelos oferecem a capacidade. O Codex e as ferramentas de desenvolvimento permitem colocar essa capacidade em prática. E os workflows de segurança podem oferecer pontos de partida mais específicos, dependendo do seu contexto. Sabemos que um dos maiores desafios para os clientes é a capacidade, e é por isso que vamos criar produtos completos, de ponta a ponta, para que vocês não precisem desenvolvê-los. Mas também é muito importante para nós que façamos essa jornada juntos. Por isso, vamos trabalhar em toda a rede de defesa Daybreak e trazer parceiros de treinamento e implementação para ajudar a construir

45:59 a fábrica de defesa e também ajudar vocês a percorrer essa jornada juntos. Quero terminar com isto: acreditamos de verdade que a janela dos defensores é real. Por isso, é tão importante para mim que não esperemos. Precisamos começar a agir agora. É muito, muito importante aproveitarmos este momento em que temos acesso aos modelos Daybreak e que eles realmente podem nos colocar em vantagem. Defender nosso mundo digital e físico vai exigir todas as equipes de segurança

46:30 equipes, pesquisadores, parceiros e mantenedores. Todos compartilhamos software. Cada correção com que contribuímos e cada lição que compartilhamos em palcos como este podem ajudar a defender outra empresa e ajudar outro defensor a agir mais rápido. É isso que me deixa otimista. Fico muito feliz que todos vocês tenham vindo hoje e que não estejamos sozinhos nisso. Temos uma comunidade e estamos prontos para colocar esses recursos em prática. Acredito que, quando olharmos para este momento, teremos orgulho, porque nos unimos, estivemos à altura do desafio e tornamos o mundo mais seguro. Estou muito ansioso para concluirmos isso

47:01 juntos, com todos vocês. E quero agradecer a todos por terem se juntado a nós aqui hoje.

Transcrição original

[00:05] Welcome everyone. Well, we are together for the afternoon. My name is Emanuel Mariel. I am the general manager for Europe in the East and Africa. And I’m just going to do the introduction for a few minutes and then hand over to the rest of uh the team. We have a really packed agenda. We have a one hour session right after. Then we have a few fire set chats. Very interesting. and then I will close that. But basically what we want the purpose of today is absolutely to understand the

[00:35] changes ahead right to learn from one another and to make sure that we make the most out of all the knowledge that we have in this room. We we are a moment in time which is very interesting. It’s almost kind of a privilege. We see this AI capabilities growing. I mean we just saw the Navier stock mathematics problem being solved a few weeks ago. We have released GPT6 Astra which is one of the most capable

[01:07] model we’ve ever shipped. The most capable model we’ve ever shipped sorry and when you look at those numbers you see that on top of scientific progress we are making businesses are making are using our technology AI technology more and more. 26% more weekly active users using Codex for marketing purposes. Legal 108% 108x more. We see that everywhere. I was in Berlin on Tuesday and I I spent some time with

[01:37] a company SMB company called Stadler. They have 650 employees and they were reporting that with their 145 agents working on top of their 650 employees they basically managed to get 30 to 40% efficiency gains. Businesses are leveraging are benefiting from these capabilities. Small medium businesses large enterprises across the board even more than 1 billion people using weekly uh using GPT

[02:09] on a weekly active basis. But with this growing capabilities come also the big question that we all have. Question of trust. It’s all about trust at the end of the day. Safety is and has always been front and center for open AAI. With the recent incidents, we put even more emphasis on safety

[02:40] topics. For instance, we have been growing significantly as a safety team. We are investing a lot in safety computing. We have posed for a couple of weeks beginning of August the most recent training runs that we had. And at the end of the day we have today Astra which is the most aligned model we have ever shipped. Safety is an essential essential sorry element of trust that’s for us on open AAI safety of

[03:10] models and then on you here I include ourselves on on in that for the room here it’s safety in the outside world external world cyber security and that’s why we are here today and trust is not only on the models it’s trust comes also with what we do as a team as an ecosystem on this security piece I’ve been traveling a lot over the past two weeks meeting many many customers. Six months ago the messages were not around cyber. Six days ago everybody

[03:43] started the conversation with cyber security concerns. Everybody. So alongside the incredible momentum we see in AI globally, we also sense emerging threats and what we call the defenders window is this gap that we see between the greater capabilities that the models we are shipping have and what comes from

[04:13] the open weights models that are fast accelerating behind. This window is this moment in time that we have to act so that defenders, you all can really leverage the best capabilities in the meantime and those open weights models are not that far behind and we know about that right that’s why we are here and that’s why it’s very rare but when we invite 150 people usually we don’t have 150 people

[04:43] showing up which is the case today everybody is showing up because I think there is a concern and everybody sees that it’s an ecosystem play. It will not be a open AI show. It will not be just a government show. It will be an ecosystem play. That’s why we let this letter a few weeks ago weeks with Yes, there are screens on the side. If you can’t see here, sorry, just to make sure there are screens on the side. It’s an ecosystem play. We have 100 people, 100 companies. Most of the companies by

[05:14] the way in the room today are on this chart too that have signed this letter. There is a letter that basically says we need to come together as one group, one ecosystem to fix this problem, right? And we all have a role to play. It starts by you the leaders in the company making sure that this cyber topic it becomes number one priority in the company. And I think we start seeing that. that I was in the US a couple of weeks ago and there it was already the number one

[05:46] priority and in Europe I feel that we are lagging a little behind but still catching up but that’s clearly the first thing it has to come from the top be number one priority on the agenda of the companies then we need technology partners dark trace checkpoint thanks for being here by the way today we need you your capabilities your knowledge your teams to connect the models that we have with the organization and the company so that we can deploy them and act on time. It’s a timing question. We need to act fast.

[06:21] Then is governments. Governments is very important because they are really the facilitator, the accelerator of this initiative. We just announced yesterday that we are going to work with Ukraine and help the cyber defense. had to face 6,000 attacks in the last year and our models are going to help them defend themselves. But not only in Ukraine, also in Europe. The EU cyber agency in Isa has reported three weeks

[06:51] ago, two weeks ago. Everything is like in the last weeks basically. I just keep saying weeks. It’s last week, two weeks ago, three weeks ago. It’s now basically Ana reported that they were using our model to find vulnerabilities. They found several vulnerabilities that they were not expecting through our model just on a small scale by the way. And then it’s on us. Us mean OpenAI. We really want to make sure that every critical infrastructure

[07:23] can benefit from this technology. It is not a question of money. Should not be a question of money. Everybody, whether it’s a hospital, utility provider should be able to defend themselves. Should be able to use our technology, our models, cyber models to defend themselves with our trusted access capabilities. Of course, that’s why we released um again two weeks ago this $1 billion fund to encourage to

[07:56] make sure that money was not the problem, right? And that what we see today is that when we combine all of us, the leaders, the technology partners, the governments and our capabilities, our technology, we have really a good opportunity to leverage this defender window. Speaking of which, and talking about defender window, I’m probably the least well positioned person to talk about that when we have Matt in the room that is coming on stage

[08:27] to basically tell us more about that. I just wanted to thank you very much. You’ll see me again at the end. Thank you very much for your attention and have a nice afternoon. Thank you. >> Hey everyone and thanks for being here today. I’m Matt. I’m the head of engineering for cyber at OpenAI and today I’m going to talk to you a little bit about how to pass cyber model capabilities to work. Does anyone know what this is? T’s barrier. Thank you. So, this

[09:00] probably wasn’t something on your mind coming into this conference today. Um, but for more than 40 years, it’s helped protect central London from tidal flooding. It’s enormous steel gates that can close across the river. And that protection has allowed us to go to work, uh, keep public services safe and gather in rooms like this. We don’t think about it because someone else takes responsibility for it. But many of you know exactly what that feels like. You protect systems that societies depend on. Hospitals, transport network, energy supplies, and all of our

[09:30] businesses rely on this digital infrastructure. As that dependence grows, cyber security becomes more important. And now AI is changing what’s possible. That same feeling, that weight became very, very clear to OpenAI very, very recently. It was very clear this summer what was coming. Our frontier models were finding weaknesses that have gone unnoticed. Broadly available models were um becoming more capable too. So right now, we believe defenders have a head start.

[10:00] We can use these models to close weaknesses before attackers exploit them. So we have to act internally at OpenAI. What we did was we grabbed our security team, our applied engineering team, and also our research team. We pulled them all together and the goal was just to strengthen our own defenses. We didn’t know exactly how we were going to do it, but we knew we had to do it. That effort became the starting point of something that we call the defense factory. Models gave agents capabilities. Skills gave them repeatable workflows. And development

[10:32] environments let them run software so we can test and validate those changes. Agents need their own environment. They need to investigate weaknesses. They need to test fixes. And our ambition is to move towards continuous defense. Lou is going to tell you a little bit more about our own defense factory a little later on in this in this session. We’re now seeing models uncovering vulnerabilities that have been hidden for decades. Our models helped identify a 23-y old uh floor in OpenBSD. In Poland, our cyber models found

[11:03] vulnerabilities in MicroTalk affecting releases going back all the way to 2013. Many people in this room run systems much older than 23 years old. And there’s um tons of things that we still need to uncover and we predict we probably will uncover as we as we dig in here. But the most important things is findings things is not really that interesting. Like we’ve had plenty of tools providing findings for a long time and it triggers a whole other process where you need to validate is it actually correct? Uh is it a duplicate? Do we already have this tracked? Is it risk accepted already? We need to turn

[11:33] them to fixes. Fixes are what we want not findings in order to protect our institutions. Uh that’s the gap we need to close and we need to verify that that fix works too. And we need to do this fast. The same capabilities that gave us these weaknesses also make it easier for attackers to exploit them. We can’t assume we’re going to stay ahead, but we do know we’re ahead for now. One thing I’m very proud of is this has become a a national priority, too. Uh so this is something the government’s looking at. We have the cyber shield initiative which aims to use agents to

[12:05] find vulnerabilities um progressing towards automated remediation across critical infrastructure. You can kind of think of this as a national defense factory, right? Other governments around the world are also looking at this. We’re very proud that the UK government are. We believe that every single organization needs their own defense factory. But we also know that OpenAI has an advantage that most organizations don’t. We have dedicated security teams. We have deep technical expertise and we have access to frontier uh AI.

[12:36] Governments, utility companies, open source software. It’s very unusual for them to have the same access that we do. And the thing that you know we need to uh really sort of internalize is their security is our security. So this is why we published this open letter. We had 500 organizations sign it and called for collective response. We need to get capable AI into the hands of defenders who don’t necessarily have the resources to do this alone. In addition, we announced the a billion dollar fund that we spoke about a moment

[13:07] ago, but this subsidizes Daybreak access and it helps defenders of of critical infrastructure, essential services, nonprofits, open source software to fix serious vulnerabilities. This gives defenders a head start. But we need to piece all these things together. Our frontier models provide the capability. Our Daybreak program gives eligible defenders access. And encodic security puts those capabilities to work across defensive and authorized offensive testing. Defense factory is a framework for bringing these pieces together into

[13:37] continuous defense. We’ll walk them through today and then we’ll return back to this map at the end. But ultimately, this is what today’s about. We want to share what Frontier models can do. We want to show how to put them to work um and how you can include them in your own operations. And we want to look at our research approach to show how we’ll create safer systems in the future, too. The defenders window is open. It’s not going to stay open for long, but it’s open right now, and we need to make it count. I’m going to hand it over to Lena, who’s

[14:08] going to come up and show you a little bit more about what our frontier models are capable of. My name is Lee and I lead our cyber program across AMIA for go to market. I’ve spent the last six months partnering with Europe’s largest and most critical organizations to improve their defensive capabilities. Today I’m going to walk you through how we built the best and the safest cyber security models and how we can make

[14:39] these available to you. At the beginning of the month, we launched GPT6 Astra, our most intelligent model yet. It’s a huge step forward for those everyday tasks, including software engineering and professional work, and it’s particularly good at computer use. That means you can hand off a lot of the admin that you normally do yourself, and let the model work through it on your computer. But it’s also a huge leap forward with cyber. We’ve trained it to find more vulnerabilities, including zero days,

[15:10] and to dig deeper into security problems and be a more capable red teamer. But capability is only part of the story. We also need to keep making that intelligence more costefficient so that people can afford to put it to work at scale. To see how we’re progressing on both of these fronts, we use a range of evaluations. One way that we measure that is with exploit gym. It tests whether a model can turn known software vulnerability into a working exploit across applications. Chrome’s JavaScript engine

[15:42] and the limit the Linux kernel. The model has to get the exploit working to score. Just triggering a crash isn’t enough. And along the bottom, you can see the number of output tokens that are used. And then up the side, the percentage of challenges successfully completed. On the graph here, you can see the output for GPT 5.6 six soul where it reached around 30% completion. Now if you take a look at Astra, it reached around 40% more successful completions, but it used far fewer tokens to do it. And that’s the progress

[16:14] that we want to highlight, tackling more of these difficult tasks with much less output needed to get there. So for defenders, that opens up the possibility of doing more thorough security testing with the resources that they have. So, what does this look like in practice? Working with our researchers, our models help uncover two previously unknown vulnerabilities in Chrome’s JavaScript engine and connect them into an exploit chain. One flaw allowed a memory corruption and a second let that

[16:44] corruption break through another layer of protection. The hard part was understanding how these weaknesses work together. And our researchers validated these findings and reported them to Google who then released a fix. So this is just one concrete example of these tools already helping to make software that we use every day much safer. And we’re taking that work beyond individual examples. Patch the planet is our initiative with trail of bits to help secure widely used open source software including projects like Python,

[17:15] curl and go. We fund expert security researchers and give them access to our models and codec security and they work directly with the maintainers to investigate the findings, develop and test patches and coordinate disclosure. In the first week alone, 37 patches were merged and in one of those projects which was AIO HTTP maintainers fixed eight reported uh issues within hours. It’s real progress with for these small teams maintaining this software that we

[17:46] all depend on. But the same capabilities that help defenders can also be misused. So models become more capable, our safeguards have to advance with them. And Astra is our first model to reach the cyber critical threshold that brings real opportunities for the defenders and a responsibility to manage risks carefully. As Sam has said previously, we shouldn’t be taking risks on behalf of humanity. People need to remain in control. And to do that with our cyber models, we use several layers of protection, including

[18:18] training the models to refuse harmful requests, detecting and blocking abuse, and monitoring for dangerous behavior. Together, these help us put powerful tools in defenders hands while making them harder to misuse. And with Astra, we strengthened those layers with a better detection for cyber misuse and attempts to bypass the safeguards. It also included tighter restrictions for higher risk accounts and monitors that examine examine the model’s reasoning and actions. These help us spot when a model goes

[18:49] outside his instructions and allows us to intervene. And that responsibility extends to what we’ll build next. Safety needs to stay ahead of the capability. And that’s why we’ve previously paused frontier training while we double down on monitoring and alignment research. We need to meet the required safety thresholds before we push the capability further. But alongside those safeguards, Astra is our most aligned model yet. Here’s one way that we test that. We give the model a difficult task which includes an

[19:19] outofscope target that the model could exploit as a shortcut. Without these production safeguards, Soul successfully exploited that target in around 48% of cases. But with Astra, we saw zero of those successful exploits that target that test. That matters because we want the models to respect the boundaries that we set even when the task gets really hard and it’s meaningful progress to make sure that we can delegate more complex work with greater confidence while keeping people in control.

[19:50] So next I wanted to talk about how we actually build these capabilities. We start with the coding and reasoning skills in our frontier models and then we go and add specialist cyber training on top of that including understanding vulnerabilities, developing working exploits and verifying the results. We make these capabilities available in two Daybreak tiers, red and blue. And Daybreak Red is our highest level of cyber access and it gives approved security teams access to these specialist models for advanced red teaming and weaponized exploit

[20:22] development. Think taking a crash and then turning it into a working exploit or chaining weaknesses together to see how far an attacker could get. But giving an agent this level of capability al means we also need to be clear about its boundaries. We need to include information about what it’s allowed to test, what it can reach, and then also allow your team to see what it’s doing. Today, teams often have to build all of this supporting infrastructure themselves. the execution environment, the network controls, monitoring and evidence collection, and

[20:52] it takes time away from their security work. So today, we’re announcing codec security red, a managed way to run penetration tests against your applications with all of the scope, controls, and oversight built directly into the workflow. So here’s how that’s going to work. You’ll start in codeex and you’ll define the assessment scope and the rules of engagement and then the investigation agents run in an open AAI hosted environment each with its own isolated sandbox.

[21:22] Your team follows their activity through the dashboard where findings and supporting evidence can come together to be reviewed. Now when those agents interact with your own application, their outgoing requests pass through network controls with a guardian agent reviewing the traffic. And that allows us to connect the investigation to your environment with controls on what the agents can reach and what they’re able to do. So this allows you to test what an attacker could actually achieve while keeping visibility and full control over the whole assessment.

[21:55] So for your team that starts with less infrastructure to build and maintain. We’re bringing the execution environment, monitoring, and findings together all into one view so you can spend more time investigating these weaknesses and getting them fixed. It also brings safeguards into the workflow with isolated environments and checks on outgoing requests that help manage the risks that come with using models that are this capable. It also gives your team more capacity to test applications and investigate potential attack paths. The aim is to

[22:27] make thorough, repeatable assessments easier to run with the team that you already have. And finally, it gives you the controls to feel confident in how you run the model. You can set the scope of what the model can access and you can block and restrict activity at the network level. And then next, for most defenders, the starting point is Daybreak Blue. It gives your front our frontier general purpose models with safeguards that are tailored to to allow authorized security work. Think reviewing code, investigating alerts, finding

[22:58] vulnerabilities, and then creating the patches. It help your teams find new issues and work through the vulnerability backlog. That includes GPT6 Soul and it now includes Luna and soon it will include GPT6 Astra, bringing our latest capabilities to everyday defensive work and giving you the option to choose the right size model for the job. So now let’s take a look at another practical workflow. Vanessa, one of our cyber deployment engineers, will show how Codeex Security investigates finding and then proposes a patch. Vanessa.

[23:38] >> Hello everyone. Um, it’s amazing to see some of you in person today that I’ve encountered over Zoom uh in San Francisco where maybe you were taking a late night call and I was taking an early morning one. It’s fantastic to be here today. Also nice to be like the only American uh speaking at today. So, that’s a little unique. Um, today we’re going to walk through a practical workflow of how to use codec security through the local plugin. I’m going to walk you through a little bit about uh how you can use this through Daybreak

[24:10] and the way that we can start to approach software security using the plugin as well as the CLI and what these workflows look like endto end for a typical security engineer who’s starting to engage with codeex uh for security work. So, what you’re looking at right now is Codeex, the desktop app. Uh, and what we’ve done is we’ve pulled on a local version of Ladybird. It’s a pre-alpha open source browser that’s been trending on GitHub for a while now. We also partnered with them through Patch the Planet as part of this. So,

[24:41] uh, when we got their permission to to demo this, uh, they are now working with Patch the Planet to also harden this project. Um, today what we’re going to do is go into the security section of Codeex. You can see that it’s empty. Now, we’re going to imagine we’re initializing our first set of scans for repos that we own. Uh, and we’re going to go ahead and take a look at what this configuration looks like. So, there’s two options here. One is to evaluate the entire codebase. The second is also to look at changes. So, this could be a PR

[25:12] or uncommitted changes or even a specific revision. But for today, what we’re going to look at is a full scan. And the reason for that is because typically we want to run a full security scan against repo the first time that we initialize it so it can identify novel vulnerabilities in the codebase that might have been missed by existing security tools. And I’m going to point you to a couple things that are really important here. One is our recommendation is to use either high or extra high reasoning for this initial

[25:43] scan. And generally speaking, you want to use the most frontier model that’s available. So in this case we can use soul or even Astra. Um and what we want to do here is initialize a scan again using high or extra high reasoning with a frontier model. The thing that I really want to focus on is the context. And this is the difference between existing security tooling in the space and what a reasoning model provides under the hood is the ability to actually provision context for the scanner and for the model to understand

[26:15] what it needs to look for in your environment. So in this example, we’re going to look at the attack vectors. We’re going to provide areas of focus for the model and we’re also going to provide additional security context. I would think about this as well as like what is the enterprise context that you would want the model to know about. So this could be anything from compensating controls, you know, a Z business logic that you’re thinking about, even things like how you define fraud. These can all be seated as part of the scan. So we’re going to start by initializing this. And

[26:46] you can see that codeex is now running a full scan. What it does under the hood is it initializes a threat model of the repo. So in this case, it reviewed 28,000 files, identified and generated a threat threat model. Then it surfaced candidate vulnerabilities and validated them to ultimately present this report. So let’s go ahead and take a look. Right now there’s a shared JavaScript by code cache vulnerability. We have a summary here and we can see the exact tag path

[27:17] based off of the files that Codex determined were vulnerable and then it validated the the actual vulnerability. Right? So we’re going from this could potentially be a vulnerability to okay, we validated this in the source code and we think this is a true positive. And then here we can see that there’s the impact. So a high impact and high likelihood. Again, these results are driven by the context you provided. So when we’re thinking about um the additional context that we seated in the net scan or context you want to

[27:48] provision through other files, this can help inform the vulnerability impact. Um but really taking a step back, we’re not interested in just surfacing vulnerabilities. Um I know many of us who have been security practitioners, I’ve been one for uh many many years now. We we’re not interested in just having a raw dump of vulnerabilities. Our goal is to ultimately remediate and burn down risk. So what we want to do is actually generate a patch. I want to pause here for a second. So the reason

[28:19] why this is so powerful is that codecs and codec security are an extension of the software development uh agents that we have shipped in the software engineering capabilities. And so part of this is taking the software engineering capabilities of these models to help inform not only what the vulnerabilities are, but what effective patches are. In this case, we can go ahead and generate a patch. You can see that it’s invoking this fix finding skill under the hood that’s part of the the plug-in and also

[28:50] part of our CLI. So now we have a patch here. We can actually review this and see exactly uh what has been affected and what code needs to be fixed. we can apply this patch within the repo locally and then verify the fix to make sure uh that the the vulnerability is no longer there. Um so this is one component of it. But when we’re looking at how do we inform these scans and how do we think about the broader vulnerabilities we’re finding in the codebase, the way to do

[29:21] this is through a security.md file. So the way I would think about this is fundamentally like an agents.mmd but for security that provides context at the repo level for what you’re most concerned about. In this example here, there’s a skill you can invoke that’s pretty easy. Um but you can also provide your own context here. And this helps inform the agent when it’s running scans about what you consider to be most important, what the threat attacks could be, uh how you consider trust boundaries

[29:52] or business logic. So really this is a core component of how we want to redefine what security looks like by providing context to the agent. Um and so here we’ve reviewed this and we’re good with it. What we want to do is actually commit this to the repo. Um and now we have a repo within Ladybird that’s been scanned. It has a security.mmd file that’s been committed to it for future runs. But that doesn’t really solve this broader problem that we have around how do we fix vulnerabilities uh at a broader scale

[30:23] and how do we engage with existing tools and systems that we have. So this is where we want to leverage the extensibility of codecs. The way that we do this is by um a actually asking codeex to take the scan results to use sub agents to generate patches for those findings uh group them and then actually open juro tickets for us uh open PRs on our behalf for us to review and notify relevant engineers on Slack. It’s really

[30:54] interesting here because part of part of what we’re seeing is the ability to communicate and engage with other stakeholders within the org. So a lot of times maybe one person is responsible for running the scan but another person is responsible for mediating. Part of what we’re seeing here is extended workflows to help you communicate with other engineers and get work done. So here what we’re doing is following a similar flow to what we walked through before where we had an endto-end remediation workflow except in this example we’ve actually spawned sub

[31:25] agents. These sub agents are doing the exact same flow. So they’re looking at the code they’re seeing the vulnerability. they’re generating a patch and then they’re going to validate it. What we can do now is see that codeex is actually opening up Jira tickets and and actually opening up PRs within GitHub. So now what we have are tickets that have been opened PRs that have been opened and we can go ahead and see that someone has been notified that there’s a ticket for them to review for a finding from a Codex security scan. If

[31:56] we go inside of this scan, we can see here there’s a ticket for someone to review in a draft PR. This has been generated by codeex for an engineer to review. And what we can do is actually look again like we did before within codeex at the affected code in the recommended fix. Um, we can verify that this works and there are no downstream effects. We can also tweak this specifically for your ONCI pipeline to make sure there are no breaking changes. So fundamentally making sure that you

[32:27] know all all checks are green and there’s no failing CI tests um as you’re opening these PRs to make life simpler for the engineer to really focus on the code itself. Um and what we can do is just say hey it’s ready for review looks good to me and let’s go ahead and merge this PR. So this is one of the ways that we can extend and augment these workflows. It’s not the only way. So in the last six months I’ve met with quite literally a thousand customers and a big

[32:57] part of this is thinking about scale. So it’s very very easy to do this for one repo when you have seven vulnerabilities but how do you do this when you have 10,000 repos? The solution to this is the CLI and the SDK. So what you were seeing in the codeex plug-in um are different skills. are composable skills that we have developed after meeting with many teams and observing their own workflows. We took the local experience of those skills in the codec security plug-in and we brought them into a CLI

[33:29] that allows more programmatic uh tests. And so here you can see there’s a bulk scan that you can run and you can define how many workers are initiated for this bulk scan and you can pass repositories.csv CSV with a number of GitHub repos or or other SCM repos that you have and then initialize these scans. So again, we’re going from a local interactive experience to one that’s more focused on programmatic scaling. The CLI can also be used within

[34:00] your CI. So you can actually use these components for things such as um seeing if there are any um vulnerable components of the repo. you can look to see if there’s a vulnerability in a version upgrade, for example, for a dependency or having a failing CI check for when there is um a PR that’s been opened. So, we’re thinking about how to help you programmatically across an enterprise. Um, and we’re really really excited about, you know, continuing to partner with every company here to help

[34:30] improve this experience. It’s all open source, which is amazing. Um, and we want to partner with just like the broader ecosystem to to accelerate security. Um, with that in mind, I’m going to pass things over to Lou and he’s going to walk you through a little bit more about how we’ve been approaching the defense factory internally. Thank you guys so much. >> Wonderful. Thank you very much, Vanessa.

[35:01] Um, so my name is Lou and I’m the field CTO within cyber, specifically within OpenAI. I’ll put my water down and grab my clicker. So what I have the privilege of talking about with you today is what we’ve been doing internally within OpenAI to build out what we mentioned as our defense factory. So I’m going to go into some of the details about what we’ve been doing and how we’ve been doing that. And hold tight because at the end as well, I will talk briefly about some product announcements. It’s a little bit of an early teaser. We do have dev day next week and then some more cyber announcements will come out over the next coming weeks as well.

[35:32] So as has been mentioned, we now live in this world with agents where agents are moving rapidly and we now need to move our internal systems and services so that they are also based on those agents as well. As Matt mentioned in the introduction, we actually called an internal code red within OpenAI and we mobilized 250 different people across engineering, security, research, put them together into a cross functional team to build out effectively what is the first iteration of our defense factory and building toward this idea of what we call continuous defense.

[36:05] So I’m going to go start by running through a loop that obviously many of you might be familiar with but this is the loop that we took and then apply these agents to the first part of that obviously naturally is inventory understanding our attack estate our endpoints etc everything that could be possible surface area to be attacked. The second part is then we started running our different cyber models across our entire estate. Doing discovery on that and as we mentioned here finding things across our technology is part of the easy part. But what we started also doing is dynamic validation. So allowing those agents to

[36:37] actually validate those fixes before they are sent over to developers or for remediation. As part of this process we also did it ownership assignment. So going through our internal systems whether that be slack, page of duty etc. our source code trying to find out specifically who are we handing these issues to for remediation and also one part we did then as part of the remediation we don’t just remediate but then we were also validating those fixes as well. Do they actually fix the issue that we thought they would

[37:09] in terms of the tech stack? So the traditional security tools that you have within your organization actually then all stay the same. We were integrating across all of these. The main ones were obviously source code to access for applications, the security tools that you’re all very familiar with, but then critically as well also workflows because to get these vulnerabilities through that pipeline, we need to assign them. We need to move them between teams and check their status. So what is new? What is new is effectively agents naturally the skills which are accustomed to the different organizations that you all work in. We

[37:41] have some of these skills as well published as part of our codeex plug-in and CLI which you can all take inspiration from. But your skills are going to be obviously naturally specific a bit more to your organization as well. But the last part and a key part of this for us as well is having an isolated environment where we can actually run these agents as well especially for applications where we can run that application alongside the agent and have it iterate and validate certain aspects. So the anatomy from our internal defense factory is effectively that now needs to

[38:11] run inside of a network. In our case it’s our network when it comes to productizing this which I’ll talk a little bit about later that naturally then will need to run in your network have access to all of your internal systems but critically needs to keep your source code your IP everything also safe within your network. Those agents were then running inside of environments. We believe that also makes sense for this to be a virtual machine. There are many different abstractions for this including containers. But the virtual machine gives us a strong amount of isolation and also allows us access to the kernel to use the kernel also to

[38:43] monitor different agent interactions to monitor its tool use and calls and that agent can then rewrite files etc. But we can still monitor that. On top of that is a development you know container which is we’ve built on top of the open standard for Microsoft uh which allows you then to package all of your dependencies, your tools, etc. uh inside of that dev environment that gives you reproducibility. So those agents work in a an environment that is always the same every time, but it also gives you um the the ability basically

[39:14] to add in hooks. So from a security perspective, you want to run a Falcon sensor in there, you want to hook that up to whiz and and do your monitoring, you can do that as well. And then naturally on top of that comes your agent with all of its skills. And then through this this allows you then effectively to run those agents across your organization at scale because you can then scale this up and that’s what we were also doing uh internally as part of our effort. So turning to a couple of different metrics of what we achieved. So across our dynamic validation we managed to get uh our false positive rate down below

[39:45] 1%. Which for a lot of organizations this number is vastly higher 50 60 you know percentage itself. For ownership assignment we got this up to about 90%. So there’s still work to do there, but that means from those vulnerabilities when we hand them over to the teams that that’s a 90% accept rate or 10% for those where we misassigned to a certain team or that had to be handed over. And then from the fixes that we were then remediating with these agents, we then also had, you know, less than 1% fixed roll back rate. So of those remediations, you know, uh, a vast maj majority of those succeeded as well.

[40:19] So to get one layer down finally just also into the detail. Um what this effectively meant for us is a number of different inputs from our various systems and our context flowing into an environment that was running then with codecs and these agents and that was then resulting in a form of output for dynamic validation. This is where we take a vulnerability from a scanner or a tool or something that Daybreak has found and then we actually validate that. So is it a duplicate? Is it you know something that’s already been raised? Is it reachable uh from our internal systems?

[40:49] The same across all of the different workflows as well. Even ownership assignment again internal systems, page duty, GitHub, etc. Who are the different owners for these different vulnerabilities so we can map them and have them successfully handed over to those individual teams. Hopefully, you’re starting to see there is a pattern here. This is basically how this worked throughout the entire process from start to finish. And the final one that I will mention is obviously then verified remediation. So applying those remediations, but then again by running that inside of its own environment, giving it an application, that agent can

[41:20] have a high degree of confidence, has that fix actually been um actually resolved fully? So the way that we ran this internally, obviously we staffed this incredibly heavily where, you know, OpenAI takes this very seriously in terms of what we believe to be uh a period in time now where cyber models are becoming incredibly powerful. So we wanted to run all these models across our infrastructure and we did that by forming this cross functional team. This is a similar pattern that we’re now running with some of our customers as well to pull together these cross

[41:51] functional teams. Run these cyber models and try to put a large push on the remediation flow end to end that then allows you to learn about your process where maybe there are handoffs, issues, bottlenecks for your specific organization and then work that backlog down and ultimately trying to build in this continuous defense where agents are doing as much of this process as you can. So ultimately that’s how we want or how we’re putting forward to use this defender’s advantage. So having a focused push to find and fix these vulnerabilities giving agents their own

[42:23] environment and then ultimately building towards continuous defense. Now one thing that now within OpenAI that we’re doing is productizing this. So we’re testing on ourselves and dog fooding. Uh but there are several customers that have an early version of this architecture that are exploring this also with some of our customers. If you’re interested on that we’re happy to talk to you about it. Obviously, you know, the capacity is limited right now. We’re working with, you know, a small handful of customers, but that will then be rolled out over the coming weeks and months as well. But the big big thing I want you to take from that is OpenAI has released models. We’ve additionally

[42:54] added tools, but we’re now trying to find ways to operationalize this for our customers. That’s consistent feedback that we get across the board is wonderful. You’ve given us this model. How do we put this to into action? How do we actually get results from this in our organization? And that’s one of the big focuses for OpenAI over the coming weeks and months. So, thank you very much and I will now hand you back over to Matt who will just close us out

[43:25] talking about our new cyber models. We’ve shown you how to put that together into action into codeex and we brought you on the journey we’ve been on about how we built a continuous effort to build our defense factory. I’m going to talk to you um through how you can start putting everything together too. Like one lesson I want you to take away is you know L talked about how we are going to build this into a product but don’t wait for us. All the pieces are here. We don’t have time. We’ve gone deepest on prevention finding and fixing weaknesses. Um but we know

[43:55] that security teams have responsibility across a lot more than that. Customers can already use our models and tools to build workflows for investigation for response. Uh and they can work around security operations. Our direction is to learn alongside them. share what works and turn that into products as we’re going to do with the defense factory. Wherever you today, wherever you are on this journey today, there is a practical next step. So firstly, if you haven’t already, apply for our Daybreak program and put these tools available for you to

[44:25] work. Second is start with the CODC security plugin. Vanessa walked you through that and you can see already how you can potentially start small, start with one repository. You can easily get up to tens of thousands, hundreds of thousands by running that in CI. And then finally, use the CLI and SDK. You can start to build your own security tools, customize them for your context, build them out for customers. One thing that we believe is quite important is Lou touched on sort of the environment it runs in, right? And these having these environments that agents

[44:57] can run, they can validate, and they can test. So one one suggestion from me is start to look at dev container and how you can package all these things together in an environment that you can uh run reproducibly. Once you do this, you’ll be able to reliably reliably run internal tests and it’ll also give clear system context and ownership. So we’ve talked you through a little bit this diagram. I started with this and I want to end with it too. This is the defense factory. It brings together various aspects of open tooling. These

[45:28] are the pieces you can bring together. The models provide the capability. Codecs and development tools let you put that capability to work. And then the security workflows that can provide more specific starting points depending on where you are. We know one of the greatest challenges for customer is capacity which is why we’re going to build full end to end products so you don’t need to build yourself. But what’s also really important to us is this needs to be a journey we go on together. So, we’re going to do work across the Daybreak Defense Network and bring training and implementation partners to help build

[45:59] defense factory and also just help you navigate this journey together. I just want to finish with this. So, we really do believe the defenders window is real. It’s why it’s so important to me that we don’t wait. We need to start moving now. It’s really really important that we start taking um advantage of this moment we have where we do have access to the Daybreak models um and that they really can kind of set you up ahead. Defending our digital and physical world is going to take all of us security

[46:30] teams, researchers, partners, maintainers, we we all share software. Every fix we contribute and every lesson we share on stages such as this, we can help defend another uh company and help another defender move faster. This is what gives me optimism. I love that you all came today and we’re not alone in this. We have a community and we’re ready to put these capabilities to work. I believe we’ll look back on this moment and we’ll be proud because we came together, we rose to the occasion and we made the world more secure. So, I’m really looking forward to getting this done

[47:01] together with all of you. And I want to thank you all for joining us here today.