ndaal SBOM Auditor

Un'applicazione web offline a binario singolo per analizzare file SBOM (Software Bill of Materials). Carica un SBOM o importa una cartella che li contiene, analizza ciascuno con un insieme di strumenti indipendenti, esamina i risultati normalizzati in un'unica interfaccia locale ed esporta il risultato in otto formati. Nessuna installazione, nessun accesso alla rete, nessuna telemetria.

English · Deutsch · Français · Español · Italiano

Cosa fa

1. Acquisizione — carica un SBOM nel browser, oppure importa ogni SBOM in una cartella configurabile. Vengono rilevati CycloneDX (JSON/XML), SPDX (JSON/tag-value e 3.0 JSON-LD) e syft-json; i file vengono sottoposti a hash del contenuto e deduplicati.
2. Analisi — esegue gli strumenti abilitati sull'SBOM, ciascuno come sottoprocesso isolato entro una scadenza e un limite di concorrenza. Uno strumento mancante è un skip visibilmente distinto; uno strumento installato che non può avviarsi o non risponde entro 15 secondi è un failure che ne indica il motivo. Nessuno dei due viene mai riportato come risultato pulito.
3. Risultati — l'output di ciascuno strumento viene normalizzato in una forma comune, con l'alias CVE risolto dall'identificatore GHSA/OSV dello strumento, e mostrato per strumento con badge di gravità.
4. Punteggio — valuta l'SBOM rispetto a tutti e diciassette gli elementi minimi CISA 2026, distinguendo un esplicito NOASSERTION di un fornitore da un campo semplicemente assente.
5. Ricerca — trova quali dei tuoi SBOM dichiarano un dato componente, nell'intero corpus, per nome o package URL.
6. Esportazione — scrive l'analisi come SARIF 2.1, SARIF 2.2, Markdown, ODT, DOCX, PDF e avvisi CSAF 2.1 / 2.2. Export persiste i formati selezionati nella directory di esportazione del server, ciascuno accompagnato da cinque file sidecar di hash crittografici; Start download renderizza gli stessi formati in memoria e li trasmette al browser — un singolo documento, o un bundle ZIP per più documenti — senza scrivere nulla su disco.

Dashboard degli SBOM memorizzati

La pagina iniziale (/) elenca ogni SBOM memorizzato e resta utilizzabile man mano che il corpus cresce:

• Paginata — 25 righe per pagina, con una didascalia "Showing X–Y of N" e i controlli Previous / Page / Next.
• Colonne ordinabili — clicca sull'intestazione Name, Format o Components per ordinare in base a essa; clicca di nuovo sull'intestazione per invertire la direzione.
• Upload più recente per primo — l'elenco si apre con l'SBOM caricato più di recente, con il suo orario nella colonna Last uploaded. Caricare un SBOM già memorizzato lo riporta in cima; la sua pagina di dettaglio conserva l'orario Ingested originale accanto a Last uploaded.
• Filtro formato — restringe l'elenco a un formato (CycloneDX JSON/XML, SPDX JSON, SPDX 3.0 JSON, SPDX tag-value, Syft JSON o Unknown); un pulsante Reset cancella i filtri mantenendo l'ordinamento corrente.
• Colonna Severity — una colonna più a destra, dopo Last uploaded, mostra la singola gravità più alta di ciascun SBOM (Critical, High, Medium, Low o Negligible), oppure "—" quando non ha ancora risultati, con un filtro di gravità corrispondente.
• Ricerca full-text — una casella di ricerca, supportata da un indice full-text tantivy, trova corrispondenze nel nome, formato e versione di specifica di un SBOM nonché nei nomi e nei package URL dei componenti che contiene, così una query come log4j o openssl trova ogni SBOM che include quel componente. La query è limitata in lunghezza e analizzata in modo indulgente.

Ricerca componenti

/components risponde alla domanda inversa — quali dei miei SBOM dichiarano questo componente — nell'intero corpus in una sola volta, per nome del componente o package URL esatto. Legge un indice dedicato dei componenti costruito all'acquisizione, separato dall'indice full-text della dashboard.

Poiché un indice obsoleto farebbe leggere un SBOM realmente interessato come "non interessato", la pagina indica quanti SBOM non sono ancora indicizzati e offre Rebuild index, che ri-analizza i byte conservati esattamente per quelli. Una ricerca è completa solo quando quell'avviso è scomparso.

"Indicizzato" significa che l'indice è stato costruito, il che non è la stessa cosa di "ha prodotto righe": un SBOM di soli metadati non dichiara componenti, quindi non ne contribuisce nessuno ed è comunque completamente indicizzato. L'archivio registra il fatto dell'indicizzazione per SBOM (schema v8, components_indexed_at) invece di dedurlo dall'esistenza delle righe — dedurlo significava che un SBOM privo di componenti non poteva mai uscire dall'insieme "non ancora indicizzato", così l'avviso sopravviveva a ogni ricostruzione e il pulsante riportava gli stessi SBOM come appena indicizzati per sempre. L'aggiornamento migra automaticamente e riempie retroattivamente tutto ciò che aveva già righe; una ricostruzione sistema il resto.

Insieme di analizzatori

Ogni strumento è opzionale a runtime e rilevato sul PATH (sovrascrivi il binario con SBA_TOOL_<NAME>_BIN). I risultati non dipendono mai da un singolo strumento. Prima di ogni scansione lo strumento viene avviato una volta con il suo argomento di versione: nessun binario significa skip (not found on PATH), mentre un binario che non può essere avviato, o che non dà risposta entro 15 secondi, significa fail con quel motivo.

Strumento	Ruolo	Verificato con
syft	Normalizzatore SBOM / convertitore CycloneDX 1.6	1.52.0
grype	Corrispondenza CVE	0.119.0
trivy	Scanner di vulnerabilità	0.74.0
osv-scanner	Ricerche nel database OSV	2.4.0, 2.6.0
bomber	Corrispondenza indipendente dell'insieme	0.5.1
bomdrift	Drift della supply-chain / typosquat (SARIF)	0.9.9
inspektr	Scanner di vulnerabilità SBOM (JSON)	0.1.9
shieldbom	Scanner CVE offline per embedded/IoT (SARIF)	0.3.0
provenant	Licenza / copyright / provenienza (ScanCode)	1.0.10

"Verificato con" è la versione con cui ogni invocazione è stata effettivamente esercitata, non un minimo e non un pin: gli strumenti vengono risolti sul PATH a runtime e qualsiasi versione compatibile funziona. osv-scanner ne elenca due perché la 2.6.0 è stata riverificata dopo che la linea 2.x ha cambiato il suo logging — la forma documentata scan --lockfile <input> --format json è invariata e continua a uscire con codice diverso da zero in presenza di risultati, quindi non è stato necessario alcun cambio di codice.