Coordinated Vulnerability Disclosure
Sicherheitskontakt
Du hast eine Sicherheitslücke in DevGuard gefunden? Dann wollen wir es als Erste erfahren. Melde sie vertraulich, wir prüfen sie, liefern einen Patch — und veröffentlichen das Advisory anschließend gemeinsam mit Dir.
Wege der Meldung
Zwei vertrauliche Wege zu uns
Beide Wege benachrichtigen die Maintainer direkt und halten Deine Meldung vertraulich, bis ein Fix bereitsteht. Nimm den, der Dir lieber ist — für alles in unseren Repositories ist GitHub der schnellste Weg.
GitHub Private Vulnerability Reporting
Öffne das Formular „Report a vulnerability“ im DevGuard-Repository. Nur die Maintainer werden benachrichtigt, und der gesamte Austausch — Rückfragen, Patch, Advisory-Entwurf — läuft in diesem privaten Thread. Im besten Fall wird die Meldung nach der Behebung als öffentliches Advisory veröffentlicht.
E-Mail an das L3montree-Entwicklungsteam
Du schreibst lieber eine E-Mail oder hast etwas entdeckt, das sich keinem Repository zuordnen lässt — etwa eine Anomalie auf einer gehosteten Instanz? Schreib an developer@l3montree.com. Damit startet eine koordinierte Offenlegung mit dem Entwicklungsteam.
Fingerprint 8360 AF73 C2B5 6CFA FDC8 5337 A715 0822 2B61 68D5
Geltungsbereich
Eine Adresse für das ganze Ökosystem
DevGuard ist mehr als ein Repository: Plattform und API, das Web-Frontend, CLI und Scanner, der Helm-Chart, unsere CI-Komponenten und die kleineren Ökosystem-Projekte. Melde einen Fund in einem davon über das DevGuard-Advisory-Formular oder per E-Mail — wir leiten ihn an das richtige Repository und die zuständigen Maintainer weiter.
Das gilt auch für diese Website und unsere gehosteten Instanzen. Wenn Du unsicher bist, ob etwas dazugehört: melde es trotzdem und lass uns das einschätzen.
Ablauf
Was nach Deiner Meldung passiert
Wir arbeiten nach dem Prinzip der koordinierten Offenlegung: Die Schwachstelle bleibt vertraulich, bis ein Fix existiert, und wird gemeinsam mit diesem Fix veröffentlicht.
- 01
Vertrauliche Meldung
Deine Meldung erreicht zuerst die Maintainer. In dieser Phase wird nichts davon öffentlich.
- 02
Prüfung
Wir reproduzieren das Problem, bewerten die Auswirkung und melden uns mit unserer Einschätzung und Rückfragen bei Dir.
- 03
Patch
Wenn möglich, entwickelt und veröffentlicht das Team innerhalb einer Woche nach Bestätigung einen Sicherheitspatch.
- 04
Offenlegung
Die Schwachstelle wird im Zuge der Patch-Veröffentlichung öffentlich gemacht. Auf Wunsch wirst Du als Melder genannt.
Hinweise
Was eine Meldung sofort bearbeitbar macht
Bitte mit dabei
- Die betroffene Komponente samt Version, Image-Tag oder Commit.
- Konkrete Schritte zur Reproduktion, ein Proof of Concept oder ein Request/Response-Paar.
- Was Du erwartet hast und was stattdessen passiert ist.
- Deine eigene Einschätzung der Auswirkung — was Angreifende erreichen könnten und unter welchen Voraussetzungen.
- Besonderheiten Deines Setups: Konfiguration, Integrationen, Self-Hosted oder SaaS.
- Ob und wann Du selbst veröffentlichen möchtest, damit wir uns abstimmen können.
Bitte vermeiden
- Öffentliche Issues, Pull Requests oder Discussions zu etwas, das noch nicht behoben ist.
- Tests gegen Instanzen, die Dir nicht gehören — betreibe DevGuard stattdessen lokal oder selbst gehostet.
- Automatisierte Scans, die einen Dienst beeinträchtigen, und jeden Zugriff auf Daten anderer.
- Warten auf die perfekte Dokumentation: eine kurze Meldung jetzt ist besser als eine ausgefeilte in drei Wochen.