Une feuille de route CRA pour les équipes produit
Commencez par un produit et une version. Définissez le périmètre, générez un inventaire logiciel, désignez les responsables des vulnérabilités et notifications, puis reliez chaque correction à une preuve reproductible.
Choisir une version réellement examinable
Un programme devient difficile à chiffrer si « le produit » désigne tous les équipements, applications et services de l’entreprise. Choisissez un build représentatif. Documentez le firmware, les applications associées, les dépendances et les services distants nécessaires. Identifiez les personnes capables de reproduire ce build et les composants fournis par des tiers.
Les principales exigences du CRA s’appliquent le 11 décembre 2027. Les notifications de l’article 14 pour les fabricants s’appliquent déjà depuis le 11 septembre 2026. Traitez ce chantier dès maintenant, tout en faisant confirmer le périmètre et les règles transitoires.
Organiser le travail autour de cinq livrables
- Un schéma du périmètre avec les versions et équipes responsables.
- Une SBOM générée et reliée à la version choisie.
- Un contact sécurité et un circuit de réception jusqu’à la correction.
- Une procédure de notification avec un responsable et un suppléant.
- Un index de preuves reliant exigences, décisions, tests et livrables.
Prioriser les risques et les dépendances
Notre méthode de planification consiste à noter le risque, les versions affectées, les preuves disponibles, le responsable et les blocages pour chaque écart. Une liste courte avec des responsables se transforme plus facilement en travail qu’un score isolé.
Distinguez les changements réalisables dans le dépôt des décisions nécessitant le produit, un fournisseur ou un conseil réglementaire. Modifier une pipeline ne suffit pas à décider de l’engagement d’assistance du fabricant.
Définir des critères de réception démontrables
| Chantier | Preuve de réalisation |
|---|---|
| Automatisation SBOM | Un build propre produit un inventaire versionné dont les limites sont documentées. |
| Réception des signalements | Un signalement de test atteint la bonne équipe et reçoit un accusé suivi. |
| Notification | Un exercice identifie le déclarant, les informations nécessaires et leur archivage. |
| Remédiation | Une modification revue, un test et les versions concernées sont reliés. |
Intégrer les preuves à la livraison
Réexaminez la préparation lorsque le périmètre, une dépendance, une hypothèse de sécurité ou l’assistance change. Ajoutez la mise à jour des preuves à la checklist de livraison.
L’évaluation Dotgrey Continent part d’un produit/build convenu et fournit de premiers livrables opérationnels ainsi qu’une proposition à prix fixe pour la suite. Elle ne remplace pas la décision de conformité du fabricant.
Sources officielles et références
Les workflows proposés sont des recommandations d’ingénierie de Dotgrey. Les textes officiels déterminent les obligations ; l’applicabilité se vérifie pour chaque produit.