OpenAI disponibiliza Codex Security como código aberto: como digitalizar, validar e corrigir vulnerabilidades

Introdução

A OpenAI lançou silenciosamente o código-fonte da interface de linha de comando (CLI) do Codex Security e do SDK TypeScript.

Este pacote público, @openai/codex-security, tem como objetivo ajudar equipes de segurança e engenharia a:

• Escanear bases de código em busca de vulnerabilidades.
• Validar descobertas plausíveis.
• Revisar alterações antes da mesclagem de código.
• Rastrear descobertas em múltiplas varreduras.
• Marcar e lembrar falsos positivos.
• Verificar se as correções resolvem o problema original.
• Exportar resultados estruturados para automação.
• Integrar revisões de segurança em fluxos de trabalho de CI/CD.
• Construir ferramentas de segurança personalizadas por meio do SDK TypeScript.

O repositório de código é distribuído sob a licença Apache License 2.0.

Isso significa que o código da CLI e do SDK é aberto. No entanto, isso não significa que todo o serviço do Codex Security, seus modelos subjacentes, cada descoberta protegida ou acesso ilimitado à rede estejam agora disponíveis gratuitamente offline.

A execução de varreduras ainda requer acesso ao Codex Security. A OpenAI também afirmou que determinadas varreduras de repositório completo, descobertas protegidas e solicitações avançadas de segurança cibernética podem exigir aprovação por meio do Trusted Access for Cyber (Acesso Confiável para Cibersegurança).

Essa distinção é muito importante:

CLI e SDK de código aberto
≠
Modelo de segurança de pesos abertos
≠
Acesso irrestrito à varredura na nuvem

O Codex Security começou como um projeto interno chamado Aardvark. Posteriormente, foi integrado ao Codex como um agente de segurança de aplicativos em prévia de pesquisa, e o novo pacote público agora permite que desenvolvedores levem o scanner para terminais locais, ferramentas internas, atividades em lote em bases de código, verificações antes de commits e pipelines de CI.

Do Aardvark ao Codex Security

A OpenAI lançou o Aardvark pela primeira vez em outubro de 2025, como um pesquisador inteligente de segurança impulsionado pelo GPT-5.

O objetivo do sistema original era se comportar mais como um pesquisador humano de segurança de aplicativos do que como um scanner tradicional baseado em assinaturas.

Em vez de apenas corresponder código a padrões conhecidos, o Aardvark podia:

• Ler bases de código.
• Construir um modelo de como o sistema funciona.
• Examinar novos commits.
• Raciocinar sobre explorabilidade.
• Escrever e executar testes.
• Usar ferramentas de segurança.
• Explicar vulnerabilidades.
• Propor patches direcionados.

Em março de 2026, a OpenAI renomeou o Aardvark para Codex Security e o integrou ao Codex.

O produto foi disponibilizado como prévia de pesquisa por meio do Codex Web para alguns planos do ChatGPT, com suporte a repositórios GitHub conectados.

A publicação de código aberto subsequente adicionou uma camada de implantação diferente.

Os desenvolvedores agora podem instalar a CLI ou importar o SDK TypeScript, enquanto a experiência gerenciada na nuvem do Codex Security continua existindo separadamente.

O que foi realmente aberto

O repositório público no GitHub contém:

• A CLI do Codex Security.
• O SDK TypeScript.
• Recursos para Docker e Docker Compose.
• Suporte para comandos voltados a CI e saída estruturada.
• Gerenciamento de histórico de varreduras e descobertas.
• Documentação e arquivos de contribuição.

O pacote é publicado no npm como:

@openai/codex-security

A licença Apache-2.0 do repositório geralmente permite uso, modificação e redistribuição dentro dos termos da licença.

O que não está incluído como modelo aberto

Esta publicação não fornece os pesos dos modelos GPT-5.6 Sol, Terra ou dos modelos dedicados do Codex Security.

A varredura padrão atualmente utiliza:

gpt-5.6-sol
Intensidade de raciocínio: xhigh

A CLI invoca o serviço de inferência por meio de acesso autenticado.

O repositório também documenta opções de provedores para modelos selecionados (como OpenRouter e Fireworks), mas os fluxos de trabalho de varredura do Codex Security e os recursos protegidos de rede podem ainda exigir autorização da OpenAI.

