Proteggere l'applicazione con CodeMender

1. Prima di iniziare

⏱️ Durata: 03:00

Nota: CodeMender è attualmente disponibile per un numero limitato di clienti in Anteprima pubblica. Contatta il team di vendita per ottenere l'accesso.

Avviso relativo alla versione pre-GA e all'Anteprima pubblica: CodeMender è attualmente disponibile per un gruppo limitato di clienti in Anteprima pubblica. I prodotti pre-GA si trovano in varie fasi di test e revisione interni. Pertanto, i clienti devono supervisionare attentamente l'utilizzo di CodeMender e non utilizzarlo in situazioni in cui non è possibile correggere errori gravi. Questo prodotto viene reso disponibile ai Clienti esclusivamente per test e valutazioni limitati e non può essere utilizzato per scopi commerciali o di produzione.

Avviso sui filtri di sicurezza e sulla conferma umana: quando disattiva la conferma umana delle azioni di scrittura e di esecuzione degli strumenti (come configurato in ~/.codemender/config.yaml o nei flag dell'interfaccia a riga di comando non interattiva come -y e --bypass-warning), il Cliente è responsabile di tale modifica ai sensi della Sezione 20(j) ("Modificare, ignorare o disabilitare i filtri di sicurezza") dei Termini specifici dei servizi. I Clienti accettano di non bypassare o aggirare automaticamente altre risposte che richiedono la conferma umana.

Ti diamo il benvenuto nel codelab pratico per proteggere la tua applicazione con CodeMender su Gemini Enterprise Agent Platform di Google Cloud.

In questo workshop, ti metterai nei panni di un Cloud Security Engineer con il compito di controllare e proteggere OWASP Juice Shop, l'applicazione web standard di settore, intenzionalmente vulnerabile, creata con Node.js, Express, TypeScript e Angular.

Gli strumenti di scansione della sicurezza tradizionali (SAST/DAST) inondano i team di sviluppo con migliaia di risultati di sicurezza statici, tassi elevati di falsi positivi e zero correzioni del codice attuabili. Gli sviluppatori dedicano ore alla valutazione dei log, al monitoraggio dei flussi di dati e alla scrittura manuale di patch che spesso interrompono il comportamento delle applicazioni esistenti.

CodeMender rivoluziona la sicurezza del codice avvolgendo un'infrastruttura agentica ottimizzata attorno agli LLM Gemini di Google. Utilizzando prompt progettati da Google DeepMind, competenze di sicurezza specializzate e orchestrazione multi-agente, CodeMender agisce come un co-sviluppatore autonomo di sicurezza AI che trova, verifica e corregge le vulnerabilità del software direttamente nei repository di codice sorgente locali.

Prerequisiti

• Conoscenza di base delle vulnerabilità delle applicazioni web (OWASP Top 10, come SQL injection e XSS)
• Conoscenza di base delle applicazioni JavaScript/TypeScript e Node.js
• Conoscenza di base degli strumenti dell'interfaccia a riga di comando (CLI)

Cosa imparerai a fare

• Come configurare, autenticare e inizializzare l'interfaccia a riga di comando di CodeMender (cm) in Google Cloud Shell.
• Come scansionare autonomamente un repository per scoprire vulnerabilità sfruttabili (cm find).
• Come convalidare le vulnerabilità in sandbox isolate e ispezionare gli artefatti di verifica (cm verify).
• Come sintetizzare, testare e applicare autonomamente patch di sicurezza sensibili al contesto (cm fix).
• Come controllare la telemetria dei token ed esportare report di conformità multiformato (cm stats, cm report).

Cosa serve

• Un progetto cloud Google Cloud con la fatturazione abilitata
• Google Cloud Shell con connessione attiva al progetto (include gcloud, git e Node.js 18+ preinstallati)
• Repository iniziale: repository GitHub OWASP Juice Shop

2. Introduzione all'architettura di CodeMender

⏱️ Durata: 04:00

Prima di passare alla scansione e alla correzione del codice, cerchiamo di capire come funziona CodeMender dietro le quinte all'interno di Gemini Enterprise Agent Platform in base agli standard ufficiali dell'architettura di Google Cloud.

Nota: CodeMender è composto da una piattaforma di ragionamento multi-agente in hosting e da un file binario client locale (cm) che opera all'interno di una sandbox di processo locale isolata per creare codice, eseguire script di riproduzione e verificare le correzioni di sicurezza.

Architettura del sistema: agente e daemon client

Dal punto di vista dell'utente, CodeMender comprende due componenti architetturali principali:

Piattaforma multi-agente in hosting: un sistema multi-agente in hosting in esecuzione su Google Cloud che esegue la logica di business della sicurezza di base, il prompt engineering degli LLM e il ragionamento sulla sicurezza.

Interfaccia a riga di comando del client locale e daemon sandbox (cm): un client in esecuzione in Google Cloud Shell che funge sia da interfaccia a riga di comando (per eseguire comandi come cm find, cm verify, cm fix) sia da daemon locale (per eseguire in sicurezza i comandi per conto dell'agente all'interno di una sandbox isolata a livello di processo).

Le 3 funzionalità principali di correzione

CodeMender gestisce la sicurezza del codice attraverso tre fasi integrate:

Trova vulnerabilità (cm find): analizza i codebase utilizzando un LLM guidato dall'agente, sfruttando strumenti di sicurezza specializzati e prompt engineering per concentrare il modello sulle falle di sicurezza. In alternativa, i risultati possono essere importati da strumenti di scansione della sicurezza esterni.

Verifica delle vulnerabilità (cm verify): crea il codice localmente e tenta di sfruttare i difetti rilevati per verificare se sono sfruttabili. In questo modo si eliminano i falsi positivi e si generano artefatti di verifica persistenti dell'area di lavoro in .exploit/ (info.yaml, PLAN.md, LOG.md, exploit.sh, REPORT.md).

Correggi le vulnerabilità (cm fix): sintetizza le patch di origine sensibili al linguaggio e le verifica eseguendo le suite di test di regressione e di build del progetto (npm test) all'interno della sandbox locale.

3. Configura l'ambiente OWASP Juice Shop

⏱️ Durata: 05:00

In questo passaggio, aprirai l'ambiente del terminale Google Cloud e recupererai il repository dell'applicazione di destinazione.

Passaggio 1: apri Cloud Shell nella console Google Cloud

Vai alla console Google Cloud nel browser.

Nella barra di navigazione in alto, fai clic sul pulsante Attiva Cloud Shell (icona >_).

Cloud Shell fornisce un terminale Linux basato su browser con gcloud, git e Node.js preinstallati e autenticati.

Passaggio 2: clona il repository OWASP Juice Shop

In Cloud Shell o nel terminale locale, clona il repository OWASP Juice Shop:

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

Passaggio 3: esamina i file chiave dell'applicazione

OWASP Juice Shop utilizza Express.js nel backend con moduli TypeScript. Dai una rapida occhiata alla struttura della directory:

ls -la routes/ lib/

Osserva i file di route principali che gestiscono l'autenticazione, le query degli utenti e l'amministrazione del carrello:

routes/login.ts: gestisce l'autenticazione degli utenti e l'esecuzione di query SQL non elaborate.

routes/search.ts: gestisce la ricerca dei prodotti e il rendering delle risposte.

routes/basket.ts: gestisce il recupero del carrello degli acquisti dell'utente.

routes/trackOrder.ts: gestisce il monitoraggio degli ordini tramite query NoSQL.

lib/xml.ts: gestisce l'analisi XML e i caricamenti dei file.

lib/insecurity.ts: utilità di supporto per i token di sessione e la crittografia.

4. Installa l'interfaccia a riga di comando CodeMender (cm) e autentica le credenziali GCP

⏱️ Durata: 08:00

In questo passaggio, abiliterai le API Google Cloud richieste, concederai le autorizzazioni IAM utilizzando gcloud, scaricherai e installerai il file binario dell'interfaccia a riga di comando cm e configurerai le Credenziali predefinite dell'applicazione (ADC).

Passaggio 1: abilita le API Google Cloud richieste tramite gcloud

CodeMender richiede l'API Agent Platform (aiplatform.googleapis.com) e l'API Cloud Resource Manager (cloudresourcemanager.googleapis.com) su Gemini Enterprise Agent Platform.

In Cloud Shell o nel terminale, recupera l'ID progetto attivo (o controlla il menu a discesa del progetto nella parte superiore della console Google Cloud) e abilita le API di servizio richieste:

# 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}

Verifica che le API siano abilitate:

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

Passaggio 2: concedi le autorizzazioni IAM tramite gcloud

Per interagire con il motore di ragionamento cloud CodeMender, agli utenti e ai service account deve essere assegnato il ruolo IAM roles/aiplatform.user (Agent Platform User).

Navigazione nella console: puoi anche verificare o concedere questo ruolo nella console Google Cloud andando su Menu di navigazione ☰ > IAM e amministrazione > IAM, individuando il tuo account e controllando i ruoli assegnati.

Concedi il ruolo IAM al tuo account utente tramite l'interfaccia a riga di comando

# 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"

Passaggio 3: scarica e installa l'interfaccia a riga di comando di cm in Cloud Shell

In Google Cloud Shell, i dati utente vengono archiviati in modo permanente nella directory $HOME. Esegui i seguenti comandi per installare cm in ~/bin senza richiedere sudo. Sei ancora in ~/juice-shop dalla sezione precedente, quindi i comandi vengono scaricati in una directory temporanea e poi eliminati. In questo modo, nessun file del programma di installazione finisce nel repository di 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

Best practice di Cloud Shell: archiviazione permanente in $HOME

Google Cloud Shell esegue il provisioning di 5 GB di spazio di archiviazione su disco permanente, montato in $HOME. Tutto ciò che si trova al di fuori della tua home directory utente (ad esempio /usr/local/bin o la directory root di sistema) è temporaneo e viene reimpostato quando la VM di Cloud Shell viene riciclata. L'installazione dei file binari in ~/bin garantisce che cm persista in tutte le sessioni future di Cloud Shell e la voce ~/.bashrc mantiene ~/bin sul tuo PATH in modo che cm sia pronto per l'uso ogni volta che apri un nuovo terminale.

Supporto multipiattaforma (macOS, Linux ARM64, Windows):

Se l'esecuzione avviene al di fuori di Cloud Shell sulla tua workstation locale, scarica i pacchetti dal repository ufficiale cmoc-prod/codemender-cli-production utilizzando gcloud artifacts generic download o 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 (tramite PowerShell Invoke-WebRequest).

Passaggio 4: verifica l'installazione dell'interfaccia a riga di comando di cm

Esegui cm --version per verificare che il file binario della CLI sia installato correttamente:

cm --version

Output previsto:

cm version 0.17.0

Passaggio 5: configura le Credenziali predefinite dell'applicazione (ADC) di Google Cloud

Configura le Credenziali predefinite dell'applicazione (ADC) di Google Cloud in modo che cm possa autenticare le richieste al motore di ragionamento cloud:

gcloud auth application-default login

Verrà visualizzata una finestra di dialogo modale di autorizzazione con l'etichetta Autorizza Cloud Shell. Fai clic su Autorizza per concedere l'accesso.

Attivazione guidata della piattaforma:

Se il tuo progetto cloud Google Cloud o la tua identità utente richiede l'attivazione iniziale della piattaforma o l'onboarding delle policy, CodeMender avvia automaticamente il browser predefinito sulla pagina di destinazione dell'attivazione e attende la conferma direttamente nel terminale, eliminando gli errori di uscita improvvisa.

5. Inizializza e verifica il workspace di CodeMender

⏱️ Durata: 03:00

Ora che cm è installato e autenticato, inizializzerai l'area di lavoro di CodeMender all'interno della directory del progetto di destinazione e verificherai la configurazione dell'ambiente.

Passaggio 1: inizializza l'area di lavoro di CodeMender (cm init)

Esegui cm init dalla directory radice del progetto per inizializzare i file di monitoraggio dello stato locale e stabilire le configurazioni di base:

cm init

Output:

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

Passaggio 2: esegui la diagnostica di integrità end-to-end (cm health)

Prima di avviare una sessione dell'agente, esegui cm health per verificare le credenziali, la configurazione, la raggiungibilità e l'autorizzazione:

cm health

Output:

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)

