Eine Schwachstelle melden
Wenn Sie glauben, eine Sicherheitslücke in der eleata Peppol-API, den SDKs oder der GitHub Action gefunden zu haben, melden Sie sie bitte an security@eleata.io. Wir bemühen uns, Meldungen innerhalb von 2 Geschäftstagen zu bestätigen und innerhalb von 5 Geschäftstagen einen Behebungszeitplan bereitzustellen.
Was Sie angeben sollten
- Eine Beschreibung der Schwachstelle und ihrer möglichen Auswirkungen
- Schritte zur Reproduktion, möglichst mit einem minimalen Proof-of-Concept
- Die betroffene Komponente und Version
- Ihren Namen und Ihre Kontaktdaten für Rückfragen (optional, aber willkommen)
Koordinierte Offenlegung
Wir folgen einem Modell der koordinierten Offenlegung. Wir bitten Forscher, uns eine angemessene Gelegenheit zur Behebung zu geben, bevor sie die Schwachstelle öffentlich bekanntmachen. Wir verpflichten uns:
- nach Treu und Glauben daran zu arbeiten, gültige Meldungen zu untersuchen und zu beheben
- eine Nennung in unserer Hall of Fame bereitzustellen (mit Ihrer Zustimmung)
- keine rechtlichen Schritte gegen Forscher zu unternehmen, die diese Richtlinie einhalten
Nicht im Geltungsbereich (Out of scope)
- Denial-of-Service- oder volumetrische Angriffe gegen Produktions-Endpoints
- Social-Engineering-Angriffe gegen eleata-Mitarbeiter
- Schwachstellen in Drittabhängigkeiten, die vom Upstream-Maintainer noch nicht offengelegt wurden
- Theoretische Schwachstellen ohne praktische Auswirkung
- Probleme, die nicht unterstützte Versionen der SDKs betreffen (älter als 12 Monate)
Bug-Bounty
Wir betreiben derzeit kein bezahltes Bug-Bounty-Programm, können aber für wesentliche Funde nach eigenem Ermessen Dank und Nennung gewähren.
Vorhandene Sicherheitsmaßnahmen
- TLS 1.2+ auf allen Produktions-Endpoints erzwungen; HSTS preload
- Content-Security-Policy-, X-Frame-Options-, Referrer-Policy-Header
- API-Keys mit bcrypt gehasht (Kostenfaktor 10); nie im Klartext gespeichert
- Stripe-Webhooks mit HMAC-SHA256-Signatur verifiziert
- XML-Parser gehärtet (defusedxml) gegen XXE, Billion-Laughs, externe DTDs
- 5 MB maximale Payload-Größe, erzwungen über Content-Length-Vorabprüfung
- Rate-Limiting pro API-Key und pro IP-Adresse
- Security-CI: gitleaks, pip-audit, npm audit, osv-scanner
- Audit-Logs für Authentifizierungs- und Key-Verwaltungsereignisse
- übermittelte XML-Payloads werden nie auf Festplatte geschrieben — sie werden nur im Speicher für die Dauer der Anfrage verarbeitet; nur Validierungs-Metadaten (Hash, Größe, Format, Ergebnis) werden gespeichert
Hall of Fame
Wir werden hier verantwortungsvolle Forscher auflisten, sobald das Programm seine ersten gültigen Meldungen erhalten hat.