SBOM Guide for Developers in 2026: EU CRA, Formats & Your Lockfile Is Already an SBOMGuide SBOM pour Développeurs en 2026 : EU CRA, Formats & Votre Lockfile est déjà un SBOM

If you're a web developer shipping software in 2026, the term "SBOM" has probably started showing up in your procurement questionnaires, compliance checklists, or Slack channels. The EU Cyber Resilience Act (CRA) is making SBOMs mandatory for any product with digital elements sold in Europe. Reporting obligations begin September 11, 2026 — five months from now.

Si vous êtes un développeur web qui livre du logiciel en 2026, le terme « SBOM » a probablement commencé à apparaître dans vos questionnaires d'appels d'offres, listes de conformité ou canaux Slack. Le Cyber Resilience Act (CRA) de l'UE rend les SBOM obligatoires pour tout produit contenant des éléments numériques vendu en Europe. Les obligations de signalement commencent le 11 septembre 2026 — dans cinq mois.

Here's the good news: your lockfile is already most of an SBOM. If you commit a package-lock.json, poetry.lock, or composer.lock, you're already generating the core data that regulators need. This guide explains what's actually required, which format to pick, and how to go from lockfile to compliant SBOM with minimal friction.

Bonne nouvelle : votre lockfile est déjà la majeure partie d'un SBOM. Si vous committez un package-lock.json, poetry.lock ou composer.lock, vous générez déjà les données essentielles que les régulateurs demandent. Ce guide explique ce qui est réellement requis, quel format choisir, et comment passer du lockfile au SBOM conforme avec un minimum de friction.

What Is an SBOM, Really?

Qu'est-ce qu'un SBOM, concrètement ?

An SBOM (Software Bill of Materials) is a machine-readable inventory of every component in your software. Think of it as a package.json for compliance: it lists every dependency (direct and transitive), their versions, where they came from, and their checksums.

Un SBOM (Software Bill of Materials) est un inventaire lisible par machine de chaque composant de votre logiciel. Pensez-y comme un package.json pour la conformité : il liste chaque dépendance (directe et transitive), leurs versions, d'où elles viennent, et leurs checksums.

The CISA (US Cybersecurity & Infrastructure Security Agency) defines 7 minimum data fields for an SBOM, updated in their 2025 guidance:

La CISA (agence américaine de cybersécurité) définit 7 champs minimum pour un SBOM, mis à jour dans leur guide 2025 :

# CISA SBOM Minimum Elements (2025)
1. Supplier Name          — who made the component
2. Component Name         — the package name
3. Version                — exact version string
4. Unique Identifier      — purl, CPE, or SWID tag
5. Dependency Relationship — direct vs transitive
6. SBOM Author            — who generated this SBOM
7. Timestamp              — when the SBOM was generated

# New in 2025 draft:
8. Component Hash         — integrity checksum (SHA-256)
9. License                — SPDX license identifier
10. Tool Name             — which tool generated the SBOM
11. Generation Context    — build-time vs source analysis

# Éléments minimum SBOM selon la CISA (2025)
1. Nom du fournisseur       — qui a créé le composant
2. Nom du composant         — le nom du package
3. Version                  — chaîne de version exacte
4. Identifiant unique       — purl, CPE ou tag SWID
5. Relation de dépendance   — directe vs transitive
6. Auteur du SBOM           — qui a généré ce SBOM
7. Horodatage               — quand le SBOM a été généré

# Nouveautés du brouillon 2025 :
8. Hash du composant        — checksum d'intégrité (SHA-256)
9. Licence                  — identifiant licence SPDX
10. Nom de l'outil          — quel outil a généré le SBOM
11. Contexte de génération  — build-time vs analyse source

If you look at that list and think "my lockfile already has most of these" — you're right. We'll get to that in a moment.

Si vous regardez cette liste et pensez « mon lockfile a déjà la plupart de ces éléments » — vous avez raison. On y revient dans un instant.

The EU CRA Timeline: What Developers Need to Know

Le calendrier EU CRA : ce que les développeurs doivent savoir

The EU Cyber Resilience Act entered into force on December 10, 2024. It applies to any manufacturer of products with digital elements shipped to EU consumers. That includes SaaS companies, agencies deploying client projects, and any developer publishing npm packages, Python libraries, or WordPress plugins used in the EU.

