Makes

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

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

        

 Notions de base 5/5

  • Identification

    A DevSecOps framework powered by Nix.

  • Conditions préalables


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

  • Supervision du projet


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

    The project is maintained by Fluid Attacks and employes contribute to it as part of of their work schedule. Usually more than 2 developers contribute to each release: https://github.com/fluidattacks/makes/commits/main and currently we have three persons in the payroll with maintainer status: https://fluidattacks.github.io/makes/governance/



    Le projet DOIT avoir au moins deux contributeurs significatifs non associés. (URL requise) [contributors_unassociated]

    As of 2022-09-22, the project has had code contributions (measured in commits) from the following individuals:

    makes $ git log --format=%aN --since=2021-09-22 | sort | uniq -c | sort -rn

    152 Kevin Amado
    109 John Perez
     49 Daniel Salazar
     15 Diego Restrepo
      6 David Arnold
      3 Luis Saavedra
      2 GuangTao Zhang
      1 Timothy DeHerrera
      1 Github Dependabot
      1 Daniel Murcia
    

    https://github.com/fluidattacks/makes/commits/main


  • Autre


    Le projet DOIT inclure une déclaration de licence dans chaque fichier source. Cela PEUT être fait en incluant ce qui suit à l'intérieur d'un commentaire au début de chaque fichier : SPDX-License-Identifier : [expression d'une licence SPDX pour le projet]. [license_per_file]

    We use https://reuse.software/ and validate its compliance in the CI/CD on each pull request. This is how a file copyright statement looks like: https://github.com/fluidattacks/makes/blob/cf3762cd96b65759d9c18a9b30f41d5aac465f2c/README.md?plain=1#L1-L5


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


    Le dépôt source du projet DOIT utiliser un logiciel courant de contrôle de version distribué (par exemple, git ou mercurial). [repo_distributed]

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



    Le projet DOIT identifier clairement les petites tâches qui peuvent être effectuées par des contributeurs nouveaux ou occasionnels. (URL requise) [small_tasks]

    Le projet DOIT exiger l'authentification à deux facteurs (2FA) des développeurs pour changer un dépôt central ou accéder à des données sensibles (telles que des signalements de vulnérabilités privés). Ce mécanisme 2FA PEUT utiliser des mécanismes sans mécanismes cryptographiques tels que SMS, mais cela n'est pas recommandé. [require_2FA]

    2FA is required at the organization level, so in order to sign-in to GitHub and approve pull requests or access the repository configuration they need to authenticate first.



    L'authentification à deux facteurs du projet (2FA) DOIT utiliser des mécanismes cryptographiques pour empêcher l'emprunt d'identité. Une 2FA basée sur un service de messages courts (SMS), par elle-même, ne satisfait PAS à ce critère, car elle n'est pas chiffrée. [secure_2FA]

    GitHub normally uses a token based 2FA read from a mobile authentication app, lately, the 2FA authentication is usually push-based, so a user needs to use GitHub mobile to enter the code display in the screen.


  • Normes de codage


    Le projet DOIT documenter ses exigences en matière de revue de code, y compris la façon dont la revue de code est menée, ce qui doit être vérifié et ce qui est requis pour être acceptable. (URL requise) [code_review_standards]

    Le projet DOIT avoir au moins 50% de toutes les modifications proposées revues avant la sortie par une personne autre que l'auteur, afin de déterminer s'il s'agit d'une modification valable et sans problèmes connus qui risqueraient de s'opposer à son inclusion. [two_person_review]
  • Système de construction opérationnel


    Le projet DOIT avoir une construction reproductible. Si aucune construction ne se produit (par exemple, les langages de script où le code source est utilisé directement au lieu d'être compilé), sélectionnez « non applicable » (N/A). (URL requise) [build_reproducible]

    We use the Makes, which uses the Nix Package Manager under the hood. The Nix Package Manager is a reproducible build tool. Generally all that is needed is a single command and that would build anything available in the repository.

    The build scripts and their Nix environment definition can be found here: https://github.com/fluidattacks/makes/tree/8aeed32054e90ef6dd577a935b35d884a238dcde/makes


  • Suite de tests automatisée


    Une suite de tests DOIT être invocable d'une manière standard pour ce langage. (URL requise) [test_invocation]

    We have to test many programing languages, so in order to simplify orchestration we use a build tool. Usually all a person needs to do to invoke the test suite is to: - Open a pull request, which fires automated tests automatically, or - Run locally $ m . /test<something>, for example: $ m . /tests/secretsForGpgFromEnv

    https://github.com/fluidattacks/makes/blob/a4b0e3ba6c309972354852efb16bca00d0d97153/.github/workflows/dev.yml#L597



    Le projet DOIT utiliser une intégration continue, où le code nouveau ou modifié est fréquemment intégré dans un dépôt de code central et des tests automatisés sont exécutés sur le résultat. (URL requise) [test_continuous_integration]

    Workflows are defined, running on GitHub actions https://github.com/fluidattacks/makes/tree/main/.github/workflows



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

    Most of the code we have (the framework) uses Nix and Shell scripting, and there is no tool to measure their coverage. For our CLI application (which uses Python), we use Pytest and Pytest-Cov, to measure statement coverage, and is executed continuously by the CI/CD system on every Pull Request. However, we also have a lot of integration tests for the Nix+Shell components, so their correctness is verified as well.



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

    Most of the code we have (the framework) uses Nix and Shell scripting, and there is no tool to measure their coverage. For our CLI application (which uses Python), we use Pytest and Pytest-Cov, to measure branch coverage, and is executed continuously by the CI/CD system on every Pull Request. However, we also have a lot of integration tests for the Nix+Shell components, so their correctness is verified as well.


  • 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 supporter des protocoles sécurisés pour toutes ses communications réseau, tels que SSHv2 ou ultérieur, TLS1.2 ou ultérieur (HTTPS), IPsec, SFTP et SNMPv3. Les protocoles non sûrs tels que FTP, HTTP, telnet, SSLv3 ou antérieur, et SSHv1 DOIVENT être désactivés par défaut et uniquement activés si l'utilisateur le configure spécifiquement. Si le logiciel produit par le projet ne prend pas en charge les communications réseau, sélectionnez « non applicable » (N/A). [crypto_used_network]


    Le logiciel produit par le projet DOIT, s'il prend en charge ou utilise TLS, prendre en charge au moins TLS version 1.2. Notez que le prédécesseur de TLS s'appelait SSL. Si le logiciel n'utilise pas TLS, sélectionnez « non applicable » (N/A). [crypto_tls12]

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


    Le site Web du projet, le dépôt (s'il est accessible via le Web) et le site de téléchargement (si séparé) DOIVENT inclure des en-têtes clés de durcissement avec des valeurs non admises. (URL requise) [hardened_site]

  • Autres problèmes de sécurité


    Le projet DOIT avoir effectué une évaluation de la sécurité au cours des 5 dernières années. Cette revue DOIT prendre en considération les exigences de sécurité et les limites de sécurité. [security_review]

    We perform security reviews on each pull request. From a conceptual and design level, the potential problems and their mitigation (threat model) have been identified here: https://fluidattacks.github.io/makes/security/threat-model/. We also make sure that the design principles are secure: https://fluidattacks.github.io/makes/security/design-principles/. Static analysis tools are used often as well: https://fluidattacks.github.io/makes/security/assurance/



    Des mécanismes de durcissement DOIVENT être utilisés dans le logiciel produit par le projet afin que les défauts du logiciel soient moins susceptibles d'entraîner des vulnérabilités de sécurité. (URL requise) [hardening]

    The Makes CLI is a Python application, there is no hardening we can do beyond making sure it runs with a recent version of Python and with dependencies free of known security vulnerabilities: https://fluidattacks.github.io/makes/security/assurance/


  • Analyse dynamique de code


    Le projet DOIT appliquer au moins un outil d'analyse dynamique à tout candidat pour une version majeure du logiciel produit par le projet avant sa sortie. [dynamic_analysis]

    We use an automated test suite for this purpose, branch coverage is enabled on it, and the critical flows are tested and verified by the CI/CD system for every change made in the project



    Le projet DEVRAIT inclure de nombreuses assertions à l'exécution dans le logiciel qu'il produit, et vérifier ces assertions lors d'une analyse dynamique. [dynamic_analysis_enable_assertions]

    We use raise SystemExit(code) anytime an error condition is encountered so that the CLI signals to the user that something went wrong. An error message is also normally printed. This system exits would also be caught by the dynamic analysis tool.



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

Soumission du badge du projet appartenant à : John Perez.
Soumission créée le 2022-03-10 18:51:06 UTC, dernière mise à jour le 2022-10-28 18:29:34 UTC. Le dernier badge obtenu l'a été le 2022-03-10 19:49:27 UTC.

Retour