Sicherheit
Schwachstellen melden.
Schreib an security@mona.expert. Was du gemacht hast, was passiert ist, was du erwartet hättest. Ein funktionierender Exploit ist nicht nötig.
Was du von uns bekommst
Eine Bestätigung binnen 48 Stunden und eine Einschätzung binnen 7 Tagen. Wir nennen dir den geplanten Zeitraum für die Behebung und melden uns, wenn der Fix ausgeliefert ist. Wenn wir etwas nicht als Schwachstelle sehen, sagen wir warum — statt still zu werden.
Koordinierte Offenlegung
Wir bitten um 90 Tage bis zur Veröffentlichung, oder bis ein Fix da ist — je nachdem, was früher eintritt. Bei aktiver Ausnutzung handeln wir schneller und sagen dir Bescheid. Ein Bounty-Programm haben wir nicht. Wir nennen dich in der Meldung, außer du möchtest das nicht.
Reaktionszeiten
| Schweregrad | Behebung | Veröffentlichung |
|---|---|---|
| Kritisch (CVSS 9.0+) oder aktiv ausgenutzt | 7 Tage | Mit dem Release |
| Hoch (7.0–8.9) | 30 Tage | Mit dem Release |
| Mittel (4.0–6.9) | 90 Tage | In den Release Notes |
| Niedrig (unter 4.0) | Nächstes reguläres Release | In den Release Notes |
Sicherheitsupdates erscheinen getrennt von Funktions-Releases und sind kostenlos. Du sollst einen Fix einspielen können, ohne dafür neue Funktionen mitnehmen zu müssen.
Was wir ausdrücklich nicht behaupten
Wir sind nicht nach ISO 27001 zertifiziert. Wir tragen keine CE-Kennzeichnung nach dem Cyber Resilience Act. Wir haben die Unterlagen vorbereitet, die eine Prüfung verlangt — eine Anwendbarkeitserklärung über alle 93 Annex-A-Maßnahmen, eine CRA-Annex-I-Zuordnung, Verfahren für Schwachstellenbehandlung und Meldepflichten — und legen sie offen.
Das ist etwas anderes als ein Zertifikat. Eine Zertifizierung nach ISO 27001 verlangt ein Audit eines Systems, das bereits läuft, mit Nachweisen über Zeit. Rund ein Viertel der Maßnahmen ist organisatorisch und lässt sich nicht durch Code erfüllen. Wir sagen das lieber hier, als es in einem Badge verschwinden zu lassen.
Außerhalb des Bedrohungsmodells
Manches sieht wie eine Schwachstelle aus, ist aber eine bewusste Entscheidung. Ein kompromittierter Host kann den Speicher des Wrappers lesen. Der Datenbank-Root kann die Audit-Trigger entfernen — die Kette macht die Änderung dann sichtbar, verhindert sie aber nicht. Ein Konto mit Inhaberrolle darf sehr viel; dafür ist die Rolle da.