Análise de vulnerabilidades com Codex Security: configuração, custos e CI

O que o Codex Security oferece para análise de vulnerabilidades após o DevDay?

O Codex Security dá à equipe três oportunidades de identificar código vulnerável: no repositório, no pull request e na cópia de trabalho do desenvolvedor. Pense em uma vistoria de um prédio, uma avaliação de uma reforma proposta e uma checagem antes de o profissional sair da obra. Cada uma enxerga uma parte diferente do mesmo sistema.

Um pull request é uma proposta de alteração de código que aguarda revisão. A CLI é a ferramenta de linha de comando executada no terminal; CI é o processo de verificações automatizadas acionado quando o código muda.

O Cloud investiga achados, elimina duplicatas e prepara correções mesmo com seu computador fechado. A OpenAI ainda o classifica como uma prévia de pesquisa. O anúncio do DevDay de 29 de setembro acrescenta informações sobre agendamento e disponibilidade; ele não transforma o Cloud em um produto de disponibilidade geral. Resumo do DevDay, status atual do produto.

Equipes que usam GitLab devem começar pela CLI. A configuração atual do Security Cloud conecta o GitHub. O suporte geral do Codex a merge requests do GitLab não comprova suporte do Security Cloud ao GitLab. O guia específico de GitLab CI/CD documenta uma forma compatível de executar verificações de segurança nesse ambiente.

Em quais planos está disponível e quanto custa para cinco pessoas?

Pro, Business, Enterprise e Edu têm acesso ao Codex Security Cloud, segundo o anúncio datado do DevDay e a Central de Ajuda atual. O Security Review lista os mesmos planos e exclui explicitamente o Plus. Ainda é preciso habilitar as permissões do workspace e o acesso aos repositórios. Disponibilidade do Cloud, acesso ao Security Review.

Para uma empresa pequena, a comparação relevante de assinatura é a de cinco licenças Standard Business:

A cobrança por tokens acompanha o volume que o modelo lê e gera. Os preços por licença podem variar conforme o país e a moeda. Os cálculos da assinatura seguem as perguntas frequentes atuais do Business. As orientações atuais de cobrança do Cloud dizem que clientes existentes recebem um aviso e precisam aderir antes de começar o uso pago; sem saldo para custeá-las, as varreduras são pausadas. Não há um orçamento fechado que inclua as varreduras para uma equipe de cinco pessoas. Cobrança do Cloud, diferença entre preços de assinatura e API.

Se você já paga pelo Business, o custo adicional de licenças pode ser zero. Ainda assim, o uso das varreduras e das revisões precisa entrar no orçamento. O total mensal soma as licenças, o uso aplicável do Cloud, as varreduras no CI pela API, o tempo do runner e qualquer assinatura opcional de um painel de segurança.

Não conte com um novo primeiro mês grátis. A oferta de uso gratuito estava ligada ao lançamento de 6 de março e cobria o mês seguinte. As páginas atuais do produto e de cobrança não confirmam uma nova oferta em 30 de setembro. Condições do lançamento original, condições atuais de cobrança.

Como referência de preço, o produto pago Code da Semgrep lista $30 por colaborador por mês, ou $150 para cinco colaboradores. A Free Edition também permite até 10 repositórios e 10 colaboradores. Assim, uma equipe de cinco pessoas pode avaliar ambos sem partir da ideia de que todo scanner existente exige uma compra. Como as coberturas são diferentes, o preço sozinho não deve definir suas ferramentas de segurança. Preços da Semgrep.

Varredura de vulnerabilidades: conecte o repositório e revise a correção

Comece por uma aplicação que você conhece e por alguém capaz de explicar suas regras de acesso. Um modelo de ameaças é uma descrição breve do que a aplicação protege, de quem pode acessá-la e de onde ela confia em outro sistema. É a planta do prédio que indica ao inspetor quais portas devem ficar trancadas.

1. Abra Plugins no ChatGPT, pelo aplicativo para desktop ou pela web. Instale e habilite Codex Security Cloud e abra Security Cloud.
2. Selecione New scan. Se solicitado, conecte o GitHub e conceda acesso ao repositório que deseja avaliar.
3. Escolha o repositório e um Cloud environment compatível. Se necessário, crie um ambiente com as dependências e a configuração de testes exigidas pelo projeto.
4. Em What to scan, escolha Repository e depois Start scan. Acompanhe o progresso em Scans.
5. Abra Findings. Leia o código afetado, as evidências de validação e as orientações de correção. Uma tentativa de validação que falhou deixa a evidência em aberto; não descarta a vulnerabilidade.
6. Quando Fix with Codex estiver disponível, gere o patch, examine-o e, após a revisão, use Create draft pull request. Execute os testes habituais e envolva o responsável pelo código antes do merge.

