rezmoss/sbomlyzeGit diff pour les SBOM — comparer les documents CycloneDX, SPDX et Syft, détecter les falsifications et valider le CI.
# sbomlyze
**`git diff` pour votre SBOM.** Comparez deux Software Bills of Materials et voyez ce qui a changé entre les builds, les versions et les releases.
sbomlyze compare les hachages des composants, pas seulement les chaînes de version. Lorsqu'un attaquant remplace un paquet sans incrémenter sa version, sbomlyze le signale. Les générateurs et les scanners de vulnérabilités manquent cela.
[![CI][ci-img]][ci]
[![GitHub Marketplace][marketplace-img]][marketplace]
[![GitHub Release][release-img]][release]
[![Go Report Card][go-report-img]][go-report]
[![OpenSSF Scorecard][scorecard-img]][scorecard]
[![OpenSSF Best Practices][best-practices-img]][best-practices]
[![License: Apache-2.0][license-img]][license]
[![Downloads][download-img]][download]
[](https://github.com/rezmoss/sbomlyze-go-spdx-demo/pull/2)
Découvrez pourquoi ce signal est différent d'un diff de manifest ou d'un diff ordinaire de composants dans
[Manifest diff vs. SBOM diff vs. integrity drift](https://github.com/rezmoss/sbomlyze/blob/main/docs/manifest-vs-sbom-vs-integrity-drift.md).
> Les générateurs produisent des SBOM et les scanners trouvent des CVE. sbomlyze vous indique ce qui a changé entre deux SBOM et s'il faut s'y fier.
> Exécutez-le après votre générateur : `syft image:tag -o cyclonedx-json | sbomlyze - --compliance` analyse et note le SBOM généré sans fichier temporaire. Comparez-le à une baseline pour classifier la dérive et conditionner votre pipeline.
## Démarrage rapide avec GitHub Action
Ajoutez [SBOMlyze Diff depuis GitHub Marketplace][marketplace] pour comparer un SBOM versionné
ou généré séparément avec sa baseline git. Le SHA immuable ci-dessous est
l'Action `v0.5.1` publiée :```yaml
steps:
- uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
with:
fetch-depth: 0
- uses: rezmoss/sbomlyze@31503690611fda8ebba4ed2bd186eda000442594 # v0.5.1
with:
sbom-path: build/sbom.cdx.json
```
L'Action écrit un Job Summary par défaut et peut appliquer une politique, signaler
une dérive d'intégrité, téléverser un SARIF ou maintenir un commentaire unique sur
une pull request. Consultez
[la référence complète de l'Action](https://github.com/rezmoss/sbomlyze/blob/main/ACTION.md) pour les entrées, sorties, permissions
et conseils de sécurité. Consultez le
[dépôt de démonstration en direct](https://github.com/rezmoss/sbomlyze-action-demo)
pour une mise à jour de dépendance réussie et un changement de hash à version
identique bloqué, avec des exécutions de workflow publiques et des preuves SARIF.
Pour un dogfooding spécifique à un format, utilisez l'exemple public
[Go + SPDX](https://github.com/rezmoss/sbomlyze-go-spdx-demo),
[Node + CycloneDX](https://github.com/rezmoss/sbomlyze-node-cyclonedx-demo) ou
[container](https://github.com/rezmoss/sbomlyze-container-demo). Chacun
contient cinq scénarios de revue reproductibles. Le
[guide bêta de 10 minutes](https://github.com/rezmoss/sbomlyze/blob/main/BETA.md) rassemble quatre questions ciblées sur
l'activation et la qualité du signal.
Les SBOM générés n'ont pas besoin d'être commités : `baseline: workflow-artifact`
récupère l'artefact correspondant le plus récent d'une exécution réussie sur la
branche par défaut. Un [workflow compagnon Syft épinglé](https://github.com/rezmoss/sbomlyze/blob/main/examples/workflows/syft-companion.yml)
montre la génération et la publication de la baseline tandis que SBOMlyze reste
responsable de la revue et de la politique.
## Pourquoi sbomlyze ?
De nombreux outils génèrent des SBOM. Peu les comparent, et encore moins vous disent si un changement est routinier ou constitue un signal d'alerte de chaîne d'approvisionnement. sbomlyze comble ce vide.
| Capacité | **sbomlyze** | cyclonedx-cli | sbomqs | syft / trivy |
|---|:---:|:---:|:---:|:---:|
| **Diff** SBOM-à-SBOM | ✅ | basique | ❌ | ❌ |
| Dérive d'**intégrité / altération** (hash modifié sans version) | ✅ | ❌ | ❌ | ❌ |
| Diff du graphe de dépendances + risque de profondeur transitive | ✅ | ❌ | ❌ | ❌ |
| Scoring de conformité **NTIA / CISA / BSI** | ✅ | ❌ | ✅ | ❌ |
| Conversion de format (Syft / CycloneDX / SPDX) | ✅ | ✅ | ❌ | partiel |
| Explorateurs **TUI + Web UI** | ✅ | ❌ | ❌ | ❌ |
| Policy gate + SARIF / JUnit / Markdown / HTML / Patch | ✅ | partiel | partiel | partiel |
## Fonctionnalités
- **Diff de SBOM** : Comparez deux SBOM et visualisez en un coup d'œil les composants ajoutés, supprimés et modifiés
- **Classification de dérive** : Distinguez la dérive de version de la **dérive d'intégrité** (un hash modifié sans changement de version, signalant une altération) et de la dérive de métadonnées
- **Scoring de conformité** : Évaluez n'importe quel SBOM selon les éléments minimaux **NTIA**, **CISA 2025** et **BSI TR-03183**
- **Diff du graphe de dépendances** : Suivez les dépendances transitives et la profondeur de la chaîne d'approvisionnement
- **Support multi-format** : Syft, CycloneDX, SPDX (JSON)
- **Conversion de format** : Convertissez entre les formats CycloneDX, SPDX et Syft
- **Correspondance d'identité robuste** : PURL → CPE → BOM-ref → précédence namespace/name
- **Mode statistiques** : Analysez des SBOM uniques pour les métriques de licence, de dépendances et d'intégrité
- **Mode TUI interactif** : Explorez les SBOM avec navigation au clavier et recherche
- **Mode Web UI** : Explorateur de SBOM basé sur navigateur avec téléversement par glisser-déposer
- **Moteur de politique** : Appliquez des règles de dérive, de licence et de score de conformité dans les pipelines CI
- **Action GitHub Marketplace** : Bloquez les pull requests sur la dérive de SBOM avec Job Summary, SARIF et sortie de commentaire optionnelle
- **Détection de doublons et de collisions** : Trouvez plusieurs versions du même paquet et les correspondances d'identité ambiguës
- **Formats de sortie multiples** : Text, JSON, SARIF, JUnit XML, Markdown, HTML, JSON Patch
- **Parsing tolérant** : Continuez en cas d'erreurs avec des avertissements structurés
## Installation
### Homebrew (macOS/Linux)```bash
brew install rezmoss/sbomlyze/sbomlyze
```
### Script d'installation
Le script d'installation télécharge le binaire approprié pour votre OS/architecture :```bash
# Install to ./bin
curl -sSfL https://raw.githubusercontent.com/rezmoss/sbomlyze/main/install.sh | sh
# Install to /usr/local/bin (requires sudo)
curl -sSfL https://raw.githubusercontent.com/rezmoss/sbomlyze/main/install.sh | sudo sh -s -- -b /usr/local/bin
# Install specific version
curl -sSfL https://raw.githubusercontent.com/rezmoss/sbomlyze/main/install.sh | sh -s -- -v 0.4.0
```
**Options d'installation :**
| Option | Description |
|--------|-------------|
| `-b <dir>` | Répertoire d'installation (par défaut : `./bin`) |
| `-d` | Activer la sortie de débogage |
| `-v <ver>` | Installer une version spécifique (par défaut : la plus récente) |
L'installateur vérifie toujours la somme de contrôle de la release. Lorsqu'un GitHub CLI
compatible est installé, il vérifie également la provenance de build de la release et échoue
en mode fermé si cette vérification n'aboutit pas.
### Go Install```bash
go install github.com/rezmoss/sbomlyze/cmd/sbomlyze@latest
```
### À partir d'une version binaire
Téléchargez le dernier binaire depuis [GitHub Releases](https://github.com/rezmoss/sbomlyze/releases).
À partir de la v0.3.7, les archives de version sont publiées avec des attestations
d'artefacts GitHub. Vérifiez un téléchargement de manière indépendante avec :```bash
gh attestation verify ./sbomlyze_0.4.0_Linux_x86_64.tar.gz \
--repo rezmoss/sbomlyze \
--signer-workflow rezmoss/sbomlyze/.github/workflows/release.yml
```
Les instructions pour les dépôts apt, rpm et apk non signés ont été supprimées jusqu'à ce que les dépôts prennent en charge la vérification des signatures native au gestionnaire de paquets.
**Utilisateurs de macOS :** Supprimez l'attribut de quarantaine après le téléchargement :```bash
xattr -d com.apple.quarantine ./sbomlyze
chmod +x ./sbomlyze
```
### Compiler depuis les sources```bash
git clone https://github.com/rezmoss/sbomlyze.git
cd sbomlyze
go build -o sbomlyze ./cmd/sbomlyze
```
## Démarrage rapide```bash
# Compare two SBOMs (the headline use case)
sbomlyze before.json after.json
# Analyze a single SBOM
sbomlyze image.json
# Read an SBOM from standard input
syft image:tag -o cyclonedx-json | sbomlyze -
# Use standard input on either side of a diff
syft image:tag -o cyclonedx-json | sbomlyze baseline.json -
# Score an SBOM against NTIA / CISA / BSI minimum elements
sbomlyze image.json --compliance
# Interactive TUI explorer
sbomlyze image.json -i
# Web UI (opens browser)
sbomlyze -web
# Convert between SBOM formats
sbomlyze convert syft.json --to spdx
sbomlyze convert cdx.json --to syft -o output.json
# JSON output for CI integration
sbomlyze before.json after.json --json
# SARIF output for GitHub Code Scanning
sbomlyze before.json after.json --format sarif
# Markdown report for PR comments
sbomlyze before.json after.json --format markdown
# Apply policy checks
sbomlyze before.json after.json --policy policy.json
```
## Utilisation```
sbomlyze <sbom1|-> [sbom2|-] [options]
sbomlyze convert <sbom|-> --to <format> [-o output]
Modes:
Single file: sbomlyze <sbom> [--json] Show statistics
Interactive: sbomlyze <sbom> -i Interactive explorer
Convert: sbomlyze convert <sbom> --to <fmt> Convert SBOM format
Web server: sbomlyze -web [--port 8080] Web UI explorer
Two files: sbomlyze <sbom1> <sbom2> [...] Show diff
Use `-` in place of one SBOM path to read it from standard input.
Options:
-i, --interactive Interactive TUI explorer
-web, --web Start web UI server
--port <port> Web server port (default 8080)
--json Output in JSON format (shortcut for --format json)
--format <format> Output format: text, json, sarif, junit, markdown, html, patch
--compliance Show NTIA/CISA/BSI compliance scoring
--policy <file> Policy file for CI checks
--strict Fail on parse warnings
--tolerant Continue on parse warnings (default)
--no-pager Disable automatic paging of output
--to <format> Target format for convert: cyclonedx (cdx), spdx, syft
-o, --output <file> Output file for convert (default: stdout)
--version, -v Show version information
--help, -h Show this help message
```
## Commandes
### Mode Statistiques (Fichier Unique)
Analysez un SBOM pour obtenir des informations sur les composants, les licences et les dépendances.```bash
sbomlyze image.json
```
La sortie inclut le contexte du scan, les principales conclusions détectées automatiquement et les statistiques :```
Scan Context:
Tool: syft 1.40.1
Schema: 16.0.18
Scan Scope: all-layers
Source Type: image
Source: alpine:latest
Key Findings:
💻 OS/Distro: Alpine Linux v3.21
📦 Dominated by apk: 71 of 71 packages (100.0%)
📂 8,542 files tracked on filesystem
🔗 Relationships: 71 containment + 64 dependency
📜 License profile: 72% permissive, 20% copyleft
⚠️ Low hash coverage: 0.0% (71 of 71 missing)
🔍 Top catalogers: apkdb-cataloger (71)
📦 SBOM Statistics
==================
Total Components: 71
By Package Type:
apk 71
Licenses:
With license: 71
Without license: 0
Top Licenses:
MIT 17
BSD-3-Clause 8
GPL-2.0-only 8
Integrity:
With hashes: 0
Without hashes: 71
Dependencies:
Components with deps: 65
Total dep relations: 176
```
#### Principales conclusions
sbomlyze génère automatiquement des informations sur votre SBOM. Pour l'analyse d'un seul fichier, celles-ci incluent :
| Conclusion | Description |
|---------|-------------|
| **Détection de l'OS/de la distribution** | Identifie le système d'exploitation ou la distribution à partir des métadonnées du SBOM |
| **Écosystème dominant** | Signale lorsqu'un type de paquet domine (>60 % de tous les paquets) |
| **Empreinte sur le système de fichiers** | Nombre de fichiers suivis sur le système de fichiers |
| **Densité des relations** | Nombre de relations de contenance et de dépendance |
| **Points chauds de localisation** | Principaux répertoires où les composants sont trouvés |
| **Profil de risque de licence** | Répartition des pourcentages de licences permissives/copyleft/inconnues |
| **Avertissements de qualité des données** | Alertes lorsque la couverture des licences (<50 %), des hachages (<50 %) ou des PURL (<80 %) est faible |
| **Avertissements de doublons** | Signale les groupes de composants en double |
| **Répartition par catalogueur** | Principaux scanners/catalogueurs ayant détecté des composants (SBOM Syft) |
#### Métriques de couverture
Le mode statistiques calcule les pourcentages de couverture pour l'évaluation de la qualité des données :
| Métrique | Description |
|--------|-------------|
| **Couverture PURL** | Pourcentage de composants avec des Package URLs |
| **Couverture CPE** | Pourcentage de composants avec des CPE (préparation à l'analyse des vulnérabilités) |
| **Couverture des licences** | Pourcentage de composants avec au moins une licence |
| **Couverture des hachages** | Pourcentage de composants avec des hachages d'intégrité |
#### Catégorisation des licences
Les licences sont automatiquement classées en :
| Catégorie | Exemples |
|----------|----------|
| **Copyleft** | GPL, LGPL, AGPL, MPL, EPL, CDDL |
| **Permissive** | MIT, BSD, Apache, ISC, Zlib, Unlicense |
| **Domaine public** | Dédications au domaine public |
| **Inconnue** | Licences non reconnues ou manquantes |
### Mode Convert
Convertissez les SBOM entre les formats CycloneDX, SPDX et Syft JSON. Le format d'entrée est détecté automatiquement.```bash
# CycloneDX to SPDX
sbomlyze convert image.cdx.json --to spdx
# Syft to CycloneDX (cdx is an alias for cyclonedx)
sbomlyze convert syft-output.json --to cdx
# SPDX to Syft, writing to a file
sbomlyze convert spdx-output.json --to syft -o converted.json
```
#### Formats de cible pris en charge
| Format | Valeur `--to` | Sortie |
|--------|-------------|--------|
| CycloneDX 1.5 | `cyclonedx` ou `cdx` | CycloneDX JSON avec métadonnées, dépendances et propriétés |
| SPDX 2.3 | `spdx` | SPDX JSON avec paquets, relations et références externes |
| Syft | `syft` | Syft JSON avec artefacts, relations, source et informations sur la distribution |
#### Ce qui est préservé
La conversion préserve les noms des composants, les versions, les PURLs, les CPEs, les licences, les hachages, les informations sur le fournisseur et les relations de dépendance. Les champs spécifiques au format (par exemple, le langage Syft, foundBy, les emplacements) sont conservés via les propriétés CycloneDX lors de la conversion vers CDX.
### Mode Diff (Deux fichiers)
Comparez deux SBOMs pour voir ce qui a changé entre les versions.```bash
sbomlyze v1.0.json v2.0.json
```
#### Aperçu du diff
Le diff commence par une comparaison des métadonnées côte à côte (noms de fichiers, tailles, informations sur le système d'exploitation, informations sur l'outil, nombre de composants), suivie des détails du contexte d'analyse lorsqu'ils sont disponibles.
#### Sortie```
📊 Drift Summary:
📦 Version drift: 58 components
⚠️ Integrity drift: 1 component (hash changed without version change!)
📝 Metadata drift: 2 components
🔑 Key Findings:
📈 Attack surface: +5 packages (7.0%), +120 files (3.2%)
🚨 2 version downgrades detected: openssl 3.1.4→3.0.2, curl 8.5.0→8.4.0
🔄 56 version upgrades (2 major, 12 minor, 42 patch) among 65 shared packages
⚠️ Integrity drift (1 total): 1 npm (review recommended)
❌ python ecosystem entirely removed (15 → 0 packages)
➕ New ecosystem: golang (8 packages)
✅ Core system packages stable: apk (71) unchanged
+ Added (2):
+ libgcrypt 1.10.3-r0
+ libgpg-error 1.49-r0
- Removed (3):
- libapk 3.0.3-r1
- libgcc 15.2.0-r2
- nghttp3 1.13.1-r0
~ Changed (58):
~ nginx
version: 1.29.4-r1 -> 1.27.3-r1
~ suspicious-pkg ⚠️ [INTEGRITY]
hash[SHA256]: abc123 -> def456
>> Added dependencies:
pkg:apk/alpine/libxslt: +[so:libgcrypt.so.20]
<< Removed dependencies:
pkg:apk/alpine/libcurl: -[so:libnghttp3.so.9]
🔗 New transitive dependencies (3):
+ pkg:npm/lodash (depth 2)
via: [pkg:npm/my-app pkg:npm/express pkg:npm/lodash]
+ pkg:npm/underscore (depth 3)
via: [pkg:npm/my-app pkg:npm/express pkg:npm/lodash pkg:npm/underscore]
📊 New deps by depth:
Depth 2: 1
Depth 3+ (risky): 2 ⚠️
```
#### Principales conclusions du diff
En mode diff, sbomlyze génère automatiquement des informations plus riches en comparant les deux SBOM :
| Conclusion | Description |
|---------|-------------|
| **Incohérence du contexte de scan** | Avertit si la version du schéma ou la portée du scan a changé entre les SBOM |
| **Delta de la surface d'attaque** | Variations du nombre de paquets, fichiers et relations avec pourcentages |
| **Écosystèmes disparus/nouveaux** | Types de paquets qui sont entièrement apparus ou disparus |
| **Migration OS/distribution** | Détecte les changements de système d'exploitation entre les scans |
| **Analyse des changements de version** | Compte les mises à niveau vs rétrogradations, classe les changements en majeur/mineur/correctif |
| **Rétrogradations de version** | Signale les rétrogradations comme un signal de sécurité avec les détails des composants |
| **Contexte de dérive d'intégrité** | Décompose la dérive d'intégrité par type de paquet avec des conseils de risque |
| **Modèles de chemins dominants** | Changements concentrés par type et chemin de système de fichiers |
| **Points chauds de suppression/ajout** | Principaux répertoires affectés par les changements |
| **Types stables** | Types de paquets avec des nombres identiques (cœur inchangé) |
| **Évolutions des catégories de licence** | Changements dans l'équilibre copyleft/permissif |
| **Lacunes des catalogueurs** | Scanners qui ont trouvé des paquets dans Before mais aucun dans After |
#### Échantillons de paquets par type
Les composants ajoutés et supprimés sont regroupés par type de paquet avec des listes d'échantillons, ce qui facilite la visualisation de ce qui a changé dans chaque écosystème.
## Notation de conformité
Évaluez n'importe quel SBOM par rapport aux trois principaux référentiels d'éléments minimaux pour répondre à la question que les auditeurs et les équipes d'approvisionnement ne cessent de poser : **« Ce SBOM est-il suffisamment complet ? »**```bash
# Score a single SBOM
sbomlyze image.json --compliance
# Score alongside a diff
sbomlyze before.json after.json --compliance
# As JSON for CI
sbomlyze image.json --compliance --json
```
### Frameworks évalués
| Framework | Vérifications | Exigences notables |
|-----------|--------|----------------------|
| **NTIA Minimum Elements** (2021) | 7 | nom, version, fournisseur, identifiants uniques (PURL/CPE), relations de dépendance, auteur du SBOM, horodatage |
| **CISA 2025 Minimum Elements** (brouillon d'août 2025) | 10 | ajoute le producteur du logiciel, les informations de licence, le **hash du composant** et le nom de l'outil en plus du NTIA |
| **BSI TR-03183-2** (v2.1.0, 2025) | 9 | exige les coordonnées du créateur du composant, un **hash SHA-512**, des licences au format SPDX et les coordonnées du créateur du SBOM |
### Présentation du score
Chaque framework rapporte un pourcentage (vérifications réussies / vérifications totales) ainsi qu'un score global (moyenne sur l'ensemble des frameworks), avec des indicateurs de statut :
| Indicateur | Score |
|-----------|-------|
| 🟢 | ≥ 90% |
| 🟡 | 70–89% |
| 🟠 | 50–69% |
| 🔴 | < 50% |
La sortie JSON (`--compliance --json`) inclut le rapport complet avec le détail réussite/échec par vérification ; le format HTML intègre le rapport de conformité dans la page du rapport.
### Contrôler la conformité en CI
Imposez des seuils de conformité via le [moteur de politiques](#policy-engine). La définition de n'importe quel seuil déclenche l'évaluation de conformité sans le flag `--compliance` :```json
{
"min_ntia_score": 85,
"min_cisa_score": 70,
"min_bsi_score": 80,
"min_overall_compliance": 75
}
```
| `-t` | `--target` | Spécifie la cible (domaine, IP ou CIDR) |
| `-p` | `--port` | Spécifie le(s) port(s) à scanner |
| `-s` | `--scan-type` | Spécifie le type de scan (par ex., SYN, TCP, UDP) |
| `-o` | `--output` | Spécifie le fichier de sortie pour les résultats |
| `-v` | `--verbose` | Active la sortie verbeuse |
| `-h` | `--help` | Affiche le message d'aide |```bash
sbomlyze image.json --policy compliance-policy.json
```
## Diff du graphe de dépendances
sbomlyze va au-delà des simples diffs de listes de composants pour analyser le graphe de dépendances complet, détectant les risques de chaîne d'approvisionnement introduits par les dépendances transitives.
### Fonctionnalités
| Fonctionnalité | Description |
|---------|-------------|
| **Diff des arêtes** | Dépendances directes ajoutées/supprimées (A dépend de B) |
| **Accessibilité transitive** | Nouvelles dépendances indirectes qui apparaissent à travers le graphe |
| **Suivi des pertes transitives** | Dépendances transitives qui ont été supprimées |
| **Suivi des chemins** | Montre exactement comment chaque nouvelle dépendance transitive est atteinte |
| **Suivi de la profondeur** | Combien de sauts séparent chaque nouvelle dépendance de votre code |
| **Résumé des risques** | Dépendances de profondeur 3+ signalées comme à risque plus élevé |
### Pourquoi la profondeur importe
Les dépendances introduites plus profondément dans le graphe sont :
- Plus difficiles à auditer et à examiner
- Souvent tirées sans approbation explicite
- Des vecteurs courants pour les attaques de chaîne d'approvisionnement (par ex., l'incident event-stream)
Le résumé de profondeur aide à prioriser l'examen :
| Profondeur | Niveau de risque | Description |
|-------|------------|-------------|
| **1** | Faible | Dépendances directes (vous les avez choisies) |
| **2** | Moyen | Dépendances de vos dépendances |
| **3+** | Élevé ⚠️ | Dépendances transitives profondes - à examiner attentivement |
### Exemple : Détecter les dépendances transitives profondes```bash
# Before: app -> express (simple, 1 dep)
# After: app -> express -> lodash -> underscore -> deep-lib (chain of 4)
sbomlyze before.json after.json
```
```markdown
Output:
``````
🔗 New transitive dependencies (3):
+ lodash (depth 2)
via: [app express lodash]
+ underscore (depth 3)
via: [app express lodash underscore]
+ deep-lib (depth 4)
via: [app express lodash underscore deep-lib]
📊 New deps by depth:
Depth 2: 1
Depth 3+ (risky): 2 ⚠️
```
### Sortie JSON pour le graphe de dépendances```json
{
"dependencies": {
"added_deps": {
"pkg:npm/express": ["pkg:npm/lodash", "pkg:npm/body-parser"]
},
"removed_deps": {},
"transitive_new": [
{
"target": "pkg:npm/underscore",
"via": ["pkg:npm/my-app", "pkg:npm/express", "pkg:npm/lodash", "pkg:npm/underscore"],
"depth": 3
}
],
"transitive_lost": [],
"depth_summary": {
"depth_1": 0,
"depth_2": 2,
"depth_3_plus": 2
}
}
}
```
## Détection de dérive
sbomlyze classe les changements de composants en trois types de dérive, vous aidant à distinguer les mises à jour normales des changements potentiellement suspects.
### Types de dérive
| Type | Indicateur | Description | Sévérité |
|------|-----------|-------------|----------|
| **Version** | 📦 | Numéro de version modifié | Normal |
| **Intégrité** | ⚠️ | Hash modifié SANS changement de version | Élevée - à investiguer ! |
| **Métadonnées** | 📝 | Seules les métadonnées (licences, etc.) ont changé | Faible |
### Dérive d'intégrité (Signal de sécurité)
La dérive d'intégrité se produit lorsqu'un hash de composant change mais que sa version reste identique. Cela pourrait indiquer :
- **Attaque de chaîne d'approvisionnement** : Le paquet a été remplacé par une version malveillante
- **Reconstruction sans incrément de version** : Légitime mais mauvaise pratique
- **Environnement de build différent** : Problèmes de reproductibilité```bash
# Example output with integrity drift
~ suspicious-pkg ⚠️ [INTEGRITY]
hash[SHA256]: abc123 -> def456
```
**Recommandation** : Toujours enquêter sur la dérive d'intégrité. Elle peut être bénigne, mais c'est un signal clé pour la sécurité de la chaîne d'approvisionnement.
### Sortie JSON pour la dérive
Le résumé de la dérive se trouve à l'intérieur de l'objet `diff` :```json
{
"diff": {
"changed": [
{
"id": "pkg:npm/suspicious-pkg",
"name": "suspicious-pkg",
"changes": ["hash[SHA-256]: abc123 -> def456"],
"drift": {
"type": "integrity",
"hash_changes": {
"changed": {
"SHA-256": {"before": "abc123", "after": "def456"}
}
}
}
}
],
"drift_summary": {
"version_drift": 55,
"integrity_drift": 1,
"metadata_drift": 2
}
}
}
```
**Extraction du résumé de dérive :**```bash
# Get drift summary
sbomlyze before.json after.json --json | jq '.diff.drift_summary'
# Check for integrity drift in CI
sbomlyze before.json after.json --json | jq -e '.diff.drift_summary.integrity_drift > 0'
```
## Détection des doublons et des collisions
### Détection des doublons
sbomlyze identifie les composants ayant la même identité mais des versions différentes au sein d'un SBOM :```
⚠️ Duplicates Found: 2
lodash: [4.17.20, 4.17.21]
express: [4.18.0, 4.19.2]
```
En mode diff, la comparaison des versions en double suit :
- **Nouveaux doublons** : Composants devenus dupliqués dans le nouveau SBOM
- **Doublons résolus** : Groupes de doublons qui ont été consolidés
- **Ajouts/suppressions de versions** : Changements de version au sein des groupes de doublons existants
### Détection de collisions
Les collisions sont des correspondances d'identité ambiguës où des composants partagent le même ID mais présentent des caractéristiques contradictoires :
| Type | Description |
|------|-------------|
| **Incohérence de nom** | Noms de composants différents mappés au même ID d'identité |
| **Incohérence de hash** | Une même version d'un composant présente des hash différents (altération potentielle) |
## SBOMlyze SBOM Explorer (TUI)```bash
sbomlyze sbom.json -i
```
### Raccourcis clavier de l'interface TUI
#### Navigation
| Touche | Action |
|-----|--------|
| `↑` / `k` | Déplacer vers le haut |
| `↓` / `j` | Déplacer vers le bas |
| `PgUp` / `Ctrl+u` | Une demi-page vers le haut |
| `PgDn` / `Ctrl+d` | Une demi-page vers le bas |
| `Home` / `g` | Aller en haut |
| `End` / `G` | Aller en bas |
| `Enter` | Afficher les détails du composant |
| `Esc` / `Backspace` | Revenir en arrière |
| `q` / `Ctrl+c` | Quitter |
#### Recherche et filtrage
| Touche | Action |
|-----|--------|
| `/` | Recherche approfondie dans tous les champs (nom, PURL, licences, JSON brut) |
| `t` | Filtrer par type de paquet (npm, apk, golang, pypi, etc.) |
| `c` | Effacer tous les filtres actifs |
#### Vues
| Touche | Contexte | Action |
|-----|---------|--------|
| `j` | Vue détaillée | Afficher le JSON brut du composant avec coloration syntaxique |
| `d` | Vue JSON | Revenir à la vue détaillée |
| `Enter` | Vue JSON | Exporter le JSON du composant vers un fichier |
| `?` | Toute vue | Afficher l'aide avec tous les raccourcis clavier |
### Vue détaillée du composant
La vue détaillée affiche des informations complètes sur le composant :
- Informations sur le paquet (nom, version, PURL, namespace, fournisseur)
- Licences avec indicateurs visuels
- Hachages d'intégrité
- CPE (Common Platform Enumeration)
- Liste des dépendances
- Identifiants (ID, BOM-ref, SPDX-ID)
## Mode interface Web
Démarrez un explorateur SBOM basé sur navigateur avec téléversement de fichiers par glisser-déposer :```bash
# Start web server on default port 8080
sbomlyze -web
# Start on custom port
sbomlyze -web --port 3000
```
Ouvrez ensuite http://localhost:8080 dans votre navigateur.
<img width="1497" height="1266" alt="Screenshot 2026-02-06 at 17 08 13" src="https://assets.kitploit.com/production/public/readmes/12637/57bcd50bc9b9955714b9078d1de37fc8152be02845a5c25b74a8fd14ff587bf4.png" />
### Fonctionnalités de l'interface web
| Fonctionnalité | Description |
|---------|-------------|
| **Glisser-déposer pour l'import** | Déposez n'importe quel fichier SBOM (Syft, CycloneDX, SPDX) sur la page (jusqu'à 500 Mo) |
| **Arborescence des dépendances** | Vue arborescente interactive avec navigation par développement/réduction (paginée pour >5000 composants) |
| **Détails des composants** | Consultez les licences, les hachages, les dépendances, les informations sur le fournisseur, le nombre de fichiers |
| **Vue JSON brute** | JSON avec coloration syntaxique pour chaque composant |
| **Recherche approfondie** | Recherchez dans tous les champs, y compris les données JSON brutes |
| **Tableau de bord statistique** | Métriques de couverture, catégories de licences, répartition des langages |
| **Navigateur de système de fichiers** | Parcourez les fichiers du SBOM avec navigation par répertoire, recherche et filtrage par couche |
### Statistiques affichées
L'interface web affiche des statistiques complètes, notamment :
- **Nombre de composants** par type de paquet (npm, apk, pypi, etc.)
- **Répartition des licences** avec ventilation par catégorie (copyleft, permissive, domaine public)
- **Métriques de couverture** avec barres de progression visuelles :
- Couverture PURL (présence de l'URL du paquet)
- Couverture CPE (préparation à l'analyse des vulnérabilités)
- Couverture des licences
- Couverture des hachages/intégrité
- **Répartition des langages** (pour les SBOM générés par Syft)
- **Statistiques des relations** (contains, dependency-of, evident-by)
- **Avertissements de détection des doublons**
### Cas d'usage
**Revue de sécurité**
- Importez un SBOM et explorez l'arborescence complète des dépendances
- Vérifiez la couverture CPE pour vous assurer que l'analyse des vulnérabilités fonctionne
- Examinez les composants sans licence ni hachage
**Audit de conformité**
- Recherchez des licences spécifiques dans tous les composants
- Consultez la répartition des catégories de licences (copyleft vs permissive)
- Exportez le JSON brut pour la documentation
**Débogage du développement**
- Explorez les paquets inclus dans votre image
- Vérifiez les dépendances transitives
- Vérifiez que les métadonnées des paquets sont correctes
### Navigateur de système de fichiers
L'interface web inclut un navigateur de système de fichiers complet pour explorer les fichiers contenus dans les SBOM (particulièrement utile pour les SBOM générés par Syft avec métadonnées de fichiers) :
- **Navigation dans l'arborescence des répertoires** avec fil d'Ariane
- **Recherche de fichiers** prenant en charge les sous-chaînes et les motifs glob (par ex. `*.so`, `/usr/lib/**/*.conf`)
- **Filtrage par couche** pour les SBOM d'images de conteneurs (parcourez les fichiers par couche d'image)
- **Relations composant-fichier** (quel composant possède quels fichiers)
- **Statistiques des fichiers** par type, type MIME, extension et couche
- **Détection des fichiers non attribués** (fichiers non associés à un composant)
## Options
---
[Read more](https://github.com/rezmoss/sbomlyze)