in-toto

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.

Es gibt keine Auswahl an Praktiken, die garantieren können, dass Software niemals Fehler oder Schwachstellen hat. Selbst formale Methoden können fehlschlagen, wenn die Spezifikationen oder Annahmen falsch sind. Auch gibt es keine Auswahl an Praktiken, die garantieren können, dass ein Projekt eine gesunde und gut funktionierende Entwicklungsgemeinschaft erhalten wird. Allerdings können Best Practices dabei helfen, die Ergebnisse von Projekten zu verbessern. Zum Beispiel ermöglichen einige Praktiken die Mehrpersonen-Überprüfung vor der Freigabe, die sowohl helfen können ansonsten schwer zu findende technische Schwachstellen zu finden und gleichzeitig dazu beitragen Vertrauen und den Wunsch nach wiederholter Zusammenarbeit zwischen Entwicklern verschiedener Unternehmen zu schaffen. Um ein Badge zu verdienen, müssen alle MÜSSEN und MÜSSEN NICHT Kriterien erfüllt sein, alle SOLLTEN Kriterien müssen erfüllt sein oder eine Rechtfertigung enthalten, und alle EMPFHOLEN Kriterien müssen erfüllt sein oder nicht (wir wollen sie zumindest berücksichtigt wissen). Wenn lediglich ein allgemeiner Kommentar angebeben werden soll, keine direkte Begründung, dann ist das erlaubt, wenn der Text mit "//" und einem Leerzeichen beginnt. Feedback ist willkommen auf derGitHub-Website als Issue oder Pull-Request. Es gibt auch eine E-Mail-Liste für allgemeine Diskussionen.

