Proteja seu aplicativo com o CodeMender

1. Antes de começar

⏱️ Duração: 03:00

Observação: no momento, o CodeMender está disponível para um grupo limitado de clientes em pré-lançamento público. Entre em contato com sua equipe de vendas para ter acesso.

Aviso de pré-GA e pré-lançamento público: o CodeMender está disponível para um conjunto limitado de clientes em pré-lançamento público. Os produtos pré-GA estão em vários estágios de teste e análise internos. Por isso, os clientes precisam supervisionar de perto o uso do CodeMender e não usá-lo em situações em que erros graves não podem ser corrigidos. Este produto é disponibilizado aos Clientes apenas para testes e avaliações limitados e não pode ser usado para fins comerciais ou de produção.

Aviso sobre filtros de segurança e confirmação humana: ao desativar a confirmação humana de ações de gravação e execução de ferramentas (conforme configurado em ~/.codemender/config.yaml ou flags de CLI não interativas, como -y e --bypass-warning), o Cliente é responsável por essa modificação de acordo com a Seção 20(j) ("Modificação, Desconsideração ou Desativação de Filtros de Segurança") dos Termos Específicos de Serviço. Os Clientes concordam em não ignorar ou burlar automaticamente outras respostas que exijam confirmação humana.

Este é o codelab prático sobre como proteger seu aplicativo com o CodeMender na Gemini Enterprise Agent Platform do Google Cloud.

Neste workshop, você vai assumir o papel de um Cloud Security Engineer encarregado de auditar e proteger o OWASP Juice Shop, um aplicativo da Web intencionalmente vulnerável, padrão do setor, criado com Node.js, Express, TypeScript e Angular.

As ferramentas tradicionais de verificação de segurança (SAST/DAST) inundam as equipes de desenvolvimento com milhares de descobertas de segurança estáticas, altas taxas de falsos positivos e zero correções de código acionáveis. Os desenvolvedores passam horas fazendo a triagem de registros, rastreando fluxos de dados e escrevendo manualmente patches que frequentemente interrompem o comportamento do aplicativo.

O CodeMender revoluciona a segurança de código ao envolver os LLMs do Gemini do Google em uma estrutura de agentes ajustada. Usando comandos criados pelo Google DeepMind, habilidades de segurança especializadas e orquestração multiagente, o CodeMender atua como um co-desenvolvedor de segurança de IA autônomo que encontra, verifica e corrige vulnerabilidades de software diretamente nos repositórios de origem locais.

Pré-requisitos

• Noções básicas sobre vulnerabilidades de aplicativos da Web (as 10 principais do OWASP, como injeção de SQL e XSS)
• Noções básicas de aplicativos JavaScript/TypeScript e Node.js
• Familiaridade básica com ferramentas de interface de linha de comando (CLI)

O que você vai aprender

• Como configurar, autenticar e inicializar a CLI do CodeMender (cm) no Google Cloud Shell.
• Como verificar um repositório de forma autônoma para descobrir vulnerabilidades exploráveis (cm find).
• Como validar vulnerabilidades em sandboxes isolados e inspecionar artefatos de verificação (cm verify).
• Como sintetizar, testar e aplicar de forma autônoma patches de segurança que consideram o contexto (cm fix).
• Como auditar a telemetria de tokens e exportar relatórios de conformidade multiformato (cm stats, cm report).

O que você precisa

• Tenha um projeto do Google Cloud com o faturamento ativado.
• Google Cloud Shell com conexão de projeto ativa (inclui gcloud, git e Node.js 18+ pré-instalados)
• Repositório inicial: repositório do GitHub da OWASP Juice Shop

2. Introdução à arquitetura do CodeMender

⏱️ Duração: 04:00

Antes de começar a verificação e correção de código, vamos entender como o CodeMender funciona nos bastidores da Gemini Enterprise Agent Platform, de acordo com os padrões oficiais de arquitetura do Google Cloud.

Observação: o CodeMender consiste em uma plataforma de raciocínio multiagente hospedada e um binário de cliente local (cm) que opera em um sandbox de processo local isolado para criar código, executar scripts de reprodução e verificar correções de segurança.

A arquitetura do sistema: agente e daemon do cliente

Do ponto de vista do usuário, o CodeMender é composto por dois componentes arquitetônicos principais:

Plataforma multiagente hospedada: um sistema multiagente hospedado no Google Cloud que executa a lógica de negócios de segurança principal, a engenharia de comandos de LLM e o raciocínio de segurança.

CLI do cliente local e daemon de sandbox (cm): um cliente em execução no Google Cloud Shell que atua como uma CLI (para emitir comandos como cm find, cm verify, cm fix) e um daemon local (para executar comandos com segurança em nome do agente dentro de um sandbox isolado no nível do processo).

Os 3 principais recursos de correção

O CodeMender lida com a segurança do código em três etapas integradas:

Encontrar vulnerabilidades (cm find): verifica bases de código usando um LLM guiado pelo agente, aproveitando ferramentas de segurança especializadas e engenharia de comandos para focar o modelo em falhas de segurança. Como alternativa, as descobertas podem ser importadas de ferramentas externas de verificação de segurança.

Verificar vulnerabilidades (cm verify): cria o código localmente e tenta explorar as falhas descobertas para verificar se elas são exploráveis. Isso elimina falsos positivos e gera artefatos de verificação de espaço de trabalho persistentes em .exploit/ (info.yaml, PLAN.md, LOG.md, exploit.sh, REPORT.md).

Corrigir vulnerabilidades (cm fix): sintetiza patches de origem que reconhecem a linguagem e os verifica executando pacotes de testes de regressão e build do projeto (npm test) no sandbox local.

3. Configurar o ambiente do OWASP Juice Shop

⏱️ Duração: 05:00

Nesta etapa, você vai abrir o ambiente de terminal do Google Cloud e buscar o repositório do aplicativo de destino.

Etapa 1: abrir o Cloud Shell no console do Google Cloud

Acesse o Console do Google Cloud no navegador.

Na barra de navegação na parte de cima, clique no botão Ativar o Cloud Shell (ícone >_).

O Cloud Shell oferece um terminal Linux baseado em navegador com gcloud, git e Node.js pré-instalados e autenticados.

Etapa 2: clonar o repositório do OWASP Juice Shop

No Cloud Shell ou no terminal local, clone o repositório do OWASP Juice Shop:

git clone https://github.com/juice-shop/juice-shop.git --depth 1
cd juice-shop

Etapa 3: inspecionar os principais arquivos do aplicativo

O OWASP Juice Shop usa o Express.js no back-end com módulos TypeScript. Confira a estrutura do diretório:

ls -la routes/ lib/

Observe os principais arquivos de rota que lidam com autenticação, consultas de usuários e administração do carrinho:

routes/login.ts: processa a autenticação do usuário e a execução de consultas SQL brutas.

routes/search.ts: processa a pesquisa de produtos e a renderização de respostas.

routes/basket.ts: processa a recuperação do carrinho de compras do usuário.

routes/trackOrder.ts: lida com o rastreamento de pedidos usando consultas NoSQL.

lib/xml.ts: processa a análise de XML e os uploads de arquivos.

lib/insecurity.ts: utilitários auxiliares para tokens de sessão e criptografia.

4. Instalar a CLI do CodeMender (cm) e autenticar as credenciais do GCP

⏱️ Duração: 08:00

Nesta etapa, você vai ativar as APIs do Cloud necessárias do Google Cloud, conceder permissões do IAM usando gcloud, fazer o download e instalar o binário da CLI cm e configurar o Application Default Credentials (ADC).

Etapa 1: ativar as APIs do Google Cloud necessárias usando o gcloud

O CodeMender requer a API Agent Platform (aiplatform.googleapis.com) e a API Cloud Resource Manager (cloudresourcemanager.googleapis.com) na Gemini Enterprise Agent Platform.

No Cloud Shell ou no terminal, recupere o ID do projeto ativo (ou verifique o menu suspenso do projeto na parte de cima do console do Google Cloud) e ative as APIs de serviço necessárias:

# Automatically retrieve and set your active Google Cloud project ID
export PROJECT_ID=$(gcloud config get-value project)
gcloud config set project ${PROJECT_ID}

# Enable required Google Cloud APIs
gcloud services enable \
 aiplatform.googleapis.com \
 cloudresourcemanager.googleapis.com \
 serviceusage.googleapis.com \
 --project=${PROJECT_ID}

Verifique se as APIs estão ativadas:

gcloud services list --enabled --filter="name:(aiplatform.googleapis.com OR cloudresourcemanager.googleapis.com)"

Etapa 2: conceder permissões do IAM usando gcloud

Para interagir com o mecanismo de raciocínio em nuvem do CodeMender, os usuários e as contas de serviço precisam ter o papel do IAM roles/aiplatform.user (Usuário da Agent Platform) atribuído.

