# Un fichier SECURITY.md pour cadrer la divulgation d’une faille trouvée

> Un canal de contact dédié et un délai annoncé évitent qu'une faille découverte dans une extension finisse publiée avant d'être corrigée.

- Auteur : WordPress Développement
- Publié le : 2023-03-21
- Mis à jour le : 2023-03-21
- Catégorie : Extensions
- URL : https://www.wpmoderne.fr/extensions/fichier-security-md-divulgation-faille/

## L’essentiel

- Un canal de contact clair évite la publication improvisée d'une faille
- Un délai annoncé cadre les attentes des deux parties
- Un historique de versions corrigées rassure les utilisateurs

Aucun canal de signalement identifié contre trois mauvaises options : c'est le choix auquel se retrouve confronté un chercheur en sécurité ou un développeur prudent qui vient de repérer un point d'entrée mal protégé sur une extension WordPress. Faute de contact clair, la personne qui trouve la faille hésite entre ouvrir un ticket public qui expose le problème avant tout correctif, chercher une adresse e-mail générique sur le site de l'éditeur en espérant une réponse, ou publier directement la découverte sur un forum ou un réseau social.

Un fichier `SECURITY.md`, placé à la racine du dépôt de l'extension, répond à cette question avant qu'elle ne se pose. Ce n'est pas un document technique de correction, mais un contrat de confiance minimal entre celui qui trouve une faille et celui qui doit la corriger.

## Ce que ce fichier doit contenir

La checklist suivante couvre les éléments qui rendent un fichier `SECURITY.md` réellement utile, dans l'ordre où un chercheur en sécurité les recherche généralement :

1. **Un canal de contact dédié**, distinct du support technique habituel : une adresse e-mail spécifique comme `securite@nom-extension.fr`, ou un formulaire privé. Jamais un simple ticket public sur le forum de support.
2. **Les versions couvertes** par la politique de sécurité : une extension maintenue sur plusieurs branches majeures doit préciser lesquelles reçoivent encore des correctifs de sécurité.
3. **Un délai de réponse annoncé**, par exemple un accusé de réception sous 48 heures ouvrées, qui rassure la personne qui signale sans l'engager à une confidentialité indéfinie.
4. **Un délai de divulgation coordonnée**, souvent fixé à 90 jours dans l'industrie, au-delà duquel le chercheur est libre de publier ses découvertes même sans correctif, ce qui incite l'éditeur à traiter le signalement avec sérieux.
5. **La méthode de communication du correctif** une fois publié : changelog, avis de sécurité séparé, ou simple mention dans la note de version.

## Un exemple de structure

> L'essentiel à retenir : Un canal de contact clair évite la publication improvisée d'une faille ; Un délai annoncé cadre les attentes des deux parties ; Un historique de versions corrigées rassure les utilisateurs

```
# Politique de sécurité

## Versions supportées

| Version | Support sécurité |
| ------- | ----------------- |
| 3.x     | oui               |
| 2.x     | corrections critiques uniquement |
| 1.x     | non               |

## Signaler une faille

Envoyez un e-mail à securite@nom-extension.fr avec :
- une description du problème,
- les étapes de reproduction,
- l'impact estimé.

Ne créez pas de ticket public tant qu'un correctif n'est pas publié.

## Délais

- Accusé de réception : sous 48 heures ouvrées.
- Premier retour sur la gravité estimée : sous 5 jours ouvrés.
- Divulgation coordonnée : 90 jours, ou dès la publication du correctif.
```

Ce fichier, écrit au format Markdown, s'ajoute simplement à la racine du dépôt Git de l'extension, à côté du `README.md`. Sur une extension hébergée sur GitHub, sa présence active automatiquement un onglet « Security » dans l'interface, qui rend le canal de signalement visible sans effort supplémentaire.

## Pourquoi le délai compte autant que le contact

Un canal de contact sans délai annoncé pousse le chercheur à l'incertitude : combien de temps attendre avant de considérer que le signalement est resté sans suite ? Cette incertitude est la première cause de divulgation prématurée, non par malveillance, mais par lassitude d'attendre une réponse qui ne vient jamais. Annoncer un délai, même généreux, change la dynamique : le chercheur sait quand il peut légitimement relancer ou publier, et l'éditeur dispose d'un cadre pour prioriser le correctif face à d'autres urgences.

Le délai de 90 jours n'est pas une règle universelle imposée par WordPress.org, mais une convention largement reprise dans l'industrie du logiciel, popularisée notamment par les équipes de sécurité de grands éditeurs. Rien n'empêche une petite structure d'annoncer un délai plus court ou plus long, tant qu'il est écrit noir sur blanc et respecté.

## Ce que ce fichier ne remplace pas

- Il ne remplace pas un audit de sécurité du code de l'extension.
- Il ne remplace pas une procédure interne de correction et de test avant publication d'un correctif.
- Il ne dispense pas de tenir un changelog précis mentionnant les versions concernées par un correctif de sécurité, sans nécessairement en détailler l'exploitation.

> Le conseil que je donne systématiquement aux développeurs indépendants qui publient une extension, même modeste : ce fichier prend dix minutes à écrire et évite des semaines de gestion de crise improvisée le jour où une faille est effectivement trouvée.

## En résumé

Un fichier `SECURITY.md` ne corrige aucune faille par lui-même, il organise la relation entre celui qui en trouve une et celui qui doit la traiter. Cadrer cette relation avant qu'un incident survienne coûte peu et évite la pire des issues : une faille publiée avant d'être corrigée, faute d'avoir su à qui la signaler. Ce document n'aborde pas la correction technique d'une faille particulière, qui relève d'un traitement au cas par cas.