Esses são os controles atuais de configuração do Cloud. O ambiente facilita a reprodução de possíveis falhas, mas não garante a validação de todos os problemas. Como funciona a validação.

Para verificações contínuas, crie outra varredura com Commit changes. Em Repositories, abra Monitoring settings para escolher o ambiente, definir a janela de histórico e habilitar ou pausar o monitoramento. Atualize o modelo de ameaças em Project context conforme a arquitetura mudar. O Cloud também permite agendar varreduras do repositório, como descrito no DevDay; o passo a passo atual de configuração não informa frequências nem cotas de agendamento, portanto não há uma franquia de varreduras diárias que possa ser presumida. Configuração do monitoramento, varreduras agendadas.

Um repositório analisado de verdade: como fazer a triagem dos achados no Gogs

O Gogs mostra por que um achado precisa do contexto da implantação antes de virar uma tarefa. A OpenAI cita esse repositório e as vulnerabilidades abaixo entre as descobertas publicadas do Codex Security. Trata-se de um caso de varredura publicado pelo fornecedor, não de uma nova varredura realizada para este artigo. As decisões de triagem abaixo são recomendações baseadas nos avisos de segurança dos mantenedores. Achados divulgados pela OpenAI.

Um número CVE identifica uma vulnerabilidade divulgada. A autenticação de dois fatores, ou 2FA, acrescenta uma segunda verificação no login, além da senha.

O primeiro aviso lista correções nas versões 0.13.4 e 0.14.0+dev; o segundo lista a 0.14.0. Essas são as primeiras versões corrigidas segundo avisos históricos, não uma recomendação para escolher uma versão antiga hoje. Confira a versão atualmente suportada pelo projeto antes de atualizar. Aviso do Gogs sobre códigos de recuperação, aviso do Gogs sobre uploads.

Mantenha o registro de triagem enxuto: revisão implantada, ponto de entrada acessível, evidências, responsável, ação e teste que verificará a correção. Um achado pode ser aceito, descartado por um motivo concreto ou mantido em aberto para investigação. Só o marque como corrigido depois de verificar a mudança de comportamento.

Use o mesmo rigor na sua própria varredura. Os relatórios salvos pela CLI registram achados e cobertura. Se uma varredura posterior omitir um achado anterior, isso não prova que ele foi corrigido; o feedback de falso positivo também não suprime permanentemente aquela classe de vulnerabilidade. Histórico de achados e feedback.

Ative a revisão automática de segurança

Depois da avaliação inicial do repositório, acrescente a revisão de pull requests como próxima camada. Em Codex settings, escolha o repositório. Em Review security vulnerabilities, habilite Auto security review e escolha All PRs, ou as preferências pessoais se quiser que cada pessoa escolha aderir ao recurso.

Escolha On PR open para uma revisão inicial, On every push para repetir a revisão a cada mudança de código ou Whenever code review runs para executá-la junto com o Code Review geral. Uma varredura prévia do Security Cloud é opcional. Você pode reaproveitar o modelo de ameaças dela ou informar o caminho de um arquivo de modelo de ameaças no repositório. Configuração do Security Review.

Por padrão, as revisões automáticas relatam achados de severidade alta e crítica. As revisões solicitadas manualmente também incluem os de severidade média por padrão. É possível alterar esses limites de forma independente. Para solicitar uma revisão manual, comente @codex security review no PR e abra o Security Report da tarefa associada para consultar todas as evidências. Os achados publicados no GitHub herdam a visibilidade do PR.

Essa revisão é focada em segurança. O Code Review geral também pode apontar problemas de segurança, por isso pode haver sobreposição. O guia mais amplo de revisão com Codex ajuda a decidir onde cada revisão entra no processo.

Instale a CLI para varreduras locais e verificações antes do commit

A CLI oferece o mesmo tipo de investigação de repositórios em um pacote que pode ser usado em scripts. O código-fonte tem licença Apache 2.0 e o pacote público no npm é @openai/codex-security. Ter o código-fonte público não dá acesso irrestrito às varreduras. Código-fonte e licença oficiais, pré-requisitos da CLI.

O acesso incluído ao modelo Daybreak Blue no Cloud fica restrito ao Cloud; ele não dá acesso a esse modelo por outros produtos Security nem pela API. Verifique a forma de login e o acesso ao modelo que pretende usar antes de levar uma varredura para o CI. Limites de acesso entre produtos.

