GitHub přestal týdně skenovat spící repozitáře — ochranu lze vrátit měsíčně

GitHub v changelogu z 1. října 2026 uvedl, že týdenní plánované skeny při výchozím nastavení code scanningu a v GitHub Code Quality nově začínají až po analýze vyvolané pushem nebo pull requestem. Změna platí pro GitHub Enterprise Cloud. Úvodní validační sken po zapnutí výchozího nastavení stále poskytne první nálezy, ale sám týdenní režim nespustí.

Podle dokumentace výchozího nastavení zůstává repozitář pro týdenní skeny aktivní, pokud v posledních 180 dnech sken vyvolal push nebo pull request; organizace může pro neaktivní repozitáře zapnout volbu „Keep scheduled scans running every 30 days for inactive repositories“. Správce tak může po zapnutí CodeQL vidět první výsledek, aniž by pro daný projekt běžel týdenní plán. Měsíční volba se vztahuje na repozitáře používající výchozí nastavení code scanningu.

První výsledek ještě neznamená týdenní plán

Po zapnutí výchozího nastavení GitHub provede validační analýzu a zpřístupní její nálezy. Tím vznikne výchozí obraz stavu kódu, ale pro plánování dalších týdenních běhů se tento sken za aktivitu nepovažuje. U projektu, v němž se už dál nevyvíjí, proto může první výsledek zůstat jediným plánem neprodlouženým nálezem, dokud organizace nezapne kontrolu neaktivních repozitářů.

Rozhodující je až pozdější push nebo pull request, který skutečně spustí analýzu. Historie Git událostí z doby před zapnutím výchozího nastavení tuto podmínku nesplní: repozitář se nestane aktivním jen proto, že měl v minulosti commity nebo otevřené pull requesty. Při hromadném zavedení CodeQL tak může několik projektů získat počáteční nálezy ve stejný den, ale pravidelný týdenní režim začne jen u těch, kde následná vývojová událost vyvolá sken.

Počáteční validace ani sken spuštěný změnou rozpoznaných jazyků už nejsou v přehledu Releases Index vedeny jako události zahajující týdenní režim. Pro správce je podstatný původ analýzy, nikoli samotná přítomnost nového výsledku. Ani změna bezpečnostní konfigurace tedy automaticky neznamená, že se po ní začne neaktivní repozitář každý týden znovu analyzovat.

Aktivitu určuje původ skenu v posledních 180 dnech

Jakmile push nebo pull request vyvolá sken při výchozím nastavení, repozitář splňuje podmínku pro týdenní plánované kontroly. Pokud v následujících 180 dnech nepřijde další takto vyvolaná analýza, týdenní skeny se zastaví. Nový odpovídající sken podmínku aktivity znovu splní. Nejde tedy o lhůtu počítanou od zapnutí CodeQL, ale od analýzy, kterou skutečně spustila příslušná vývojová událost.

Čas posledního výsledku sám o sobě nestačí. Plánovaný sken může přidat novější nález, aniž by prodloužil období aktivity; totéž platí pro počáteční sken a analýzy po změně konfigurace nebo jazyka. Při posuzování rozvrhu je proto nutné odlišit, kdy analýza proběhla, od toho, co ji vyvolalo. Jinak může repozitář s nedávným nálezem vypadat jako kandidát na další týdenní běh, přestože podmínku aktivity už nesplňuje.

GitHub sdílí údaj o aktivitě mezi code scanningem a GitHub Code Quality. Změna týdenního plánování se tak týká obou uvedených funkcí, pravidlo pro třicetidenní kontrolu neaktivních projektů však dokumentace popisuje pro výchozí nastavení code scanningu. U repozitářů s vlastním pokročilým nastavením je třeba posuzovat jejich skutečně nastavené spouštěče a rozvrh, nikoli na ně automaticky přenášet pravidla výchozího režimu.

Měsíční kontrola je volba celé organizace

Organizace může ponechat plánované skeny i projektům, které už nesplňují podmínku pro týdenní režim. V nastavení organizace vede cesta přes Settings, Advanced Security a Global settings do části Code scanning. Tam lze zapnout kontrolu neaktivních repozitářů s výchozím nastavením každých 30 dní. Jde o pevně stanovený interval: správce jej v této volbě nemůže upravit podle vlastního rozvrhu.

Volba mění pokrytí repozitářů bez nedávného vývoje. U projektu, který po úvodní validaci nikdy neměl analýzu vyvolanou pushem či pull requestem, vytvoří opakovanou kontrolu i bez týdenního plánu. U projektu, jemuž období aktivity skončilo později, zachová řidší pravidelné skenování. Zároveň přidává plánované běhy tam, kde by bez zapnutí volby nevznikaly; při správě velkého počtu repozitářů proto záleží na tom, kolik neaktivních projektů organizace skutečně potřebuje pravidelně kontrolovat.

Měsíční sken sám neobnoví týdenní režim. Je to plánovaná analýza, nikoli push nebo pull request, a do období aktivity se nezapočítává. Pokud se na neaktivním projektu později znovu začne pracovat a příslušná událost spustí sken, může se pro něj opět uplatnit týdenní plán. Přepínač tak řeší kontinuitu kontroly nečinného kódu, zatímco četnější režim nadále závisí na analýze vyvolané vývojem.

Co ukáže audit hromadného nasazení

Seznam repozitářů se zapnutým CodeQL ještě neříká, ve kterých projektech lze čekat další plánovaný výsledek. Pro každý projekt je potřeba spojit způsob nastavení, historii spouštěčů analýz a organizační volbu pro neaktivní repozitáře. Takový soupis oddělí jednorázově zkontrolovaný kód od kódu v týdenním nebo měsíčním režimu:

• Výchozí nastavení a úvodní validace ukazují, že první analýza proběhla. Samy neurčují další týdenní běh.
• Analýza vyvolaná pushem nebo pull requestem po zapnutí nastavení určuje začátek týdenního režimu. Datum commitu bez spuštěného skenu nestačí.
• Původ poslední takové analýzy ukáže, zda repozitář ještě spadá do období aktivity. Pozdější plánovaný sken toto období neprodlouží.
• Organizační volba pro neaktivní repozitáře ukáže, zda projekt s výchozím nastavením dostane další plánovanou kontrolu i bez nové vývojové události.

Výsledkem mohou být dvě skupiny projektů se stejně čerstvým nálezem, ale odlišným očekávaným rozvrhem. Pro správce mnoha repozitářů je právě toto rozlišení důležité při hodnocení pokrytí: první nález prokazuje provedenou analýzu, zatímco další pravidelný výsledek závisí na spouštěči skenu nebo na zapnuté organizační volbě.

Přečtěte si také:

• Passkey, nebo heslo: ochranu může zrušit slabá obnova účtu
• Claude Code, nebo Codex: benchmark nezná váš repozitář
• GitHub Actions, nebo GitLab CI: účet mění minuty, cache i runner