umoci

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 1084 est silver 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 4/5 ●

  • Identification

    umoci is a tool for modifying Open Container images

  • Conditions préalables


    Assez pour un badge !

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

  • Supervision du projet


    Pas assez pour un badge.

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

    Currently this project has a bus factor of one (Aleksa Sarai). However, we are working on improving this situation (Tycho Andersen is close to qualifying in this respect).


    Assez pour un badge !

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

    There are currently two unassociated significant contributors (Aleksa Sarai and Tycho Andersen). See https://github.com/opencontainers/umoci/graphs/contributors for current statistics.


  • Autre


    Assez pour un badge !

    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]

    Every source file includes the standard Apache 2.0 license header.


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


    Assez pour un badge !

    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.


    Assez pour un badge !

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

    This is provided by https://github.com/opencontainers/umoci/labels/good%20first%20issue.


    Assez pour un badge !

    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]

    The opencontainers GitHub organisation requires 2FA be enabled for all accounts that are members, and thus all developers with push access must have 2FA.


    Assez pour un badge !

    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 provides TOTP and FIDO 2FA, which are both cryptographically secure.


  • Normes de codage


    Assez pour un badge !

    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]

    Coding standards and requirements are described in the contributing documentation https://github.com/opencontainers/umoci/blob/master/CONTRIBUTING.md.


    Assez pour un badge !

    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]

    As described in the governance rules https://github.com/opencontainers/umoci/blob/master/GOVERNANCE.md, 100% of contributions require two LGTMs from maintainers before a change can be merged. For changes made by maintainers, they are allowed to approve their own changes meaning that their contributions require one additional LGTM from a different maintainer.


  • Système de construction opérationnel


    Assez pour un badge !

    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]

    umoci is written in Go which is a reproducible project https://blog.filippo.io/reproducing-go-binaries-byte-by-byte/, and we also have CI checks to ensure that builds are trivially reproducible. https://github.com/opencontainers/umoci/blob/v0.4.3/Makefile#L111-L122


  • Suite de tests automatisée


    Assez pour un badge !

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

    The test suite can be invoked from the project's Makefile https://github.com/opencontainers/umoci/blob/master/Makefile which uses the standard go testing tool for unit tests and runs the bats testing tool for integration tests.


    Assez pour un badge !

    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]

    This project makes use of the free software CI system Travis https://travis-ci.org/opencontainers/umoci, and the actual test framework is the free software project bats https://github.com/bats-core/bats-core.


    Pas 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 90% s'il existe au moins un outil FLOSS qui peut mesurer ce critère dans le langage sélectionné. [test_statement_coverage90]

    We currently have a hard requirement of 80% statement coverage for all new changes, which are automatically tested as part of CI. In future we plan to increase this to 90% (the main restriction is that currently Go's error paths are considered separate statements -- and it's not always possible to mock all error paths, especially obvious error paths).


    Assez pour un badge !

    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]

    There doesn't currently exist any branch coverage tool for Go -- only statement coverage is available. https://github.com/golang/go/issues/28888


  • Utiliser de bonnes pratiques de base de cryptographie

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

    Assez pour un badge !

    Le logiciel produit par le projet DOIT 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]

    This project does not support network communication.


    Assez pour un badge !

    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]

    This project does not use TLS.


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


    Assez pour un badge !

    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]

    The necessary hardening headers are being set (see https://observatory.mozilla.org/analyze/umo.ci for an up-to-date report), but unfortunately our CSP has to include unsafe-inline for both script-src and style-src because the Hugo theme we use makes use of inline JS and CSS. However we do plan to move away from this theme to resolve the issue https://github.com/opencontainers/umoci/issues/336 and our project website is entirely static with no private data.


  • Autres problèmes de sécurité


    Pas assez pour un badge.

    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]

    This project has not yet received any third-party security review.


    Assez pour un badge !

    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]

    While Go doesn't provide many hardening mechanisms, we do use -buildmode=pie to enable ASLR https://github.com/opencontainers/umoci/blob/v0.4.3/Makefile. We also additionally have several protections such as making extracted filesystems world-inaccessible by default https://umo.ci/reference/security/, as well as working actively on protecting against container escapes (though this is something still being worked on https://github.com/opencontainers/umoci/issues/277).


  • Analyse dynamique de code


    Pas assez pour un badge.

    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]

    This is on the roadmap -- see https://github.com/opencontainers/umoci/issues/335.


    À peine suffisant pour un badge.

    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 have various forms of validation (most notably relating to checksum mismatches), and our test suite validates that such attacks are being correctly detected. However, since we do not have any dynamic analysis suite (our test suite only checks statement coverage not branch coverage), this requirement is technically not met.



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

Soumission du badge du projet appartenant à : Aleksa Sarai.
Soumission créée le 2017-07-02 06:46:40 UTC, dernière mise à jour le 2020-06-29 03:43:04 UTC. Le dernier badge obtenu l'a été le 2017-07-02 13:10:18 UTC.

Retour