Forschung in gutem Glauben trifft niemals auf Anwälte.

Sicherheitsforschung macht das Produkt sicherer, und wir möchten, dass der Bericht uns erreicht, bevor er einen Angreifer erreicht. Wenn Sie diese Richtlinie befolgen, werden wir: Ihren Bericht schnell bestätigen, mit Ihnen zusammenarbeiten, um ihn zu verstehen und zu validieren, Sie während der Behebung auf dem Laufenden halten, Sie auf Wunsch namentlich nennen und keine rechtlichen Schritte gegen Sie wegen der Forschung einleiten oder unterstützen. Dieses letzte Versprechen ist der Kern dieses Dokuments, und Abschnitt 07 führt es konkret aus.

Senden Sie eine E-Mail an security@transglot.ai. Fügen Sie hinzu, was Sie gefunden haben, wo Sie es gefunden haben, die Schritte zur Reproduktion, was ein Angreifer damit tun könnte, und alles, was uns bei der Bestätigung hilft: eine Anfrage und Antwort, ein kurzes Video, ein Proof of Concept. Teilen Sie uns mit, ob Sie genannt werden möchten und unter welchem Namen. Schreiben Sie nach Möglichkeit auf Englisch. Wenn Sie den Bericht verschlüsseln möchten, fragen Sie in einer ersten Nachricht danach, und wir werden einen Schlüssel austauschen. Wir veröffentlichen auch eine security.txt-Datei mit derselben Adresse, sodass ein automatisierter Scanner auf ein Postfach verweist, das von einer Person gelesen wird.

Wir bestätigen einen Bericht innerhalb von drei Werktagen. Innerhalb von zehn Werktagen geben wir eine erste Einschätzung ab, einschließlich der Frage, ob wir das Problem reproduzieren können und wie wir es eingestuft haben. Wir teilen Ihnen mit, wann eine Fehlerbehebung veröffentlicht wird, und bei hohen oder kritischen Problemen haben wir normalerweise innerhalb von neunzig Tagen nach Validierung eine Lösung bereitgestellt, schneller, wenn das Risiko akut ist. Wenn eine Behebung länger dauert, teilen wir Ihnen den Grund mit, anstatt zu schweigen. Wir informieren Sie, bevor wir etwas über das Problem veröffentlichen, und wir werden Ihren Namen nicht ohne Ihre Zustimmung veröffentlichen.

Bitte warten Sie neunzig Tage ab Ihrer ersten Meldung, bevor Sie Details veröffentlichen, und vereinbaren Sie bei Bedarf eine längere Frist, wenn die Behebung wirklich komplex ist oder wenn Kunden Maßnahmen ergreifen müssen. Wir werden diesen Zeitraum nicht nutzen, um das Problem zu vertuschen: Wir halten Sie auf dem Laufenden, und wenn wir es nicht beheben können, teilen wir Ihnen auch das mit. Wir werden der Veröffentlichung nach Ablauf der Frist nicht widersprechen. Wenn ein Problem aktiv ausgenutzt wird, informieren Sie uns sofort, und wir werden entsprechend schnell handeln. Wir koordinieren gerne eine gemeinsame advisory und beantragen bei Bedarf eine CVE-ID.

Die Produktions-Webanwendung und die Marketing-Website auf unseren eigenen Domains, die öffentliche REST-API, der Delivery-Endpunkt, der kontextbezogene Editor und seine Einbettungsflächen, unsere veröffentlichten Client-Pakete, unsere Webhook-Zustellung und -Signierung, unsere Authentifizierungs- und Single-Sign-On-Flows sowie unsere öffentliche Infrastruktur, soweit sie über das Internet erreichbar ist. Berichte über Designentscheidungen, die wir als bewussten Kompromiss dokumentiert haben, wie etwa der gemeinsam genutzte Translation-Memory-Pool für exakte Übereinstimmungen oder das Fehlen einer Festplattenverschlüsselung bei Live-Volumes, sind als Argumente willkommen, stellen aber keine Sicherheitslücken dar: Sie sind auf der Sicherheitsseite explizit aufgeführt, damit Forscher keine Zeit damit verbringen, etwas zu beweisen, das wir bereits veröffentlicht haben.

Alles, was nicht von uns betrieben wird, einschließlich der Website eines Kunden, Integrationen Dritter und jedes System, das über einen Connector erreicht wird. Denial-of-Service-, volumetrische oder Ressourcenerschöpfungstests sowie alles, was den Dienst für andere Benutzer beeinträchtigt. Social Engineering, Phishing oder physische Angriffe gegen unsere Mitarbeiter, unsere Büros oder unsere Lieferanten. Spam und Berichte, die von einem automatisierten Scanner ohne begleitende Analyse generiert wurden. Erkenntnisse, die nur auf einem fehlenden Best-Practice-Header, einem Cookie-Flag ohne nachgewiesene Auswirkungen, einer veralteten Bibliothek ohne ausnutzbaren Pfad, einem durch Überschreitung gefundenen Rate-Limit, einem selbst verursachten Cross-Site-Scripting, einem Clickjacking-Bericht auf einer Seite ohne sensible Aktion oder dem Fehlen einer umfassenden Content-Security-Policy beruhen, was wir bereits als Lücke dokumentiert haben. Sicherheitslücken, die physischen Zugriff auf das entsperrte Gerät eines Opfers oder einen Root-Level-Kompromittierung der Maschine des Opfers erfordern.

