in-toto

Projekte, die den nachfolgenden Best Practices folgen, können sich freiwillig selbst zertifizieren und zeigen, dass sie einen Core-Infrastruktur-Initiative (CII) 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 "#" 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: Badgelevel für Projekt 1523 ist passing Hier ist, wie man es einbetten:
Sie können Ihren Badgestatus anzeigen, indem Sie folgendes in Ihre Markdown-Datei einbetten:
[![CII Best Practices](https://bestpractices.coreinfrastructure.org/projects/1523/badge)](https://bestpractices.coreinfrastructure.org/projects/1523)
oder indem Sie folgendes in Ihr HTML einbetten:
<a href="https://bestpractices.coreinfrastructure.org/projects/1523"><img src="https://bestpractices.coreinfrastructure.org/projects/1523/badge"></a>


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



 Grundlagen 12/12

  • Identifizierung

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

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

    Welche Programmiersprache wird verwendet, um das Projekt umzusetzen?
    Wenn es mehr als eine Programmiersprache gibt, liste sie als kommagetrennte Werte (Leerzeichen sind optional) auf und sortiere sie von am häufigsten zum am wenigsten verwendeten. Wenn es eine lange Liste gibt, bitte mindestens die ersten drei häufigsten auflisten. Wenn es keine Programmiersprache gibt (z.B. ist dies nur ein Dokumentations- oder Testprojekt), verwenden Sie das einzelne Zeichen "-". Bitte verwenden Sie eine herkömmliche Großschreibung für jede Sprache, z.B. "JavaScript".
    Das Common Platform Enumeration (CPE) ist ein strukturiertes Namensschema für IT Systeme, Software und Pakete. Es wird in diversen Systemen und Datenbanken bei der Meldung von Schwachstellen verwendet.
  • Grundlegende Informationen auf der Projektwebseite


    Genug für ein Badge!

    Die Projekt-Website MUSS prägnant beschreiben, was die Software tut (welches Problem löst sie?). [description_good]
    Dies MUSS in der Sprache sein, die potenzielle Nutzer verstehen können (z.B. möglichst wenig Fachbegriffe verwenden).

    The project website's landing page provides an introductory video and key aspects about the in-toto project. A textual description of the project is found in the menu item "About->What is in-toto?"

    https://in-toto.github.io/ https://in-toto.github.io/in-toto.html



    Genug für ein Badge!

    Die Projekt-Website MUSS Informationen darüber enthalten, wie Feedback erhalten und gegeben werden kann (als Fehlerberichte oder Verbesserungsvorschläge), und wie man zur Softwareentwicklung beitragen kann. [interact]

    The project website has a menu item "Community" with two subitems "Contact", providing handles for the project's mailing list, GitHub Organization and IRC channel; and "Contribute", which links directly to the projects main repository.

    https://in-toto.github.io/contact.html https://github.com/in-toto/in-toto/



    Genug für ein Badge!

    Die Informationen darüber, wie jemand beitragen kann, MÜSSEN den Prozess erklären (z.B. wie werden Pull-Requests verwendet?) (URL erforderlich) [contribution]
    Wir nehmen an, dass Projekte auf GitHub Issues und Pull-Requests verwenden, sofern nichts anders angegeben ist. Diese Information kann kurz sein, z.B., dass das Projekt Pull-Requests, einen Issue-Tracker oder eine Mailing-Liste verwendet (welche?)

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



    Genug für ein Badge!

    Die Informationen darüber, wie jemand beitragen können, SOLLTEN die Anforderungen für akzeptable Beiträge (z.B. einen Hinweis auf jeden erforderlichen Programmierstandard) enthalten. (URL erforderlich) [contribution_requirements]

    What is expected of contributions is covered in the README and GOVERNANCE documents.

    https://github.com/in-toto/in-toto/blob/develop/GOVERNANCE.md https://github.com/in-toto/in-toto#instructions-for-contributors


  • FLOSS license

    Unter welcher Lizenz/welchen Lizenzen ist das Projekt veröffentlicht?
    Bitte verwenden Sie das SPDX License Expression Format; Beispiele sind "Apache-2.0", "BSD-2-Clause", "BSD-3-Clause", "GPL-2.0+", "LGPL-3.0+", "MIT" und "(BSD-2-Clause OR Ruby)".



    Genug für ein Badge!

    Die vom Projekt entwickelte Software MUSS als FLOSS lizensiert veröffentlicht sein. [floss_license]
    FLOSS is software released in a way that meets the Open Source Definition or Free Software Definition. Examples of such licenses include the CC0, MIT, BSD 2-clause, BSD 3-clause revised, Apache 2.0, Lesser GNU General Public License (LGPL), and the GNU General Public License (GPL). For our purposes, this means that the license MUST be: The software MAY also be licensed other ways (e.g., "GPLv2 or proprietary" is acceptable).

    The MIT license is approved by the Open Source Initiative (OSI).



    Genug für ein Badge!

    Es wird EMPFHOLEN, dass alle erforderlichen Lizenz(en) für die vom Projekt entwickelte Software von der Open Source Initiative (OSI) anerkannt werden. [floss_license_osi]
    Die OSI verwendet einen anspruchsvollen Genehmigungsprozess, um festzulegen, welche Lizenzen OSS sind.

    The MIT license is approved by the Open Source Initiative (OSI).



    Genug für ein Badge!

    Das Projekt MUSS die Lizenz(en) seiner Erzeugnisse an einem üblichen Ort in ihrem Quell-Repository veröffentlichen. (URL erforderlich) [license_location]
    Z.B. als Top-Level-Datei mit dem Namen LICENSE oder COPYING. Der Dateiname der Lizenz DARF eine Dateiendung wie ".txt" oder ".md" haben.

    Non-trivial license location file in repository: https://github.com/in-toto/in-toto/blob/develop/LICENSE.


  • Dokumentation


    Genug für ein Badge!

    Das Projekt MUSS eine grundlegende Dokumentation für die vom Projekt entwickelte Software liefern. [documentation_basics]
    Diese Dokumentation muss in irgendeinem Medium sein (z.B. Text oder Video), das folgendes beinhaltet: wie man die Software installiert, wie man sie started, wie man sie benutzt (evtl. ein Tutorial mit Beispielen) und wie man sie sicher benutzt (z.B. was zu tun und zu lassen ist), wenn das ein passendes Einsatzgebiet für die Software ist. Die Sicherheitsdokumentation muss nicht lange sein. Das Projekt DARF Hypertext-Links zu Nicht-Projekt-Materialien als Dokumentation verwenden. Wenn das Projekt keine Software entwickelt, wählen Sie "nicht anwendbar" (N/A) aus.

    The project's README file provides basic documentation, installation instructions, demo, etc.



    Genug für ein Badge!

    Das Projekt MUSS Referenzdokumentationen enthalten, die externe Schnittstellen (beides, Eingabe und Ausgabe) der vom Projekt entwickelten Software beschreiben. [documentation_interface]
    Die Dokumentation einer externen Schnittstelle erklärt einem Endbenutzer oder Entwickler, wie man sie benutzt. Dies beinhaltet auch eine Programmierschnittstelle (API), falls die Software eine hat. Wenn es sich um eine Bibliothek handelt, dokumentieren Sie die wichtigsten Klassen/Typen und Methoden/Funktionen, die aufgerufen werden können. Wenn es sich um eine Webanwendung handelt, definieren Sie ihre URL-Schnittstelle (häufig eine REST-Schnittstelle). Wenn es sich um eine Befehlszeilenschnittstelle handelt, dokumentieren Sie die Parameter und Optionen, die sie unterstützt. In vielen Fällen ist es am besten, wenn die meisten dieser Dokumente automatisch generiert werden, so dass diese Dokumentation mit der sich ändernden Software synchronisiert bleibt, aber dies ist nicht erforderlich. Das Projekt DARF Hypertext-Links zu Nicht-Projekt-Materialien als Dokumentation verwenden. Dokumentation DARF automatisch generiert werden (falls möglich ist dies oft der beste Weg). Die Dokumentation einer REST-Schnittstelle kann mit Swagger/OpenAPI erzeugt werden. Code-Interface-Dokumentation kann mit Werkzeugen wie JSDoc (JavaScript), ESDoc (JavaScript), pydoc (Python) oder Doxygen (verschiedene) generiert werden. Nur Kommentare im Quelltext reicht nicht aus, um dieses Kriterium zu erfüllen; Es muss einen einfacheren Weg geben, um die Informationen zu sehen, ohne den ganzen Quellcode durchzulesen. Wenn das Projekt keine Software entwickelt, wählen Sie "nicht anwendbar" (N/A) aus.

    The project's README describes the typical workflow and how the use the provided command line tools for the different steps of the workflow.

    https://github.com/in-toto/in-toto/#carrying-out-software-supply-chain-steps https://github.com/in-toto/in-toto/#release-final-product


  • Andere


    Genug für ein Badge!

    Die Projekt-Seiten (Website, Repository und Download-URLs) MÜSSEN HTTPS mit TLS unterstützen. [sites_https]
    This requires that the project home page URL and the version control repository URL begin with "https:", not "http:". You can get free certificates from Let's Encrypt. Projects MAY implement this criterion using (for example) GitHub pages, GitLab pages, or SourceForge project pages. If you are using GitHub pages with custom domains, you MAY use a content delivery network (CDN) as a proxy to support HTTPS, such as described in the blog post "Secure and fast GitHub Pages with CloudFlare", to satisfy this criterion. If you support HTTP, we urge you to redirect the HTTP traffic to HTTPS.

    The project website is hosted on GitHub pages and has free certificates from Let's Encrypt. The repository is hosted on GitHub. Download URLs are available via GitHub and PyPI (HTTPS).

    https://in-toto.github.io/ https://github.com/in-toto/in-toto https://pypi.python.org/pypi/in-toto



    Genug für ein Badge!

    Das Projekt MUSS einen oder mehrere Mechanismen zur Diskussion (einschließlich der vorgeschlagenen Änderungen und Issues) haben, die durchsuchbar sind, bei denen Nachrichten und Themen durch URL adressiert werden, neue Personen an einigen der Diskussionen teilnehmen können und keine lokale Installation von proprietärer Software erfordern. [discussion]
    Beispiele für akzeptable Mechanismen umfassen archivierte Mailingliste(n), GitHub Issues und Pull-Request-Diskussionen, Bugzilla, Mantis und Trac. Asynchrone Diskussionsmechanismen (wie IRC) sind akzeptabel, wenn sie diese Kriterien erfüllen; Stellen Sie sicher, dass es einen URL-adressierbaren Archivierungsmechanismus gibt. Proprietäres JavaScript ist ungern gesehen aber erlaubt.

    GitHub supports discussions on issues and pull requests.

    https://github.com/in-toto/in-toto/issues https://github.com/in-toto/in-toto/pulls



    Genug für ein Badge!

    Das Projekt SOLLTE Dokumentationen in englischer Sprache zur Verfügung stellen und in der Lage sein, Fehlerberichte und Kommentare zum Code in Englisch zu akzeptieren. [english]
    Englisch ist derzeit die Lingua Franca der Computertechnik; Wenn Englisch unterstützt wird, erhöht das die Anzahl der verschiedenen potenziellen Entwickler und Reviewer weltweit. Ein Projekt kann dieses Kriterium auch dann erfüllen, wenn die Hauptsprache der Kernentwickler nicht Englisch ist.

    All of the project's material is written in English, and it accepts bug reports and comments in English.

    https://github.com/in-toto/in-toto/blob/develop/README.md https://in-toto.github.io/ https://github.com/in-toto/docs/blob/master/in-toto-spec.md



(Advanced) What other users have additional rights to edit this badge entry? Currently: []
Most projects should ignore this field. Project badge entries can always be edited by the badge entry owner (creator), BadgeApp administrators, and anyone who can commit to the GitHub repository (if it's on GitHub). If you want someone else to be able to edit this badge entry, and you already have edit rights to this project badge entry, you can additional users with edit rights. Just enter "+" followed by a comma-separated list of integer user ids. Those users will then also be allowed to edit this project entry. If you're the owner of the badge entry or a BadgeApp administrator, you can remove users from this list by entering "-" followed by a comma-separated list of integer user ids. We expect that normally only one person will edit a particular badge entry at a time. This application uses optimistic locking to prevent saving stale data if multiple users try to edit a badge entry simultaneously. If you have multiple editors, we recommend saving badge entry data incrementally and often (that is a wise practice anyway).



 Verbesserungs/Nacharbeits -Kontrolle 9/9

  • Öffentliches Versionskontroll Source Repository


    Genug für ein Badge!

    Das Projekt MUSS ein versiongesteuertes Quell-Repository haben, das öffentlich lesbar ist und eine URL hat. [repo_public]
    The URL MAY be the same as the project URL. The project MAY use private (non-public) branches in specific cases while the change is not publicly released (e.g., for fixing a vulnerability before it is revealed to the public).

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



    Genug für ein Badge!

    The project's source repository MUST track what changes were made, who made the changes, and when the changes were made. [repo_track]

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



    Genug für ein Badge!

    To enable collaborative review, the project's source repository MUST include interim versions for review between releases; it MUST NOT include only final releases. [repo_interim]
    Projects MAY choose to omit specific interim versions from their public source repositories (e.g., ones that fix specific non-public security vulnerabilities, may never be publicly released, or include material that cannot be legally posted and are not in the final release).

    Development occurs on the "develop" branch of the project's GitHub repository. Before final releases, collaborative review happens on the "develop" branch and pull requests that are merged into it.



    Genug für ein Badge!

    It is SUGGESTED that common distributed version control software be used (e.g., git) for the project's source repository. [repo_distributed]
    Git is not specifically required and projects can use centralized version control software (such as subversion) with justification.

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


  • Einzigartige Versionsnummerierung


    Genug für ein Badge!

    Die für Endbenutzer vorgesehenen Projektergebnisse MÜSSEN eine eindeutige Versionskennung für jede Freigabe haben. [version_unique]
    This MAY be met in a variety of ways including a commit IDs (such as git commit id or mercurial changeset id) or a version number (including version numbers that use semantic versioning or date-based schemes like YYYYMMDD).

    The project's source code is versioned via the setup.py Python module, which includes a field for the version number. https://github.com/in-toto/in-toto/blob/0.1.1/setup.py#L36

    The project's specification document is also versioned. https://github.com/in-toto/docs/blob/master/in-toto-spec.md



    Genug für ein Badge!

    It is SUGGESTED that the Semantic Versioning (SemVer) format be used for releases. [version_semver]
    Other version numbering schemes, such as commit IDs (such as git commit id or mercurial changeset id) or date-based schemes like YYYYMMDD, MAY be used as version numbers, since they are unique. Some alternatives can cause problems, because users may not be able to easily determine if they are up-to-date. SemVer may be less helpful for identifying software releases if all recipients only run the latest version (e.g., it is the code for a single website or internet service that is constantly updated via continuous delivery).


    Genug für ein Badge!

    It is SUGGESTED that projects identify each release within their version control system. For example, it is SUGGESTED that those using git identify each release using git tags. [version_tags]

    The project's releases are available on the GitHub repository. Each release is tagged with git and signed with gpg. https://github.com/in-toto/in-toto/releases


  • Versionshinweise


    Genug für ein Badge!

    The project MUST provide, in each release, release notes that are a human-readable summary of major changes in that release to help users determine if they should upgrade and what the upgrade impact will be. The release notes MUST NOT be the raw output of a version control log (e.g., the "git log" command results are not release notes). Projects whose results are not intended for reuse in multiple locations (such as the software for a single website or service) AND employ continuous delivery MAY select "N/A". (URL erforderlich) [release_notes]
    The release notes MAY be implemented in a variety of ways. Many projects provide them in a file named "NEWS", "CHANGELOG", or "ChangeLog", optionally with extensions such as ".txt", ".md", or ".html". Historically the term "change log" meant a log of every change, but to meet these criteria what is needed is a human-readable summary. The release notes MAY instead be provided by version control system mechanisms such as the GitHub Releases workflow.

    The project's provides a CHANGELOG file that summarizes the changes introduced by the release.

    https://github.com/in-toto/in-toto/blob/develop/CHANGELOG.md



    Genug für ein Badge!

    The release notes MUST identify every publicly known vulnerability with a CVE assignment or similar that is fixed in each new release, unless users typically cannot practically update the software themselves. If there are no release notes or there have been no publicly known vulnerabilities, choose "not applicable" (N/A). [release_notes_vulns]
    If users typically cannot practically update the software themselves on their computers, but must instead depend on a middleman to perform the upgrade (as is often the case for a kernel and low-level software that is intertwined with a kernel), the project may choose "not applicable" (N/A).

    There have been no publicly known vulnerabilities identified in the specification or code.


 Berichterstattung 8/8

  • Bug-Report Prozess


    Genug für ein Badge!

    The project MUST provide a process for users to submit bug reports (e.g., using an issue tracker or a mailing list). (URL erforderlich) [report_process]

    The project's users can submit bug reports using the GitHub issue tracker or emails to the project's consensus builder.

    https://github.com/in-toto/in-toto/issues https://github.com/in-toto/in-toto#security-issues-and-bugs



    Genug für ein Badge!

    Das Projekt SOLLTE einen Issue Tracker für die Nachverfolgung einzelner Issues verwenden. [report_tracker]

    The project uses GitHub's issue tracker to track individual issues.

    https://github.com/in-toto/in-toto/issues



    Genug für ein Badge!

    The project MUST acknowledge a majority of bug reports submitted in the last 2-12 months (inclusive); the response need not include a fix. [report_responses]

    The majority of bug reports submitted in the last 2-12 months have been acknowledged.

    https://github.com/in-toto/in-toto/issues?q=is%3Aissue+created%3A%3E%3D2017-01-01



    Genug für ein Badge!

    Das Projekt SOLLTE auf eine Mehrheit (>50%) der Verbesserungsvorschläge in den letzten 2-12 Monaten (einschließlich) reagieren. [enhancement_responses]
    Die Antwort DARF "nein" oder eine Diskussion über ihre Vorzüge sein. Das Ziel ist einfach, dass es einige Antworten auf einige Anfragen gibt, was darauf hinweist, dass das Projekt noch am Leben ist. Für die Zwecke dieses Kriteriums müssen die Projekte keine falschen Anfragen (z.B. von Spammern oder automatisierten Systemen) zählen. Wenn ein Projekt keine weiteren Verbesserungen vornimmt, wählen Sie bitte "Unerfüllt" und geben Sie die URL ein, die diesen Zustand den Benutzern klar macht. Wenn ein Projekt von der Anzahl der Verbesserungsvorschläge überwältigt wird, wählen Sie bitte "Unerfüllt" und erklären Sie die Situation.

    The majority of enhancement requests have been acknowledged in the last 2-12 months.

    https://github.com/in-toto/in-toto/issues?q=is%3Aissue+created%3A%3E%3D2017-01-01



    Genug für ein Badge!

    Das Projekt MUSS ein öffentlich zugängliches Archiv für Berichte und Antworten für die spätere Suche haben. (URL erforderlich) [report_archive]

    All reports and responses are publicly available on GitHub's issue and pull request pages and can be searched using GitHub's searching syntax:

    https://github.com/in-toto/in-toto/issues https://github.com/in-toto/in-toto/pulls https://help.github.com/articles/searching-issues-and-pull-requests/


  • Anfälligkeits-Prozessbericht


    Genug für ein Badge!

    Das Projekt MUSS den Prozess für die Meldung von Schwachstellen auf der Projektseite veröffentlichen. (URL erforderlich) [vulnerability_report_process]
    E.g., a clearly designated mailing address on https://PROJECTSITE/security, often in the form security@example.org. This MAY be the same as its bug reporting process. Vulnerability reports MAY always be public, but many projects have a private vulnerability reporting mechanism.

    The project publishes the process for reporting vulnerabilities.

    https://github.com/in-toto/in-toto#security-issues-and-bugs



    Genug für ein Badge!

    If private vulnerability reports are supported, the project MUST include how to send the information in a way that is kept private. (URL erforderlich) [vulnerability_report_private]
    Examples include a private defect report submitted on the web using HTTPS (TLS) or an email encrypted using OpenPGP. If vulnerability reports are always public (so there are never private vulnerability reports), choose "not applicable" (N/A).

    The project allows users to encrypted their reports when emailing them.

    https://github.com/in-toto/in-toto#security-issues-and-bugs



    Genug für ein Badge!

    The project's initial response time for any vulnerability report received in the last 6 months MUST be less than or equal to 14 days. [vulnerability_report_response]
    Wenn in den letzten 6 Monaten keine Schwachstellen gemeldet wurden, wählen Sie "nicht anwendbar" (N/A).

    There have been no vulnerabilities reported in the last 6 months.


 Qualität 13/13

  • Produktivsystem


    Genug für ein Badge!

    Falls die vom Projekt entwickelte Software vor Benutzung kompiliert werden muss, MUSS das Projekt ein funktionierendes Buildsystem bereitstellen, das den Source Code automatisch in Software übersetzt. [build]
    Ein Build-System bestimmt, welche Aktionen durchgeführt werden müssen, um die Software neu zu bauen (und in welcher Reihenfolge) und führt dann diese Schritte aus. Zum Beispiel kann es einen Compiler aufrufen, um den Quellcode zu kompilieren. Wenn eine ausführbare Datei aus dem Quellcode erstellt wird, muss es möglich sein, den Quellcode des Projekts zu ändern und dann eine aktualisierte ausführbare Datei mit diesen Modifikationen zu erzeugen. Wenn die vom Projekt produzierte Software von externen Bibliotheken abhängt, muss das Build-System diese externen Bibliotheken nicht bauen. Wenn es keine Notwendigkeit gibt, irgendetwas zu bauen, um die Software zu verwenden, nachdem ihr Quellcode geändert wurde, wählen Sie "nicht anwendbar" (N/A).

    The project uses Travis CI to ensure the software can be built from the source code.

    https://travis-ci.org/in-toto/in-toto



    Genug für ein Badge!

    Es ist EMPFHOLEN, dass gewöhnliche Werkzeuge zum Kompiliren von Software benutzt wird. [build_common_tools]
    Beispielsweise, Maven, Ant, cmake, die Autotools, make oder rake.

    The project uses the standard Python tools to "build", package, and distribute the software.

    https://pypi.python.org/pypi/in-toto



    Genug für ein Badge!

    Das Projekt SOLLTE allein mit FLOSS Werkzeugen gebaut werden können. [build_floss_tools]

    The project uses the standard Python tools to "build", package, and distribute the software.

    https://pypi.python.org/pypi/in-toto


  • Automatisierte Test-Suite


    Genug für ein Badge!

    The project MUST use at least one automated test suite that is publicly released as FLOSS (this test suite may be maintained as a separate FLOSS project). [test]
    The project MAY use multiple automated test suites (e.g., one that runs quickly, vs. another that is more thorough but requires special equipment).

    Genug für ein Badge!

    Eine Test-Suite SOLLTE in einer üblichen Weise für diese Programmiersprache aufrufbar sein. [test_invocation]
    Zum Beispiel, "make check", "mvn test", oder "rake test".

    The project's tests are written using Python's standard unittest module. The test suite also uses tox, a popular way of invoking a project's test suite.

    https://github.com/in-toto/in-toto/blob/0.1.1/test/runtests.py https://github.com/in-toto/in-toto/blob/0.1.1/tox.ini



    Genug für ein Badge!

    It is SUGGESTED that the test suite cover most (or ideally all) the code branches, input fields, and functionality. [test_most]

    Our test suite covers over 99% of the source code.

    https://coveralls.io/github/in-toto/in-toto



    Genug für ein Badge!

    It is SUGGESTED that the project implement continuous integration (where new or changed code is frequently integrated into a central code repository and automated tests are run on the result). [test_continuous_integration]
  • Neue Funktionalitäts-Überprüfung


    Genug für ein Badge!

    The project MUST have a general policy (formal or not) that as major new functionality is added to the software produced by the project, tests of that functionality should be added to an automated test suite. [test_policy]
    As long as a policy is in place, even by word of mouth, that says developers should add tests to the automated test suite for major new functionality, select "Met."

    The project's .tox.ini config and continuous integration system requires 99% coverage of the source code, otherwise a build failure results. It's policy is captured in the GOVERNANCE document and pull request template.

    https://github.com/in-toto/in-toto/blob/develop/GOVERNANCE.md https://github.com/in-toto/in-toto/blob/develop/.github/PULL_REQUEST_TEMPLATE.md



    Genug für ein Badge!

    The project MUST have evidence that the test_policy for adding tests has been adhered to in the most recent major changes to the software produced by the project. [tests_are_added]
    Major functionality would typically be mentioned in the release notes. Perfection is not required, merely evidence that tests are typically being added in practice to the automated test suite when new major functionality is added to the software produced by the project.

    The project's continuous integration system requires at least 99% coverage of the source code at all times.

    https://github.com/in-toto/in-toto/blob/develop/tox.ini#L38



    Genug für ein Badge!

    It is SUGGESTED that this policy on adding tests (see test_policy) be documented in the instructions for change proposals. [tests_documented_added]
    Allerdings ist auch eine informelle Regel akzeptabel, solange die Tests in der Praxis hinzugefügt werden.

    The project's pull request template documents the policy of verifying that tests have been added to the change.

    https://github.com/in-toto/in-toto/blob/develop/.github/PULL_REQUEST_TEMPLATE.md


  • Warnhinweise


    Genug für ein Badge!

    The project MUST enable one or more compiler warning flags, a "safe" language mode, or use a separate "linter" tool to look for code quality errors or common simple mistakes, if there is at least one FLOSS tool that can implement this criterion in the selected language. [warnings]
    Examples of compiler warning flags include gcc/clang "-Wall". Examples of a "safe" language mode include JavaScript "use strict" and perl5's "use warnings". A separate "linter" tool is simply a tool that examines the source code to look for code quality errors or common simple mistakes. These are typically enabled within the source code or build instructions.

    The project uses two separate "linter" tools, Pylint and Bandit, to look for code quality errors and simple mistakes.

    https://github.com/in-toto/in-toto/blob/develop/tox.ini#L9-L27



    Genug für ein Badge!

    Das Projekt MUSS auf Warnungen reagieren. [warnings_fixed]
    Dies sind die Warnungen, die durch die Umsetzung des warnings Kriteriums identifiziert wurden. Das Projekt sollte Warnungen beheben oder im Quellcode als falsch positives Ergebnis markieren. Idealerweise gibt es keine Warnungen, aber ein Projekt DARF einige Warnungen akzeptieren (typischerweise weniger als 1 Warnung pro 100 Zeilen oder weniger als 10 Warnungen).

    The linter tools are executed during Continuous Integration builds with Travis CI and tox. If a linter detects an error, the CI build fails and the corresponding pull request won't be merged.

    https://github.com/in-toto/in-toto/blob/develop/.travis.yml#L8 https://github.com/in-toto/in-toto/blob/develop/tox.ini#L9



    Genug für ein Badge!

    It is SUGGESTED that projects be maximally strict with warnings in the software produced by the project, where practical. [warnings_strict]
    Some warnings cannot be effectively enabled on some projects. What is needed is evidence that the project is striving to enable warning flags where it can, so that errors are detected early.

    The project is strict with warnings and requires that pull requests emit no linter warnings, i.e. that CI builds pass.

    https://travis-ci.org/in-toto/in-toto


 Sicherheit 16/16

  • Wissen über sichere Entwicklungspraktiken


    Genug für ein Badge!

    The project MUST have at least one primary developer who knows how to design secure software. [know_secure_design]
    This requires understanding the following design principles, including the 8 principles from Saltzer and Schroeder:
    • economy of mechanism (keep the design as simple and small as practical, e.g., by adopting sweeping simplifications)
    • fail-safe defaults (access decisions should deny by default, and projects' installation should be secure by default)
    • complete mediation (every access that might be limited must be checked for authority and be non-bypassable)
    • open design (security mechanisms should not depend on attacker ignorance of its design, but instead on more easily protected and changed information like keys and passwords)
    • separation of privilege (ideally, access to important objects should depend on more than one condition, so that defeating one protection system won't enable complete access. E.G., multi-factor authentication, such as requiring both a password and a hardware token, is stronger than single-factor authentication)
    • least privilege (processes should operate with the least privilege necessary)
    • least common mechanism (the design should minimize the mechanisms common to more than one user and depended on by all users, e.g., directories for temporary files)
    • psychological acceptability (the human interface must be designed for ease of use - designing for "least astonishment" can help)
    • limited attack surface (the attack surface - the set of the different points where an attacker can try to enter or extract data - should be limited)
    • input validation with whitelists (inputs should typically be checked to determine if they are valid before they are accepted; this validation should use whitelists (which only accept known-good values), not blacklists (which attempt to list known-bad values)).
    A "primary developer" in a project is anyone who is familiar with the project's code base, is comfortable making changes to it, and is acknowledged as such by most other participants in the project. A primary developer would typically make a number of contributions over the past year (via code, documentation, or answering questions). Developers would typically be considered primary developers if they initiated the project (and have not left the project more than three years ago), have the option of receiving information on a private vulnerability reporting channel (if there is one), can accept commits on behalf of the project, or perform final releases of the project software. If there is only one developer, that individual is the primary developer.

    The primary developers of the project are familiar with secure software design and work in a security lab at a university.



    Genug für ein Badge!

    Mindestens einer der primären Entwickler des Projekts MUSS über weitläufige Arten von Fehlern, die zu Schwachstellen in dieser Art von Software führen, Bescheid wissen sowie mindestens eine Methode, um jede von ihnen zu beseitigen oder zu mildern. [know_common_errors]
    Examples (depending on the type of software) include SQL injection, OS injection, classic buffer overflow, cross-site scripting, missing authentication, and missing authorization. See the CWE/SANS top 25 or OWASP Top 10 for commonly used lists.

    The primary developers of the project are familiar with secure software design and work in a security lab at a university.


  • Verwende grundlegend gute kryptographische Praktiken

    Beachte, dass einige Software keine kryptographischen Mechanismen verwenden muss.

    Genug für ein Badge!

    Die vom Projekt entwickelte Software MUSS standardmäßig nur kryptografische Protokolle und Algorithmen verwenden, die öffentlich sind und von Experten überprüft wurden (falls kryptographische Protokolle und Algorithmen verwendet werden). [crypto_published]
    Diese kryptographischen Kriterien gelten nicht immer, da einige Software keine direkten kryptografischen Funktionen benötigt.

    The project uses only cryptographic protocols and algorithms that are publicly published and reviewed by experts.

    More infos about the protocols and algorithms can be found at: https://github.com/secure-systems-lab/securesystemslib

    Securesystemslib is an internal interface to renowned cryptography libraries (pyca/cryptography and pyca/PyNaCl).



    Genug für ein Badge!

    Wenn die Software, die durch das Projekt produziert wird, eine Anwendung oder Bibliothek ist, und ihr Hauptzweck nicht die Kryptographie ist, dann SOLLTE sie lediglich Software einbinden, die speziell für kryptographische Funktionen entworfen ist; Sie SOLLTE NICHT eine eigene Implementierung vornehmen. [crypto_call]

    The project does not reimplement its own cryptographic functions. It uses an internal interface to renowned cryptography libraries (pyca/cryptography and pyca/PyNaCl):

    https://github.com/secure-systems-lab/securesystemslib



    Genug für ein Badge!

    Alle Funktionalitäten in der vom Projekt entwickelten Software, die von Kryptographie abhängigen, MÜSSEN mit FLOSS implementiert werden. [crypto_floss]

    All functionality in the project that depends on crypto uses FLOSS.

    https://github.com/secure-systems-lab/securesystemslib



    Genug für ein Badge!

    Die Sicherheitsmechanismen innerhalb der vom Projekt entwickelten Software, MÜSSEN Standard-Keylängen verwenden, die die NIST-Mindestanforderungen bis zum Jahr 2030 erfüllen (wie im Jahr 2012 festgelegt). Es MUSS möglich sein, die Software so zu konfigurieren, dass kürzere Keylängen vollständig deaktiviert werden können. [crypto_keylength]
    Diese minimalen Bitlängen sind: symmetric key 112, factoring modulus 2048, discrete logarithm key 224, discrete logarithmic group 2048, elliptic curve 224, and hash 224 (das Passworthashing ist nicht von dieser Bitlänge abgedeckt, weitere Informationen zum Passworthashing finden sich im crypto_password_storage Kriterium). Siehe http://www.keylength.com für einen Vergleich von Keylängen Empfehlungen von verschiedenen Organisationen. Die Software KANN kleinere Keylängen in einigen Konfigurationen erlauben (idealerweise nicht, da dies Downgrade-Angriffe erlaubt, aber kürzere Keylängen sind manchmal für die Interoperabilität notwendig).

    The project uses safe defaults that follow NIST requirements, and disallow smaller key lengths.

    https://github.com/secure-systems-lab/securesystemslib



    Genug für ein Badge!

    Die Standard-Sicherheitsmechanismen innerhalb der vom Projekt entwickelten Software MÜSSEN NICHT von defekten kryptographischen Algorithmen abhängen (z.B. MD4, MD5, Single DES, RC4, Dual_EC_DRBG) oder Chiffre-Modi verwenden, die dem Kontext unangemessen sind, außer sie sind notwendig, um kompatible Protokolle bereit zu stellen (wenn das Protokoll in der neusten Version in der Zielumgebung zum Einsatz kommt, die Zielumgebung solch in Protokoll erfordert und das Zielsystem keine sicherere Alternative anbietet). Die Dokumentation MUSS auf jegliche Sicherheitsrisiken hinweisen und bekannte Vorsichtsmaßnahmen beschreiben, sollten unsichere Protokolle unumgäglich sein. [crypto_working]
    Der EZB-Modus ist fast nie angemessen, da er identische Blöcke innerhalb des Geheimtextes aufdeckt, wie der ECB-Pinguin zeigt. Der CTR Modus ist oft unangemessen, da er keine Authentifizierung durchführt und Duplikate verursacht, wenn eine Eingabe wiederholt wird. In vielen Fällen ist es am besten, einen Block-Chiffre-Algorithmus-Modus zu wählen, der entworfen wurde, um Geheimhaltung und Authentifizierung zu kombinieren, z.B. Galois/ Counter Mode (GCM) und EAX. Projekte KÖNNTEN Benutzern erlauben, defekte Mechanismen zu ermöglichen (z.B. während der Einrichtung), falls nötig für Kompatibilität, aber dann wissen die Benutzer, dass sie es tun.

    The project does not depend on broken cryptographic algorithms.

    https://github.com/secure-systems-lab/securesystemslib



    Genug für ein Badge!

    Die Standard-Sicherheitsmechanismen innerhalb der vom Projekt entwickelten Software SOLLTEN NICHT nicht von kryptographischen Algorithmen oder Modi mit bekannten schweren Schwächen abhängen (z.B. SHA-1-Kryptographie-Hash-Algorithmus oder CBC-Modus in SSH). [crypto_weaknesses]
    Sorgen über den CBC-Modus in SSH werden in CERT: SSH CBC vulnerability erläutert.

    The project's default security mechanisms do not depend on weak algorithms or modes.

    https://github.com/secure-systems-lab/securesystemslib



    Genug für ein Badge!

    Die Sicherheitsmechanismen innerhalb der vom Projekt entwickelten Software SOLLTEN ein perfektes Vorwärtsgeheimnis für wichtige Vereinbarungsprotokolle implementieren, so dass ein Sitzungsschlüssel, der aus einer Reihe von Langzeitschlüsseln abgeleitet wird, nicht beeinträchtigt werden kann, wenn einer der Langzeitschlüssel in der Zukunft kompromittiert wird. [crypto_pfs]

    The project does not depend on key agreement protocols.



    Genug für ein Badge!

    Wenn die vom Projekt erzeugte Software Passwörter für die Authentifizierung von externen Benutzern speichert, MÜSSEN die Passwörter als iterierte Hashes mit einem per-User-Salt unter Verwendung eines Key-Stretching (iterierten) Algorithmus (z.B. PBKDF2, Bcrypt oder Scrypt) gespeichert werden. [crypto_password_storage]
    Dieses Kriterium gilt nur, wenn die Software die Authentifizierung von Benutzern mit Passwörtern erzwingt, wie z.B. bei serverseitige Webanwendungen. Es gilt nicht in Fällen, in denen die Software Kennwörter für die Authentifizierung in andere Systeme speichert (z.B. die Software implementiert einen Client für ein anderes System), da zumindest Teile dieser Software oft Zugriff auf das Passwort im Klartext haben müssen.

    The project uses PBKDF2 for encrypted keys.

    https://github.com/secure-systems-lab/securesystemslib



    Genug für ein Badge!

    Die Sicherheitsmechanismen innerhalb der vom Projekt entwickelten Software MÜSSEN alle kryptographischen Schlüssel und Nonces mit einem kryptographisch sicheren Zufallszahlengenerator erzeugen und DARF NICHT mit Generatoren arbeiten, die kryptographisch unsicher sind. [crypto_random]
    Ein kryptographisch sicherer Zufallszahlengenerator kann ein Hardware-Zufallszahlengenerator sein oder es kann ein kryptographisch sicherer Pseudozufallszahlengenerator (CSPRNG) sein, der einen Algorithmus wie Hash_DRBG, HMAC_DRBG, CTR_DRBG, Yarrow oder Fortuna verwendet. Beispiele für Aufrufe von sicheren Zufallszahlengeneratoren umfassen Java's java.security.SecureRandom und JavaScript's window.crypto.getRandomValues. Beispiele für Anrufe von unsicheren Zufallszahlengeneratoren sind Java's java.util.Random und JavaScript's Math.random.

    The project's cryptography interface uses only Python's os.urandom which is considered cryptographically secure.

    https://github.com/secure-systems-lab/securesystemslib


  • Gesicherte Zustellung gegen Man-in-the-Middle (MITM) Angriffe


    Genug für ein Badge!

    Das Projekt MUSS einen Auslieferungsmechanismus verwenden, der den MITM-Angriffen entgegenwirkt. Die Verwendung von https oder ssh + scp ist akzeptabel. [delivery_mitm]
    Ein noch stärkerer Mechanismus ist die Freigabe der Software mit digital signierten Paketen, da dies Angriffe auf das Verteilungssystem verringert, aber das funktioniert nur, wenn die Benutzer sicher sein können, dass die öffentlichen Schlüssel für Signaturen korrekt sind und wenn die Benutzer die Signatur tatsächlich überprüfen.

    The project website and the repository are available via https. The project itself does not use any network protocols.



    Genug für ein Badge!

    Ein kryptographischer Hash (z.B. sha1sum) MUSS NICHT über http abgerufen und ohne Überprüfung einer kryptographischen Signatur verwendet werden. [delivery_unsigned]
    Diese Hashes können im Transit verändert werden.

    The project's signed metadata, which includes cryptographic hashes, is always validated by the client software before accepting it.

    https://github.com/in-toto/in-toto/blob/0.1.1/in_toto/verifylib.py


  • Öffentlich bekannte Schwachstellen wurden behoben


    Genug für ein Badge!

    There MUST be no unpatched vulnerabilities of medium or high severity that have been publicly known for more than 60 days. [vulnerabilities_fixed_60_days]
    Die Sicherheitslücke, muss vom Projekt selbst gepatched und freigegeben werden (Patches woanders entwickelt werden). Eine Sicherheitsücke wird (für diesen Zweck) öffentlich bekannt, sobald es einen CVE mit öffentlich freigegebenen nicht bezahlten Informationen hat (veröffentlicht beispielsweise in der National Vulnerability Database) oder wenn das Projekt informiert und die Informationen der Öffentlichkeit zugänglich gemacht wurden (evtl. durch das Projekt). Eine Sicherheitslücke ist mittel- bis scherwiegend, wenn ihr CVSS 2.0 Basis-Score 4 oder höher ist. Hinweis: Das bedeutet, dass Benutzer bis zu 60 Tage für alle Angreifer weltweit anfällig bleiben können. Dieses Kriterium ist oft viel einfacher zu treffen als das, was Google empfiehlt in Rebooting responsible disclosure, weil Google empfiehlt, dass die 60-Tage-Periode beginnen, wenn das Projekt benachrichtigt wird selbst dann wenn der Bericht nicht öffentlich ist.

    There are now publicly known vulnerabilities.



    Genug für ein Badge!

    Projekte SOLLTEN alle kritischen Schwachstellen schnell nachdem sie gemeldet wurden beheben. [vulnerabilities_critical_fixed]

    Although the project has not received reports for critical vulnerabilities, the developers should be able to rapidly fix any that are reported in the future.


  • Andere Sicherheitsissues


    Genug für ein Badge!

    The public repositories MUST NOT leak a valid private credential (e.g., a working password or private key) that is intended to limit public access. [no_leaked_credentials]
    A project MAY leak "sample" credentials for testing and unimportant databases, as long as they are not intended to limit public access.

    The project's public repository does not leak valid private credentials. Private keys found in the repository are used for testing only.


 Analyse 8/8


Die Daten sind unter der Creative Commons Attribution 3.0-Lizenz oder Nachfolder (CC-BY-3.0+) verfügbar, bereitgestellt von der Core Infrastructure Initiative 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 CII Best Practices Badge Mitwirkenden an.

Projekt Badge Eintrag im Besitz von: Lukas Puehringer.
Eintrag erstellt auf 2018-01-03 16:15:50 UTC, zuletzt aktualisiert auf 2018-01-05 21:39:40 UTC. Letztes erreichtes Badge auf 2018-01-05 21:31:54 UTC.

Zurück