Astetik

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 15154 ist passing 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/15154/badge)](https://www.bestpractices.dev/projects/15154)
oder indem Sie Folgendes in Ihr HTML einbetten:
<a href="https://www.bestpractices.dev/projects/15154"><img src="https://www.bestpractices.dev/projects/15154/badge"></a>


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

Baseline Series: Baseline Niveau 1 Baseline Niveau 2 Baseline Niveau 3

        

 Grundlagen 13/13 ●

 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]
    Die URL KANN die gleiche wie die Projekt-URL sein. Das Projekt KANN in bestimmten Fällen private (nichtöffentliche) Zweige verwenden, während die Änderung nicht öffentlich freigegeben wird (z. B. für die Behebung einer Sicherheitslücke, bevor sie veröffentlicht wird).

    The public Git repository retains attributable dated commits and interim review branches/PRs between tagged releases. Evidence: https://github.com/autonomio/astetik https://github.com/autonomio/astetik/commits/master https://github.com/autonomio/astetik/pull/62


    Genug für ein Badge!

    Das Quell-Repository des Projekts MUSS verfolgen, welche Änderungen vorgenommen wurden, wer die Änderungen vorgenommen hat und wann die Änderungen vorgenommen wurden. [repo_track]

    The public Git repository retains attributable dated commits and interim review branches/PRs between tagged releases. Evidence: https://github.com/autonomio/astetik https://github.com/autonomio/astetik/commits/master https://github.com/autonomio/astetik/pull/62


    Genug für ein Badge!

    Um eine kollaborative Überprüfung zu ermöglichen, MUSS das Quell-Repository des Projekts Zwischenversionen für die Überprüfung zwischen Releases enthalten. Es DARF NICHT nur endgültige Veröffentlichungen enthalten. [repo_interim]
    Projekte DÜRFEN sich entscheiden, bestimmte Zwischenversionen aus ihren öffentlichen Quell-Repositories auszulassen (z.B. diejenigen, die bestimmte nicht-öffentliche Sicherheitslücken beheben, niemals öffentlich freigegeben werden können, oder Material enthalten, das nicht legal veröffentlicht werden kann und nicht in der endgültigen Version enthalten ist).

    The public Git repository retains attributable dated commits and interim review branches/PRs between tagged releases. Evidence: https://github.com/autonomio/astetik https://github.com/autonomio/astetik/commits/master https://github.com/autonomio/astetik/pull/62


    Genug für ein Badge!

    Es ist EMPFOHLEN, dass eine gemeinsame genutzte Versionskontrollsoftware (z.B. git oder mercurial) für das Source-Repository des Projekts verwendet wird. [repo_distributed]
    Git ist nicht speziell gefordert und Projekte können andere zentralisierte Versionskontrollsoftware (wie z. B. Subversion) mit Rechtfertigung verwenden.

    The public Git repository retains attributable dated commits and interim review branches/PRs between tagged releases. Evidence: https://github.com/autonomio/astetik https://github.com/autonomio/astetik/commits/master https://github.com/autonomio/astetik/pull/62


  • 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]
    Dies DARF durch einer Vielzahl von Möglichkeiten, einschließlich einer Commit-IDs (wie z. B. gits Commit-ID oder mercurials Changeset-ID) oder eine Versionsnummer, (einschließlich Versionsnummern, die semantische oder datumsbasierte Systeme wie YYYYMMDD verwenden) erfüllt werden.

    Released results have unique tag/version identities and source commit IDs. Latest published historical release is v1.16; current protected source version 2.0.0 is explicitly unpublished. Evidence: https://github.com/autonomio/astetik/releases/tag/v1.16 https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/pyproject.toml https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/docs/Developer/Release-Policy.md


    Genug für ein Badge!

    Es ist EMPFHOLEN, dass ein Semantic Versioning (SemVer) oder Calendar Versioning (CalVer) Versionsnummerierungsformat für Releases verwendet wird. Es ist EMPFHOLEN, dass Anwender des CalVer Formates auch die Micro Ebene mit angeben. [version_semver]
    Andere Versionsnummerierungsschemata, wie z. B. Commit-IDs (wie z. B. gits Commit-ID oder mercurials Changeset-ID) oder datumsbasierte Schemata wie YYYYMMDD, DÜRFEN als Versionsnummern verwendet werden, da sie eindeutig sind. Einige Alternativen können zu Problemen führen, denn die Benutzer können nicht leicht feststellen, ob sie aktuell sind. SemVer kann weniger hilfreich sein, um Software-Releases zu identifizieren, wenn alle Empfänger nur die neueste Version ausführen (z.B. ist es der Code für eine einzelne Website oder Internet-Service, der ständig durch kontinuierliche Updates aktualisiert wird).

    The currently maintained source follows three-component SemVer with a mandatory per-PR bump gate. Historical PyPI versions such as 1.16 followed Python version syntax and were not strict three-component SemVer. Evidence: https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/docs/Developer/Semantic-Versioning.md https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/governance/version_gate.py


    Genug für ein Badge!

    Es wird erwartet, dass Projekte jedes Release innerhalb ihres Versionskontrollsystems identifizieren. Zum Beispiel wird erwartet, dass die Projekte, die git verwenden, jedes Release mit git-Tags identifizieren. [version_tags]

    Released historical versions have Git tags, and the configured release process derives a unique v<project.version> tag for future explicitly authorized releases. Evidence: https://github.com/autonomio/astetik/tags https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/docs/Developer/Making-Release.md


  • Versionshinweise


    Genug für ein Badge!

    Das Projekt MUSS zu jedem Update Releasenotes enthalten, die eine lesbare Zusammenfassung der wichtigsten Änderungen der Version sind, damit Benutzer/innen sehen können, ob sie aktualisieren sollten und was die Auswirkungen des Updades sind. Die Releasenotes DÜRFEN NICHT die Rohausgabe eines Versionskontrollprotokolls sein (z. B. die "git log"-Befehlsergebnisse sind keine Releasenotes). Für Projekte, deren Ergebnisse nicht für die Wiederverwendung an mehreren Standorten bestimmt sind (z. B. die Software für eine einzelne Website oder Dienstleistung) und eine kontinuierliche Lieferung verwenden, können Sie "N/A" auswählen. (URL erforderlich) [release_notes]
    Die Releasenotes DÜRFEN auf vielfältige Weise implementiert werden. Viele Projekte bieten sie in einer Datei namens "NEWS", "CHANGELOG" oder "ChangeLog", optional mit Erweiterungen wie ".txt", ".md" oder ".html" an. Historisch bedeutete der Begriff "Change Log" ein Protokoll, in dem jede Änderung festgehalten wird, aber um diese Kriterien zu erfüllen, benötigt es eine menschlich lesbare Zusammenfassung. Die Releasenotes können stattdessen von Versionskontrollsystemmechanismen wie dem GitHub Release Workflow zur Verfügung gestellt werden.

    Latest distributed release v1.16 has human-readable notes identifying Hatch migration and minor fixes. Current 2.0 source has a reviewed human-readable changelog; future notes are generated from that reviewed section rather than raw git logs. Evidence: https://github.com/autonomio/astetik/releases/tag/v1.16 https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/CHANGELOG.md https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/docs/Developer/Release-Policy.md


    Genug für ein Badge!

    Die Releasenotes MÜSSEN jede öffentlich bekannte Laufzeit-Sicherheitslücke mit einer CVE-Zuweisung oder Ähnlichem kennzeichnen, die in der aktuellen veröffentlichten Version behoben sind. Dieses Kriterium darf als nicht anwendbar (N/A) markiert werden, wenn Benutzer typischerweise nicht selbst die Software aktualisieren. Diese Kirterium trifft nur auf die Projektergebnisse zu, nicht auf Abhängikeiten. Wenn keine Releasenotes vorhanden sind oder keine öffentlich bekannten Sicherheitslücken bekannt sind, wählen Sie (N/A). [release_notes_vulns]
    Dieses Kiterium hilft Benutzer zu verstehen ob ein Update eine bestimmte öffentlich bekannte Sicherheitslücke schließt, und zu entscheiden ob das Update eingespielt wird oder nicht. Wenn Benutzer die Software normalerweise nicht selbst auf ihren Computern aktualisieren können, sondern stattdessen auf eine/n Mittelsfrau/mann angewiesen sind, um das Upgrade durchzuführen (wie es bei einem Kernel und einer Low-Level-Software häufig der Fall ist), wählen Sie stattdessen "nicht anwendbar" (N/A), da diese zusätzliche Information für den Benutzer nicht hilfreich ist. Ein Projekt kann auch N/A auswählen wenn alle Empfänger nur die neuste Version benutzen (z. B. wenn der Code für eine einzelne Webseite oder Internetdienst ist der continuierlich mittels Contious Delivery geupdated wird). Diese Kriterium betrifft nur die Projektergenbisse, nicht seine Abhängigkeiten. Alle Sicherheitslücken für alle Abhängigkeiten eines Projektes aufzulisten ist unhandlich weil Abhängikeiten sich regelmäßig ändern könen; außerdem ist es unnötig weil Tools die sich auf die Analyse von Abhängikeiten spezialisieren das viel skalierbarer hin bekommen.

    No publicly known Astetik runtime vulnerability with a CVE or comparable advisory was found in GitHub advisories or the OSV PyPI package query. The criterion concerns project vulnerabilities, not transitive dependencies. Evidence: https://github.com/autonomio/astetik/security/advisories https://api.osv.dev/v1/query


 Berichterstattung 8/8 ●

  • Bug-Report-Prozess


    Genug für ein Badge!

    Das Projekt muss einen Prozess für Benutzer enthalten, um Fehlerberichte zu senden (z. B. mit einem Issue-Tracker oder eine Mailing-Liste). (URL erforderlich) [report_process]

    SUPPORT and issue templates describe how to submit a versioned reproducible report using the public GitHub issue tracker. Evidence: https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/SUPPORT.md https://github.com/autonomio/astetik/issues


    Genug für ein Badge!

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

    Live GitHub repository metadata has has_issues=true; issues are the documented bug and contribution tracker. Evidence: https://api.github.com/repos/autonomio/astetik https://github.com/autonomio/astetik/issues https://github.com/autonomio/astetik/blob/5db38b5fc054292a2dc3d6e592746f4815e23bf2/SUPPORT.md


    Genug für ein Badge!

    Das Projekt MUSS eine Mehrheit der in den letzten 2-12 Monaten eingereichten Fehlerberichte berücksichtigen; Die Antwort muss keine Korrektur enthalten. [report_responses]

    Complete GitHub issue inventory has no human bug reports or enhancement requests submitted between 2025-10-02 and 2026-08-02, the 2–12 month evaluation window. This does not claim old unanswered historical issues were acknowledged. Evidence: https://github.com/autonomio/astetik/issues?q=is%3Aissue+created%3A2025-10-02..2026-08-02


    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.

    Complete GitHub issue inventory has no human bug reports or enhancement requests submitted between 2025-10-02 and 2026-08-02, the 2–12 month evaluation window. This does not claim old unanswered historical issues were acknowledged. Evidence: https://github.com/autonomio/astetik/issues?q=is%3Aissue+created%3A2025-10-02..2026-08-02


    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]

    GitHub issue and PR discussions are public, searchable, URL-addressable, and accessible through a browser without installing proprietary client software. Evidence: https://github.com/autonomio/astetik/issues https://github.com/autonomio/astetik/pulls


  • 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]
    z.B., eine klar benannte Mailing-Adresse auf https://PROJECTSITE/security, oft in der Form security@example.org. Dies KANN die gleiche sein wie die für den Fehlerberichtsprozess. Informationen über Schwachstellen können immer öffentlich sein, aber viele Projekte verfügen über einen privaten Schwachstellen-Berichtsmechanismus.

    SECURITY documents how to report vulnerabilities privately by arranging a channel through the established author contact, warns against public exploitable details, and defines useful report contents. Evidence: https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/SECURITY.md https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/MAINTAINERS.md


    Genug für ein Badge!

    Falls das Projekt einen Kanal zur Übertragung von Schwachstellen besitzt, dann MUSS diese Informationsübertragung privat ablaufen. (URL erforderlich) [vulnerability_report_private]
    Beispiele hierfür sind ein privater Defektbericht, der im Internet über HTTPS (TLS) oder eine mit OpenPGP verschlüsselte E-Mail verschickt wird. Wenn die Informationsübertragung von Schwachstellen immer öffentlich sind (also gibt es niemals private Informationsübertragung von Schwachstellen), wählen Sie "nicht anwendbar" (N/A).

    GitHub private vulnerability reporting is enabled for Astetik. Reports are submitted privately over GitHub HTTPS at https://github.com/autonomio/astetik/security/advisories/new . Live repository setting verified 2026-10-02; reporters should not publish exploitable details in public issues. Evidence: https://github.com/autonomio/astetik/security/advisories/new https://github.com/autonomio/astetik/security/policy


    Genug für ein Badge!

    Das Projekts MUSS mindestens binnen 14 Tagen, auf jeden in den letzten 6 Monaten erhaltenen Anfälligkeitsbericht, reagieren. [vulnerability_report_response]
    Wenn in den letzten 6 Monaten keine Schwachstellen gemeldet wurden, wählen Sie "nicht anwendbar" (N/A).

    The primary maintainer confirms no private vulnerability reports were received in the past 12 months as of 2026-10-02. No public Astetik vulnerability report or advisory was found in the last six months. Thus there is no initial-response interval to claim; the official criterion permits N/A when no vulnerabilities were reported in that period. Evidence: https://github.com/autonomio/astetik/security/advisories


 Qualität 13/13 ●

 Sicherheit 16/16 ●

  • Wissen über sichere Entwicklungspraktiken


    Genug für ein Badge!

    Das Projekt MUSS mindestens einen primären Entwickler haben, der weiß, wie man sichere Software entwerfen kann. (Siehe "Details" für spezifische Anforderungen.) [know_secure_design]
    Dies erfordert das Verständnis der folgenden Designprinzipien, einschließlich der 8 Prinzipien von Saltzer und Schroeder:
    • Wirtschaftlichkeit des Mechanismus (halten Sie das Design so einfach und klein wie möglich, z. B. durch umfassende Vereinfachungen)
    • Fehlersichere Voreinstellungen (Zugriffsentscheidungen sollten standardmäßig verweigert werden und die Installation der Projekte sollte standardmäßig sicher sein)
    • Vollständige Vermittlung (jeder Zugang, der begrenzt werden kann, muss auf Berechtigungen überprüft werden und darf nicht umgangen werden können)
    • Offenes Design (Sicherheitsmechanismen sollten nicht von der Unkenntnis der Angreifer über das Designs abhängig gemacht werden, sondern stattdessen auf leichter schützbare und änderbare Informationen wie Schlüssel und Passwörter)
    • Trennung von Privilegien (Idealerweise sollte der Zugriff auf wichtige Objekte von mehr als einer Bedingung abhängen, so dass die Beseitigung eines Schutzsystems keinen vollständigen Zugriff ermöglicht. z. B., Multi-Faktor-Authentifizierung wie die Erfordernis eines Passwortes und eines Hardware-Token ist stärker als die Single-Faktor-Authentifizierung)
    • So wenige Privilegien wie möglich (Prozesse sollten nur mit den geringsten Privilegien laufen)
    • So wenig gemeinsame Mechanismen wie möglich (Das Design sollte die Mechanismen minimieren, die von mehreren Benutzern gemeinsam verwendet werden und von allen Benutzern abhängig sind, z.B. Verzeichnisse für temporäre Dateien)
    • Psychologische Akzeptanz (Die menschliche Schnittstelle muss benutzerfreundlich entworfen werden - Design für "geringeste Überraschung" kann dabei helfen)
    • Begrenzte Angriffsfläche (die Angriffsfläche - die Menge der verschiedenen Punkte, wo ein Angreifer versuchen kann, Daten einzugeben oder zu extrahieren - sollte begrenzt sein)
    • Eingabevalidierung mit Positivliste (Eingaben sollten in der Regel überprüft werden, um festzustellen, ob sie gültig sind, bevor sie akzeptiert werden; diese Validierung sollte Postitivlisten verwenden (die nur bekannte gute Werte akzeptieren), nicht Negativlisten (die versuchen, bekannte schlechte Werte aufzulisten)).
    Ein "Primärer Entwickler" in einem Projekt ist jedermann, der mit der Codebasis des Projekts vertraut ist, der in der Lage ist Änderungen daran vorzunehmen und von den meisten anderen Teilnehmern des Projekts als solches anerkannt wird. Ein primärer Entwickler hat üblicherweise im vergangen Jahr eine Reihe von Aufgaben übernommen (Code, Dokumentation oder Beantwortung von Fragen). Die Entwickler würden typischerweise als primäre Entwickler betrachtet, wenn sie das Projekt initiiert haben (und das Projekt nicht vor mehr als drei Jahre verlassen haben), die Möglichkeit haben, Informationen zu Schwachstellen über einen privaten Berichtskanal zu erhalten (falls vorhanden), neuen Code zum Projekt entgegennehmen zu können, oder die endgültige Freigaben der Projektsoftware durchzuführen. Wenn es nur einen Entwickler gibt, ist diese Person der primäre Entwickler. Es gibt viele Bücher und Kurse die Wissen vermitteln,wie sichere Software entwickelt und entworfen werden kann. Zum Beispiel bietet der kostenlose Kurs Secure Software Development Fundamentals drei Module an, die erklären wie man sichere Software entwickelt.

    Mikko Kotila, Astetik primary maintainer/developer, explicitly confirms understanding all specified secure-design principles: economy of mechanism, fail-safe defaults, complete mediation, open design, separation of privilege, least privilege, least common mechanism, psychological acceptability, limited attack surface, and allowlist input validation. Confirmation given 2026-10-02; implementation controls are documented in the assurance case. Evidence: https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/MAINTAINERS.md https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/docs/Developer/Security-Assurance-Case.md


    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]
    Beispiele (je nach Art der Software) beinhalten SQL-Injektion, OS-Injektion, klassischer Pufferüberlauf, Cross-Site-Scripting, fehlende Authentifizierung und fehlende Autorisierung. Siehe die CWE/SANS top 25 oder OWASP Top 10 für häufig verwendete Listen. Es gibt viele Bücher und Kurse die Wissen vermitteln,wie sichere Software entwickelt und entworfen werden kann. Zum Beispiel bietet der kostenlose Kurs Secure Software Development Fundamentals drei Module an, die erklären wie man sichere Software entwickelt.

    Mikko Kotila, Astetik primary maintainer/developer, explicitly confirms knowing common vulnerability classes relevant to this library and at least one mitigation for each, including injection, unsafe deserialization, path traversal, missing authorization, secret leakage, and vulnerable dependencies. Confirmation given 2026-10-02; the assurance case records the project trust boundaries and relevant controls. Evidence: https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/docs/Developer/Security-Assurance-Case.md


  • 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 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 maintained library uses the Python standard-library hashlib SHA-256 primitive for content identity/integrity. SHA-256 is published, 256 bits, and not a broken algorithm. No custom cipher or authentication cryptography is implemented; receipts explicitly do not establish signed authorship. Evidence: https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/astetik/_json.py https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/astetik/_source_file.py https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/docs/Reference/Evidence-Result.md


    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 maintained library uses the Python standard-library hashlib SHA-256 primitive for content identity/integrity. SHA-256 is published, 256 bits, and not a broken algorithm. No custom cipher or authentication cryptography is implemented; receipts explicitly do not establish signed authorship. Evidence: https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/astetik/_json.py https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/astetik/_source_file.py https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/docs/Reference/Evidence-Result.md


    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]
    Siehe Open Standards Requirement for Software by the Open Source Initiative.

    The maintained library uses the Python standard-library hashlib SHA-256 primitive for content identity/integrity. SHA-256 is published, 256 bits, and not a broken algorithm. No custom cipher or authentication cryptography is implemented; receipts explicitly do not establish signed authorship. Evidence: https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/astetik/_json.py https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/astetik/_source_file.py https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/docs/Reference/Evidence-Result.md


    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, und hash 224 (das Passworthashing ist nicht von dieser Bitlänge abgedeckt, weitere Informationen zum Passworthashing finden sich im crypto_password_storage Kriterium). Siehe https://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 maintained library uses the Python standard-library hashlib SHA-256 primitive for content identity/integrity. SHA-256 is published, 256 bits, and not a broken algorithm. No custom cipher or authentication cryptography is implemented; receipts explicitly do not establish signed authorship. Evidence: https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/astetik/_json.py https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/astetik/_source_file.py https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/docs/Reference/Evidence-Result.md


    Genug für ein Badge!

    Die Standard-Sicherheitsmechanismen innerhalb der vom Projekt entwickelten Software DÜRFEN 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 bereitzustellen (wenn das Protokoll in der neusten Version in der Zielumgebung zum Einsatz kommt, die Zielumgebung solch ein 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 maintained library uses the Python standard-library hashlib SHA-256 primitive for content identity/integrity. SHA-256 is published, 256 bits, and not a broken algorithm. No custom cipher or authentication cryptography is implemented; receipts explicitly do not establish signed authorship. Evidence: https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/astetik/_json.py https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/astetik/_source_file.py https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/docs/Reference/Evidence-Result.md


    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.

    Project integrity digests use hashlib.sha256. No MD5/SHA1 security mechanism or home-grown cipher was found in runtime. Repository delivery uses platform HTTPS/signing primitives. Evidence: https://github.com/autonomio/astetik/blob/5db38b5fc054292a2dc3d6e592746f4815e23bf2/astetik/_json.py https://github.com/autonomio/astetik/blob/5db38b5fc054292a2dc3d6e592746f4815e23bf2/astetik/_source_file.py https://github.com/autonomio/astetik/blob/5db38b5fc054292a2dc3d6e592746f4815e23bf2/astetik/_result.py


    Genug für ein Badge!

    Die Sicherheitsmechanismen innerhalb der vom Projekt entwickelten Software SOLLTEN Perfect Forward Secrecy 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 installed local scientific library does not implement a network key-agreement protocol or session encryption. Evidence: https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/docs/Overview/Boundary.md https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/docs/Developer/Security-Assurance-Case.md


    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. Argon2id, Bcrypt, Scrypt, or PBKDF2). Siehe auch OWASP Password Storage Cheat Sheet). [crypto_password_storage]
    Dieses Kriterium gilt nur, wenn die Software die Authentifizierung von externan Benutzern mit Passwörtern erzwingt (inbound authentication), wie z. B. bei serverseitigen Webanwendungen. Es gilt nicht in Fällen, in denen die Software Kennwörter für die Authentifizierung in andere Systeme speichert (outbound authentication, 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 installed local scientific library does not authenticate external users or store authentication passwords. Evidence: https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/docs/Developer/Security-Assurance-Case.md


    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 DÜRFEN 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 Javas java.security.SecureRandom und JavaScripts window.crypto.getRandomValues. Beispiele für Anrufe von unsicheren Zufallszahlengeneratoren sind Javas java.util.Random und JavaScripts Math.random.

    Astetik does not generate cryptographic keys or nonces. Scientific determinism/content identities are SHA-256 hashes, not randomly generated secrets. Evidence: https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/astetik/_json.py https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/docs/Developer/Security-Assurance-Case.md


  • 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 public repository and source downloads use HTTPS, as do PyPI package downloads. The project does not instruct users to accept unsigned hashes obtained over HTTP. Evidence: https://github.com/autonomio/astetik https://pypi.org/project/astetik/ https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/docs/Developer/Release-Policy.md


    Genug für ein Badge!

    Ein kryptographischer Hash (z.B. sha1sum) DARF NICHT über http abgerufen und ohne Überprüfung einer kryptographischen Signatur verwendet werden. [delivery_unsigned]
    Diese Hashes könnten bei der Übermittlung verändert werden.

    The public repository and source downloads use HTTPS, as do PyPI package downloads. The project does not instruct users to accept unsigned hashes obtained over HTTP. Evidence: https://github.com/autonomio/astetik https://pypi.org/project/astetik/ https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/docs/Developer/Release-Policy.md


  • Öffentlich bekannte Schwachstellen wurden behoben


    Genug für ein Badge!

    Es DARF KEINE ungepatchte Schwachstelle von mittlerer oder höherer Schwere enthalten sein, die seit mehr als 60 Tagen öffentlich bekannt ist. [vulnerabilities_fixed_60_days]
    Die Sicherheitslücke muss vom Projekt selbst gepatched und freigegeben werden (Patches dürfen 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 hat einen mittlerem oder höheren Schweregrad, wenn ihr Common Vulnerability Scoring System (CVSS) Basis-Score 4 oder höher ist. In CVSS Versionen 2.0 bis 3.1 entspricht dies einem CVSS score von 4.0 oder höher. Projekte können einen CVSS Score der in einer viel verwendeten Schwachstellendatenbank (wie z.B. National Vulnerability Database) verwenden, wenn der Score entsprechend der aktuellsten CVSS Version in der Datenbank gelistet ist. Projekte können stattdessen den Schweregrad selbst berechnen, indem sie die neuste Version der CVSS zum Zeitpunkt der Schwachstellenmeldung verwendend, wenn die Eingaben für die Berechnung veröffentlicht werden sobald die Schwachstelle öffentlich bekannt gegeben wurde. 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. Beachten Sie auch, dass dieses Badge-Kriterium, wie andere Kriterien, auf einzelne Projekte zutrifft. Manche Projekte sind teil einer größeren Organisation oder eines größeren Projektes, möglicherweise als Teil mehrer Lagen, und manche Projekte füttern ihre Ergebnisse an andere Organisationen oder Projekte als teil einer möglicherweisen komplexen Lieferkette. Daher fokussieren wir uns auf die Antwortzeit einzelner Projekte. Wenn ein Projekt einen Patch bereitgestellt hat können andere entscheiden wie sie damit umgehen möchten (z. B. können sie auf eine neue Version upgraden oder nur einzelne Patches auswählen und einspielen).

    No publicly known medium-or-higher Astetik runtime vulnerability was found in GitHub advisories or the OSV package database. Live Scorecard configuration findings are separately tracked and do not establish exploitable project vulnerabilities older than 60 days. Evidence: https://github.com/autonomio/astetik/security/advisories https://api.osv.dev/v1/query https://github.com/autonomio/astetik/security/code-scanning


    Genug für ein Badge!

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

    No confirmed critical Astetik vulnerability is currently known from the public advisory/OSV audit, and the primary maintainer confirms no private vulnerability reports in the past 12 months. There is no outstanding confirmed critical vulnerability or historical fix interval to misrepresent. Critical reports are prioritized for immediate triage and prompt remediation; this answer does not invent a past response-time result. Evidence: https://github.com/autonomio/astetik/security/advisories https://api.osv.dev/v1/query


  • Andere Sicherheitsissues


    Genug für ein Badge!

    Die öffentlichen Repositorys DÜRFEN NICHT gültige private Zugriffsdaten enthalten (z. B. ein funktionierendes Passwort oder einen privaten Schlüssel), die den öffentlichen Zugriff einschränken sollen. [no_leaked_credentials]
    Ein Projekt DARF "Beispiel"-Zugriffsdaten für Tests und unwichtige Datenbanken herausgeben, solange sie nicht den öffentlichen Zugang einschränken sollen.

    GitHub secret-scanning alert 1 is resolved as false_positive after independent analysis: the detected bytes span adjacent WB_A3 country-code and WOE_ID geographic-ID fields in countries.dbf record 184 (North Korea), matching public Natural Earth v4.0.0 attributes. The matched value is geographical metadata, not a credential. No valid private credential is identified in the public repository audit. Evidence: https://github.com/autonomio/astetik/security/secret-scanning/1 https://github.com/autonomio/astetik/blob/eb829edaca3fc189ff3ea181d0a2a531fd80abe5/astetik/extras/countries.dbf https://raw.githubusercontent.com/nvkelso/natural-earth-vector/v4.0.0/50m_cultural/ne_50m_admin_0_countries.dbf


 Analyse 8/8 ●


Sie können Tools und KI-Systeme nutzen, um Änderungen über eine einfache URL vorzuschlagen, z. B. https://www.bestpractices.dev/de/projects/15154/choose/edit?osps_ac_01_01_status=Met&osps_ac_01_01_justification=GitHub+enforced. Wie das geht, erfahren Sie in unserem Automatisierungsvorschlagssystem. Diese Daten sind unter der Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0) verfügbar. Dies bedeutet, dass ein Datenempfänger die Daten mit oder ohne Änderungen weitergeben darf, solange der Datenempfänger den Text dieser Vereinbarung mit den weitergegebenen Daten zur Verfügung stellt. Bitte nennen Sie Mikko Kotila und die OpenSSF Best Practices Badge-Mitwirkenden als Urheber.

Projekt-Badge-Eintrag im Besitz von: Mikko Kotila.
Eintrag erstellt: 2026-10-02 06:55:56 UTC, zuletzt aktualisiert: 2026-10-02 09:51:47 UTC. Letztes erreichtes Badge: 2026-10-02 09:07:57 UTC.