Critères des meilleures pratiques FLOSS (niveau Or)

Il s'agit de l'ensemble des meilleures pratiques pour les projets de logiciels libres et open source (FLOSS) pour obtenir le badge des meilleures pratiques de la Open Source Security Foundation (OpenSSF) au niveau or. Vous pouvez afficher cette liste avec uniquement les critères ou avec des informations supplémentaires. L'ensemble complet des critères pour tous les niveaux de badge est également disponible.

Voir la discussion des critères pour plus d'informations sur ces critères.

Or

Le projet DOIT avoir un « facteur bus » de 2 ou plus. {Atteint URL} ^[bus_factor]
Le projet DOIT avoir au moins deux contributeurs significatifs non associés. {Atteint URL} ^{[contributors_unassociated]}

Le projet DOIT inclure une déclaration de droit d'auteur dans chaque fichier source, identifiant le détenteur du droit d'auteur (par exemple, les contributeurs de [nom du projet]). {Atteint justification} ^{[copyright_per_file]}
Le projet DOIT inclure une déclaration de licence dans chaque fichier source. Cela PEUT être fait en incluant ce qui suit à l'intérieur d'un commentaire au début de chaque fichier : SPDX-License-Identifier : [expression d'une licence SPDX pour le projet]. {Atteint justification} ^{[license_per_file]}

Le dépôt source du projet DOIT utiliser un logiciel courant de contrôle de version distribué (par exemple, git ou mercurial). {Atteint justification} ^{[repo_distributed]}
Le projet DOIT identifier clairement les petites tâches qui peuvent être effectuées par des contributeurs nouveaux ou occasionnels. {Atteint URL} ^{[small_tasks]}
Le projet DOIT exiger l'authentification à deux facteurs (2FA) des développeurs pour changer un dépôt central ou accéder à des données sensibles (telles que des signalements de vulnérabilités privés). Ce mécanisme 2FA PEUT utiliser des mécanismes sans mécanismes cryptographiques tels que SMS, mais cela n'est pas recommandé. {Atteint justification} ^{[require_2FA]}
L'authentification à deux facteurs du projet (2FA) DOIT utiliser des mécanismes cryptographiques pour empêcher l'emprunt d'identité. Une 2FA basée sur un service de messages courts (SMS), par elle-même, ne satisfait PAS à ce critère, car elle n'est pas chiffrée. {Atteint justification} ^[secure_2FA]

Le projet DOIT documenter ses exigences en matière de revue de code, y compris la façon dont la revue de code est menée, ce qui doit être vérifié et ce qui est requis pour être acceptable. {N/A justification} {Atteint URL} ^{[code_review_standards]}
Le projet DOIT avoir au moins 50% de toutes les modifications proposées revues avant la sortie par une personne autre que l'auteur, afin de déterminer s'il s'agit d'une modification valable et sans problèmes connus qui risqueraient de s'opposer à son inclusion. {Atteint justification} ^{[two_person_review]}

Le projet DOIT avoir une construction reproductible. Si aucune construction ne se produit (par exemple, les langages de script où le code source est utilisé directement au lieu d'être compilé), sélectionnez « non applicable » (N/A). {N/A justification} {Atteint URL} ^{[build_reproducible]}

Une suite de tests DOIT être invocable d'une manière standard pour ce langage. {Atteint URL} ^{[test_invocation]}
Le projet DOIT utiliser une intégration continue, où le code nouveau ou modifié est fréquemment intégré dans un dépôt de code central et des tests automatisés sont exécutés sur le résultat. {Atteint URL} ^{[test_continuous_integration]}
Le projet DOIT avoir une ou des suites de tests automatisées FLOSS qui fournissent une couverture d'instructions d'au moins 90% s'il existe au moins un outil FLOSS qui peut mesurer ce critère dans le langage sélectionné. {N/A justification} {Atteint justification} ^{[test_statement_coverage90]}
Le projet DOIT avoir une ou des suites de tests automatisées FLOSS qui fournissent une couverture de branche d'au moins 80% s'il existe au moins un outil FLOSS qui peut mesurer ce critère dans le langage sélectionné. {N/A justification} {Atteint justification} ^{[test_branch_coverage80]}

Le logiciel produit par le projet DOIT supporter des protocoles sécurisés pour toutes ses communications réseau, tels que SSHv2 ou ultérieur, TLS1.2 ou ultérieur (HTTPS), IPsec, SFTP et SNMPv3. Les protocoles non sûrs tels que FTP, HTTP, telnet, SSLv3 ou antérieur, et SSHv1 DOIVENT être désactivés par défaut et uniquement activés si l'utilisateur le configure spécifiquement. Si le logiciel produit par le projet ne prend pas en charge les communications réseau, sélectionnez « non applicable » (N/A). {N/A autorisé} {Atteint justification} ^{[crypto_used_network]}
Le logiciel produit par le projet DOIT, s'il prend en charge ou utilise TLS, prendre en charge au moins TLS version 1.2. Notez que le prédécesseur de TLS s'appelait SSL. Si le logiciel n'utilise pas TLS, sélectionnez « non applicable » (N/A). {N/A autorisé} {Atteint justification} ^{[crypto_tls12]}

Le site Web du projet, le dépôt (s'il est accessible via le Web) et le site de téléchargement (si séparé) DOIVENT inclure des en-têtes clés de durcissement avec des valeurs non admises. {Atteint URL} ^{[hardened_site]}

Le projet DOIT avoir effectué une évaluation de la sécurité au cours des 5 dernières années. Cette revue DOIT prendre en considération les exigences de sécurité et les limites de sécurité. {Atteint justification} ^{[security_review]}
Des mécanismes de durcissement DOIVENT être utilisés dans le logiciel produit par le projet afin que les défauts du logiciel soient moins susceptibles d'entraîner des vulnérabilités de sécurité. {N/A justification} {Atteint URL} ^[hardening]

Le projet DOIT appliquer au moins un outil d'analyse dynamique à tout candidat pour une version majeure du logiciel produit par le projet avant sa sortie. {N/A justification} {Atteint justification} ^{[dynamic_analysis]}
Le projet DEVRAIT inclure de nombreuses assertions à l'exécution dans le logiciel qu'il produit, et vérifier ces assertions lors d'une analyse dynamique. {N/A justification} {Atteint justification} ^{[dynamic_analysis_enable_assertions]}