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

Notions de base

Conditions préalables

Le projet DOIT atteindre un badge de niveau argent. ^{[achieve_silver]}

Supervision du projet

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]}

Détails:

Les contributeurs sont associés s'ils sont payés pour leur travail par la même organisation (en tant qu'employé ou contractuel) et si l'organisation bénéficie des résultats du projet. Les subventions financières ne comptent pas comme provenant de la même organisation si elles passent par d'autres organisations (par exemple, les subventions scientifiques versées à différentes organisations par un même gouvernement ou ONG ne rendent pas les contributeurs associés). Quelqu'un est un contributeur significatif s'il a apporté des contributions non triviales au projet au cours de la dernière année. Des exemples de bons indicateurs d'un contributeur significatif sont : écrit au moins 1 000 lignes de code, a contribué à 50 commits ou au moins 20 pages de documentation.

Autre

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]}

Détails:

Cela PEUT être fait en incluant ce qui suit à l'intérieur d'un commentaire au début de chaque fichier: « Copyright les contributeurs de [nom du projet]. ». Voir « Avis de droits d'auteur dans les projets de logiciels Open Source » par Steve Winslow.
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]}

Détails:

Cela PEUT également être fait en incluant une déclaration en langage naturel identifiant la licence. Le projet PEUT également inclure une URL stable indiquant le texte de la licence ou directement le texte complet de la licence. Notez que le critère license_location requiert que la licence du projet soit dans un emplacement standard. Voir ce didacticiel SPDX pour plus d'informations sur les expressions de licence SPDX. Notez la relation avec copyright_per_file, dont le contenu devrait généralement précéder les informations sur la licence.

Contrôle des modifications

Dépôt source public sous contrôle de version

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]}

Détails:

Cette identification se fait typiquement en marquant les problèmes sélectionnés dans un outil de suivi de problèmes avec une ou plusieurs étiquettes que le projet utilise à cet effet, par exemple up-for-grabs, first-timers-only, « Small fix », microtask ou IdealFirstBug. Ces nouvelles tâches n'ont pas besoin d'ajouter des fonctionnalités ; elles peuvent améliorer la documentation, ajouter des cas de test ou toute autre chose qui aide le projet et aide le contributeur à en comprendre davantage sur le projet.
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]

Détails:

Un mécanisme 2FA qui répond à ce critère serait une application de mot de passe à usage unique basé sur le temps (TOTP) qui génère automatiquement un code d'authentification qui change après un certain laps de temps. Notez que GitHub prend en charge TOTP.

Qualité

Normes de codage

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]}

Détails:

Voir aussi two_person_review et contribution_requirements.
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]}

Système de construction opérationnel

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]}

Détails:

Une construction reproductible signifie que plusieurs parties peuvent refaire indépendamment le processus de génération d'informations à partir de fichiers source et obtenir exactement le même résultat bit-à-bit. Dans certains cas, cela peut être résolu en forçant un ordre de tri. Les développeurs JavaScript peuvent envisager d'utiliser npm shrinkwrap et webpack OccurenceOrderPlugin. Les utilisateurs GGC et clang peuvent trouver l'option -frandom-seed utile. L'environnement de construction (y compris le jeu d'outils) peut souvent être défini pour les parties externes en spécifiant le hachage cryptographique d'un conteneur spécifique ou d'une machine virtuelle qu'ils peuvent utiliser pour la reconstruction. Le projet de construction reproductible dispose de documentation sur la façon de le faire.

Suite de tests automatisée

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]}

Détails:

Dans la plupart des cas, cela signifie que chaque développeur qui travaille à plein temps sur le projet intègre son code au moins tous les jours.
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]}

Sécurité

Utiliser de bonnes pratiques de base de cryptographie

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]}

Livraison sécurisée contre les attaques man-in-the-middle (MITM)

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]}

Détails:

Notez que GitHub et GitLab sont connus pour le faire. Des sites tels que https://securityheaders.com/ peuvent le vérifier rapidement. Les en-têtes clés de durcissement sont : Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), X-Content-Type-Options (comme « nosniff ») et X-Frame-Options. Les sites Web complètement statiques sans possibilité de se connecter à travers les pages Web peuvent éventuellement omettre certains entêtes de durcissement avec moins de risques, mais il n'existe aucune manière fiable de détecter ces sites, donc nous exigeons ces en-têtes mêmes pour les sites complètement statiques.

Autres problèmes de sécurité

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]}

Détails:

Cela PEUT être fait par les membres du projet et/ou une évaluation indépendante. Cette évaluation PEUT être soutenue par des outils d'analyse statiques et dynamiques, mais il doit aussi y avoir une revue par des humains pour identifier les problèmes (en particulier dans la conception) que les outils ne peuvent pas détecter.
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]

Analyse

Analyse dynamique de code

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]}