GitHub nově hlídá klíče Lovable a Supabase, únik ale řeší dvěma způsoby

GitHub 5. října 2026 rozšířil secret scanning o klíč Lovable, tokeny Pydantic Logfire a AI Gateway a dva druhy přístupových tokenů Supabase. Při nálezu klíče Lovable ve veřejném repozitáři jej předá jeho vydavateli. Nález ostatních nově rozpoznávaných tokenů vede k upozornění, které musí řešit správce repozitáře, pokud má uživatelská upozornění zapnutá.

Rozdíl určuje, komu GitHub nález oznámí jako první, nikoli zda už uniklý údaj přestal platit. Lovable Labs může klíč po obdržení partnerského hlášení ověřit a zneplatnit; u tokenu Supabase nebo Pydantic musí držitel zajistit zneplatnění či výměnu sám. Vývojář proto potřebuje znát přesný typ nalezeného údaje i stav přístupu u služby, která jej vydala.

Pět vzorů, tři vydavatelé

Rozšíření se týká konkrétních přihlašovacích údajů, nikoli všech tajných hodnot používaných v projektech těchto služeb. GitHub nově rozpoznává následující typy:

• Lovable Labs: lovable_api_key.
• Pydantic Services Inc.: logfire_token a pydantic_ai_gateway_api_key.
• Supabase: supabase_oauth_access_token a supabase_scoped_personal_access_token.

U Supabase jde o přístupový token OAuth a osobní přístupový token s omezeným rozsahem oprávnění. U Pydantic se změna vztahuje k Logfire a AI Gateway. Pro posouzení nálezu je důležité označení typu tajemství, které detektor přiřadí, ne samotná zmínka o názvu služby v kódu projektu.

Seznam také vymezuje rozsah novinky. Používá-li aplikace jiný klíč Supabase nebo jiné přihlašovací údaje Pydantic, nelze z tohoto oznámení vyvodit, že pro ně právě přibyl stejný detektor nebo stejná cesta hlášení. A ani shoda s podporovaným vzorem sama neříká, zda nalezená hodnota dosud poskytuje platný přístup.

Veřejný klíč Lovable dostane přímo vydavatel

Zařazení Lovable Labs do partnerského programu má pro veřejný repozitář konkrétní důsledek: nález klíče typu lovable_api_key GitHub předá Lovable Labs. Vydavatel tak může posoudit platnost údaje a zasáhnout u přístupu, který sám spravuje. Pouhé předání však ještě neznamená, že klíč byl skutečně zneplatněn nebo nahrazen.

Podle dokumentace partnerského hlášení GitHubu poskytovatel nalezený řetězec ověří a podle rizika rozhodne, zda tajemství zneplatní, vydá nové, nebo kontaktuje uživatele. Partnerské hlášení jde přímo poskytovateli a samo se nezobrazuje mezi běžnými upozorněními na kartě Security and quality. Prázdný seznam upozornění v repozitáři tedy není potvrzením, že veřejně vystavený klíč Lovable zůstal bez povšimnutí nebo že už je bezpečný.

Vlastník aplikace má přesto důvod jednat. Pokud zná konkrétní veřejně vystavený klíč, měl by ověřit jeho stav u Lovable a připravit náhradu pro místa, kde jej aplikace používá. Partnerská cesta může zásah vydavatele urychlit, ale její výsledek závisí na ověření nálezu a rozhodnutí poskytovatele. Dokud není původní přístup prokazatelně neplatný, je rozumné považovat jej za kompromitovaný.

Tokeny Supabase a Pydantic vyžadují zásah držitele

U nových tokenů Supabase a Pydantic je podstatné uživatelské upozornění v repozitáři. Pokud je tato funkce pro repozitář dostupná a zapnutá, správce najde nález na kartě Security and quality v části Secret scanning. Upozornění ukáže, který podporovaný typ tajemství byl nalezen; samo nezruší přístup u Supabase ani u Pydantic.

Uživatelská upozornění se mohou týkat veřejných i soukromých repozitářů, ale jejich dostupnost závisí na nastavení a oprávnění konkrétního repozitáře. Partnerské předání klíče Lovable se naproti tomu vztahuje na veřejný nález. Veřejný a soukromý repozitář se proto u téhož klíče mohou lišit v tom, komu GitHub nález oznámí. Při známém úniku v soukromém projektu není bezpečné čekat na upozornění, které v něm nemusí být zapnuté.

Uživatel může v seznamu upozornění hledat podle vydavatele nebo typu tajemství a rozlišit tak například token OAuth od osobního tokenu Supabase. Rozsah oprávnění konkrétního tokenu ovlivňuje možné následky úniku, nikoli základní potřebu vystavený platný údaj zneplatnit. Zvlášť u tokenu použitého v nasazení aplikace je nutné zjistit, kde všude je jeho stará hodnota uložená, aby výměna nepřerušila provoz.

Od nálezu k neplatnému klíči

Po zjištění úniku je rozhodující zneplatnění původního přístupu u vydavatele. U tokenů Supabase a Pydantic tuto změnu musí zajistit jejich držitel; u klíče Lovable je třeba nejprve ověřit, zda už vydavatel na partnerské hlášení reagoval. Pokud to není jasné, má vývojář řešit výměnu klíče sám. Náhradní údaj pak musí vložit i do konfigurace běžící aplikace, automatizovaného nasazení a dalších míst, která starý přístup používají.

Smazání klíče z aktuální verze souboru nezneplatní jeho kopii v historii repozitáře ani hodnotu, kterou si někdo již uložil. Stejně tak uzavření upozornění na GitHubu nemění platnost tokenu u jeho vydavatele. Smysluplné pořadí je zajistit nový funkční přístup, vyřadit původní hodnotu a teprve potom uzavřít upozornění. Pokud služba nabízí záznamy o použití tokenu, mohou pomoci určit, zda byl vystavený údaj po úniku použit.

Pro aplikaci propojující Lovable se Supabase může jeden repozitář obsahovat údaje obou služeb, ale každá vystavená hodnota vyžaduje vlastní ověření a výměnu. Partnerské hlášení klíče Lovable neřeší token Supabase uložený vedle něj. Incident končí až ve chvíli, kdy původní přihlašovací údaje přestaly fungovat a aplikace používá jejich bezpečně uložené náhrady.

Přečtěte si také:

• Bitwarden, nebo 1Password: nižší cena neřeší způsob obnovy
• Docker posílá AI agenty do cloudu, tajné klíče jim ale neukáže
• Supabase, nebo Firebase: levný začátek může skrýt drahé čtení dat