Rapport de sécurité
Pour plus de détails sur les politiques de sécurité active, consultez [cette page] (https://github.com/nodejs/node/security/policy).
Signaler une faille dans Node.js
Signalez les bogues de sécurité dans Node.js via [HackerOne] (https://hackerone.com/nodejs).
Vous recevrez un accusé de réception de votre rapport dans les 5 jours, et vous recevrez une réponse plus détaillée dans les 10 jours, indiquant les prochaines étapes. une réponse plus détaillée à votre rapport dans les 10 jours, indiquant les prochaines étapes du traitement de votre demande. traitement de votre demande.
Après la réponse initiale à votre rapport, l'équipe de sécurité s'efforcera de vous tenir informé des progrès réalisés en vue d'un correctif et d'une annonce complète. vous tenir informé des progrès réalisés en vue d'une correction et d'une annonce complète, et pourra vous demander des informations supplémentaires ou des conseils sur le problème signalé. problème signalé.
Programme de primes aux bugs Node.js
Le projet Node.js s'engage dans un programme officiel de primes aux bogues pour les chercheurs en sécurité et les divulgations publiques responsables. et les divulgations publiques responsables. Le programme est géré par la plateforme la plateforme HackerOne. Voir https://hackerone.com/nodejs pour plus de détails.
Signaler un bogue dans un module tiers
Les bogues de sécurité dans les modules tiers doivent être signalés à leurs mainteneurs respectifs.
Politique de divulgation
Voici la politique de divulgation de la sécurité pour Node.js
Le rapport de sécurité est reçu et un gestionnaire principal lui est attribué. Cette personne Cette personne coordonnera le processus de correction et de libération. Le problème est confirmé et une liste de toutes les versions affectées est établie. Le code est audité pour trouver tout problème similaire potentiel. Des correctifs sont préparés pour toutes les versions qui sont toujours en cours de maintenance. Ces correctifs ne sont pas déposés dans le mais sont plutôt conservés localement dans l'attente de l'annonce.
Une date d'embargo est proposée pour cette vulnérabilité et un CVE (Common Vulnerabilities and Exposures (CVE®)) est demandé pour cette vulnérabilité. Vulnérabilités et expositions communes (CVE®) est demandé pour la vulnérabilité.
À la date d'embargo, la liste de diffusion sur la sécurité de Node.js reçoit une copie de l'annonce. annonce. Les changements sont poussés vers le dépôt public et de nouvelles versions sont déployées sur nodejs.org. Dans les 6 heures suivant la notification de la liste de diffusion une copie de l'avis sera publiée sur le blog de Node.js.
En règle générale, la date d'embargo est fixée à 72 heures à compter de l'émission du CVE. est publié. Toutefois, cela peut varier en fonction de la gravité du bogue ou de la de la difficulté à appliquer un correctif.
Ce processus peut prendre un certain temps, en particulier lorsqu'une coordination est nécessaire avec les responsables d'autres projets. avec les responsables d'autres projets. Tous les efforts seront faits pour traiter le bogue le plus rapidement possible ; cependant, il est important que nous suivions la processus de publication ci-dessus pour s'assurer que la divulgation est traitée de manière de manière cohérente.
Recevoir les alertes de sécurité
Les notifications de sécurité seront diffusées par les méthodes suivantes.
Commentaires sur cette politique
Si vous avez des suggestions sur la façon dont ce processus pourrait être amélioré, veuillez soumettre une pull request ou file an issue pour en discuter.
OpenSSF Best Practices
Le [badge des meilleures pratiques] de l'Open Source Security Foundation (OpenSSF) (https://github.com/coreinfrastructure/best-practices-badge) est un moyen pour les projets de logiciels libres et open source (FLOSS) de montrer qu'ils suivent les meilleures pratiques. Les projets peuvent volontairement auto-certifier la manière dont ils suivent chaque meilleure pratique. Les utilisateurs du badge peuvent rapidement déterminer quels sont les projets FLOSS qui suivent les meilleures pratiques et qui sont donc plus susceptibles de produire des logiciels sécurisés de meilleure qualité.