Le Cyber Resilience Act de l'UE est entré en vigueur le 10 décembre 2024. Il s'applique à tout fabricant de produits contenant des éléments numériques vendus aux consommateurs de l'UE. Cela inclut les entreprises SaaS, les agences déployant des projets clients, et tout développeur publiant des packages npm, bibliothèques Python ou plugins WordPress utilisés dans l'UE.

# EU CRA Critical Dates
───────────────────────────────────────────────────
Dec 10, 2024    CRA entered into force
Jun 11, 2026    Conformity Assessment Bodies notified
Sep 11, 2026    Vulnerability REPORTING obligations begin
                → 24h early warning for actively exploited vulns
                → 72h full notification
                → 14-day final report
Dec 11, 2027    ALL requirements fully enforceable
                → SBOM mandatory in technical documentation
                → Machine-readable format required
                → Top-level dependencies at minimum
───────────────────────────────────────────────────
Penalties: up to €15 million or 2.5% global turnover

# Dates clés EU CRA
───────────────────────────────────────────────────
10 déc. 2024    CRA entré en vigueur
11 juin 2026    Notification des organismes d'évaluation
11 sept. 2026   Obligations de SIGNALEMENT en vigueur
                → Alerte précoce en 24h pour vulns exploitées
                → Notification complète en 72h
                → Rapport final en 14 jours
11 déc. 2027    TOUTES les exigences applicables
                → SBOM obligatoire dans la doc technique
                → Format lisible par machine requis
                → Dépendances de premier niveau au minimum
───────────────────────────────────────────────────
Sanctions : jusqu'à 15 millions € ou 2,5% du CA mondial

Why September 2026 matters more than December 2027: The reporting deadline comes 15 months before the SBOM deadline. But here's the catch — to report which vulnerabilities affect your product within 24 hours, you need to already know what components are in it. That means SBOM readiness is effectively required by September 2026, even though the formal SBOM obligation is December 2027.

Pourquoi septembre 2026 compte plus que décembre 2027 : La date limite de signalement arrive 15 mois avant celle du SBOM. Mais voici le piège — pour signaler quelles vulnérabilités affectent votre produit en 24 heures, vous devez déjà savoir quels composants s'y trouvent. Cela signifie que la préparation SBOM est de facto requise dès septembre 2026, même si l'obligation formelle est en décembre 2027.

In the US, the situation is slightly different. OMB Memorandum M-26-05 (January 2026) rescinded the mandatory SBOM attestation memos, shifting to a risk-based approach. However, Executive Order 14028 remains in effect, and federal procurement increasingly requires SBOM documentation from vendors.

Aux États-Unis, la situation est légèrement différente. Le mémorandum OMB M-26-05 (janvier 2026) a annulé les mémos d'attestation SBOM obligatoires, passant à une approche basée sur le risque. Cependant, le décret exécutif 14028 reste en vigueur, et les marchés publics fédéraux exigent de plus en plus la documentation SBOM des fournisseurs.

Your Lockfile Is Already (Most of) an SBOM

Votre Lockfile est déjà (presque) un SBOM

In December 2025, developer Andrew Nesbitt published an influential post titled "Could lockfiles just be SBOMs?". His analysis showed that lockfiles already contain the core data needed for an SBOM:

En décembre 2025, le développeur Andrew Nesbitt a publié un article influent intitulé « Could lockfiles just be SBOMs? ». Son analyse montre que les lockfiles contiennent déjà les données essentielles d'un SBOM :

# What your lockfile already has:
✅ Component Name     — every package listed by name
✅ Version            — exact pinned versions
✅ Integrity Hash     — SHA-512 checksums (npm, Composer)
✅ Dependencies       — full transitive tree resolved
✅ Source URL         — registry + resolved URL

# What your lockfile is missing:
❌ SBOM Author        — who generated it
❌ Timestamp          — when (though git provides this)
❌ License info       — not in most lockfiles
❌ Unique Identifier  — no purl/CPE format
❌ Supplier Name      — not explicitly listed

