Syft : générer des SBOM en CLI

Un SBOM (Software Bill of Materials) est un inventaire complet de tous les composants logiciels de votre application : librairies, versions, licences, dépendances. C’est devenu un standard de sécurité obligatoire pour répondre aux réglementations comme le Cyber Resilience Act ou la directive NIS2.

Syft est un outil open source développé par Anchore qui génère des SBOM en quelques secondes, pour n’importe quelle image conteneur, projet source ou archive. Simple, rapide, intégrable partout.

Exemple concret : scanner une image FastAPI Python (devops-status-api) → 118 packages catalogués, SBOM de 618K en 2 secondes.

Pourquoi utiliser Syft ?

Cas d’usage concrets

Réglementations

Générez automatiquement les SBOM obligatoires pour les audits de conformité (CRA, NIS2, Executive Order US).

Détection vulnérabilités

Alimentez des scanners comme Grype ou Dependency-Track avec des SBOM à jour.

Supply chain sécurisée

Créez des attestations signées qui prouvent l’intégrité de vos builds selon SLSA.

Transparence légale

Documentez automatiquement les licences et composants open source pour vos équipes juridiques.

Points forts de Syft

• Rapide : génère un SBOM de devops-status-api (118 packages) en ~2 secondes
• Multi-sources : images Docker, registries OCI, projets locaux, archives tar/zip
• Multi-formats : CycloneDX (JSON, XML), SPDX (JSON, tag-value), GitHub Dependency, table Markdown…
• Zéro config : détection automatique des langages (Go, Python, npm, Maven, etc.)
• CI/CD ready : GitHub Actions, GitLab CI, Jenkins, Tekton…

Installation

Linux / macOS

Le script officiel installe la dernière version stable :

curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin

Vérifiez l’installation :

syft version

Vous devriez voir :

Application:   syft
Version:       1.38.2
BuildDate:     2025-12-09T21:48:47Z
GitCommit:     bfe63f83dbaea88e22a5cfcd7d704c034c953730
GitDescription: v1.38.2
Platform:      linux/amd64
GoVersion:     go1.25.4
Compiler:      gc
SchemaVersion: 16.1.0

Autres plateformes

Homebrew (macOS/Linux)

brew install syft

Docker

docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
anchore/syft:latest <source>

Windows (Scoop)

scoop install syft

Binaire standalone

Téléchargez depuis GitHub Releases ↗ :

wget https://github.com/anchore/syft/releases/download/v1.38.2/syft_1.38.2_linux_amd64.tar.gz
tar -xzf syft_1.38.2_linux_amd64.tar.gz -C /usr/local/bin syft
chmod +x /usr/local/bin/syft

Premiers SBOM : images conteneur

Générer un SBOM depuis une image locale

Si vous avez une image Docker déjà téléchargée :

syft devops-status-api@sha256:0c4d2ee8...

Ce qui se passe :

1. Syft détecte que c’est une image OCI (par le digest SHA256)
2. Il scanne toutes les couches de l’image
3. Il identifie les paquets APK (Alpine), bibliothèques Python, exécutables
4. Il affiche un tableau avec nom, version, type de chaque composant

Résultat :

 ✔ Cataloged packages [118 packages]
NAME                 VERSION       TYPE
alpine-baselayout    3.7.1-r8      apk
python               3.12.12       binary
fastapi              0.115.5       python
python-jose          3.3.0         python
starlette            0.41.3        python
requests             2.31.0        python
... 112 autres packages

118 packages : typique pour une image Python Alpine (base Alpine + dépendances Python + exécutables).

Sauvegarder en JSON (CycloneDX)

Pour exploiter le SBOM dans d’autres outils :

syft devops-status-api@sha256:0c4d2ee8... -o cyclonedx-json > sbom.json
# ✔ Cataloged packages [118 packages]
# Fichier généré : sbom.json (618K)

Options disponibles :

• cyclonedx-json : format JSON CycloneDX (standard DevSecOps)
• cyclonedx-xml : format XML CycloneDX
• spdx-json : format JSON SPDX (standard Linux Foundation)
• spdx-tag-value : format texte SPDX (lisible humain)
• github-json : format Dependency Graph GitHub
• table : tableau terminal (par défaut)
• text : liste simple texte

Vérifier le contenu JSON :

jq '.components | length' sbom.json
# 969 (composants CycloneDX détaillés : packages + dépendances)

Lister les 5 premiers packages Python :

jq '.components[:5] | .[] | {name, version}' sbom.json
# {"name": "alembic", "version": "1.14.0"}
# {"name": "anthropic", "version": "0.40.0"}
# ...

Pourquoi CycloneDX ? Développé par l’OWASP, CycloneDX inclut nativement les vulnérabilités (VEX), licences, hashes et dépendances. C’est le format recommandé pour la sécurité applicative.

Scanner une image distante (registry)

