Guida alla versione preliminare · 0.1.0

Autorizzare i sorgenti e inviare una scansione

Seleziona i sorgenti esatti, prepara gli scanner abilitati e distingui un risultato completo da una copertura limitata.

Il riferimento API è in inglese.

Assegna a ogni sorgente un confine chiaro

Parti dalla directory da esaminare. Aggiungerla a VS Code o sceglierla come contesto di repository cambia l’appartenenza all’editor, non l’autorità dello scanner.

In Projects, usa Authorize another source root se è fuori dalle radici configurate in sola lettura. Controlla il percorso esatto, scegli Copy host command ed eseguilo dalla copia dei sorgenti del backend. L’helper dell’host, riservato al proprietario, applica il confine ristretto conservando radici e dati esistenti. L’API non ha un socket Docker.

Dopo l’applicazione sull’host, registra la directory con Add Project. Non autorizzare /, una raccolta di home o un ampio genitore comune per raggiungere repository indipendenti. Una scelta fuori radice è rifiutata prima di creare progetto o scansione.

POSIX e Remote WSL usano mount autorizzati in sola lettura. I percorsi Windows nativi supportati usano snapshot sigillati e limitati. L’architettura delle scansioni spiega i due trasporti e i controlli condivisi d’identità.

Leggi Scan setup prima dell’invio

Seleziona il progetto e controlla Scan setup. I tre controlli riguardano servizi principali, accesso ai sorgenti e dati degli scanner. Ogni prerequisito mancante ha un recupero corrispondente. Il modulo normale diventa disponibile quando sono pronti.

Una risposta di salute riuscita stabilisce la vitalità. Non dimostra che i sorgenti siano montati, che tutti gli strumenti siano pronti o che una scansione abbia copertura completa.

Prepara gli scanner abilitati

Apri una volta Tools > Prepare all scanners. Il flusso verifica il catalogo, scarica database o regole tramite l’updater separato privo di accesso ai sorgenti e verifica gli input scelti. La preparazione non legge il codice del progetto.

Controlli di preparazione con verifiche dei dati e disponibilità runtime.

Prepare scanners verifica i dati esaminati prima di avviare una scansione completa.

Apri l’immagine completa

Gli strumenti esterni coprono attività complementari:

Strumenti Ruolo principale
Trivy, Gitleaks e TruffleHog Rilevamento di segreti; Trivy controlla anche vulnerabilità e configurazione. La verifica di rete di TruffleHog è disabilitata.
OpenGrep e Bearer Regole statiche di sicurezza applicativa e privacy.
Checkov Controlli di configurazione dell’infrastruttura.
Syft e Grype Inventario software seguito da analisi delle vulnerabilità delle dipendenze.

Grype dipende dall’inventario sanitizzato di Syft della stessa scansione. Gli strumenti euristici interni di ripiego sono etichettati separatamente e non sostituiscono la copertura esterna.

Segui la preparazione in Jobs. Fase, componente, ultima attività e byte descrivono lavoro osservato. Un indicatore indeterminato non implica una percentuale nascosta o una stima di completamento.

Database verificati mutabili e controlli scaricati avvisano dopo sette giorni e scadono dopo quattordici dai timestamp definiti dalla fonte. Gli alberi immutabili delle regole seguono l’identità del lock. Riscaricare lo stesso database scaduto non ne rinnova l’età intrinseca. Se Tools richiede un aggiornamento dei sorgenti, ottieni sorgenti verificati più recenti, conserva l’installazione e riprepara. Non modificare timestamp o disabilitare controlli di validità.

Scegli copertura completa o limitata

Complete coverage è la scelta normale. Se uno scanner abilitato non è pronto, l’ammissione fallisce prima di creare scansione o job.

Limited coverage è un ripiego esplicito quando almeno uno può funzionare. Esamina sottoinsieme pronto, strumenti omessi e motivi, poi conferma quel preflight esatto. Il risultato resta parziale e il gate incompleto. Modifiche successive al ciclo di vita non colmano le omissioni.

Uno scanner deve produrre output nativo valido anche senza rilievi. Output mancante, malformato o non affidabile non diventa una scansione pulita. Esamina avvisi e omissioni oltre al numero di rilievi.

Scegli l’ambito previsto

Usa i controlli di scansione del progetto per sorgenti registrati. In VS Code:

  • Scan Workspace with Lomo CodeSecurity risolve un contesto di repository aperto.
  • Scan Workspace Folders… permette di scegliere radici, esaminare percorsi esatti e confermare un lotto.
  • Il pulsante workspace in Explorer analizza la radice risolta o apre il selettore multiradice.
  • Il clic destro su una cartella o un file supportato ne sceglie l’ambito esatto.
  • Rescan Exact Finding File conferma e analizza solo il file del rilievo.

Salva prima le modifiche. Gli scanner leggono disco o snapshot ammessi, non buffer non salvati dell’editor. Un risultato di file o cartella ha quell’ambito, non l’intero repository. L’albero Findings etichetta questi risultati e offre Open scan history per quelli precedenti.

La richiesta incremental_diff esegue attualmente l’intera vista dei sorgenti. Registra effective_mode=full e incremental-diff-fallback-full. Non esegue gli scanner solo sui file cambiati.

Analizza più repository senza unire i risultati

Per repository sotto un genitore aperto, usa prima Choose repositories in this workspace…. La scoperta è limitata ai figli immediati; una ricerca esplicita può scegliere un repository più profondo. Il genitore resta aperto e ogni figlio conserva un’identità distinta.

Scan Workspace Folders… mostra l’autorizzazione, permette di omettere radici e chiede conferma finale. Ogni radice ammessa ha progetto, scansione e job propri. Non esiste un gate superato complessivo del lotto.

Cancel ferma il lavoro corrente annullabile e lascia non avviate le radici successive. Se l’osservazione di un job ammesso diventa incerta, il risultato indica quel job esatto e non vengono inviate altre radici. Leggi ogni esito anziché trattare la notifica come un singolo successo.

Interpreta il risultato finale

Apri la scansione esatta quando il job termina. Controlla ambito, stato, copertura, avvisi, scanner omessi e gate prima dei rilievi.

  • Una scansione completata può fallire il gate perché restano evidenze bloccanti.
  • Una scansione parziale conserva rilievi utili ma non ha evidenza completa.
  • Lavoro fallito o annullato può conservare rilievi persistiti in sicurezza e artefatti pubblicabili.
  • Zero rilievi da solo non stabilisce nessuno di questi stati.

Trasferimento e analisi hanno limiti distinti. Uno snapshot permette 5.000 file regolari, 8 MiB per file trasferito e 64 MiB decodificati totali, con 112 MiB separati per la richiesta codificata. L’analisi del codice idoneo ha un limite di 1 MiB per file. Acquisire un file maggiore non prova che sia stato analizzato interamente. Percorsi insicuri, link non supportati e identità cambiate sono rifiutati.

Continua con la revisione dei rilievi e l’interpretazione del gate. I client API devono conservare identità esatte di job e comando all’invio; consulta scansioni, autorizzazione dei sorgenti e job.