Due diligence fournisseurs CRA : questionnaire et alertes

La diligence raisonnable sur les composants est une obligation du fabricant au titre de l'article 13, paragraphe 5 du règlement sur la cyberrésilience. Texte intégral :

"Aux fins du respect de l’obligation énoncée au paragraphe 1, les fabricants font preuve de diligence raisonnable lorsqu’ils intègrent dans des produits comportant des éléments numériques des composants obtenus auprès de tiers, de sorte que ces composants ne compromettent pas la cybersécurité du produit comportant des éléments numériques, y compris lors de l’intégration de composants de logiciels libres et ouverts qui n’ont pas été mis à disposition sur le marché dans le cadre d’une activité commerciale."

Cette page est le compagnon opérationnel de l'ensemble des obligations du fabricant. Le cadre réglementaire, la frontière des rôles et les contrôles côté importateur figurent dans les guides du cluster : fabricant, importateur, distributeur et qui est concerné. Ce qui suit, c'est le questionnaire, les playbooks par type de fournisseur que les pages du cluster ne couvrent pas (FOSS, cloud, matériel seul, stewards OSS, firmware COTS modifié) et les scénarios opérationnels qui touchent les équipes dans la vraie vie des achats (fournisseur fantôme, composants amont partagés, retards post-fusion-acquisition, visibilité au-delà du rang 1).

Pourquoi la due diligence fournisseurs compte

Même en tant que fabricant de votre propre produit, votre livrable inclut des composants de fournisseurs : bibliothèques logicielles tierces, composants matériels, modules firmware, services cloud. Les vulnérabilités de ces composants deviennent les vôtres, et votre évaluation de la conformité doit prendre en compte les risques de chaîne d'approvisionnement.

L'article 13, paragraphe 5 rend cette évaluation explicite. Le CRA ne prescrit pas de format de questionnaire, mais un questionnaire écrit est la manière pratique de documenter que vous avez vérifié la sécurité du composant, la gestion des vulnérabilités, la disponibilité du SBOM, les engagements d'assistance et les voies de réponse du fournisseur avant l'intégration. Sans enregistrements datés, vous n'avez aucune histoire à raconter à une autorité de surveillance du marché sur la façon dont le risque au niveau du composant a été traité.

Si votre rôle sur un produit donné est aussi celui d'importateur (vous introduisez sur le marché UE le produit d'un fabricant hors UE), les quatre contrôles préalables au marché de l'importateur constituent un devoir de vérification distinct. Ce guide reste concentré sur la diligence côté fabricant.

Cadre de diligence raisonnable

Approche par niveaux

Tous les fournisseurs n'appellent pas le même niveau de scrutin :

ÉVALUATION DES NIVEAUX DE FOURNISSEURS

NIVEAU 1 (Critique) :
- Composants à fonctions de sécurité (cryptographie, authentification, pare-feu)
- Dépendances logicielles principales
- Matériel avec firmware
Évaluation : questionnaire complet + revue documentaire + surveillance continue

NIVEAU 2 (Significatif) :
- Composants de fonctionnalité majeure
- Éléments connectés au réseau
- Composants de traitement de données
Évaluation : questionnaire standard + revue documentaire

NIVEAU 3 (Standard) :
- Composants hors sécurité
- Bibliothèques utilitaires
- Matériel périphérique
Évaluation : questionnaire basique + vérifications ponctuelles

NIVEAU 4 (Minimal) :
- Composants commodités
- OSS bien établi
- Matériel non connecté
Évaluation : vérification basique + inclusion au SBOM

Domaines d'évaluation

Votre diligence doit couvrir :

Le cadre est générique, mais les preuves que chaque type de fournisseur peut réellement produire varient. Les cinq sections suivantes parcourent les formes de fournisseurs les plus courantes et la voie de diligence qui correspond à chacune.

Diligence spécifique aux fournisseurs FOSS

L'article 13, paragraphe 5 nomme explicitement les composants FOSS : composants de logiciels libres et ouverts qui n'ont pas été mis à disposition sur le marché dans le cadre d'une activité commerciale. L'obligation légale s'applique que de l'argent change de mains ou non. Un questionnaire signé en bonne et due forme par un éditeur commercial n'est pas le modèle quand l'amont est un projet GitHub à trois mainteneurs.

Pour les composants FOSS non commerciaux, l'ensemble des preuves passe des documents attestés par le fournisseur aux signaux observables sur le projet, que vous pouvez collecter vous-même.

LISTE DE CONTRÔLE DILIGENCE COMPOSANT FOSS

SANTÉ DU PROJET :
[ ] Commits actifs sur les 90 derniers jours
[ ] Nombre de contributeurs distincts (>1 = bus-factor allégé)
[ ] Cadence de publication déclarée ou observable
[ ] Suivi des issues réactif (temps médian avant premier commentaire)

