OpenSSL before Heartbleed

Les projets PEUVENT choisir d'omettre des versions intermédiaires spécifiques dans leurs dépôts source publics (par exemple, celles qui corrigent des vulnérabilités de sécurité non publiques spécifiques, ne peuvent jamais être rendues publiques ou incluent des éléments qui ne peuvent être légalement publiés et ne sont pas dans la version finale).

Les projets devraient généralement préférer le format attendu par leurs utilisateurs, par exemple, parce que c'est le format normal utilisé par leur écosystème. De nombreux écosystèmes préfèrent SemVer, et SemVer est généralement préféré pour les interfaces de programmation d'applications (API) et les kits de développement logiciel (SDK). CalVer a tendance à être utilisé par des projets de grande envergure, ayant un nombre inhabituellement élevé de dépendances développées indépendamment, ayant une portée en constante évolution ou étant sensibles au temps. Il est PROPOSÉ que ceux qui utilisent CalVer incluent une valeur de niveau micro, car l'inclusion d'un niveau micro prend en charge les branches maintenues simultanément chaque fois que cela devient nécessaire. D'autres formats de numérotation de version peuvent être utilisés, y compris les ID de commit git ou les ID de jeu de modifications mercurial, à condition qu'ils identifient de manière unique les versions. Cependant, certaines alternatives (telles que les ID de commit git) peuvent poser des problèmes en tant qu'identificateurs de version, car les utilisateurs peuvent ne pas être en mesure de déterminer facilement s'ils sont à jour. Le format de l'ID de version peut être sans importance pour l'identification des versions logicielles si tous les destinataires n'exécutent que la dernière version (par exemple, il s'agit du code d'un site Web ou d'un service Internet unique qui est constamment mis à jour par livraison continue).

La réponse PEUT être « non » ou une discussion sur ses mérites. Le but est simplement qu'il y ait une réponse à certaines demandes, ce qui indique que le projet est toujours en vie. Aux fins de ce critère, les projets ne doivent pas compter les fausses demandes (par exemple, provenant de spammeurs ou de systèmes automatisés). Si un projet ne fait plus d'améliorations, sélectionnez « non satisfait » et incluez l'URL qui rend cette situation claire pour les utilisateurs. Si un projet tend à être submergé par le nombre de demandes d'amélioration, sélectionnez « non satisfait » et expliquez.

Les projets hébergés sur GitHub DEVRAIENT envisager d'activer le signalement privé d'une vulnérabilité de sécurité . Les projets sur GitLab DEVRAIENT envisager d'utiliser sa capacité à signaler une vulnérabilité en privé . Les projets PEUVENT identifier une adresse postale sur https://PROJECTSITE/security, souvent sous la forme security@example.org. Ce processus de rapport de vulnérabilité PEUT être le même que son processus de rapport de bogue. Les rapports de vulnérabilité PEUVENT toujours être publics, mais de nombreux projets ont un mécanisme de rapport de vulnérabilité privé.

