
Git diff pour les SBOM — comparer les documents CycloneDX, SPDX et Syft, détecter les falsifications et valider le CI.
git diff pour votre SBOM. Comparez deux Bills of Materials logiciels et voyez ce qui a changé entre les builds, versions et releases.
sbomlyze compare les empreintes de composants, pas seulement les chaînes de version. Lorsqu'un attaquant remplace un package sans en augmenter la version, sbomlyze le signale. Les générateurs et les scanners de vulnérabilités ne détectent pas 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] [![License: Apache-2.0][license-img]][license] [![Downloads][download-img]][download]
Découvrez pourquoi ce signal diffère d'un manifeste ou d'un diff de composants classique dans Manifest diff vs. SBOM diff vs. integrity drift.
Les générateurs produisent des SBOM et les scanners trouvent des CVE. sbomlyze vous indique ce qui a changé entre deux SBOM et si vous pouvez lui faire confiance. Exécutez-le après votre générateur :
syft image:tag -o cyclonedx-json | sbomlyze - --complianceanalyse et évalue le SBOM généré sans fichier temporaire. Comparez-le avec une baseline pour classer les dérives et contrôler votre pipeline.
Ajoutez [SBOMlyze Diff from GitHub Marketplace][marketplace] pour comparer un SBOM suivi dans le dépôt
ou généré séparément avec sa baseline git. Le SHA immuable ci-dessous est
l'Action publiée v0.5.1 :```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 du SARIF ou maintenir un unique commentaire de pull request. Voir [la référence complète de l’Action](https://github.com/rezmoss/sbomlyze/blob/HEAD/ACTION.md) pour les entrées, les sorties, les permissions et les recommandations de sécurité. Voir le [dépôt de démonstration en direct](https://github.com/rezmoss/sbomlyze-action-demo) pour une mise à jour de dépendance acceptée et un changement de hash bloqué à version identique, avec des exécutions de workflow publiques et des preuves SARIF.
Pour un dogfooding spécifique au 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 [conteneur](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/HEAD/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 de la branche par défaut. Un [workflow compagnon Syft épinglé](https://github.com/rezmoss/sbomlyze/blob/HEAD/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 une modification est routinière ou un signal d’alerte pour la chaîne d’approvisionnement. sbomlyze comble cette lacune.
| Capacité | **sbomlyze** | cyclonedx-cli | sbomqs | syft / trivy |
|---|:---:|:---:|:---:|:---:|
| **Diff** SBOM à SBOM | ✅ | basique | ❌ | ❌ |
| Dérive **d’intégrité / d’altération** (hash modifié sans changement de version) | ✅ | ❌ | ❌ | ❌ |
| Diff de graphe de dépendances + risque de profondeur transitive | ✅ | ❌ | ❌ | ❌ |
| Score de conformité **NTIA / CISA / BSI** | ✅ | ❌ | ✅ | ❌ |
| Conversion de format (Syft / CycloneDX / SPDX) | ✅ | ✅ | ❌ | partiel |
| Explorateurs **TUI + Web UI** | ✅ | ❌ | ❌ | ❌ |
| Contrôle de politique + SARIF / JUnit / Markdown / HTML / Patch | ✅ | partiel | partiel | partiel |
## Fonctionnalités
- **Diffing SBOM** : Comparez deux SBOM et voyez d’un coup d’œil les composants ajoutés, supprimés et modifiés
- **Classification des dérives** : 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
- **Score de conformité** : Notez tout SBOM par rapport aux éléments minimaux **NTIA**, **CISA 2025** et **BSI TR-03183**
- **Diff de 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** : Priorité PURL → CPE → BOM-ref → namespace/name
- **Mode statistiques** : Analysez des SBOM uniques pour les métriques de licence, de dépendance et d’intégrité
- **Mode TUI interactif** : Explorez les SBOM avec navigation clavier et recherche
- **Mode Web UI** : Explorateur de SBOM basé sur le navigateur avec téléversement par glisser-déposer
- **Moteur de politique** : Appliquez les règles de dérive, de licence et de score de conformité dans les pipelines CI
- **Action GitHub Marketplace** : Conditionnez les pull requests selon la dérive SBOM avec Job Summary, SARIF et sortie de commentaire facultative
- **Détection des doublons et collisions** : Trouvez plusieurs versions du même paquet et des correspondances d’identité ambiguës
- **Formats de sortie multiples** : Texte, JSON, SARIF, JUnit XML, Markdown, HTML, JSON Patch
- **Analyse tolérante** : Continuez en cas d’erreurs avec des avertissements structurés
## Installation
### Homebrew (macOS/Linux)```bash
brew install rezmoss/sbomlyze/sbomlyze
Le script d'installation télécharge le bon binaire pour votre OS/architecture :```bash
curl -sSfL https://raw.githubusercontent.com/rezmoss/sbomlyze/main/install.sh | sh
curl -sSfL https://raw.githubusercontent.com/rezmoss/sbomlyze/main/install.sh | sudo sh -s -- -b /usr/local/bin
curl -sSfL https://raw.githubusercontent.com/rezmoss/sbomlyze/main/install.sh | sh -s -- -v 0.4.0
**Options de l'installateur :**
| Option | Description |
|--------|-------------|
| `-b <dir>` | Répertoire d'installation (défaut : `./bin`) |
| `-d` | Activer la sortie de débogage |
| `-v <ver>` | Installer une version spécifique (défaut : dernière) |
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 la build de la release et échoue (fail closed) si
cette vérification ne réussit pas.
### Go Install```bash
go install github.com/rezmoss/sbomlyze/cmd/sbomlyze@latest
Téléchargez la dernière version binaire depuis GitHub Releases.
À partir de la v0.3.7, les archives de versions sont publiées avec des attestations
d'artefacts GitHub. Vérifiez un téléchargement indépendamment 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 concernant les dépôts apt, rpm et apk non signés ont été retirées jusqu'à ce que
les dépôts prennent en charge la vérification de signature native du gestionnaire de paquets.
**Utilisateurs de macOS :** Supprimez le drapeau de quarantaine après le téléchargement :```bash
xattr -d com.apple.quarantine ./sbomlyze
chmod +x ./sbomlyze
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
sbomlyze <sbom1|-> [sbom2|-] [options] sbomlyze convert <sbom|-> --to [-o output]
Modes: Single file: sbomlyze [--json] Show statistics Interactive: sbomlyze -i Interactive explorer Convert: sbomlyze convert --to Convert SBOM format Web server: sbomlyze -web [--port 8080] Web UI explorer Two files: sbomlyze [...] 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 Web server port (default 8080) --json Output in JSON format (shortcut for --format json) --format Output format: text, json, sarif, junit, markdown, html, patch --compliance Show NTIA/CISA/BSI compliance scoring --policy Policy file for CI checks --strict Fail on parse warnings --tolerant Continue on parse warnings (default) --no-pager Disable automatic paging of output --to Target format for convert: cyclonedx (cdx), spdx, syft -o, --output 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 comprend le contexte de l'analyse, les principaux résultats détectés 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)
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 constatations
sbomlyze génère automatiquement des informations sur votre SBOM. Pour l'analyse d'un fichier unique, celles-ci incluent :
| Constatation | Description |
|---------|-------------|
| **Détection OS/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 du système de fichiers** | Nombre de fichiers suivis sur le système de fichiers |
| **Densité des relations** | Comptage des relations de containment et de dependency-of |
| **Points chauds de localisation** | Répertoires principaux où les composants sont trouvés |
| **Profil de risque de licence** | Répartition des pourcentages de licences permissives / copyleft / inconnues |
| **Avertissements sur la 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 des catalogueurs** | Principaux scanners/catalogueurs ayant détecté des composants (SBOM Syft) |
#### Métriques de couverture
Le mode statistiques calcule des pourcentages de couverture pour l'évaluation de la qualité des données :
| Métrique | Description |
|--------|-------------|
| **Couverture PURL** | Pourcentage de composants avec des URL de paquet |
| **Couverture CPE** | Pourcentage de composants avec des CPE (préparation à l'analyse de 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 catégorisées en :
| Catégorie | Exemples |
|----------|----------|
| **Copyleft** | GPL, LGPL, AGPL, MPL, EPL, CDDL |
| **Permissive** | MIT, BSD, Apache, ISC, Zlib, Unlicense |
| **Domaine public** | Dédicaces au domaine public |
| **Inconnue** | Licences non reconnues ou manquantes |
### Mode Conversion
Convertit les SBOM entre les formats JSON CycloneDX, SPDX et Syft. 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
La conversion préserve les noms des composants, les versions, les PURL, les CPE, les licences, les empreintes (hashs), les informations du fournisseur et les relations de dépendance. Les champs spécifiques au format (par ex. langage Syft, foundBy, locations) sont transmis via les propriétés CycloneDX lors de la conversion vers CDX.
Comparez deux SBOM 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 côte à côte des métadonnées (noms de fichiers, tailles, informations sur le système d'exploitation, informations sur l'outil, nombre de composants), suivie des détails du contexte de scan 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 ⚠️
En mode diff, sbomlyze génère automatiquement des insights plus riches comparant les deux SBOM :
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.
Évaluez n'importe quelle SBOM par rapport aux trois principaux frameworks d'éléments minimaux pour répondre à la question que les auditeurs et les équipes d'approvisionnement ne cessent de poser : « Cette SBOM est-elle suffisamment complète ? »```bash
sbomlyze image.json --compliance
sbomlyze before.json after.json --compliance
sbomlyze image.json --compliance --json
### Cadres évalués
| Cadre | 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** (projet d'août 2025) | 10 | ajoute le producteur du logiciel, les informations de licence, **hash du composant** et le nom de l'outil en plus de NTIA |
| **BSI TR-03183-2** (v2.1.0, 2025) | 9 | exige le contact du créateur du composant, **hash SHA-512**, les licences au format SPDX et le contact du créateur du SBOM |
### Présentation des scores
Chaque cadre rapporte un pourcentage (vérifications réussies / vérifications totales) ainsi qu'un score global (moyenne entre les cadres), 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 de réussite/échec par vérification ; le format HTML intègre le rapport de conformité dans la page du rapport.
### Exiger la conformité dans le CI
Appliquez les seuils de conformité via le [moteur de règles](#policy-engine). La définition d'un seuil quelconque déclenche l'évaluation de la conformité sans l'option `--compliance` :```json
{
"min_ntia_score": 85,
"min_cisa_score": 70,
"min_bsi_score": 80,
"min_overall_compliance": 75
}
The input is empty: there is no content to translate. Please provide the chunk 33/115 content you want translated into French.```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, en détectant les risques liés à la chaîne d'approvisionnement introduits via les dépendances transitives.
### Fonctionnalités
| Fonctionnalité | Description |
|---------|-------------|
| **Diff d'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 chaque nouvelle dépendance se trouve de votre code |
| **Résumé des risques** | Dépendances de profondeur 3+ signalées comme à risque plus élevé |
### Pourquoi la profondeur est importante
Les dépendances introduites plus profondément dans le graphe sont :
- Plus difficiles à auditer et à examiner
- Souvent ajoutées sans approbation explicite
- Vecteurs courants d'attaques de la chaîne d'approvisionnement (par ex., incident event-stream)
Le résumé de profondeur aide à prioriser la revue :
| 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étection de 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
Sortie:``` 🔗 New transitive dependencies (3):
📊 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
}
}
}
sbomlyze classe les modifications de composants en trois types de dérive, vous aidant à distinguer les mises à jour normales des changements potentiellement suspects.
La dérive d'intégrité se produit lorsque le hash d'un composant change mais que sa version reste la même. Cela pourrait indiquer :
~ suspicious-pkg ⚠️ [INTEGRITY] hash[SHA256]: abc123 -> def456
**Recommandation** : Examinez toujours le drift d'intégrité. Il peut être bénin, mais c'est un signal clé pour la sécurité de la chaîne d'approvisionnement.
### Sortie JSON pour le drift
Le résumé du drift se trouve dans 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
sbomlyze before.json after.json --json | jq '.diff.drift_summary'
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 dans un SBOM :```
⚠️ Duplicates Found: 2
lodash: [4.17.20, 4.17.21]
express: [4.18.0, 4.19.2]
En mode diff, le suivi des versions dupliquées détecte :
Les collisions sont des correspondances d'identité ambiguës où des composants partagent le même ID mais présentent des caractéristiques conflictuelles :
| Type | Description |
|---|---|
| Incohérence de nom | Différents noms de composants mappés au même ID d'identité |
| Incohérence de hash | Même version d'un composant avec des hashs différents (altération potentielle) |
sbomlyze sbom.json -i

### Raccourcis clavier TUI
#### Navigation
| Touche | Action |
|-----|--------|
| `↑` / `k` | Déplacer vers le haut |
| `↓` / `j` | Déplacer vers le bas |
| `PgUp` / `Ctrl+u` | Monter d'une demi-page |
| `PgDn` / `Ctrl+d` | Descendre d'une demi-page |
| `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 filtres
| 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, espace de noms, fournisseur)
- Licences avec indicateurs visuels
- Hashes d'intégrité
- CPEs (Common Platform Enumeration)
- Liste des dépendances
- Identifiants (ID, BOM-ref, SPDX-ID)
## Mode interface web
Lancez 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
Ensuite, ouvrez http://localhost:8080 dans votre navigateur.
L'interface Web affiche des statistiques complètes, notamment :
Revue de sécurité
Audit de conformité
Débogage de développement
L'interface Web inclut un explorateur de système de fichiers complet pour explorer les fichiers dans les SBOM (particulièrement utile pour les SBOM générés par Syft avec des métadonnées de fichiers) :
*.so, /usr/lib/**/*.conf)-i (Mode interactif)Lancez l'explorateur TUI en mode terminal pour naviguer dans les SBOM avec les commandes clavier.```bash sbomlyze image.json -i
Fonctionnalités : navigation arborescente, détails des composants, recherche, inspection des licences/hashs.
### `-web` (Mode serveur web)
Démarrez un serveur web pour l'exploration de SBOM via navigateur.```bash
# Default port 8080
sbomlyze -web
# Custom port
sbomlyze -web --port 3000
L'interface web fournit le téléversement par glisser-déposer, une vue arborescente interactive, une recherche approfondie et un tableau de bord de statistiques.
--complianceÉvaluez le SBOM par rapport aux cadres d'éléments minimaux NTIA, CISA 2025 et BSI TR-03183. Voir Scoring de conformité.```bash sbomlyze image.json --compliance sbomlyze image.json --compliance --json
### `--format` / `-f`
Sélectionnez le format de sortie. Sept formats sont disponibles :
| Format | Option | Description | Idéal pour |
|--------|------|-------------|----------|
| **text** | `--format text` (par défaut) | Sortie terminal lisible par un humain | Inspection locale |
| **json** | `--json` ou `--format json` | JSON structuré | Pipelines CI, scripting |
| **sarif** | `--format sarif` | SARIF 2.1.0 pour GitHub Code Scanning | Intégration GitHub |
| **junit** | `--format junit` | Résultats de tests JUnit XML | Tableaux de bord de tests CI |
| **markdown** | `--format markdown` | Rapport Markdown prêt pour les commentaires de PR | Commentaires de pull request |
| **html** | `--format html` | Rapport HTML autonome (CSS/JS intégrés) | Auditeurs, rapports partageables |
| **patch** | `--format patch` | Opérations JSON Patch RFC 6902 | Application programmatique de correctifs |```bash
# SARIF output for GitHub Code Scanning
sbomlyze before.json after.json --format sarif > results.sarif
# JUnit output for CI test dashboards
sbomlyze before.json after.json --format junit > results.xml
# Markdown report for PR comments
sbomlyze before.json after.json --format markdown > report.md
# Self-contained HTML report
sbomlyze before.json after.json --format html > report.html
# JSON Patch operations
sbomlyze before.json after.json --format patch > changes.json
Génère un rapport SARIF 2.1.0 adapté à GitHub Code Scanning. Les règles détectées incluent :
integrity-drift (erreur) : hash modifié sans changement de versiondeep-dependency (avertissement) : nouvelle dépendance à une profondeur de 3 ou plusnew-component / removed-component (note) : ajouts/suppressions de composantsversion-change (note) : mises à jour de version de composantspolicy-violation (erreur/avertissement) : violations de règles de politiqueGénère du XML JUnit avec des cas de test pour :
Génère un rapport Markdown avec :
Génère un fichier HTML unique autonome (CSS et JavaScript intégrés, aucune ressource externe) adapté pour être envoyé par e-mail aux auditeurs ou joint à une version. Il comprend le tableau de bord des statistiques, l'arbre des dépendances, le résumé de la dérive et le rapport de conformité intégré lorsque --compliance est défini.
Génère un tableau d'opérations JSON Patch RFC 6902 (add, remove, replace) représentant le diff.
--jsonRaccourci pour --format json. Produit les résultats au format JSON pour une consommation programmatique.```bash
sbomlyze image.json --json
sbomlyze before.json after.json --json
**Structure JSON des stats :**```json
{
"stats": {
"total_components": 71,
"by_type": {"apk": 71},
"by_license": {"MIT": 17, "BSD-3-Clause": 8},
"without_license": 0,
"with_hashes": 0,
"without_hashes": 71,
"total_dependencies": 176,
"with_dependencies": 65,
"duplicate_count": 0,
"by_language": {"go": 45, "python": 12},
"by_found_by": {"apk-db-cataloger": 71},
"license_categories": {
"copyleft": 8,
"permissive": 55,
"public_domain": 0,
"unknown": 8
},
"with_cpes": 71,
"without_cpes": 0,
"with_purl": 71,
"without_purl": 0
},
"warnings": []
}
--policy <file>Appliquez les règles de la politique et faites échouer le CI en cas de violation.```bash sbomlyze before.json after.json --policy policy.json
Voir [Policy Engine](#policy-engine) pour plus de détails.
### `--strict`
Échoue immédiatement sur toute erreur d'analyse.```bash
sbomlyze broken.json --strict
# Error parsing broken.json: unknown SBOM format
# exit status 1
--tolerant (par défaut)Continuer le traitement en cas d'erreurs, collecter les avertissements.```bash sbomlyze broken.json --tolerant
Les avertissements d'analyse incluent des informations structurées : le fichier source, un message lisible par un humain, et éventuellement le champ à l'origine du problème.
### `--no-pager`
Désactive la pagination automatique de la sortie. Utile lorsque vous redirigez la sortie vers une autre commande ou lorsque vous exécutez dans des environnements non interactifs.```bash
sbomlyze image.json --no-pager
sbomlyze before.json after.json --no-pager | head -20
Créer des politiques pour appliquer des règles dans les pipelines CI/CD. sbomlyze se termine avec le code 1 en cas de violations.
{ "max_added": 10, "max_removed": 5, "max_changed": 100, "deny_licenses": ["GPL-3.0", "AGPL-3.0"], "require_licenses": true, "deny_duplicates": true, "deny_integrity_drift": true, "max_depth": 3, "warn_supplier_change": true, "warn_new_transitive": true, "min_ntia_score": 85, "min_cisa_score": 70, "min_bsi_score": 80, "min_overall_compliance": 75 }
### Règles de politique
| Règle | Type | Description |
|------|------|-------------|
| `max_added` | int | Nombre maximal de nouveaux composants autorisés (0 = illimité) |
| `max_removed` | int | Nombre maximal de composants supprimés autorisés (0 = illimité) |
| `max_changed` | int | Nombre maximal de composants modifiés autorisés (0 = illimité) |
| `deny_licenses` | []string | Liste des identifiants de licence interdits |
| `require_licenses` | bool | Exiger que tous les composants *ajoutés* aient des licences (ne vérifie que les composants nouvellement ajoutés en mode diff) |
| `deny_duplicates` | bool | Échouer si des paquets en double existent dans le résultat |
| `deny_integrity_drift` | bool | Échouer si le hachage d'un composant change sans changement de version (risque de chaîne d'approvisionnement) |
| `max_depth` | int | Échouer si de nouvelles dépendances transitives sont à une profondeur >= N (0 = illimité) |
| `warn_supplier_change` | bool | Avertir (sans échouer) si le fournisseur/auteur d'un composant change |
| `warn_new_transitive` | bool | Avertir (sans échouer) en cas de nouvelles dépendances transitives |
| `min_ntia_score` | int | Échouer si le score de conformité NTIA est inférieur à ce seuil (0-100, 0 = désactivé) |
| `min_cisa_score` | int | Échouer si le score de conformité CISA est inférieur à ce seuil (0-100, 0 = désactivé) |
| `min_bsi_score` | int | Échouer si le score de conformité BSI est inférieur à ce seuil (0-100, 0 = désactivé) |
| `min_overall_compliance` | int | Échouer si le score de conformité global est inférieur à ce seuil (0-100, 0 = désactivé) |
> Définir tout seuil `min_*_score` déclenche automatiquement l'évaluation de la conformité, même sans l'option `--compliance`.
### Exemple : Politique stricte```json
{
"max_added": 5,
"max_removed": 3,
"max_changed": 20,
"deny_licenses": ["GPL-3.0", "AGPL-3.0", "SSPL-1.0"],
"require_licenses": true,
"deny_duplicates": true,
"deny_integrity_drift": true,
"max_depth": 3,
"warn_supplier_change": true,
"warn_new_transitive": true,
"min_overall_compliance": 80
}
!! Policy Violations (3): [max_added] too many components added: 10 > 5 [max_removed] too many components removed: 7 > 3 [deny_licenses] component foo has denied license: GPL-3.0
## Formats SBOM pris en charge
| Format | Détection de fichier | Identifiants extraits |
|--------|----------------------|------------------------|
| Syft (natif) | Clé JSON `"artifacts"` + l'une de `"source"`, `"distro"`, `"descriptor"` | PURL, CPE, name |
| CycloneDX | Clé JSON `"bomFormat"` = `"CycloneDX"`, ou `"$schema"` contenant `cyclonedx` | PURL, CPE, BOM-ref, group (namespace) |
| SPDX | Clé JSON `"spdxVersion"` commençant par `"SPDX-"` | PURL, CPE, SPDXID |
Tous les formats doivent être en JSON. La prise en charge de XML n'est pas disponible actuellement.
### Conversion de format
sbomlyze peut convertir entre n'importe lequel des trois formats pris en charge :```bash
sbomlyze convert input.json --to spdx # any format → SPDX 2.3
sbomlyze convert input.json --to cyclonedx # any format → CycloneDX 1.5
sbomlyze convert input.json --to syft # any format → Syft JSON
Voir Mode Conversion pour plus de détails.
sbomlyze peut comparer des SBOM dans différents formats :```bash
sbomlyze syft-output.json cyclonedx-output.json
sbomlyze spdx-output.json syft-output.json
**Remarque :** Les différents formats de SBOM extraient différents niveaux de détail. Un diff entre formats peut montrer des changements qui reflètent des différences de format (par exemple, la disponibilité des champs) plutôt que de réels changements système. Le système de résultats clés signalera les incohérences de contexte d'analyse lorsqu'elles seront détectées.
## Correspondance d'identité des composants
Les composants sont mis en correspondance à l'aide d'un système d'identité basé sur la priorité :
| Priorité | Identifiant | Exemple | Description |
|----------|------------|---------|-------------|
| 1 | PURL | `pkg:npm/lodash` | Package URL (version supprimée) |
| 2 | CPE | `cpe:vendor:product` | CPE vendor:product (version supprimée) |
| 3 | BOM-ref / SPDXID | `ref:component-123` | Identifiant CycloneDX bom-ref ou SPDX |
| 4 | Namespace + Name | `com.example/mypackage` | Groupe/namespace avec nom |
| 5 | Name | `simple-package` | Repli sur le nom uniquement |
## Intégration CI/CD
### GitHub Actions
SBOMlyze est fourni sous forme d'Action JavaScript sans dépendance. Elle compare un SBOM de tête archivé ou généré séparément avec le fichier à la base git de la pull request, publie un Job Summary, et produit éventuellement du SARIF ou met à jour un commentaire de PR.```yaml
name: SBOM Check
on:
pull_request:
permissions:
contents: read
jobs:
sbom-diff:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
with:
fetch-depth: 0
- id: sbomlyze
uses: rezmoss/sbomlyze@31503690611fda8ebba4ed2bd186eda000442594 # v0.5.1
with:
sbom-path: build/sbom.cdx.json
policy: .github/sbom-policy.json
fail-on: policy
L'Action n'exécute jamais les commandes du générateur. Générez le SBOM de tête dans une étape séparée,
faisant l'objet d'une revue, ou commitez-le dans le dépôt. comment et sarif sont tous deux définis
par défaut sur false; les PR issues d'un fork reçoivent toujours le Job Summary complet lorsque l'autorisation
de commentaire n'est pas disponible. Consultez la référence de l'Action pour toutes les
entrées/sorties, l'épinglage SHA, le téléversement SARIF, les permissions et le comportement de sécurité.
sbom-diff: stage: test script: - syft . -o json > current.json - sbomlyze baseline.json current.json --policy policy.json --json > sbom-report.json - sbomlyze baseline.json current.json --format junit > sbom-junit.xml artifacts: paths: - sbom-report.json reports: junit: sbom-junit.xml when: always
### Alerte de dérive d'intégrité```bash
# Alert on any integrity drift (CI example)
if sbomlyze baseline.json current.json --json | jq -e '.diff.drift_summary.integrity_drift > 0' > /dev/null; then
echo "⚠️ INTEGRITY DRIFT DETECTED - Investigate immediately!"
exit 1
fi
if sbomlyze baseline.json current.json --json | jq -e '.diff.dependencies.depth_summary.depth_3_plus > 0' > /dev/null; then echo "⚠️ New deep transitive dependencies detected - Review required!" fi
### Porte de conformité```bash
# Fail the build if the SBOM doesn't meet minimum-element requirements
sbomlyze current.json --policy compliance-policy.json
# where compliance-policy.json sets min_overall_compliance / min_ntia_score / etc.
| Code | Signification |
|---|---|
| 0 | Succès, aucune différence ni violation |
| 1 | Différences trouvées (tout composant ajouté/supprimé/modifié), violations de politique ou erreurs |
Remarque : En mode diff, le code de sortie 1 est renvoyé dès qu'une modification de composant est détectée, même sans fichier de politique. Cela le rend utilisable comme un simple contrôle « quelque chose a-t-il changé ? » dans le CI.
syft nginx:1.25-alpine -o json > nginx-125.json syft nginx:1.26-alpine -o json > nginx-126.json
sbomlyze nginx-125.json nginx-126.json
### Audit de licence```bash
# Check for GPL licenses in new dependencies
cat > audit-policy.json << EOF
{
"deny_licenses": ["GPL-2.0", "GPL-3.0", "LGPL-2.1", "LGPL-3.0"],
"require_licenses": true
}
EOF
sbomlyze old.json new.json --policy audit-policy.json
cat > no-drift.json << EOF { "max_added": 0, "max_removed": 0, "max_changed": 0 } EOF
sbomlyze baseline.json current.json --policy no-drift.json
### Vérification de conformité```bash
# Score an SBOM and enforce a minimum
sbomlyze image.json --compliance
cat > compliance-policy.json << EOF
{
"min_ntia_score": 90,
"min_overall_compliance": 80
}
EOF
sbomlyze image.json --policy compliance-policy.json
syft alpine:latest -o json > alpine-syft.json sbomlyze convert alpine-syft.json --to cyclonedx -o alpine-cdx.json
sbomlyze convert vendor-sbom.cdx.json --to spdx > vendor-sbom.spdx.json
sbomlyze convert input.json --to spdx | jq '.packages | length'
### Explorer SBOM dans le navigateur```bash
# Generate SBOM and explore in web UI
syft alpine:latest -o json > alpine.json
# Start web server
sbomlyze -web
# Then open http://localhost:8080 and drag-drop alpine.json
sbomlyze alpine.json -i
## Développement
### Exécuter les tests```bash
make test
# or
go test -v ./...
make lint # runs go vet + golangci-lint + staticcheck make vulncheck # runs govulncheck for known CVEs
### Compilation```bash
make build-quick
# or
go build -o sbomlyze ./cmd/sbomlyze
make all # Run test, lint, and build make test # Run all tests with race detector make lint # Run go vet, golangci-lint, and staticcheck make vulncheck # Run govulncheck for known vulnerabilities make build # Build with goreleaser (snapshot) make build-quick # Quick build for development make snapshot-test # Run snapshot tests only make update-snapshot # Update snapshot golden files make clean # Remove build artifacts
## Contribuer
Les contributions sont les bienvenues ! Les good first issues sont étiquetées [`good first issue`](https://github.com/rezmoss/sbomlyze/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22). Consultez [CONTRIBUTING.md](https://github.com/rezmoss/sbomlyze/blob/HEAD/CONTRIBUTING.md) s'il est présent, et n'hésitez pas à ouvrir une issue ou une discussion pour proposer des modifications.
[ci]: https://github.com/rezmoss/sbomlyze/actions/workflows/ci.yml
[ci-img]: https://github.com/rezmoss/sbomlyze/actions/workflows/ci.yml/badge.svg
[marketplace]: https://github.com/marketplace/actions/sbomlyze-diff
[marketplace-img]: https://img.shields.io/badge/Marketplace-SBOMlyze%20Diff-blue?logo=github
[release]: https://github.com/rezmoss/sbomlyze/releases
[release-img]: https://img.shields.io/github/v/release/rezmoss/sbomlyze
[go-report]: https://goreportcard.com/report/github.com/rezmoss/sbomlyze
[go-report-img]: https://goreportcard.com/badge/github.com/rezmoss/sbomlyze
[license]: https://raw.githubusercontent.com/rezmoss/sbomlyze/main/LICENSE
[license-img]: https://img.shields.io/badge/License-Apache%202.0-blue.svg
[download]: https://github.com/rezmoss/sbomlyze/releases
[download-img]: https://img.shields.io/github/downloads/rezmoss/sbomlyze/total
[scorecard]: https://scorecard.dev/viewer/?uri=github.com/rezmoss/sbomlyze
[scorecard-img]: https://api.scorecard.dev/projects/github.com/rezmoss/sbomlyze/badge
| 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 packages, relations et références externes |
| Syft | syft | Syft JSON avec artefacts, relations, source et informations de distribution |
| Résultat | Description |
|---|
| Incohérence du contexte d'analyse | Alerte si la version du schéma ou le périmètre d'analyse a changé entre les SBOM |
| Delta de surface d'attaque | Variations des nombres de paquets, fichiers et relations avec pourcentages |
| Écosystèmes disparus/nouveaux | Types de paquets ayant entièrement disparu ou fait leur apparition |
| Migration OS/distribution | Détecte les changements de système d'exploitation entre les analyses |
| Analyse des changements de version | Compte les montées de version par rapport aux baisses, classe les changements en majeurs/mineurs/correctifs |
| Baisses de version | Signale les baisses de version comme signal de sécurité avec le détail des composants |
| Contexte de dérive d'intégrité | Décompose la dérive d'intégrité par type de paquet avec recommandations de risque |
| Schémas de chemins dominants | Changements concentrés par type et chemin de système de fichiers |
| Points chauds de suppressions/ajouts | Principaux répertoires affectés par les changements |
| Types stables | Types de paquets avec des comptes identiques (noyau inchangé) |
| Changements de catégories de licence | Modifications de l'équilibre copyleft/permissif |
| Lacunes du catalogueur | Analyseurs ayant trouvé des paquets dans Avant mais aucun dans Après |
| Type | Indicateur | Description | Sévérité |
|---|
| Version | 📦 | Numéro de version modifié | Normale |
| Intégrité | ⚠️ | Hash modifié SANS changement de version | Élevée - à examiner ! |
| Métadonnées | 📝 | Seules les métadonnées (licences, etc.) ont changé | Faible |
| Fonctionnalité | Description |
|---|
| Glisser-déposer | Déposez n'importe quel fichier SBOM (Syft, CycloneDX, SPDX) sur la page (jusqu'à 500 Mo) |
| Arbre des dépendances | Vue arborescente interactive avec navigation développer/réduire (paginée pour plus de 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 statistiques | Métriques de couverture, catégories de licences, répartition par langage |
| Explorateur de système de fichiers | Parcourez les fichiers du SBOM avec navigation par répertoire, recherche et filtrage par couche |