A OpenAI apresentou o Codex Security, um agente de segurança de aplicação que analisa uma codebase, valida vulnerabilidades prováveis e propõe correções que os desenvolvedores podem revisar antes de aplicar o patch. O produto está sendo lançado em pesquisa prévia para clientes ChatGPT Enterprise, Business e Edu através do Codex web. Por que a OpenAI Construiu o Codex Security? O produto foi projetado para um problema que a maioria das equipes de engenharia já conhece bem: ferramentas de segurança geralmente geram muitos achados fracos, enquanto as equipes de software estão lançando código mais rapidamente com desenvolvimento assistido por AI. Em seu anúncio, a equipe da OpenAI argumenta que o principal problema não é apenas a qualidade da detecção, mas a falta de contexto do sistema. Uma vulnerabilidade que parece grave em uma varredura genérica pode ter baixo impacto na aplicação real, enquanto um problema sutil ligado à arquitetura ou limites de confiança pode ser totalmente ignorado. O Codex Security é posicionado como um sistema com consciência de contexto que tenta reduzir essa lacuna. Como o Codex Security Funciona? O Codex Security funciona em 3 etapas: Etapa 1: Construindo um Modelo de Ameaças Específico para o Projeto O primeiro passo é analisar o repositório e gerar um modelo de ameaças específico para o projeto. O sistema examina a estrutura relevante para a segurança da codebase para modelar o que a aplicação faz, em que ela confia e onde pode estar exposta. Esse modelo de ameaças é editável, o que é importante na prática porque sistemas reais geralmente incluem suposições específicas da organização que ferramentas automatizadas não conseguem inferir de forma confiável por conta própria. Permitir que as equipes refinem o modelo ajuda a manter a análise alinhada com a arquitetura real, em vez de um modelo de segurança genérico. Etapa 2: Encontrando e Validando Vulnerabilidades A segunda etapa é a descoberta e validação de vulnerabilidades. O Codex Security usa o modelo de ameaças como contexto para procurar problemas e classificar os achados pelo seu provável impacto no mundo real dentro desse sistema. Sempre que possível, ele testa os achados em ambientes de validação isolados. Se os usuários configurarem um ambiente adaptado ao projeto, o sistema pode validar problemas potenciais no contexto da aplicação em execução. Essa validação mais profunda pode reduzir ainda mais os falsos positivos e pode permitir que o sistema gere provas de conceito funcionais. Para as equipes de engenharia, essa distinção é importante: uma prova de que uma falha é explorável no sistema real é mais útil do que um aviso estático bruto porque fornece evidências mais claras para priorização e correção. Etapa 3: Propondo Correções com Contexto do Sistema A terceira etapa
Fonte: MarkTechPost
Publicado em 2026-03-06