Sécurité
CWE : Common Weakness Enumeration. « Énumération des faiblesses communes », par analogie avec la nomenclature des malfaçons d'un expert du bâtiment : infiltration, fissure, défaut d'étanchéité, sans désigner aucune maison en particulier. Le catalogue, maintenu par MITRE, recense les types d'erreurs de conception ou de code qui ouvrent la porte aux vulnérabilités.
Faiblesse, pas vulnérabilité : Une CWE décrit une classe de défaut (CWE-89 pour l'injection SQL, CWE-79 pour le cross-site scripting). Une CVE désigne une faille précise dans un produit précis, et son enregistrement indique en général la CWE dont elle relève.
Une hiérarchie à plusieurs niveaux : Les entrées, plus de neuf cents actives, vont du général au particulier : des piliers et des classes abstraites jusqu'aux variantes liées à un langage ou à une technologie. Pour classer un défaut, on choisit l'entrée la plus spécifique qui s'applique, ce qui laisse deux outils en retenir deux différentes pour le même défaut sans qu'aucun ait tort.
Le retour d'expérience : Classer chaque dossier clos par CWE montre quelles erreurs reviennent et où porter les tests, la revue de code et la formation. Un PSIRT qui compte ses CVE sans regarder leurs CWE soigne les symptômes un par un.
Le Top 25 : MITRE publie chaque année, avec la CISA, la liste des 25 faiblesses les plus dangereuses, calculée à partir des CVE publiées. Vingt ans d'audits apprennent que l'injection et le débordement de mémoire y reviennent avec la régularité d'un marronnier de rentrée, malgré les solutions publiées depuis des décennies.
Ce qui arrive si on s'en passe
Sans référence aux CWE, chaque défaut trouvé reste un cas isolé : une injection SQL corrigée dans un formulaire ne signale pas les autres requêtes construites de la même façon, et la même classe d'erreur revient d'une version à l'autre. Les résultats des outils d'analyse statique, des tests d'intrusion et des avis de vulnérabilité n'ont plus d'identifiant commun. Il devient alors impossible de les recouper, de compter les faiblesses par type ou de vérifier qu'une catégorie entière (CWE-79, CWE-89, CWE-798) a été traitée. La revue de code perd sa grille de lecture et les priorités se fixent au cas par cas. Le motif récurrent reste en place : il suffit à l'attaquant de le chercher ailleurs dans le code pour retrouver une porte ouverte.
Explication de la marmotte
Imagine un grand carnet qui range les erreurs que font les gens quand ils fabriquent des programmes. Il ne parle pas d'un programme en particulier, mais des types d'erreurs : oublier de vérifier ce que tape l'utilisateur, laisser une porte de secours sans serrure, ranger un mot de passe en clair. Chaque type d'erreur porte un numéro. Quand une entreprise découvre un défaut dans son logiciel, elle note le numéro correspondant. Avec le temps, elle voit quelles erreurs reviennent souvent et sait quoi surveiller en priorité, un peu comme un professeur qui repère les fautes d'orthographe préférées de sa classe.
Où ce terme est utilisé
- CWE Top 25 2025 : les vingt-cinq faiblesses logicielles les plus dangereuses (17 occurrences)
- Référentiels & catalogues (11 occurrences)
- CWE-284 : contrôle d'accès défaillant, le pilier venu de l'OWASP (6 occurrences)
- CWE-20 : validation des entrées insuffisante, la classe que le MITRE déconseille (4 occurrences)
- CWE-89 : injection SQL, la classe de la requête concaténée (4 occurrences)
- CWE-120 : débordement de tampon classique, la copie sans mesure (3 occurrences)
- CWE-121 : débordement de tampon dans la pile (3 occurrences)
- CWE-122 : débordement de tampon dans le tas (3 occurrences)
- CWE-125 : lecture hors limites, la fuite qui ne casse rien (3 occurrences)
- CWE-200 : exposition d'information sensible, un impact pris pour une cause (3 occurrences)
