# Checklist SBOM pour les PME (A1.6) Ce qu'il faut consigner dans une nomenclature logicielle (SBOM), et à quel moment. Un SBOM favorise la transparence et la traçabilité des produits qui utilisent des composants FOSS, et les pratiques SBOM peuvent être adoptées progressivement. ## Ce qu'il faut consigner — Minimum - [ ] Nom du produit + version (identifiant de version) - [ ] Nom du composant + version - [ ] Dépendances directes et transitives (selon disponibilité) - [ ] Informations de licence (lorsque c'est possible) - [ ] Identifiants uniques (lorsqu'ils sont disponibles, par exemple package URL / empreintes) ## Quand générer ou mettre à jour le SBOM Minimum : - [ ] Pour les versions majeures (par exemple, 1.0, 1.1, 2.0) Recommandé : - [ ] Pour chaque version qui modifie les dépendances Toujours mettre à jour lorsque : - [ ] Un correctif de sécurité nécessite une mise à niveau de dépendance - [ ] Un composant critique / fortement exposé change de version - [ ] Une correction de vulnérabilité est mise en œuvre ## Niveaux de maturité SBOM ### Niveau 1 — De base - Liste structurée des dépendances - Mise à jour à chaque version majeure - Lien avec la documentation des versions ### Niveau 2 — Structuré - Génération automatisée du SBOM (lorsque c'est possible) - Dépendances directes + transitives - Collecte des informations de licence - SBOM stocké avec les artefacts de publication ### Niveau 3 — Avancé - Génération du SBOM intégrée au CI/CD - Surveillance continue des dépendances - Vérification des empreintes - Historique des versions du SBOM - Analyse d'impact rapide en cas de CVE --- _D'après le livrable OCCTET D2.3 – Bonnes pratiques d'adoption du CRA (CRA Adoption Best Practice Document, v1.0, mars 2026), publié sous licence CC BY 4.0._