TUF (The Update Framework)

Les projets qui suivent les meilleures pratiques ci-dessous peuvent s'auto-certifier et montrer qu'ils ont obtenu le badge de la Open Source Security Foundation (OpenSSF).

Si c'est votre projet, veuillez indiquer votre statut de badge sur votre page de projet ! Le statut du badge ressemble à ceci : Le niveau de badge pour le projet 1351 est gold Voici comment l'intégrer :

Ce sont les critères du niveau Basique. Vous pouvez également afficher les critères des niveaux Argent ou Or.

        

 Notions de base 13/13 ●

  • Identification

    A framework for securing software update systems.

    Quel(s) langage(s) de programmation sont utilisés pour implémenter le projet ?

  • Contenu basique du site Web du projet


    Assez pour un badge !

    Le site du projet DOIT décrire succinctement ce que le logiciel fait (quel problème résout-il ?). [description_good]

    https://theupdateframework.io/

    The Update Framework (TUF) helps developers maintain the security of software update systems, providing protection even against attackers that compromise the repository or signing keys. TUF provides a flexible framework and specification that developers can adopt into any software update system.


    Assez pour un badge !

    Le site Web du projet DOIT fournir des informations sur la façon d'obtenir, de fournir des commentaires (comme des signalements de bogues ou des demandes d'amélioration) et de contribuer au logiciel. [interact]

    Both the project website and the reference implementation GitHub repository show multiple ways of engaging with the project to propose specification enhancements (TAPs), submit feature requests, bug reports and security issues, etc.

    https://theupdateframework.io/, https://github.com/theupdateframework/python-tuf


    Assez pour un badge !

    L'information sur la façon de contribuer DOIT expliquer le processus de contribution (par exemple, les pull requests sont-ils utilisés ?) (URL requise) [contribution]

    The project uses Github issues and pull requests: https://github.com/theupdateframework/python-tuf/issues https://github.com/theupdateframework/python-tuf/pulls

    The contribution process is covered in : https://github.com/theupdateframework/python-tuf/contribute https://github.com/theupdateframework/python-tuf/blob/develop/docs/GOVERNANCE.md#contributions


    Assez pour un badge !

    Les informations sur la façon de contribuer DEVRAIENT inclure les exigences pour des contributions acceptables (par exemple, une référence à toute norme de codage requise). (URL requise) [contribution_requirements]

    The contribution process is covered in below documents. It prescribes following a custom style guide, based on well-known public style guides. https://github.com/theupdateframework/python-tuf/contribute https://github.com/theupdateframework/python-tuf/blob/develop/docs/GOVERNANCE.md#contributions https://github.com/secure-systems-lab/code-style-guidelines/blob/master/python.md


  • Licence FLOSS

    Sous quelle(s) licence(s) le projet est-il distribué ?


    Assez pour un badge !

    Le logiciel produit par le projet DOIT être distribué en tant que FLOSS. [floss_license]

    https://github.com/theupdateframework/python-tuf#license The Apache-2.0 and MIT licenses are approved by the Open Source Initiative (OSI).


    Assez pour un badge !

    Il est PROPOSÉ que toute licence requise pour le logiciel produit par le projet soit approuvée par l'Open Source Initiative (OSI). [floss_license_osi]

    The Apache-2.0 and MIT licenses are approved by the Open Source Initiative (OSI).


    Assez pour un badge !

    Le projet DOIT afficher la ou les licences de ses résultats dans un emplacement standard dans leur dépôt source. (URL requise) [license_location]

    https://github.com/theupdateframework/python-tuf/blob/develop/LICENSE https://github.com/theupdateframework/python-tuf/blob/develop/LICENSE-MIT


  • Documentation


    Assez pour un badge !

    Le projet DOIT fournir une documentation de base pour le logiciel produit par le projet. [documentation_basics]

    basic docs in repo readme: https://github.com/theupdateframework/python-tuf#readme


    Assez pour un badge !

    Le projet DOIT fournir une documentation de référence qui décrit l'interface externe (entrée et sortie) du logiciel produit par le projet. [documentation_interface]

    detailed reference docs on readthedocs: https://theupdateframework.readthedocs.io/


  • Autre


    Assez pour un badge !

    Les sites du projet (site Web, dépôt et URLs de téléchargement) DOIVENT supporter HTTPS en utilisant TLS. [sites_https]

    The project website is hosted on GitHub pages and has free certificates from Let's Encrypt. The repository is hosted on GitHub. Download URLs are available via GitHub and PyPI.

    https://theupdateframework.io/ https://github.com/theupdateframework/python-tuf https://pypi.org/project/tuf/


    Assez pour un badge !

    Le projet DOIT avoir un ou plusieurs mécanismes de discussion (y compris les changements et les problèmes proposés) qui peuvent être recherchés, permettent de désigner les messages et les sujets par une URL, permettent aux nouvelles personnes de participer à certaines des discussions et ne nécessitent pas d'installation côté client de logiciels propriétaires. [discussion]

    Discussions take place on the project's mailing list and GitHub issue tracker.

    https://github.com/theupdateframework/python-tuf/issues https://groups.google.com/forum/?fromgroups#!forum/theupdateframework


    Assez pour un badge !

    Le projet DEVRAIT fournir de la documentation en anglais et être en mesure d'accepter les signalements de bogues et les commentaires sur le code en anglais. [english]

    All of project's material is written in English, and it accepts bug reports and comments in English. All responses to other questions on the individual types of documentation include links to pages in English.


    Assez pour un badge !

    Le projet DOIT être maintenu. [maintained]

    https://github.com/theupdateframework/python-tuf/pulse https://github.com/theupdateframework/python-tuf/blob/develop/docs/MAINTAINERS.txt



