A OpenAI lançou silenciosamente o código-fonte da interface de linha de comando e do SDK TypeScript do Codex Security. O pacote público @ope...

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:
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.
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:
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 repositório público no GitHub contém:
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.
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.
Instalar o pacote npm não equivale a obter permissão para executar cada varredura.
A documentação da OpenAI afirma:
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.
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:
O problema não é apenas que os desenvolvedores carecem de relatórios de vulnerabilidades.
Muitos mantenedores já recebem relatórios em excesso, incluindo:
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.
A OpenAI descreve o sistema como um fluxo de trabalho de segurança de aplicativos em múltiplas etapas.
O Codex Security começa estudando o repositório para entender a estrutura relacionada à segurança do projeto.
Ele tenta identificar:
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.
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:
O scanner pode revisar:
Quando possível, o Codex Security tenta validar problemas de alto sinal em um ambiente isolado.
A validação ajuda a responder:
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.
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.
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.
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.
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.
A OpenAI afirma que, em um período de 30 dias, o Codex Security:
| Métrica | Resultado relatado pela OpenAI |
|---|---|
| Número de commits varridos | Mais de 1,2 milhão |
| Descobertas críticas | 792 |
| Descobertas de alta gravidade | 10.561 |
| Commits varridos com problemas críticos | Menos de 0,1% |
A OpenAI também relatou melhorias na versão beta:
A OpenAI afirmou posteriormente que o Codex Security Cloud passou a ter:
| Métrica | Resultado relatado pela OpenAI |
|---|---|
| Número de bases de código varridas | Mais de 30.000 |
| Número de commits varridos | Mais de 30 milhões |
| Descobertas marcadas manualmente como corrigidas | Mais de 70.000 |
| Correções identificadas automaticamente | Mais de 500.000 |
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.
O Codex Security está disponível através de várias interfaces relacionadas.
| Interface | Uso principal |
|---|---|
| Plugin Codex Security | Varredura e correção interativas no aplicativo de desktop do ChatGPT ou na CLI do Codex |
| Workbench de segurança | Visualizar varreduras salvas, descobertas, histórico do repositório, cobertura e artefatos |
| CLI do Codex Security | Fluxos de trabalho locais repetíveis, terminal, pre-commit, em lote e CI |
| SDK TypeScript | Incorporar varredura e controle de ciclo de vida em aplicativos ou ferramentas de desenvolvedor |
| Codex Security Cloud | Varrer repositórios GitHub conectados através do Codex Cloud |
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.
Os comandos a seguir seguem a documentação oficial atual da CLI da OpenAI.
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
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
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.
A OpenAI recomenda armazenar os resultados fora do repositório varrido.
Os relatórios podem conter:
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
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.
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.
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.mdPrincipal relatório legível por humanos.
Descreva sua ideia uma vez e o We0 AI pode gerar um site de apresentacao, paginas e CMS, alem de ajudar a atrair clientes e trafego apos o lancamento.
Uma geração completa de projetos para registro gratuito
Melhor para experimentar um fluxo de geração completo e ver rapidamente um primeiro rascunho do projeto.
findings.jsonDescobertas estruturadas, incluindo gravidade, confiança, locais afetados, evidências e recomendações de correção.
coverage.jsonCobertura da revisão, exclusões, trabalho adiado, problemas pendentes e avaliação de completude.
scan-manifest.jsonAlvos, 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).
O SARIF pode ser usado pelo GitHub Code Scanning e outras ferramentas de segurança compatíveis.
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.
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.
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.
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.
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:
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.
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.
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:
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.
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.
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:
A conteinerização reduz parte da exposição do host, mas não torna a varredura de segurança autorizada livre de riscos.
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:
Quando a digitalização subsequente não cobre a área relevante, as descobertas ausentes permanecem em estado desconhecido.
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:
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.
O guia oficial de CI da OpenAI demonstra o uso de GitHub Actions para digitalização de pull requests.
O padrão recomendado é:
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 Codex Security não visa substituir todos os controles de segurança existentes.
Ele pode complementar as seguintes ferramentas:
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.
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.
Algumas descobertas podem ser testadas em ambientes isolados.
Outras dependem de:
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.
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.
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.
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.
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.
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:
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.
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 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 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).
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.
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.
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 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.
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.
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.
Comece com uma frase e tenha um site completo em minutos.