Aller au contenu principal

Bonnes pratiques d'adoption du CRA

Guide de conformité au CRA pour les PME

Une démarche pratique et proportionnée pour les PME qui intègrent des composants FOSS : qui doit se concentrer sur quoi, comment évaluer les risques, quel niveau de diligence raisonnable appliquer et comment le maintenir dans la durée.

Sur cette page

Personas en PME : sur quoi se concentrer

Les PME abordent l’adoption du CRA à partir de rôles et de niveaux de maturité technique différents. Les personas suivants illustrent des responsabilités courantes et ce que chaque rôle doit prioriser lors de l’utilisation et de l’intégration de composants FOSS.

Persona A

Dirigeant non technique

PDG / Directeur des opérations / Responsable d'exploitation

Priorité : s’assurer que l’entreprise peut démontrer une démarche de conformité raisonnable et reproductible, sans devoir entrer dans le détail technique.

  • Veiller à ce que les rôles soient attribués (qui gère les mises à jour, qui surveille les vulnérabilités, qui approuve les dépendances).
  • Veiller à ce que les preuves de base existent (disponibilité du SBOM, contact de sécurité, politique de mise à jour, canal de signalement des vulnérabilités).
  • Allouer le temps et le budget nécessaires aux activités de « conformité minimale viable ».
  • Exiger une documentation simple : ce que nous utilisons, pourquoi nous l’utilisons, comment nous le maintenons à jour.

Persona B

Responsable technique

CTO / Développeur principal / Responsable DevOps

Priorité : mettre en œuvre des contrôles concrets qui réduisent les risques et peuvent être maintenus dans la durée.

  • Intégrer la sécurité au cycle de vie (revue, tests, publications sécurisées, mises à jour).
  • Assurer la visibilité sur les dépendances (SBOM, analyse des dépendances, suivi des dépendances transitives).
  • Mettre en place le traitement des vulnérabilités (réception, triage, processus de correction, notes de version).
  • Garantir la traçabilité (rigueur du versionnage, journal des modifications, branches protégées, contrôles d’accès).

Persona C

Product owner / coordinateur conformité

Chef de produit / QA / Référent sécurité

Priorité : faire le lien entre les décisions produit, les attentes des clients et les preuves de conformité.

  • Clarifier le périmètre du produit et l’usage prévu (où les FOSS sont utilisés, où se situe l’exposition).
  • Adopter une vision fondée sur les risques : quels composants sont critiques et lesquels présentent un faible risque.
  • Tenir à jour des dossiers de preuves légers (décisions relatives aux risques, registre des composants, historique des mises à jour).
  • Coordonner les équipes pour que la surveillance et les mises à jour ne passent pas entre les mailles du filet.

Ces personas ne s’excluent pas mutuellement. Dans de nombreuses PME, une même personne cumule plusieurs rôles. L’essentiel est de veiller à ce que les responsabilités soient explicitement attribuées.

D'une consommation ad hoc à une gouvernance structurée

Le CRA annonce une transformation plus large : la conformité ne se limite plus à la conception interne des produits. Elle s’étend à toute la chaîne d’approvisionnement logicielle. Pour les PME, cela implique de passer d’une consommation ad hoc de l’open source à une gouvernance structurée de l’écosystème, fondée sur les risques.

Consommation ad hoc

Fragmentée et manuelle

Gouvernance structurée

Fondée sur les risques et évolutive

Les gestionnaires open source deviennent des acteurs clés de cette architecture de gouvernance, et l’utilisation de composants dépourvus de gestionnaire fera l’objet d’un examen approfondi afin d’en évaluer correctement les risques. Plutôt que d’auditer individuellement chaque projet en amont, les PME peuvent :

  • S’appuyer sur des processus alignés sur ceux des gestionnaires open source
  • Se reposer sur des cadres de sécurité structurés
  • Documenter cet engagement dans le cadre de leur diligence raisonnable
  • Démontrer une gestion proportionnée et fondée sur les risques

Cette approche s’inscrit dans l’esprit du CRA : améliorer la cybersécurité sans imposer de charge disproportionnée.

Diligence raisonnable pour les composants open source

