Politique de divulgation des vulnérabilités

En bref

Cette page présente la politique de divulgation coordonnée des vulnérabilités de NextPDF. Elle explique à la personne qui signale comment joindre les mainteneurs en privé, quel délai de réponse attendre et comment fonctionne l’embargo.

Limite. Une politique de divulgation est un engagement de processus, pas une garantie de délai ni de résultat. Les objectifs ci-dessous sont des engagements pris de bonne foi par les mainteneurs envers les personnes qui signalent ; ils décrivent le processus suivi par le projet, et non une promesse contractuelle selon laquelle un signalement donné fera l’objet d’un accusé de réception, d’un triage, d’un correctif ou d’une divulgation à une date précise. Le calendrier de divulgation coordonnée se négocie ; il n’est pas garanti unilatéralement.

Installation

Sans objet. Signaler une vulnérabilité n’exige aucune installation. La surface de contact lisible par machine est publiée à l’adresse /.well-known/security.txt (RFC 9116). La politique lisible par un humain qui fait foi est le fichier SECURITY.md du dépôt.

Vue d’ensemble conceptuelle

La politique met en œuvre la divulgation coordonnée des vulnérabilités au sens d’ISO/IEC 29147 et le processus de traitement d’ISO/IEC 30111 (iso_iec_30111#x9.x43.p2) : réception privée, triage et évaluation de la gravité, remédiation sous embargo, puis publication publique conjointe. Lorsqu’une vulnérabilité touche plusieurs fournisseurs, le calendrier de publication de l’avis est coordonné entre les parties concernées plutôt que fixé unilatéralement (iso_iec_29147#x3.x110.p13).

Le processus est également aligné sur les obligations de traitement des vulnérabilités imposées aux fabricants par le règlement européen sur la cyberrésilience (eu_cra#x1.p191) et sur la pratique « répondre aux vulnérabilités » du cadre de développement logiciel sécurisé du NIST (nist_sp_800_218#x15). Dans les deux cas, il s’agit de devoirs de processus reproductibles, et non de la garantie d’un résultat individuel donné.

Surface d’API

Sans objet. La divulgation est un processus, pas une API. La surface de découverte lisible par machine est le fichier RFC 9116 security.txt ; les outils en analysent les champs Contact: et Expires:. Cette page ne reproduit pas son contenu, en dehors des canaux ci-dessous.

Exemple de code — Démarrage rapide

Sans objet. Il n’y a aucun code à exécuter pour signaler une vulnérabilité. Utilise un canal privé :

• GitHub Security Advisories (canal préféré — chiffrement au repos, journal d’audit) : ouvre un avis en brouillon dans l’onglet GitHub Security du projet.
• E-mail : écris à [email protected] avec [SECURITY] dans l’objet. Si tu as besoin d’un chiffrement de bout en bout et qu’aucune clé OpenPGP publiée n’est encore listée dans security.txt, utilise plutôt le canal GitHub Security Advisory.

Ne signale pas via des tickets publics, des listes de diffusion publiques, les réseaux sociaux ou la messagerie instantanée. Une divulgation publique avant la disponibilité d’un correctif met en danger les utilisateurs de versions non corrigées.

Exemple de code — Production

Sans objet.

Cas limites & pièges

• Les objectifs sont des engagements, pas des SLA. Le calendrier ci-dessous indique ce que le projet vise. Un problème complexe à composants multiples ou nécessitant une coordination en amont peut prendre plus de temps ; la personne qui signale est tenue informée.
• La durée de l’embargo est négociable, avec un plafond. L’embargo par défaut court du triage à la publication du correctif. Une personne qui signale et qui a besoin de plus de temps doit le demander explicitement à l’ouverture de l’avis. Une fois le maximum atteint, le projet publiera l’avis, qu’un correctif soit disponible ou non, conformément aux normes de divulgation coordonnée du secteur — cela évite qu’un avis soit retenu indéfiniment.
• La gravité dicte le calendrier. Un problème critique, activement exploité, est traité selon un calendrier resserré ; une suggestion de renforcement de faible gravité ne suit pas ce calendrier. La gravité est évaluée lors du triage et peut être révisée.
• L’attribution d’un CVE fait partie du triage. Le mainteneur demande un CVE via l’inscription CNA du projet auprès de GitHub Security Advisory pendant l’étape de triage ; la personne qui signale n’a pas besoin d’en demander un séparément.

Performances

Sans objet.

Notes de sécurité

Les objectifs de délai de réponse sont des engagements envers les personnes qui signalent et constituent la base de référence du projet pour le traitement des vulnérabilités. Ce sont des objectifs, pas des garanties :

Étape	Objectif
Accuser réception	dans un délai de 1 à 2 jours ouvrés
Triage initial + évaluation de la gravité	dans un délai d’environ 5 jours ouvrés / 7 jours calendaires
Développement du correctif + revue privée	généralement 14 jours ouvrés ; 30 à 90 jours pour les CVE confirmés complexes selon la gravité
Attribution d’un CVE (si accepté)	en parallèle du correctif, via le canal CNA de GitHub
Divulgation publique coordonnée	à la publication du correctif, à une date fixée conjointement avec la personne qui signale
Embargo (du triage à la publication)	environ 90 jours par défaut, réduit en cas d’exploitation active, prolongeable sur demande explicite jusqu’à un maximum fixe

Règles de processus vérifiables par un relecteur :

1. Le privé d’abord. Aucun canal public n’est accepté pour la réception. Les seuls canaux acceptés sont le GitHub Security Advisory et l’e-mail de sécurité.
2. Coordonné, pas unilatéral. Le calendrier de divulgation est négocié avec la personne qui signale et tout fournisseur également concerné (iso_iec_29147#x3.x110.p13).
3. Embargo borné. L’embargo a une valeur par défaut et un plafond strict ; un avis n’est pas retenu indéfiniment.
4. Crédit sur demande. Les chercheurs sont crédités une fois l’embargo levé, sauf s’ils demandent l’anonymat.

Ces déclarations décrivent le processus que le projet s’engage à suivre. Elles ne garantissent pas qu’un signalement donné donnera lieu à un correctif, à un CVE ou à une divulgation à une date particulière.

Conformité

Ce n’est pas un profil de conformité. La politique est alignée sur ISO/IEC 29147 et ISO/IEC 30111, ainsi que sur les devoirs de processus du CRA et du SSDF cités plus haut ; « alignée sur » est une formulation délibérée — le projet ne revendique aucune certification au titre de l’un de ces référentiels. Ils définissent ce qui caractérise un processus solide ; cette page documente l’engagement du projet à en faire fonctionner un.

Voir aussi

• Centre de confiance
• Modèle de menace du moteur
• Modèle de sécurité des signatures et du chiffrement
• Fichiers SECURITY.md et /.well-known/security.txt du dépôt (RFC 9116)