Passaggio 3: comprendere i parametri di configurazione (config.yaml)

CodeMender crea un file di configurazione dell'area di lavoro in .codemender/config.yaml (o ~/.codemender/config.yaml). Questo file definisce i limiti delle policy, le regole di inclusione dei file e gli hook di verifica dei test:

# 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/*"])

Impostazioni chiave per questo codelab:

• Modalità Workshop (--sandbox=false, **--bypass-warning e** **-y)**: CodeMender applica tre limiti di sicurezza indipendenti: la sandbox a livello di sistema operativo (sandbox.enabled / --sandbox), il limite del percorso dell'area di lavoro (project_paths / --allow-all-paths) e la lista bloccata dei comandi (command_policy.yaml / --allow-all-commands). Poiché questo lab viene eseguito in una VM Google Cloud Shell isolata su un progetto di esempio, i passaggi successivi passano --sandbox=false per disattivare solo la sandbox a livello di sistema operativo per un'esecuzione prevedibile dello strumento, oltre a --bypass-warning e -y per saltare l'avviso di esecuzione dell'host e i prompt di conferma. Il limite del percorso e la lista bloccata dei comandi rimangono applicati e questo codelab non richiede mai --allow-all-paths o --allow-all-commands. Sulla tua workstation o durante la scansione di repository non attendibili, mantieni attiva la sandbox: nasconde le directory delle credenziali come ~/.ssh e ~/.config/gcloud ai comandi eseguiti dall'agente, rimuove le variabili di ambiente simili a secret (come *_TOKEN* e _KEY) e mantiene .git/hooks e .codemender in sola lettura.

