umoci

Projekte, die den nachfolgenden Best Practices folgen, können sich freiwillig selbst zertifizieren und zeigen, dass sie einen Core-Infrastruktur-Initiative-/OpenSSF-Badge erhalten haben.

Wenn dies Ihr Projekt ist, zeigen Sie bitte Ihren Badge-Status auf Ihrer Projektseite! Der Badge-Status sieht so aus: Badge-Level für Projekt 1084 ist silver So können Sie ihn einbetten:

Dies sind die Kriterien das Level Gold. Sie können auch die Kriterien für die Level Passing oder Silber sehen.

        

 Grundlagen 4/5 ●

  • Identifizierung

    umoci is a tool for modifying Open Container images

  • Voraussetzungen


    Genug für ein Badge!

    Das Projekt MUSS ein Silber-Siegel erreichen. [achieve_silver]

  • Projektüberwachung


    Nicht genug für ein Badge.

    Das Projekt MUSS einen "Busfaktor" von 2 oder mehr haben. (URL erforderlich) [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).


    Genug für ein Badge!

    Das Projekt MUSS mindestens zwei unabhängige bedeutende Entwickler haben. (URL erforderlich) [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.


  • Andere


    Genug für ein Badge!

    Das Projekt MUSS eine Lizenzerklärung in jeder Quelldatei enthalten. Dies DARF als Kommentar relativ am Anfangs jeder Datei einfügt sein: SPDX-License-Identifier: [SPDX license expression for project]. [license_per_file]

    Every source file includes the standard Apache 2.0 license header.


  • Öffentliches Versionskontroll-Source-Repository


    Genug für ein Badge!

    Das Source-Repository des Projekts MUSS eine geläufige, verteilte Versionskontrollsoftware (z. B. git oder mercurial) verwenden. [repo_distributed]

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


    Genug für ein Badge!

    Das Projekt MUSS eindeutig kleine Aufgaben identifizieren, die von neuen oder gelegentlichen Mitwirkenden durchgeführt werden können. (URL erforderlich) [small_tasks]

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


    Genug für ein Badge!

    Das Projekt MUSS eine Zwei-Faktor-Authentifizierung (2FA) für Entwickler haben, um ein zentrales Repository zu wechseln oder auf sensible Daten zugreifen zu können (z. B. private Schwachstellen-Berichte). Dieser 2FA-Mechanismus DARF Mechanismen ohne kryptographische Mechanismen wie SMS verwenden, obwohl dies nicht empfohlen wird. [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.


    Genug für ein Badge!

    Die Zwei-Faktor-Authentifizierung des Projekts (2FA) SOLLTE Kryptographie-Mechanismen verwenden, um Identitätswechsel zu verhindern. Short-Message-Service-/SMS-basierte 2FAs allein erfüllen dieses Kriterium nicht, da sie nicht verschlüsselt sind. [secure_2FA]

    GitHub provides TOTP and FIDO 2FA, which are both cryptographically secure.


  • Programmierstil


    Genug für ein Badge!

    Das Projekt MUSS seine Code-Review-Anforderungen dokumentieren, einschließlich, wie Code-Überprüfung durchgeführt wird, was überprüft werden muss und was erforderlich ist, um akzeptabel zu sein. (URL erforderlich) [code_review_standards]

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


    Genug für ein Badge!

    Das Projekt MUSS mindestens 50% aller vorgeschlagenen Änderungen vor dem Release durch eine andere Person als den Autor überprüfen, um festzustellen, ob es sich um eine sinnvolle Änderung handelt und frei von bekannten Problemen ist, die gegen die Freigabe der Änderung sprechen würden [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.


  • Produktivsystem


    Genug für ein Badge!

    Das Projekt MUSS ein reproducible Build haben. Wenn kein Building erforderlich ist (z. B. Skriptsprachen, in denen der Quellcode direkt verwendet wird, anstatt kompiliert zu werden), wählen Sie "nicht anwendbar" (N/A). (URL erforderlich) [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


  • Automatisierte Test-Suite


    Genug für ein Badge!

    Eine Test-Suite MUSS in einer standardisierten Weise für diese Programmiersprache anrufbar sein. (URL erforderlich) [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.


    Genug für ein Badge!

    Das Projekt MUSS eine kontinuierliche Integration implementieren, bei der neue oder geänderte Codes häufig in ein zentrales Code-Repository integriert werden und automatisierte Tests auf dem Ergebnis durchgeführt werden. (URL erforderlich) [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.


    Nicht genug für ein Badge.

    Das Projekt MUSS automatisierte FLOSS-Test-Suite(n) einsetzen, die mindestens 90% der Befehle abdecken, wenn es mindestens ein FLOSS-Tool gibt, das dieses Kriterium in der ausgewählten Programmiersprache messen kann. [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).


    Genug für ein Badge!

    Das Projekt MUSS automatisierte FLOSS-Test-Suite(s) mit mindestens 80% Zweig-Abdeckung haben, wenn es mindestens ein FLOSS-Tool gibt, das dieses Kriterium in der ausgewählten Sprache messen kann. [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


  • Verwende grundlegend gute kryptographische Praktiken

    Beachten Sie, dass einige Software keine kryptographischen Mechanismen verwenden muss. Wenn Ihr Project Software erstellt das (1) kryptographische funktionen einbindet, aktiviert, oder ermöglicht und (2) aus den USA heraus an nicht US-Bürger verteilt wird, dann könnten sie rechtlich zu weiterne Schritten gezwungen sein. Meistens beinhaltet dies lediglich das Senden einer E-Mail. Für mehr Informationen, siehe den Abschnitt zu Encryption in Understanding Open Source Technology & US Export Controls.

    Genug für ein Badge!

    Die vom Projekt produzierte Software MUSS sichere Protokolle für alle Netzwerkkommunikationen unterstützen , wie SSHv2 oder höher, TLS1.2 oder höher (HTTPS), IPsec, SFTP und SNMPv3. Unsichere Protokolle wie FTP, HTTP, Telnet, SSLv3 oder früher, und SSHv1 MÜSSEN standardmäßig deaktiviert werden und nur aktiviert werden, wenn der/die Benutzer/in es speziell konfiguriert. Wenn die vom Projekt produzierte Software keine Netzwerkkommunikation verwendet, wählen Sie "nicht anwendbar" (N/A). [crypto_used_network]

    This project does not support network communication.


    Genug für ein Badge!

    Die Projektsoftware MUSS, wenn sie TLS unterstützt oder verwendet, mindestens TLS Version 1.2 unterstützen. Beachten Sie, dass der Vorgänger von TLS SSL genannt wurde. Wenn die Software TLS nicht verwendet, wählen Sie "nicht anwendbar" (N/A). [crypto_tls12]

    This project does not use TLS.


  • Gesicherte Zustellung gegen Man-in-the-Middle-/MITM-Angriffe


    Genug für ein Badge!

    Die Projekt-Website, das Repository (wenn über das Internet zugänglich) und die heruntergelandenen Seiten (falls separat) MÜSSEN Key-Hardening-Headers mit nichtpermeablen Werten enthalten. (URL erforderlich) [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.


  • Andere Sicherheitsissues


    Nicht genug für ein Badge.

    Das Projekt MUSS innerhalb der letzten 5 Jahre eine Sicherheitsüberprüfung durchgeführt haben. Diese Überprüfung muss die Sicherheitsanforderungen und die Sicherheitsgrenze berücksichtigen. [security_review]

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


    Genug für ein Badge!

    Härtungsmechanismen müssen in der Projektsoftware verwendet werden, so dass Softwarefehler weniger wahrscheinlich zu Sicherheitslücken führen. (URL erforderlich) [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).


  • Dynamische Codeanalyse


    Nicht genug für ein Badge.

    Das Projekt MUSS mindestens ein dynamisches Analyse-Tool auf jeden kommenden Hauptproduktionsrelease der Software, die durch das Projekt vor seiner Freigabe produziert wird, anwenden. [dynamic_analysis]

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


    Gerade genug für ein Badge.

    Das Projekt SOLLTE viele Laufzeit-Assertionen in der Projektsoftware enthalten und diese Assertionen während der dynamischen Analyse überprüfen. [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.



Die Daten sind unter der Creative Commons Attribution 3.0-Lizenz oder Nachfolder (CC-BY-3.0+) verfügbar, bereitgestellt von der Open Source Security Foundation unter den Nutzungsbedingungen. Es ist allen erlaubt, die Daten zu teilen und anzupassen, müssen aber einen angemessene Hinweis auf den Urheber geben. Bitte geben Sie als Urheber Aleksa Sarai und die OpenSSF Best Practices Badge Mitwirkenden an.

Projekt-Badge-Eintrag im Besitz von: Aleksa Sarai.
Eintrag erstellt: 2017-07-02 06:46:40 UTC, zuletzt aktualisiert: 2020-06-29 03:43:04 UTC. Letztes erreichtes Badge: 2017-07-02 13:10:18 UTC.

Zurück