Código aberto não remove o controle de acesso

Instalar o pacote npm não equivale a obter permissão para executar cada varredura.

A documentação da OpenAI afirma:

• É necessário acesso ao Codex Security.
• Alguns repositórios ou solicitações podem exigir "acesso confiável à rede".
• Fazer login ou configurar uma chave de API não concede automaticamente "acesso confiável".
• As descobertas de segurança podem conter trechos sensíveis do código-fonte e detalhes de exploração de vulnerabilidades.
• Os usuários devem escanear somente código que possuem ou que têm autorização para avaliar.

O código público torna o fluxo de trabalho inspecionável e extensível. Ele não remove as camadas de segurança e autorização em torno de usos avançados de rede.

Por que essa publicação é importante

Agentes de programação com IA geram e modificam software em uma velocidade que pode superar a capacidade de revisão de muitas organizações.

Isso cria um gargalo de segurança.

Um produto pode passar de ideia a aplicativo implantado em poucos dias ou horas, enquanto a revisão tradicional de segurança de aplicativos pode ainda depender de:

• Modelagem manual de ameaças.
• Configuração de análise estática.
• Testes de penetração.
• Revisão de dependências.
• Triagem manual.
• Agendamento de lançamentos.
• Disponibilidade da equipe de segurança.

O problema não é apenas que os desenvolvedores carecem de relatórios de vulnerabilidades.

Muitos mantenedores já recebem relatórios em excesso, incluindo:

• Descobertas duplicadas.
• Alertas de baixo impacto.
• Classificações de gravidade incorretas.
• Caminhos de código inalcançáveis.
• Descobertas sem evidências.
• Recomendações de correção genéricas.
• Relatórios que ignoram a arquitetura do projeto.

O design do Codex Security gira em torno do objetivo oposto: menos descobertas, mais contextuais, com evidências para ajudar revisores a decidir o que corrigir.

Como o Codex Security funciona

A OpenAI descreve o sistema como um fluxo de trabalho de segurança de aplicativos em múltiplas etapas.

1. Construção do contexto do repositório e modelo de ameaças

O Codex Security começa estudando o repositório para entender a estrutura relacionada à segurança do projeto.

Ele tenta identificar:

• O que o sistema faz.
• Quais componentes confiam entre si.
• Onde a entrada controlada pelo usuário entra no sistema.
• Quais limites separam usuários, locatários, papéis ou serviços.
• Quais operações têm privilégios.
• Quais ativos são sensíveis.
• Onde o sistema está exposto a invasores.

O resultado é um modelo de ameaças específico do projeto, não uma lista de verificação genérica.

As equipes podem adicionar documentação de arquitetura, políticas de segurança, áreas de foco e vetores de ataque conhecidos para melhorar esse contexto.

1. Busca por vulnerabilidades no contexto

Ao revisar o código relevante, o agente usa o modelo de ameaças para avaliar o impacto real.

Isso permite raciocinar sobre problemas que scanners baseados em regras dificilmente compreendem isoladamente.

Exemplos podem incluir:

• Lacunas de autorização entre limites de locatários.
• Injeção indireta de prompts que acessam ferramentas privilegiadas.
• Exposição de dados sensíveis por meio de rastreamento por proxies.
• Bypass de autenticação.
• Server-side request forgery (SSRF).
• Interações perigosas entre componentes aparentemente comuns.

O scanner pode revisar:

• Repositórios de código inteiros.
• Um ou mais caminhos selecionados.
• Um intervalo de commits.
• Alterações em pull requests.
• Alterações no diretório de trabalho, encenadas ou não.
• Múltiplos repositórios em atividades em lote.

1. Validação de descobertas plausíveis

Quando possível, o Codex Security tenta validar problemas de alto sinal em um ambiente isolado.

A validação ajuda a responder:

• O caminho vulnerável é alcançável?
• As condições de exploração propostas são realistas?
• A prova de conceito funciona?
• O problema foi classificado incorretamente?
• A descoberta pode afetar um sistema em execução?

Esta etapa visa reduzir falsos positivos.

Ela não garante que cada descoberta foi reproduzida, nem que uma varredura completa prove que o repositório está seguro.