# Ce que votre lockfile a déjà :
✅ Nom du composant     — chaque package listé par nom
✅ Version              — versions exactes épinglées
✅ Hash d'intégrité     — checksums SHA-512 (npm, Composer)
✅ Dépendances          — arbre transitif complet résolu
✅ URL source           — registre + URL résolue

# Ce qui manque à votre lockfile :
❌ Auteur du SBOM       — qui l'a généré
❌ Horodatage           — quand (bien que git le fournisse)
❌ Info licence          — absent de la plupart des lockfiles
❌ Identifiant unique   — pas de format purl/CPE
❌ Nom du fournisseur   — pas explicitement listé

The gap between a lockfile and a compliant SBOM is metadata, not substance. The hard part — resolving the full dependency tree with exact versions and integrity hashes — is already done by your package manager every time you run npm install, poetry lock, or composer install.

L'écart entre un lockfile et un SBOM conforme est une question de métadonnées, pas de substance. La partie difficile — résoudre l'arbre complet des dépendances avec les versions exactes et les hashs d'intégrité — est déjà faite par votre gestionnaire de packages chaque fois que vous lancez npm install, poetry lock ou composer install.

Here's the comparison for the three most common web development ecosystems:

Voici la comparaison pour les trois écosystèmes les plus courants en développement web :

# Lockfile vs SBOM Data — by ecosystem
──────────────────────────────────────────────────────
                    package-lock.json  poetry.lock  composer.lock
──────────────────────────────────────────────────────
Package name             ✅              ✅            ✅
Exact version            ✅              ✅            ✅
Integrity hash           ✅ (SHA-512)    ✅ (SHA-256)  ✅ (SHA-256)
Dependency tree          ✅              ✅            ✅
Source registry          ✅              ✅            ✅
License                  ❌              ❌            ❌
SBOM author/timestamp    ❌              ❌            ❌
purl identifiers         ❌              ❌            ❌
──────────────────────────────────────────────────────
SBOM fields covered:     5/7             5/7           5/7

# Lockfile vs données SBOM — par écosystème
──────────────────────────────────────────────────────
                    package-lock.json  poetry.lock  composer.lock
──────────────────────────────────────────────────────
Nom du package           ✅              ✅            ✅
Version exacte           ✅              ✅            ✅
Hash d'intégrité         ✅ (SHA-512)    ✅ (SHA-256)  ✅ (SHA-256)
Arbre de dépendances     ✅              ✅            ✅
Registre source          ✅              ✅            ✅
Licence                  ❌              ❌            ❌
Auteur/horodatage SBOM   ❌              ❌            ❌
Identifiants purl        ❌              ❌            ❌
──────────────────────────────────────────────────────
Champs SBOM couverts :   5/7             5/7           5/7

CycloneDX vs SPDX: Which Format Should You Pick?

CycloneDX vs SPDX : quel format choisir ?

Two standards dominate the SBOM space. Here's the practical difference:

Deux standards dominent l'espace SBOM. Voici la différence pratique :

# CycloneDX (OWASP / ECMA-424)
────────────────────────────────
Focus:      Security & vulnerability tracking
Backed by:  OWASP Foundation, standardized as ECMA-424
Best for:   Engineering & security teams
Strengths:  Compact model, native vulnerability support,
            VEX (Vulnerability Exploitability eXchange)
EU CRA:     CycloneDX 1.6+ accepted (BSI TR-03183-2)
Ecosystem:  Higher contributor activity, faster issue
            resolution (Source: arXiv, 2025)

# SPDX (Linux Foundation / ISO 5962:2021)
────────────────────────────────
Focus:      License compliance & IP tracking
Backed by:  Linux Foundation, ISO standard
Best for:   Legal & compliance teams
Strengths:  Deep license fields, NTIA recommended,
            broader regulatory recognition
EU CRA:     SPDX 3.0.1+ accepted (BSI TR-03183-2)
Ecosystem:  Mature tooling, broad industry adoption

# CycloneDX (OWASP / ECMA-424)
────────────────────────────────
Focus :      Sécurité & suivi des vulnérabilités
Soutenu par: Fondation OWASP, standardisé ECMA-424
Idéal pour : Équipes engineering & sécurité
Forces :     Modèle compact, support natif des vulns,
             VEX (Vulnerability Exploitability eXchange)
