Sicherheitsrichtlinie und CNA-Geltungsbereich
Wie Sie eine Schwachstelle in allem melden, was Gelhaus Solutions veröffentlicht oder betreibt, was erfasst ist, und was nach dem Absenden geschieht.
- Herausgegeben von
- Gelhaus Solutions · Richtlinie zur Offenlegung von Schwachstellen
- Programm
- Antrag läuft
- Rechtsraum
- Deutschland
- Dieses Dokument
- https://gplatform.org/security/policy
- Die andere Hälfte
- CNA-Geltungsbereichserklärung →
- Zuletzt geändert
- 13 September 2026
Was diese Richtlinie sagt
Geltungsbereich
Gelhaus Solutions bearbeitet Schwachstellen in der Software, die es veröffentlicht, und den Diensten, die es betreibt: der GHub-Produktreihe und den unter der Organisation Gelhaus Solutions veröffentlichten Werkzeugen.
Für jedes Produkt heißt das: das Ganze davon (das Quell-Repository, die daraus veröffentlichten Artefakte und die Produktivinstallation), gleich ob der Quelltext zum Zeitpunkt Ihrer Meldung öffentlich ist. Die Geltungsbereichserklärung ist der genaue Wortlaut, und die Liste darauf ist maßgeblich.
Die Tabelle unten ist genau diese Liste, vollständig. Sie sagt, was erfasst ist, was nur teilweise erfasst ist und was gar nicht erfasst ist, denn das Dritte schuldet man einer meldenden Person genauso wie das Erste.
Eine Grenze sei ausdrücklich genannt: Postiz liegt nicht in diesem Geltungsbereich. Es hat eine eigene CVE Numbering Authority mit MITRE als TL-Root und eine eigene GCVE Numbering Authority. Funde in Postiz gehen an dieses Programm, und die Postiz-Seite sagt wie.
Eine Schwachstelle melden
Schreiben Sie an egelhaus@ennogelhaus.de oder reichen Sie über GAdvisory ein. Beides erreicht dieselbe Person und startet denselben Ablauf.
Nutzen Sie GAdvisory, wenn Sie die Meldung durch die Sichtung verfolgen und den Entwurf des Datensatzes vor der Veröffentlichung lesen wollen. Nutzen Sie E-Mail, wenn Sie lieber kein Konto anlegen möchten oder die Meldung verschlüsselt werden soll. Für diese Domain ist über WKD ein PGP-Schlüssel veröffentlicht, der Fingerabdruck steht weiter unten auf dieser Seite.
Bitte eröffnen Sie kein öffentliches Issue und posten Sie es nicht in einen Discord-Kanal. Verboten ist beides nicht, aber beides ist im Moment des Absendens öffentlich, und damit liegt der Zeitplan nicht mehr in irgendjemandes Hand, auch nicht in Ihrer.
Was eine brauchbare Meldung enthält
Was Sie getan haben, was passiert ist, und was Sie stattdessen erwartet hatten. Eine Version oder einen Commit. Genug Detail, um es nachzuvollziehen.
Wenn Sie einen CVSS-Vektor im Kopf haben, senden Sie den Vektor statt der Zahl. Über den Vektor lohnt sich das Streiten, und dieser Streit wird besser geführt, bevor der Datensatz geschrieben ist, als danach.
Wenn Sie nicht sicher sind, ob das Gefundene eine Schwachstelle ist, senden Sie es und sagen Sie das dazu. Das zu entscheiden ist meine Aufgabe und keine Voraussetzung dafür, mit mir zu sprechen.
Bewertung und Offenlegung
Die Fristen unten sind Zusagen, keine Absichtserklärungen. Wo eine nicht gehalten werden kann, erfahren Sie das, bevor sie reißt, mit Grund und neuem Termin.
Jeder Datensatz bekommt einen CVSS-Vektor mit aufgeschriebener Begründung und eine CWE-Kette statt einer einzelnen Kennung, damit die Ursache im Datensatz landet und nicht nur das Symptom.
Safe Harbour
Melden Sie in gutem Glauben, und ich gehe deswegen nicht gegen Sie vor und bitte auch niemanden sonst darum.
Guter Glaube heißt: nur gegen die eigene Installation oder ein eigenes Konto testen, nicht auf fremde Daten zugreifen und sie nicht verändern, den Dienst für andere nicht beeinträchtigen, kein automatisiertes Scannen betreiben, das auf eine Dienstblockade hinausläuft, und dem unten stehenden Zeitplan eine Chance geben, bevor Sie an die Öffentlichkeit gehen.
Bleiben Sie darin, und einen Fehler zu finden ist ein Gefallen. Treten Sie heraus, hört es auf, eine Forschungsfrage zu sein.
Namensnennung
Voreingestellt ist, dass Ihre Meldung mit Ihrer Nennung in den öffentlichen Bestand eingeht, unter dem Namen oder Handle, den Sie mir geben. Sagen Sie Bescheid, und das unterbleibt. So oder so erfahren Sie es vor der Veröffentlichung, nicht danach.
Was keine Schwachstellenmeldung ist
Ausgabe eines automatischen Scanners ohne beigefügte Analyse. Fehlende Sicherheits-Header ohne beschriebenen Angriffsweg. Best-Practice-Funde ohne genannte Auswirkung. Meldungen, deren einziger Inhalt das Angebot ist, mir die Einzelheiten zu verkaufen.
Auch was wirklich außerhalb des Geltungsbereichs liegt, bekommt eine Antwort, die das sagt, und warum. Schweigen ist keines der möglichen Ergebnisse.
Reaktionszeiten
Jede Zeile ist eine Zusage, kein Vorsatz. Sie gilt für alles im Geltungsbereich unten, in beiden Sprachen, ob Sie Kunde sind oder nicht.
Innerhalb von 3 Werktagen. Wer schweigend wartet, kann Bearbeitung nicht von Ignorieren unterscheiden, deshalb kommt das zuerst und schnell.
Innerhalb von 10 Werktagen: ob sie angenommen wird, der Schweregrad, der CVSS-Vektor mit Begründung und die CWE-Kette.
Richtet sich nach dem Schweregrad und wird mit Ihnen abgestimmt, wenn die Bewertung vorliegt, statt vorab zugesagt zu werden, bevor man weiß, worum es geht.
90 Tage ab dem Bericht oder ab Auslieferung eines Fixes, je nachdem, was zuerst eintritt.
Nach Absprache, und öffentlich im Bestand vermerkt, wenn das Advisory erscheint. Eine still verschobene Frist ist keine Frist.
Sie hören davon, bevor er nicht hält: mit Grund und neuem Termin, nicht hinterher.
Was abgedeckt ist
Gruppiert danach, wer die Kennung vergibt. Die erste Gruppe ist dieses Programm; die übrigen sind benannt, damit sich die Abgrenzung prüfen und nicht bloß vermuten lässt. Nichts wird abgelehnt, weil es nicht gelistet ist: Auch eine nicht gelistete Meldung wird gelesen und beantwortet.
Die Zusagen oben gelten heute. Der CNA-Geltungsbereich, auf den sie sich beziehen, ist beantragt und noch nicht gewährt; der Antrag entscheidet also darüber, wer die Kennung vergibt, nicht darüber, ob eine Meldung bearbeitet wird. Die Geltungsbereichserklärung für sich →
Gelhaus Solutions
Meine eigene Software: die GHub-Produktreihe, die unter der Organisation Gelhaus Solutions veröffentlichten Werkzeuge und die davon gehosteten Instanzen. Das ist der Geltungsbereich, den der CNA-Antrag abdeckt.
Eine Plattform für Sicherheits-Advisories, die nicht an die Datenbank eines Ökosystems gebunden ist.
Ein Management-Broker, der in Ihrer eigenen Infrastruktur läuft.
Teilweise im Geltungsbereich: Module, die GPlatform ausliefert, sind erfasst, die Plattform selbst nicht, da sie nicht an Prosumer ausgeliefert wird.
Ein Konto, ein Log und ein Ort für Governance, für jede G-Open-Registry.
Community-Top-Level-Domains neben dem gewohnten Internet, signiert von der Root an.
Eigene Adressen und eine eigene ASN in einem privaten Netz, geroutet über Hubs und Ende-zu-Ende verschlüsselt.
Gruppen und Mailinglisten, gebaut zum Betreiben.
Analytik, bei der jeder Datenbestand ein Modul ist.
Discord-Analytik, gespeichert nach Form.
Eine Börsensimulation.
Sperrt Pull Requests hinter eine Bewerbung, als GitHub-App oder aus GitHub Actions heraus.
Dies ist ein Fork von vulnogram/vulnogram; im Geltungsbereich sind nur Schwachstellen, die unser Repository betreffen.
Gelhaus Solutions pflegt diesen Fork von Kener. Meldungen zu Code, den wir geschrieben oder geändert haben, gehören hierher. Meldungen zu unverändertem Upstream-Code von Kener gehören zum Upstream-Projekt. Upstream-Änderungen werden nach Prüfung selektiv übernommen, eine Meldung kann uns also erreichen, bevor der Upstream-Fix in unserem Baum liegt. Was zuerst bei uns eingeht, leiten wir weiter und verfolgen den Fix, bis wir ihn übernommen haben.
Dies ist ein Fork von discord-tickets/bot; im Geltungsbereich sind nur Schwachstellen, die unser Repository betreffen.
Eine Steuerungsebene für eine Flotte autonomer Agenten, die zufällig in Minecraft leben.
Von einer anderen CNA abgedeckt
Hier genannt, damit die Abgrenzung ausgesprochen ist. Ich betreibe dieses Programm ebenfalls, aber es ist eine eigene Behörde mit eigenem Geltungsbereich.
Abgedeckt durch die Postiz-CNA mit MITRE als TL-Root und durch GCVE Numbering Authority 125. Ich betreibe dieses Programm, aber es ist eine eigene Authority mit eigenem Geltungsbereich: Postiz-Funde bitte dort melden, nicht hier. Veröffentlichte Advisories →
Teil der Postiz-Plattform und von derselben CNA abgedeckt, obwohl es in einem eigenen Repository liegt. Gleiches Programm, gleiche Meldestelle. Veröffentlichte Advisories →
Meldewege
Verschlüsselt oder nicht, in beiden Sprachen, und ohne Konto irgendwo. Was eine Meldung enthalten sollte, steht in der Richtlinie oben; nichts davon ist Bedingung dafür, gelesen zu werden.
Am besten für alles, was einen Beleg braucht. Sicherheitsmeldungen, Abstimmung, Anfragen zur Zusammenarbeit.
Kennungen und Datensätze
Wer die Kennungen vergibt, in welchem Format die Datensätze erscheinen, und das Schlüsselmaterial, unter dem Sie etwas senden können.
- CNA-Status
- Antrag läuft. Bis er bewilligt ist, erhalten Funde eine Advisory-Kennung mit dem Präfix GSSA-, und alles, was eine CVE rechtfertigt, wird über die zuständige Root geleitet, statt auf den Antrag zu warten.
- Datensatzformate
- CVE-Record-Format 5.1 und OSV, mit CVSS-3.1- und CVSS-4.0-Vektoren und CWE-Ketten statt einer einzelnen Kennung.
- Wo Datensätze veröffentlicht werden
- Über GAdvisory, unter gadvisory.org. Advisories gegen GAdvisory selbst werden ebenfalls dort veröffentlicht, im selben Format wie jede Meldung von außen.
- Schlüssel zur Verschlüsselung
- Für diese Domain über WKD veröffentlicht.
gpg --locate-keys contact@gplatform.orgholt ihn. - Fingerabdruck
F066 2191 307B 7D43 84FE B7C1 1DE1 AF26 AD7E 24DF- Maschinenlesbar
- /.well-known/security.txt, per RFC 9116.
- Sprachen
- Englisch oder Deutsch, wie es Ihnen passt. Auf den Zeitplan hat das keinen Einfluss.
Postiz hat eine eigene CVE Numbering Authority und einen eigenen Geltungsbereich. Meldungen dazu gehen dorthin, nicht über diese Richtlinie.