Résumé

  • L’index officiel de l’EEF comptait, le 30 octobre, 370 fiches CVE datées de 2026 et neuf de 2025. Le volume publié est environ 41 fois supérieur ; il ne dénombre ni les correctifs ni les failles trouvées par l’IA.
  • À RIPE 93, Alistair Woodman prévoyait plus de 500 CVE en 2026 et a demandé aux entreprises utilisatrices de contribuer au financement de la sécurité des paquets.

Alistair Woodman a terminé son intervention à RIPE 93 par une demande nette aux entreprises qui utilisent Erlang, Elixir et Gleam : financer la sécurité de l’écosystème. Trois jours après sa présentation, le registre public de l’Erlang Ecosystem Foundation affichait 370 fiches datées de 2026. Le chiffre rend visible le travail de divulgation ; il laisse hors champ l’arrivée d’un correctif dans une version du paquet.

À 08 h 59 UTC le 30 octobre, l’index recensait 370 CVE publiées en 2026 et neuf en 2025. Cela représente environ 41 fois plus de fiches. L’index ne précise ni quelle version corrige chaque faille ni combien de temps la vérification a pris. La date de publication du signalement est visible ; celle du retour à une version corrigée ne l’est pas.

Woodman avait donné sa prévision trois jours plus tôt, au groupe de travail Sécurité de RIPE 93. Selon lui, l’EEF couvre plus de 20 000 paquets Elixir, Erlang et Gleam, utilisés régulièrement par environ 100 000 personnes et par au moins 5 000 entreprises connues de la fondation. Il estimait à une dizaine les CVE de l’année précédente et attendait plus de 500 en 2026. Il décrivait une charge de travail multipliée par plus de cinquante. L’index et sa prévision ne comptent pas la même chose : l’un recense des publications, l’autre décrit le travail attendu par l’équipe.

Il a également expliqué que les vulnérabilités existaient déjà et que l’analyse assistée par IA les rendait plus faciles à découvrir. La découverte ne modifie pas le paquet. Un mainteneur doit encore comprendre le rapport, vérifier la faille, corriger le code, publier une version et contrôler le résultat.

Woodman a décrit cinq responsables principaux dans l’activité CNA de l’EEF ; deux personnes assuraient la majeure partie du travail CVE et de la recherche sur l’IA. La fondation teste le regroupement des découvertes par projet afin que les mainteneurs puissent réserver du temps et traiter plusieurs problèmes ensemble. C’est une réponse à un problème de cadence : une découverte peut arriver à toute heure, tandis que le correctif dépend des personnes qui connaissent déjà le code.

La politique publique de l’EEF prévoit un accusé de réception sous deux jours ouvrés, puis une évaluation sous deux jours ouvrés après cet accusé. Pour un signalement non public sur un paquet Hex couvert par la CNA, l’absence de réponse du mainteneur pendant 14 jours permet à l’EEF de poursuivre la publication du CVE. Une divulgation coordonnée peut durer jusqu’à trois mois. Ces délais règlent la réception et la publication ; ils ne donnent pas le temps qui sépare le signalement d’une version corrigée.

L’index public contient l’identifiant, le titre, les détails et les dates de publication ou de mise à jour. Il ne relie pas chaque fiche à la réponse du mainteneur, à une version corrigée et à une date de vérification. Avec ce lien, le nombre de CVE publierait aussi le temps pendant lequel les utilisateurs restent sur une version vulnérable.

Woodman siège au conseil de l’EEF et a demandé aux entreprises qui dépendent de cet écosystème de financer le travail de sécurité. Sa demande touche au partage du coût : les entreprises utilisent les paquets, les mainteneurs absorbent une grande partie du travail après la découverte. Une CVE publiée met le problème sur la table. La version corrigée indique quand le logiciel a changé. Le chiffre suivant devrait suivre cette seconde étape.

Sources : session RIPE 93 ; transcription officielle ; pages de l’EEF sur la CNA, son périmètre, sa politique de sécurité et son index CVE ; conseil de l’EEF.