Modalità di ricerca di CodeMender

CodeMender fornisce tre diverse modalità di scansione tramite il comando cm find. Ogni modalità è progettata per una fase specifica del ciclo di vita dello sviluppo software, bilanciando velocità, ambito e profondità.

Confrontare le modalità di ricerca

La seguente tabella mette a confronto le tre modalità di scansione di cm find:

Modalità Comando Ambito di destinazione Runtime tipico Ideale per
Scansione standard cm find PATH Directory specificata Runtime moderato Scoperta di sviluppatori locali, controlli rapidi, recensioni esplorative
Scansione differenziale cm find PATH --diff[=REF] File modificati più file dipendenti (come chiamanti e chiamati) Runtime veloce Pipeline CI/CD delle richieste di pull (GitHub Actions, Cloud Build), hook pre-commit
Scansione approfondita cm find PATH --deep Intero repository Runtime più lungo Controlli pianificati, idoneità al rilascio, certificazioni di conformità (SOC 2, ISO)

Scansione standard (predefinita)

Una scansione standard è la modalità predefinita quando esegui cm find senza fornire flag di scansione aggiuntivi. Esegue una scansione autonoma di una singola sessione della directory di destinazione specificata. Durante la scansione, CodeMender rileva i file sorgente, assegna loro la priorità in base ai pattern di vulnerabilità, esegue un'analisi di sicurezza iniziale e segnala le potenziali vulnerabilità raggruppate per gravità e tipo.

I seguenti esempi mostrano come eseguire una scansione standard su una directory di destinazione:

# Scan a directory using the default model
cm find ./src

# Scan with a specific Gemini model
cm find ./src --model gemini-3.8-flash

Punti di forza

Una scansione standard funziona senza configurazione e senza flag o parametri aggiuntivi. Bilancia velocità e copertura con un runtime moderato e utilizza un numero minimo di token e risorse di calcolo, il che lo rende conveniente per lo sviluppo quotidiano.

Compromessi e limitazioni

Una scansione standard ha un richiamo inferiore sui codebase di grandi dimensioni e potrebbe non esplorare tutti i file nei repository aziendali di grandi dimensioni e con più pacchetti perché opera in un unico contesto di sessione. Inoltre, si concentra principalmente sui pattern locali all'interno dei singoli file, il che limita l'analisi tra pacchetti e potrebbe non rilevare vulnerabilità che interessano pacchetti distanti.

Quando utilizzarlo

Utilizza una scansione standard nei seguenti scenari:

  • Esegui una scansione sulla tua macchina locale prima di eseguire il commit delle modifiche per ricevere un feedback rapido durante lo sviluppo locale.
  • Ispeziona un repository appena clonato o un piccolo progetto per una valutazione iniziale della sua postura di sicurezza.
  • Ispeziona una sottodirectory o un modulo specifico quando esamini un potenziale problema.

Scansione differenziale

Una scansione diff esegue l'analisi Git diff per i workflow delle richieste di pull e le pipeline CI/CD ispezionando i file modificati e aggiunti e concentrandosi sugli intervalli di righe esatti (diff hunk) che sono stati modificati. Oltre a esaminare le righe modificate, esegue un'analisi dell'impatto per scoprire i file non modificati nel repository che chiamano, importano o dipendono dalle funzioni e dai simboli modificati. In questo modo si garantisce che le modifiche che alterano i contratti o le firme delle funzioni in un file non introducano vulnerabilità nei file dipendenti.

Durante l'analisi, CodeMender isola automaticamente le vulnerabilità preesistenti nel codice non modificato, in modo che i problemi legacy non causino l'esito negativo dell'analisi o blocchino la richiesta di pull. Poi valuta i risultati in base ai criteri --fail-on e genera i risultati in formato tabella, JSON o SARIF v2.1.0.

I seguenti esempi mostrano come eseguire una scansione diff rispetto alle modifiche della copia di lavoro, alle modifiche in staging o a un ramo di destinazione:

# Scan working copy changes versus HEAD
cm find . --diff

# Scan staged changes only (pre-commit)
cm find . --diff --staged

# Scan a pull request branch against the main branch in CI/CD
cm find . --diff=origin/main --format=sarif --output=results.sarif \
    --fail-on=CRITICAL,HIGH

Per le configurazioni della pipeline end-to-end, vedi Integrazione con CI/CD.

Punti di forza

Una scansione differenziale è rapida e deterministica e in genere termina in meno di 2 minuti per mantenere brevi i tempi di esecuzione della pipeline CI/CD. A differenza degli scanner diff che ispezionano solo le righe modificate, --diff ispeziona le relazioni tra chiamante e chiamato per rilevare regressioni della sicurezza e violazioni del contratto tra file. Poiché sopprime i risultati nel codice non modificato, la scansione blocca solo le richieste pull relative a problemi introdotti o interessati dalle modifiche, evitando report rumorosi e build non riuscite non necessarie. Una scansione differenziale genera anche SARIF v2.1.0 per l'integrazione diretta nelle annotazioni di GitHub Code Scanning e nelle dashboard di Cloud Build.

Compromessi e limitazioni

Una scansione differenziale analizza solo il codice all'interno dell'area interessata della richiesta di pull e non trova vulnerabilità preesistenti nelle parti intatte del repository. Richiede anche un repository Git con accesso al riferimento di base di destinazione.

Quando utilizzarlo

Utilizza una scansione differenziale nei seguenti scenari:

  • Esegui controlli automatizzati su ogni richiesta di pull nelle pipeline CI/CD come GitHub Actions, Cloud Build, GitLab CI o Jenkins.
  • Verifica che le modifiche locali siano pulite negli hook pre-commit o pre-push prima di eseguire il push del codice nel repository remoto.
  • Verifica che le unioni tra i rami di rilascio non introducano regressioni.