L’intégration de composants FOSS dans des produits comportant des éléments numériques crée une responsabilité partagée tout au long de la chaîne d’approvisionnement logicielle. Dans le cadre fondé sur les risques du CRA, les fabricants, y compris les PME, sont tenus d’exercer une diligence raisonnable appropriée et proportionnée lors de la sélection, de l’intégration et de la maintenance de composants logiciels tiers.

La diligence raisonnable n’a pas pour but de décourager l’utilisation de logiciels open source. Au contraire, les FOSS restent un levier fondamental d’innovation et de compétitivité. Ils doivent toutefois être intégrés de manière responsable. La diligence raisonnable garantit que :

Vous comprenez ce que vous intégrez

Vous connaissez le niveau de risque qu’il introduit

Vous pouvez justifier votre décision d’intégration

Vous êtes en mesure de le surveiller et de le maintenir dans la durée

La diligence raisonnable n’est pas une vérification ponctuelle avant la publication. C’est une activité orientée cycle de vie, qui se poursuit pendant toute la durée de vie prévue du produit, conformément aux exigences du CRA en matière de développement sécurisé et de gestion des vulnérabilités.

Évaluation des composants FOSS fondée sur les risques

Avant d’intégrer un composant FOSS, les PME devraient évaluer trois dimensions clés. Les questions sont conçues pour être compréhensibles par les décideurs techniques comme non techniques.

Criticité fonctionnelle

Demandez-vous :

  • Ce composant gère-t-il l’authentification, le chiffrement, le contrôle d’accès ou les mises à jour ?
  • Est-il au cœur des fonctionnalités principales du produit ?
  • Si ce composant tombe en panne, notre produit cesserait-il de fonctionner ?
  • Pourrait-il compromettre la confidentialité, l’intégrité ou la disponibilité des données ?

Plus la fonction est critique, plus l’évaluation doit être rigoureuse. Une bibliothèque de journalisation n’est pas comparable à un module d’authentification.

Niveau d’exposition

Demandez-vous :

  • Ce composant est-il accessible depuis Internet ?
  • Traite-t-il des données saisies par des utilisateurs externes ?
  • Est-il exposé via des API ?
  • Ou est-il entièrement interne et isolé ?

Une exposition plus forte élargit la surface d’attaque. Un composant utilitaire interne peut nécessiter un examen plus léger qu’un composant de service exposé publiquement.

Impact d’une défaillance

Demandez-vous :

  • Une exploitation pourrait-elle entraîner une violation de données personnelles ?
  • Une interruption de service affecterait-elle les clients ?
  • Cela déclencherait-il des obligations de notification réglementaire ?
  • Cela pourrait-il nuire à notre réputation ?

L’impact détermine l’effort justifié en matière de gestion des risques.

Ces facteurs se combinent

  • Un composant moyennement critique mais exposé publiquement peut nécessiter des contrôles renforcés.
  • Un composant très critique utilisé uniquement en interne peut justifier un examen structuré mais proportionné.

L’objectif est la proportionnalité, et non un contrôle uniforme.

Niveaux de diligence raisonnable proportionnés

Conformément au principe de proportionnalité du CRA, les pratiques de diligence raisonnable peuvent être structurées selon des niveaux de maturité croissants.

Niveau 1

Diligence raisonnable de base

Adaptée aux composants peu critiques et faiblement exposés.

Les mesures comprennent :

  • Vérification de l’activité du projet et de sa maintenance récente
  • Examen des vulnérabilités divulguées publiquement
  • Vérification de la compatibilité des licences
  • Inclusion du composant dans la nomenclature logicielle (Software Bill of Materials, SBOM)

L’objectif est la transparence et la traçabilité. Pour de nombreuses PME, il s’agit d’un socle réaliste et atteignable, en phase avec des attentes de conformité proportionnées.

Niveau 2

Diligence raisonnable structurée

Adaptée aux composants moyennement critiques ou exposés.

Mesures complémentaires possibles :

  • Examen de la transparence de la gouvernance et de la structure des mainteneurs
  • Évaluation des pratiques de signalement et de réponse aux vulnérabilités
  • Évaluation de la rigueur des publications et de la clarté du versionnage
  • Outils automatisés d’analyse des dépendances