EU CRA :     CycloneDX 1.6+ accepté (BSI TR-03183-2)
Écosystème : Plus d'activité contributeurs, résolution
             plus rapide (Source : arXiv, 2025)

# SPDX (Linux Foundation / ISO 5962:2021)
────────────────────────────────
Focus :      Conformité licences & suivi PI
Soutenu par: Linux Foundation, standard ISO
Idéal pour : Équipes juridiques & conformité
Forces :     Champs licence détaillés, recommandé NTIA,
             reconnaissance réglementaire plus large
EU CRA :     SPDX 3.0.1+ accepté (BSI TR-03183-2)
Écosystème : Outillage mature, adoption industrielle large

Our recommendation for web developers: Start with CycloneDX. It maps more naturally to lockfile data, its security-first model aligns with vulnerability monitoring, and the OWASP ecosystem has excellent tooling for npm, Python, and PHP. If your company's legal team or procurement process specifically requires SPDX, you can always convert between formats — most modern tools support both.

Notre recommandation pour les développeurs web : Commencez par CycloneDX. Il s'aligne plus naturellement avec les données de lockfile, son modèle sécurité-first correspond au monitoring de vulnérabilités, et l'écosystème OWASP a d'excellents outils pour npm, Python et PHP. Si votre équipe juridique exige spécifiquement SPDX, vous pouvez toujours convertir entre les formats — la plupart des outils modernes supportent les deux.

Generating Your First SBOM: Practical Guide by Ecosystem

Générer votre premier SBOM : guide pratique par écosystème

You don't need a vendor. Your package manager can generate an SBOM today.

Vous n'avez pas besoin d'un fournisseur. Votre gestionnaire de packages peut générer un SBOM dès aujourd'hui.

npm / Node.js

npm / Node.js

npm has a built-in sbom command since npm v10:

npm a une commande sbom intégrée depuis npm v10 :

# Generate CycloneDX SBOM from your project
npm sbom --sbom-format cyclonedx

# Generate SPDX format instead
npm sbom --sbom-format spdx

# Use lockfile only (no node_modules needed)
npm sbom --sbom-format cyclonedx --package-lock-only

# Save to file for CI/CD
npm sbom --sbom-format cyclonedx > sbom.json

For more advanced generation (transitive dependencies, component hashes), use cdxgen:

Pour une génération plus avancée (dépendances transitives, hashs de composants), utilisez cdxgen :

# Install cdxgen globally
npm install -g @cyclonedx/cdxgen

# Generate SBOM from project root
cdxgen -o sbom.json

# cdxgen auto-detects: package-lock.json, yarn.lock,
# pnpm-lock.yaml, bun.lock

Python (pip, Poetry, Pipenv)

Python (pip, Poetry, Pipenv)

# Using cdxgen (recommended — handles all Python lockfiles)
cdxgen -t python -o sbom.json

# Using Syft (anchore)
syft . -o cyclonedx-json > sbom.json

# Syft supports: requirements.txt, poetry.lock,
# Pipfile.lock, setup.py, pyproject.toml

PHP / Composer

PHP / Composer

# Using cdxgen
cdxgen -t php -o sbom.json
# Parses composer.lock, distinguishes required (packages)
# from dev (packages-dev)

# Using CycloneDX PHP Composer plugin
composer require --dev cyclonedx/cyclonedx-php-composer
composer make-bom

Multi-ecosystem with Syft

Multi-écosystème avec Syft

If you work across ecosystems (a common reality for agencies), Syft by Anchore handles all lockfile formats in one tool:

Si vous travaillez sur plusieurs écosystèmes (réalité courante pour les agences), Syft d'Anchore gère tous les formats de lockfile en un seul outil :

# Install Syft
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s

# Generate SBOM from any project directory
syft dir:./my-project -o cyclonedx-json=sbom.json

# Scan a Docker image
syft my-app:latest -o cyclonedx-json=sbom.json

Integrating SBOM Into Your CI/CD Pipeline

Intégrer le SBOM dans votre pipeline CI/CD

The real challenge isn't generating one SBOM — it's keeping it current. Your SBOM changes every time a dependency is added, updated, or removed. The right approach is to generate it automatically on every build.

