Zephyr Project

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 74 est gold Voici comment l'intégrer :

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

        

 Notions de base 17/17

  • Identification

    The Zephyr Project is a small, scalable real-time operating system for use on resource-constrained systems supporting multiple architectures. Developers are able to tailor their optimal solution. As a true open source project, the community can evolve the Zephyr Project to support new hardware, developer tools, sensor and device drivers. Advancements in security, device management capabilities, connectivity stacks and file systems can be easily implemented.

  • Conditions préalables


    Le projet DOIT atteindre un badge de niveau basique. [achieve_passing]

  • Contenu basique du site Web du projet


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

    https://docs.zephyrproject.org/latest/contribute/index.html -- Require contributors to adhere to specific coding styles and guidelines outlined in the project documentation.


  • Supervision du projet


    Le projet DEVRAIT avoir un mécanisme juridique par lequel tous les développeurs de quantités non triviales de logiciel du projet affirment qu'ils sont légalement autorisés à effectuer ces contributions. L'approche la plus commune et facilement mise en œuvre pour ce faire est d'utiliser un Certificat d'origine du développeur (DCO), où les utilisateurs ajoutent une information « sign-off-by » dans leurs commits et le projet pointe vers le site Web du DCO. Cependant, cela PEUT être mis en œuvre en tant que contrat de licence de contributeur (CLA), ou tout autre mécanisme juridique. (URL requise) [dco]

    DCO and signed-off-by expectations are documented in contribution guidelines: https://www.zephyrproject.org/doc/contribute/contribute_guidelines.html and in the GitHub CONTRIBUTING.rst file



    Le projet DOIT définir et documenter clairement son modèle de gouvernance de projet (la façon dont il prend ses décisions, y compris les rôles clés). (URL requise) [governance]

    Le projet DOIT adopter un code de conduite et le publier dans un lieu standard. (URL requise) [code_of_conduct]

    Contributing and Conduct guidelines are found https://www.zephyrproject.org/community/community-guidelines



    Le projet DOIT clairement définir et documenter publiquement les rôles clés dans le projet et leurs responsabilités, y compris les tâches que ces rôles doivent accomplir. Il DOIT être clairement exprimé qui a quel(s) rôle(s), mais cela pourrait ne pas être documenté de la même manière. (URL requise) [roles_responsibilities]

    Le projet DOIT pouvoir continuer avec une interruption minimale si une personne décède, est invalidée ou ne peut/veut plus continuer à maintenir le projet. En particulier, le projet DOIT être en mesure de créer et de fermer des problèmes, d'accepter les modifications proposées et de publier des versions du logiciel, dans un délai d'une semaine après confirmation du retrait d'un individu du projet. Cela PEUT être fait en s'assurant que quelqu'un d'autre possède les clés, les mots de passe et les droits juridiques nécessaires pour poursuivre le projet. Les personnes qui exécutent un projet FLOSS PEUVENT faire cela en fournissant des clés dans un coffre-fort et un testament fournissant les droits légaux nécessaires (par exemple, pour les noms DNS). (URL requise) [access_continuity]

    The project has distributed maintainer and codeowner roles, as found in the GitHub repository CODEOWNER files (https://github.com/zephyrproject-rtos/zephyr/blob/master/CODEOWNERS). There are also multiple administrators for the GitHub site that are authorized to merge pull requests, and the development team is spread around the world (Canada, India, multiple US locations).



    Le projet DEVRAIT avoir un « bus factor » de 2 ou plus. (URL requise) [bus_factor]

    Using the truck-factor tool, we have a TF of 12, see https://github.com/zephyrproject-rtos/zephyr/wiki/Truck-Factor for the output from the tool.


  • Documentation


    Le projet DOIT avoir une feuille de route documentée qui décrit ce que le projet a l'intention de faire et ne pas faire pour au moins l'année suivante. (URL requise) [documentation_roadmap]

    The next 4 planned releases (1 year outlook) are shown here: https://github.com/zephyrproject-rtos/zephyr/projects/9



    Le projet DOIT inclure la documentation de l'architecture (aussi appelée conception de haut niveau) du logiciel produit par le projet. Si le projet ne produit pas de logiciel, sélectionnez « non applicable » (N/A). (URL requise) [documentation_architecture]

    The Zephyr Kernel Primer (https://www.zephyrproject.org/doc/kernel/kernel.html) has an introduction to the kernel's key capabilities and services, along with an overview of the source tree structure.



    Le projet DOIT documenter ce à quoi l'utilisateur peut et ne peut pas s'attendre en termes de sécurité à partir du logiciel produit par le projet (ses « exigences de sécurité »). (URL requise) [documentation_security]

    https://www.zephyrproject.org/doc/security/security-overview.html outlines the steps of the Zephyr Security board towards a defined security process that helps developers build more secure software while addressing security compliance requirements



    Le projet DOIT fournir un guide de « démarrage rapide » pour les nouveaux utilisateurs afin de les aider à faire rapidement quelque chose avec le logiciel. (URL requise) [documentation_quick_start]

    Le projet DOIT faire un effort pour maintenir la documentation conforme à la version actuelle des résultats du projet (y compris les logiciels produits par le projet). Tous les défauts de la documentation connus la rendant incohérente DOIVENT être corrigés. Si la documentation est généralement à jour, mais inclut de manière erronée certaines informations antérieures qui ne sont plus vraies, considérez cela comme un défaut, puis faites le suivi et corrigez comme d'habitude. [documentation_current]

    Documentation is maintained and released with each tagged release of the software (e.g., https://www.zephyrproject.org/doc/1.8.0/ for the 1.8 release). Additionally, the master branch documentation is updated and maintained at https://www.zephyrproject.org/doc. Documentation defects are tracked along with code defects in our Jira (soon to be GitHub issues) system.



    La page d'accueil et/ou le site Web du dépôt du projet DOIVENT identifier et pointer tous les accomplissements, y compris ce badge sur les meilleures pratiques, dans les 48 heures suivant la reconnaissance publique que l'accomplissement a été atteint. (URL requise) [documentation_achievements]

    https://github.com/zephyrproject-rtos/zephyr has the cii best practices badge and the announcement page (https://www.zephyrproject.org/news/announcements) mentions project achievements.


  • Accessibilité et internationalisation


    Le projet (à la fois les sites du projet et les résultats du projet) DEVRAIT suivre les meilleures pratiques d'accessibilité afin que les personnes handicapées puissent encore participer au projet et utiliser les résultats du projet où il est raisonnable de le faire. [accessibility_best_practices]

    Zephyr is an embedded OS without any user interface or textual output. This can come as part of an application on top of Zephyr, but zephyr itself does not have any end-user facing interface that needs to be internationalised.



    Le logiciel produit par le projet DEVRAIT être internationalisé pour permettre une localisation facile pour la culture, la région ou la langue du public cible. Si l'internationalisation (i18n) ne s'applique pas (par exemple, le logiciel ne génère pas de texte destiné aux utilisateurs finaux et ne trie pas de texte lisible par les humains), sélectionnez « non applicable » (N/A). [internationalization]

    Zephyr is an embedded OS without any user interface or textual output. This can come as part of an application on top of Zephyr, but zephyr itself does not have any end-user facing interface that needs to be internationalised.


  • Autre


    Si les sites du projet (site Web, dépôt et URL de téléchargement) entreposent des mots de passe pour l'authentification d'utilisateurs externes, les mots de passe DOIVENT être entreposés comme hachages itérés avec salage par utilisateur en utilisant un algorithme d'étirement des clés (itéré) (par exemple, Argon2id, Bcrypt, Scrypt, ou PBKDF2). Si les sites du projet n'entreposent pas de mots de passe à cette fin, sélectionnez « non applicable » (N/A). [sites_password_security]

    Website is not available for external users. Github and other services used do use a 2 factor authentication for all contributors.


  • Versions précédentes


    Le projet DOIT maintenir les anciennes versions les plus utilisées du produit ou fournir un chemin de mise à niveau vers des versions plus récentes. Si le chemin de mise à niveau est difficile, le projet DOIT documenter comment effectuer la mise à niveau (par exemple, les interfaces qui ont changé et une suggestion d'étapes détaillées pour aider la mise à niveau). [maintenance_or_update]

    Previous software releases are available from https://www.zephyrproject.org/downloads. A plan for Long-Term-Support (LTS) support is in progress.


  • Procédure de signalement des bogues


    Le projet DOIT utiliser un suivi des problèmes pour le suivi des problèmes individuels. [report_tracker]
  • Processus de signalement de vulnérabilité


    Le projet DOIT créditer les auteurs de tous les signalements de vulnérabilité résolus au cours des 12 derniers mois, à l'exception des auteurs qui demandent l'anonymat. S'il n'y a pas eu de vulnérabilité résolue au cours des 12 derniers mois, sélectionnez « non applicable » (N/A). (URL requise) [vulnerability_report_credit]

    All changes to software are submitted through the GitHub pull request process and logged and reviewed there: https://github.com/zephyrproject-rtos/zephyr/pulls. Git log tools can be used to generate detailed reports, as well as summaries on https://github.com/zephyrproject-rtos/zephyr/pulse for insights.



    Le projet DOIT avoir un processus documenté pour répondre aux signalements de vulnérabilité. (URL requise) [vulnerability_response_process]
  • Normes de codage


    Le projet DOIT identifier les guides de style de codage spécifiques pour les langages principaux qu'il utilise, et exiger que les contributions le respectent en général. (URL requise) [coding_standards]

    The project contribution guidelines include coding standards and tools for verifying: https://www.zephyrproject.org/doc/contribute/contribute_guidelines.html#coding-style



    Le projet DOIT imposer automatiquement son ou ses styles de codage sélectionnés s'il existe au moins un outil FLOSS qui peut le faire dans le(s) langage(s) sélectionné(s). [coding_standards_enforced]

    gitlint and checkpatch tools automatically verify and enforce coding standards, as documented in https://www.zephyrproject.org/doc/contribute/contribute_guidelines.html#coding-style


  • Système de construction opérationnel


    Les systèmes de construction pour les binaires natifs DOIVENT honorer les variables (d'environnement) pertinentes du compilateur et du lieur qui leur sont transmises (par exemple, CC, CFLAGS, CXX, CXXFLAGS et LDFLAGS) et les transmettre aux invocations du compilateur et du lieur. Un système de construction PEUT les étendre avec des options supplémentaires ; il NE DOIT PAS simplement remplacer les valeurs fournies par les siennes. Si aucun fichier binaire natif n'est généré, sélectionnez « non applicable » (N/A). [build_standard_variables]

    We're using CMake to generate binaries which does support the above and does honor environment variables.



    Le système de construction et d'installation DEVRAIT préserver les informations de débogage si elles sont demandées dans les options correspondants (par exemple, « install -s » n'est pas utilisé). S'il n'y a pas de système de construction ou d'installation (par exemple, les bibliothèques JavaScript typiques), sélectionnez « non applicable » (N/A). [build_preserve_debug]

    The generated ELF has debugging information, however the binary installed to the final platform may not preserve this information.



    Le système de construction pour le logiciel produit par le projet NE DOIT PAS reconstruire de manière récursive des sous-répertoires s'il existe des dépendances croisées dans les sous-répertoires. S'il n'y a pas de système de construction ou d'installation (par exemple, les bibliothèques JavaScript typiques), sélectionnez « non applicable » (N/A). [build_non_recursive]

    Any cross dependencies will cause a rebuild of the dependent component.



    Le projet DOIT pouvoir répéter le processus de génération d'informations à partir de fichiers source et obtenir exactement le même résultat bit-à-bit. Si aucune construction ne se produit (par exemple, dans les langages de script où le code source est utilisé directement au lieu d'être compilé), sélectionnez « non applicable » (N/A). [build_repeatable]

    Rebuilding binaries that have no variable data such as timestamps results in the same bit-for-bit output, this is verified by building a binary for a certain configuration multiple times and comparing check-sums of generated binaries and all other output.


  • Système d'installation


    Le projet DOIT fournir un moyen d'installer et de désinstaller facilement le logiciel produit par le projet en utilisant une convention couramment utilisée. [installation_common]

    The build system provides a common method for installing on all target platforms.



    Le système d'installation pour les utilisateurs finaux DOIT honorer les conventions standard pour sélectionner l'emplacement où les artefacts construits sont écrits au moment de l'installation. Par exemple, s'il installe des fichiers sur un système POSIX, il DOIT honorer la variable d'environnement DESTDIR. S'il n'y a pas de système d'installation ou pas de convention standard, sélectionnez « non applicable » (N/A). [installation_standard_variables]

    We install the compiled image in a platform-specific way (e.g., to flash)



    Le projet DOIT fournir un moyen pour les développeurs potentiels d'installer rapidement tous les résultats du projet ainsi que l'environnement nécessaire pour apporter des modifications, y compris les tests et l'environnement de test. Cela DOIT être effectué avec une convention couramment utilisée. [installation_development_quick]

    We have getting started guides for Linux, Windows, and MacOS


  • Composants maintenus à l'extérieur


    Le projet DOIT afficher ses dépendances externes de manière analysable par ordinateur. (URL requise) [external_dependencies]

    Note: this is about installation of items that are needed to use and build zephyr, see requirement above.

    External components are identified in the /ext area in GitHub: https://github.com/zephyrproject-rtos/zephyr/tree/master/ext but those are not "installed", they are part of the source. For external dependencies need to build and test the project we have scripts/requirements.txt (https://github.com/zephyrproject-rtos/zephyr/blob/master/scripts/requirements.txt).



    Les projets DOIVENT surveiller ou vérifier périodiquement leurs dépendances externes (y compris les copies de commodité) pour détecter les vulnérabilités connues, et corriger les vulnérabilités exploitables ou les vérifier comme inexploitables. [dependency_monitoring]

    see https://github.com/zephyrproject-rtos/zephyr/issues/6533, one step of the release process is to verify for known vulnerabilities



    Le projet DOIT :
    1. rendre facile l'identification et la mise à jour des composants maintenus extérieurement au projet ; ou
    2. utiliser des composants standards fournis par le système ou le langage de programmation.
    Ensuite, si une vulnérabilité se trouve dans un composant réutilisé, il sera facile de mettre à jour ce composant. [updateable_reused_components]

    External components are self-contained without any modifications or local changes, we maintain information about the source and origin of such components and track the used versions and SHAs in case of git repositories. Updating to a new component is in most cases a drop-in replacement of existing code. We will support external components in external repos. Additional, wherever we have local modifications, we maintain a fork of the original trees and keep the trees up-to-date with upstream. Local modification are submitted upstream where applicable, this is a policy of the project.



    Le projet DEVRAIT éviter d'utiliser des fonctions et des API obsolètes quand des alternatives FLOSS sont disponibles dans l'ensemble de technologies qu'il utilise (sa « pile de technologies ») et disponibles à une large majorité des utilisateurs supportés par le projet (afin que les utilisateurs puissent avoir accès à l'alternative). [interfaces_current]

    The project is self-contained and does use minimal external APIS, mostly from libc. We verify usage of those APIs on constant basis and remove any obsolete usage when found or reported.


  • Suite de tests automatisée


    Une suite de tests automatisée DOIT être appliquée à chaque commit dans un dépôt partagé pour au moins une branche. Cette suite de tests DOIT produire un rapport sur le succès ou l'échec du test. [automated_integration_testing]

    Each commit/Pull Request requires passing a series of sanity checks, including building documentation, driven by the "shippable" tool: https://app.shippable.com/github/zephyrproject-rtos/zephyr/dashboard



    Le projet DOIT ajouter des tests de régression à une suite de tests automatisée pour au moins 50% des bogues corrigés au cours des six derniers mois. [regression_tests_added50]

    Issues that are marked with regression label (https://github.com/zephyrproject-rtos/zephyr/labels/Regression) will be added to automated test-suite and integration tests that run through CI where applicable.



    Le projet DOIT avoir une ou des suites de tests automatisées FLOSS qui fournissent une couverture d'instructions d'au moins 80% s'il existe au moins un outil FLOSS qui peut mesurer ce critère dans le langage sélectionné. [test_statement_coverage80]

    We use gcov/lcov to measure coverage of core features of the project. Due to the fact that Zephyr is an RTOS that can't be run with all features enabled on a host system, the coverage of some areas is not measured yet, the kernel however is being measured and has coverage of 80% in the supported configuration and where measurement is possible. Coverage reports can be found here: https://codecov.io/gh/zephyrproject-rtos/zephyr


  • Nouveau test de fonctionnalité


    Le projet DOIT avoir une politique écrite formelle, que dès qu'une nouvelle fonctionnalité majeure est ajoutée, des tests pour la nouvelle fonctionnalité DOIVENT être ajoutés à une suite de tests automatisée. [test_policy_mandated]

    Policy for adding new functionality and the requirements on tests can be seen here: https://github.com/zephyrproject-rtos/zephyr/blob/master/CONTRIBUTING.rst



    Le projet DOIT inclure, dans ses instructions documentées pour les propositions de changement, la politique selon laquelle des tests doivent être ajoutés pour toute nouvelle fonctionnalité majeure. [tests_documented_added]
  • Options d'avertissement


    Les projets DOIVENT être maximalement stricts avec les avertissements dans le logiciel produit par le projet, quand cela est approprié. [warnings_strict]

    Build system statically compiles and fails when met with warnings. CI also catch potential issues before being accepted into the code.


  • Connaissance du développement sécurisé


    Le projet DOIT implémenter des principes de conception sécurisés (à partir de « know_secure_design »), quand cela est approprié. Si le projet ne produit pas de logiciel, sélectionnez « non applicable » (N/A). [implement_secure_design]
  • 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 .

    Les mécanismes de sécurité par défaut dans le logiciel produit par le projet NE DOIVENT 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]

    There are no default usages for weak crypto, SSH is not being used and is not supported.



    Le projet DEVRAIT supporter plusieurs algorithmes cryptographiques, afin que les utilisateurs puissent rapidement changer si l'un deux est cassé. Les algorithmes à clés symétriques courants incluent AES, Twofish et Serpent. Les alternatives d'algorithme de hachage cryptographique courantes incluent SHA-2 (y compris SHA-224, SHA-256, SHA-384 ET SHA-512) et SHA-3. [crypto_algorithm_agility]

    Through the support of mbedTLS and tinyCrypt, users and developers have a variety of algorithms to choose from.



    Le projet DOIT supporter le stockage des informations d'authentification (comme les mots de passe et les jetons dynamiques) et des clés cryptographiques privées dans des fichiers distincts des autres informations (fichiers de configuration, bases de données et journaux) et permettre aux utilisateurs de les mettre à jour et de les remplacer sans recompilation de code. Si le projet ne traite jamais d'informations d'authentification et de clés cryptographiques privées, sélectionnez « non applicable » (N/A). [crypto_credential_agility]

    This is application specific and is out of scope for the project. Mechanism to support this requirement are provided in general terms. Application developer will have to follow best practices for their use-case.



    Le logiciel produit par le projet DEVRAIT 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 DEVRAIENT ê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). [crypto_used_network]

    We support TLS and DTLS for all communication protocols. HTTPS, COAPS and any other protocols can be abled with additional security enabled.



    Le logiciel produit par le projet DEVRAIT, 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). [crypto_tls12]

    All configurations of the project use TLS 12 by default:

    lib/crypto/mbedtls/configs/config-ccm-psk-tls1_2.h:#define MBEDTLS_SSL_PROTO_TLS1_2 ext/lib/crypto/mbedtls/configs/config-coap.h:#define MBEDTLS_SSL_PROTO_TLS1_2 ext/lib/crypto/mbedtls/configs/config-mini-dtls1_2.h:#define MBEDTLS_SSL_PROTO_TLS1_2 ext/lib/crypto/mbedtls/configs/config-mini-tls1_2.h:#define MBEDTLS_SSL_PROTO_TLS1_2 ext/lib/crypto/mbedtls/configs/config-threadnet.h:#define MBEDTLS_SSL_PROTO_TLS1_2

    https://github.com/zephyrproject-rtos/zephyr/tree/master/ext/lib/crypto/mbedtls/configs



    Le logiciel produit par le projet DOIT, s'il prend en charge TLS, effectuer la vérification des certificats TLS par défaut lors de l'utilisation de TLS, y compris sur les sous-ressources. Si le logiciel n'utilise pas TLS, sélectionnez « non applicable » (N/A). [crypto_certificate_verification]

    The project contains a sample application that is located at the primary repository located at: https://github.com/zephyrproject-rtos/zephyr The sample application implements a proper TLS secure connection and publishes data to the Google Cloud.



    Le logiciel produit par le projet DOIT, s'il supporte TLS, effectuer une vérification de certificat avant d'envoyer des en-têtes HTTP avec des informations privées (telles que des cookies sécurisés). Si le logiciel n'utilise pas TLS, sélectionnez « non applicable » (N/A). [crypto_verification_private]

    The project contains a sample application that is located at the primary repository located at: https://github.com/zephyrproject-rtos/zephyr The sample application implements a proper TLS secure connection and publishes data to the Google Cloud.


  • Livraison sécurisée


    Le projet DOIT signer cryptographiquement les versions des résultats du projet destinées à une utilisation répandue, et il DOIT y avoir un processus documenté expliquant aux utilisateurs comment ils peuvent obtenir les clés de signature publique et vérifier la ou les signatures. La clé privée pour ces signature(s) NE DOIT PAS être sur le(s) site(s) utilisé(s) pour distribuer directement le logiciel au public. Si les versions ne sont pas destinées à une utilisation répandue, sélectionnez « non applicable » (N/A). [signed_releases]

    We don't do binary distributions and Git provides a secure release history.



    Il est PROPOSÉ que, dans le système de contrôle de la version, chaque tag d'une version importante (un tag faisant partie d'une version majeure, d'une version mineure ou qui corrige des vulnérabilités notées publiquement) soit cryptographiquement signé et vérifiable comme décrit dans signed_releases. [version_tags_signed]

    Starting with release 1.12, the releases are now being signed by keys of recognized developers & maintainers.


  • Autres problèmes de sécurité


    Les résultats du projet DOIVENT vérifier toutes les entrées provenant de sources potentiellement non fiables pour s'assurer qu'elles sont valides (une liste blanche) et rejeter les entrées non valides, en cas de restrictions sur les données. [input_validation]

    The project does not have user interfaces that would allow user input by default, so this is out of scope. If those interfaces are added by the developer/user they need to follow our secure coding practices document in the project here: http://docs.zephyrproject.org/security/security.html



    Les 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é. [hardening]

    We do build by default with -Wformat -Wformat-security -Wno-format-zero-length and stack-protector is enabled as an option where supported. It is disabled by default for performance reasons but can be enabled by the user. The master CMake file contents show this to be the case:

    https://github.com/zephyrproject-rtos/zephyr/blob/master/CMakeLists.txt



    Le projet DOIT fournir une analyse de fiabilité qui justifie pourquoi ses exigences de sécurité sont respectées. L'analyse de fiabilité DOIT inclure : une description du modèle de menace, une identification claire des limites de confiance, un argument selon lequel des principes de conception sécurisés ont été appliqués et un argument selon lequel les faiblesses de sécurité courantes de l'implémentation ont été contrées. (URL requise) [assurance_case]

    The project maintains documentation of current threat models, identification of assets, and trust boundaries. The documentation also provides coding and development guidelines intended to mitigate threats.

    See: https://docs.zephyrproject.org/latest/security/secure-coding.html


  • Analyse statique de code


    Le projet DOIT utiliser au moins un outil d'analyse statique avec des règles ou des approches pour rechercher des vulnérabilités courantes dans le langage ou l'environnement analysé, s'il existe au moins un outil FLOSS qui peut mettre en œuvre ce critère dans le langage sélectionné. [static_analysis_common_vulnerabilities]
  • Analyse dynamique de code


    Si le logiciel produit par le projet inclut un logiciel écrit à l'aide d'un langage non sûr pour les accès mémoire (par exemple C ou C++), alors le projet DOIT utiliser au moins un outil dynamique (par exemple, un fuzzer ou un scanneur d'application Web) utilisé de manière routinière en combinaison avec un mécanisme permettant de détecter des problèmes de sécurité mémoire tels que les dépassement mémoire. Si le projet ne produit pas de logiciel écrit dans un langage non sûr pour les accès mémoire, sélectionnez « non applicable » (N/A). [dynamic_analysis_unsafe]

    Software is not application-level.



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 Brett Preston et les contributeurs du badge des meilleures pratiques de la OpenSSF.

Soumission du badge du projet appartenant à : Brett Preston.
Soumission créée le 2016-03-10 17:42:23 UTC, dernière mise à jour le 2024-06-05 17:27:55 UTC. Le dernier badge perdu l'a été le 2018-03-10 20:49:56 UTC. Le dernier badge obtenu l'a été le 2018-03-10 20:50:26 UTC.

Retour