Une diligence raisonnable structurée apporte de la prévisibilité. Elle limite les décisions prises au cas par cas et étaye des évaluations internes des risques documentées.

Niveau 3

Diligence raisonnable renforcée

Adaptée aux composants très critiques ou exposés publiquement.

Mesures renforcées possibles :

  • Surveillance continue des vulnérabilités
  • Examen des pratiques de divulgation coordonnée
  • Évaluation de l’engagement de maintenance à long terme
  • Prise en compte des attestations de sécurité volontaires prévues par l’article 25
  • Dialogue avec les mainteneurs le cas échéant

Particulièrement pertinente pour les composants qui :

  • Traitent des données sensibles
  • Sont exposés publiquement
  • Assurent des fonctionnalités essentielles du produit
  • Fonctionnent dans des environnements réglementés ou à fort impact

Une diligence raisonnable renforcée consolide la résilience de l’ensemble de la chaîne d’approvisionnement logicielle.

Vous ne savez pas quel niveau s’applique ? La matrice de décision combine criticité et exposition pour en recommander un. Des modèles couvrant les niveaux 1 à 3 sont disponibles dans les checklists et modèles.

Utiliser la matrice de décision

Surveillance continue et responsabilité sur le cycle de vie

La diligence raisonnable ne s’arrête pas au moment de l’intégration. Des vulnérabilités peuvent être découvertes des années plus tard. Les mainteneurs peuvent changer. Les publications peuvent ralentir. La responsabilité sur le cycle de vie exige une vigilance continue quant à l’évolution des vulnérabilités et à l’état de maintenance des projets.

Les PME devraient

  • Surveiller les divulgations de vulnérabilités affectant les dépendances incluses
  • Suivre les nouvelles versions et les mises à jour de sécurité
  • Tenir à jour leurs SBOM
  • Réévaluer le risque lorsque l’exposition ou l’architecture change

Réévaluer en particulier lorsque

  • De nouvelles fonctionnalités sont ajoutées au produit
  • L’exposition publique augmente
  • Les exigences réglementaires évoluent
  • L’activité de maintenance en amont diminue

Cette approche continue s’inscrit directement dans les obligations de sécurité du CRA relatives au cycle de vie.

Exploiter les attestations de sécurité

Lorsqu’elles existent, les attestations de sécurité volontaires prévues par l’article 25 peuvent étayer une diligence raisonnable structurée. Les attestations peuvent :

  • Fournir des informations standardisées et comparables sur la gouvernance et les pratiques de sécurité
  • Réduire les demandes de conformité répétitives adressées aux mainteneurs
  • Faciliter l’intégration dans les processus internes d’évaluation des risques

L'intégrateur reste responsable

Le recours aux attestations ne supprime pas la responsabilité de l’intégrateur. Les PME doivent évaluer la pertinence des informations attestées au regard de leur propre contexte d’intégration, de leur niveau d’exposition et de l’architecture de leur produit. Les attestations renforcent la transparence mais ne remplacent pas une évaluation des risques en contexte.

Écueils courants et signaux d'alerte

Écueils courants dans l’intégration des FOSS

Les PME se heurtent fréquemment à des difficultés récurrentes :

  • Supposer qu’une large adoption est automatiquement gage de sécurité
  • Ne pas identifier les dépendances indirectes (transitives)
  • Effectuer une validation ponctuelle sans surveillance continue
  • Compter sur les correctifs en amont sans vérifier qu’ils sont effectivement adoptés
  • Intégrer des composants sans documenter les raisons de leur sélection

Reconnaître ces schémas permet aux PME de passer d’une intégration réactive à une gestion structurée des risques.

Signaux d’alerte à surveiller

Indicateurs pouvant suggérer un risque accru :

  • Aucun canal visible de signalement des problèmes de sécurité
  • De longues périodes sans mise à jour ni maintenance
  • Des vulnérabilités critiques non résolues et sans communication
  • Un versionnage ou une documentation des versions incohérents
  • Un manque de clarté sur les responsabilités des mainteneurs
  • De vastes arbres de dépendances peu transparents