Navegação no console: também é possível verificar ou conceder esse papel no console do Google Cloud. Para isso, acesse Menu de navegação ☰ > IAM e administrador > IAM, localize sua conta e verifique os papéis atribuídos.

Conceder o papel do IAM à sua conta de usuário pela CLI

# Get your active authenticated gcloud account email
USER_EMAIL=$(gcloud config get-value account)

# Add IAM policy binding for user account
gcloud projects add-iam-policy-binding ${PROJECT_ID} \
 --member="user:${USER_EMAIL}" \
 --role="roles/aiplatform.user"

Etapa 3: fazer o download e instalar a CLI da cm no Cloud Shell

No Google Cloud Shell, os dados do usuário são armazenados de forma permanente no diretório $HOME. Execute os comandos a seguir para instalar o cm no ~/bin sem precisar do sudo. Você ainda está em ~/juice-shop da seção anterior. Portanto, os comandos são baixados em um diretório temporário e limpos depois. Dessa forma, nenhum arquivo do instalador vai parar no repositório da Juice Shop:

# Download into a temporary directory so nothing lands in the Juice Shop repository
CM_TMP=$(mktemp -d)
curl -L -o "${CM_TMP}/cm-linux-amd64.zip" "https://artifactregistry.googleapis.com/download/v1/projects/cmoc-prod/locations/us/repositories/codemender-cli-production/files/cm:stable:cm-linux-amd64.zip:download?alt=media"
unzip -o "${CM_TMP}/cm-linux-amd64.zip" -d "${CM_TMP}"

# Install into your persistent ~/bin directory and clean up
mkdir -p ~/bin
install -m 0755 "${CM_TMP}/cm" ~/bin/cm
rm -rf "${CM_TMP}"

# Add ~/bin to PATH for this session and future Cloud Shell sessions
export PATH="$HOME/bin:$PATH"
grep -qxF 'export PATH="$HOME/bin:$PATH"' ~/.bashrc || echo 'export PATH="$HOME/bin:$PATH"' >> ~/.bashrc

Prática recomendada do Cloud Shell: armazenamento permanente em $HOME

O Google Cloud Shell provisiona 5 GB de armazenamento em disco permanente ativado em $HOME. Tudo fora do diretório principal do usuário (como /usr/local/bin ou raiz do sistema) é temporário e redefinido quando a VM do Cloud Shell é reciclada. A instalação de binários em ~/bin garante que o cm persista em todas as sessões futuras do Cloud Shell, e a entrada ~/.bashrc mantém ~/bin no seu PATH para que o cm esteja pronto para uso sempre que você abrir um novo terminal.

Suporte multiplataforma (macOS, Linux ARM64, Windows):

Se estiver executando fora do Cloud Shell na estação de trabalho local, baixe os pacotes do repositório oficial cmoc-prod/codemender-cli-production usando gcloud artifacts generic download ou curl:

• macOS Apple Silicon: curl -L -o cm-darwin-arm64.zip "https://artifactregistry.googleapis.com/download/v1/projects/cmoc-prod/locations/us/repositories/codemender-cli-production/files/cm:stable:cm-darwin-arm64.zip:download?alt=media"

• macOS Intel: curl -L -o cm-darwin-amd64.zip "https://artifactregistry.googleapis.com/download/v1/projects/cmoc-prod/locations/us/repositories/codemender-cli-production/files/cm:stable:cm-darwin-amd64.zip:download?alt=media"

• Linux ARM64: curl -L -o cm-linux-arm64.zip "https://artifactregistry.googleapis.com/download/v1/projects/cmoc-prod/locations/us/repositories/codemender-cli-production/files/cm:stable:cm-linux-arm64.zip:download?alt=media"

• Windows: cm-windows-amd64.zip / cm-windows-arm64.zip (pelo PowerShell Invoke-WebRequest).

Etapa 4: verificar a instalação da CLI da cm

Execute cm --version para verificar se o binário da CLI está instalado corretamente:

cm --version

Saída esperada:

cm version 0.17.0

Etapa 5: configurar o Application Default Credentials (ADC) do Google Cloud

Configure o Application Default Credentials (ADC) do Google Cloud para que o cm possa autenticar solicitações para o mecanismo de raciocínio em nuvem:

gcloud auth application-default login

Uma caixa de diálogo modal de autorização chamada Autorizar o Cloud Shell vai aparecer. Clique em Autorizar para conceder acesso.

Ativação guiada da plataforma:

Se o projeto na nuvem do Google Cloud ou a identidade do usuário exigir ativação inicial da plataforma ou integração de políticas, o CodeMender vai abrir automaticamente o navegador padrão na página de destino de ativação e aguardar a confirmação diretamente no terminal, eliminando erros de saída abrupta.

5. Inicializar e verificar o espaço de trabalho do CodeMender

⏱️ Duração: 03:00

Agora que o cm está instalado e autenticado, você vai inicializar o espaço de trabalho do CodeMender no diretório do projeto de destino e verificar a configuração do ambiente.

Etapa 1: inicializar o espaço de trabalho do CodeMender (cm init)

Execute cm init na raiz do diretório do projeto para inicializar os arquivos de rastreamento de estado local e estabelecer as configurações de referência:

cm init

Saída:

✅ Initialized CodeMender workspace at /home/user/.codemender

Etapa 2: executar diagnósticos de integridade completos (cm health)

Antes de iniciar uma sessão de agente, execute cm health para verificar suas credenciais, configuração, acessibilidade e autorização:

cm health

Saída:

CodeMender Health Check
───────────────────────
 Backend:   iapi
 Endpoint:  https://aiplatform.googleapis.com
 Location:  global
 Project:   my-gcp-project

 ✓ credentials     passed   (0ms)  Token acquired for project "my-gcp-project"
 ✓ config          passed   (0ms)  Configuration valid (backend "iapi")
 ✓ reachability    passed   (250ms)  Endpoint https://aiplatform.googleapis.com responded
 ✓ authorization   passed   (68ms)  Caller authorized for project "my-gcp-project"

Status: HEALTHY (exit code 0, 319ms)

Etapa 3: entender os parâmetros de configuração (config.yaml)

O CodeMender cria um arquivo de configuração do espaço de trabalho em .codemender/config.yaml (ou ~/.codemender/config.yaml). Esse arquivo define limites de política, regras de inclusão de arquivos e hooks de verificação de teste:

# CodeMender CLI configuration.
# The server endpoint is baked in at build time (see build profiles).
# Override it here only if you need a different endpoint.

server: {}
location: "global"         # Service location: "global" (default), "us", "eu", or "us-central1" (overridden by $CM_LOCATION)

# Customer-supplied team identifier sent as the X-CodeMender-Team-Id
# telemetry header. Overridden by --team-id flag or $CM_TEAM_ID env var.
# Max 63 chars, must match [A-Za-z0-9._-]. Omit to skip the header.
# team_id: "acme-security"

scan:
 extensions:
   include: [".py", ".java", ".go", ".js", ".jsx", ".mjs", ".cjs", ".ts", ".tsx", ".c", ".cc", ".cpp", ".cxx", ".h", ".hh", ".hpp", ".hxx", ".inl", ".ipp", ".cs", ".rs", ".kt", ".kts", ".rb", ".php", ".sol", ".tf", ".hcl"]
   exclude: [".min.js", ".generated.go", ".pb.go"]
 # A leading "/" matches only that directory at the scan root.
 exclude_dirs: ["node_modules", "vendor", "dist", "/target", "/obj", "/build", ".gradle"]
 max_file_size_kb: 2048   # Maximum file size for discovery (2048 KB / 2 MiB)
 incremental: true

# Restrict agent file access to these directories (all commands).
# When empty, the scan target directory is used as the boundary.
# project_paths: []

output:
 format: table   # "table", "json", "sarif"

tools:
 confirm_commands: true   # Prompt Y/N before running shell commands (default: true)
 confirm_writes: true     # Prompt Y/N before writing/modifying files (default: true)
 # cleanup_candidate_branches: true # Auto-delete temporary candidate branches on completion (default: true)
 # Use --yes flag on find/fix/session resume to skip all confirmations

# Version Control and Automated Testing Guardrails
vcs:
 type: ""               # VCS type: "git", "mercurial", "custom", or "" (auto-detect)
 commands:
   reset: ""            # Shell command to reset codebase (auto-populated for known VCS)
   diff: ""             # Shell command to show changes (auto-populated for known VCS)
   status: ""           # Shell command to list modified files (auto-populated for known VCS)
   stage: ""            # Shell command to stage changes (auto-populated for known VCS)

build:
 command: "npm test"    # Shell command to build/verify changes from the agent

sandbox:
 enabled: true          # Process-level OS sandbox (default: true)
 mounts:
   target_dir: "."
 network:
   profile: "permissive-closed" # Complete network isolation; set to "permissive-open" if build requires internet
security:
 protected_files: []    # Files mounted read-only inside sandbox (e.g. ["~/.ssh/*"])

Configurações principais para este codelab:

