06.10.2026 · Signal Titans Editorial
GitHub introduit des formulaires structurés pour réduire les signalements de vulnérabilités de faible qualité
GitHub propose des formulaires structurés personnalisables pour les rapports privés de vulnérabilité afin d'aider les mainteneurs à filtrer les signalements.

GitHub a lancé des formulaires structurés pour le signalement privé de vulnérabilités afin d'aider les mainteneurs de dépôts à filtrer les soumissions de faible qualité et générées par IA. Par défaut, le système remplace la zone de texte libre unique par des champs de saisie standardisés, garantissant que les chercheurs en sécurité fournissent un contexte exploitable avant de soumettre un rapport.
Exigences de soumission standardisées
Le formulaire de signalement de vulnérabilité par défaut exige que les divulgations contiennent quatre champs spécifiques : un résumé, des détails techniques, une preuve de concept d'au moins 150 caractères et une évaluation de l'impact sur la sécurité. GitHub consolide directement ces réponses dans la description de l'avis de sécurité, conservant ainsi le flux de travail de révision et d'édition existant pour les mainteneurs.
Pour faire face à l'augmentation des soumissions automatisées, le formulaire intègre une case à cocher de divulgation dédiée où les rapporteurs peuvent indiquer s'ils ont utilisé des outils d'IA pour découvrir ou rédiger l'avis.
Options de personnalisation et d'application par dépôt
Les mainteneurs peuvent mettre en œuvre des formulaires de signalement personnalisés en créant un fichier `.github/VULNERABILITY_REPORT.yml` dans la branche par défaut d'un dépôt ou à l'échelle d'une organisation via son dépôt `.github` central. Les formulaires reposent sur la syntaxe des formulaires de tickets de GitHub et permettent aux mainteneurs de configurer des exigences de longueur de caractères. Si une configuration de formulaire personnalisé contient des erreurs, GitHub bascule automatiquement sur le formulaire par défaut.
Les administrateurs peuvent également obliger les rapporteurs à sélectionner une classification CWE (Common Weakness Enumeration) avant toute soumission en passant par les paramètres de sécurité du dépôt. Les administrateurs d'organisations et d'entreprises peuvent appliquer cette exigence CWE de manière universelle sur tous leurs dépôts grâce à des politiques d'organisation.
Intégration API et disponibilité selon les abonnements
Les formulaires personnalisés affectent les soumissions programmatiques via l'API REST de GitHub. Bien que les intégrations d'API existantes continuent de fonctionner avec le formulaire par défaut sans contrainte d'application, les rapports soumis par API à des dépôts disposant de formulaires personnalisés doivent se conformer aux champs définis. Lorsqu'une soumission d'API échoue à la validation, GitHub renvoie un message d'erreur indiquant un nouveau point de terminaison qui détaille le schéma du formulaire actif du dépôt.
Si un dépôt inclut un fichier `SECURITY.md` standard, GitHub affiche une bannière bien visible renvoyant vers cette politique avant qu'un chercheur ne soumette une divulgation. Cette fonctionnalité est disponible pour les dépôts publics ayant activé le signalement privé de vulnérabilités sur les abonnements GitHub Free, GitHub Pro, GitHub Team et GitHub Enterprise Cloud.
Illustration éditoriale générée par IA ; ce n’est pas une photographie documentaire.