Pas besoin de docker pull :

syft registry:ghcr.io/mon-org/devops-status-api:v1.0.0 -o spdx-json > app.spdx.json
# ✔ Cataloged packages [118 packages]

Ce qui se passe :

1. Syft télécharge uniquement les métadonnées OCI (manifeste + config)
2. Il télécharge les couches nécessaires en streaming
3. Il génère le SBOM sans polluer votre cache Docker local

Avantage : scanner 50 images sans remplir votre disque.

Comprendre les formats SBOM

CycloneDX vs SPDX : lequel choisir ?

Critère	CycloneDX	SPDX
Créateur	OWASP	Linux Foundation
Focus	Sécurité applicative + DevSecOps	Conformité légale + licences
Vulnérabilités	VEX natif (Vulnerability Exploitability eXchange)	Extension externe nécessaire
Taille fichier	Compact (focus composants critiques)	Verbeux (métadonnées exhaustives)
Adoption	Scanners (Dependency-Track, Grype, Trivy)	Tooling juridique + ISO/IEC 5962:2021
Format	JSON, XML	JSON, tag-value, RDF, YAML

Recommandation pratique :

• CycloneDX JSON : pour la CI/CD, scanners de vulnérabilités, dashboards temps réel
• SPDX JSON : pour audits légaux, conformité réglementaire (CRA, NIS2), archivage long terme

Générer les deux formats simultanément :

syft alpine:latest -o cyclonedx-json=alpine.cdx.json -o spdx-json=alpine.spdx.json

Vous obtenez :

• alpine.cdx.json → pour Dependency-Track
• alpine.spdx.json → pour l’équipe juridique

Versionner les formats

CycloneDX et SPDX évoluent. Syft permet de spécifier la version du schéma :

# CycloneDX 1.5 (recommandé en 2025)
syft nginx:latest -o cyclonedx-json@1.5=sbom.json

# SPDX 2.3 (version stable actuelle)
syft nginx:latest -o spdx-json@2.3=sbom.json

Pourquoi c’est important ? Les outils en aval (scanners, compliance tools) supportent des versions spécifiques. Vérifiez la doc de votre chaîne d’outils.

Scanner des projets locaux

Syft ne scanne pas que des images Docker. Il analyse aussi :

• Code source d’un projet (détection automatique pip, npm, go.mod, pom.xml…)
• Systèmes de fichiers montés
• Archives (.tar, .zip, .rpm, .deb)

Projet Python (source)

cd ~/projets/devops-status-api
syft dir:. -o table | head -15
# ✔ Cataloged packages [32 packages]
NAME                 VERSION  TYPE
alembic              1.14.0   python
fastapi              0.115.5  python
python-jose          3.3.0    python
requests             2.31.0   python
... 28 autres

Ce qui est détecté :

• requirements.txt, setup.py, pyproject.toml
• Packages Python avec versions exactes
• Dépendances dévelopement (pytest, black, mypy…)

Différence image vs source :

• Image : 118 packages (Alpine + Python + runtime)
• Source : 32 packages (uniquement dépendances Python déclarées)

Scanner un filesystem Linux complet

Utile pour auditer un serveur :

sudo syft dir:/ -o cyclonedx-json > system-sbom.json

Attention : cela scanne TOUT le système (paquets APT/YUM, binaires, libs). Le SBOM sera volumineux (plusieurs Mo).

Cas d’usage : Conformité PCI-DSS, audits de vulnérabilités sur machines virtuelles legacy, inventaire datacenter.

Intégration CI/CD

GitHub Actions

Ajoutez cette étape dans .github/workflows/build.yml :

name: Build avec SBOM

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Build image
        run: docker build -t devops-status-api:${{ github.sha }} .

      - name: Installer Syft
        run: curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin

      - name: Générer SBOM
        run: syft devops-status-api:${{ github.sha }} -o cyclonedx-json=sbom.json

      - name: Uploader SBOM
        uses: actions/upload-artifact@v4
        with:
          name: sbom-cyclonedx
          path: sbom.json
          retention-days: 90

Résultat : SBOM stocké 90 jours dans GitHub Artifacts, téléchargeable ou envoyable à un scanner.

- name: Upload to Dependency Graph
  uses: advanced-security/sbom-generator-action@v1
  with:
    sbom-file: sbom.json

GitLab CI

Dans .gitlab-ci.yml :

generate-sbom:
  image: alpine:latest
  stage: build
  before_script:
    - apk add --no-cache curl
    - curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin
  script:
    - syft $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA -o cyclonedx-json=sbom.json
  artifacts:
    paths:
      - sbom.json
    expire_in: 1 month

Variables utilisées :

• $CI_REGISTRY_IMAGE : chemin complet de l’image dans le registry GitLab
• $CI_COMMIT_SHA : hash du commit (tag de l’image)

Attestations signées (Sigstore)

