ndaal SBOM Auditor

Una aplicación web offline de binario único para investigar archivos SBOM (Software Bill of Materials). Suba un SBOM o importe una carpeta de ellos, analice cada uno con un conjunto de herramientas independientes, revise los hallazgos normalizados en una única interfaz local y exporte el resultado en ocho formatos. Sin instalación, sin acceso a la red, sin telemetría.

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

Qué hace

1. Ingesta — suba un SBOM en el navegador, o importe todos los SBOM de una carpeta configurable. Se detectan CycloneDX (JSON/XML), SPDX (JSON/tag-value y 3.0 JSON-LD) y syft-json; los archivos se someten a hash de contenido y se deduplican.
2. Análisis — ejecute las herramientas habilitadas contra el SBOM, cada una como un subproceso aislado bajo un plazo límite y un límite de concurrencia. Una herramienta ausente es una omisión visiblemente distinta; una herramienta instalada que no puede iniciarse o no responde en 15 segundos es un fallo que indica el motivo. Ninguno de los dos se reporta jamás como un resultado limpio.
3. Hallazgos — la salida de cada herramienta se normaliza a una forma común, con el alias CVE resuelto a partir del identificador GHSA/OSV de la herramienta, y se muestra por herramienta con insignias de severidad.
4. Puntuación — califique el SBOM según los diecisiete elementos mínimos de CISA 2026, distinguiendo un NOASSERTION explícito de un proveedor de un campo que simplemente está ausente.
5. Búsqueda — encuentre cuáles de sus SBOM declaran un componente dado, en todo el corpus, por nombre o URL de paquete.
6. Exportación — escriba el análisis como SARIF 2.1, SARIF 2.2, Markdown, ODT, DOCX, PDF y avisos CSAF 2.1 / 2.2. Export persiste los formatos seleccionados en el directorio de exportación del servidor, cada uno acompañado de cinco archivos auxiliares de hash criptográfico; Start download renderiza los mismos formatos en memoria y los transmite al navegador — un documento, o un paquete ZIP para varios — sin escribir nada en disco.

Panel de SBOM almacenados

La página de inicio (/) lista cada SBOM almacenado y sigue siendo utilizable a medida que el corpus crece:

• Paginado — 25 filas por página, con un rótulo "Showing X–Y of N" y controles Previous / Page / Next.
• Columnas ordenables — haga clic en el encabezado Name, Format o Components para ordenar por él; haga clic de nuevo en el encabezado para invertir la dirección.
• Subida más reciente primero — la lista se abre con el SBOM subido más recientemente, su hora en la columna Last uploaded. Subir un SBOM que ya está almacenado lo devuelve al principio; su página de detalle conserva la hora original de Ingested junto a Last uploaded.
• Filtro de formato — restrinja la lista a un formato (CycloneDX JSON/XML, SPDX JSON, SPDX 3.0 JSON, SPDX tag-value, Syft JSON o Unknown); un botón Reset borra los filtros mientras mantiene el orden actual.
• Columna de severidad — una columna situada más a la derecha, después de Last uploaded, muestra la única severidad de hallazgo más alta de cada SBOM (Critical, High, Medium, Low o Negligible), o "—" cuando aún no tiene hallazgos, con un filtro de severidad correspondiente.
• Búsqueda de texto completo — un cuadro de búsqueda, respaldado por un índice de texto completo tantivy, coincide con el nombre, el formato y la versión de especificación de un SBOM, así como con los nombres y las URL de paquete de los componentes que contiene, de modo que una consulta como log4j o openssl encuentra cada SBOM que incluye ese componente. La consulta tiene un límite de longitud y se analiza de forma indulgente.

Búsqueda de componentes

/components responde a la pregunta inversa — cuáles de mis SBOM declaran este componente — en todo el corpus a la vez, por nombre de componente o URL de paquete exacta. Lee un índice de componentes dedicado construido en la ingesta, separado del índice de texto completo del panel.

Dado que un índice obsoleto haría que un SBOM genuinamente afectado se leyera como "no afectado", la página indica cuántos SBOM aún no están indexados y ofrece Rebuild index, que vuelve a analizar los bytes retenidos para exactamente esos. Una búsqueda solo está completa una vez que esa advertencia desaparece.

"Indexado" significa que el índice fue construido, lo cual no es lo mismo que "produjo filas": un SBOM de solo metadatos no declara componentes, por lo que no contribuye con ninguno y aun así está completamente indexado. El almacén registra el hecho de la indexación por SBOM (schema v8, components_indexed_at) en lugar de inferirlo de la existencia de filas — inferirlo significaba que un SBOM sin componentes nunca podía salir del conjunto "aún no indexado", por lo que la advertencia sobrevivía a cada reconstrucción y el botón reportaba los mismos SBOM como recién indexados para siempre. La actualización migra automáticamente y rellena todo lo que ya tenía filas; una reconstrucción resuelve el resto.

Conjunto de analizadores

Cada herramienta es opcional en tiempo de ejecución y se detecta en PATH (anule el binario con SBA_TOOL_<NAME>_BIN). Los hallazgos nunca dependen de una sola herramienta. Antes de cada escaneo, la herramienta se inicia una vez con su argumento de versión: sin binario significa skip (not found on PATH), mientras que un binario que no puede iniciarse, o que no da respuesta en 15 segundos, significa fail con ese motivo.

Herramienta	Rol	Verificada contra
syft	Normalizador de SBOM / conversor a CycloneDX 1.6	1.52.0
grype	Comparador de CVE	0.119.0
trivy	Escáner de vulnerabilidades	0.74.0
osv-scanner	Consultas a la base de datos OSV	2.4.0, 2.6.0
bomber	Comparador de conjunto independiente	0.5.1
bomdrift	Deriva de cadena de suministro / typosquat (SARIF)	0.9.9
inspektr	Escáner de vulnerabilidades de SBOM (JSON)	0.1.9
shieldbom	Escáner de CVE embebido/IoT offline (SARIF)	0.3.0
provenant	Licencia / copyright / procedencia (ScanCode)	1.0.10

"Verificada contra" es la versión con la que se ejercitó realmente cada invocación, no un mínimo ni una fijación: las herramientas se resuelven en PATH en tiempo de ejecución y cualquier versión compatible funciona. osv-scanner lista dos porque 2.6.0 se reverificó después de que la línea 2.x cambiara su registro — la forma documentada scan --lockfile <input> --format json no ha cambiado y sigue saliendo con código distinto de cero ante hallazgos, por lo que no se necesitó ningún cambio de código.