GitHub rozšiřuje ochranu přihlašovacích údajů pomocí AI, také v Copilot CLI

Dnes se AI agent podílí na každém třetím pull requestu na GitHubu. Před rokem to bylo méně než u každého desátého. Pokud toto tempo vydrží, během příštích dvou let by většinu kódu odesílaného na GitHub mohli psát agenti. Značnou část tohoto kódu možná člověk nikdy celou nepřečte.

Pokud vývojáři a agenti pracují rychleji, musí s rostoucím tempem tvorby kódu držet krok i ochrana. Pro GitHub to znamená předcházet většímu počtu úniků a u těch zbývajících omezit závislost nápravy na ruční práci lidí.

U úniků citlivých údajů, jako jsou hesla, tokeny a API klíče, jde o zásadní zlom. Vývojáři nejsou méně opatrní – jen už nestíhají tempu vývoje. Nástroje, které vývojářům umožňují vytvářet více softwaru, by měly převzít také větší díl práce spojené s jeho ochranou.

GitHub toto tvrzení dokládá daty za devět čtvrtletí. Zároveň představuje klasifikátor, který společně s Microsoft Applied Sciences dotrénoval tak, aby rozšířil push protection i na citlivé údaje bez pevně dané struktury. Model posoudí celou sadu potenciálně citlivých údajů za méně než dvě milisekundy a mohl by více než zdvojnásobit počet údajů, jejichž úniku dokáže GitHub zabránit.

Ve veřejně dostupném kódu se nový citlivý údaj objeví přibližně každé dvě sekundy. Za poslední tři roky se tento počet každoročně zdvojnásoboval. Ve veřejné debatě se rychle objevuje vysvětlení, že AI vede vývojáře k menší opatrnosti.

Mezi 2. čtvrtletím 2024 a 2. čtvrtletím 2026 vzrostl počet kontrolovaných pushů 2,84krát, zatímco počet pushů obsahujících přihlašovací údaje vzrostl 2,59krát. V datech za devět úplných čtvrtletí GitHub nezjistil statisticky prokazatelný trend ve vývoji podílu pushů s citlivými údaji. Současně data naznačují, že vývojáři riziku nechtěného zveřejnění rozumějí lépe než dříve a jsou méně ochotní ho přijmout. Podíl blokací při pushi, které vývojáři obešli, ve stejném období lineárně klesl z 6,63 % na 3,93 %. Tato čísla zpochybňují rozšířené tvrzení, že agenti vedou vývojáře k menší opatrnosti.

Více pushů, bez jasného růstu podílu pushů s citlivými údaji

2. čtvrtletí 2026 · 574 milionů pushů · 0,47 % s citlivými údaji

Veřejné pushe od 2. čtvrtletí 2024 do 2. čtvrtletí 2026. Podíl vyjadřuje, v kolika pushích byl zjištěn citlivý údaj. Data zahrnují podporované vzory poskytovatelů včetně vlastních tokenů GitHubu.

Při neměnném podílu znamená dvojnásobná aktivita dvojnásobný očekávaný počet úniků. Pokud každý únik vyžaduje stejný zásah člověka, zdvojnásobí se i objem práce. Průměrná doba do ručního zneplatnění citlivého údaje se pohybuje kolem 40 dnů; přibližně v jednom z pěti případů přesáhla 90 dnů. Tvorba softwaru zrychluje, ale zveřejněné přihlašovací údaje mohou zůstávat použitelné týdny či měsíce, protože ruční náprava nedokáže růst stejným tempem jako vývoj.

Samotné nabádání vývojářů k větší opatrnosti tento problém nevyřeší. Má-li být vývoj softwaru dlouhodobě udržitelný, je s rostoucím množstvím kódu nutné předcházet více únikům a snižovat množství lidské práce potřebné k řešení těch zbývajících.

Zkušenosti GitHubu z posledních let práce na secret scanning ukazují, že největší přínos má propojení detekce se systémy, které mohou rovnou zasáhnout.

Katalog GitHubu pokrývá více než 150 technologických partnerů zapojených do secret scanning partnership program. GitHub s vydavateli přihlašovacích údajů vytváří detektory a hlásí jim veřejná zveřejnění, aby na ně mohli reagovat. Ve 2. čtvrtletí 2026 kontrola veřejného obsahu úspěšně hlásila průměrně 26 nálezů přihlašovacích údajů za sekundu, včetně opakovaných záchytů. Řada partnerů po oznámení token okamžitě zneplatní. Týká se to například API klíčů OpenAI, přihlašovacích údajů účtů Google Cloud, webhooků Slack, uživatelských tokenů Hugging Face nebo klíčů SendGrid. Vlastník může stále potřebovat token nahradit, ale jeho zneplatnění nemusí čekat na to, až vývojář najde a zpracuje upozornění z GitHubu.