Des exemples incluent un signalement de défaut privé envoyé sur le Web en utilisant HTTPS (TLS) ou un courrier électronique chiffré à l'aide d'OpenPGP. Si les signalements de vulnérabilités sont toujours publics (donc il n'y a jamais de signalements de vulnérabilités privés), choisissez « non applicable » (N/A).

S'il n'y a pas eu de vulnérabilité signalée au cours des 6 derniers mois, choisissez « non applicable » (N/A).

Dès qu'une politique est en place, même par le bouche à oreille, qui spécifie que les développeurs devraient ajouter des tests à une suite de tests automatisée pour toute nouvelle fonctionnalité importante, sélectionnez « Atteint ».

Les principales fonctionnalités sont généralement mentionnées dans les notes de version. La perfection n'est pas nécessaire, il suffit de prouver que les tests sont généralement ajoutés en pratique à la suite de tests automatisée lorsque de nouvelles fonctionnalités majeures sont ajoutées au logiciel produit par le projet.

Cependant, même une règle informelle est acceptable tant que les tests sont ajoutés dans la pratique.

Des exemples d'options d'avertissement du compilateur incluent « -Wall » pour gcc/clang. Des exemples d'un mode de langage « sûr » incluent « use strict » en JavaScript et « use warnings » de perl5. Un outil « linter » distinct est simplement un outil qui examine le code source pour rechercher des erreurs de qualité de code ou des erreurs simples courantes. Ceux-ci sont généralement activés par le code source ou par les instructions de construction.

Ce sont les avertissements identifiés par la mise en œuvre du critère warnings. Le projet doit corriger les avertissements ou les marquer dans le code source comme faux positifs. Idéalement, il n'y aurait pas d'avertissement, mais un projet PEUT accepter certains avertissements (généralement moins de 1 avertissement pour 100 lignes ou moins de 10 avertissements).

Certains avertissements ne peuvent être efficacement activés sur certains projets. Ce qui est nécessaire est la preuve que le projet s'efforce d'activer les options d'avertissements où il peut, de sorte que les erreurs soient détectées tôt.

Ces longueurs de bit minimales sont : pour une clé symétrique 112, pour un modulo de factorisation 2048, pour une clé de logarithme discret 224, pour un groupe du logarithmique discret 2048, pour une courbe elliptique 224 et pour un hachage 224 (le hachage de mot de passe n'est pas couvert par cette longueur de bit, plus d'informations sur le hachage de mot de passe peuvent être trouvées dans le critère crypto_password_storage). Voir https://www.keylength.com pour une comparaison des recommandations sur les longueurs de clés de diverses organisations. Le logiciel PEUT permettre de plus petites longueurs de clés dans certaines configurations (idéalement non, car cela permet des attaques de dégradation, mais des longueurs de clés plus courtes sont parfois nécessaires pour l'interopérabilité).

Le mode ECB n'est presque jamais approprié car il révèle des blocs identiques dans le texte chiffré, comme le montre le pingouin ECB, et le mode CTR est souvent inapproprié car il n'effectue pas d'authentification et provoque des doublons si l'état d'entrée est dupliqué. Dans de nombreux cas, il est préférable de choisir un mode d'algorithme de chiffrement de bloc conçu pour combiner le secret et l'authentification, par exemple Galois/Counter Mode (GCM) et EAX. Les projets PEUVENT permettre aux utilisateurs d'activer les mécanismes cassés (par exemple pendant la configuration) si nécessaire pour la compatibilité, mais les utilisateurs savent alors qu'ils le font.

Les préoccupations concernant le mode CBC en SSH sont discutées dans CERT : vulnérabilité SSH CBC.

Un mécanisme encore plus fort distribue le logiciel sous forme de paquetages signés numériquement, car cela atténue les attaques sur le système de distribution, mais cela ne fonctionne que si les utilisateurs peuvent être convaincus que les clés publiques pour les signatures sont correctes et si les utilisateurs vérifient la signature.

Ces hachages peuvent être modifiés en transit.

La vulnérabilité doit être corrigée et diffusée par le projet lui-même (les correctifs peuvent être développés ailleurs). Une vulnérabilité devient publique (à cet effet) une fois qu'elle a un CVE avec des informations non payantes publiquement publiées (signalée, par exemple, dans la Base de données Nationale des Vulnérabilités) ou lorsque le projet a été informé et que l'information a été diffusée au public (éventuellement par le projet). Une vulnérabilité est considérée de gravité moyenne ou supérieure si son score de base qualitatif du Système Commun d'Évaluation des Vulnérabilités (CVSS) est moyen ou supérieur. Dans les versions CVSS 2.0 à 3.1, cela équivaut à un score CVSS de 4.0 ou supérieur. Les projets peuvent utiliser le score CVSS publié dans une base de données de vulnérabilité largement utilisée (telle que la base de données nationale des vulnérabilités) en utilisant la version la plus récente de CVSS rapportée dans cette base de données. Les projets peuvent aussi calculer eux-mêmes la gravité à l'aide de la dernière version de CVSS au moment de la divulgation de la vulnérabilité, si les entrées de calcul sont révélées publiquement une fois que la vulnérabilité est connue du public.Note : cela signifie que les utilisateurs peuvent être laissés vulnérables à tous les attaquants du monde entier jusqu'à 60 jours. Ce critère est souvent beaucoup plus facile à atteindre que ce que Google recommande dans son Redémarrage de la divulgation responsable, car Google recommande que la période de 60 jours commence lorsque le projet est notifié même si le rapport n'est pas public. Notez que ce critère de badge, comme d'autres critères, s'applique à un projet individuel. Certains projets font parti d'organisations ou de projets englobants, parfois à plusieurs niveaux, et de nombreux projets fournissent leurs résultats à d'autres organisations et projets au sein d'une chaîne approvisionnement potentiellement complexe. Un projet individuel ne peut souvent pas contrôler le reste, mais un projet individuel peut travailler à fournir un correctif de vulnérabilité à temps. Pour cette raison, nous nous concentrons seulement sur le temps de réponse des projets individuels. Une fois qu'un correctif est disponible de la part d'un projet individuel, les autres projets peuvent déterminer comment appliquer le correctif (par exemple, ils peuvent mettre à jour la dernière version ou ils peuvent appliquer uniquement le correctif).

Un outil d'analyse statique de code examine le code logiciel (au niveau du code source, du code intermédiaire ou de l'exécutable) sans l'exécuter avec des entrées spécifiques. Aux fins de ce critère, les avertissements du compilateur et les modes de langage « sûrs » ne comptent pas comme des outils d'analyse statique de code (ceux-ci évitent généralement une analyse approfondie car la rapidité est vitale). Certains outils d'analyse statique se concentrent sur la détection de défauts génériques, d'autres se concentrent sur la détection de défauts spécifiques (tels que les vulnérabilités) et d'autres encore proposent une combinaison de ces deux types d'outils. Des exemples de tels outils d'analyse statique de code incluent cppcheck (C, C++), clang static analyzer (C, C++), SpotBugs (Java), FindBugs (Java) (y compris FindSecurityBugs), PMD (Java), Brakeman (Ruby on Rails), lintr (R), goodpractice (R), Coverity Quality Analyzer, SonarQube, Codacy et HP Enterprise Fortify Static Code Analyzer. Des listes plus vastes d'outils peuvent être trouvées dans des endroits tels que la liste Wikipedia d'outils pour l'analyse statique de code, l'information OWASP sur l'analyse statique de code, la liste NIST des analyseurs de sécurité du code source et la liste des outils d'analyse statique de Wheeler. S'il n'y a pas d'outil d'analyse statique FLOSS disponible pour le(s) langage(s) d'implémentation utilisé(s), sélectionnez « N/A ».