Le vrai défi n'est pas de générer un SBOM — c'est de le garder à jour. Votre SBOM change à chaque dépendance ajoutée, mise à jour ou supprimée. La bonne approche est de le générer automatiquement à chaque build.

# GitHub Actions example
name: Generate SBOM
on:
  push:
    paths:
      - 'package-lock.json'
      - 'poetry.lock'
      - 'composer.lock'

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

      - name: Generate SBOM
        uses: CycloneDX/gh-node-module-generatebom@v1
        with:
          output: sbom.json

      - name: Upload SBOM artifact
        uses: actions/upload-artifact@v4
        with:
          name: sbom
          path: sbom.json

Key principle: Generate the SBOM from your lockfile, not from node_modules or installed packages. Lockfiles are deterministic and committed to version control — they're your single source of truth for what's actually deployed.

Principe clé : Générez le SBOM depuis votre lockfile, pas depuis node_modules ou les packages installés. Les lockfiles sont déterministes et committés dans le contrôle de version — ils sont votre source unique de vérité pour ce qui est réellement déployé.

SBOM + Vulnerability Monitoring: The Complete Picture

SBOM + Monitoring de vulnérabilités : le tableau complet

An SBOM alone doesn't make you secure — it makes you transparent. You know what's in your software. But the real value comes when you combine that inventory with continuous vulnerability monitoring.

Un SBOM seul ne vous rend pas sécurisé — il vous rend transparent. Vous savez ce qu'il y a dans votre logiciel. Mais la vraie valeur vient quand vous combinez cet inventaire avec un monitoring continu des vulnérabilités.

This is exactly what the EU CRA demands: not just a list of components, but the ability to report actively exploited vulnerabilities within 24 hours. That's impossible without automated scanning.

C'est exactement ce que l'EU CRA exige : pas seulement une liste de composants, mais la capacité de signaler les vulnérabilités activement exploitées en 24 heures. C'est impossible sans scan automatisé.

# The SBOM + Monitoring workflow
───────────────────────────────────────────────────

1. GENERATE   Your lockfile → SBOM (automated in CI/CD)
              package-lock.json → CycloneDX JSON
              poetry.lock → CycloneDX JSON
              composer.lock → CycloneDX JSON

2. MONITOR    Continuous scan against vulnerability DBs
              Every lockfile upload → checked against OSV.dev,
              NVD, GitHub Advisory Database, daily

3. ALERT      Instant notification when new CVE found
              Email + dashboard alert within hours,
              not weeks

4. REPORT     EU CRA compliant vulnerability reporting
              24h early warning → 72h full notification
              → 14-day final report

───────────────────────────────────────────────────
Your lockfile is both your SBOM source AND your
vulnerability monitoring input. One file, two purposes.

# Le workflow SBOM + Monitoring
───────────────────────────────────────────────────

1. GÉNÉRER    Votre lockfile → SBOM (automatisé en CI/CD)
              package-lock.json → CycloneDX JSON
              poetry.lock → CycloneDX JSON
              composer.lock → CycloneDX JSON

2. MONITORER  Scan continu contre les bases de vulnérabilités
              Chaque upload de lockfile → vérifié contre OSV.dev,
              NVD, GitHub Advisory Database, quotidiennement

3. ALERTER    Notification instantanée quand nouvelle CVE trouvée
              Email + alerte dashboard en quelques heures,
              pas en semaines

4. SIGNALER   Reporting conforme EU CRA
              Alerte précoce 24h → notification complète 72h
              → rapport final 14 jours

───────────────────────────────────────────────────
Votre lockfile est à la fois votre source SBOM ET
votre input de monitoring. Un fichier, deux usages.

This is where tools like CVE OptiBot fit in. Instead of generating SBOMs in a format nobody reads, you upload your lockfile and get continuous vulnerability monitoring — the same data, used for the purpose regulators actually care about: knowing when your software is vulnerable and acting on it fast.

C'est là qu'interviennent des outils comme CVE OptiBot. Au lieu de générer des SBOM dans un format que personne ne lit, vous uploadez votre lockfile et obtenez un monitoring continu des vulnérabilités — les mêmes données, utilisées pour ce qui intéresse vraiment les régulateurs : savoir quand votre logiciel est vulnérable et agir vite.

Frequently Asked Questions

Questions fréquentes