É preciso distinguir as datas: o repositório no GitHub foi criado em 13 de julho de 2026; seu histórico público atual começa com um commit de inicialização de 15 de julho, enquanto as publicações no npm começam em 28 de julho. A data de 13 de julho, sozinha, não prova que a CLI licenciada foi disponibilizada no npm naquele dia. Fixe a versão do pacote para ter uma configuração reproduzível. Metadados do repositório, commit inicial, histórico de publicação no npm.

Use Node.js 22.13.0 ou posterior na série 22, Node 24 ou Node 26, além de Python 3.10 ou posterior. A partir do seu repositório, faça login e mantenha a saída fora da cópia local:

npx @openai/codex-security@0.1.31 login
npx @openai/codex-security@0.1.31 scan . --auth chatgpt \
  --output-dir ../codex-security-results --dry-run
npx @openai/codex-security@0.1.31 scan . --auth chatgpt \
  --output-dir ../codex-security-results

Leia report.md, findings.json e coverage.json. A cobertura pode ser completa, parcial ou desconhecida; examine as áreas deixadas para depois e as perguntas em aberto mesmo quando nenhum achado for relatado. Esses comandos seguem o guia de início rápido da CLI.

Instale a verificação de pré-commit com npx @openai/codex-security@0.1.31 install-hook. Ela analisa alterações tanto preparadas quanto não preparadas para o commit, bloqueia por padrão achados de severidade alta e erros de varredura e preserva um script de pré-commit existente. Como enxerga os dois tipos de alteração, mantenha experimentos sem relação com o trabalho fora da cópia local ao interpretar o resultado. Comportamento do hook.

A versão do pacote e os comandos acima foram conferidos durante a preparação deste artigo. Não se afirma aqui a realização de uma varredura local autenticada, uma duração medida ou um custo de varredura.

Integre a CLI ao CI e guarde o SARIF

SARIF é um formato padronizado de arquivo para achados de segurança, que permite a outra ferramenta mostrar cada problema junto de sua localização no código-fonte. Exportar o arquivo e contratar um painel hospedado são decisões separadas.

Crie no CI um secret chamado CODEX_SECURITY_API_KEY para uma conta ou organização de API com o acesso necessário às varreduras. A chave permite que o runner se autentique sem um login interativo no ChatGPT. Este exemplo de GitHub Actions analisa PRs confiáveis do próprio repositório, compara as revisões exatas da base e do head, exporta SARIF e preserva os resultados. Ele adapta o modelo oficial de CI, fixa a versão do pacote verificada para este artigo e começa bloqueando achados de severidade alta. Remova --fail-on-severity high para uma adoção que apenas informe os achados; erros de varredura e cobertura incompleta continuam exigindo atenção.

Salve como .github/workflows/codex-security.yml:

name: Codex Security
on:
  pull_request:
jobs:
  security:
    if: github.event.pull_request.head.repo.full_name == github.repository && github.actor != 'dependabot[bot]'
    runs-on: ubuntu-latest
    permissions:
      contents: read
    steps:
      - uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020
        with:
          node-version: '26'
      - uses: actions/setup-python@5fda3b95a4ea91299a34e894583c3862153e4b97
        with:
          python-version: '3.14'
      - name: Install trusted CLI outside the checkout
        run: npm install --prefix "$RUNNER_TEMP/security-cli" --ignore-scripts --no-audit --no-fund @openai/codex-security@0.1.31
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1
        with:
          ref: ${{ github.event.pull_request.head.sha }}
          fetch-depth: 0
          persist-credentials: false
      - name: Scan and export
        env:
          OPENAI_API_KEY: ${{ secrets.CODEX_SECURITY_API_KEY }}
          CODEX_SECURITY_STATE_DIR: ${{ runner.temp }}/security-state
          BASE_SHA: ${{ github.event.pull_request.base.sha }}
          HEAD_SHA: ${{ github.event.pull_request.head.sha }}
        run: |
          set -euo pipefail
          cli="$RUNNER_TEMP/security-cli/node_modules/.bin/codex-security"
          out="$RUNNER_TEMP/security-results"
          base="$(git merge-base "$BASE_SHA" "$HEAD_SHA")"
          scan_exit=0
          "$cli" scan . --diff "$base" --head "$HEAD_SHA" \
            --auth api-key --output-dir "$out" \
            --fail-on-severity high --json \
            > "$RUNNER_TEMP/security-result.json" || scan_exit=$?
          if test -f "$out/scan-manifest.json"; then
            "$cli" export "$out" --export-format sarif \
              --source-root "$GITHUB_WORKSPACE" \
              --output "$out/results.sarif"
          fi
          exit "$scan_exit"
      - name: Keep reports, including SARIF when available
        if: always()
        uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a
        with:
          name: codex-security-results
          path: |
            ${{ runner.temp }}/security-results
            ${{ runner.temp }}/security-result.json
          retention-days: 7