• Modo Workshop (--sandbox=false, **--bypass-warning e** **-y)**: o CodeMender aplica três limites de segurança independentes: o sandbox no nível do SO (sandbox.enabled / --sandbox), o limite do caminho do espaço de trabalho (project_paths / --allow-all-paths) e a lista de bloqueio de comandos (command_policy.yaml / --allow-all-commands). Como este laboratório é executado em uma VM isolada do Google Cloud Shell em um projeto de exemplo, as próximas etapas transmitem --sandbox=false para desativar apenas o sandbox no nível do SO para uma execução previsível da ferramenta, além de --bypass-warning e -y para pular o aviso de execução do host e as solicitações de confirmação. O limite do caminho e a lista de bloqueio de comandos permanecem aplicados, e este codelab nunca precisa de --allow-all-paths ou --allow-all-commands. Na sua estação de trabalho ou ao verificar repositórios não confiáveis, mantenha o sandbox ativado: ele oculta diretórios de credenciais, como ~/.ssh e ~/.config/gcloud, de comandos executados pelo agente, remove variáveis de ambiente semelhantes a secrets (como *_TOKEN* e _KEY) e mantém .git/hooks e .codemender como somente leitura.

• Verificação de teste automatizada (build.command): quando configurado (por exemplo, npm test), o cm fix executa automaticamente seu pacote de testes para garantir que os patches de segurança gerados não introduzam regressões. Para ver a referência de configuração completa, consulte a documentação oficial do CodeMender.

6. Descobrir vulnerabilidades com cm find .

⏱️ Duração: 07:00

Nesta etapa, você vai executar cm find . --quick para fazer uma verificação de segurança agêntica na base de código da Juice Shop.

Etapa 1: execute cm find . --quick.

A partir do CodeMender v0.16.0, cm find <path> usa como padrão a Análise detalhada (

--deep

) para uma análise completa de cada arquivo, enquanto a Verificação rápida (

--quick

) faz uma triagem rápida do repositório. Execute cm find . --quick para realizar uma verificação rápida no repositório do OWASP Juice Shop (tempo de execução estimado: cerca de 8 minutos para a triagem completa da base de código de 684 arquivos):

cm find . --quick -y --sandbox=false --bypass-warning --model gemini-3.8-flash

cm inicia uma sessão de verificação na Gemini Enterprise Agent Platform, analisando arquivos de código-fonte em todos os módulos do repositório:

⚠️ Sandbox DISABLED and command approval OFF: the agent can run commands on this machine without asking. Code in the scanned repository could steer it. Re-enable the sandbox or command approval (drop --yes, or set tools.confirm_commands: true) unless you trust the repository.
🔍 Discovering files in /home/user/juice-shop...
  Found 684 source files
🚀 Starting FIND session (mode: QUICK)...
  Server: https://aiplatform.googleapis.com
  Session: ChBjMjI4YWY5MzljZjUzNTQ4EAgaAjg1KgRtYWlu
  Operation: ChBjMjI4YWY5MzljZjUzNTQ4EAgaAjg1KgRtYWlu
📂 Scan target: /home/user/juice-shop
🔒 Sandbox roots (agent can only access these directories):
  • /home/user/juice-shop

