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 Basique. Vous pouvez également afficher les critères des niveaux Argent ou Or.

        

 Notions de base 13/13

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

    Quel(s) langage(s) de programmation sont utilisés pour implémenter le projet ?
  • Contenu basique du site Web du projet


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

    The page at https://rich-iannone.github.io/pointblank gives an overview of the package, which problems the software is good at addressing, and several introductory-level examples.



    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]

    The project website provides information on all of this. In the 'Installation' section (https://rich-iannone.github.io/pointblank/#installation), instructions are provided on how to install the CRAN version of the package and the in-development version. The final sentence invites users to report bugs, ask questions about usage, and share ideas for new features in the GitHub Issues page (link provided in sentence).



    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]

    Projects on GitHub by default use issues and pull requests, as encouraged by documentation such as https://guides.github.com/activities/contributing-to-open-source/.



    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 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.


  • Licence FLOSS

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



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

    MIT attribution: https://github.com/rich-iannone/pointblank/blob/e132043ba806873aa20c1a0d60a3960c14e81c64/DESCRIPTION#L19. The MIT license is approved by the Open Source Initiative (OSI).



    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 MIT license his approved by the Open Source Initiative (OSI). The MIT license is approved by the Open Source Initiative (OSI).



    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]

    Non-trivial license location file in repository: https://github.com/rich-iannone/pointblank/blob/main/LICENSE.md. Further to this, the DESCRIPTION file (required for all R packages) specifies the license used for the package (MIT attribution: https://github.com/rich-iannone/pointblank/blob/e132043ba806873aa20c1a0d60a3960c14e81c64/DESCRIPTION#L19).


  • Documentation


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

    There is full documentation for the package functions and an introductory article available in the project website (https://rich-iannone.github.io/pointblank/). The Reference section of the project website (https://rich-iannone.github.io/pointblank/reference/index.html) arranges the package functions into families with descriptions of each function family. Additionally, help for each function can be obtained by using help(<function name>) in the R console.



    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]

    The manual available at (https://rich-iannone.github.io/pointblank/ goes into detail about the interface, and the help files at https://github.com/rich-iannone/pointblank/tree/main/man document and demonstrate every exported function in full detail. The man folder is the standard way to document exported functions and data objects in an R package.


  • Autre


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

    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]

    GitHub supports discussions on issues and pull requests.



    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]

    Le projet DOIT être maintenu. [maintained]


