# Checklists et modèles La boîte à outils pratique de mise en œuvre pour les PME : des checklists et des modèles légers à cocher en ligne, à imprimer ou à télécharger dans les outils que vous utilisez déjà. --- ## Checklist de conformité minimale viable (MVC) (A1.1) Un socle d'une page regroupant les pratiques que la plupart des PME peuvent mettre en œuvre pour intégrer des composants open source en cohérence avec le CRA. Conçue pour un temps et des ressources limités ; à renforcer de manière proportionnée en fonction du risque. ### A. Rôles et responsabilités — Qui fait quoi ? Désigner un responsable pour : - [ ] La sélection et l'approbation des dépendances - [ ] La surveillance des vulnérabilités - [ ] Les mises à jour de sécurité / l'application des correctifs - [ ] La documentation des versions (ce qui a changé, ce qui a été mis à jour) > Des responsabilités clairement attribuées évitent que les tâches de sécurité restent implicites ou sans responsable. ### B. Visibilité sur les composants — Savoir ce que vous utilisez - [ ] Tenir un registre simple des composants FOSS comprenant : - Nom du composant + version - Où il est utilisé (module / partie du produit) - Criticité (faible / moyenne / élevée) - Exposition (interne / limitée / publique) - Responsable des mises à jour - [ ] Générer un SBOM (au moins pour les versions majeures) ou tenir une liste équivalente des dépendances > La visibilité est le fondement d'une gestion fondée sur les risques. ### C. Diligence raisonnable de base — Avant l'intégration Pour chaque composant important, confirmer les points suivants : - [ ] Le composant est activement maintenu (activité récente / signaux de publication) - [ ] Les vulnérabilités connues ont été examinées - [ ] La compatibilité des licences a été vérifiée - [ ] Un contact de sécurité ou une procédure de divulgation existe (le cas échéant) ### D. Traitement des vulnérabilités — Que faire lorsqu'un problème survient Disposer d'un processus interne de base qui répond aux questions suivantes : - [ ] Comment recevons-nous les alertes de vulnérabilité ? - [ ] Qui effectue le triage ? - [ ] Comment décidons-nous de l'urgence ? - [ ] Comment appliquons-nous les correctifs et publions-nous les versions ? - [ ] Comment communiquons-nous les changements (notes de version) ? ### E. Mises à jour et cycle de vie — Rester sécurisé dans la durée Définir une politique de mise à jour simple : - [ ] À quelle fréquence examinons-nous les mises à jour ? (par exemple, une fois par mois + correctifs urgents dès que possible) - [ ] Comment gérons-nous les composants en fin de vie ? - [ ] Qui approuve les mises à niveau des dépendances ? Suivre au minimum : - [ ] La date du dernier examen des dépendances - [ ] La date de la dernière mise à jour de sécurité / version corrective ### F. Preuves — Pouvoir démontrer ce qui a été fait Conserver des preuves légères pouvant être présentées si nécessaire : - [ ] Registre des composants + SBOM - [ ] Politique de mise à jour (une page suffit) - [ ] Notes sur le traitement des vulnérabilités (processus + au moins un exemple d'entrée de journal) - [ ] Notes de version mentionnant les mises à jour de dépendances / de sécurité > **Principe MVC** — Commencer petit, rester constant et adapter les contrôles en fonction du risque. --- ## Checklist rapide de diligence raisonnable (§5.4.5) Douze questions à se poser avant d'intégrer un composant FOSS. Elle ne remplace pas une évaluation structurée des risques, mais offre un point d'entrée accessible et proportionné pour les PME aux ressources limitées. ### Visibilité de base - [ ] Le projet est-il activement maintenu ? - [ ] L'historique des versions est-il transparent ? - [ ] Un contact de sécurité est-il publiquement disponible ? ### Connaissance des vulnérabilités - [ ] Les vulnérabilités sont-elles documentées ? - [ ] Les correctifs sont-ils publiés de manière structurée ? - [ ] Existe-t-il des signes de réactivité ? ### Transparence de la chaîne d'approvisionnement - [ ] Le composant est-il inclus dans le SBOM ? - [ ] Les dépendances sont-elles visibles ? - [ ] Le versionnage est-il cohérent ? ### Cycle de vie - [ ] Y a-t-il des signes d'une maintenance continue ? - [ ] Les mises à jour sont-elles communiquées clairement ? - [ ] Le statut de fin de vie est-il défini ? --- ## Registre des composants FOSS (A1.2) Un registre simple des composants open source intégrés à votre produit. Il favorise la traçabilité, la diligence raisonnable et la surveillance sur le cycle de vie, et peut être tenu dans un tableur, SharePoint, Git ou tout autre outil interne. | Nom du composant | Version | Utilisé dans | Criticité | Exposition | Licence | Activité des mainteneurs | Dernier examen des vulnérabilités | Responsable des mises à jour | Remarques | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | | ExampleAuthLib | 2.4.1 | Module d'authentification | Élevée | Publique | MIT | Soutenue (versions mensuelles) | 12 févr. 2026 | CTO | Sensible pour la sécurité. CVE-2025-XXXX corrigée dans la v2.4.1. Surveillance continue activée. | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - **Criticité :** Faible / Moyenne / Élevée - **Exposition :** Interne / Limitée / Publique --- ## Fiche de composant open source (A1.3) Pour les composants de criticité moyenne ou élevée, ou tout composant exposé publiquement. Elle complète le registre des composants en documentant les raisons du choix du composant et la surveillance mise en place. ### Composant - **Nom du composant**: - **Version / plage de versions utilisée**: - **Dépôt / lien de référence** (facultatif): - **Utilisé dans** (module / fonctionnalité): - **Criticité fonctionnelle** (Faible / Moyenne / Élevée): - **Exposition** (Interne / Limitée / Publique): - **Licence**: ### Justification du choix — Pourquoi ce composant ? - **Pourquoi a-t-il été choisi ?** (par exemple, adéquation fonctionnelle, stabilité, performances, écosystème) - **Alternatives envisagées** (le cas échéant): ### Diligence raisonnable de base effectuée - [ ] Activité des mainteneurs examinée - [ ] Historique des vulnérabilités examiné - [ ] Contact de sécurité / procédure de divulgation disponible (le cas échéant) - [ ] Compatibilité des licences confirmée - [ ] Inclus dans le SBOM ### Risques connus / remarques - **Limites / préoccupations connues**: - **Préoccupations liées à la profondeur des dépendances** (si pertinent): ### Surveillance et responsabilités - **Responsable des mises à jour / personne responsable**: - **Source(s) de surveillance des vulnérabilités** (par exemple, avis de sécurité, flux CVE, alertes du dépôt): - **Fréquence d'examen** (par exemple, mensuelle + alertes urgentes au besoin): - **Date du dernier examen**: - **Date du prochain examen prévu**: --- ## Mini-guide de traitement des vulnérabilités (A1.4) Un processus de traitement des vulnérabilités structuré mais léger, à la mesure d'une PME, de la première alerte à la clôture. ### 1. Réception — Comment nous recevons les alertes Sources surveillées : - [ ] Avis de sécurité des projets - [ ] Bases de données CVE - [ ] Outil d'analyse des dépendances - [ ] Signalements de clients - [ ] Tests internes - **Responsable des alertes**: - **Contact suppléant**: ### 2. Triage — Déterminer la gravité et l'urgence Pour chaque vulnérabilité, consigner : - **Composant et version(s) concernés**: - **Est-il utilisé dans notre produit ?** (Oui / Non) - **Contexte d'exposition** (Interne / Limitée / Publique): - **Criticité fonctionnelle** (Faible / Moyenne / Élevée): - **Indicateurs d'exploitabilité** (si connus): - **Priorité de réponse proposée** (Faible / Moyenne / Élevée): Règle de décision (simple) : - Criticité élevée + exposition publique → à traiter en urgence - Risque moyen → correctif planifié - Risque faible → suivre et corriger lors du prochain cycle planifié ### 3. Correction — Corriger et vérifier Action entreprise : - [ ] Mise à niveau vers une version corrigée - [ ] Application d'un correctif - [ ] Mesure d'atténuation / modification de configuration - [ ] Solution de contournement temporaire - **Responsable**: - **Date cible**: - **Validation effectuée** (par exemple, tests / non-régression / vérification du déploiement): ### 4. Publication et communication - **Notes de version mises à jour** (Oui / Non): - **SBOM mis à jour** (Oui / Non): - **Communication client / interne nécessaire ?** (Oui / Non) - **Si oui : canal et responsable du message**: ### 5. Clôture et retour d'expérience - **Date de clôture**: - **Ce qui a fonctionné / ce qu'il faut améliorer la prochaine fois** (1 ou 2 points): --- ## Politique de mise à jour des dépendances (A1.5) Une politique courte qui définit comment les dépendances tierces sont examinées, mises à jour et retirées. Une page suffit. ### Périmètre S'applique aux dépendances tierces, y compris les composants FOSS. ### Principe Les dépendances sont maintenues selon une approche fondée sur les risques et orientée cycle de vie. Les actions de mise à jour sont proportionnées à la criticité, à l'exposition et à l'impact. ### Rythme des mises à jour - **Examen régulier des dépendances** (par exemple, mensuel / trimestriel): Les mises à jour de sécurité sont appliquées selon la classification des risques : - **Risque élevé :** dès que possible - **Risque moyen :** correctif planifié dans le prochain cycle de publication - **Risque faible :** suivi et résolu dans le cadre de la maintenance courante ### Responsabilité des décisions - **Responsable de l'approbation des mises à niveau de dépendances**: - **Responsable de l'approbation des correctifs de sécurité urgents**: ### Dépendances en fin de vie Si une dépendance n'est plus prise en charge ou arrive en fin de vie, nous : - Consignons le risque - Évaluons les alternatives - Planifions une migration ou des mesures compensatoires - Documentons la décision et le calendrier --- ## 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._