# 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.

---

_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._

<https://occtet.eu/fr/best-practices/checklists-and-templates/>