• Verifica automatica dei test (build.command): se configurato (ad es. npm test), cm fix esegue automaticamente la suite di test per garantire che le patch di sicurezza generate non introducano regressioni. Per il riferimento di configurazione completo, consulta la documentazione ufficiale di CodeMender.

6. Scopri le vulnerabilità con cm find .

⏱️ Durata: 07:00

In questo passaggio, eseguirai cm find . --quick per eseguire una scansione di sicurezza agentica nel codebase di Juice Shop.

Passaggio 1: esegui cm find . --quick

A partire da CodeMender v0.16.0, cm find <path> viene impostato per impostazione predefinita su Deep Scan (

--deep

) per un'analisi esaustiva file per file, mentre Scansione rapida (

--quick

) fornisce un triage rapido del repository. Esegui cm find . --quick per eseguire un'analisi rapida nel repository OWASP Juice Shop (tempo di esecuzione stimato: circa 8 minuti per il triage completo del codebase di 684 file):

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

cm avvia una sessione di scansione sulla Gemini Enterprise Agent Platform, analizzando i file del codice sorgente in tutti i moduli del repository:

⚠️ 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

Suggerimento: scelta di modalità e modelli di scansione:

• Modalità di scansione: utilizza --quick per un triage rapido e interattivo del repository (~8 minuti), il valore predefinito --deep (cm find .) per audit esaustivi file per file o --diff per i controlli delle richieste di pull CI/CD (trattati nella Parte 2 di questa serie di codelab).

