GitHub wykrywa sekrety Lovable i Supabase — klucz może zniknąć szybciej

GitHub ogłosił 5 października 2026 r., że secret scanning rozpoznaje pięć wskazanych formatów danych dostępowych Lovable Labs, Pydantic Services Inc. i Supabase. Lovable Labs dołączyło też do programu partnerskiego: klucz tej firmy znaleziony w publicznym repozytorium GitHub przekazuje wystawcy, który może go unieważnić lub wymienić. Samo wykrycie ani przekazanie klucza nie oznacza jeszcze, że przestał on działać.

Październikowa zmiana wymaga rozróżnienia dwóch ścieżek. Sekret typu Partner trafia do wystawcy, natomiast typ User powoduje alert dla osób odpowiedzialnych za repozytorium, jeśli mają dostęp do tej funkcji. W przypadku repozytoriów prywatnych dane nie są automatycznie przekazywane wystawcy, a odpowiedzialność za reakcję pozostaje po stronie właściciela — na ten skutek zwraca uwagę CloudNinjas. W obu ścieżkach ujawniony sekret trzeba ocenić i w razie potrzeby samodzielnie unieważnić.

Które sekrety obejmuje październikowy komunikat

Lista GitHuba wymienia pięć identyfikatorów formatów. Tylko klucz Lovable Labs znajduje się w ogłoszeniu również na liście nowego partnera. Pozostałe pozycje należą do ścieżki alertów User; wykrycie takiego ciągu nie uruchamia opisanego dla Lovable przekazania do wystawcy.

• Lovable Labs — lovable_api_key: Partner. Znalezisko w publicznym repozytorium jest przesyłane Lovable Labs, aby firma mogła podjąć działanie wobec klucza.
• Pydantic Services Inc. — logfire_token: User. Wykrycie może wygenerować alert w repozytorium objętym skanowaniem.
• Pydantic Services Inc. — pydantic_ai_gateway_api_key: User. Reakcja na alert należy do osób zarządzających danymi dostępowymi.
• Supabase — supabase_oauth_access_token: User. Ten format jest rozpoznawany przez skaner, ale nie został wskazany jako nowy sekret partnera Lovable.
• Supabase — supabase_scoped_personal_access_token: User. Wykrycie prowadzi ścieżką alertu dla użytkownika.

Przy tokenach Supabase ważna jest chronologia. Wpis GitHuba z 17 czerwca 2026 r. wymieniał już oba formaty Supabase wśród dodanych detektorów. Październikowy komunikat wymienia je ponownie, więc nie ustala daty ich pierwszego wdrożenia. Wyraźnie wskazaną zmianą w programie partnerskim jest dołączenie Lovable Labs.

Alert dla użytkownika a zgłoszenie do wystawcy

Przekazanie sekretu Partner daje wystawcy możliwość szybszej reakcji na klucz ujawniony publicznie. Lovable Labs może go unieważnić lub obrócić, lecz między otrzymaniem zgłoszenia a wykonaniem tej czynności jest różnica. Osoba utrzymująca aplikację powinna ustalić aktualny stan klucza u wystawcy, zamiast wnioskować o nim z samego faktu wykrycia.

Alert User służy innej osobie: właścicielowi lub opiekunowi repozytorium. Wskazuje znaleziony sekret, aby można było sprawdzić jego użycie i odebrać mu ważność w usłudze, która go wydała. Włączenie detektora nie jest testem potwierdzającym, że każdy pasujący ciąg pozostaje aktywnym tokenem. Z drugiej strony brak wiadomości od wystawcy nie dowodzi, że ujawniony token jest bezpieczny.

Zakres repozytorium również ma znaczenie. Zgłoszenie partnerskie opisane dla Lovable dotyczy znaleziska publicznego; alerty User mogą pojawić się w repozytoriach publicznych i prywatnych, zależnie od dostępności oraz ustawień skanowania. Dlatego przy analizie znaleziska trzeba wiedzieć zarówno, jaki format wykryto, jak i gdzie go znaleziono. Dopiero te dwie informacje pozwalają ustalić, kto otrzymał sygnał i kto musi podjąć działanie.

Co zrobić po ujawnieniu klucza

Pierwszeństwo ma odebranie ważności starej wartości u wystawcy. Usunięcie sekretu z bieżącego pliku nie cofa wcześniejszego commitu ani możliwości skopiowania danych, gdy były widoczne. Poniższa kolejność pomaga ograniczyć dostęp, a potem ustalić zakres ujawnienia.

1. Unieważnij stary sekret. Sprawdź jego stan w usłudze, która go wydała, i cofnij dostęp bez czekania na ewentualną reakcję partnera. Jeśli chodzi o klucz Lovable, potwierdź wykonanie tej czynności u Lovable Labs; przekazanie zgłoszenia nie jest takim potwierdzeniem.
2. Wydaj i wdroż nową wartość. Podmień ją w miejscach, które korzystały ze starej: konfiguracji aplikacji, wdrożeniach i zadaniach automatycznych. Sprawdź działanie tych zależności, aby unieważnienie klucza nie przerwało usługi ani nie pozostawiło aktywnej kopii w użyciu.
3. Sprawdź historię i logi. Ustal, w których commitach i gałęziach znalazł się sekret oraz jak długo mógł być dostępny. Następnie przejrzyj dostępne logi wystawcy pod kątem użycia w tym okresie. Podejrzana aktywność może wymagać szerszej reakcji niż sama wymiana tokenu.
4. Oceń zakres uprawnień. Ustal, do jakich projektów i operacji stary sekret dawał dostęp. Nowej wartości nadaj tylko uprawnienia potrzebne aplikacji; przy zbyt szerokim zakresie sama podmiana ciągu pozostawi podobne skutki ewentualnego kolejnego ujawnienia.

Historię repozytorium można uporządkować po unieważnieniu starego sekretu. Jest to działanie porządkowe, a nie zamiennik rotacji: wcześniejsza kopia klucza mogła już znaleźć się poza repozytorium. O zakończeniu najpilniejszej części reakcji decyduje potwierdzenie u wystawcy, że ujawniona wartość nie zapewnia już dostępu.

Przeczytaj także:

• Podejrzany link bez klikania: skaner może ujawnić także poufny adres
• Cursor czy GitHub Copilot? Tańszy plan nie zawsze oznacza tańsze agenty
• GitHub zażąda ponownego logowania przed zmianą tokenu lub webhooka