O arquivo coverage.json da varredura registra se o status de cobertura é:

Completo
Parcial
Desconhecido

Os revisores devem ler exclusões, áreas adiadas e problemas pendentes antes de tratar uma varredura como evidência de revisão abrangente.

1. Proposição de correções direcionadas

Para descobertas aceitas, o Codex Security pode sugerir um patch projetado para se adequar ao sistema atual.

O objetivo não é apenas silenciar o scanner.

Uma boa correção deve:

Eliminar ou mitigar as causas raiz.

• Manter o comportamento esperado do aplicativo.
• Evitar refatorações amplas e não relacionadas.
• Minimizar regressões.
• Incluir evidências ou testes quando apropriado.
• Manter a revisão possível por engenheiros humanos.

A varredura padrão do Codex Security fornece apenas relatórios. Os patches sugeridos ainda devem passar pelos fluxos normais de revisão de código, testes e controle de implantação.

1. Aprendendo com o feedback da revisão

A CLI armazena o histórico de varreduras e oferece suporte ao feedback sobre descobertas.

Os revisores podem marcar descobertas como falsos positivos e registrar o motivo.

Varreduras subsequentes podem levar em consideração essa explicação ao reexaminar o código atual.

Isso ajuda o scanner a se adaptar a fatos específicos do repositório, sem suprimir permanentemente caminhos de código que podem se tornar vulneráveis no futuro.

Resultados relatados pela OpenAI

A OpenAI publicou vários dados de adoção e qualidade de sua implantação em pré-visualização.

Essas são métricas relatadas pela empresa, não resultados de benchmarks independentes.

Pré-visualização de pesquisa de março de 2026

A OpenAI afirma que, em um período de 30 dias, o Codex Security:

A OpenAI também relatou melhorias na versão beta:

• Redução de 84% em alertas desnecessários em um repositório com varredura contínua.
• Redução de mais de 90% em descobertas com gravidade exagerada.
• Redução de mais de 50% em falsos positivos em todos os repositórios.

Atualização Daybreak de junho de 2026

A OpenAI afirmou posteriormente que o Codex Security Cloud passou a ter:

A escala é significativa, mas esses números não devem ser interpretados como uma comparação controlada com CodeQL, Semgrep, Snyk ou testes de penetração manuais.

Essas ferramentas operam de maneiras diferentes e podem medir descobertas, correções e cobertura de formas diferentes.

Interfaces do Codex Security

O Codex Security está disponível através de várias interfaces relacionadas.

A CLI pública e o SDK usam o mesmo fluxo de trabalho geral do scanner que o plugin, mas a disponibilidade e a maturidade dos recursos podem variar entre o diretório do plugin, o pacote da CLI e a pré-visualização de pesquisa na nuvem.

Início rápido: instalar e executar o Codex Security

Os comandos a seguir seguem a documentação oficial atual da CLI da OpenAI.

Etapa 1: Verificar os pré-requisitos

A CLI requer:

Node.js 22 ou superior
Python 3.10 ou superior
Acesso ao Codex Security

O repositório GitHub atualmente fornece uma faixa mais específica de versões suportadas do Node.js, incluindo as versões mais recentes 22.x, 24.x e 26.x.

Verifique seu ambiente:

node --version
python3 --version

Etapa 2: Instalar o pacote

Instale o Codex Security a partir do npm:

npm install @openai/codex-security

Verifique a versão instalada:

npx @openai/codex-security --version

Liste os comandos:

npx @openai/codex-security --help

Etapa 3: Autenticar

Para uso interativo local, faça login com sua conta do ChatGPT:

npx @openai/codex-security login

Para máquinas remotas ou sem cabeça:

npx @openai/codex-security login --device-auth

Para CI ou outros fluxos de trabalho não supervisionados, forneça a chave de API por meio do ambiente:

export OPENAI_API_KEY=""

Não coloque chaves de API no controle de versão.

Use um gerenciador de segredos ou o sistema de segredos protegidos da plataforma de CI.

Quando tanto o login do ChatGPT armazenado quanto a chave de API estiverem disponíveis, escolha explicitamente o método desejado:

npx @openai/codex-security scan . --auth chatgpt

Ou:

npx @openai/codex-security scan . --auth api-key

