Badania w dobrej wierze nigdy nie spotykają się z prawnikami.

Badania bezpieczeństwa czynią produkt bezpieczniejszym, a my chcemy, aby raport dotarł do nas zanim trafi do atakującego. Jeśli będziesz przestrzegać tej polityki, my: szybko potwierdzimy otrzymanie raportu, będziemy współpracować z Tobą w celu zrozumienia i walidacji luki, będziemy Cię informować o postępach w naprawie, uznamy Twój wkład, jeśli sobie tego życzysz, oraz nie będziemy podejmować ani popierać działań prawnych przeciwko Tobie za przeprowadzone badania. To ostatnie zobowiązanie jest sednem tego dokumentu, a klauzula 07 precyzuje je w szczegółach.

Wyślij e-mail na adres security@transglot.ai. Dołącz opis tego, co znalazłeś, gdzie to znalazłeś, kroki niezbędne do odtworzenia luki, co atakujący mógłby z tym zrobić oraz wszystko, co pomoże nam to potwierdzić: żądanie i odpowiedź, krótki film, proof of concept. Poinformuj nas, czy chcesz zostać uznany za autora i pod jakim imieniem/nazwiskiem. Jeśli to możliwe, pisz po angielsku. Jeśli chcesz zaszyfrować raport, poproś o to w pierwszej wiadomości, a my wymienimy klucze. Publikujemy również plik security.txt z tym samym adresem, dzięki czemu automatyczne skanery wskazują na skrzynkę odbiorczą czytaną przez człowieka.

Potwierdzamy otrzymanie raportu w ciągu trzech dni roboczych. Wstępna ocena, w tym informacja, czy udało nam się odtworzyć lukę i jak ją oceniliśmy, następuje w ciągu dziesięciu dni roboczych. Informujemy Cię, gdy poprawka zostanie wydana. Zazwyczaj wydajemy poprawkę dla luk o wysokim lub krytycznym poziomie zagrożenia w ciągu dziewięćdziesięciu dni od ich walidacji, a szybciej, jeśli ryzyko jest aktywne. Jeśli wydanie poprawki zajmie więcej czasu, wyjaśnimy dlaczego, zamiast milczeć. Poinformujemy Cię przed opublikowaniem jakichkolwiek informacji dotyczących luki i nie opublikujemy Twojego nazwiska bez wcześniejszej zgody.

Prosimy o wstrzymanie się z publikacją szczegółów przez dziewięćdziesiąt dni od pierwszego zgłoszenia, a w razie potrzeby o dłuższy okres, jeśli naprawa jest naprawdę złożona lub wymaga działania ze strony klienta. Nie wykorzystamy tego okresu do ukrycia problemu: będziemy Cię na bieżąco informować, a jeśli nie uda nam się go naprawić, również o tym powiadomimy i nie będziemy sprzeciwiać się publikacji po upływie tego terminu. Jeśli luka jest aktywnie eksploatowana, poinformuj nas o tym niezwłocznie, a my dostosujemy tempo działania do sytuacji. Chętnie skoordynujemy wspólne oświadczenie i wystąpimy o nadanie CVE, jeśli będzie to odpowiednie.

Produkcyjna aplikacja webowa i strona marketingowa na naszych własnych domenach, publiczne API REST, endpoint dostawy, edytor w kontekście i jego elementy osadzone, nasze opublikowane pakiety klienckie, dostawa i podpisywanie webhooków, nasze przepływy uwierzytelniania i single sign-on oraz nasza publiczna infrastruktura, tak jak jest dostępna z internetu. Raporty dotyczące decyzji projektowych, które udokumentowaliśmy jako świadomy kompromis, takich jak współdzielona pula tłumaczeń oparta na exact-match lub brak szyfrowania na poziomie dysku dla woluminów live, są mile widziane jako argumenty, ale nie stanowią luk: są one wyraźnie wymienione na stronie bezpieczeństwa, precisely aby badacz nie spędzał południa na udowadnianiu czegoś, co już publikujemy.

Wszystko, czym nie operujemy my, w tym własna strona internetowa klienta, integracje stron trzecich i dowolny system osiągany przez konektor. Ataki typu Denial of Service, testy wyczerpania zasobów lub obciążenia wolumetrycznego oraz wszystko, co pogarsza działanie usługi dla innych użytkowników. Inżynieria społeczna, phishing lub próby fizyczne wobec naszego personelu, biur lub dostawców. Spam i raporty generowane przez automatyczne skanery bez dołączonej analizy. Znaleziska będące jedynie brakującym nagłówkiem zgodnym z najlepszymi praktykami, flagą ciasteczka bez wykazanego wpływu, przestarzałą biblioteką bez ścieżki eksploatacji, limitem częstotliwości, który znalazłeś poprzez jego przekroczenie, samo-wywolanym cross-site scriptingiem, raportem clickjackingu na stronie bez akcji wrażliwych lub brakiem szerokiej polityki bezpieczeństwa treści (CSP), co już dokumentujemy jako lukę. Luki wymagające fizycznego dostępu do odblokowanego urządzenia ofiary lub wymagające kompromise poziomu root na maszynie ofiary.