O workflow preserva o código de saída da varredura enquanto exporta os resultados selados disponíveis. Código de saída 0 significa que o escopo selecionado tem cobertura completa e atende à sua política de severidade. Código de saída 1 significa que um achado atinge o limite definido. Código de saída 2 indica um erro ou cobertura incompleta, incluindo cobertura parcial ou desconhecida. Uma varredura informativa com status verde ainda é um relatório sobre o escopo escolhido, não um certificado de segurança. Exportação de artefatos e códigos de saída.

Para exibir o SARIF como alertas de análise de código no GitHub, acrescente a etapa upload-sarif do modelo oficial e suas permissões. Repositórios públicos são compatíveis; repositórios privados e internos precisam ter GitHub Code Security habilitado. Guardar o SARIF como artefato, como no exemplo acima, permite examiná-lo sem prometer um painel gratuito para repositórios privados. Requisitos do GitHub para SARIF.

No GitLab, use o modelo de CI/CD para produção da OpenAI, que cobre diffs de merge requests, varreduras da branch padrão protegida e varreduras agendadas por adesão. A ingestão nativa de SARIF exige GitLab Ultimate 19.2 ou posterior. Os relatórios salvos como artefatos comuns são uma alternativa separada caso o acesso a esse painel não esteja disponível.

As execuções no CI usam as permissões do runner e podem herdar seu ambiente. Mantenha credenciais sem relação com a tarefa fora do job e use alterações de código confiáveis. Acrescente um valor para --max-cost depois de definir um orçamento; trata-se de um limite estimado, que pode ser ultrapassado por solicitações já em andamento. Pré-requisitos de CI, controles de custo.

Cinco usos que vale testar, em ordem de retorno

1. Uma equipe SaaS que altera login ou acesso entre tenants. Faça a varredura inicial, melhore o modelo de ameaças e habilite o Security Review nos PRs. O retorno é uma chance maior de identificar uma falha nos limites entre contas antes de os clientes esbarrarem nela. Mantenha o responsável pela autenticação na revisão.
2. Um fundador que assume uma aplicação antiga. Faça uma varredura do repositório e atribua responsáveis aos achados aceitos antes de acrescentar funcionalidades. Isso pode transformar um backlog desconhecido em uma lista curta de trabalho respaldado por evidências, em vez de um pedido genérico para reescrever tudo.
3. Uma equipe GitLab sem um scanner de segurança gerenciado. Execute verificações pela CLI nos diffs dos merge requests e guarde o SARIF e a cobertura como artefatos. O retorno é um registro de revisão reproduzível dentro do sistema de CI que a equipe já opera.
4. Uma agência que mantém vários repositórios de clientes. Use as varreduras em lote da CLI que podem ser retomadas, com contexto de arquitetura e histórico de achados separados para cada cliente. Isso pode reduzir a repetição da configuração e tornar a passagem da manutenção mais precisa. Varreduras em lote.
5. Uma equipe com um backlog de segurança cheio de ruído. Use o fluxo de triagem de backlog do Codex Security para confrontar resultados de scanners com o código e os controles atuais. O retorno são evidências para decidir quais tarefas merecem tempo de engenharia. Mantenha os scanners originais em execução. Triagem de backlog.

Dois serviços que você pode criar com essas ferramentas

A oportunidade mais forte é implantar e manter a segurança para equipes pequenas. Um fundador paga pela configuração, pelo trabalho de modelagem de ameaças, pela integração com CI e pela triagem humana recorrente, em vez de mais uma interface em torno de um botão de varredura.

As estimativas do DataForSEO para o Google nos Estados Unidos retornaram 720 buscas mensais por “software vulnerability scanning” e 90 por “code security scanner” nesta apuração. São buscas, não clientes pagantes, e a expressão mais ampla também inclui trabalho fora da varredura de repositórios. O preço de $150 por mês do Semgrep Code para cinco colaboradores oferece uma referência concreta para um serviço de escopo restrito. Referência de preço da Semgrep.