Wir stellen Ihnen gerne die Informationen in mehreren Sprachen zur Verfügung, allerdings ist die englische Version maßgeblich, insbesondere wenn es Konflikte oder Inkonsistenzen zwischen den Übersetzungen gibt.
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 1523 ist gold So können Sie ihn einbetten:
Sie können Ihren Badge-Status anzeigen, indem Sie Folgendes in Ihre Markdown-Datei einbetten:
[![OpenSSF Best Practices](https://www.bestpractices.dev/projects/1523/badge)](https://www.bestpractices.dev/projects/1523)
oder indem Sie Folgendes in Ihr HTML einbetten:
<a href="https://www.bestpractices.dev/projects/1523"><img src="https://www.bestpractices.dev/projects/1523/badge"></a>


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

        

 Grundlagen 5/5 ●

  • Identifizierung

    Hinweis: Andere Projekte können den selben Namen benutzen.

    in-toto is a framework to protect supply chain integrity.

  • Voraussetzungen


    Genug für ein Badge!

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

  • Projektüberwachung


    Genug für ein Badge!

    Das Projekt MUSS einen "Busfaktor" von 2 oder mehr haben. (URL erforderlich) [bus_factor]
    Ein "bus factor" (aka "LKW-Faktor") ist die minimale Anzahl von Projektmitgliedern, die plötzlich aus einem Projekt ("hit by a bus") verschwinden müssen, bevor das Projekt aufgrund fehlender kompetenter Mitarbeiter stockt. Das Truck-Factor-Tool kann dies für Projekte auf GitHub schätzen. Weitere Informationen finden Sie unter Bewertung des Busfaktors von Git-Repositories von Cosentino et al.

    Three people mentioned in the MAINTAINERS.txt file have full ownership access to the in-toto GitHub Organization: https://github.com/in-toto/in-toto/blob/develop/MAINTAINERS.txt https://github.com/orgs/in-toto/people


    Genug für ein Badge!

    Das Projekt MUSS mindestens zwei unabhängige bedeutende Entwickler haben. (URL erforderlich) [contributors_unassociated]
    Die Mitwirkenden sind assoziiert, wenn sie von der gleichen Organisation (als Angestellter oder Auftragnehmer) bezahlt werden und die Organisation von den Ergebnissen des Projekts profitieren wird. Finanzielle Zuschüsse aus derselben Organisation zählen nicht, wenn sie durch andere Organisationen gehen (z.B. werden wissenschaftliche Zuschüsse, die an verschiedene Organisationen von einer gemeinsamen Regierung oder NGO-Quelle gezahlt werden, nicht dazu führen, dass die Mitwirkenden assoziiert werden). Jemand ist ein/e wichtige/r Mitwirkende/r, wenn sie/er im vergangenen Jahr nicht-triviale Beiträge zum Projekt geleistet hat. Beispiele für gute Indikatoren für einen bedeutenden Mitwirkenden sind: mindestens 1.000 Zeilen Code geschrieben, 50 Commits erarbeitet oder mindestens 20 Seiten zur Dokumentation beigetragen.

    The in-toto project is primarily a specification but also maintains several implementations. As the Python reference implementation is spec-complete and has reached the 1.0 stability milestone, activity is primarily visible on the specification, its enhancement proposals, and other implementations. in-toto has a robust community within the CNCF and receives contributions from a variety of industry adopters and academics, most of whom are not directly affiliated with the project.

    in-toto PRs authors (Repository group: All, Range: Last year): https://intoto.devstats.cncf.io/d/22/prs-authors-table?orgId=1&var-period_name=Last%20year&var-repogroup_name=All

    in-toto PRs authors companies** (Repository group: All, Range: Last year): https://intoto.devstats.cncf.io/d/21/prs-authors-companies-table?orgId=1&var-period_name=Last%20year&var-repogroup_name=All

    **might include some false mappings


  • 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]
    Dies DARF auch durch die Einbeziehung einer Erklärung in natürlicher Sprache geschehen, die die Lizenz kennzeichnet. Das Projekt DARF auch eine stabile URL enthalten, die auf den Lizenztext oder den vollständigen Lizenztext hinweist. Beachten Sie, dass das Kriterium license_location die Projektlizenz an einem Standardstandort benötigt. Weitere Informationen zu SPDX-Lizenzausdrücken finden Sie unter SPDX-Tutorial . Beachten Sie die Beziehung zu copyright_per_file , deren Inhalt typischerweise den Lizenzinformationen vorausgeht.

    Each source file contains the following SPDX conformant license statement in a comment near the beginning of the file:

    # SPDX-License-Identifier: Apache-2.0


 Verbesserungs-/Nacharbeits-Kontrolle 4/4 ●

  • Ö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]
    Git ist nicht speziell gefordert und Projekte können andere zentralisierte Versionskontrollsoftware (wie z. B. Subversion) mit Rechtfertigung verwenden.

    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]
    Diese Identifizierung erfolgt in der Regel durch die Markierung ausgewählter Ausgaben in einem Issue-Tracker mit einem oder mehreren Tags, die das Projekt für den Zweck verwendet, z.B. up-for-Grabs , First-Timers-only , "Small fix", Microtask oder IdealFirstBug. Diese neuen Aufgaben müssen nicht das Hinzufügen von Funktionalität beinhalten. Sie können die Dokumentation verbessern, Testfälle hinzufügen oder irgendetwas anderes, das das Projekt unterstützt und den Mitwirkenden hilft mehr über das Projekt zu verstehen.

    Issue tracker has an "Up for grabs" label, identifying such tasks. https://github.com/in-toto/in-toto/issues?q=is%3Aissue+is%3Aopen+label%3A%22Up+for+grabs%22


    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]

    All developers who can merge to the main branch, "develop", have 2FA enabled on their GitHub accounts.


    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]
    Ein 2FA-Mechanismus, der dieses Kriterium erfüllt, wäre eine Time-Based-One-Time-Password-/TOTP-Anwendung, die automatisch einen Authentifizierungscode generiert, der sich nach einer gewissen Zeit ändert. Beachten Sie, dass GitHub TOTP unterstützt.

    All developers who can merge to the main branch, "develop", have 2FA enabled on their GitHub accounts, using Time-based One-Time Password (TOTP).


 Qualität 7/7 ●

 Sicherheit 5/5 ●

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

    The software produced by the project does not employ network protocols.


    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]

    The software produced by the 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]
    Beachten Sie, dass GitHub und GitLab bekannt bekannterweise dies erfüllen. Websites wie https://securityheaders.io/ können dies schnell überprüfen. Die wichtigsten Key-Hardening-Header sind: Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), X-Content-Type-Options (as "nosniff"), and X-Frame-Options. Komplett statische websiten die keine Möglichkeit für das anmelden auf der webseite erlauben können vermutlich mit geringer Gefahr einige Hardening-Headers weglassen; es gibt jedoch keine verlässliche Methode solche Seiten zu identifizieren und deshalb erfordern wir diese Headers auch auf voll statischen Webseiten.

    All listed security headers are used on the project website and source code repository website: https://securityheaders.com/?q=https%3A%2F%2Fin-toto.io https://securityheaders.com/?q=https%3A%2F%2Fgithub.com%2Fin-toto%2Fin-toto


  • Andere Sicherheitsissues


    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]
    Dies DARF durch die Projektmitglieder und/oder eine unabhängige Bewertung geschehen. Diese Bewertung kann durch statische und dynamische Analyse-Tools unterstützt werden, aber es muss auch eine menschliche Überprüfung sein, um Probleme zu identifizieren (insbesondere im Design), die Werkzeuge nicht erkennen können.

    The CNCF sig-security performed an assessment of the project. https://github.com/cncf/sig-security/tree/master/assessments/projects/in-toto


    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]
    Härtungsmechanismen können HTTP-Header enthalten wie Content Security Policy (CSP), oder Compiler-Flags (z.B. -fstack-protector), um Angriffe zu mildern, oder Compiler-Flags, um undefiniertes Verhalten zu eliminieren. Für unsere Zwecke wird das Prinzip des kleinsten Privilegs nicht als Verhärtungsmechanismus betrachtet (trotzdem ist es wichtig, aber an anderer Stelle).

    The software produced by the project uses hardening mechanisms such as input validation (see above) and the Python-style EAFP error handling paradigm for library functions, translated to POSIX-style exit codes for command lines tools.

    https://docs.python.org/3/glossary.html#term-eafp


 Analyse 2/2 ●

  • Dynamische Codeanalyse


    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]
    Ein dynamisches Analyse-Tool untersucht die Software, indem es sie mit bestimmten Eingaben ausführt. Beispielsweise DARF das Projekt ein Fuzzing-Tool verwenden (z.B. American Fuzzy Lop) oder einen Web Application Scanner (z.B. OWASP ZAP oder w3af). In einigen Fällen ist das OSS-Fuzz Projekt bereit, Fuzz-Tests auf Ihr Projekt anzuwenden. Für die Zwecke dieses Kriteriums muss das dynamische Analyse-Tool die Eingaben in irgendeiner Weise variieren, um nach verschiedenen Arten von Problemen zu suchen oder eine automatisierte Test-Suite mit mindestens 80% Zweig-Abdeckung sein. Die Englische Wikipedia-Seite zur dynamischen Analysen und die OWASP Seite über Fuzzing nennen einige dynamische Analyse-Tools. Das Analyse-Tool(s) DARF für der Suche nach Sicherheitslücken eingesetzt werden, aber das ist nicht erforderlich.

    Dynamic analysis is automatically applied to every push to the repository:

    https://github.com/in-toto/in-toto/blob/v0.3.0/.travis.yml#L27 https://github.com/in-toto/in-toto/blob/v0.3.0/tox.ini


    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]
    This criterion does not suggest enabling assertions during production; that is entirely up to the project and its users to decide. This criterion's focus is instead to improve fault detection during dynamic analysis before deployment. Enabling assertions in production use is completely different from enabling assertions during dynamic analysis (such as testing). In some cases enabling assertions in production use is extremely unwise (especially in high-integrity components). There are many arguments against enabling assertions in production, e.g., libraries should not crash callers, their presence may cause rejection by app stores, and/or activating an assertion in production may expose private data such as private keys. Beware that in many Linux distributions NDEBUG is not defined, so C/C++ assert() will by default be enabled for production in those environments. It may be important to use a different assertion mechanism or defining NDEBUG for production in those environments.

    Run-time assertions are checked in the dynamic analysis test code using Python unittest's assert methods.

    https://github.com/in-toto/in-toto/tree/develop/tests https://docs.python.org/3.7/library/unittest.html#assert-methods



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 Lukas Puehringer und die OpenSSF Best Practices Badge Mitwirkenden an.

Projekt-Badge-Eintrag im Besitz von: Lukas Puehringer.
Eintrag erstellt: 2018-01-03 16:15:50 UTC, zuletzt aktualisiert: 2022-11-02 15:08:49 UTC. Letztes erreichtes Badge: 2018-01-05 21:31:54 UTC.

Zurück