ndaal SBOM Auditor

Une application web hors ligne à binaire unique pour analyser des fichiers SBOM (Software Bill of Materials). Téléversez un SBOM ou importez un dossier de SBOM, analysez chacun avec un ensemble d'outils indépendants, examinez les résultats normalisés dans une interface locale unique et exportez le résultat dans huit formats. Aucune installation, aucun accès réseau, aucune télémétrie.

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

Ce qu'il fait

1. Ingestion — téléversez un SBOM dans le navigateur, ou importez tous les SBOM d'un dossier configurable. Les formats CycloneDX (JSON/XML), SPDX (JSON/tag-value et 3.0 JSON-LD) et syft-json sont détectés ; les fichiers sont hachés par contenu et dédupliqués.
2. Analyse — exécutez les outils activés sur le SBOM, chacun comme un sous-processus isolé soumis à un délai limite et à une limite de concurrence. Un outil manquant est un skip visiblement distinct ; un outil installé qui ne peut pas démarrer ou qui ne répond pas dans les 15 secondes est un échec qui en nomme la raison. Ni l'un ni l'autre n'est jamais rapporté comme un résultat propre.
3. Constats — la sortie de chaque outil est normalisée selon une forme commune, avec l'alias CVE résolu à partir de l'identifiant GHSA/OSV de l'outil, et affichée par outil avec des badges de gravité.
4. Notation — évaluez le SBOM par rapport aux dix-sept éléments minimaux CISA 2026, en distinguant un NOASSERTION explicite d'un fournisseur d'un champ simplement absent.
5. Recherche — trouvez lesquels de vos SBOM déclarent un composant donné, dans l'ensemble du corpus, par nom ou par package URL.
6. Export — écrivez l'analyse au format SARIF 2.1, SARIF 2.2, Markdown, ODT, DOCX, PDF et avis CSAF 2.1 / 2.2. Export conserve les formats sélectionnés dans le répertoire d'export du serveur, chacun accompagné de cinq fichiers de hachage cryptographique annexes ; Start download génère les mêmes formats en mémoire et les diffuse au navigateur — un document, ou une archive ZIP pour plusieurs — sans rien écrire sur le disque.

Tableau de bord des SBOM stockés

La page d'accueil (/) liste tous les SBOM stockés et reste utilisable à mesure que le corpus grandit :

• Paginé — 25 lignes par page, avec une légende « Showing X–Y of N » et des contrôles Previous / Page / Next.
• Colonnes triables — cliquez sur l'en-tête Name, Format ou Components pour trier selon celui-ci ; cliquez à nouveau sur l'en-tête pour inverser le sens.
• Téléversement le plus récent en premier — la liste s'ouvre avec le SBOM téléversé le plus récemment, son horodatage dans la colonne Last uploaded. Téléverser un SBOM déjà stocké le replace en tête ; sa page de détail conserve l'horodatage Ingested d'origine à côté de Last uploaded.
• Filtre de format — restreignez la liste à un format (CycloneDX JSON/XML, SPDX JSON, SPDX 3.0 JSON, SPDX tag-value, Syft JSON ou Unknown) ; un bouton Reset efface les filtres tout en conservant le tri en cours.
• Colonne de gravité — une colonne à l'extrême droite, après Last uploaded, affiche la gravité de constat la plus élevée de chaque SBOM (Critical, High, Medium, Low ou Negligible), ou « — » lorsqu'il n'a pas encore de constat, avec un filtre de gravité correspondant.
• Recherche plein texte — une zone de recherche, adossée à un index plein texte tantivy, correspond au nom, au format et à la version de spécification d'un SBOM ainsi qu'aux noms et package URLs des composants qu'il contient, de sorte qu'une requête telle que log4j ou openssl trouve chaque SBOM qui embarque ce composant. La requête est limitée en longueur et analysée avec indulgence.

Recherche de composants

/components répond à la question inverse — lesquels de mes SBOM déclarent ce composant — sur l'ensemble du corpus en une seule fois, par nom de composant ou package URL exacte. Elle lit un index de composants dédié construit à l'ingestion, distinct de l'index plein texte du tableau de bord.

Comme un index obsolète ferait apparaître un SBOM réellement affecté comme « non affecté », la page indique combien de SBOM ne sont pas encore indexés et propose Rebuild index, qui réanalyse les octets conservés pour exactement ceux-là. Une recherche n'est complète qu'une fois cet avertissement disparu.

« Indexé » signifie que l'index a été construit, ce qui n'est pas la même chose que « a produit des lignes » : un SBOM contenant uniquement des métadonnées ne déclare aucun composant, il n'en contribue donc aucun et reste pleinement indexé. Le stockage enregistre le fait de l'indexation par SBOM (schéma v8, components_indexed_at) plutôt que de l'inférer de l'existence de lignes — l'inférer signifiait qu'un SBOM sans composant ne pouvait jamais quitter l'ensemble « pas encore indexé », si bien que l'avertissement survivait à chaque reconstruction et que le bouton signalait indéfiniment les mêmes SBOM comme fraîchement indexés. La mise à niveau migre automatiquement et complète tout ce qui avait déjà des lignes ; une reconstruction règle le reste.

Ensemble d'analyseurs

Chaque outil est optionnel à l'exécution et détecté sur le PATH (remplacez le binaire avec SBA_TOOL_<NAME>_BIN). Les constats ne dépendent jamais d'un seul outil. Avant chaque analyse, l'outil est démarré une fois avec son argument de version : l'absence de binaire signifie skip (not found on PATH), tandis qu'un binaire qui ne peut pas démarrer, ou qui ne donne aucune réponse dans les 15 secondes, signifie fail avec cette raison.

Outil	Rôle	Vérifié avec
syft	Normaliseur SBOM / convertisseur CycloneDX 1.6	1.52.0
grype	Correspondance CVE	0.119.0
trivy	Scanner de vulnérabilités	0.74.0
osv-scanner	Recherches dans la base OSV	2.4.0, 2.6.0
bomber	Correspondance d'ensemble indépendante	0.5.1
bomdrift	Dérive de chaîne d'approvisionnement / typosquat (SARIF)	0.9.9
inspektr	Scanner de vulnérabilités SBOM (JSON)	0.1.9
shieldbom	Scanner CVE hors ligne embarqué/IoT (SARIF)	0.3.0
provenant	Licence / copyright / provenance (ScanCode)	1.0.10

« Vérifié avec » est la version avec laquelle chaque invocation a réellement été exercée, ni un plancher ni un épinglage : les outils sont résolus sur le PATH à l'exécution et toute version compatible fonctionne. osv-scanner en liste deux car 2.6.0 a été revérifié après que la ligne 2.x a modifié sa journalisation — la forme documentée scan --lockfile <input> --format json est inchangée et se termine toujours avec un code non nul en présence de constats, donc aucun changement de code n'a été nécessaire.