Le Cyber Resilience Act exige des éditeurs un programme de divulgation de vulnérabilités (VDP — Vulnerability Disclosure Program) opérationnel à partir du 11 septembre 2026. Ce qui semble basique cache plusieurs exigences précises souvent omises. Voici comment monter un programme conforme, sans complexité inutile.
Ce que demande le CRA
D'après l'article 13 du règlement et les standards complémentaires :
- Canal de signalement : un moyen accessible de signaler une vulnérabilité.
- Procédure de triage : analyse et priorisation des signalements.
- Coordination avec la personne qui signale (chercheur, client, citoyen).
- Correction dans des délais raisonnables.
- Communication des correctifs aux utilisateurs.
- Notification ENISA dans les 24h pour les vulnérabilités activement exploitées.
- Notification ENISA dans les 72h pour les incidents significatifs liés.
Le canal de signalement
security.txt (RFC 9116) — incontournable
Standard pour publier les informations de contact sécurité :
``` # https://yourapp.example/.well-known/security.txt
Contact: mailto:security@yourapp.example Contact: https://yourapp.example/security/report Expires: 2027-01-01T00:00:00.000Z Encryption: https://yourapp.example/.well-known/security.asc Acknowledgments: https://yourapp.example/security/hall-of-fame Preferred-Languages: fr, en Canonical: https://yourapp.example/.well-known/security.txt Policy: https://yourapp.example/security/policy Hiring: https://yourapp.example/jobs/security ```
À déposer à la racine de votre site : /.well-known/security.txt (et /security.txt en redirect).
Signé optionnellement avec PGP/GPG pour les signalements sensibles.
Email security@
Boîte mail dédiée, monitorée par une équipe sécurité. Pas un alias qui finit en spam.
Formulaire web
Page dédiée avec formulaire structuré qui demande :
- Description de la vulnérabilité.
- Étapes de reproduction.
- Impact potentiel.
- Identité du chercheur (optionnel).
- Souhait de divulgation (responsible disclosure ou public).
Chiffrement
Pour les vulnérabilités hautement sensibles, le chercheur peut souhaiter chiffrer son rapport. Publier votre clé PGP/GPG dans .well-known/security.asc.
La procédure de triage
Étape 1 — Réception
Notification à l'équipe sécurité dans l'heure (idéalement temps réel via webhook/Slack).
Étape 2 — Acknowledgment
Réponse au chercheur dans les 48 heures (jour ouvré). Format type :
Bonjour [nom],
Nous avons bien reçu votre signalement de vulnérabilité concernant [composant]. Nous l'analysons en priorité. Vous pouvez nous suivre via [ticket interne ID].
Cordialement, [nom]
Étape 3 — Validation
Reproduction de la vulnérabilité par l'équipe. Détermination de :
- Validité : est-ce une vraie vulnérabilité ?
- Criticité : score CVSS 3.1 ou équivalent.
- Périmètre : quelle version, quels environnements affectés ?
- Exploitabilité : conditions de déclenchement, complexité.
Étape 4 — Décision
- Critical : remédiation prioritaire, déploiement urgent.
- High : remédiation dans 30 jours.
- Medium : remédiation dans 90 jours.
- Low/info : roadmap normale.
Étape 5 — Coordination avec le chercheur
- Confirmation de la réception et de la validité.
- Estimation du délai de correction.
- Discussion du calendrier de divulgation publique (responsible disclosure standard : 90 jours).
Étape 6 — Correction
Développement, test, déploiement.
Étape 7 — Communication aux utilisateurs
Pour les CVE significatifs :
- CVE assigné (via votre CNA ou MITRE).
- Notice publique sur votre page security advisories.
- Communication ciblée aux clients impactés.
- Crédit au chercheur si souhaité.
Étape 8 — Notification ENISA (si critique)
Pour les vulnérabilités activement exploitées : notification ENISA dans les 24 heures.
Pour les incidents significatifs déclenchés par la vulnérabilité : notifications dans les 24h / 72h / 1 mois selon timeline NIS2-DORA-CRA.
Bug bounty vs VDP
VDP (Vulnerability Disclosure Program)
- Pas de récompense financière (sauf hall of fame, swag).
- Ouvert à tous.
- Périmètre généralement large.
- Coût opérationnel modeste.
- Suffisant pour conformité CRA.
Bug bounty
- Récompenses financières variables ($100 à $50k+ selon criticité).
- Souvent privé (chercheurs sélectionnés) ou public (HackerOne, Bugcrowd, YesWeHack).
- Périmètre précisé strictement.
- Coût opérationnel plus élevé.
- Génère plus de signal mais aussi plus de bruit.
Recommandation : pour démarrer, VDP suffit. Si vous voulez accélérer la découverte de vulnérabilités, bug bounty privé sur invitation après 6-12 mois de VDP.
Templates de policy
Votre page /security/policy doit contenir :
Périmètre
Quels actifs sont dans le scope ? Quels actifs sont hors scope (ex: services tiers, environnements de test) ?
Règles d'engagement
- Pas de DoS.
- Pas d'accès à des données autres que les vôtres.
- Pas de phishing du staff.
- Respect des utilisateurs.
Engagement de l'éditeur
- Délai de réponse.
- Pas de poursuite légale si conditions respectées.
- Crédit public possible.
- Coordination de divulgation.
Hall of fame
Liste des chercheurs ayant contribué (avec leur accord).
Le hall of fame — sous-estimé
Reconnaissance publique des chercheurs qui contribuent. Quelques noms et la date de leur contribution. Coût : zéro. Bénéfice : motive des chercheurs sérieux à signaler chez vous plutôt que de vendre la vulnérabilité ailleurs.
Articulation avec les acteurs
Avec ENISA
ENISA met en place une plateforme de signalement coordonnée. À partir de 2026, votre programme doit pouvoir notifier ENISA dans les délais.
Avec CERT-FR / ANSSI
Pour les acteurs français, CERT-FR coordonne sur les vulnérabilités significatives. Maintenir un contact établi.
Avec MITRE
Devenir CNA (CVE Numbering Authority) si vous gérez beaucoup de CVE. Sinon, demander des CVE via votre CSIRT national.
Ressources humaines
Pour une scale-up européenne :
- Phase initiale (peu de signalements) : 0.2-0.5 ETP.
- Mature : 1-2 ETP dédiés au programme + équipe dev impliquée pour les corrections.
Le mix typique : un PM sécurité + un dev sénior pour les corrections + l'équipe dev pour les implémentations.
Mesurer le programme
KPIs à tracker :
- Volume de signalements : croissance attendue, signe de maturité du programme.
- MTTR triage : temps entre réception et validation.
- MTTR correction par criticité.
- Taux de signalements valides (vs duplicates, false positives).
- Satisfaction des chercheurs (peuvent partager publiquement).
Le piège — VDP "boîte mail"
Certaines organisations annoncent "envoyez à security@" sans process derrière. Résultat : signalements traités quelques semaines/mois plus tard, chercheurs frustrés, image dégradée, et non-conformité CRA parce que les délais ne sont pas tenus.
Posture saine : un programme léger mais opérationnel dès le démarrage > un programme ambitieux qui ne fonctionne pas.