Un signal d’alerte n’exclut pas automatiquement un composant. Cependant, la présence de plusieurs indicateurs peut justifier une diligence raisonnable renforcée ou un réexamen de la stratégie d’intégration.

Checklist rapide de diligence raisonnable

Douze questions simples sur la visibilité de base, la connaissance des vulnérabilités, la transparence de la chaîne d’approvisionnement et le cycle de vie. Un point d’entrée accessible et proportionné pour les PME aux ressources limitées.

Ouvrir la checklist

Le parcours des PME vers une adoption des FOSS alignée sur le CRA

Le CRA est fondé sur les risques et orienté cycle de vie. Les PME peuvent adopter une démarche pragmatique en suivant un parcours simple, qui s’adapte à la criticité du produit et aux ressources disponibles.

  1. Démarrer Définir les responsabilités et une visibilité de base

    • Attribuer la responsabilité de : la sélection des dépendances, les mises à jour de sécurité, la surveillance des vulnérabilités et la documentation.
    • Créer un inventaire minimal des principaux composants FOSS utilisés dans le produit.

  2. Délimiter le périmètre Là où les FOSS comptent dans votre produit

    • Identifier les parties du produit qui sont exposées à Internet, traitent des données ou sont sensibles du point de vue de la sécurité.
    • Préciser quels composants sont critiques pour le fonctionnement du produit.

  3. Évaluer le risque Raisonner de manière proportionnée

    • Évaluer chaque composant selon : la criticité, l’exposition et l’impact.
    • Décider du niveau de diligence raisonnable approprié (de base / structurée / renforcée).

  4. Appliquer des contrôles proportionnés Faire ce qui est approprié

    • Pour les composants à faible risque : vérifications de base + SBOM + surveillance.
    • Pour les composants à risque plus élevé : contrôles de gouvernance structurés, publications plus rigoureuses, surveillance renforcée.

  5. Surveiller En continu, et pas une seule fois

    • Suivre les vulnérabilités et les mises à jour en amont.
    • Mettre à jour le SBOM à chaque version (ou au moins à chaque version majeure).
    • Veiller à ce que les mises à jour soient adoptées rapidement.

  6. Réévaluer Quand la situation évolue

    • Le produit devient plus exposé (nouvelles intégrations, exposition à Internet).
    • Des fonctionnalités critiques changent.
    • La maintenance en amont décline.
    • De nouvelles vulnérabilités apparaissent dans des dépendances essentielles.

Ce parcours vise à aider les PME à démontrer une démarche structurée et défendable, même avec des ressources limitées.

Matrice de décision pour la diligence raisonnable des composants FOSS

Pour favoriser des décisions cohérentes et proportionnées, la matrice combine deux dimensions, la criticité fonctionnelle et le niveau d’exposition, et recommande le niveau de diligence raisonnable (L1 / L2 / L3) défini plus haut.

Criticité fonctionnelle Niveau d'exposition InterneUsage isoléLimitéeAccès contrôléPubliqueExposée à Internet
FaibleL1 De baseL1 De baseL2 Structurée
MoyenneL1 De baseL2 StructuréeL3 Renforcée
ÉlevéeL2 StructuréeL3 RenforcéeL3 Renforcée

Comment utiliser cette matrice

  1. Déterminez la criticité fonctionnelle du composant :
    • Assure-t-il des fonctionnalités essentielles ?
    • Gère-t-il l’authentification, le chiffrement ou les mises à jour ?
    • Une défaillance aurait-elle un impact important sur le produit ?
  2. Déterminez le niveau d’exposition :
    • Est-il uniquement interne ?
    • Est-il accessible via des API authentifiées ?
    • Est-il exposé publiquement ?
  3. Repérez l’intersection dans la matrice pour identifier le niveau de diligence raisonnable recommandé.

Points d’attention

  • Cette matrice fournit des orientations, pas une classification rigide.
  • Si l’impact d’une défaillance est exceptionnellement élevé (par exemple, sûreté, environnement réglementé), les PME peuvent choisir d’appliquer un niveau de diligence raisonnable supérieur.
  • La matrice favorise la proportionnalité, en évitant à la fois la sur-ingénierie et la sous-évaluation.

Retour en haut