Les outils d'analyse statique spécialement conçus pour détecter les vulnérabilités les plus courantes sont plus susceptibles de les détecter. Cela dit, l'utilisation d'outils statiques aidera généralement à trouver des problèmes, nous suggérons donc, sans l'exiger, de le faire pour le badge de niveau « passant ».

Une vulnérabilité est considérée comme étant de gravité moyenne ou supérieure si son score qualitatif de base du Système Commun d'Évaluation des Vulnérabilités (CVSS) est moyen ou supérieur. Dans les versions CVSS 2.0 à 3.1, cela équivaut à un score CVSS de 4.0 ou supérieur. Les projets peuvent utiliser le score CVSS publié dans une base de données de vulnérabilité largement utilisée (telle que la base de données nationale des vulnérabilités) en utilisant la version la plus récente de CVSS rapportée dans cette base de données. Les projets peuvent aussi calculer eux-mêmes la gravité à l'aide de la dernière version de CVSS au moment de la divulgation de la vulnérabilité, si les entrées de calcul sont révélées publiquement une fois que la vulnérabilité est connue du public. Remarquez que le critère vulnerabilities_fixed_60_days nécessite que de telles vulnérabilités soient corrigées dans les 60 jours de leur divulgation publique.

Un outil d'analyse dynamique examine le logiciel en l'exécutant avec des entrées spécifiques. Par exemple, le projet PEUT utiliser un outil de fuzzing (par exemple, American Fuzzy Lop) ou un scanner d'application Web (par exemple, OWASP ZAP ou w3af). Dans certains cas, le projet OSS-Fuzz peut être prêt à appliquer des tests de fuzzing à votre projet. Aux fins de ce critère, l'outil d'analyse dynamique doit varier les entrées d'une manière ou d'une autre pour rechercher différents types de problèmes ou être une suite de test automatisée avec au moins 80% de couverture de branche. La page Wikipedia sur l'analyse dynamique et la page OWASP sur le fuzzing identifient certains outils d'analyse dynamique. Le ou les outils d'analyse PEUVENT être axés sur la recherche de vulnérabilités de sécurité, mais cela n'est pas nécessaire.

Des exemples de mécanismes pour détecter les problèmes de sécurité de la mémoire comprennent Address Sanitizer (ASAN) (disponible dans GCC et LLVM), Memory Sanitizer et valgrind. D'autres outils potentiellement utilisés incluent thread sanitizer et undefined behavior sanitizer. La généralisation de l'utilisation des assertions fonctionnera également.

Si vous n'utilisez pas d'analyse de code dynamique et n'avez donc trouvé aucune vulnérabilité de cette manière, choisissez « non applicable » (N/A). Une vulnérabilité est considérée comme étant de gravité moyenne ou supérieure si son score qualitatif de base du Système Commun d'Évaluation des Vulnérabilités (CVSS) est moyen ou supérieur. Dans les versions CVSS 2.0 à 3.1, cela équivaut à un score CVSS de 4.0 ou supérieur. Les projets peuvent utiliser le score CVSS publié dans une base de données de vulnérabilité largement utilisée (telle que la base de données nationale des vulnérabilités) en utilisant la version la plus récente de CVSS rapportée dans cette base de données. Les projets peuvent aussi calculer eux-mêmes la gravité à l'aide de la dernière version de CVSS au moment de la divulgation de la vulnérabilité, si les entrées de calcul sont révélées publiquement une fois que la vulnérabilité est connue du public.