ndaal SBOM Auditor

A single-binary, offline web application to investigate SBOM (Software Bill of Materials) files. Upload an SBOM or import a folder of them, analyse each with an ensemble of independent tools, review the normalised findings in one local UI, and export the result in eight formats. No installation, no network access, no telemetry.

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

What it does

1. Ingest — upload an SBOM in the browser, or import every SBOM in a configurable folder. CycloneDX (JSON/XML), SPDX (JSON/tag-value and 3.0 JSON-LD) and syft-json are detected; files are content-hashed and deduplicated.
2. Analyse — run the enabled tools against the SBOM, each as an isolated subprocess under a deadline and a concurrency limit. A missing tool is a visibly distinct skip; an installed tool that cannot start or does not answer within 15 seconds is a failure that names the reason. Neither is ever reported as a clean result.
3. Findings — each tool's output is normalised to a common shape, with the CVE alias resolved from the tool's GHSA/OSV identifier, and shown per tool with severity badges.
4. Score — grade the SBOM against all seventeen CISA 2026 minimum elements, distinguishing a supplier's explicit NOASSERTION from a field that is simply absent.
5. Search — find which of your SBOMs declare a given component, across the whole corpus, by name or package URL.
6. Export — write the analysis as SARIF 2.1, SARIF 2.2, Markdown, ODT, DOCX, PDF and CSAF 2.1 / 2.2 advisories. Export persists the selected formats to the server export directory, each accompanied by five cryptographic hash sidecars; Start download renders the same formats in memory and streams them to the browser — one document, or a ZIP bundle for several — writing nothing to disk.

Stored SBOMs dashboard

The home page (/) lists every stored SBOM and stays usable as the corpus grows:

• Paged — 25 rows per page, with a "Showing X–Y of N" caption and Previous / Page / Next controls.
• Sortable columns — click the Name, Format or Components header to sort by it; click the header again to reverse the direction.
• Newest upload first — the list opens with the most recently uploaded SBOM, its time in the Last uploaded column. Uploading an SBOM that is already stored moves it back to the top; its detail page keeps the original Ingested time next to Last uploaded.
• Format filter — narrow the list to one format (CycloneDX JSON/XML, SPDX JSON, SPDX 3.0 JSON, SPDX tag-value, Syft JSON or Unknown); a Reset button clears the filters while keeping the current sort.
• Severity column — a rightmost column, after Last uploaded, shows each SBOM's single highest finding severity (Critical, High, Medium, Low or Negligible), or "—" when it has no findings yet, with a matching severity filter.
• Full-text search — a search box, backed by a tantivy full-text index, matches an SBOM's name, format and spec version as well as the names and package URLs of the components it contains, so a query such as log4j or openssl finds every SBOM that ships that component. The query is length-capped and parsed leniently.

Component search

/components answers the inverse question — which of my SBOMs declare this component — across the whole corpus at once, by component name or exact package URL. It reads a dedicated component index built at ingest, separate from the dashboard's full-text index.

Because a stale index would make a genuinely affected SBOM read as "not affected", the page states how many SBOMs are not yet indexed and offers Rebuild index, which re-parses the retained bytes for exactly those. A search is only complete once that warning is gone.

"Indexed" means the index was built, which is not the same as "produced rows": a metadata-only SBOM declares no components, so it contributes none and is still fully indexed. The store records the fact of indexing per SBOM (schema v8, components_indexed_at) rather than inferring it from row existence — inferring it meant a component-free SBOM could never leave the "not yet indexed" set, so the warning survived every rebuild and the button reported the same SBOMs as freshly indexed forever. Upgrading migrates automatically and backfills anything that already had rows; one rebuild settles the remainder.

Analyzer ensemble

Each tool is optional at runtime and detected on PATH (override the binary with SBA_TOOL_<NAME>_BIN). Findings never depend on any single tool. Before each scan the tool is started once with its version argument: no binary means skip (not found on PATH), while a binary that cannot be started, or that gives no answer within 15 seconds, means fail with that reason.

Tool	Role	Verified against
syft	SBOM normaliser / CycloneDX 1.6 converter	1.52.0
grype	CVE matcher	0.119.0
trivy	Vulnerability scanner	0.74.0
osv-scanner	OSV database lookups	2.4.0, 2.6.0
bomber	Independent ensemble matcher	0.5.1
bomdrift	Supply-chain drift / typosquat (SARIF)	0.9.9
inspektr	SBOM vulnerability scanner (JSON)	0.1.9
shieldbom	Offline embedded/IoT CVE scanner (SARIF)	0.3.0
provenant	Licence / copyright / provenance (ScanCode)	1.0.10

"Verified against" is the version each invocation was actually exercised with, not a floor and not a pin: tools are resolved on PATH at runtime and any compatible version works. osv-scanner lists two because 2.6.0 was re-verified after the 2.x line changed its logging — the documented scan --lockfile <input> --format json form is unchanged and still exits non-zero on findings, so no code change was needed.

The first eight tools contribute CVE-shaped vulnerability findings; provenant is different — it reports licence, copyright, holder and author provenance, which the auditor stores and displays as its own finding shape (a "Licence & provenance" section per run, included in the Markdown export) rather than discarding it.

The scanners cannot read every format directly: bomber consumes only CycloneDX ≤ 1.6, and none of the scanners read SPDX 3.0 JSON-LD. In both cases the auditor normalises the input to CycloneDX via syft convert first, and skips with a documented reason when syft is unavailable rather than let a tool report zero packages. grype's vulnerability database is refreshed once per run (out of band) so a routine staleness is a fresh scan, not a failed one.

Vulnerability enrichment

After analysis, each CVE-shaped finding is enriched with three real signals pulled from a vulnlookup service (default https://vulnlookup.ndaal.eu):

• EPSS — the exploitation-probability score and its percentile.
• CISA-KEV — a flag marking the CVE as known-exploited.
• nuclei — whether a public exploit template exists, and its severity.