• Modelli di ragionamento: gemini-3.8-flash (predefinito) è ottimizzato per un triage rapido e correzioni mirate, mentre --model gemini-4-argon fornisce una finestra contestuale da 1 milione di token per un'analisi approfondita del flusso di dati multimodulo.

Passaggio 2: esamina i risultati della scansione tramite cm report

Esegui cm report -f table per visualizzare tutti i risultati relativi alla sicurezza rilevati dal database di stato SQLite locale:

cm report -f table

Output:

┌──────────┬───────────┬──────┬───┬──────────────────────────────┬────────────────────────────────────────┐
│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

Nota importante sugli ID di ricerca dinamici:

Ogni scansione di CodeMender genera dinamicamente ID di risultati esadecimali univoci di 8 caratteri (ad esempio 43aa7446, dd83d0a4, 79d490b0). Gli ID mostrati in questo tutorial sono acquisiti dalla nostra esecuzione di riferimento. Nei seguenti passaggi di correzione, copia e utilizza l'ID risultato esatto corrispondente a routes/login.ts, come visualizzato nella tabella di output cm report del tuo terminale.

Passaggio 3: comprendere gli stati del ciclo di vita e i livelli di gravità dei risultati

CodeMender monitora le vulnerabilità attraverso un ciclo di vita formale a quattro stati:

Stato del risultato	Significato e gestione della transizione
OPEN	La vulnerabilità è stata rilevata (o importata), ma non è stata ancora verificata, corretta o ignorata.
FIXED	CodeMender ha generato una patch, applicato la differenza e verificato che le suite di build/test vengano superate e gli exploit non vadano a buon fine.
DISMISSED	Contrassegnata come inattiva a causa di un livello di confidenza basso, non rientra nel modello di minacce o è stata verificata come falso positivo. Disattiva gli avvisi futuri.
REOPENED	Un difetto precedentemente FIXED o DISMISSED rilevato nuovamente in una scansione successiva (che indica una regressione del codice).

Classificazioni della gravità

🔴 CRITICAL: rischio immediato e grave (ad es. esecuzione di codice da remoto, SQL injection non autenticata) direttamente raggiungibile da confini non attendibili.

🟠 HIGH: difetto grave (ad es. lettura arbitraria del database, escalation dei privilegi) che richiede un contesto utente specifico o condizioni concatenate.

🟡 MEDIUM: rischio moderato con ambito limitato o che richiede l'interazione dell'utente (ad es. Open Redirect, CSRF).

🔵 LOW: difetti di igiene della difesa in profondità o vettori di ricognizione con un impatto diretto minimo.

7. Verificare le vulnerabilità ed esaminare gli artefatti di verifica acquisiti

⏱️ Durata: 10:00

Una delle funzionalità principali di CodeMender è la generazione automatica di artefatti di verifica persistenti ogni volta che esegui cm verify. Verifichiamo il risultato SQL injection critico in routes/login.ts (illustrato come 43aa7446 in questo tutorial) ed esaminiamo gli artefatti creati dall'agente.

Passaggio 1: esegui cm verify <login-finding-id>

Individua l'ID del risultato per routes/login.ts dalla tabella cm report (ad esempio, 43aa7446) ed esegui cm verify <finding-id> --sandbox=false --bypass-warning -y (tempo di esecuzione stimato: circa 20 minuti per eseguire i passaggi dello strumento autonomo, avviare i servizi in background ed eseguire gli script di exploit PoC in tempo reale):

# 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

Output:

⚠️ 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

Opzioni di verifica e riepilogo di uscita:

• Solo verifica statica (--skip-exploit-verification): in ambienti sensibili o cluster di gestione temporanea in cui è vietata l'esecuzione di payload di exploit attivi, passa --skip-exploit-verification per eseguire l'analisi semantica statica solo senza lanciare exploit PoC attivi.

• Riepilogo dell'uscita del comando: al termine della verifica, CodeMender genera un riepilogo del completamento:

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

Tieni presente che il conteggio dei token total include i token di ragionamento interni, che potrebbero superare in + out.

Passaggio 2: panoramica degli artefatti di verifica acquisiti

A partire da CodeMender v0.16.0, gli artefatti di verifica sono standardizzati nella directory root del repository in .exploit/, mentre una copia persistente viene conservata in ~/.codemender/artifacts/<session-id>/. Si tratta di file di lavoro locali, non di parte della correzione, quindi li escluderai da Git prima di eseguire lo stage della patch nella sezione successiva. Esegui ls -la .exploit/ per elencarle:

ls -la .exploit/

Output:

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

File artefatto	Categoria	Purpose
info.yaml	Manifest dei metadati	YAML strutturato che definisce l'UUID, il titolo, la gravità (CRITICAL), l'affidabilità (certain) e i tag CWE (cwe-89) del risultato.
PLAN.md	Strategia degli agenti	Piano di verifica passo passo ed elenco di controllo eseguiti in modo autonomo dal motore di ragionamento di CodeMender.
LOG.md	Log di traccia dell'esecuzione	Traccia di audit con timestamp che registra ogni chiamata allo strumento, endpoint della richiesta HTTP e risultato del test.
server_runner.js/server.log	Log del runner/server helper	Script helper creato dall'agente per avviare Juice Shop per i test e l'output del server acquisito.
exploit.sh	Execution Wrapper / Standalone PoC	Wrapper di script shell che avvia il servizio di destinazione e chiama il client PoC, convalidando le risposte HTTP 200.
REPORT.md	Analisi delle cause principali	Riepilogo esecutivo, analisi delle vulnerabilità riga per riga, analisi SQL non elaborata e suggerimenti per la parametrizzazione di Sequelize.