(Avancé) Quels autres utilisateurs ont les droits supplémentaires pour modifier cette soumission de badge? Actuellement : []



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


    Assez pour un badge !

    Le projet DOIT avoir un dépôt source sous contrôle de version qui est publiquement lisible et possède une URL. [repo_public]

    The reference implementation is tracked with git and hosted on GitHub https://github.com/theupdateframework/python-tuf


    Assez pour un badge !

    Le dépôt source du projet DOIT suivre les changements apportés, qui a effectué les changements et quand les changements ont été effectués. [repo_track]

    Changes are tracked with git commits and GitHub issues und pull requests https://github.com/theupdateframework/python-tuf Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.


    Assez pour un badge !

    Pour permettre une analyse collaborative, le dépôt source du projet DOIT inclure des versions provisoires pour examen entre versions officielles ; Il NE DOIT PAS inclure que les dernières versions. [repo_interim]

    Each Pull Request must be reviewed and approved by at least one maintainer: https://github.com/theupdateframework/python-tuf/blob/develop/docs/GOVERNANCE.md#contributions


    Assez pour un badge !

    Il est PROPOSÉ qu'un logiciel reconnu de contrôle de version distribué soit utilisé (par exemple, git) pour le dépôt source du projet. [repo_distributed]

    The project uses git https://github.com/theupdateframework/python-tuf Repository on GitHub, which uses git. git is distributed.


  • Numérotation unique de la version


    Assez pour un badge !

    Les résultats du projet DOIVENT avoir un identifiant de version unique pour chaque version destinée à être utilisée par les utilisateurs. [version_unique]

    Both the specification and the reference implementation are versioned and the version progression for both is documented.

    https://github.com/theupdateframework/python-tuf/blob/develop/docs/RELEASE.md https://github.com/theupdateframework/specification#versioning

    Furthermore, a periodically run GitHub action helps to match implementation and specification versions https://github.com/theupdateframework/python-tuf/blob/develop/.github/workflows/specification-version.yml


    Assez pour un badge !

    Il est PROPOSÉ d'utiliser le format de numérotation de version appelé Versionage Sémantique (SemVer) ou Versionage Calendaire (CalVer). Il est PROPOSÉ que ceux qui utilisent CalVer incluent une valeur de niveau micro. [version_semver]

    Releases match the SemVer format: https://github.com/theupdateframework/python-tuf/releases


    Assez pour un badge !

    Il est PROPOSÉ que les projets identifient chaque version dans leur système de contrôle de version. Par exemple, il est PROPOSÉ que ceux qui utilisent git identifient chaque version à l'aide des tags de git. [version_tags]

    Releases are tagged (signed) with git: https://github.com/theupdateframework/python-tuf/tags


  • Notes de version


    Assez pour un badge !

    Le projet DOIT fournir, avec chaque distribution, des notes de version qui sont un résumé lisible par les humains des changements majeurs dans cette version afin d'aider les utilisateurs à déterminer s'ils doivent se mettre à niveau et quel sera l'impact de la mise à niveau. Les notes de version NE DOIVENT PAS être la sortie brute d'un journal de contrôle de version (par exemple, les résultats de la commande « git log » ne sont pas des notes de version). Les projets dont les résultats ne sont pas destinés à être réutilisés dans plusieurs emplacements (tels que le logiciel pour un site Web ou un service unique) ET qui utilisent la livraison continue PEUVENT sélectionner « N/A ». (URL requise) [release_notes]

    Changelog available on GitHub release page and in dedicated document: https://github.com/theupdateframework/python-tuf/releases https://github.com/theupdateframework/python-tuf/blob/develop/docs/CHANGELOG.md


    Assez pour un badge !

    Les notes de version DOIVENT identifier toutes les vulnérabilités connues du public corrigées dans cette version qui avaient déjà une affectation CVE ou similaire lors de la création de la version. Ce critère peut être marqué comme non applicable (N/A) si les utilisateurs ne peuvent pas en général mettre à jour le logiciel eux-mêmes (par exemple, comme c'est souvent le cas pour les mises à jour du noyau). Ce critère s'applique uniquement aux résultats du projet, pas à ses dépendances. S'il n'y a pas de notes de version ou qu'il n'y a pas eu de vulnérabilité publiquement connue, choisissez N/A. [release_notes_vulns]

    Vulnerability fixes are identified in the release notes with links to the corresponding GitHub Security Advisory

    https://github.com/theupdateframework/python-tuf/blob/develop/docs/CHANGELOG.md https://github.com/theupdateframework/python-tuf/security/advisories


  • Procédure de signalement des bogues


    Assez pour un badge !

    Le projet DOIT fournir un processus permettant aux utilisateurs de soumettre des signalements de bogue (par exemple, en utilisant un suivi des problèmes ou une liste de diffusion). (URL requise) [report_process]

    Bug reports can be submitted using the GitHub issue feature, which is standard for open source projects

    https://github.com/theupdateframework/python-tuf/issues https://groups.google.com/forum/?fromgroups#!forum/theupdateframework

    This is also explained in the contributor instructions on the repository: https://github.com/theupdateframework/python-tuf/contribute https://github.com/theupdateframework/python-tuf/blob/develop/docs/GOVERNANCE.md


    Assez pour un badge !

    Le projet DEVRAIT utiliser un suivi des problèmes pour le suivi des problèmes individuels. [report_tracker]

    The project uses GitHub's issue tracker to track individual issues.

    https://github.com/theupdateframework/python-tuf/issues


    Assez pour un badge !

    Le projet DOIT confirmer une majorité des signalements de bogues soumis au cours des 2 à 12 derniers mois (inclus) ; la réponse ne doit pas nécessairement inclure une correction. [report_responses]

    All bug reports submitted in the last 2-12 months have been acknowledged.

    https://github.com/theupdateframework/python-tuf/issues


    Assez pour un badge !

    Le projet DEVRAIT répondre à une majorité (>50%) des demandes d'amélioration au cours des 2 à 12 derniers mois (inclus). [enhancement_responses]

    All enhancement reports submitted in the last 2-12 months have been acknowledged.

    https://github.com/theupdateframework/python-tuf/issues


    Assez pour un badge !

    Le projet DOIT avoir une archive publique pour les signalements et les réponses pour une recherche ultérieure. (URL requise) [report_archive]

    All reports and issues submitted to the project have been documented in the mailing list and issue tracker.

    https://github.com/theupdateframework/python-tuf/issues https://groups.google.com/forum/?fromgroups#!forum/theupdateframework


  • Processus de signalement de vulnérabilité


    Assez pour un badge !

    Le projet DOIT publier le processus de signalement des vulnérabilités sur le site du projet. (URL requise) [vulnerability_report_process]

    The project publishes the process for reporting vulnerabilities.

    https://github.com/theupdateframework/python-tuf/blob/develop/README.md#security-issues-and-bugs


    Assez pour un badge !

    Si les signalements de vulnérabilités privés sont pris en charge, le projet DOIT inclure la façon d'envoyer l'information de manière confidentielle. (URL requise) [vulnerability_report_private]

    The project instructs users to encrypted their reports with GPG when emailing it.

    https://github.com/theupdateframework/python-tuf/blob/develop/README.md#security-issues-and-bugs


    Assez pour un badge !

    Le temps de réponse initial du projet pour tout signalement de vulnérabilité reçu au cours des 6 derniers mois DOIT être inférieur ou égal à 14 jours. [vulnerability_report_response]

    Vulnerability reports have been responded too immediately and addressed in a timely manner so far:

    https://github.com/theupdateframework/python-tuf/security/advisories?state=published


  • Connaissance du développement sécurisé


    Assez pour un badge !

    Le projet DOIT avoir au moins un développeur principal qui sait comment concevoir un logiciel sécurisé. (Voir les « détails » pour les exigences exactes.) [know_secure_design]

    The primary developers of the project are familiar with secure software design and work in a security lab at a university.


    Assez pour un badge !

    Au moins l'un des principaux développeurs du projet DOIT connaître les types courants d'erreurs qui conduisent à des vulnérabilités dans ce genre de logiciel, ainsi qu'au moins une méthode pour contrer ou atténuer chacun d'eux. [know_common_errors]

    The primary developers of the project are familiar with secure software design and work in a security lab at a university.


  • Utiliser de bonnes pratiques de base de cryptographie

    Notez que certains logiciels n'ont pas besoin d'utiliser des mécanismes cryptographiques. Si votre projet produit un logiciel qui (1) inclut ou active la fonctionnalité de chiffrement, et (2) peut être publié des États-Unis (US) vers l'extérieur des États-Unis ou vers un citoyen autre qu'américain, vous pouvez être légalement obligé à faire quelques étapes supplémentaires. En règle générale, cela implique simplement l'envoi d'un email. Pour plus d'informations, consultez la section sur le chiffrement de Comprendre la technologie Open Source et les contrôles à l'exportation américains .

    Assez pour un badge !

    Le logiciel produit par le projet DOIT utiliser, par défaut, uniquement les protocoles cryptographiques et les algorithmes publiés publiquement et revus par des experts (si des protocoles et algorithmes cryptographiques sont utilisés). [crypto_published]

    The project uses only cryptographic protocols and algorithms that are publicly published and reviewed by experts.


    Assez pour un badge !

    Si le logiciel produit par le projet est une application ou une bibliothèque, et si son objectif principal n'est pas d'implémenter de la cryptographie, alors il DEVRAIT simplement appeler un logiciel spécialement conçu pour implémenter des fonctions cryptographiques ; il ne DEVRAIT PAS ré-implémenter les siennes. [crypto_call]

    The project does not reimplement its own cryptographic functions.


    Assez pour un badge !

    Toutes les fonctionnalités du logiciel produit par le projet qui dépendent de la cryptographie DOIVENT être réalisables à l'aide de FLOSS. [crypto_floss]

    All functionality in the project that depends on crypto uses FLOSS.


    Assez pour un badge !

    Les mécanismes de sécurité dans le logiciel produit par le projet DOIVENT utiliser des longueurs de clés par défaut qui satisfont au moins aux exigences minimales du NIST jusqu'à l'année 2030 (comme indiqué en 2012). Il DOIT être possible de configurer le logiciel afin que les plus petites longueurs de clés soient complètement désactivées. [crypto_keylength]

    The project uses safe defaults that follows NIST requirements, and disallows smaller key lengths.


    Assez pour un badge !

    Les mécanismes de sécurité par défaut dans le logiciel produit par le projet NE DOIVENT PAS dépendre d'algorithmes cryptographiques cassés (par exemple, MD4, MD5, DES unique, RC4, Dual_EC_DRBG) ou utiliser des modes de chiffrement inappropriés dans le contexte, sauf si ils sont nécessaires pour implémenter un protocole d'interopérabilité (où le protocole implémenté est la version la plus récente du standard supporté largement par l'écosystème du réseau, l'écosystème requiert l'utilisation de cet algorithme ou mode, et cet écosystème n'offre pas d'alternative plus sûre). La documentation DOIT décrire tous les risques de sécurité appropriés et les parades connues si ces algorithmes ou modes cassés sont nécessaires pour un protocole d'interopérabilité. [crypto_working]

    The project does not depend on broken cryptographic algorithms.


    Assez pour un badge !

    Les mécanismes de sécurité par défaut dans le logiciel produit par le projet NE DEVRAIENT PAS dépendre d'algorithmes ou de modes cryptographiques avec des faiblesses sérieuses connues (par exemple, l'algorithme de hachage cryptographique SHA-1 ou le mode CBC en SSH). [crypto_weaknesses]

    The project's default security mechanisms do not depend on weak algorithms or modes.


    Assez pour un badge !

    Les mécanismes de sécurité dans le logiciel produit par le projet DEVRAIENT implémenter la confidentialité persistante pour les protocoles d'échange de clés afin qu'une clé de session dérivée d'un ensemble de clés à long terme ne soit pas compromise si l'une des clés à long terme est compromise dans le futur. [crypto_pfs]

    The project does not depend on key agreement protocols.


    Assez pour un badge !

    Si le logiciel produit par le projet entraîne la sauvegarde de mots de passe pour l'authentification d'utilisateurs externes, les mots de passe DOIVENT être sauvegardés comme hachages itérés avec un salage par utilisateur en utilisant un algorithme d'étirement de clé (itéré) (par exemple Argon2id, Bcrypt, Scrypt, ou PBKDF2). Voir également le pense-bête sur le stockage des clés d'OWASP. [crypto_password_storage]

    The project's key files make use of PBKDF2.


    Assez pour un badge !

    Les mécanismes de sécurité dans le logiciel produit par le projet DOIVENT générer toutes les clés cryptographiques et les nonces en utilisant un générateur de nombres aléatoires cryptographiquement sécurisé, et NE DOIVENT PAS le faire en utilisant des générateurs qui ne seraient pas cryptographiquement sécurisés. [crypto_random]

    The project does use a cryptographically secure random number generator.


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


    Assez pour un badge !

    Le projet DOIT utiliser un mécanisme de livraison qui contrecarre les attaques MITM. L'utilisation de https ou ssh+scp est acceptable. [delivery_mitm]

    The project supports HTTPS.


    Assez pour un badge !

    Un hachage cryptographique (par exemple, un sha1sum) NE DOIT PAS être récupéré par http et utilisé sans vérifier une signature cryptographique. [delivery_unsigned]

    The project's signed metadata, which includes cryptographic hashes, is always validated by the client software before accepting it.


  • Vulnérabilités publiquement identifiées et corrigées


    Assez pour un badge !

    Il ne DOIT pas y avoir de vulnérabilités non corrigées de gravité moyenne ou supérieure connues publiquement depuis plus de 60 jours. [vulnerabilities_fixed_60_days]

    All known vulnerabilities of medium and higher severity have been patched within 60 days.

    https://github.com/theupdateframework/python-tuf/security/advisories?state=published


    Assez pour un badge !

    Les projets DEVRAIENT corriger rapidement toutes les vulnérabilités critiques après leur signalement. [vulnerabilities_critical_fixed]

    All critical vulnerabilities have been patched rapidly after they were reported.

    https://github.com/theupdateframework/python-tuf/security/advisories?state=published


  • Autres problèmes de sécurité


    Assez pour un badge !

    Les dépôts publics NE DOIVENT PAS fuiter un certificat privé valide (par exemple, un mot de passe ou une clé privée) qui est destiné à limiter l'accès public. [no_leaked_credentials]

    The project does not leak a valid private credential. The unit and integration tests do use sample private keys and credentials, and these are used strictly for testing purposes.


  • Analyse statique de code


    Assez pour un badge !

    Au moins un outil d'analyse statique de code (au-delà des avertissements du compilateur et des modes « sûrs » des languages) DOIT être appliqué à toute distribution majeure proposée avant sa sortie s'il existe au moins un outil FLOSS qui implémente ce critère dans le langage sélectionné. [static_analysis]

    The project uses Floss tools pylint and Bandit for static analysis and black and isort for uniform auto-format, which are all run in CI.

    https://github.com/theupdateframework/python-tuf/blob/develop/tox.ini https://github.com/theupdateframework/python-tuf/blob/develop/.github/workflows/ci.yml


    Assez pour un badge !

    Il est PROPOSÉ qu'au moins l'un des outils d'analyse statique utilisés pour le critère d'analyse statique inclue des règles ou des approches pour rechercher des vulnérabilités courantes dans le langage ou l'environnement analysé. [static_analysis_common_vulnerabilities]

    The project uses Floss tools pylint and Bandit (security linter) for static analysis and black and isort for uniform auto-format, which are all run in CI.

    https://github.com/theupdateframework/python-tuf/blob/develop/tox.ini https://github.com/theupdateframework/python-tuf/blob/develop/.github/workflows/ci.yml


    Assez pour un badge !

    Toutes les vulnérabilités exploitables de gravité moyenne ou plus découvertes avec une analyse statique de code DOIVENT être corrigées en temps approprié après leur confirmation. [static_analysis_fixed]

    Assez pour un badge !

    Il est PROPOSÉ que l'analyse statique du code source se produise à chaque commit ou au moins quotidiennement. [static_analysis_often]

    The project uses Floss tools pylint and Bandit (security linter) for static analysis and black and isort for uniform auto-format, which are all run in CI on pull requests and pushes to the develop branch.

    https://github.com/theupdateframework/python-tuf/blob/develop/tox.ini https://github.com/theupdateframework/python-tuf/blob/develop/.github/workflows/ci.yml


  • Analyse dynamique de code


    Assez pour un badge !

    Il est PROPOSÉ qu'au moins un outil d'analyse dynamique soit appliqué à tout candidat pour une version majeure du logiciel avant sa distribution. [dynamic_analysis]

    The project's automated test suite ensures 97% code coverage: https://coveralls.io/r/theupdateframework/python-tuf?branch=develop


    Assez pour un badge !

    Il est PROPOSÉ que, si le logiciel produit par le projet comprend un logiciel écrit à l'aide d'un langage non sûr pour les accès mémoire (par exemple, C ou C ++), au moins un outil dynamique (par exemple, un fuzzer ou un scanner d'application Web) soit utilisé de façon routinière en combinaison avec un mécanisme pour détecter des problèmes de sécurité mémoire tels que les dépassements de zone mémoire. Si le projet ne produit pas de logiciel écrit dans un langage non sûr pour les accès mémoire, choisissez « non applicable » (N/A). [dynamic_analysis_unsafe]

    The project does not produce software written in a memory-unsafe language.


    Assez pour un badge !

    Il est PROPOSÉ que le projet utilise une configuration pour au moins une analyse dynamique (comme le test ou le fuzzing) qui active de nombreuses assertions. Dans de nombreux cas, ces assertions ne doivent pas être activées dans les versions de production. [dynamic_analysis_enable_assertions]

    The project's codebase does not include run-time assertions. However, the unit tests (which we consider separate from the codebase) do make use of assertions. The project's code style guidelines recommend limited use of assertions.


    Assez pour un badge !

    Toutes les vulnérabilités exploitables de gravité moyenne ou plus découvertes avec une analyse de code dynamique DOIVENT être corrigées en un temps approprié après leur confirmation. [dynamic_analysis_fixed]


Ces données sont disponibles sous une licence Creative Commons Attribution version 3.0 ou ultérieure (CC-BY-3.0+). Chacun peut librement partager et adapter les données, à condition de créditer leur origine. Veuillez créditer Justin Cappos et les contributeurs du badge des meilleures pratiques de la OpenSSF.

Soumission du badge du projet appartenant à : Justin Cappos.
Soumission créée le 2017-10-26 19:09:52 UTC, dernière mise à jour le 2022-02-09 14:13:41 UTC. Le dernier badge perdu l'a été le 2017-11-17 17:46:04 UTC. Le dernier badge obtenu l'a été le 2017-11-20 19:26:07 UTC.

Retour