Checklists et modèles

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é

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 ?

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

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

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