pointblank

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 4310 est passing 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 15/17 ●

  • Identification

    The pointblank R package lets people easily validate data in data frames, 'tibble' objects, Spark DataFrames, and database tables (e.g., 'PostgreSQL' and 'MySQL'). Validation pipelines can be made using easily-readable, consecutive validation steps. Upon execution of the validation plan, several reporting options are available. The package also facilitates an information management workflow, where the aim is to record, collect, and generate useful information on data tables.

  • Conditions préalables


    Assez pour un badge !

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

  • Contenu basique du site Web du projet


    Assez pour un badge !

    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]

    The pull request template at https://github.com/rich-iannone/pointblank/blob/main/.github/PULL_REQUEST_TEMPLATE.md has a checklist of requirements for an acceptable contribution.


  • Supervision du projet


    Assez pour un badge !

    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]

    A Contributor License Agreement (CLA) is enforced for all contributors outside of the core team. This is implemented via a Github Actions workflow (https://github.com/rich-iannone/pointblank/blob/main/.github/workflows/cla.yml). With every pull request from outside the core team, a 'signature' is required before merging is allowed to occur.


    Assez pour un badge !

    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]

    Governance is outlined in the project README.md file (https://github.com/rich-iannone/pointblank/blob/master/README.md#%EF%B8%8F-governance).


    Assez pour un badge !

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

    The adherence to a code of conduct is stated in the project README on GitHub (https://github.com/rich-iannone/pointblank#code-of-conduct), on the main page of the project website (https://rich-iannone.github.io/pointblank/), and in the interface for a pull request (https://github.com/rich-iannone/pointblank/blob/master/.github/PULL_REQUEST_TEMPLATE.md). The pointblank project adopts the Contributor Code of Conduct from https://www.contributor-covenant.org/version/1/0/0/code-of-conduct/.


    Assez pour un badge !

    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]

    This is stated in the package DESCRIPTION file (https://github.com/rich-iannone/pointblank/blob/18688d816c23651682bb83e5e41d0591880d16c1/DESCRIPTION#L13), where authors are assigned roles. It is understood that the "cre" role signifies the maintainer, which is the main decision maker for the project and only person that communicates with CRAN.


    Assez pour un badge !

    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]

    There is a second author and maintainership (with all its powers, including submitting new versions of the package to CRAN) can be moved swiftly in the case that the maintainer cannot continue with development (https://github.com/rich-iannone/pointblank/blob/18688d816c23651682bb83e5e41d0591880d16c1/DESCRIPTION#L13).


    Assez pour un badge !

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

    There are currently two authors involved in the project (https://github.com/rich-iannone/pointblank/blob/18688d816c23651682bb83e5e41d0591880d16c1/DESCRIPTION#L13).


  • Documentation


    Assez pour un badge !

    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]

    At the bottom of the README.md file there is an automatically-generated table that outlines the major tasks for the next three versions of the package (https://github.com/rich-iannone/pointblank/blob/master/README.md). This easily encompasses a year of work.


    Informations inconnues requises, pas assez pour un badge.

    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]

    Informations inconnues requises, pas assez pour un badge.

    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]

    Assez pour un badge !

    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]

    The pointblank package has an introductory article in the project website (https://rich-iannone.github.io/pointblank/articles/intro-to-pointblank.html).


    Assez pour un badge !

    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]

    The project takes its documentation seriously and uses roxygen2 (https://roxygen2.r-lib.org) to in-line function documentation with the source code. During package checks (performed often, part of continuous integration), R CMD check looks for missing documentation entries for exported functions (e.g., missing description, arguments with no explanations). The project maintainers go beyond this and ensure that changes are immediately reflected in the documentation.


    Assez pour un badge !

    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]

    There are several status badges in the project README (https://github.com/rich-iannone/pointblank) that immediately reflect any changed statuses (including the best practices badges). These badges are also shown on the project website (https://rich-iannone.github.io/pointblank/index.html).


  • Accessibilité et internationalisation


    Assez pour un badge !

    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]

    The project website (https://rich-iannone.github.io/pointblank/index.html) is accessible through screen readers and the graphics are (1) large, (2) contain contrast, (3) have alt text. The GitHub repository is also accessible and can be navigated via the keyboard.


    Assez pour un badge !

    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]

    The package contains functions for reporting and those all contain "lang" and "locale" arguments for translations and formatting values specific to a chosen locale (over 700 available). The text at https://rich-iannone.github.io/pointblank/index.html#table-scans demonstrates that reporting is translated to eight languages currently (with more on the way).


  • Autre


    Assez pour un badge !

    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]

    The project site does not allow for logins.


  • Versions précédentes


    Assez pour un badge !

    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]

    Older versions of pointblank are available as tagged releases in GitHub (https://github.com/rich-iannone/pointblank/releases). The source for each release can be downloaded or installed though devtools::install_github("rich-iannone/pointblank@<release_tag>"). The upgrade path is typically easy as the installation mechanism will automatically update dependent packages while installing pointblank.


  • Procédure de signalement des bogues


    Assez pour un badge !

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

    Issue tracker: https://github.com/rich-iannone/pointblank/issues


  • Processus de signalement de vulnérabilité


    Assez pour un badge !

    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]

    The NEWS.md file (https://github.com/rich-iannone/pointblank/blob/master/NEWS.md) provides credit for reporters and for contributors. If the reporter requests anonymity, that will be honored.


    Assez pour un badge !

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

    Any vulnerability reports can be made though the issue tracker (https://github.com/rich-iannone/pointblank/issues). Should the reporter want to do so anonymously, the project maintainer can be reached through the posted email address (https://github.com/rich-iannone/pointblank/blob/18688d816c23651682bb83e5e41d0591880d16c1/DESCRIPTION#L14).


  • Normes de codage


    Assez pour un badge !

    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]

    In the project README, it is stated that pointblank is "...developing an API that closely follows tidyverse conventions by adhering to the tidyverse style guide" (https://github.com/rich-iannone/pointblank#how-pointblank-fits-in-with-other-packages-that-validate-tabular-data). The pull request template additionally requires that PRs comply with the testing guidelines (https://github.com/rich-iannone/pointblank/blob/master/.github/PULL_REQUEST_TEMPLATE.md).


    Assez pour un badge !

    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]

    The lintr package (https://github.com/jimhester/lintr) is invoked by a GitHub Actions workflow (https://github.com/rich-iannone/pointblank/blob/master/.github/workflows/lint.yaml) for every commit and pull request. The lints check specifically for adherence to the coding style used in the project. If any lints are found, the maintainer is notified via email and CI correspondingly fails. This status is also transparent in the 'lint' badge shown in the project repository README.md (on GitHub) and in the project website (https://rich-iannone.github.io/pointblank/).


  • Système de construction opérationnel


    Assez pour un badge !

    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]

    There are no native binaries produced in this project.


    Assez pour un badge !

    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]

    Installation though the common mechanisms for R packages does allow for preservation of debugging information.


    Assez pour un badge !

    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]

    The build system for R packages does not recursively build subdirectories.


    Assez pour un badge !

    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]

    Building from source is reproducible.


  • Système d'installation


    Assez pour un badge !

    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]

    Installation and uninstallation for R packages like pointblank can be done through install.packages() and remove.packages().


    Assez pour un badge !

    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]

    Installation via install.packages() places the built artifacts in the system R package library. This location is discoverable in the R console by invoking .Library.


    Assez pour un badge !

    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]

    This can be done easily by cloning the source via git (or downloading the project .zip file, available in GitHub) and building the package locally via R CMD build.


  • Composants maintenus à l'extérieur


    Assez pour un badge !

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

    All dependencies are listed by convention in the package's DESCRIPTION file (https://github.com/rich-iannone/pointblank/blob/18688d816c23651682bb83e5e41d0591880d16c1/DESCRIPTION#L26). This file is processed by the R package building system.


    Assez pour un badge !

    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]

    External packages are inspected by the maintainer periodically to ensure that vulnerabilities are fixed in a timely manner. Packages that are external dependencies can be removed from the CRAN repository (e.g., for failing checks on the CRAN check system) and the maintainer of pointblank is aware of this possibility and has strategies to work around this.


    Assez pour un badge !

    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]

    We can identify which externally-maintained components (all of which are other R packages) by inspecting the DESCRIPTION file. These can be easily updated by either using install.packages() or devtools::update_packages().


    Assez pour un badge !

    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 only uses functions from well-maintained R packages as dependencies. It avoids using functions marked as deprecated.


  • Suite de tests automatisée


    Assez pour un badge !

    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]

    GitHub Actions (with three workflows) is used with every commit (including commits on other branches and in PRs). Rigorous checks are applied with each of those workflows. Any failure is reported to the maintainer.


    Assez pour un badge !

    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]

    Tests are added to the test suite for all bug fixes.


    Assez pour un badge !

    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]

    One of the GitHub Actions workflows checks for code coverage from the test suite and sends the report to a third-party for further reporting and badge generation. We display the code coverage badge on the project README and code coverage must at least be 80%.


  • Nouveau test de fonctionnalité


    Assez pour un badge !

    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]

    Upon pull request creation, the checklist that users see contains an item that requires "...unit tests to tests/testthat for any new functionality" (https://github.com/rich-iannone/pointblank/blob/master/.github/PULL_REQUEST_TEMPLATE.md). Project authors must also abide by this rule.


    Assez pour un badge !

    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]

    In the pull request instructions (https://github.com/rich-iannone/pointblank/blob/main/.github/PULL_REQUEST_TEMPLATE.md), there is a checklist item that expresses the requirement for new tests to be added with the proposed changes.


  • Options d'avertissement


    Assez pour un badge !

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

    The GitHub Actions workflow for checking the package (with R CMD check) is configured to fail if any warnings are detected (https://github.com/rich-iannone/pointblank/blob/18688d816c23651682bb83e5e41d0591880d16c1/.github/workflows/R-CMD-check.yaml#L76).


  • Connaissance du développement sécurisé


    Assez pour un badge !

    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]

    This is out of scope for pointblank and other R packages that do not explicitly focus on privacy and security.


  • 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 !

    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]

    This is out of scope for pointblank and other R packages that do not explicitly focus on privacy and security.


    Assez pour un badge !

    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]

    This is out of scope for pointblank and other R packages that do not explicitly focus on privacy and security.


    Assez pour un badge !

    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 out of scope for pointblank and other R packages that do not explicitly focus on privacy and security.


    Assez pour un badge !

    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]

    This is out of scope for pointblank and other R packages that do not explicitly focus on privacy and security.


    Assez pour un badge !

    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]

    This is out of scope for pointblank and other R packages that do not explicitly focus on privacy and security.


    Assez pour un badge !

    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]

    This is out of scope for pointblank and other R packages that do not explicitly focus on privacy and security.


    Assez pour un badge !

    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]

    This is out of scope for pointblank and other R packages that do not explicitly focus on privacy and security.


  • Livraison sécurisée


    Assez pour un badge !

    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]

    Releases are signed on GitHub with a verified signature using GitHub’s key (https://github.com/rich-iannone/pointblank/tags).


    Assez pour un badge !

    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]

    Version tags are signed on GitHub with a verified signature using GitHub’s key (https://github.com/rich-iannone/pointblank/tags).


  • Autres problèmes de sécurité


    Assez pour un badge !

    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]

    This is out of scope for pointblank and other R packages that do not explicitly focus on privacy and security.


    Assez pour un badge !

    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]

    This is out of scope for pointblank and other R packages that do not explicitly focus on privacy and security.


    Assez pour un badge !

    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]

    This is out of scope for pointblank and other R packages that do not explicitly focus on privacy and security. However, assurance will be added to the README (https://github.com/rich-iannone/pointblank/blob/master/README.md) should this become important.


  • Analyse statique de code


    Assez pour un badge !

    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]

    The lintr package (https://github.com/jimhester/lintr) is invoked by a GitHub Actions workflow (https://github.com/rich-iannone/pointblank/blob/main/.github/workflows/lint.yaml) for every commit and pull request. If any lints are found, the maintainer is notified via email and CI correspondingly fails. This status is also transparent in the 'lint' badge shown in the project repository README.md (on GitHub) and in the project website (https://rich-iannone.github.io/pointblank/).


  • Analyse dynamique de code


    Assez pour un badge !

    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]

    The pointblank package is entirely implemented in R and as such it does not use any memory-unsafe language.



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

Soumission du badge du projet appartenant à : Richard Iannone.
Soumission créée le 2020-09-30 13:14:57 UTC, dernière mise à jour le 2022-02-02 03:54:59 UTC. Le dernier badge obtenu l'a été le 2020-09-30 14:41:58 UTC.

Retour