Jeśli dobrowolnie i sumiennie przestrzegasz tej polityki podczas swoich badań, uznamy Twoje badania za autoryzowane, będziemy współpracować z Tobą w celu szybkiego zrozumienia i rozwiązania problemu oraz nie będziemy rekomendować ani podejmować działań prawnych przeciwko Tobie, w tym na podstawie przepisów o niewłaściwym wykorzystaniu komputerów, antyhakerskich, dotyczących obejścia zabezpieczeń lub prawa umów, w tym żadnych roszczeń wynikających z Polityki Akceptowalnego Użytkowania lub Warunków Korzystania z Usługi, które Twoje testy mogłyby w inny sposób naruszać. Jeśli osoba trzecia wytoczy Ci sprawę za badania prowadzone zgodnie z tą polityką, damy znać, że Twoje działania były autoryzowane. Ta bezpieczna przystań ogranicza się do nas: nie może i nie autoryzuje Cię do działania przeciwko osobom trzecim, innym klientom lub systemom kogokolwiek innego.

Używaj tylko loginów i kont, które posiadasz lub masz wyraźną zgodę na testowanie, i utwórz własną darmową przestrzeń roboczą zamiast sondować cudze. Nie uzyskuj dostępu, nie modyfikuj, nie kopiuj, nie wykradaj ani nie niszcz danych, które nie są Twoje, a jeśli przypadkowo natrafisz na dane klienta, przerwij, nie zapisuj ich i niezwłocznie poinformuj nas, co zobaczyłeś, abyśmy mogli ocenić zakres narażenia. Nie pogarszaj dostępności ani nie przeprowadzaj testów obciążeniowych, stresowych ani typu denial of service. Nie wykorzystuj znaleziska do uzyskania większego dostępu niż potrzebny do jego zademonstrowania i nie utrzymuj trwałości (persistence). Nie szantażuj i nie uzależniaj ujawnienia od płatności. Nie publikuj przed momentem określonym w klauzuli 04. Przestrzegaj obowiązującego prawa oraz wszelkich ograniczeń eksportowych lub sankcyjnych, które Cię dotyczą.

Obecnie nie oferujemy płatnego programu nagród za błędy. Zapewniamy natomiast szybką, osobistą odpowiedź, publiczne podziękowanie (jeśli sobie tego życzysz), pisemne potwierdzenie w przypadku istotnych ustaleń oraz wspomnianą wyżej ochronę prawną. W razie uruchomienia płatnego programu opublikujemy tutaj jego zakres i stawki przed przyjęciem pierwszego zgłoszenia.

Nie będziemy wymagać podpisania umowy o poufności jako warunku przyjęcia Twojego zgłoszenia i nie wykorzystamy formularza zgłoszeniowego do zobowiązania Cię do milczenia. Nie będziemy Cię straszyć za zgłoszenie, które okaże się mieć niski poziom zagrożenia lub będzie duplikatem. Nie zgłosimy Cię do Twojego pracodawcy, uczelni ani platformy. Jeśli nie zgodzimy się z Twoją oceną poziomu zagrożenia, wyjaśnimy dlaczego, zamiast zamykać wątek.

Klient, który znajdzie lukę podczas korzystania z produktu, jest objęty niniejszą polityką i jej zasadą bezpiecznej przystani, a zgłoszenie luki nigdy nie stanowi naruszenia Polityki Akceptowalnego Użytkowania. Zgłoś ją na adres bezpieczeństwa, a nie poprzez zwykłe wsparcie, aby trafiła do właściwych osób bez oczekiwania w kolejce. Nie testuj przy użyciu danych produkcyjnych należących do Twoich użytkowników końcowych, jeśli możesz tego uniknąć.

Strona bezpieczeństwa wymienia rzeczy, których celowo nie zbudowaliśmy, aby recenzent lub badacz dowiedział się o nich od nas, a nie podczas due diligence: woluminy live nie są szyfrowane na dysku, dziennik audytu jest typu append-only w warstwie aplikacji i nie posiada łańcucha hashy ani podpisu, nie ma szerokiej polityki bezpieczeństwa treści (CSP) i obecnie nie posiadamy certyfikatu bezpieczeństwa strony trzeciej. Publikowanie naszych własnych luk to najtańsza forma uczciwości w branży i oszczędza wszystkim tydzień pracy.

Raporty bezpieczeństwa i pytania dotyczące tej polityki kieruj na adres security@transglot.ai. Wszystko, co nie dotyczy kwestii bezpieczeństwa, w tym nadużycia i prawa autorskie, kieruj na adres hello@transglot.ai. Kwestie prywatności i ochrony danych kieruj na adres privacy@transglot.ai.