POSTURE DE SÉCURITÉ :
[ ] SECURITY.md présent avec adresse de signalement
[ ] Politique CVD (canal privé d'avis de sécurité, pas une simple issue)
[ ] Historique CVE revu (NVD, GitHub Security Advisories, OSV)
[ ] Ingrédients SBOM eux-mêmes identifiables, pas des forks profonds

LICENCE ET PROVENANCE :
[ ] Identifiant SPDX correspond aux métadonnées du paquet
[ ] Pas de dépendance transitive incompatible côté licence
[ ] Artéfacts publiés avec une provenance vérifiable (par ex. SLSA, sigstore)

VOTRE PLAN DE REPLI :
[ ] Cible de fork identifiée si l'amont devient silencieux
[ ] Capacité interne de patch déclarée (quel ingénieur, quel code)
[ ] Candidats de remplacement listés, avec effort de substitution estimé

Deux règles opérationnelles. Premièrement, l'article 13, paragraphe 6 exige que les vulnérabilités que vous trouvez dans un composant FOSS soient signalées au projet amont et que tout correctif que vous produisez soit reversé, dans un format lisible par machine lorsque c'est pertinent. L'élément que vous cochez dans le questionnaire n'est pas l'engagement de l'amont envers vous, c'est votre propre engagement à faire remonter vulnérabilités et correctifs. Deuxièmement, un amont silencieux n'éteint pas votre obligation. Si le projet devient inactif, votre plan de repli (fork, patch interne, remplacement) fait partie de l'enregistrement de diligence, pas d'un problème futur.

Pour les projets soutenus par une fondation ou une entité juridique agissant comme steward de logiciels open source, le schéma de diligence change encore. Ce cas est traité dans la section suivante.

Steward OSS face à fournisseur commercial

Une classe d'amont petite mais importante est dirigée par un steward de logiciels open source : une entité juridique, en général une fondation, dont la finalité principale est de soutenir des projets open source spécifiques destinés à un usage commercial. La Linux Foundation, l'Eclipse Foundation et l'Apache Software Foundation en sont des exemples typiques. Les stewards relèvent de l'article 24, pas de l'article 13. L'ensemble des obligations est plus étroit (politique de cybersécurité documentée, devoir de coopération avec la surveillance du marché, application partielle du signalement d'incidents de l'article 14), et le steward n'est pas le fabricant d'un produit commercial en aval.

Pour la frontière fabricant / steward, voyez stewards open source.

La conséquence pour vous, intégrateur en aval, c'est que la forme du questionnaire change.

Ce que vous continuez de faire : contrôles de santé projet, ingestion du SBOM, surveillance des CVE, votre propre plan de repli fork-and-patch. Ce que vous arrêtez d'attendre : SLA contractuels de notification, paliers d'assistance payants, clauses d'audit. L'enregistrement de diligence pour un composant soutenu par un steward est plus mince côté papier fournisseur et plus dense côté contrôles internes que pour un éditeur commercial, et c'est la forme juridiquement correcte.

Diligence sur les composants de service cloud

Quand le « composant » à l'intérieur de votre produit est une API ou un service managé (un SaaS d'authentification, un broker de messages managé, une fonction serverless, une base de données cloud), le schéma de preuves est encore différent. Pas de DoC, pas de SBOM, pas de code source que vous livrez. Il y a un contrat, un portefeuille d'attestations de sécurité et un modèle de responsabilité partagée.

DILIGENCE COMPOSANT DE SERVICE CLOUD

ATTESTATIONS DE SÉCURITÉ :
[ ] Rapport SOC 2 Type II (en cours)
[ ] Certificat ISO/IEC 27001 (en cours, vérification du périmètre)
[ ] ISO/IEC 27017 (contrôles spécifiques au cloud) si pertinent
[ ] ISO/IEC 27018 (DCP en cloud public) si données personnelles concernées

PREUVES OPÉRATIONNELLES :
[ ] Page d'état avec historique d'incidents et post-mortems
[ ] RTO/RPO publiés et date du dernier test PRA
[ ] Liste des sous-traitants et processus de notification des changements
[ ] Accord de traitement des données avec résidence UE, le cas échéant

RESPONSABILITÉ PARTAGÉE :
[ ] Périmètre de responsabilité du prestataire documenté
[ ] Votre périmètre de responsabilité reconnu (config, identité, secrets, réseau)
[ ] Accès aux journaux et aux pistes d'audit pour votre périmètre

ADJACENT AU CRA :
[ ] Voie de divulgation des vulnérabilités pour l'API elle-même
[ ] Horloge de notification d'atteinte dans le contrat (heures, pas « rapidement »)
[ ] Fenêtre de préavis de discontinuation de service (généralement 12 mois)