A autenticação não concede automaticamente o Trusted Access da Cyber.

Etapa 4: Escolher um diretório de saída privado

A OpenAI recomenda armazenar os resultados fora do repositório varrido.

Os relatórios podem conter:

• Trechos de código-fonte.
• Evidências de vulnerabilidades.
• Material de prova de conceito.
• Detalhes de arquitetura.
• Caminhos sensíveis.
• Orientação de correção.

Prepare os diretórios de destino e de resultados:

REPOSITORY=/caminho/para/repositorio
SCAN_DIR=/caminho/fora/do/repositorio/codex-security-results

Se o diretório de estado persistente padrão não for gravável, escolha outro diretório privado:

export CODEX_SECURITY_STATE_DIR=/caminho/fora/do/repositorio/codex-security-state

Etapa 5: Executar uma verificação de teste

Antes de iniciar o trabalho do modelo, confirme os caminhos locais e a configuração da varredura:

npx @openai/codex-security scan "$REPOSITORY" \
--output-dir "$SCAN_DIR" \
--dry-run

A execução de teste não inicia o Codex nem carrega credenciais de varredura.

Etapa 6: Executar a primeira varredura

Inicie uma varredura padrão do repositório:

npx @openai/codex-security scan "$REPOSITORY" \
--output-dir "$SCAN_DIR"

Solicite o formato JSON legível por máquina na saída padrão:

npx @openai/codex-security scan "$REPOSITORY" \
--output-dir "$SCAN_DIR" \
--json

Por padrão, o Codex Security atualmente usa:

Modelo: gpt-5.6-sol
Intensidade de raciocínio: xhigh

Configurações de menor custo podem usar outros modelos e níveis de intensidade suportados:

npx @openai/codex-security scan "$REPOSITORY" \
--model gpt-5.6-terra \
--effort high

As configurações de intensidade suportadas incluem:

minimal (mínimo)
low (baixo)
medium (médio)
high (alto)
xhigh (extremamente alto)

Intensidades mais baixas podem reduzir o tempo e o custo, mas também podem diminuir a profundidade da revisão.

Resultados de uma varredura completa

O diretório de resultados padrão pode conter:

codex-security-results/
├── scan-manifest.json
├── findings.json
├── coverage.json
├── report.md
├── artifacts/
└── exports/
└── results.sarif

report.md

Principal relatório legível por humanos.

findings.json

Descobertas estruturadas, incluindo gravidade, confiança, locais afetados, evidências e recomendações de correção.

coverage.json

Cobertura da revisão, exclusões, trabalho adiado, problemas pendentes e avaliação de completude.

scan-manifest.json

Alvos, escopo, informações do produtor e referências de artefatos selados.

artifacts/

Relatórios de vulnerabilidade, arquivos de prova de conceito ou evidências relacionadas (se houver).

Exportação SARIF

O SARIF pode ser usado pelo GitHub Code Scanning e outras ferramentas de segurança compatíveis.

Escaneando apenas áreas importantes

Grandes monorepositórios não precisam necessariamente de uma varredura completa a cada vez.

Selecione caminhos específicos:

npx @openai/codex-security scan "$REPOSITORY" \
--path services/billing \
--path packages/auth

Isso é útil quando um lançamento afeta serviços específicos ou limites de segurança.

Revisando pull requests ou escopo de commits

Escaneie as alterações commitadas entre a revisão base e o HEAD:

npx @openai/codex-security scan "$REPOSITORY" \
--diff origin/main \
--head HEAD

O parâmetro do repositório deve apontar para a raiz da árvore de trabalho do Git, e as revisões necessárias devem existir localmente.

Revisando alterações não commitadas

Escaneie alterações encenadas e não encenadas em relação ao HEAD:

npx @openai/codex-security scan "$REPOSITORY" \
--working-tree \
--base HEAD

Isso é útil antes de criar um pull request ou commitar alterações sensíveis à segurança.

Usando o modo de varredura profunda

Quando a varredura normal não é suficiente, execute uma revisão mais abrangente:

npx @openai/codex-security scan "$REPOSITORY" \
--mode deep

O modo profundo leva mais tempo e pode consumir mais recursos do modelo.