Push protection zasahuje dříve. Zastaví rozpoznatelné přihlašovací údaje ještě předtím, než se dostanou do historie repozitáře, a umožní vývojáři nebo agentovi změnu opravit dříve, než vznikne únik vyžadující prošetření. GitHub spolupracuje s technologickými partnery na co nejvyšší přesnosti jejich detektorů. Jakmile je přesnost dostatečná, může pro dané typy údajů zapnout push protection vývojářské komunitě ve výchozím nastavení.

Díky práci partnerů zablokovala push protection za poslední měsíc citlivý údaj alespoň jednou za sekundu. U přihlašovacích údajů navázaných na konkrétního vydavatele GitHub zablokuje více případů, než kolik jich ochranou projde. Pro vývojáře se taková ochrana stává běžnou součástí práce.

Při započtení dalších typů citlivých údajů zastaví push protection přibližně 30 % nově zjištěných případů ještě před zápisem do historie repozitáře. Zbývajících 70 % GitHub odhalí až poté, co už byly přihlašovací údaje zveřejněny. Z toho vyplývá:

1. Prevenci lze škálovat výpočetním výkonem, náprava však stále závisí na lidech.
2. Odmítnutí pushe stojí výpočetní prostředky; řešení úniku údaje, který už je ve viditelné historii, stojí čas a pozornost vývojáře.
3. S rostoucím množstvím kódu je nutné zabránit více únikům a snížit lidskou práci potřebnou k řešení ostatních. Jinak se objem vznikajících zranitelností stane nezvládnutelným.

Výzvy k větší opatrnosti tuto nerovnováhu nevyřeší. Rozpoznávání většího počtu citlivých údajů v dřívějších fázích vývoje je úkol, který musí převzít samotná platforma.

Dokud citlivý údaj neprojde pushem, náklady na jeho zastavení jsou nízké a rozhodnutí má dvě možnosti: zablokovat, nebo povolit. Poté už může tentýž řetězec umožnit přihlášení do skutečného systému a možné náklady nemají pevnou horní hranici.

V mnoha případech je jediným vodítkem pro detekci okolní kód a širší kontext. Token vydaný poskytovatelem může mít rozpoznatelnou předponu. Heslo interní databáze ale může být zcela nestrukturované, bez jakéhokoli identifikačního vzoru. GitHub už kontext využíval k vyhledávání těchto údajů po pushi; problémem bylo vyvážit posuzování podle kontextu s dalšími požadavky.

GitHub to označuje jako „problém čtyř těles“ ochrany citlivých údajů: přesnost, latence, propustnost a náklady jsou vzájemně provázané. Přínos prevence musí ospravedlnit čas, který vývojáři zabere. Nález vhodný k pozdější kontrole nemusí být dostatečným důvodem k zablokování pushe. Falešně pozitivní nález vývojáře přeruší a oslabí jeho důvěru v další blokaci. Příliš pomalá, drahá nebo obtížně škálovatelná kontrola zase omezuje, jak často ji lze spouštět.

Nový klasifikátor ModernBERT posuzuje potenciálně citlivé údaje v kontextu, aniž by generoval kód nebo text. Podle GitHubu je přesnější než dosavadní postupy založené na velkých jazykových modelech a zároveň velmi rychlý: dávky kandidátních údajů vyhodnotí za méně než dvě milisekundy. Má také dostatečně nízké provozní náklady, aby mohl běžet ve velkém měřítku přímo během zpracování pushe.

Zařazení modelu do push protection může více než zdvojnásobit počet citlivých údajů, jejichž úniku GitHub dokáže zabránit. Funkce je aktuálně v private preview. Později v říjnu 2026 má být dostupná organizacím s GitHub Secret Protection v Enterprise Cloud a GitHub Teams. Bude spotřebovávat AI kredity.

GitHub model rozšiřuje také do dalších míst, kde vývojáři pracují, nejen do kontroly při pushi.

• Od 7. října 2026 přecházejí všechny organizace s AI secret detection automaticky na nový model. Upozornění vzniklá při těchto kontrolách po pushi zůstávají součástí zakoupené služby secret scanning bez dodatečných nákladů.
• Model bude také součástí GitHub Enterprise Server 3.23 v public preview. Zákazníkům Secret Protection tak přinese upozornění na nálezy pomocí AI i v prostředích zcela oddělených od vnějších sítí, tedy air-gapped.
• GitHub přidává klasifikátor do příkazu /security-review v Copilot CLI a Copilot App. Uživatelé Copilot tak budou moci řešit citlivé údaje ještě před pushem, aniž by jejich organizace musela mít plán GitHub Secret Protection. Spotřeba AI kreditů bude ve Vašem přehledu AI usage insights přiřazena ke GitHub Secret Protection.

Cílem GitHubu je umožnit vývojářům svěřovat agentům více práce bez dohledu nad každým požadavkem. Současně by počet lidí potřebných k ochraně přihlašovacích údajů neměl růst přímo úměrně množství vytvářeného kódu. Pokrok v ochraně softwaru musí držet krok s pokrokem v jeho tvorbě.