(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


    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]

    Repository on GitHub, which provides public git repositories with URLs.



    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]

    Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.



    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]

    The GitHub releases at https://github.com/rich-iannone/pointblank/releases include multiple interim development releases.



    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]

    Repository on GitHub, which uses git. git is distributed.


  • Numérotation unique de la version


    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]

    The pointblank package follows the versioning guide at http://r-pkgs.had.co.nz/release.html#release-version, the community accepted variant of semantic versioning for R packages.



    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]


    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]

    All releases (viewable at https://github.com/rich-iannone/pointblank/releases) have a git/GitHub tag.


  • Notes de version


    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]

    Non-trivial release notes file in repository: https://github.com/rich-iannone/pointblank/blob/main/NEWS.md.



    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]
  • Procédure de signalement des bogues


    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]

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

    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]

    The issue tracker contains all bug reports: https://github.com/rich-iannone/pointblank/issues



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

    The issue tracker contains all feature requests: https://github.com/rich-iannone/pointblank/issues. Feature requests are tagged as Enhancements and are usually successfully implemented.



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

    The issue tracker at https://github.com/rich-iannone/pointblank/issues has the complete archive of all the reports and responses. It is easily searchable.


  • Processus de signalement de vulnérabilité


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

    Vulnerabilities fall under bugs for this project. The place to report them is https://github.com/rich-iannone/pointblank/issues, and the contact information of the maintainer is available in https://github.com/rich-iannone/pointblank/blob/main/DESCRIPTION.



    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 contact information of the maintainer is at https://github.com/rich-iannone/pointblank/blob/main/DESCRIPTION.



    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]

    All responses to issues are considerably faster than 14 days. Please refer to the discussion logs at https://github.com/rich-iannone/pointblank/issues.


  • Système de construction opérationnel


    Si le logiciel produit par le projet nécessite d'être construit pour être utilisé, le projet DOIT fournir un système de construction fonctionnel qui peut reconstruire automatiquement le logiciel à partir du code source. [build]

    Using the instructions available at https://rich-iannone.github.io/pointblank/#installation (under "...install the development version"), users can install the package from source.



    Il est PROPOSÉ d'utiliser des outils courants pour la construction du logiciel. [build_common_tools]

    See the instructions available at https://rich-iannone.github.io/pointblank/#installation. The two most common tools for installing R packages (install.packages() and devtools::install_github()) can be used for pointblank.



    Le projet DEVRAIT être constructible en utilisant uniquement des outils FLOSS. [build_floss_tools]

    The pointblank package only requires formally released R packages on CRAN http://cran.r-project.org/ to install.


  • Suite de tests automatisée


    Le projet DOIT utiliser au moins une suite de tests automatisée publiée publiquement comme FLOSS (cette suite de tests peut être maintenue sous la forme d'un projet FLOSS distinct). Le projet DOIT clairement montrer ou documenter comment exécuter la ou les suites de tests (par exemple, via un script d'intégration continue (CI) ou via la documentation dans des fichiers tels que BUILD.md, README.md ou CONTRIBUTING.md). [test]

    Une suite de tests DEVRAIT être invocable d'une manière standard pour ce langage. [test_invocation]

    The tests are in the standard format for R packages. Using the testthat package (http://github.com/r-lib/testthat), it is easy to run the tests. Standard R package quality checks run these tests, as do testthat::test_package() and devtools::test(). This is the de facto standard for R packages.



    Il est PROPOSÉ que la suite de tests couvre la plupart (ou idéalement toutes) les branches du code, les champs de saisie et les fonctionnalités. [test_most]

    The tests run by testthat::test_package()/devtools::test() under the default settings run nearly every line of code in the package. The test results are sent to a 3rd party service for reporting on code coverage, a metric that is taken very seriously for this project.



    Il est PROPOSÉ que le projet utilise 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). [test_continuous_integration]

    The pointblank package uses GitHub Actions to run R CMD check (a comprehensive set of tests for the package) with each commit and pull request (https://github.com/rich-iannone/pointblank/actions?query=workflow%3AR-CMD-check). Merging doesn't typically occur unless all CI checks pass.


  • Nouveau test de fonctionnalité


    Le projet DOIT avoir une politique générale (formelle ou non) qui spécifie que, dès qu'une nouvelle fonctionnalité majeure est ajoutée au logiciel produit par le projet, des tests de cette fonctionnalité devraient être ajoutés à une suite de tests automatisée. [test_policy]

    New tests for the functionality are added to the existing unit test suite, and these tests are checked with continuous integration (GitHub Actions) in a pull request before being merged into the project.



    Le projet DOIT avoir la preuve que la politique de test pour l'ajout de tests a été respectée dans les dernières modifications majeures apportées au logiciel produit par le projet. [tests_are_added]

    Evidence for the testing policy is available in the pull requests page (https://github.com/rich-iannone/pointblank/pulls) and also in the commit history (https://github.com/rich-iannone/pointblank/commits/main).



    Il est PROPOSÉ que cette politique sur l'ajout de tests (voir la politique de test) soit documentée dans les instructions pour les propositions de modification. [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


    Le projet DOIT activer une ou plusieurs options d'avertissement du compilateur, un mode du langage « sûr » ou utiliser un outil « linter » séparé pour rechercher des erreurs de qualité de code ou des erreurs simples courantes, s'il existe au moins un outil FLOSS qui peut implémenter ce critère dans le langage sélectionné. [warnings]

    The lintr package https://github.com/jimhester/lintr is used in 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/).



    Le projet DOIT résoudre les avertissements. [warnings_fixed]

    Three separate GitHub Actions workflows detect warnings in installation and testing. Notifications are sent to the maintainer's email and to the respective badges shown in the project repository README.md (on GitHub) and in the project website (https://rich-iannone.github.io/pointblank/).



    Il est PROPOSÉ que les projets soient 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é


    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 codebase almost entirely consists of functions. These are uncomplicated and generally divided between exported and non-exported functions. All exported functions (i.e., user-side) are highly documented. The current maintainer has written nearly all functions entirely, and any incoming contributions are reviewed line-by-line via PRs. With this process in place, attempts to vandalize the code and make it less secure can be easily detected.



    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 maintainer of pointblank is experienced in programming in R, the language of the implementation. Those errors that lead to vulnerabilities in R packages can be easily recognized by the maintainer. That said, security vulnerabilities are likely to come from other components that pointblank uses (other R packages as dependencies). To circumvent this, there is a policy to only use packages that the maintainer trusts (based on the reputations of the package developers and other factors), and to periodically review the dependency packages for indications of possible security vulnerabilities.


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

    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]

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



    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]

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



    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]

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



    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]

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



    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]

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



    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]

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



    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]

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



    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]

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



    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]

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


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


    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 website (https://rich-iannone.github.io/pointblank/) is protected with https.



    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]

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


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


    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]

    Please see the issue tracker for details: https://github.com/rich-iannone/pointblank/issues.



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

    Please see the issue tracker for details: https://github.com/rich-iannone/pointblank/issues.


  • Autres problèmes de sécurité


    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]

    https://github.com/rich-iannone/pointblank is a public repository. Owing to that, there are no limitations on the access to the package and its source code.


  • Analyse statique de code


    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 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/).



    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 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/).



    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]

    All lints from lintr are quickly addressed after they are automatically discovered through the GitHub Actions workflow ('lint') (via mail sent to the maintainer).



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

    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


    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 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/).



    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 pointblank package is entirely implemented in R and as such it does not use any memory-unsafe language.



    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]

    Dynamic analysis is not required for pointblank. This is true for all R packages that are implemented entirely in R (without uses of C, C++, etc.).



    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]

    Dynamic analysis is not required for pointblank. This is true for all R packages that are implemented entirely in R (without uses of C, C++, etc.). If there are related issues, they are solved soon after their reporting (see https://github.com/rich-iannone/pointblank/issues).



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