Wenn Sie sich bei Ihrer Forschung redlich bemühen, diese Richtlinie einzuhalten, betrachten wir Ihre Forschung als autorisiert. Wir arbeiten mit Ihnen zusammen, um das Problem schnell zu verstehen und zu lösen, und wir werden keine rechtlichen Schritte gegen Sie empfehlen oder einleiten, einschließlich solcher aufgrund von Computermissbrauch, Anti-Hacking-, Anti-Umgehungs- oder Vertragsrecht, sowie keine Ansprüche gemäß den Richtlinien zur akzeptablen Nutzung oder den Nutzungsbedingungen geltend machen, die Ihre Tests sonst verletzen würden. Wenn eine dritte Partei Klage gegen Sie wegen Forschung im Rahmen dieser Richtlinie erhebt, werden wir bekannt geben, dass Ihre Aktivitäten autorisiert waren. Dieser Safe Harbour beschränkt sich auf uns: Er autorisiert Sie nicht und kann Sie nicht dazu berechtigen, gegen Dritte, andere Kunden oder die Systeme anderer Personen vorzugehen.

Verwenden Sie nur Logins und Konten, die Ihnen gehören oder für die Sie eine ausdrückliche Testgenehmigung haben, und erstellen Sie Ihren eigenen kostenlosen Arbeitsbereich, statt den anderer zu untersuchen. Greifen Sie nicht auf Daten zu, die nicht Ihnen gehören, ändern, kopieren, exfiltrieren oder zerstören Sie diese nicht, und wenn Sie versehentlich Kundendaten finden, stoppen Sie sofort, speichern Sie sie nicht und teilen Sie uns unverzüglich mit, was Sie gesehen haben, damit wir die Exposition bewerten können. Beeinträchtigen Sie nicht die Verfügbarkeit und führen Sie keine Last-, Stress- oder Denial-of-Service-Tests durch. Nutzen Sie einen Fund nicht, um mehr Zugriff zu erhalten, als zur Demonstration nötig ist, und halten Sie keine Persistenz aufrecht. Erpressen Sie nicht und machen Sie die Offenlegung nicht von einer Zahlung abhängig. Veröffentlichen Sie nichts, bevor es Klausel 04 erlaubt. Halten Sie sich an geltendes Recht und alle für Sie geltenden Exportkontroll- oder Sanktionsbeschränkungen.

Derzeit gibt es kein bezahltes Bug-Bounty-Programm. Was wir bieten, ist eine schnelle, persönliche Antwort, die Nennung Ihres Namens in einer öffentlichen Danksagung (falls gewünscht), eine schriftliche Referenz für schwerwiegende Funde und der oben genannte sichere Hafen. Sollten wir ein bezahltes Programm einführen, werden wir den Umfang und die Vergütungsspannen hier veröffentlichen, bevor wir die erste Meldung annehmen.

Wir werden Sie nicht auffordern, eine Vertraulichkeitsvereinbarung als Bedingung für die Entgegennahme Ihres Berichts zu unterzeichnen, und wir werden ein Berichtsformular nicht dazu nutzen, Sie zum Schweigen zu verpflichten. Wir werden Sie nicht wegen eines Berichts bedrohen, der sich als geringfügig oder als Duplikat herausstellt. Wir werden Sie nicht bei Ihrem Arbeitgeber, Ihrer Universität oder einer Plattform melden. Wenn wir mit Ihrer Schweregradeinschätzung nicht übereinstimmen, werden wir dies begründen, anstatt den Vorgang einfach zu schließen.

Ein Kunde, der während der Nutzung des Produkts eine Sicherheitslücke findet, fällt unter diese Richtlinie und ihren Safe Harbour. Die Meldung ist niemals ein Verstoß gegen die Richtlinien zur akzeptablen Nutzung. Melden Sie die Lücke an die Sicherheits-E-Mail-Adresse und nicht über den normalen Support, damit sie die richtigen Personen erreicht, ohne in einer Warteschlange zu landen. Testen Sie nach Möglichkeit nicht mit Produktionsdaten, die Ihren eigenen Endnutzern gehören.

Auf der Sicherheitsseite nennen wir die Dinge, die wir absichtlich nicht implementiert haben, damit Prüfer oder Forscher diese von uns erfahren und nicht erst im Rahmen einer Due-Diligence-Prüfung: Die Live-Volumes sind nicht festplattenverschlüsselt, das Audit-Log ist auf Anwendungsebene nur anhängbar (append-only) und verfügt über keine Hash-Kette oder Signatur, es gibt keine umfassende Content-Security-Policy, und wir besitzen derzeit keine Sicherheitszertifizierung durch Dritte. Die Veröffentlichung unserer eigenen Lücken ist die günstigste Form der Ehrlichkeit im Geschäft und spart allen eine Woche.

Sicherheitsberichte und Fragen zu dieser Richtlinie gehen an security@transglot.ai. Alles, was kein Sicherheitsproblem ist, einschließlich Missbrauch und Urheberrechtsverletzungen, geht an hello@transglot.ai. Themen zu Datenschutz und Datensicherheit gehen an privacy@transglot.ai.