§ Sicherheit
Sicherheit und koordinierte Offenlegung
Wohin eine Schwachstelle gehört, was wir tun und wann — und was stattdessen den Advisory-Weg für Inhalte nimmt.
Eine Schwachstelle melden
Senden Sie Ihren Bericht an security@scellis.com. Bitte beschreiben Sie, was Sie getan haben, was passiert ist und was Sie erwartet hatten — eine kurze Reproduktion ist wertvoller als eine lange Beschreibung. Wenn Sie einen Proof of Concept haben, fügen Sie ihn bei; wenn er einen bestimmten Kontozustand benötigt, schreiben Sie das, anstatt ihn im Konto einer anderen Person herzustellen.
Sie brauchen keine Erlaubnis, um zu suchen. Tests gegen Ihr eigenes Konto und Ihre eigenen Inhalte sind willkommen, und wir gehen nicht gegen Forschende vor, die sich innerhalb der unten genannten Grenzen bewegen. Sie können anonym melden; wir antworten dennoch, sofern Sie uns irgendeinen Antwortweg nennen.
Das maschinenlesbare Gegenstück zu dieser Seite liegt unter /.well-known/security.txt (RFC 9116). Es trägt ein Ablaufdatum, damit eine veraltete Kopie sich selbst zu erkennen gibt, anstatt Ihren Bericht still in die falsche Richtung zu lenken.
Was in diesen Kanal gehört — und was nicht
Dieser Kanal ist für Schwachstellen der PLATTFORM: des API-Workers, des Relays, der Browser-Sandbox, der Authentifizierungs- und Autorisierungsfläche, des Billing-Webhooks, des Objektspeichers — und für jeden Weg, einen dieser Teile zu etwas zu bringen, was er verweigern müsste.
Er ist NICHT der Kanal für kompromittierte INHALTE. Ein bösartiger Block, ein Pack mit veränderten Bytes, ein Datensatz mit eingebettetem Payload, ein Listing, das nicht ist, was es behauptet — dafür gibt es den Meldeweg im Produkt (jede öffentlich sichtbare Entität, jedes Release, Listing, jede Notiz und jedes Profil ist von der Oberfläche aus meldbar, auf der sie erscheint) und, nach der Triage, den Advisory-Weg, der den Katalog und alle Installierenden erreicht. Inhaltsprobleme hierher zu senden bedeutet, sie genau den Personen zuzuleiten, die am wenigsten schnell handeln können.
Ebenfalls außerhalb des Umfangs: fehlende Sicherheitsheader ohne belegte Auswirkung, volumetrische Denial-of-Service-Angriffe, Berichte, die ausschließlich von einem automatisierten Scanner erzeugt wurden, sowie Social Engineering gegenüber Personen im Umfeld von Scellis.
Grenzen, um die wir bitten
Verwenden Sie eigene Konten und eigene Daten. Greifen Sie nicht auf Inhalte anderer Personen zu, verändern oder exfiltrieren Sie sie nicht; wenn eine Schwachstelle Ihnen Zugang zu fremden Daten verschafft, halten Sie inne, dokumentieren Sie nur das zum Nachweis Nötige und sagen Sie es uns.
Beeinträchtigen Sie den Dienst nicht für andere: keine volumetrischen Lasttests, keine Masse an Kontoerstellungen, kein automatisiertes Scannen, das Zustände verändert. Nutzen Sie eine Schwachstelle nicht, um Zugang zu behalten, und lassen Sie nichts zurück.
Veröffentlichen Sie nicht, bevor wir Gelegenheit zur Behebung hatten (siehe Zeitplan unten). Wenn Sie den Eindruck haben, dass eine Behebung unangemessen verzögert wird, sagen Sie uns das — es ist ein Gespräch und keine Regel, die wir einseitig auf Sie anwenden.
Was wir tun, und wann
Wir bestätigen jeden Bericht innerhalb von 3 Werktagen und teilen Ihnen innerhalb von 10 Werktagen mit, ob wir ihn reproduzieren konnten und wie wir die Schwere einschätzen.
Eine kritische Schwachstelle wollen wir innerhalb von 30 Tagen nach Reproduktion beheben, eine hochschwere innerhalb von 90 Tagen. Geringere Schweregrade werden eingeplant, und wir sagen Ihnen, wo. Verschiebt sich eine Behebung, nennen wir den Grund, anstatt still zu werden — ein bekanntes verschobenes Datum ist handhabbar, Schweigen nicht.
Wir veröffentlichen nach dem Fix und nennen Sie mit dem Namen, den Sie wählen (auch gar nicht). Die Formulierung stimmen wir vorher mit Ihnen ab. Scellis ist vor dem Start und betreibt kein Bug-Bounty-Programm, es gibt also keine Vergütung; wir sagen das ausdrücklich, statt es Sie nach der Arbeit herausfinden zu lassen.
Wenn personenbezogene Daten betroffen waren
Eine Schwachstelle, die personenbezogene Daten offengelegt hat, ist zugleich eine Datenschutzverletzung und löst parallel zur Behebung den Weg nach Art. 33/34 DSGVO aus: Meldung an die zuständige Aufsichtsbehörde binnen 72 Stunden nach Bekanntwerden und direkte Benachrichtigung der betroffenen Personen, wenn für sie ein hohes Risiko besteht.
Dieser Prozess läuft unabhängig davon, ob die Meldung über diesen Kanal kam, und unabhängig davon, ob die meldende Person Teile dieser Richtlinie befolgt hat.