Le CRA ne réglemente pas directement le prestataire cloud lorsqu'il ne met pas sur le marché un produit comportant des éléments numériques. Votre obligation au titre de l'article 13, paragraphe 5 est de démontrer que la dépendance cloud ne compromet pas la cybersécurité de votre produit. Le livrable, c'est le portefeuille d'attestations plus une déclaration écrite de responsabilité partagée, pas un questionnaire au format CRA.

Diligence sur les fournisseurs matériel seul et ODM

Quand votre sous-traitant industriel (ODM, EMS, assembleur OEM) livre des cartes physiques et que le firmware est le vôtre, le fournisseur fournit le support matériel mais pas l'enveloppe de sécurité. Le CRA place l'enveloppe de sécurité sur vous, l'entité qui flashe et signe le firmware embarqué sur la carte.

Le questionnaire est ici plus léger sur les questions logicielles et plus dense sur la confiance matérielle et l'intégrité de la chaîne d'approvisionnement.

DILIGENCE MATÉRIEL SEUL / ODM

CONFIANCE MATÉRIELLE :
[ ] BOM avec identification cryptographique des composants
[ ] Contrôles anticontrefaçon (audit de sourcing des composants)
[ ] Source des éléments sécurisés et méthode de pré-provisionnement
[ ] Processus d'injection des clés en usine et piste d'audit

INTÉGRITÉ D'ASSEMBLAGE :
[ ] Système qualité ISO 9001 en place
[ ] Inviolabilité visible appliquée pendant l'assemblage et l'expédition
[ ] Traçabilité par lot/série de l'usine au quai de réception