A documentação atual da OpenAI afirma que ela suporta alvos de repositório e caminho, mas não alvos de diff ou árvore de trabalho.

Adicionando arquitetura contextual e informações de segurança

Forneça documentação interna para ajudar o agente a entender corretamente o sistema:

npx

@openai/codex-security scan "$REPOSITORY" \
--knowledge-base /path/to/architecture.md \
--knowledge-base /path/to/security-policies

Contexto útil pode incluir:

• Limites de confiança.
• Arquitetura de autenticação.
• Regras de isolamento de locatários.
• Classificação de dados sensíveis.
• Caminhos de rede esperados.
• Invariantes de segurança.
• Modelos de ameaça.
• Exceções conhecidas.
• Controles compensatórios.

Não inclua informações confidenciais desnecessariamente.

Esses arquivos fazem parte de um fluxo de trabalho de varredura sensível à segurança e devem seguir políticas apropriadas de retenção e controle de acesso.

Controlando o custo da varredura

Defina um limite estimado de custo do modelo em dólares:

npx @openai/codex-security scan "$REPOSITORY" \
--max-cost 5

Solicitações já em andamento podem ser concluídas após o limite ser atingido, portanto, o valor final pode exceder o limite.

Quando uma varredura com limite de custo é interrompida, o Codex Security preserva os resultados existentes.

Resultados parciais não devem ser considerados cobertura completa do repositório.

Adicionando verificação de segurança pré-commit

Instale o hook Git incluído:

npx @openai/codex-security install-hook

Este hook escaneia alterações encenadas e não encenadas antes do commit.

A OpenAI afirma que ele bloqueia:

• Descobertas de alta gravidade.
• Erros de varredura.

Ele não substitui scripts pré-commit existentes.

As equipes devem revisar como ele interage com desempenho local, permissões do desenvolvedor, custos do modelo e hooks de lint ou teste existentes antes de habilitá-lo em toda a organização.

Escaneando vários repositórios

Primeiro, verifique o GitHub CLI:

gh auth login

Inicie o fluxo interativo de descoberta de repositórios:

npx @openai/codex-security bulk-scan

O fluxo interativo atual exclui repositórios arquivados e forks, e requer confirmação antes da varredura.

Use uma lista CSV preparada para atividades de varredura repetíveis:

npx @openai/codex-security bulk-scan repositories.csv \
--output-dir /path/outside/repositories/security-scans \
--workers 4

Executar o mesmo comando novamente pode retomar a atividade de varredura sem reescanear repositórios que já possuem artefatos de resultados completos.

Executando varreduras em lote no Docker

O repositório público contém recursos Docker e Compose.

Com acesso à conta contendo a imagem e o ambiente necessários, um comando de lote de exemplo é:

docker compose run --rm codex-security \
bulk-scan /input/repositories.csv \
--output-dir /output \
--workers 4

A OpenAI recomenda:

• Usar um host Docker Linux.
• Suportar namespaces de usuário não privilegiados.
• Usar diretórios persistentes privados para resultados e estado de login.
• Fornecer segredos via ambiente ou gerenciador de segredos.
• Opcionalmente, habilitar o endurecimento AppArmor quando suportado.

A conteinerização reduz parte da exposição do host, mas não torna a varredura de segurança autorizada livre de riscos.

Rastreando descobertas entre execuções

Liste varreduras anteriores de um repositório:

npx @openai/codex-security scans list "$REPOSITORY"

Inspecione uma varredura salva:

npx @openai/codex-security scans show SCAN_ID

Marque descobertas revisadas como falsos positivos:

npx @openai/codex-security findings false-positive FINDING_OCCURRENCE_ID \
--reason "Esta rota já verificou permissões"

Reexecute uma varredura salva usando suas configurações originais:

npx @openai/codex-security scans rerun SCAN_ID

Corresponda itens de descobertas por causa raiz:

npx @openai/codex-security scans match

PREVIOUS_SCAN_ID CURRENT_SCAN_ID

Comparar resultados de digitalização:

```Bash
npx @openai/codex-security scans compare PREVIOUS_SCAN_ID CURRENT_SCAN_ID

A comparação pode classificar as descobertas como:

• Novas.
• Persistentes.
• Reabertas.
• Resolvidas.
• Desconhecidas.

Quando a digitalização subsequente não cobre a área relevante, as descobertas ausentes permanecem em estado desconhecido.

Usando o SDK TypeScript

O mesmo pacote npm inclui um SDK TypeScript de módulo ECMAScript.

Ele requer Node.js 22 ou superior no servidor, e a digitalização também requer Python 3.10 ou superior.

A integração básica é a seguinte:

import { CodexSecurity } from "@openai/codex-security";

const security = new CodexSecurity();

try {
const result = await security.run("/caminho/para/repositorio", {
outputDir: "/caminho/fora/do/repositorio/resultados",
});

console.log(result.reportPath);
console.log(result.coverage.completeness);
console.log(result.findings.findings.length);
} finally {
await security.close();
}

O SDK suporta fluxos de trabalho de longa duração por meio dos seguintes recursos:

• Verificações de pré-execução.
• Descobertas tipadas.
• Detalhes de cobertura.
• Callbacks de progresso.
• Limite de custo estimado.
• Operações de cancelamento.
• Gerenciamento do ciclo de vida da digitalização.
• Acesso a caminhos de artefatos.

Aplicações reutilizáveis devem criar um cliente, executar as digitalizações necessárias e fechar o cliente para liberar o ambiente de execução isolado.

Adicionando Codex Security ao CI

O guia oficial de CI da OpenAI demonstra o uso de GitHub Actions para digitalização de pull requests.

O padrão recomendado é:

1. Armazenar a chave de API como um segredo protegido do repositório ou da organização.
2. Instalar o Codex Security fora do diretório de checkout do repositório.
3. Fixar a versão do pacote.
4. Fazer checkout do histórico completo do Git, mas sem reter credenciais de checkout.
5. Calcular a base de merge.
6. Digitalizar apenas o diff do pull request.
7. Exportar SARIF.
8. Enviar SARIF para o GitHub Code Scanning.
9. Preservar artefatos da digitalização.
10. Adicionar políticas de severidade somente após revisar a qualidade e o tempo de execução da digitalização.

O exemplo oficial fixa uma versão específica do pacote disponível no momento da publicação. As equipes devem atualizar essa versão intencionalmente após revisar as notas de versão, em vez de executar automaticamente ferramentas de segurança não auditadas com segredos do repositório.

Uma representação concisa da etapa principal de digitalização é a seguinte:

- name: Digitalizar alterações do pull request
env:
OPENAI_API_KEY: ${{ secrets.CODEX_SECURITY_API_KEY }}
BASE_SHA: ${{ github.event.pull_request.base.sha }}
HEAD_SHA: ${{ github.event.pull_request.head.sha }}
SCAN_DIR: ${{ runner.temp }}/codex-security-results
run: |
set -euo pipefail
BASE_REVISION="$(git merge-base "$BASE_SHA" "$HEAD_SHA")"

"$CODEX_SECURITY_BIN" scan . \
--diff "$BASE_REVISION" \
--head "$HEAD_SHA" \
--auth api-key \
--output-dir "$SCAN_DIR" \
--json

> "$RUNNER_TEMP/codex-security.json"

Este trecho pressupõe que o runner já tenha o CLI instalado e verificado, que o head do pull request tenha sido verificado com histórico completo e que CODEX_SECURITY_BIN esteja definido.

Para fluxos de trabalho de produção, use o guia oficial completo de CI, incluindo

ações fixadas, exportação SARIF, permissões, retenção de artefatos e verificações de segurança de branch.

O lugar do Codex Security na arquitetura de segurança

O Codex Security não visa substituir todos os controles de segurança existentes.

Ele pode complementar as seguintes ferramentas:

• Teste estático de segurança de aplicações.
• Análise de composição de software.
• Varredura de segredos.
• Varredura de infraestrutura como código.
• Varredura de contêineres.
• Atualização de dependências.
• Teste de fuzzing.
• Teste dinâmico de aplicações.
• Revisão humana de código.
• Teste de penetração.
• Programas de recompensa por vulnerabilidades.
• Monitoramento de produção.

Sua vantagem única está na capacidade de raciocinar contextualmente sobre a estrutura do repositório e a intenção do sistema.

Uma arquitetura de segurança madura pode usar scanners determinísticos para padrões conhecidos de alto volume e scanners baseados em agentes para lógica entre arquivos, análise de explorabilidade, evidências e recomendações de correção.

O que o Codex Security não pode garantir

Ele não pode provar que um repositório é seguro

Nenhum scanner pode provar a ausência de todas as vulnerabilidades em uma base de código real arbitrária.

Cobertura parcial ou desconhecida torna essa limitação ainda mais relevante.

A verificação não é universalmente aplicável

Algumas descobertas podem ser testadas em ambientes isolados.

Outras dependem de:

• Dados de produção.
• Serviços externos.
• Configurações de infraestrutura.
• Hardware.
• Credenciais.
• Lógica de negócios.
• Comportamento do usuário.

Uma descoberta sem prova automatizada não é automaticamente um falso positivo, e uma prova verificada também não revela todas as variantes dessa vulnerabilidade.

Descobertas de IA ainda exigem revisão humana

Os modelos podem interpretar mal a arquitetura, superestimar o impacto, propor patches incompletos ou introduzir regressões.

Os responsáveis pela segurança devem revisar as evidências e as soluções de correção.

Pacotes de código aberto ainda exigem chamadas de modelo

O código-fonte do pacote é público, mas a digitalização padrão não é um binário estático local totalmente independente do acesso de inferência.

O uso do modelo pode envolver custos, tratamento de dados e considerações de autorização.

Saídas sensíveis precisam de proteção

O diretório de resultados pode ser mais sensível do que a saída comum de build.

Não envie descobertas detalhadas, arquivos de prova de conceito ou trechos de código-fonte vulneráveis para artefatos públicos.

Acesso à rede é restrito a usos autorizados

Use a ferramenta apenas em repositórios e sistemas que você possui ou para os quais tenha autorização explícita de avaliação.

O controle de acesso da OpenAI não substitui a autorização legal.

Scanners de segurança também precisam de um modelo de ameaças

A maior vantagem conceitual do Codex Security é também uma necessidade prática.

Os agentes precisam de contexto preciso.

Apenas o repositório pode não explicar:

• Qual serviço é acessível publicamente.
• Qual provedor de identidade é confiável.
• Se existem limites de rede.
• Quais dados são sensíveis.
• Quais verificações de autorização são executadas a montante.
• Qual recurso de implantação está desabilitado.
• Quais riscos a organização aceitou.

Contexto deficiente pode levar a descobertas de baixa qualidade.

As equipes devem tratar modelos de ameaças editáveis e bases de conhecimento como ativos de segurança de primeira classe, não como enfeites opcionais de prompt.

Perguntas frequentes

O que é o Codex Security?

O Codex Security é um agente de segurança de aplicações da OpenAI para descobrir, verificar, priorizar e ajudar a corrigir vulnerabilidades. Ele surgiu do projeto interno Aardvark e agora está disponível.

É implementado por meio de plugins, CLI, SDK TypeScript e fluxos de trabalho em nuvem conectados a repositórios.

O Codex Security é totalmente open source?

O CLI e o SDK TypeScript estão disponíveis no GitHub sob a licença Apache 2.0.

Licença publicada publicamente. O modelo subjacente da OpenAI, o serviço de nuvem gerenciado, os resultados de descobertas protegidas e o acesso irrestrito de segurança cibernética não foram publicados como componentes de código aberto ou de pesos abertos.

Qualquer pessoa pode instalar e executar o Codex Security?

Qualquer pessoa pode acessar os pacotes públicos, mas a execução de varreduras requer acesso ao Codex Security. Algumas varreduras de repositório inteiro ou recursos avançados de rede também podem exigir o "Trusted Access for Cyber" (Acesso Confiável para Cibersegurança).

Qual modelo o Codex Security utiliza?

A documentação atual da CLI afirma que as varreduras usam por padrão o GPT-5.6 Sol, com nível de esforço de raciocínio xhigh. Os usuários podem escolher outros modelos e níveis de esforço suportados, e o repositório público também documenta configurações selecionadas de fornecedores terceirizados.

O Codex Security pode escanear pull requests?

Sim. A CLI pode escanear as alterações confirmadas entre a revisão base e a revisão de cabeçalho, portanto é adequada para fluxos de trabalho de pull requests. A OpenAI também fornece um guia oficial de GitHub Actions, com suporte para exportação SARIF e retenção de artefatos.

O Codex Security corrige vulnerabilidades automaticamente?

Ele pode sugerir correções delimitadas e ajudar a validar se uma alteração resolve uma descoberta. As varreduras geram apenas relatórios por padrão; os humanos devem revisar, testar e aprovar os patches antes de mesclar ou implantar.

O Codex Security pode ser executado em Docker?

O repositório inclui recursos de Docker e Docker Compose para varreduras em lote não interativas. A OpenAI recomenda armazenamento persistente privado, gerenciamento de chaves, recursos de isolamento Linux suportados e endurecimento opcional com AppArmor.

Um relatório limpo do Codex Security prova que meu aplicativo é seguro?

Não. A cobertura pode ser completa, parcial ou desconhecida, e nenhum scanner automatizado pode garantir que aplicativos complexos estejam livres de vulnerabilidades. Use o Codex Security como parte de um programa mais amplo de desenvolvimento seguro.

Ferramentas relacionadas

• Codex Security: Visão geral oficial de plugins, CLI, SDK, scanner de nuvem e fluxos de trabalho suportados.
• Repositório GitHub do Codex Security: Código-fonte Apache-2.0 da CLI, SDK TypeScript, recursos Docker e fluxos de contribuição.
• Codex Security no npm: Pacotes publicados para instalar a CLI e o SDK.
• Codex CLI: Agente de codificação local de código aberto da OpenAI e host de plugins.
• GitHub Code Scanning: Interface de resultados de vulnerabilidades compatível com SARIF do GitHub.
• CodeQL: Mecanismo de análise semântica de código do GitHub para detecção de vulnerabilidades baseada em consultas.
• Semgrep: Plataforma de análise estática baseada em regras que complementa revisões de segurança por agentes.
• OWASP Juice Shop: Um aplicativo intencionalmente vulnerável para treinamento de segurança autorizado e avaliação de scanners.

Links relacionados

• Documentação do Codex Security: Ponto de partida oficial para interfaces de produto e fluxos de trabalho.
• Início rápido da CLI do Codex Security: Instruções oficiais de instalação, autenticação, varredura, histórico, orçamento, operações em lote e Docker.
• SDK TypeScript do Codex Security: Documentação oficial de configuração do SDK, ciclo de vida de varredura, resultados tipados, progresso e cancelamento.
• Executando o Codex Security em CI: Fluxo de trabalho completo de GitHub Actions e SARIF da OpenAI.
• Prévia de pesquisa do Codex Security: Artigo de lançamento de março de 2026 e métricas de prévia da OpenAI.
• Apresentando o Aardvark: Descrição original do pesquisador de segurança inteligente que se tornou o Codex Security.
• Iniciativa de segurança Daybreak: Atualização de junho de 2026 da OpenAI sobre a escala do Codex Security, trabalho de segurança de código aberto e ferramentas cibernéticas defensivas.

Resumo

A OpenAI tornou o código aberto da CLI e do SDK TypeScript do Codex Security, fornecendo aos desenvolvedores uma base pública sob licença Apache-2.0 para varredura de repositórios, revisão de alterações, histórico de varreduras, validação de correções, atividades em lote, exportação SARIF, verificações de CI e integrações de segurança personalizadas.

O agente difere de scanners de padrões básicos: ele constrói contexto do repositório e um modelo de ameaças, busca vulnerabilidades nesse contexto, valida problemas suspeitos sempre que possível e propõe correções delimitadas para revisão humana.

Esta versão não é um modelo de segurança local irrestrito. A execução de varreduras ainda requer acesso autorizado de inferência, e certos fluxos de trabalho avançados de segurança cibernética podem exigir o "Trusted Access for Cyber". Descobertas sensíveis e trechos de código-fonte também exigem controles cuidadosos de armazenamento e retenção.

O Codex Security é mais útil em um programa de segurança de aplicações em camadas — e não como prova de que um repositório está livre de vulnerabilidades.

A mudança prática é que, desde que as equipes apliquem rigorosamente autorização, modelagem de ameaças, validação e aprovação humana em seus processos, as revisões de segurança agora podem se aproximar da velocidade do desenvolvimento assistido por IA.