📡 Waiting for server (https://aiplatform.googleapis.com)...
────────────────────────────────────────────────────────────
2026-10-29T03:01:47Z [INFO]  🔧 [Step 1] list_dir → /home/user/juice-shop
2026-10-29T03:01:56Z [INFO]  🔧 [Step 2] list_dir → .../juice-shop/routes
2026-10-29T03:02:08Z [INFO]  🔧 [Step 3] read_file → .../juice-shop/server.ts
2026-10-29T03:02:47Z [INFO]  🔧 [Step 7] read_file → .../juice-shop/routes/login.ts
2026-10-29T03:02:56Z [INFO]  🔧 [Step 8] read_file → .../juice-shop/routes/search.ts
2026-10-29T03:03:48Z [INFO]  🔧 [Step 13] read_file → .../juice-shop/routes/fileUpload.ts
2026-10-29T03:04:30Z [INFO]  🔧 [Step 16] read_file → .../juice-shop/routes/userProfile.ts
2026-10-29T03:06:11Z [INFO]  🔧 [Step 25] read_file → .../juice-shop/routes/trackOrder.ts
2026-10-29T03:07:57Z [INFO]  🔧 [Step 33] read_file → .../juice-shop/routes/order.ts
2026-10-29T03:09:30Z [INFO]  ✅ Completed 33 tool steps in 7m48s | Tokens: 2.6M in / 8k out / 2.7M total
────────────────────────────────────────────────────────────

🔒 Found 12 vulnerabilities:

ID        SEVERITY    TYPE                                     FILE                             TITLE                                                                                   CONFIDENCE
────────  ────────    ────                                     ────                             ─────                                                                                   ──────────
43aa7446  🔴 CRITICAL  SQL INJECTION                            routes/login.ts                  SQL Injection in User Login Handler Allows Authentication Bypass                        100%
dd83d0a4  🟠 HIGH      SQL INJECTION                            routes/search.ts                 UNION-Based SQL Injection in Product Search Allows Database Exfiltration                100%
4dfe2409  🟠 HIGH      CODE INJECTION                           routes/userProfile.ts            Remote Code Execution via Eval in User Profile Template Handler                         100%
79d490b0  🟠 HIGH      PATH TRAVERSAL                           routes/fileUpload.ts             Path Traversal (Zip Slip) in Zip File Upload Allows Arbitrary File Overwrite            100%
4f2b050c  🟠 HIGH      XML EXTERNAL ENTITY (XXE)                routes/fileUpload.ts             XML External Entity (XXE) Injection in File Upload Route Leaks System Files             100%
1ece0e25  🟠 HIGH      IMPROPER ACCESS CONTROL                  server.ts                        Missing Authorization on Product Update Endpoint Allows Unauthorized Product Tampering  100%
757fd438  🟠 HIGH      CWE-943                                  routes/trackOrder.ts             NoSQL / JavaScript Injection in Order Tracking Allows Database Record Exfiltration      100%
349bac9f  🟡 MEDIUM    SERVER-SIDE REQUEST FORGERY (SSRF)       routes/profileImageUrlUpload.ts  Server-Side Request Forgery (SSRF) in Profile Image URL Upload Route                    100%
be5e1459  🟡 MEDIUM    OPEN REDIRECT                            routes/redirect.ts               Open Redirect via Inadequate Allowlist Substring Match                                  100%
06ecf8a5  🟡 MEDIUM    INSECURE DIRECT OBJECT REFERENCE (IDOR)  routes/basket.ts                 Insecure Direct Object Reference (IDOR) Allows Access to Arbitrary User Baskets         100%
02f6a293  🟡 MEDIUM    PATH TRAVERSAL                           routes/dataErasure.ts            Local File Read via Insecure Template Layout Parameter in Data Erasure Route            100%
95ee59a3  🟡 MEDIUM    CWE-943                                  routes/updateProductReviews.ts   NoSQL Injection in Product Review Update Endpoint Allows Mass Modification              100%

Summary: 1 CRITICAL, 6 HIGH, 5 MEDIUM

Run 'cm report' for detailed analysis, 'cm verify <finding-id>' to validate, or 'cm fix <finding-id>' to generate a patch.
2026-10-29T03:09:30Z [INFO]  📄 Session log: /home/user/.codemender/logs/20261029T030140Z_ChBjMjI4YWY5MzljZjUzNTQ4EAgaAjg1KgRtYWlu.log

Dica: como escolher modos e modelos de leitura:

• Modos de verificação: use --quick para uma triagem rápida e interativa do repositório (~8 minutos), o padrão --deep (cm find .) para auditorias exaustivas arquivo por arquivo ou --diff para verificações de solicitação de pull de CI/CD (abordadas na Parte 2 desta série de codelabs).

• Modelos de raciocínio: o gemini-3.8-flash (padrão) é otimizado para triagem rápida e correções focadas, enquanto o --model gemini-4-argon oferece uma janela de contexto de 1 milhão de tokens para análise profunda de fluxo de dados em vários módulos.

Etapa 2: analisar as descobertas da verificação em cm report

Execute cm report -f table para mostrar todas as descobertas de segurança descobertas no banco de dados de estado SQLite local:

cm report -f table

Saída:

┌──────────┬───────────┬──────┬───┬──────────────────────────────┬────────────────────────────────────────┐
│ID        │Severity   │Status│Fix│File                          │Title                                   │
├──────────┼───────────┼──────┼───┼──────────────────────────────┼────────────────────────────────────────┤
│ 43aa7446 │🔴 CRITICAL│OPEN  │—  │routes/login.ts               │SQL Injection in User Login Handler A...│
│ dd83d0a4 │🟠 HIGH    │OPEN  │—  │routes/search.ts              │UNION-Based SQL Injection in Product ...│
│ 4dfe2409 │🟠 HIGH    │OPEN  │—  │routes/userProfile.ts         │Remote Code Execution via Eval in Use...│
│ 79d490b0 │🟠 HIGH    │OPEN  │—  │routes/fileUpload.ts          │Path Traversal (Zip Slip) in Zip File...│
│ 4f2b050c │🟠 HIGH    │OPEN  │—  │routes/fileUpload.ts          │XML External Entity (XXE) Injection i...│
│ 1ece0e25 │🟠 HIGH    │OPEN  │—  │server.ts                     │Missing Authorization on Product Upda...│
│ 757fd438 │🟠 HIGH    │OPEN  │—  │routes/trackOrder.ts          │NoSQL / JavaScript Injection in Order...│
│ 349bac9f │🟡 MEDIUM  │OPEN  │—  │routes/profileImageUrlUploa...│Server-Side Request Forgery (SSRF) in...│
│ be5e1459 │🟡 MEDIUM  │OPEN  │—  │routes/redirect.ts            │Open Redirect via Inadequate Allowlis...│
│ 06ecf8a5 │🟡 MEDIUM  │OPEN  │—  │routes/basket.ts              │Insecure Direct Object Reference (IDO...│
│ 02f6a293 │🟡 MEDIUM  │OPEN  │—  │routes/dataErasure.ts         │Local File Read via Insecure Template...│
│ 95ee59a3 │🟡 MEDIUM  │OPEN  │—  │routes/updateProductReviews.ts│NoSQL Injection in Product Review Upd...│
└──────────┴───────────┴──────┴───┴──────────────────────────────┴────────────────────────────────────────┘

12 finding(s): 1 CRITICAL, 6 HIGH, 5 MEDIUM · ✅ 0 fixed, 🔴 12 open
📋 Report generated at 2026-10-29 03:10:05 UTC
2026-10-29T03:10:05Z [INFO]  📄 Session log: /home/user/.codemender/logs/20261029T031005Z_pending.log

Observação importante sobre IDs de descoberta dinâmicos:

Cada verificação do CodeMender gera dinamicamente IDs de descoberta hexadecimais exclusivos de 8 caracteres (como 43aa7446, dd83d0a4, 79d490b0). Os IDs mostrados neste tutorial são capturados da nossa execução de referência. Nas etapas de correção a seguir, copie e use o ID de descoberta exato correspondente a routes/login.ts, conforme exibido na tabela de saída cm report do seu terminal.

Etapa 3: entender os estados do ciclo de vida e os níveis de gravidade das descobertas

O CodeMender rastreia vulnerabilidades por um ciclo de vida formal de quatro estados:

Estado da descoberta	Significado e processamento de transição
OPEN	A vulnerabilidade foi descoberta (ou importada), mas ainda não foi verificada, corrigida ou descartada.
FIXED	O CodeMender gerou um patch, aplicou o diff e verificou se os pacotes de build/teste foram aprovados e se as tentativas de exploração falharam.
DISMISSED	Marcado como inativo devido à baixa confiança, fora do modelo de ameaças ou verificado como um falso positivo. Silencia alertas futuros.
REOPENED	Uma falha FIXED ou DISMISSED detectada novamente em uma verificação posterior (indicando uma regressão de código).

Classificações de gravidade

🔴 CRITICAL: risco imediato e grave (por exemplo, execução remota de código, injeção de SQL não autenticada) diretamente acessível de limites não confiáveis.

🟠 HIGH: falha grave (por exemplo, leitura arbitrária de banco de dados, escalonamento de privilégios) que exige um contexto de usuário específico ou condições encadeadas.

🟡 MEDIUM: risco moderado com escopo restrito ou que exige interação do usuário (por exemplo, redirecionamento aberto, CSRF).

🔵 LOW: falhas de higiene de defesa em profundidade ou vetores de reconhecimento com impacto direto mínimo.

7. Verificar vulnerabilidades e analisar artefatos de verificação capturados

⏱️ Duração: 10:00

Um dos principais recursos do CodeMender é a geração automática de artefatos de verificação persistentes sempre que você executa cm verify. Vamos verificar a descoberta de injeção de SQL crítica em routes/login.ts (ilustrada como 43aa7446 neste tutorial) e analisar os artefatos criados pelo agente.

Etapa 1: execute cm verify <login-finding-id>.

Localize o ID da descoberta de routes/login.ts na tabela cm report (por exemplo, 43aa7446) e execute cm verify <finding-id> --sandbox=false --bypass-warning -y (tempo estimado de execução: cerca de 20 minutos para executar as etapas da ferramenta autônoma, iniciar os serviços em segundo plano e executar scripts de exploração de PoC em tempo real):

# Replace 43aa7446 with your actual login.ts finding ID
# --sandbox=false turns off only the OS-level sandbox; the path boundary and command policy stay enforced
cm verify 43aa7446 --sandbox=false --bypass-warning -y --model gemini-3.8-flash

Saída:

⚠️ Sandbox DISABLED and command approval OFF: the agent can run commands on this machine without asking. Code in the scanned repository could steer it. Re-enable the sandbox or command approval (drop --yes, or set tools.confirm_commands: true) unless you trust the repository.
🔬 Verifying finding: SQL Injection in User Login Handler Allows Authentication Bypass
  ID: 43aa7446-40de-467d-8ca4-8571dca16036
  File: /home/user/juice-shop/routes/login.ts
  Severity: 🔴 CRITICAL
  Type: SQL INJECTION
Resetting workspace at /home/user/juice-shop

🔧 Running: git checkout HEAD -- . && git clean -fd
Removing .cm_project

✅ Reset complete. Ready for vulnerability research.
🚀 Starting VERIFY session...
  Server: https://aiplatform.googleapis.com
  Session: ChBkZTRhMWU3YTI4MjU5ZDY0EAgaAmU4KgRtYWlu
  Operation: ChBkZTRhMWU3YTI4MjU5ZDY0EAgaAmU4KgRtYWlu
📂 Scan target: /home/user/juice-shop/routes
🔒 Sandbox boundary (agent can explore within):
  • /home/user/juice-shop

📡 Waiting for verification agent (https://aiplatform.googleapis.com)...
────────────────────────────────────────────────────────────
2026-10-29T03:11:31Z [INFO]  🔧 [Step 1] run_command → mkdir -p /home/user/juice-shop/.exploit
2026-10-29T03:11:42Z [INFO]  🔧 [Step 2] read_file → .../juice-shop/routes/login.ts
2026-10-29T03:12:03Z [INFO]  🔧 [Step 4] read_file → .../juice-shop/package.json
2026-10-29T03:12:14Z [INFO]  🔧 [Step 5] write_to_file → .../juice-shop/.exploit/PLAN.md
2026-10-29T03:19:00Z [INFO]  🔧 [Step 25] run_command → npm run build:server
2026-10-29T03:29:20Z [INFO]  🔧 [Step 61] write_to_file → .../juice-shop/.exploit/info.yaml
2026-10-29T03:29:53Z [INFO]  🔧 [Step 63] write_to_file → .../juice-shop/.exploit/LOG.md
2026-10-29T03:30:17Z [INFO]  🔧 [Step 64] write_to_file → .../juice-shop/.exploit/REPORT.md
2026-10-29T03:30:55Z [INFO]  🔧 [Step 66] run_command → git status --short
2026-10-29T03:31:46Z [INFO]  ✅ Completed 66 tool steps in 20m23s | Tokens: 2.8M in / 7k out / 2.8M total
────────────────────────────────────────────────────────────
2026-10-29T03:31:46Z [INFO]  Artifacts manifest written: /home/user/.codemender/artifacts/ChBkZTRhMWU3YTI4MjU5ZDY0EAgaAmU4KgRtYWlu/manifest.json (7 artifacts)
📦 Captured 7 agent artifacts in /home/user/.codemender/artifacts/ChBkZTRhMWU3YTI4MjU5ZDY0EAgaAmU4KgRtYWlu
Pulling artifacts for session ChBkZTRhMWU3YTI4MjU5ZDY0EAgaAmU4KgRtYWlu
Resetting workspace at /home/user/juice-shop

🔧 Running: git checkout HEAD -- . && git clean -fd
Removing .cm_project
Removing .exploit/LOG.md
Removing .exploit/PLAN.md
Removing .exploit/REPORT.md
Removing .exploit/exploit.sh
Removing .exploit/info.yaml
Removing .exploit/server_runner.js

✅ Reset complete. Ready for vulnerability research.
📥 Copying 7 finding artifact(s) to workspace...
  • /home/user/juice-shop/.exploit/LOG.md
  • /home/user/juice-shop/.exploit/PLAN.md
  • /home/user/juice-shop/.exploit/REPORT.md
  • /home/user/juice-shop/.exploit/exploit.sh
  • /home/user/juice-shop/.exploit/info.yaml
  • /home/user/juice-shop/.exploit/server.log
  • /home/user/juice-shop/.exploit/server_runner.js

🚀 Programmatically running exploit script to confirm: /home/user/juice-shop/.exploit/exploit.sh
EXPLOIT SUCCESSFUL

✅ Exploit execution succeeded. Finding VERIFIED (confidence: 100%)

Run 'cm report' to see updated findings.
2026-10-29T03:31:52Z [INFO]  📄 Session log: /home/user/.codemender/logs/20261029T031121Z_ChBkZTRhMWU3YTI4MjU5ZDY0EAgaAmU4KgRtYWlu.log

Opções de verificação e resumo de saída:

• Somente verificação estática (--skip-exploit-verification): em ambientes sensíveis ou clusters de preparo em que a execução de payloads de exploit ativos é proibida, transmita --skip-exploit-verification para realizar apenas a análise semântica estática sem iniciar exploits de PoC ativos.

• Resumo de saída do comando: quando a verificação é concluída, o CodeMender gera um resumo de conclusão:

✅ Completed 66 tool steps in 20m23s | Tokens: 2.8M in / 7k out / 2.8M total

A contagem de tokens total inclui tokens de raciocínio interno, que podem exceder in + out.

Etapa 2: visão geral dos artefatos de verificação capturados

A partir do CodeMender v0.16.0, os artefatos de verificação são padronizados na raiz do repositório em .exploit/, mantendo uma cópia persistente em ~/.codemender/artifacts/<session-id>/. Eles são arquivos de trabalho locais, não parte da correção. Por isso, você vai excluí-los do Git antes de preparar o patch na próxima seção. Execute ls -la .exploit/ para listá-los:

ls -la .exploit/

Saída:

total 40
drwxrwxr-x  2 user user 4096 Oct 29 03:31 .
drwxrwxr-x 35 user user 4096 Oct 29 03:31 ..
-rwxr-xr-x  1 user user 3272 Oct 29 03:31 exploit.sh
-rw-r--r--  1 user user  313 Oct 29 03:31 info.yaml
-rw-r--r--  1 user user 2196 Oct 29 03:31 LOG.md
-rw-r--r--  1 user user  771 Oct 29 03:31 PLAN.md
-rw-r--r--  1 user user 6387 Oct 29 03:31 REPORT.md
-rw-rw-r--  1 user user 2438 Oct 29 03:31 server.log
-rw-rw-r--  1 user user  462 Oct 29 03:31 server_runner.js

Arquivo de artefato	Categoria	Purpose
info.yaml	Manifesto de metadados	YAML estruturado que define o UUID, o título, a gravidade (CRITICAL), a confiança (certain) e as tags CWE (cwe-89) da descoberta.
PLAN.md	Estratégia do agente	Plano de verificação detalhado e lista de verificação executados de forma autônoma pelo mecanismo de raciocínio do CodeMender.
LOG.md	Registro de rastreamento de execução	Trilha de auditoria com carimbo de data/hora que registra cada chamada de ferramenta, endpoint de solicitação HTTP e resultado de teste.
server_runner.js / server.log	Registro do servidor / executor auxiliar	Script auxiliar que o agente criou para iniciar o Juice Shop para testes e a saída do servidor capturada.
exploit.sh	Wrapper de execução / PoC independente	Wrapper de script de shell que inicia o serviço de destino e chama o cliente de PoC, validando as respostas HTTP 200.
REPORT.md	Análise da causa raiz	Resumo executivo, análise de vulnerabilidade linha por linha, detalhamento de SQL bruto e recomendações de parametrização do Sequelize.

Os arquivos auxiliares variam de acordo com a execução:

Dependendo da vulnerabilidade e da estratégia selecionada pelo agente, ele pode criar arquivos auxiliares que o exploit.sh usa (nesta execução, server_runner.js e server.log) ou colocar toda a lógica diretamente no exploit.sh. Ambos são artefatos de reprodução válidos e totalmente automatizados capturados em .exploit/.

Etapa 3: análise detalhada dos destaques do artefato de verificação

O agente grava esses artefatos do zero em cada execução, então o conteúdo exato deles é diferente a cada vez. Abra-os no editor do Cloud Shell (ou com cat) e procure o seguinte:

Artefato	O que procurar
info.yaml	O ID completo, o título, a gravidade, a confiança e as tags da descoberta, como cwe-89.
PLAN.md	A lista de verificação que o agente seguiu, desde a leitura do arquivo informado até a criação do script de reprodução.
LOG.md	Ações e resultados com carimbo de data/hora, incluindo o resultado de cada execução do script de reprodução.
exploit.sh	O script de reprodução independente: como ele inicia o app, qual endpoint ele segmenta e como ele decide o sucesso (ele imprime EXPLOIT SUCCESSFUL).
server_runner.js / server.log	Arquivos auxiliares que o agente criou para iniciar o Juice Shop para testes e a saída desse servidor.
REPORT.md	A análise de causa raiz: a linha vulnerável em routes/login.ts, por que ela é explorável e a correção recomendada (consultas parametrizadas).

Rastreamento de refatoração automatizada e artefatos de PoC executáveis na prática:

• Rastreamento de código movido em refatorações: em equipes de desenvolvimento que se movem rapidamente, os desenvolvedores costumam reorganizar diretórios (como mover routes/login.ts para um caminho modular como src/auth/login.ts). Os verificadores de vulnerabilidades tradicionais perdem o rastreamento quando os arquivos são movidos, o que resulta em relatórios órfãos ou erros de "arquivo não encontrado". O rastreamento semântico do CodeMender detecta código deslocado em renomeações e movimentações de diretório, atualizando automaticamente os registros de descobertas e os números de linha em ~/.codemender/state.db.

• Do script de PoC ao teste de regressão: o artefato de verificação .exploit/exploit.sh é gerado com permissões executáveis POSIX (chmod +x). Como .exploit/ fica fora do Git, as equipes que querem uma verificação de regressão permanente podem revisar o script, adaptá-lo ao pacote de testes (por exemplo, em test/security/) e confirmá-lo deliberadamente, para que uma mudança futura não possa reintroduzir a vulnerabilidade de forma silenciosa.

8. Corrigir a injeção de SQL com o comando cm fix

⏱️ Duração: 10:00

Agora que verificamos a descoberta de injeção de SQL em routes/login.ts (ID de exemplo 43aa7446) e analisamos os artefatos, vamos executar cm fix para aplicar um patch de consulta parametrizada automatizado.

Etapa 1: execute cm fix <login-finding-id> -y.

Execute cm fix <finding-id> --sandbox=false --bypass-warning -y (substitua 43aa7446 pelo ID real da descoberta de login de cm report) para sintetizar e aplicar uma correção:

# Replace 43aa7446 with your actual login.ts finding ID
cm fix 43aa7446 --sandbox=false --bypass-warning -y --model gemini-3.8-flash

Dica: como direcionar o agente de correção com **--context e --no-cache**:

É possível transmitir -c, --context <text> para orientar o agente de correção com requisitos específicos do domínio (por exemplo, cm fix 43aa7446 -c "Use Sequelize named replacements" -y). Para ignorar patches em cache e forçar uma nova sessão de raciocínio de IA, transmita --no-cache.

Saída:

⚠️ Sandbox DISABLED and command approval OFF: the agent can run commands on this machine without asking. Code in the scanned repository could steer it. Re-enable the sandbox or command approval (drop --yes, or set tools.confirm_commands: true) unless you trust the repository.
🩹 Fixing finding: SQL Injection in User Login Handler Allows Authentication Bypass
  File: /home/user/juice-shop/routes/login.ts
  Severity: CRITICAL
🔒 Sandbox roots (agent can only access these directories):
  • /home/user/juice-shop
Found latest VERIFY session ChBkZTRhMWU3YTI4MjU5ZDY0EAgaAmU4KgRtYWlu for finding 43aa7446-40de-467d-8ca4-8571dca16036
Pulling artifacts for session ChBkZTRhMWU3YTI4MjU5ZDY0EAgaAmU4KgRtYWlu
Resetting workspace at /home/user/juice-shop

🔧 Running: git checkout HEAD -- . && git clean -fd
Removing .cm_project
Removing .exploit/LOG.md
Removing .exploit/PLAN.md
Removing .exploit/REPORT.md
Removing .exploit/exploit.sh
Removing .exploit/info.yaml
Removing .exploit/server_runner.js

✅ Reset complete. Ready for vulnerability research.
📥 Copying 7 finding artifact(s) to workspace...
  • /home/user/juice-shop/.exploit/LOG.md
  • /home/user/juice-shop/.exploit/PLAN.md
  • /home/user/juice-shop/.exploit/REPORT.md
  • /home/user/juice-shop/.exploit/exploit.sh
  • /home/user/juice-shop/.exploit/info.yaml
  • /home/user/juice-shop/.exploit/server.log
  • /home/user/juice-shop/.exploit/server_runner.js
  Session: ChA0YjllNzFkMTgyM2JmZDQ0EAgaAjdiKgRtYWlu
  Operation: ChA0YjllNzFkMTgyM2JmZDQ0EAgaAjdiKgRtYWlu

📡 Waiting for fix agent (https://aiplatform.googleapis.com)...
────────────────────────────────────────────────────────────
2026-10-29T03:41:30Z [INFO]  🔧 [Step 4] read_file → .../juice-shop/routes/login.ts
2026-10-29T03:41:58Z [INFO]  🔧 [Step 6] run_command → npm run test:server
2026-10-29T03:43:11Z [INFO]  🔧 [Step 9] grep_search → pattern="sequelize\\.query" path=.../juice-shop/routes
2026-10-29T03:43:54Z [INFO]  🔧 [Step 12] read_file → .../juice-shop/routes/vulnCodeSnippet.ts
2026-10-29T03:44:41Z [INFO]  🔧 [Step 13] read_file → .../juice-shop/routes/vulnCodeFixes.ts
2026-10-29T03:53:14Z [INFO]  🔧 [Step 31] search_and_replace → .../juice-shop/routes/login.ts
2026-10-29T03:53:52Z [INFO]  🔧 [Step 33] run_command → npm run build:server
2026-10-29T03:55:23Z [INFO]  🔧 [Step 37] run_command → npm run test:server
2026-10-29T03:55:49Z [INFO]  🔧 [Step 38] run_command → git diff
2026-10-29T03:57:18Z [INFO]  ✅ Completed 43 tool steps in 16m54s | Tokens: 1.6M in / 4k out / 1.6M total
────────────────────────────────────────────────────────────

✨ Patch generated successfully!

diff --git a/routes/login.ts b/routes/login.ts
index fb9fce3..57f3afe 100644
--- a/routes/login.ts
+++ b/routes/login.ts
@@ -31,7 +31,14 @@ export function login () {

  return (req: Request, res: Response, next: NextFunction) => {
    verifyPreLoginChallenges(req) // vuln-code-snippet hide-line
-    models.sequelize.query(`SELECT * FROM Users WHERE email = '${req.body.email || ''}' AND password = '${security.hash(req.body.password || '')}' AND deletedAt IS NULL`, { model: UserModel, plain: true }) // vuln-code-snippet vuln-line loginAdminChallenge loginBenderChallenge loginJimChallenge
+    models.sequelize.query('SELECT * FROM Users WHERE email = :email AND password = :password AND deletedAt IS NULL', {
+      replacements: {
+        email: typeof req.body?.email === 'string' ? req.body.email : '',
+        password: security.hash(typeof req.body?.password === 'string' ? req.body.password : '')
+      },
+      model: UserModel,
+      plain: true
+    }) // vuln-code-snippet vuln-line loginAdminChallenge loginBenderChallenge loginJimChallenge
      .then((authenticatedUser) => { // vuln-code-snippet neutral-line loginAdminChallenge loginBenderChallenge loginJimChallenge
        const user = utils.queryResultToJson(authenticatedUser)
        if (user.data?.id && user.data.totpSecret !== '') {

────────────────────────────────────────────────────────────
2026-10-29T03:57:18Z [INFO]  📄 Session log: /home/user/.codemender/logs/20261029T034021Z_ChA0YjllNzFkMTgyM2JmZDQ0EAgaAjdiKgRtYWlu.log

Investigação: como o agente de correção descobriu a correção parametrizada ideal:

Observe que o agente não se limitou a injetar uma lógica de substituição de string. Ao analisar a estrutura do projeto:

1. Descoberta de contexto: ele inspecionou routes/login.ts e procurou usos de sequelize.query e UserModel em routes/ para entender como os manipuladores downstream esperam que a instância UserModel seja retornada.
2. Análise de referência: inspecionou routes/vulnCodeFixes.ts e routes/vulnCodeSnippet.ts para preservar as anotações de desafio necessárias (// vuln-code-snippet vuln-line ...).
3. Parametrização idiomática: substituiu a interpolação de strings de modelo literal bruta ('${req.body.email || ''}') por substituições de vinculação nomeadas do Sequelize (WHERE email = :email AND password = :password, replacements: { email: ..., password: ... }), imunizando completamente o endpoint contra injeção de SQL e preservando os tipos de retorno exatos ({ model: UserModel, plain: true }). Ele também adicionou verificações de tipo para que as entradas que não são strings sejam substituídas por uma string vazia.
4. Certificado YouTube ao vivo: ele inspecionou o arquivo (npx eslint), recriou o servidor (npm run build:server), executou novamente os testes do servidor (npm run test:server) e confirmou que o script de replicação de erro não funciona mais.

Proteções de segurança corporativa: por que o agente de correção não pode "trapacear":

Uma preocupação comum ao adotar agentes de programação de IA autônomos é: o agente vai desativar testes com falha ou enfraquecer os portões de CI/CD só para forçar uma pontuação de aprovação?

O CodeMender resolve isso com proteções de correções com escopo arquitetônicas rigorosas:

• Pipelines imutáveis: os fluxos de trabalho de CI/CD (.github/workflows/, .gitlab-ci.yml, scripts do Cloud Build) são montados como somente leitura e estritamente protegidos contra modificações.

• Integridade do pacote de testes: o agente não pode excluir, comentar ou modificar as declarações de teste de unidade atuais para simular uma correção.

• Raio de impacto limitado: as mudanças são estritamente limitadas aos caminhos de código do aplicativo diretamente responsáveis pelo coletor de vulnerabilidades.

• Verificação de porta dupla: um patch só é confirmado se os dois pacotes de testes do projeto (npm test, tsc) forem aprovados E o script de exploit ativo (exploit.sh) não conseguir reproduzir o ataque.

Etapa 2: inspecionar o status e a diferença do VCS usando cm vcs

Execute cm vcs status e cm vcs diff para ver os arquivos modificados do espaço de trabalho:

cm vcs status
cm vcs diff

Saída:

📂 CodeMender VCS Status
──────────────────────────────────────────────────
  Directory: /home/user/juice-shop
  Command:   git status --short
──────────────────────────────────────────────────

M routes/login.ts
?? .cm_project
?? .exploit/
2026-10-29T03:59:47Z [INFO]  📄 Session log: /home/user/.codemender/logs/20261029T035947Z_pending.log

As duas entradas não rastreadas são arquivos locais do CodeMender, não fazem parte da correção: .exploit/ contém os artefatos de verificação de cm verify, e .cm_project marca a raiz do projeto para o CodeMender. Você vai mantê-los fora do commit na próxima etapa.

E cm vcs diff:

🔍 Running diff in /home/user/juice-shop: git diff
diff --git a/routes/login.ts b/routes/login.ts
index fb9fce3..57f3afe 100644
--- a/routes/login.ts
+++ b/routes/login.ts
@@ -31,7 +31,14 @@ export function login () {

  return (req: Request, res: Response, next: NextFunction) => {
    verifyPreLoginChallenges(req) // vuln-code-snippet hide-line
-    models.sequelize.query(`SELECT * FROM Users WHERE email = '${req.body.email || ''}' AND password = '${security.hash(req.body.password || '')}' AND deletedAt IS NULL`, { model: UserModel, plain: true }) // vuln-code-snippet vuln-line loginAdminChallenge loginBenderChallenge loginJimChallenge
+    models.sequelize.query('SELECT * FROM Users WHERE email = :email AND password = :password AND deletedAt IS NULL', {
+      replacements: {
+        email: typeof req.body?.email === 'string' ? req.body.email : '',
+        password: security.hash(typeof req.body?.password === 'string' ? req.body.password : '')
+      },
+      model: UserModel,
+      plain: true
+    }) // vuln-code-snippet vuln-line loginAdminChallenge loginBenderChallenge loginJimChallenge
      .then((authenticatedUser) => { // vuln-code-snippet neutral-line loginAdminChallenge loginBenderChallenge loginJimChallenge
        const user = utils.queryResultToJson(authenticatedUser)
        if (user.data?.id && user.data.totpSecret !== '') {

Etapa 3: preparar o patch verificado com cm vcs stage

Depois de revisar o diff unificado e confirmar que a correção atende aos seus padrões de qualidade e segurança, prepare o patch para commit. Como cm vcs stage executa git add -A, ele prepara todas as mudanças na árvore de trabalho, incluindo as entradas .exploit/ e .cm_project não rastreadas da Etapa 2. Primeiro, adicione-os ao .git/info/exclude, um arquivo de ignorar somente local que o Git nunca confirma, para que apenas o patch seja preparado:

# Keep CodeMender's local files out of Git (local-only; not committed)
printf '.exploit/\n.cm_project\n' >> .git/info/exclude

Em seguida, prepare as mudanças usando cm vcs stage:

cm vcs stage

Saída:

📦 CodeMender VCS Stage
──────────────────────────────────────────────────
  Directory: /home/user/juice-shop
  Command:   git add -A
──────────────────────────────────────────────────

2026-10-29T04:00:06Z [INFO]  📄 Session log: /home/user/.codemender/logs/20261029T040006Z_pending.log
✅ Changes staged successfully.

Verifique se apenas o patch está preparado no Git:

cm vcs status

Saída:

📂 CodeMender VCS Status
──────────────────────────────────────────────────
  Directory: /home/user/juice-shop
  Command:   git status --short
──────────────────────────────────────────────────

M  routes/login.ts

Se você executou cm vcs stage antes de atualizar .git/info/exclude, remova os arquivos do CodeMender da área de preparo com git restore --staged .exploit .cm_project. Os arquivos permanecem no disco, eles são removidos apenas da área de preparo.

Reverter mudanças especulativas (cm vcs reset):

Se uma correção gerada com IA não estiver alinhada aos seus padrões de arquitetura ou introduzir uma lógica indesejável, execute cm vcs reset para descartar imediatamente todas as modificações do espaço de trabalho geradas durante a sessão e restaurar o repositório para o estado de referência limpo (git checkout HEAD -- . && git clean -fd).

Etapa 4: confirmar o patch e limpar os artefatos de verificação

Confirme o patch preparado antes de corrigir a próxima descoberta: cada execução de cm fix e cm verify começa redefinindo o espaço de trabalho (git checkout HEAD -- . && git clean -fd), o que descarta as mudanças não confirmadas. Em seguida, exclua a pasta local .exploit/ para que a próxima correção comece em um espaço de trabalho limpo. Como .exploit/ agora é ignorado, git clean -fd não o remove mais para você. Uma cópia permanente dos artefatos permanece em ~/.codemender/artifacts/<session-id>/.

git commit -m "fix: use parameterized query in login route"
rm -rf .exploit/

Se o Git pedir sua identidade, execute git config user.name "Your Name" e git config user.email "[e-mail]" no repositório e faça o commit novamente.

9. Validar patches, gerenciar sessões e exportar relatórios (cm report)

⏱️ Duração: 08:00

Depois de aplicar uma correção de segurança gerada com IA, é essencial gerenciar as sessões ativas, inspecionar as estatísticas de uso de tokens e gerar relatórios de compliance de segurança empresarial usando o cm report.

Etapa 1: gerenciar sessões com estado (cm session list / resume / cancel)

O CodeMender rastreia cada tarefa de verificação, verificação e correção como uma sessão com estado no banco de dados SQLite local (~/.codemender/state.db). Execute cm session list para inspecionar suas sessões:

cm session list

Saída:

SESSION_ID  TYPE    STATUS       TARGET                          CREATED              RESUMABLE
──────────  ────    ──────       ──────                          ───────              ─────────
ChA0Yjll    FIX     ✅ COMPLETED  ...40de-467d-8ca4-8571dca16036  2026-10-29T03:40:21  —
ChBkZTRh    VERIFY  ✅ COMPLETED  ...40de-467d-8ca4-8571dca16036  2026-10-29T03:11:21  —
ChBjMjI4    FIND    ✅ COMPLETED  /home/user/juice-shop           2026-10-29T03:01:40  —

3 session(s) total
2026-10-22T02:24:43Z [INFO]  📄 Session log: /home/user/.codemender/logs/20261022T022443Z_pending.log

Gerenciamento de sessões e auditabilidade empresarial:

• Sessões unificadas de vários workers e **INCOMPLETE** Status: ao auditar repositórios grandes com workers paralelos (--deep-workers 8), o CodeMender consolida todas as atividades simultâneas dos workers em uma única sessão pai unificada em cm session list, cm report e cm stats. Se uma verificação de vários arquivos --deep ou --diff tiver falhas parciais de worker enquanto outros arquivos forem bem-sucedidos, o CodeMender vai registrar o status da sessão como INCOMPLETE (em vez de COMPLETED ou FAILED), preservando todas as descobertas parciais encontradas e sinalizando claramente que alguns arquivos não foram totalmente verificados.

• Resiliência a interrupções e vazamento zero de tokens: se uma verificação ou correção de longa duração for interrompida por problemas de rede, limites de taxa ou cancelamento do usuário (Ctrl+C / SIGINT / cm session cancel), o CodeMender envia todas as interações de ferramentas concluídas e o consumo de tokens diretamente para o ~/.codemender/state.db. A contabilização de tokens em caminhos de saída de erro e cancelamento é estritamente preservada, garantindo 100% de precisão de auditoria com zero turnos omitidos. É possível retomar imediatamente com cm session resume <session-id> (transmitindo as mesmas flags da execução original, como --sandbox=false --bypass-warning -y) para continuar da última etapa concluída da ferramenta sem gastar novamente o orçamento de tokens.

• Comandos operacionais: liste sessões ativas e históricas com cm session list, cancele jobs de computação com cm session cancel <session-id> ou redefina bancos de dados locais com cm clean.

Etapa 2: execute cm report para verificar as descobertas corrigidas

Execute cm report -f table para exibir os status atualizados das descobertas (as descobertas corrigidas agora mostram FIXED com ✅ applied na coluna Fix):

cm report -f table

Saída:

┌──────────┬───────────┬──────┬──────────┬──────────────────────────────┬────────────────────────────────────────┐
│ID        │Severity   │Status│Fix       │File                          │Title                                   │
├──────────┼───────────┼──────┼──────────┼──────────────────────────────┼────────────────────────────────────────┤
│ 43aa7446 │🔴 CRITICAL│FIXED │✅ applied│routes/login.ts               │SQL Injection in User Login Handler A...│
│ dd83d0a4 │🟠 HIGH    │OPEN  │—         │routes/search.ts              │UNION-Based SQL Injection in Product ...│
│ 4dfe2409 │🟠 HIGH    │OPEN  │—         │routes/userProfile.ts         │Remote Code Execution via Eval in Use...│
│ 79d490b0 │🟠 HIGH    │OPEN  │—         │routes/fileUpload.ts          │Path Traversal (Zip Slip) in Zip File...│
│ 4f2b050c │🟠 HIGH    │OPEN  │—         │routes/fileUpload.ts          │XML External Entity (XXE) Injection i...│
│ 1ece0e25 │🟠 HIGH    │OPEN  │—         │server.ts                     │Missing Authorization on Product Upda...│
│ 757fd438 │🟠 HIGH    │OPEN  │—         │routes/trackOrder.ts          │NoSQL / JavaScript Injection in Order...│
│ 349bac9f │🟡 MEDIUM  │OPEN  │—         │routes/profileImageUrlUploa...│Server-Side Request Forgery (SSRF) in...│
│ be5e1459 │🟡 MEDIUM  │OPEN  │—         │routes/redirect.ts            │Open Redirect via Inadequate Allowlis...│
│ 06ecf8a5 │🟡 MEDIUM  │OPEN  │—         │routes/basket.ts              │Insecure Direct Object Reference (IDO...│
│ 02f6a293 │🟡 MEDIUM  │OPEN  │—         │routes/dataErasure.ts         │Local File Read via Insecure Template...│
│ 95ee59a3 │🟡 MEDIUM  │OPEN  │—         │routes/updateProductReviews.ts│NoSQL Injection in Product Review Upd...│
└──────────┴───────────┴──────┴──────────┴──────────────────────────────┴────────────────────────────────────────┘

12 finding(s): 1 CRITICAL, 6 HIGH, 5 MEDIUM · ✅ 1 fixed, 🔴 11 open
📋 Report generated at 2026-10-29 04:01:10 UTC
2026-10-29T04:01:10Z [INFO]  📄 Session log: /home/user/.codemender/logs/20261029T040110Z_pending.log

Etapa 3: verificar o uso de tokens usando cm stats

Execute cm stats para inspecionar o consumo de tokens locais em todos os modos de verificação (cm find --quick, cm verify e cm fix):

cm stats

Saída:

COMMAND          REQUESTS  POLLS  INPUT   OUTPUT  CACHED  THOUGHT  TOOL_CALLS  TOTAL   CACHE_HIT%  THINK_RATIO%  DURATION
───────          ────────  ─────  ─────   ──────  ──────  ───────  ──────────  ─────   ──────────  ────────────  ────────
total            3         186    10.7M   23.1k   9.9M    55.5k    0           10.8M   91.8%       70.7%         35m 54s
cm find --quick  1         33     2.0M    9.4k    1.8M    15.2k    0           2.1M    90.6%       61.8%         05m 44s
cm fix           1         33     870.9k  908     678.6k  20.3k    0           892.2k  77.9%       95.7%         04m 40s
cm verify        1         120    7.8M    12.7k   7.3M    20.0k    0           7.9M    93.6%       61.1%         25m 31s

3 turn(s) across 3 command type(s) in the last 7 days
2026-10-22T02:24:46Z [INFO]  📄 Session log: /home/user/.codemender/logs/20261022T022446Z_pending.log

Observabilidade de tokens em três níveis e alinhamento de FinOps:

O CodeMender oferece visibilidade completa da economia de raciocínio de IA em três camadas operacionais:

1. Linha contínua em tempo real (--compact): rastreamento de tokens em tempo real durante a execução da ferramenta sem desordem no terminal.
2. Resumo de saída do comando: contagem de etapas, tempo de execução decorrido e totais de tokens de entrada/saída/raciocínio após a conclusão do comando.
3. Painel unificado de sessões e invocações (cm stats): toda a telemetria de tokens é consolidada em um modelo de sessão unificado que reflete diretamente as faturas do Google Cloud Billing. Além dos tokens brutos, a exportação de cm stats --json fornece métricas de invocação de modelo (invocations.total, per_session, per_turn), permitindo que as equipes de SecOps e FinOps monitorem o consumo de cotas da API, a frequência de turnos de raciocínio e as taxas de ocorrência em cache (CACHE_HIT%) em sessões durante qualquer período (--since 168h).

Etapa 4: gerar e visualizar o relatório HTML interativo (cm report -f html)

Exporte as descobertas da verificação e os patches aplicados como um painel HTML interativo e independente:

cm report -f html
cp ~/.codemender/reports/report.html ./report.html

Para ver report.html no Google Cloud Shell:

Inicie um servidor da Web de pré-lançamento local no terminal do Cloud Shell:

python3 -m http.server 8080

Na barra de ferramentas no canto superior direito do Cloud Shell, clique no botão Visualização na Web (ícone com olho/tela) ➔ Visualizar na porta 8080 para ver o painel de compliance interativo no navegador.

(Alternativa) No explorador de arquivos do editor do Cloud Shell, clique com o botão direito do mouse em report.html e em Fazer download para visualizar o arquivo no navegador local.

Etapa 5: principais recursos do relatório HTML interativo gerado

Confira abaixo uma análise dos principais componentes do relatório HTML interativo gerado (report.html):

1. Cabeçalho de métricas executivas e cards de postura

Metadados do cabeçalho: exibe detalhes do repositório de destino (OWASP Juice Shop), total de arquivos de origem verificados (684 files) e carimbo de data/hora de geração do UTC.

Grade de cards de métricas: fornece uma visão geral instantânea de alto nível do total de descobertas, distribuições de gravidade (CRITICAL, HIGH, MEDIUM, LOW) e total de vulnerabilidades corrigidas (FIXED).

2. Tabela de resumo de descobertas interativas

Matriz de vulnerabilidade: mostra uma tabela filtrável com ID, Severity, Status (OPEN x FIXED), CWE Type, File Location, Vulnerability Title e Confidence Score.

3. Análise profunda da causa raiz e snippet de código-fonte vulnerável

Análise recolhível (RCA): ao clicar em qualquer linha de descoberta, a análise detalhada da causa raiz sintetizada pelo modelo de raciocínio de segurança do Gemini é aberta.

Snippet de código-fonte vulnerável: mostra os números de linha exatos e o código-fonte com destaque de sintaxe ao redor do coletor vulnerável.

4. Diferenças de patch de correção de IA sintetizadas

Visualização de diferenças unificada: para vulnerabilidades corrigidas (FIXED), o CodeMender renderiza um bloco de diferenças unificado que destaca as adições de código do aplicativo aplicadas em verde (+) e o código vulnerável removido em vermelho (-).

Etapa 6: (opcional) Importar descobertas de SAST de terceiros (cm report import)

O CodeMender não se limita às falhas descobertas pelo próprio verificador. As equipes podem importar resultados de SAST externos (por exemplo, do Semgrep, Snyk, SonarQube ou Fortify) usando um esquema JSON padronizado ou um assistente interativo, permitindo que o CodeMender verifique e sintetize correções para eles imediatamente:

# Create a sample third-party findings JSON file
cat << 'EOF' > ./findings.json
[
 {
   "file_path": "routes/basket.ts",
   "line": 18,
   "title": "SQL Injection in Basket Handler",
   "message": "Raw basket ID concatenated in query",
   "severity": "HIGH",
   "vuln_type": "CWE-89"
 }
]
EOF

# Ingest findings into CodeMender state database
cm report import --file ./findings.json

Saída:

Successfully imported 1 findings.
2026-10-22T02:27:10Z [INFO]  📄 Session log: /home/user/.codemender/logs/20261022T022710Z_pending.log

10. Limpar recursos

⏱️ Duração: 01:00

Para evitar o uso desnecessário de disco no ambiente shell do Google Cloud Shell e liberar espaço dos recursos temporários do workshop, siga estas etapas de limpeza.

Etapa 1: limpar o cache local do CodeMender e remover o repositório

O CodeMender oferece um comando cm clean integrado para limpar o banco de dados de descobertas locais (~/.codemender/state.db), os relatórios HTML e os arquivos de backup de origem. Execute os seguintes comandos no Cloud Shell:

# Purge local SQLite findings cache, HTML reports, and backup files
cm clean

# Remove cloned repository
cd ~
rm -rf ~/juice-shop

Etapa 2: (opcional) desativar as APIs do Google Cloud

Se você não planeja usar as APIs do CodeMender ou da Agent Platform neste projeto para desenvolvimento futuro, desative as APIs de serviço:

gcloud services disable \
 aiplatform.googleapis.com \
 cloudresourcemanager.googleapis.com \
 --project=${PROJECT_ID}

Observação: a desativação das APIs vai interromper todas as sessões ou integrações ativas associadas aos serviços da Agent Platform no seu projeto.

11. Parabéns

⏱️ Duração: 02:00

Parabéns! Você transformou o OWASP Juice Shop de um aplicativo intencionalmente vulnerável em uma base de código protegida e segura usando o CodeMender na Gemini Enterprise Agent Platform do Google Cloud.

O que você aprendeu

Correção autônoma de ciclo fechado: o CodeMender vai além do ruído de alertas estáticos passivos ao executar um ciclo de vida de segurança completo e autodirigido, desde a descoberta do repositório (cm find) até a verificação de exploits em sandbox (cm verify) e a síntese de patches testados para regressão (cm fix).

Provas de exploração baseadas em evidências: ao capturar artefatos de verificação tangíveis (PLAN.md, LOG.md, exploit.sh, REPORT.md), o CodeMender elimina falsos positivos e comprova a capacidade de exploração no mundo real antes de escrever qualquer código.

Correções idiomáticas e sensíveis ao contexto: em vez de aplicar substituições de texto genéricas, os agentes de raciocínio do Gemini analisam a arquitetura do aplicativo, os modelos de dados e os ORMs para produzir patches limpos e fáceis de manter (como consultas parametrizadas do Sequelize) que preservam a lógica de negócios atual.

Proteções integradas de segurança e teste: cada correção proposta é validada automaticamente em relação aos pacotes de teste do projeto (npm test) e aos verificadores de tipo (tsc) em sandboxes de espaço de trabalho isoladas antes que as mudanças sejam preparadas.

Mudança de mentalidade do desenvolvedor

Fluxo de trabalho tradicional de SAST manual	Correção autônoma com o CodeMender (cm)
Fadiga de alertas: horas gastas na triagem de relatórios ruidosos com altas taxas de falsos positivos.	Agentic Code Discovery (cm find .): verificação profunda e contextual de repositórios com tecnologia dos modelos do Gemini.
Verificação manual de PoC: criação de payloads curl personalizados e scripts de ataque para confirmar vulnerabilidades.	Provas de exploração automatizadas (cm verify ): síntese automática de planos de validação executáveis, registros e scripts de shell.
Refatoração manual de alto risco: correção manual de consultas de banco de dados complexas, geralmente introduzindo erros de sintaxe ou de tempo de execução.	Síntese de patch idiomática (cm fix ): geração de diffs com reconhecimento de contexto adaptada aos ORMs e padrões de framework atuais.
Riscos de regressão de produção: os patches de segurança frequentemente interrompem a lógica de negócios ou os testes downstream.	Proteções de teste automatizadas: validação contínua em relação a pacotes de testes locais e sandboxes de processos isolados.
Compilações manuais de compliance: agregar manualmente as descobertas em documentos estáticos para análises de auditoria.	Telemetria padronizada e SARIF (cm report -f sarif): exportação instantânea de OASIS SARIF v2.1.0, painéis HTML e análise de tokens.

Próximas etapas

🚀 Continue a trilogia do CodeMender:

Parte 2: Proteja seu pipeline de CI/CD com o CodeMender — Automatize a verificação contínua sem interface gráfica, a integração do painel SARIF e as solicitações de pull de autorrecuperação no GitHub Actions.

Parte 3: Vibe coding seguro com Antigravity e CodeMender — Combine o desenvolvimento de IA generativa com um assistente de segurança autônomo.

📖 Confira a documentação:

Documentação do CodeMender no Google Cloud

Soluções de segurança do Google Cloud

💡 Aplique aos seus próprios projetos:

Execute cm find . e cm fix nos seus próprios repositórios Node.js, Python, Go, Java, Rust ou C/C++.