REMISE DU FIRMWARE :
[ ] Qui signe le firmware : vous, l'ODM, ou les deux
[ ] État de provisionnement au premier démarrage (réglages d'usine, transfert de propriété)
[ ] Chaîne de bootloader et de secure boot, qui possède chaque maillon

APRÈS EXPÉDITION :
[ ] Fenêtre de préavis EOL pour la plateforme matérielle
[ ] Engagement de last-time-buy et durée
[ ] Disponibilité de pièces de rechange pour la période d'assistance que vous engagez

Une erreur opérationnelle courante : signer une période d'assistance pluriannuelle avec un ODM dont la fenêtre EOL matérielle est de 18 mois. L'horloge de la période d'assistance CRA démarre lorsque vous mettez le produit sur le marché UE ; si le silicium sous-jacent passe en EOL à l'intérieur de cette fenêtre, l'obligation d'assistance ne se transfère pas à la tolérance de votre client.

Firmware COTS que vous modifiez

Si vous prenez un produit commercial sur étagère, modifiez le firmware et mettez le résultat sur le marché UE, l'article 22 vous traite comme le fabricant du produit modifié pour la partie touchée par la modification substantielle, ou pour le produit entier si la modification touche l'enveloppe de cybersécurité.

"Une personne physique ou morale, autre que le fabricant, l’importateur ou le distributeur, qui apporte une modification substantielle à un produit comportant des éléments numériques et met ce produit à disposition sur le marché est considérée comme un fabricant aux fins du présent règlement."

La conséquence pour la diligence est lourde : la DoC et l'évaluation de la conformité du fabricant d'origine ne couvrent plus le produit tel que vous le mettez sur le marché. Vous héritez de l'ensemble des obligations du fabricant pour la partie affectée ou pour l'ensemble. Le fournisseur d'origine devient sans pertinence pour le dossier CRA ; votre propre équipe d'ingénierie devient la partie responsable.

L'étape de diligence n'est donc pas un questionnaire au fournisseur d'origine. C'est une évaluation interne de l'impact de la modification. Documentez le périmètre de la modification, décidez si elle est substantielle, et traitez l'ensemble comme un travail de niveau fabricant si la modification touche l'authentification, le chiffrement, la surface réseau ou le mécanisme de mise à jour. Un enregistrement propre indiquant quelle modification a été appliquée à quel lot d'unités est l'artéfact qu'une autorité de surveillance du marché demandera en premier.

Le questionnaire

Utilisez ce questionnaire comme point de départ pour les éditeurs commerciaux de logiciels et les fournisseurs de matériel. Les sections précédentes couvrent les variantes pour FOSS, stewards OSS, API cloud, ODM matériel seul et firmware COTS modifié.

Section 1 : informations sur l'entreprise

QUESTIONNAIRE DE DUE DILIGENCE FOURNISSEUR
Section 1 : informations sur l'entreprise

1.1 Détails de l'entreprise
    Nom de l'entreprise : _________________________________
    Adresse légale : ________________________________
    Pays d'incorporation : _____________________
    Contact principal : _____________________________
    Contact sécurité : ____________________________

1.2 Informations commerciales
    Années d'activité : ___________________________
    Nombre de salariés : _________________________
    Chiffre d'affaires annuel (fourchette) : ______________________

1.3 Représentation UE (si hors UE)
    Nom + adresse du mandataire autorisé dans l'UE : __
    (Pour le détail complet de la cascade mandataire et de
    l'orientation vers l'importateur lorsqu'il n'y a pas
    d'établissement UE, voyez le guide du cluster
    importateur :
    /cra-compliance/importer#if-the-non-eu-manufacturer-has-no-eu-establishment)

1.4 Certifications (joindre copies)
    [ ] ISO 9001 (management de la qualité)
    [ ] ISO 27001 (sécurité de l'information)
    [ ] ISO 27701 (vie privée)
    [ ] SOC 2
    [ ] Autre : _________________________________

Section 2 : conformité produit

Section 2 : conformité produit

2.1 Identification du produit
    Nom/Modèle du produit : __________________________
    Version/Révision : ___________________________
    Catégorie de produit : ___________________________

2.2 Classification CRA
    [ ] Par défaut
    [ ] Important Classe I (Annexe III, Partie I)
    [ ] Important Classe II (Annexe III, Partie II)
    [ ] Critique (Annexe IV)
    [ ] Pas encore classifié

2.3 Évaluation de la conformité
    [ ] Module A (auto-évaluation)
    [ ] Module B+C (examen UE de type)
    [ ] Module H (assurance qualité complète)
    [ ] Pas encore complétée

    Si module B, C ou H :
    Nom de l'organisme notifié : __________________________
    Numéro de certificat : __________________________
    Date du certificat : ____________________________

2.4 Déclaration UE de conformité
    [ ] DoC disponible (joindre copie)
    [ ] DoC pas encore émise
    Date de la DoC : ________________________________

2.5 Marquage CE
    [ ] Marquage CE apposé
    [ ] Marquage CE pas encore apposé
    Si apposé, où sur le produit : _________________

2.6 Documentation technique
    [ ] Dossier technique disponible sur demande
    [ ] SBOM disponible (format : ________________)
    [ ] Documentation d'évaluation des risques disponible
    [ ] Instructions utilisateur/sécurité disponibles

Section 3 : pratiques de sécurité

Section 3 : pratiques de sécurité

3.1 Développement sécurisé
    Suivez-vous un cycle de développement sécurisé ?
    [ ] Oui, décrire : __________________________
    [ ] Non

    Effectuez-vous des tests de sécurité ?
    [ ] Analyse statique (SAST)
    [ ] Analyse dynamique (DAST)
    [ ] Tests de pénétration
    [ ] Tests de fuzzing
    [ ] Autre : _________________________________

    Avez-vous un standard de codage sécurisé ?
    [ ] Oui, lequel : ____________________________
    [ ] Non

3.2 Gestion des composants
    Comment suivez-vous les composants tiers ?
    [ ] SBOM maintenu
    [ ] Outil de suivi des dépendances (nom : _________)
    [ ] Suivi manuel
    [ ] Pas de suivi systématique

    Comment surveillez-vous les vulnérabilités dans les dépendances ?
    [ ] Scan automatisé (outil : _______________)
    [ ] Surveillance manuelle des CVE
    [ ] Dépend des notifications fournisseur
    [ ] Pas de surveillance systématique

3.3 Architecture de sécurité
    Décrivez les principales fonctionnalités de sécurité du produit :
    _____________________________________________

    Quels standards cryptographiques sont utilisés ?
    _____________________________________________

    Comment l'authentification est-elle implémentée ?
    _____________________________________________

    Comment les données sont-elles protégées au repos et en transit ?
    _____________________________________________

Section 4 : gestion des vulnérabilités

Section 4 : gestion des vulnérabilités

4.1 Divulgation des vulnérabilités
    Avez-vous une politique de divulgation coordonnée des vulnérabilités ?
    [ ] Oui, URL : ______________________________
    [ ] Non

    Avez-vous un fichier security.txt ?
    [ ] Oui, URL : ______________________________
    [ ] Non

    Quelle est la méthode de contact sécurité ?
    [ ] E-mail : __________________________________
    [ ] Formulaire web : _______________________________
    [ ] Plateforme bug bounty : ____________________
    [ ] Autre : _________________________________

4.2 Engagements de réponse
    Quel est votre délai d'accusé de réception ?
    [ ] Dans les 24 h
    [ ] Dans les 72 h
    [ ] Dans les 7 jours
    [ ] Pas d'engagement

    Quel est votre délai typique de correctif pour :
    Vulnérabilités critiques : ___________________
    Vulnérabilités hautes : _______________________
    Vulnérabilités moyennes : _____________________

4.3 Signalement ENISA
    Êtes-vous prêt pour le signalement ENISA (sept. 2026) ?
    [ ] Oui, processus établi
    [ ] En cours
    [ ] Non
    [ ] Sans objet (pas fabricant)

4.4 Vulnérabilités historiques
    Combien de vulnérabilités de sécurité ont été signalées
    dans ce produit au cours des 24 derniers mois ? ______

    Comment ont-elles été résolues ?
    [ ] Toutes corrigées dans les délais annoncés
    [ ] Quelques retards (expliquer) : __________________
    [ ] Certaines restent non corrigées (expliquer) : ________

Section 5 : mise à jour et assistance

Section 5 : mise à jour et assistance

5.1 Période d'assistance
    Quelle est la période d'assistance engagée depuis la mise
    sur le marché ?
    [ ] 5 ans (minimum CRA)
    [ ] 7 ans
    [ ] 10 ans
    [ ] Autre : _________________________________
    [ ] Non définie

    Quand ce produit a-t-il été mis sur le marché UE pour la première fois ?
    Date : ______________________________________

    Quand la période d'assistance se termine-t-elle ?
    Date : ______________________________________

5.2 Mécanisme de mise à jour
    Comment les mises à jour de sécurité sont-elles livrées ?
    [ ] Mises à jour automatiques (OTA)
    [ ] Téléchargement manuel depuis portail
    [ ] Support physique
    [ ] Autre : _________________________________

    Les mises à jour de sécurité sont-elles séparées des mises à jour fonctionnelles ?
    [ ] Oui
    [ ] Non, regroupées

    Les utilisateurs peuvent-ils différer ou ignorer les mises à jour ?
    [ ] Oui
    [ ] Non, obligatoires
    [ ] Configurable

5.3 Vérification des mises à jour
    Les mises à jour sont-elles signées ?
    [ ] Oui, méthode : __________________________
    [ ] Non

    Les utilisateurs peuvent-ils vérifier l'authenticité des mises à jour ?
    [ ] Oui, comment : _____________________________
    [ ] Non

5.4 Planification de fin d'assistance
    Avez-vous un processus de fin de vie documenté ?
    [ ] Oui
    [ ] Non

    Comment les clients seront-ils notifiés de la fin de vie ?
    _____________________________________________

    Que se passe-t-il après la fin de la période d'assistance ?
    [ ] Le produit continue de fonctionner
    [ ] Le produit perd des fonctionnalités
    [ ] Le produit nécessite une migration

Section 6 : exigences de documentation

Section 6 : exigences de documentation

6.1 Documentation disponible
    Cochez toute documentation que vous pouvez fournir :

    [ ] Déclaration UE de conformité
    [ ] Dossier technique (ou extraits pertinents)
    [ ] Software Bill of Materials (SBOM)
        Format : [ ] CycloneDX [ ] SPDX [ ] Autre
    [ ] Résumé de l'évaluation des risques
    [ ] Document d'architecture de sécurité
    [ ] Instructions utilisateur (pertinentes pour la sécurité)
    [ ] Politique de divulgation des vulnérabilités
    [ ] Conditions d'assistance/maintenance

6.2 Livraison de documentation
    Comment la documentation sera-t-elle fournie ?
    [ ] Sur demande (délai de réponse : ____________)
    [ ] Via portail sécurisé
    [ ] Livrée avec le produit
    [ ] Autre : _________________________________

6.3 Détails SBOM (si disponible)
    Le SBOM couvre :
    [ ] Dépendances directes uniquement
    [ ] Dépendances transitives incluses
    [ ] Composants matériels (si applicable)

    Fréquence de mise à jour du SBOM :
    [ ] Par version
    [ ] Sur demande
    [ ] Pas de mise à jour systématique

Section 7 : engagements contractuels

Section 7 : engagements contractuels

7.1 Garantie de conformité
    Garantirez-vous la conformité CRA dans le contrat ?
    [ ] Oui
    [ ] Non
    [ ] Négociable

7.2 Conservation de la documentation
    Conserverez-vous la documentation technique pendant 10 ans ?
    [ ] Oui
    [ ] Non
    [ ] Période plus courte : ________________________

7.3 Obligations de notification
    Nous notifierez-vous de :
    [ ] Vulnérabilités de sécurité dans le produit
    [ ] Changements de statut de conformité
    [ ] Décisions de fin d'assistance
    [ ] Changements matériels de l'architecture de sécurité

7.4 Droits d'audit
    Autoriserez-vous des audits de conformité ?
    [ ] Oui, sans restriction
    [ ] Oui, avec préavis
    [ ] Non

7.5 Indemnisation
    Indemniserez-vous pour non-conformité CRA ?
    [ ] Oui
    [ ] Non
    [ ] Négociable

Section 8 : attestation

Section 8 : attestation

J'atteste que les informations fournies dans ce questionnaire
sont exactes et complètes au meilleur de ma connaissance.

Je comprends que [Votre Entreprise] s'appuie sur ces informations
à des fins de conformité CRA et que des déclarations matériellement
fausses peuvent entraîner la résiliation du contrat.

Complété par : _____________________________________
Titre : ___________________________________________
Date : ____________________________________________
Signature : _______________________________________

Signaux d'alerte (avant contrat)

Ces signaux d'alerte sont à capter pendant la revue du questionnaire et la négociation contractuelle, avant qu'un bon de commande ne soit signé. Pour le miroir côté importateur, appliqué au moment de placer le produit d'un fabricant hors UE sur le marché UE, voyez ce qu'il faut refuser et pourquoi sur la page cluster importateur.

Signaux d'alerte critiques (disqualifient la relation)

Signaux d'alerte sérieux (atténuation négociée requise)

Signaux jaunes (à surveiller dans la durée)

Processus de vérification et surveillance

Vérification initiale

1. Collecte des documents

   • Demander copie de la DoC
   • Demander le SBOM (ou confirmation de disponibilité)
   • Demander les informations de contact sécurité
   • Demander l'engagement de période d'assistance

2. Revue des documents

   • Vérifier que la DoC est signée et complète
   • Vérifier que l'identification du produit correspond
   • Vérifier les déclarations de marquage CE
   • Revoir le format et la complétude du SBOM

3. Vérifications ponctuelles de conformité

   • Vérifier que security.txt existe (si accessible sur le web)
   • Vérifier que la politique CVD est publiée
   • Tester que le contact sécurité répond
   • Vérifier les déclarations de période d'assistance dans la documentation

Surveillance continue

CALENDRIER DE SURVEILLANCE FOURNISSEUR

Mensuel :
[ ] Vérifier les avis de sécurité publiés
[ ] Vérifier que le contact sécurité fonctionne toujours
[ ] Revoir toute divulgation de vulnérabilités

Trimestriel :
[ ] Demander un SBOM mis à jour (si versions significatives)
[ ] Vérifier que la politique CVD est toujours accessible
[ ] Vérifier les nouvelles certifications ou les expirations

Annuel :
[ ] Rafraîchissement complet du questionnaire
[ ] Revoir le statut de la période d'assistance
[ ] Vérifier que la documentation est toujours disponible
[ ] Revue de stabilité commerciale

Sur déclencheur :
[ ] Incident de sécurité majeur, revue immédiate
[ ] Changement de propriété, réévaluation complète
[ ] Discontinuation produit, planification fin de vie
[ ] Renouvellement de contrat, re-vérification de conformité

Quand un fournisseur ne répond pas

L'échec opérationnel le plus courant en diligence fournisseur n'est pas une réponse ratée au questionnaire : c'est l'absence de toute réponse. Le fournisseur fait le mort, traîne pendant des mois, ou envoie une réponse d'une ligne du type « nous respectons toutes les réglementations applicables ». Il n'y a pas de sanction statutaire contre le fournisseur (il n'a pas d'obligation CRA de répondre à votre questionnaire), donc le flux d'escalade doit être commercial et procédural.

ESCALADE NON-RÉPONSE FOURNISSEUR

SEMAINE 1 : envoi initial du questionnaire
            Fenêtre de réponse raisonnable : 15 jours ouvrés pour le
            niveau 1, 30 pour le niveau 2, 45 pour les niveaux 3-4.

SEMAINE 3 : première relance au contact sécurité nommé et au contact
            commercial principal. En copie le responsable achats.

SEMAINE 5 : escalade vers l'account executive du fournisseur et vers
            votre propre directeur des achats. Fixer une date ferme.

SEMAINE 7 : si toujours pas de réponse de fond :
            a) Documenter la non-réponse dans le dossier fournisseur
            b) Marquer le composant « conformité non vérifiée »
            c) Déclencher l'évaluation d'un fournisseur de remplacement
            d) Avertir les responsables produit dépendant du composant

