OpenAI abre ferramenta de segurança e acende debate sobre o scanner
CLI e SDK analisam código, validam falhas e integram modelos externos, mas o debate mira o que existe além da varredura.
CLI e SDK analisam código, validam falhas e integram modelos externos, mas o debate mira o que existe além da varredura.
A OpenAI publicou uma CLI e um SDK em TypeScript para encontrar, validar e corrigir vulnerabilidades no código. A ferramenta roda pelo pacote @openai/codex-security, integra o Codex Security e recebeu 597 pontos e 229 comentários no Hacker News. Ela serve para equipes que querem levar análise de segurança ao terminal e ao CI, com histórico de scans, comparação de achados e controles de execução. A disputa começa no scanner.
O usuário instala o pacote com npm, faz login e executa npx @openai/codex-security scan .. A ferramenta exige Node.js 22.13.0 ou superior na linha 22.x, Node.js 24.x ou Node.js 26.x, além de Python 3.10 ou posterior e acesso ao Codex Security. Ela também aceita OPENAI_API_KEY ou CODEX_API_KEY no CI, sem guardar essas chaves no diretório de credenciais ou no keyring do sistema.
A OpenAI permite escolher modelos e provedores. O comando aceita --provider openrouter com anthropic/claude-sonnet-4.5 e --provider fireworks com accounts/fireworks/models/qwen3-235b-a22b. O repositório também mostra o uso de gpt-5.6-terra, com esforço alto, e modos de análise profunda que distribuem trabalho entre workers e subagentes. Há controle fino.
O SDK expõe a classe CodexSecurity para executar scans em TypeScript. O sistema guarda o histórico no diretório de estado do Codex Security e compara dois scans por causa raiz, em vez de apenas confrontar linhas alteradas. A comparação classifica achados como novos, persistentes, reabertos, resolvidos ou desconhecidos. Se a cobertura ficar incompleta, o sistema mantém o achado como desconhecido.
Esses recursos deslocam o debate do modelo para o fluxo que o cerca. O comentário mais votado de knighthacker resume esse lado: “O scanner é a parte menos interessante. O harness ao redor dele é o produto: deduplicação entre execuções, rastreamento de falsos positivos, controles de orçamento e bloqueio no CI.” Para esse grupo, a utilidade nasce de comparar resultados, controlar custo e decidir quando uma falha impede o merge. O modelo sozinho não resolve esse trabalho.
A outra linha de crítica questiona o que a ferramenta aceita analisar e como prova que o usuário tem autorização. minraws escreveu: “Parece que recebi vários erros dizendo que vocês estão tentando fazer algo que não permitimos... muito irritante. Eles podem explicar em que tipos de projeto isso funciona e como verifica que eu sou dono? Ele simplesmente não funcionará no Linux kernel mesmo nos meus próprios patches?” A dúvida atinge o uso em projetos grandes, sensíveis ou mantidos por terceiros.
O repositório informa que alguns pedidos de cibersegurança e achados protegidos exigem aprovação pelo Trusted Access for Cyber. O usuário precisa verificar ou solicitar acesso em chatgpt.com/cyber. A documentação mostrada não responde, por si só, como o sistema distingue um projeto autorizado de um projeto sem permissão. Esse ponto continua aberto.
petesergeant reduziu a primeira leitura a outra hipótese: “Não acho que haja muito mais nisso além de um wrapper conveniente de CI em torno dos modelos existentes.” Depois, ele apontou que havia mais conteúdo no SDK. A reação mostra a divisão central: uma parte avalia a ferramenta pelo modelo que encontra a vulnerabilidade; outra avalia a camada que organiza execuções, resultados e decisões no pipeline.
Michael, cofundador da Promptfoo e uma das pessoas que trabalham na CLI, reconheceu as falhas de autenticação no thread: “Nós acabamos de abrir o código, e ainda há bastante coisa para melhorar. Esperem que o produto evolua rapidamente.” A OpenAI coletou cinco comentários do debate. O volume maior aparece no placar: 597 pontos e 229 comentários.
As equipes que avaliam a ferramenta precisam separar duas decisões. A primeira mede se o scanner encontra e valida falhas relevantes no código. A segunda verifica se autenticação, permissões, falsos positivos, orçamento e bloqueio no CI cabem no processo da empresa. O pacote oferece mecanismos para essa segunda camada, mas o thread não apresenta benchmark nem evidência comparativa.
Também falta uma resposta pública sobre o alcance dos projetos protegidos e sobre a política de autorização para repositórios específicos. Sem essa resposta, a adoção depende de testes controlados e da leitura dos requisitos de Trusted Access for Cyber. O debate não escolhe entre scanner e harness. Ele mostra que a decisão técnica precisa avaliar os dois.