A menor versão vendável poderia cobrir um repositório pertencente ao cliente, um modelo de ameaças documentado, o workflow de CI e uma fila de achados revisados. Use os acessos do cliente e deixe os custos de uso visíveis. A dificuldade é operacional: você precisa conhecer a aplicação o suficiente para rejeitar achados enganosos e revisar correções sensíveis. Vender uma garantia de segurança iria além do que as evidências sustentam.

Uma segunda oportunidade é um pacote de evidências de release para agências. Uma agência poderia oferecer, em cada entrega ao cliente, um registro datado do escopo da varredura, dos achados aceitos, das lacunas restantes e das correções verificadas. A consulta ampla “vulnerability scanning tools” tem uma estimativa de 1,900 buscas mensais nos Estados Unidos, mas mede o interesse por ferramentas em vários domínios de segurança. Ela sustenta uma hipótese para investigar junto aos clientes, não a demanda por esse produto específico.

O MVP poderia reunir artefatos de varredura salvos e uma triagem aprovada em um relatório compacto para o cliente. A dificuldade está na portabilidade e na confiança: o SARIF pode ser transferido, mas o valor do seu serviço vem de uma interpretação honesta, incluindo a cobertura incompleta. Um relatório gerado sozinho é fácil de copiar. Todos os volumes de busca são estimativas mensais de palavras-chave do DataForSEO obtidas em 30 de setembro de 2026; nenhum comprova um mercado em crescimento ou intenção de compra.

Quais verificações continuam necessárias?

Mantenha a varredura de dependências, que verifica os pacotes e as versões importados pela aplicação, e a varredura de segredos, que detecta credenciais expostas. A análise do repositório pode investigar um problema relacionado, mas não funciona como inventário completo de pacotes nem como sistema de monitoramento de credenciais.

Mantenha o SAST determinístico quando suas verificações amplas e reproduzíveis ou seus requisitos de garantia forem relevantes. A OpenAI afirma explicitamente que o Codex Security complementa o SAST. Você pode testar o agente sem comprar uma suíte paga; isso não torna redundante a cobertura existente. Perguntas frequentes do Cloud.

Mantenha uma pessoa na revisão do código de autorização. A autenticação identifica quem você é; a autorização define a quais dados de cliente ou ações você pode ter acesso. Essas regras dependem da intenção do negócio e de premissas de implantação que um scanner pode interpretar mal. Peça ao responsável para revisar os limites entre tenants, as permissões administrativas, os fluxos de recuperação e os testes de regressão. Essa é uma recomendação de engenharia, coerente com a necessidade de avaliação humana de ameaças declarada pelo fornecedor.

Mantenha também limites para o ambiente de varredura. O Cloud usa contêineres isolados; as varreduras locais e no CI usam suas permissões locais. O guia de segurança de sandbox aborda a tarefa separada de controlar o que um agente pode acessar.

Codex ou a revisão de segurança do Claude Code?

Continue com o Claude Code se sua necessidade imediata for verificar a segurança de alterações pendentes e a equipe já o utilizar. Execute /security-review localmente ou configure a GitHub Action de revisão de segurança da Anthropic para comentários nos PRs e filtragem de falsos positivos. Esses recursos estão disponíveis para usuários do Claude Code, incluindo os planos pagos Pro/Max e contas API Console. Configuração da revisão de segurança do Claude.

Escolha o Codex Security Cloud quando o fluxo desejado incluir uma avaliação inicial gerenciada do repositório, monitoramento de commits, varreduras agendadas e correções preparadas. Escolha a CLI quando o histórico de achados salvo, os artefatos de cobertura e a exportação de SARIF se encaixarem no seu processo local ou de CI. Essa comparação não estabelece um vencedor em precisão ou custo.

Confira a política de filtragem de ambas as opções. A Action de revisão de segurança da Anthropic documenta exclusões que incluem negação de serviço e esgotamento de recursos; portanto, um risco de esgotamento de disco como o caso de upload do Gogs exige uma revisão cuidadosa dessa política. A Action é uma oferta separada do produto hospedado Code Review do Claude. Repositório de revisão de segurança da Anthropic.

Na segunda-feira, coloque uma pessoa responsável por um repositório. Execute a varredura inicial, corrija o modelo de ameaças, faça a triagem dos primeiros achados e acrescente um CI que apenas informe os resultados antes de escolher um limite de severidade para bloqueio. Registre o custo de uso e a cobertura em aberto antes de expandir para outro repositório.

Se quiser integrar isso ao processo de desenvolvimento que sua equipe já usa, eu desenvolvo sistemas de IA para produção.