SEMAINE 9 : porte de décision.
            Réponse de fond reçue, passer à la revue.
            Pas de réponse, basculer vers le fournisseur de remplacement
            et documenter le basculement comme une décision motivée par
            le CRA.

La non-réponse est elle-même une preuve de diligence. Une autorité de surveillance du marché qui vous demande pourquoi vous avez écarté un fournisseur acceptera bien plus facilement une piste d'escalade datée et une décision de basculement qu'un vague « ils étaient difficiles à travailler ». L'artéfact que vous conservez, c'est le journal d'escalade daté plus la note de décision.

Composants amont partagés et vetting coordonné

Quand plusieurs fabricants intègrent le même composant amont (une bibliothèque cryptographique largement utilisée, un SDK courant de traitement d'image, un OS embarqué populaire), chaque fabricant en aval porte sa propre obligation au titre de l'article 13, paragraphe 5. L'obligation ne se transfère pas au pair le plus diligent, et « tout le monde l'utilise » n'est pas une défense.

Il existe deux schémas de coordination qui réduisent les doublons sans déporter l'obligation :

L'enregistrement de diligence doit nommer explicitement la source de vetting partagée : « rapport de revue de [groupe de travail], daté du [X], revu et accepté le [Y], écarts suivis dans [système] ». Un copier-coller depuis le dossier de diligence d'un pair ne remplace pas votre propre note de décision.

Après une fusion-acquisition : relations fournisseurs héritées

Quand votre entreprise en acquiert une autre, vous récupérez aussi sa liste de fournisseurs. Une réalité post-fusion courante, c'est des dizaines voire des centaines de relations fournisseurs sans aucun enregistrement de diligence au format CRA. Le travail ne se fait pas en une nuit, mais un triage est atteignable en un trimestre.

TRIAGE FOURNISSEURS POST-FUSION (90 JOURS)

JOUR 1-15 : inventaire
[ ] Extraire la liste fournisseurs de l'ERP / système achats de l'entité acquise
[ ] Croiser avec les BOM produits courants
[ ] Identifier quels fournisseurs alimentent les produits dans le périmètre CRA
[ ] Sortir du triage actif les fournisseurs hors périmètre

JOUR 15-30 : hiérarchisation
[ ] Appliquer votre modèle de niveaux à la liste héritée
[ ] Marquer les fournisseurs sans enregistrement de diligence existant
[ ] Signaler ceux dont les produits relèvent de l'Important Classe II ou du Critique

JOUR 30-60 : questionnaires niveau 1
[ ] Envoyer le questionnaire à chaque fournisseur niveau 1 sans dossier
[ ] Renvoyer à tout fournisseur niveau 1 dont le dossier a plus de 24 mois
[ ] Capturer les réponses de façon centralisée

JOUR 60-90 : porte de décision
[ ] Fournisseurs niveau 1 avec réponses satisfaisantes, intégrés
[ ] Fournisseurs niveau 1 avec signaux d'alerte, plan d'atténuation ou remplacement
[ ] Fournisseurs niveau 2/3, programmés dans le cycle annuel standard

EN CONTINU :
[ ] Intégrer les fournisseurs hérités dans votre calendrier de surveillance normal
[ ] Marquer dans le dossier l'origine acquise-par-fusion pour audit

Le CRA n'accorde pas de période de grâce en cas de fusion-acquisition ; l'entité acquéreuse hérite de l'obligation du fabricant à la date de clôture de l'acquisition, sur les composants actuellement présents dans les produits expédiés. Le triage ci-dessus est le compromis pratique : démontrer qu'un programme de diligence défendable tourne, même si le dossier complet est en cours de reconstitution.

Visibilité sur la sous-traitance au-delà du rang 1

Votre fournisseur de rang 1 peut lui-même sous-traiter à un fournisseur de rang 2, qui à son tour intègre des composants d'un amont de rang 3. L'obligation CRA est la vôtre, quel que soit le rang où la vulnérabilité prend sa source. La visibilité pratique, en revanche, s'épuise vite au-delà du rang 1.

Trois contrôles concrets qui achètent une vraie visibilité multi-rang :

• Clause SBOM transitif. Le contrat exige que le SBOM du fournisseur inclue les dépendances transitives, pas seulement les dépendances directes. Un SBOM direct seul cache presque toute la surface de risque réelle.
• Liste de sous-traitants. Le contrat exige que le fournisseur divulgue et tienne à jour la liste des sous-traitants nommés qui touchent à des parties sensibles du composant. La clause ne vous donne pas de veto, mais elle vous donne de la visibilité.
• Passage de vulnérabilité. Le contrat exige que le fournisseur fasse remonter les vulnérabilités découvertes dans des composants intégrés de manière transitive avec le même délai que celles du code développé en direct.

Sans SBOM transitif, vous ne pouvez pas faire tourner des scans d'arbre de dépendances contre le composant, et vous ne pouvez pas démontrer à une autorité de surveillance du marché que le risque multi-rang a été évalué. Sans liste de sous-traitants, un changement de sous-traitant amont (avec sa propre provenance, ses propres contrôles, son propre bus-factor) vous est invisible. Sans passage de vulnérabilité, le silence du fournisseur rang 1 sur un problème rang 2 devient votre silence sur un incident de sécurité.

Clauses d'accord fournisseur

Incluez ces dispositions dans les contrats fournisseurs. Chaque clause est le crochet contractuel d'un des résultats de diligence ci-dessus.

Déclaration de conformité :

Le Fournisseur déclare et garantit que le(s) Produit(s)
sont conformes au Règlement (UE) 2024/2847 (Cyber Resilience
Act) et que le Fournisseur a complété l'évaluation de la
conformité requise.

Fourniture de documentation :

Le Fournisseur fournira sur demande :
(a) Copie de la Déclaration UE de conformité
(b) Software Bill of Materials au format [CycloneDX/SPDX],
    incluant les dépendances transitives
(c) Documentation technique pertinente pour les
    obligations de conformité de l'Acheteur
Délai de réponse : [5 jours ouvrés]

Notification de vulnérabilités :

Le Fournisseur notifiera l'Acheteur dans les [24/48] heures
suivant la prise de connaissance de toute vulnérabilité de
sécurité dans le(s) Produit(s) ou dans tout composant
intégré de manière transitive qui :
(a) Est activement exploitée, ou
(b) A un score CVSS de 7,0 ou plus, ou
(c) Fait l'objet d'une divulgation publique

Engagement de période d'assistance :

Le Fournisseur s'engage à fournir des mises à jour de
sécurité pour le(s) Produit(s) pendant une période minimale
de [5/7/10] ans à compter de la date de première mise sur
le marché dans l'UE.

Mises à jour SBOM :

Le Fournisseur fournira un SBOM mis à jour dans les [10]
jours ouvrés suivant chaque version produit incluant des
changements aux composants tiers directs ou transitifs.

Droits d'audit :

L'Acheteur peut auditer la conformité du Fournisseur avec
cet Accord et les exigences CRA applicables moyennant un
préavis écrit de [30 jours], pas plus d'une fois par an
sauf si déclenché par un problème de conformité.

Divulgation des sous-traitants :

Le Fournisseur maintiendra et fournira sur demande une liste
des sous-traitants qui contribuent à ou ont accès à des
composants sensibles du/des Produit(s). Le Fournisseur
notifiera l'Acheteur de tout changement matériel de cette
liste dans les [30] jours.

Erreurs courantes

Se fier à l'auto-attestation

Problème : accepter les assurances verbales du fournisseur sans documentation.

Correction : toujours obtenir des preuves écrites. Pas de copie DoC, pas d'achat. Un questionnaire signé est le plancher, pas le plafond.

Évaluation ponctuelle

Problème : diligence à la signature du contrat uniquement.

Correction : mettez en place le calendrier de surveillance ci-dessus. L'état de conformité change ; les questionnaires expirent.

Ignorer les fournisseurs de niveau 3-4

Problème : n'évaluer que les fournisseurs « majeurs » et ignorer les plus petits.

Correction : même les composants mineurs introduisent des vulnérabilités (la leçon log4j). Adaptez l'évaluation à l'échelle, ne sautez pas le niveau.

Pas d'appui contractuel

Problème : se fier à la bonne volonté du fournisseur sans clauses contractuelles.

Correction : mettez les obligations de conformité par écrit. Les clauses ci-dessus sont le plancher.

Attendre décembre 2027

Problème : lancer les évaluations fournisseurs juste avant la date d'application du CRA.

Correction : commencez maintenant. Les réponses fournisseurs traînent. Les fournisseurs non conformes mettent des mois à se remettre en conformité ou à être remplacés.

Liste de contrôle due diligence fournisseur

LISTE DE CONTRÔLE DUE DILIGENCE FOURNISSEUR

PRÉ-ENGAGEMENT :
[ ] Niveau du fournisseur déterminé (1/2/3/4)
[ ] Type de fournisseur déterminé (commercial, FOSS, steward
    OSS, cloud, matériel seul, COTS modifié)
[ ] Variante de questionnaire appropriée sélectionnée
[ ] Réviseur interne assigné

ÉVALUATION INITIALE :
[ ] Questionnaire envoyé
[ ] Questionnaire reçu et revu
[ ] Signaux d'alerte identifiés et traités
[ ] Documentation collectée :
    [ ] Déclaration UE de conformité (ou raison Sans objet)
    [ ] SBOM avec dépendances transitives (ou disponibilité confirmée)
    [ ] Politique CVD
    [ ] Engagement de période d'assistance
[ ] Vérifications ponctuelles complétées :
    [ ] security.txt vérifié
    [ ] Contact sécurité testé
    [ ] Marquage CE vérifié

NÉGOCIATION CONTRAT :
[ ] Clauses de conformité incluses
[ ] Dispositions documentation convenues
[ ] Termes notification vulnérabilités fixés (heures, pas « rapidement »)
[ ] Engagement période d'assistance sécurisé
[ ] Droits d'audit inclus
[ ] Calendrier de mise à jour SBOM convenu
[ ] Clause de divulgation des sous-traitants incluse

POST-CONTRAT :
[ ] Calendrier de surveillance établi
[ ] Première livraison documentation confirmée
[ ] Contacts enregistrés dans le système de gestion fournisseurs
[ ] Dates de revue calendrisées

EN CONTINU :
[ ] Vérifications mensuelles complétées
[ ] Revues trimestrielles complétées
[ ] Réévaluation annuelle complétée
[ ] Événements déclencheurs traités (incident, changement de propriété, EOL)

Guides connexes

• Comment générer un SBOM conforme au CRA : outils, formats et intégration CI/CD
• Le guide du fabricant CRA
• Liste de contrôle du distributeur CRA

Cet article est fourni à titre informatif uniquement et ne constitue pas un conseil juridique. Pour des conseils de conformité spécifiques, consultez un conseiller juridique qualifié.