Guida alla versione preliminare · 0.1.0
Esecuzione e preparazione degli scanner
Segui strumenti fissati, copertura dei sorgenti e generazioni di dati validate fino ai rilievi normalizzati.
Il riferimento API è in inglese.
Una scansione combina vista autorizzata dei sorgenti, strumenti abilitati, dati validati e copertura esplicita. Il catalogo è curato nel codice. Non scopre eseguibili arbitrari, scarica database mancanti durante l’analisi o promette l’ultima versione upstream.
Ammetti la copertura richiesta prima di iniziare
L’API verifica la revisione corrente del preflight alla creazione. Se uno strumento abilitato è bloccato, rifiuta la scansione completa prima di creare scansione o job. Una scansione limitata confermata esplicitamente richiede almeno uno strumento abilitato pronto. Registra omissioni e motivi, resta parziale e non può superare il gate.
Le scansioni predefinite non usano IA. Un passaggio Advisor richiesto per l’intera scansione usa il percorso locale autorizzato separatamente; non cambia ciò che gli scanner hanno verificato. Consulta Advisor.
incremental_diff esegue attualmente tutti gli scanner abilitati sull’intera vista. Il riepilogo registra effective_mode=full, nessun conteggio di file cambiati e incremental-diff-fallback-full. Non dichiara risultati incrementali da strumenti senza un contratto completo condiviso sui file cambiati. Ammissione e esecuzione di ripiego definiscono le decisioni.
Segui il percorso di esecuzione nativa
- Scegli e autorizza i sorgenti
Mantieni esplicito l’ambito di repository, file o cartella. POSIX e Remote WSL usano mount ristretti in sola lettura; i percorsi Windows nativi supportati usano snapshot sigillati limitati.
- Esamina il preflight
Leggi disponibilità, validità e ambito prima di ammettere lavoro.
- Ammetti un comando di scansione
L’API verifica autorità e semantica e conserva identità di comando e job.
- Analizza i sorgenti ammessi
Il worker invoca lo scanner con dati offline validati. incremental_diff ricorre attualmente all’intera vista dei sorgenti.
- Raccogli risultati limitati
Gli adapter normalizzano e oscurano pattern sensibili noti. Il worker valida le pagine prima di conservare i rilievi.
- Leggi copertura e poi il gate
Solo evidenze complete applicabili raggiungono la policy. Una scansione completata può fallire se restano rilievi bloccanti.
Gli strumenti girano in sequenza in gruppi di processi propri con limiti finiti. Syft precede Grype; Grype legge lo SBOM sanitizzato della stessa scansione. Abilitare Grype senza Syft produce evidenza incompleta.
Ogni adapter fornisce configurazione propria, ambiente ristretto e percorsi temporanei privati quando necessari. L’output nativo interpretato viene verificato prima della normalizzazione. Output richiesto mancante, record malformati, posizioni invalide o errori non diventano silenziosamente una scansione pulita. L’adapter rimuove i report grezzi dopo l’elaborazione; SARIF, JSONV2, JSONL e stderr grezzi non sono artefatti scaricabili.
La matrice descrive il contratto fissato. I frammenti di comando spiegano l’adapter; non sono comandi autonomi che riproducono autorità, verifica dati e controlli di risorse di CodeSecurity.
| Strumento e sorgenti | Versione | Esecuzione e input effettivi | Output nativo e preparazione |
|---|---|---|---|
| Trivy | 0.73.0 |
fs cerca vulnerabilità, segreti e configurazioni errate. Un secondo passaggio rootfs solo librerie copre dipendenze impacchettate, inclusi archivi Java. Configurazione e file di esclusione propri; aggiornamenti, telemetria e controlli versione disabilitati. |
SARIF di entrambi i passaggi; database Trivy e Java e controlli validati. |
| Gitleaks | 8.30.1 |
dir analizza sorgenti acquisiti con configurazione propria delle regole predefinite. Ignora soppressioni gitleaks:allow; .gitleaksignore nella radice causa rifiuto. |
SARIF; binario fissato e regole native. È scansione di directory, non modalità di cronologia Git di Gitleaks. |
| OpenGrep | 1.27.0 |
scan usa l’ingresso rules.yml verificato e validato. Core nativo nell’immagine; controlli versione e metriche disabilitati. |
SARIF; richiede una generazione verificata di regole esaminate. |
| Bearer | 2.1.0+lomo.1 |
scan usa configurazione propria e directory esterna di regole verificate, senza regole predefinite o controllo versione. Telemetria disabilitata. |
JSONV2; regole Bearer verificate e identità build del binario modificato. Gli errori rendono incompleta l’evidenza. |
| Grype | 0.117.0 |
sbom: legge l’output Syft sanitizzato della scansione. Non riacquisisce autonomamente il repository. Aggiornamenti automatici di applicazione e database disabilitati. |
SARIF; database Grype verificato e dipendenza Syft della stessa scansione. |
| Checkov | 3.3.10 |
Scansione directory con Kubernetes, Dockerfile e Terraform, configurazione propria, download disabilitati e segnalazione soft-fail. .checkov.yaml o .checkov.yml nella radice causano rifiuto. |
SARIF; input immagine fissati. L’argomento directory unito evita la scoperta della configurazione target della versione fissata. |
| TruffleHog | 3.96.0 |
filesystem usa --no-update --no-verification. Le credenziali rilevate non sono provate contro provider esterni. |
JSONL; binario fissato e detector nativi. |
| Syft | 1.51.0 |
dir: cataloga i sorgenti acquisiti; controllo aggiornamenti disabilitato. |
CycloneDX JSON sanitizzato prima dell’uso in Grype e della pubblicazione come SBOM ammesso. |
Registro, rami effettivi degli adapter e lock contengono argomenti e identità completi. secrets-lite, sast-lite e iac-lite facoltativi partono disabilitati e hanno copertura esplicitamente limitata.
Considera i limiti di sorgenti e parser
L’acquisizione ammette 5.000 file, 8 MiB per file regolare e 64 MiB totali. Il testo idoneo ha un limite d’analisi separato di 1 MiB. Acquisire un file grande non lo rende interamente analizzato.
La ricevuta di copertura registra file idonei e omissioni: conteggio eccessivo, dimensioni, binari, UTF-8 invalido, file illeggibili e tipi non supportati. L’elaborazione dei report nativi ammette 64 MiB d’input. Stdout e stderr condividono spazio temporaneo limitato del container ma non hanno ancora limiti individuali di streaming.
I rilievi normalizzati portano scanner, regola, gravità, posizione, messaggio, snippet, fingerprint e metadati limitati. Duplicati esatti possono essere accorpati; due rilievi canonici diversi con lo stesso fingerprint sono rifiutati. L’ordine è deterministico prima del trasporto. Il riepilogo conserva errori, copertura, modalità richiesta ed effettiva e identità dei dati.
Evidenza completa significa che input idonei e report nativi supportati sono stati elaborati senza omissioni segnalate. Non copre necessariamente ogni costrutto, dipendenza o debolezza e non prova la sfruttabilità di un’API rischiosa. Senza rilievi può esserci copertura parziale; con copertura completa può fallire la policy. Copertura e canonicalizzazione alimentano il confine di pubblicazione.
Prepara i dati fuori dall’esecuzione sui sorgenti
- Leggi disponibilità e validità
Osservazione del catalogo, dati installati, salute e scadenza descrivono cose diverse.
- Recupera componenti verificati
L’updater senza accesso ai sorgenti scarica solo componenti selezionati e verificati.
- Prepara e valida
Identità e contenuto vengono verificati prima di selezionare la generazione candidata.
- Seleziona una generazione completa
L’attivazione passa a dati validati. Un’osservazione obsoleta o pubblicazione interrotta richiede riconciliazione.
- Analizza con dati in sola lettura
Gli scanner leggono la generazione attiva. Definizioni incluse scadute richiedono sorgenti verificati aggiornati e preparazione.
L’updater separato ha rete verso fonti verificate e cache scrivibile, senza mount dei sorgenti. Prepara un candidato privato, valida identità fissate e contenuto, sigilla una generazione completa e la seleziona atomicamente. Una directory scaricata parzialmente non è una generazione attiva.
A runtime lo scanner risolve disponibilità e percorsi da una generazione validata. Non deve approvare strumenti contro una revisione del puntatore e leggere dati da un’altra. Verifiche della generazione attiva e precedente sono distinte: una precedente invalida può bloccare il rollback senza invalidare quella attiva verificata.
| Input di disponibilità | Regola di validità della revisione |
|---|---|
| Database Trivy OS e Java | UpdatedAt del pubblicatore; avviso dopo sette giorni e scadenza dopo quattordici. |
| Database Grype | Timestamp intrinseco di build fissato; avviso dopo sette giorni e scadenza dopo quattordici. |
| Controlli Trivy | Timestamp verificato d’acquisizione; avviso dopo sette giorni e scadenza dopo quattordici. |
| Regole OpenGrep e Bearer verificate | Identità immutabile verificata, senza scadenza temporale inventata. |
Ricompilare lock invariati o riscaricare lo stesso database non rinnova il timestamp intrinseco. I dati con avviso restano usabili ma possono omettere vulnerabilità nuove. Dati scaduti richiedono sorgenti e lock verificati aggiornati. Il rollback controlla identità, compatibilità e validità; annullare non ritira una generazione attivata.
Salute, download finito e Ready to Scan sono risultati distinti. Flag offline e topologia definiti nel codice richiedono anche verifica dell’egress effettivo dell’immagine prima di affermare proprietà di una build. Consulta attivazione, verifica runtime e preparazione dell’operatore.
Conserva le licenze upstream con gli strumenti
La tabella registra gli identificatori del lock verificato e collega testi upstream fissati. È un inventario dei sorgenti, non una revisione completa di ridistribuzione o licenze delle dipendenze.
| Strumento | Licenza registrata e testo upstream |
|---|---|
| Trivy | Apache-2.0 |
| Gitleaks | MIT |
| OpenGrep | LGPL-2.1-or-later nel lock |
| Bearer | Elastic-2.0 |
| Grype | Apache-2.0 |
| Checkov | Apache-2.0 |
| TruffleHog | AGPL-3.0-or-later |
| Syft | Apache-2.0 |
La licenza Apache-2.0 di Lomo non sostituisce quei termini. L’indice licenze conserva una distinzione irrisolta tra espressione del lock OpenGrep e COPYRIGHT. Bearer include un avviso di modifica e ricetta e patch sorgente; non è intercambiabile con un binario upstream invariato. Esamina avvisi, modifiche, dipendenze integrate, regole e dati per la distribuzione prevista.