I file helper variano in base all'esecuzione:

A seconda della vulnerabilità e della strategia selezionata dall'agente, potrebbe creare file helper utilizzati da exploit.sh (in questa esecuzione, server_runner.js e server.log) o inserire tutta la logica direttamente in exploit.sh. Entrambi sono artefatti di riproduzione validi e completamente automatizzati acquisiti in .exploit/.

Passaggio 3: procedura dettagliata approfondita dei punti salienti degli artefatti di verifica

L'agente scrive questi artefatti da zero a ogni esecuzione, quindi i contenuti esatti cambiano ogni volta. Aprile nell'editor di Cloud Shell (o con cat) e cerca quanto segue:

Artefatto	Cosa cercare
info.yaml	L'ID completo, il titolo, la gravità, l'affidabilità e i tag del risultato, ad esempio cwe-89.
PLAN.md	L'elenco di controllo seguito dall'agente, dalla lettura del file segnalato alla scrittura dello script di riproduzione.
LOG.md	Azioni e risultati con timestamp, incluso l'esito di ogni esecuzione dello script di riproduzione.
exploit.sh	Lo script di riproduzione autonomo: come avvia l'app, quale endpoint ha come target e come decide l'esito positivo (stampa EXPLOIT SUCCESSFUL).
server_runner.js/server.log	File di supporto creati dall'agente per avviare Juice Shop per i test e l'output del server.
REPORT.md	L'analisi delle cause principali: la riga vulnerabile in routes/login.ts, il motivo per cui è sfruttabile e la correzione consigliata (query parametrizzate).

Automated Refactor Tracking & Executable PoC Artifacts in Practice:

• Moved Code Tracking across Refactors: nei team di sviluppo in rapida evoluzione, gli sviluppatori riorganizzano spesso le directory (ad esempio spostando routes/login.ts in un percorso modulare come src/auth/login.ts). Gli scanner di vulnerabilità tradizionali perdono il tracciamento quando i file vengono spostati, generando report orfani o errori "file non trovato". Il monitoraggio semantico di CodeMender rileva il codice spostato tra ridenominazioni e spostamenti di directory, aggiornando automaticamente i record dei risultati e i numeri di riga in ~/.codemender/state.db.

• Da script PoC a test di regressione: l'artefatto di verifica .exploit/exploit.sh viene generato con autorizzazioni eseguibili POSIX (chmod +x). Poiché .exploit/ rimane fuori da Git, i team che desiderano un controllo di regressione permanente possono esaminare lo script, adattarlo alla propria suite di test (ad esempio, in test/security/) ed eseguirne il commit deliberatamente, in modo che una modifica futura non possa reintrodurre silenziosamente la vulnerabilità.

8. Correggi la SQL injection con la correzione di cm

⏱️ Durata: 10:00

Ora che abbiamo verificato il risultato dell'SQL injection in routes/login.ts (ID di esempio 43aa7446) ed esaminato i relativi artefatti, eseguiamo cm fix per applicare una patch di query con parametri automatizzata.

Passaggio 1: esegui cm fix <login-finding-id> -y