Scansione approfondita

L'analisi approfondita è una modalità di analisi esaustiva progettata per controlli di sicurezza completi a livello di repository. Esegue l'audit dei file sorgente nell'intero repository contemporaneamente utilizzando worker paralleli (configurati con --deep-workers, che per impostazione predefinita è 8 e supporta un intervallo da 1 a 16). Man mano che rileva i risultati candidati, li convalida e li conferma in base al contesto del codice circostante per filtrare i falsi positivi prima di generare i report sui risultati.

I seguenti esempi mostrano come eseguire una scansione approfondita in un repository:

# Run an exhaustive deep scan across the entire repository
cm find . --deep

# Tune concurrency and use the cyber-specialized security model
cm find . --deep --deep-workers=8 --model=gemini-3.8-flash-cyber

Punti di forza

Una scansione approfondita offre un richiamo elevato e una scoperta completa delle vulnerabilità in grandi codebase aziendali, superando le scansioni a sessione singola e utilizzando la verifica automatizzata per mantenere un'elevata precisione. Supporta più lingue ed è indipendente dalla piattaforma, funzionando in tutte le lingue supportate da Gemini senza richiedere compilatori, configurazioni di build o file di grammatica specifici per la lingua. Ottimizza inoltre l'utilizzo delle risorse concentrando l'analisi sul codice di produzione e riducendo al minimo il consumo di token e di risorse di calcolo sui file non di produzione.

Compromessi e limitazioni

Non utilizzare una scansione approfondita come controllo sincrono che blocca le richieste pull. Le scansioni approfondite eseguono un'analisi completa dell'intero repository. Di conseguenza, richiedono un runtime più lungo e una spesa di token più elevata rispetto alle scansioni standard o differenziali.

Quando utilizzarlo

Utilizza una scansione approfondita nei seguenti scenari:

  • Esegui controlli di sicurezza pianificati con cadenza giornaliera o settimanale in tutti i repository di produzione.
  • Esegui un controllo completo della sicurezza pre-release prima dei rilasci delle versioni principali o dei deployment di produzione.
  • Genera prove di audit per le revisioni di conformità e certificazione SOC 2, ISO 27001, FedRAMP o PCI-DSS.
  • Stabilisci una base di riferimento iniziale per la sicurezza quando esegui l'onboarding di un nuovo codebase in CodeMender.

Scegliere una modalità di ricerca

Utilizza la seguente tabella di riferimento per selezionare la modalità di scansione più adatta al tuo workflow:

Flusso di lavoro o ambiente Caso d'uso e obiettivo Modalità consigliata Comando di esempio
Terminale locale Scoperta rapida o controllo di affidabilità su un modulo specifico Scansione standard cm find ./src
Terminale locale Controllo pre-commit delle modifiche in attesa di commit prima del push Scansione differenziale cm find . --diff --staged
pipeline CI/CD Controllo automatico delle richieste di pull sul codice modificato e sui chiamanti Scansione differenziale cm find . --diff=origin/main --fail-on=CRITICAL,HIGH
Pipeline o controllo pianificato Controlli notturni, porte pre-release, conformità allo standard SOC 2 Scansione approfondita cm find . --deep --deep-workers=8

Riferimento ai flag dei comandi per modalità

Le tabelle seguenti descrivono i flag della riga di comando supportati da ciascuna modalità di scansione.

Flag comuni (tutte le modalità)

I seguenti flag si applicano a tutte le modalità di scansione di cm find:

Flag Predefinito Descrizione
-c, --context TEXT "" Contesto aggiuntivo per guidare l'agente di scansione, ad esempio note sull'architettura.
--model MODEL_NAME gemini-3.8-flash Modello Gemini da utilizzare (gemini-3.8-flash, gemini-3.8-flash-cyber).
-y, --yes false Salta tutte le richieste di conferma interattive.
--unrestricted false Disattiva la sandbox del file system.

Flag di scansione delle differenze

I seguenti flag configurano le scansioni cm find --diff:

Flag Predefinito Descrizione
--diff[=REF] Off Attiva la modalità diff rispetto al riferimento di destinazione, ad esempio origin/main o HEAD~1. Senza REF, il confronto viene effettuato con HEAD. Non può essere utilizzato con --deep.
--staged Off Limita la differenza al solo indice di staging (git diff --cached). Richiede --diff.
--diff-depth DEPTH 1 Profondità di attraversamento per l'analisi d'impatto (da 1 a 3, valore predefinito: 1 hop).
--diff-workers COUNT 4 Numero di worker simultanei per i job di controllo delle richieste di pull (da 1 a 16).
--diff-max-neighbors COUNT 10 Numero massimo di file del chiamante o del chiamato dipendenti da esaminare.
--fail-on SEVERITIES CRITICAL,HIGH Gravità separate da virgole che causano l'uscita di cm find con il codice 1.
--fail-on-truncation Off Esci con il codice 1 se il rilevamento dei vicini supera il limite.
--format FORMAT table Formato di output: table, json o sarif.
--output FILE Output standard Scrivi il report in un file anziché nell'output standard.

Flag di analisi approfondita

I seguenti flag configurano le scansioni cm find --deep:

Flag Predefinito Descrizione
--deep false Abilita l'analisi approfondita esaustiva a livello di repository. Non può essere utilizzato con --diff.
--deep-workers COUNT 8 Numero di worker simultanei per la scansione approfondita (da 1 a 16).