Une attestation est un SBOM signé cryptographiquement qui prouve :

1. Quel SBOM a été généré
2. Qui l’a généré (identité GitHub/OIDC)
3. Quand il a été généré
4. Qu’il n’a pas été modifié depuis

Syft + Cosign = attestations SLSA conformes au framework SLSA.

Générer une attestation signée

Pré-requis : installer Cosign :

curl -sL https://github.com/sigstore/cosign/releases/latest/download/cosign-linux-amd64 -o cosign
chmod +x cosign && sudo mv cosign /usr/local/bin/

Générer + signer avec Sigstore (keyless) :

syft attest --output cyclonedx-json devops-status-api@sha256:0c4d2ee8... | \
  cosign attest --type cyclonedx --predicate - devops-status-api@sha256:0c4d2ee8...
# ✔ Attestation signée et publiée dans le registry

Ce qui se passe :

1. Syft génère le SBOM CycloneDX
2. Cosign crée une attestation in-toto
3. Signature via Sigstore (certificat éphémère OIDC)
4. Attestation publiée dans le registry OCI

Pourquoi crucial ? Sans signature, un attaquant peut modifier le SBOM (masquer une vulnérabilité). L’attestation garantit l’intégrité.

Distribution OCI avec ORAS

Plutôt que stocker les SBOM dans S3, attachez-les directement aux images avec ORAS.

# Générer SBOM
syft devops-status-api@sha256:0c4d2ee8... -o spdx-json > sbom.spdx.json

# Attacher au registry OCI
oras attach --artifact-type application/spdx+json \
  devops-status-api@sha256:0c4d2ee8... \
  sbom.spdx.json:application/spdx+json

Avantages : SBOM suit l’image (même registry, même permissions), pas de bucket S3 à gérer.

Cas d’usage avancés

Multi-format pour plusieurs consommateurs

Votre équipe sécurité veut du CycloneDX, l’équipe juridique du SPDX, et le management un PDF. Générez tout d’un coup :

syft nginx:latest \
  -o cyclonedx-json=sbom.cdx.json \
  -o spdx-json=sbom.spdx.json \
  -o table=sbom.txt

Ensuite, convertissez le texte en PDF avec enscript ou pandoc.

Scanner avec Grype immédiatement

Grype est le scanner de vulnérabilités d’Anchore :

# Générer SBOM + scanner en 1 commande
syft devops-status-api@sha256:0c4d2ee8... -o json | grype
# ✔ Scanned [12 vulnerability matches]

Pourquoi séparer SBOM et scan ? SBOM change rarement, CVE découvertes quotidiennement → re-scanner le même SBOM sans rebuilder l’image.

grype sbom:./sbom.json

Alimenter Dependency-Track

Dependency-Track centralise tous vos SBOM et suit les vulnérabilités dans le temps.

Uploader un SBOM via API :

# Générer le SBOM
syft mon-app:latest -o cyclonedx-json > sbom.json

# Encoder en Base64
SBOM_B64=$(cat sbom.json | base64 -w0)

# Uploader vers Dependency-Track
curl -X PUT https://dependency-track.exemple.fr/api/v1/bom \
  -H "X-Api-Key: ${DT_API_KEY}" \
  -H "Content-Type: application/json" \
  -d "{
    \"projectName\": \"mon-app\",
    \"projectVersion\": \"1.0\",
    \"autoCreate\": true,
    \"bom\": \"${SBOM_B64}\"
  }"

Dependency-Track détecte automatiquement si c’est du CycloneDX ou SPDX.

Comparer deux SBOM (diff)

Utile pour détecter les ajouts/suppressions entre deux versions :

# Comparer v1.0 vs v1.1
syft devops-status-api:v1.0 -o json > sbom-v1.json
syft devops-status-api:v1.1 -o json > sbom-v1.1.json
jd -set sbom-v1.json sbom-v1.1.json

Cas d’usage : auditer changements de dépendances avant production (nouveau package suspect ?).

À retenir

• Installation : 1 script curl, zéro config, détection auto langages
• Formats : CycloneDX (DevSecOps) ou SPDX (légal/conformité)
• Multi-sources : images Docker, registries OCI, code source, archives
• CI/CD : intégration GitHub Actions/GitLab en 5 lignes
• Attestations : Syft + Cosign = SBOM signés (SLSA)
• Écosystème : Grype (scan), Dependency-Track (central), ORAS (OCI)

Pour aller plus loin

Guides connexes :

• SBOM de A à Z : concepts, formats, réglementations
• Grype : scanner vulnérabilités SBOM
• Cosign : signer images et attestations
• SLSA : framework supply chain (niveaux 1-4)

Documentation :

• Syft GitHub ↗ : source, releases, issues
• CycloneDX Spec ↗ : schéma JSON/XML
• SPDX Spec ↗ : ISO/IEC 5962:2021