Esegui cm fix <finding-id> --sandbox=false --bypass-warning -y (sostituisci 43aa7446 con l'ID risultato di accesso effettivo di cm report) per sintetizzare e applicare una correzione:

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

Suggerimento: indirizza l'agente Fix con **--context e --no-cache**:

Puoi passare -c, --context <text> per guidare l'agente di correzione con requisiti specifici del dominio (ad es. cm fix 43aa7446 -c "Use Sequelize named replacements" -y). Per bypassare le patch memorizzate nella cache e forzare una nuova sessione di ragionamento AI, passa --no-cache.

Output:

⚠️ 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

Approfondimento: come l'agente di correzione ha scoperto la correzione parametrizzata ottimale:

Nota come l'agente non ha semplicemente inserito la logica di sostituzione delle stringhe. Esplorando la struttura del progetto:

1. Rilevamento del contesto: ha esaminato routes/login.ts e cercato gli utilizzi di sequelize.query e UserModel in routes/ per capire in che modo i gestori downstream si aspettano che venga restituita l'istanza UserModel.
2. Analisi dei riferimenti: ha esaminato routes/vulnCodeFixes.ts e routes/vulnCodeSnippet.ts per conservare le annotazioni delle sfide richieste (// vuln-code-snippet vuln-line ...).
3. Parametrizzazione idiomatica: ha sostituito l'interpolazione di stringhe letterali di template non elaborati ('${req.body.email || ''}') con sostituzioni di associazioni denominate di Sequelize (WHERE email = :email AND password = :password, replacements: { email: ..., password: ... }), immunizzando completamente l'endpoint contro la SQL injection e preservando i tipi restituiti esatti ({ model: UserModel, plain: true }). Ha inoltre aggiunto controlli dei tipi in modo che gli input non di stringa vengano sostituiti da una stringa vuota.
4. Verifica in tempo reale: ha eseguito il linting del file (npx eslint), ha ricreato il server (npm run build:server), ha eseguito nuovamente i test del server (npm run test:server) e ha confermato che lo script di riproduzione non ha più esito positivo.

Enterprise Safety Guardrails: Why the Fix Agent Cannot "Cheat":

Una preoccupazione comune quando si adottano agenti di programmazione AI autonomi è: l'agente disabiliterà i test non riusciti o indebolirà i gate CI/CD solo per forzare un punteggio positivo?

CodeMender risolve questo problema tramite rigide protezioni per le correzioni con ambito architetturali:

• Pipeline immutabili: i workflow CI/CD (.github/workflows/, .gitlab-ci.yml, script di Cloud Build) sono montati in sola lettura e rigorosamente protetti da modifiche.

• Integrità della suite di test: all'agente è vietato eliminare, commentare o modificare le asserzioni dei test di unità esistenti per simulare una correzione.

• Raggio d'azione limitato: le modifiche sono strettamente limitate ai percorsi del codice dell'applicazione direttamente responsabili del sink della vulnerabilità.

npm testtscexploit.sh

Passaggio 2: controlla lo stato e la differenza del VCS utilizzando cm vcs

Esegui cm vcs status e cm vcs diff per visualizzare i file dell'area di lavoro modificati:

cm vcs status
cm vcs diff

Output:

📂 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

Le due voci non monitorate sono i file locali di CodeMender, non fanno parte della correzione: .exploit/ contiene gli artefatti di verifica di cm verify e .cm_project contrassegna la directory root del progetto per CodeMender. Nel passaggio successivo, li escluderai dal commit.

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 !== '') {

Passaggio 3: prepara la patch verificata con cm vcs stage

Dopo aver esaminato il diff unificato e aver confermato che la correzione soddisfa i tuoi standard di qualità e sicurezza, prepara la patch per il commit. Poiché cm vcs stage esegue git add -A, prepara ogni modifica nell'albero di lavoro, incluse le voci .exploit/ e .cm_project non monitorate del passaggio 2. Per prima cosa, aggiungili a .git/info/exclude, un file di esclusione solo locale di cui Git non esegue mai il commit, in modo che venga eseguita la gestione temporanea solo della patch:

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

Quindi, prepara le modifiche utilizzando cm vcs stage:

cm vcs stage

Output:

📦 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.

Verifica che solo la patch sia in fase di preparazione in Git:

cm vcs status

Output:

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

M  routes/login.ts

Se hai eseguito cm vcs stage prima di aggiornare .git/info/exclude, annulla la gestione temporanea dei file CodeMender con git restore --staged .exploit .cm_project. I file rimangono sul disco, vengono solo rimossi dall'area di gestione temporanea.

Reverting Speculative Changes (cm vcs reset):

Se una correzione generata dall'AI non è in linea con i tuoi pattern architetturali o introduce una logica indesiderata, esegui cm vcs reset per ignorare immediatamente tutte le modifiche allo spazio di lavoro generate durante la sessione e ripristinare lo stato di base pulito del repository (git checkout HEAD -- . && git clean -fd).

Passaggio 4: esegui il commit della patch e cancella gli artefatti di verifica

Esegui il commit della patch temporanea prima di correggere il risultato successivo: ogni esecuzione di cm fix e cm verify inizia con la reimpostazione dell'area di lavoro (git checkout HEAD -- . && git clean -fd), che elimina le modifiche non sottoposte a commit. Quindi elimina la cartella .exploit/ locale in modo che la correzione successiva inizi da un workspace pulito. Poiché .exploit/ ora viene ignorato, git clean -fd non lo rimuove più per te. Una copia permanente degli artefatti rimane in ~/.codemender/artifacts/<session-id>/.

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

Se Git ti chiede la tua identità, esegui git config user.name "Your Name" e git config user.email "[e-mail]" nel repository, quindi esegui di nuovo il commit.

9. Convalida le patch, gestisci le sessioni ed esporta i report (report cm)

⏱️ Durata: 08:00

Dopo aver applicato una correzione di sicurezza generata dall'AI, è essenziale gestire le sessioni attive, ispezionare le statistiche di utilizzo dei token e generare report sulla conformità della sicurezza aziendale utilizzando cm report.

Passaggio 1: gestisci le sessioni stateful (cm session list / resume / cancel)

CodeMender monitora ogni attività di scansione, verifica e correzione come sessione stateful nel suo database SQLite locale (~/.codemender/state.db). Esegui cm session list per ispezionare le sessioni:

cm session list

Output:

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

Gestione delle sessioni e controllabilità aziendale:

• Sessioni multi-worker unificate e **INCOMPLETE** stato: durante l'audit di repository di grandi dimensioni con worker paralleli (--deep-workers 8), CodeMender consolida tutte le attività dei worker simultanei in un'unica sessione principale unificata in cm session list, cm report e cm stats. Se un'analisi --deep o --diff di più file presenta errori parziali dei worker mentre altri file vengono analizzati correttamente, CodeMender registra lo stato della sessione come INCOMPLETE (anziché COMPLETED o FAILED), conservando tutti i risultati parziali rilevati e segnalando chiaramente che alcuni file non sono stati analizzati completamente.

• Resilienza alle interruzioni e zero perdita di token: se una scansione o una correzione di lunga durata viene interrotta da un'interruzione della rete, da limiti di frequenza o dall'interruzione dell'utente (Ctrl+C / SIGINT / cm session cancel), CodeMender invia tutti i turni dello strumento completati e il consumo di token direttamente a ~/.codemender/state.db. Il conteggio dei token nei percorsi di uscita per errori e annullamenti viene mantenuto rigorosamente, garantendo un'accuratezza dell'audit del 100% senza turni omessi. Puoi riprendere immediatamente con cm session resume <session-id> (passando gli stessi flag dell'esecuzione originale, ad esempio --sandbox=false --bypass-warning -y) per continuare dall'ultimo passaggio dello strumento completato senza spendere nuovamente il budget dei token.

• Comandi operativi: elenca le sessioni attive e storiche con cm session list, interrompi i job di computing con cm session cancel <session-id> o reimposta i database locali con cm clean.

Passaggio 2: esegui cm report per verificare i risultati corretti

Esegui cm report -f table per visualizzare gli stati dei risultati aggiornati (nota che i risultati corretti ora mostrano FIXED con ✅ applied nella colonna Fix):

cm report -f table

Output:

┌──────────┬───────────┬──────┬──────────┬──────────────────────────────┬────────────────────────────────────────┐
│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

Passaggio 3: controlla l'utilizzo dei token utilizzando cm stats

Esegui cm stats per esaminare il consumo di token locale nelle modalità di scansione (cm find --quick, cm verify e cm fix):

cm stats

Output:

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

Osservabilità dei token a tre livelli e allineamento con FinOps:

CodeMender offre una visibilità completa sugli aspetti economici del ragionamento dell'AI su tre livelli operativi:

1. Live Rolling Line (--compact): monitoraggio dei token in tempo reale durante l'esecuzione dello strumento senza ingombro del terminale.
2. Riepilogo dell'uscita dal comando: conteggi dei passaggi, tempo di esecuzione trascorso e totali dei token di input/output/ragionamento al completamento del comando.
3. Dashboard unificata per sessioni e chiamate (cm stats): tutta la telemetria dei token è consolidata in un modello di sessione unificato che rispecchia direttamente le fatture di fatturazione Cloud. Oltre ai token non elaborati, l'esportazione di cm stats --json fornisce metriche di chiamata del modello (invocations.total, per_session, per_turn), consentendo ai team SecOps e FinOps di monitorare il consumo della quota API, la frequenza dei turni di ragionamento e i tassi di successo della cache (CACHE_HIT%) tra le sessioni in qualsiasi periodo di tempo (--since 168h).

Passaggio 4: genera e visualizza l'anteprima del report HTML interattivo (cm report -f html)

Esporta i risultati della scansione e le patch applicate come dashboard HTML autonoma e interattiva:

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

Per visualizzare report.html in Google Cloud Shell:

Avvia un server web di anteprima locale nel terminale Cloud Shell:

python3 -m http.server 8080

Nella barra degli strumenti in alto a destra di Cloud Shell, fai clic sul pulsante Anteprima web (icona con occhio/schermo) ➔ Anteprima sulla porta 8080 per visualizzare la dashboard di conformità interattiva nel browser.

(In alternativa) In Esplora file dell'editor di Cloud Shell, fai clic con il tasto destro del mouse su report.html e poi su Scarica per visualizzare il file nel browser locale.

Passaggio 5: funzionalità principali del report HTML interattivo generato

Di seguito è riportata una suddivisione dei componenti chiave del report HTML interattivo generato (report.html):

1. Intestazione delle metriche per i dirigenti e schede sulla postura

Metadati dell'intestazione: mostra i dettagli del repository di destinazione (OWASP Juice Shop), il numero totale di file di origine scansionati (684 files) e il timestamp di generazione UTC.

Griglia delle schede delle metriche: fornisce una panoramica istantanea di alto livello dei risultati totali, delle distribuzioni della gravità (CRITICAL, HIGH, MEDIUM, LOW) e delle vulnerabilità totali corrette (FIXED).

2. Tabella di riepilogo dei risultati interattivi

Matrice delle vulnerabilità: mostra una tabella filtrabile contenente ID, Severity, Status (OPEN rispetto a FIXED), CWE Type, File Location, Vulnerability Title e Confidence Score.

3. Analisi approfondita delle cause principali e snippet di codice sorgente vulnerabile

Analisi comprimibile (RCA): se fai clic su una riga dei risultati, viene espansa l'analisi dettagliata delle cause principali sintetizzata dal modello di ragionamento di sicurezza di Gemini.

Snippet di codice sorgente vulnerabile: mostra i numeri di riga esatti e il codice sorgente con evidenziazione della sintassi intorno al sink vulnerabile.

4. Diff di patch di correzione AI sintetizzate

Unified Diff View: per le vulnerabilità corrette (FIXED), CodeMender esegue il rendering di un blocco diff unificato che evidenzia le aggiunte di codice dell'applicazione applicate in verde (+) e il codice vulnerabile rimosso in rosso (-).

Passaggio 6: (facoltativo) Importa i risultati SAST di terze parti (cm report import)

CodeMender non si limita ai difetti rilevati dal proprio scanner. I team possono importare risultati SAST esterni (ad esempio da Semgrep, Snyk, SonarQube o Fortify) utilizzando uno schema JSON standardizzato o una procedura guidata interattiva, consentendo a CodeMender di verificare e sintetizzare immediatamente le correzioni:

# 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

Output:

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

10. Esegui la pulizia delle risorse

⏱️ Durata: 01:00

Per evitare un utilizzo non necessario del disco nel tuo ambiente Google Cloud Shell e ripulire le risorse temporanee del workshop, segui questi passaggi di pulizia.

Passaggio 1: svuota la cache locale di CodeMender e rimuovi il repository

CodeMender fornisce un comando cm clean integrato per eliminare il database dei risultati locali (~/.codemender/state.db), i report HTML e i file di backup di origine. Esegui questi comandi in Cloud Shell:

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

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

(Facoltativo) Passaggio 2: disattiva le API Google Cloud

Se non prevedi di utilizzare le API CodeMender o Agent Platform in questo progetto per un ulteriore sviluppo, puoi disabilitare le API di servizio:

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

Nota: la disattivazione delle API interromperà tutte le sessioni o le integrazioni attive associate ai servizi della piattaforma degli agenti nel tuo progetto.

11. Complimenti

⏱️ Durata: 02:00

Complimenti! Hai trasformato con successo OWASP Juice Shop da un'applicazione intenzionalmente vulnerabile in un codebase sicuro e protetto utilizzando CodeMender sulla piattaforma Gemini Enterprise Agent Platform di Google Cloud.

Argomenti trattati

Correzione autonoma a ciclo chiuso: CodeMender va oltre il rumore degli avvisi statici passivi eseguendo un ciclo di vita della sicurezza completo e autonomo, dal rilevamento del repository (cm find) alla verifica degli exploit in sandbox (cm verify) e alla sintesi delle patch testate per la regressione (cm fix).

Prove di exploit basate su evidenze: acquisendo artefatti di verifica tangibili (PLAN.md, LOG.md, exploit.sh, REPORT.md), CodeMender elimina i falsi positivi e dimostra la possibilità di exploit nel mondo reale prima di scrivere qualsiasi codice.

Correzioni idiomatiche sensibili al contesto: anziché applicare sostituzioni di testo generiche, gli agenti di reasoning di Gemini analizzano l'architettura delle applicazioni, i modelli di dati e gli ORM per produrre patch pulite e gestibili (come le query Sequelize parametrizzate) che preservano la logica di business esistente.

Misure di sicurezza e test integrate: ogni correzione proposta viene convalidata automaticamente rispetto alle suite di test del progetto (npm test) e ai controlli dei tipi (tsc) all'interno di sandbox di workspace isolate prima che le modifiche vengano messe in gestione temporanea.

Cambiamento di mentalità degli sviluppatori

Flusso di lavoro SAST manuale tradizionale	Autonomous Remediation with CodeMender (cm)
Affaticamento da avvisi: ore spese a valutare report rumorosi con alti tassi di falsi positivi.	Agentic Code Discovery (cm find .): scansione approfondita e sensibile al contesto dei repository basata sui modelli Gemini.
Verifica manuale del PoC: creazione di payload curl personalizzati e script di attacco per confermare le vulnerabilità.	Automated Exploit Proofs (cm verify ): sintesi automatica di piani di convalida eseguibili, log e script shell.
Rifattorizzazione manuale ad alto rischio: applicazione manuale di patch a query di database complesse, che spesso introduce errori di sintassi o di runtime.	Sintesi di patch idiomatica (cm fix ): generazione di diff sensibili al contesto, personalizzate in base agli ORM e agli standard dei framework esistenti.
Rischi di regressione in produzione: le patch di sicurezza spesso interrompono la logica di business o i test downstream.	Automated Test Guardrails: convalida continua rispetto a suite di test locali e sandbox di processi isolati.
Compilazioni manuali della conformità: aggregazione manuale dei risultati in documenti statici per le revisioni di audit.	Telemetria standardizzata e SARIF (cm report -f sarif): esportazione istantanea di OASIS SARIF v2.1.0, dashboard HTML e analisi dei token.

Passaggi successivi

🚀 Continua la trilogia di CodeMender:

Parte 2: Proteggi la tua pipeline CI/CD con CodeMender - Automatizza la scansione headless continua, l'integrazione della dashboard SARIF e le richieste di pull con correzione automatica in GitHub Actions.

Parte 3: Vibe-coding sicuro con Antigravity e CodeMender - Abbina lo sviluppo di AI generativa con un assistente di sicurezza autonomo.

📖 Esplora la documentazione:

Documentazione di CodeMender su Google Cloud

Soluzioni di sicurezza di Google Cloud

💡 Applica ai tuoi progetti:

Esegui cm find . e cm fix sui tuoi repository Node.js, Python, Go, Java, Rust o C/C++.