Stručně: Proces správy záplat určuje, jak aktualizace probíhají od přijetí až po doložení: do jaké třídy záplata spadá, v jakém okně se instaluje, jak se testuje a vrací zpět, kdo restartuje a jak se dokládá úspěch. Rutinní aktualizace běží plánovaně v taktu, nouzové záplaty následují předem dohodnutou rychlou cestou. Z hasičských zásahů se tak stává opakovatelný postup.
Když je každá záplata nouzový stav
Večer 21. 10. 2026 probíhal v mnoha firmách stejný scénář. Záplaty byly venku, BSI (německý Spolkový úřad pro informační bezpečnost) naléhalo a začaly otázky: Smíme teď prostě aktualizovat? Kdo testuje? Kdo restartuje služby? Kdo řekne vedení, že e-shop bude krátce nedostupný? A jak potom dokážeme, že to vyšlo?
Ve firmách bez procesu se to všechno musí vyjasňovat v tu chvíli. Ve firmách s procesem je odpověď už dána. Rozdíl není v technice, ale v dohodách, které padly předem.
Stavební kameny procesu správy záplat
Funkční proces nejdřív rozlišuje, jak je záplata naléhavá. Většinou stačí tři třídy:
| Třída | Typický důvod | Okno | Test | Schválení |
|---|---|---|---|---|
| Rutina | opravy chyb, bezpečnostní aktualizace s nízkým rizikem | pevný měsíční termín | staging, standardní testy | IT, podle plánu |
| Naléhavé | vysoké hodnocení, systém veřejně dostupný | předsunuto na krátkou dobu | zkrácený, nejdůležitější postupy | vedoucí IT |
| Nouzové | kritická zranitelnost, hlášené útoky, např. PHP2Shell | okamžitě | smoke test po instalaci | předem udělené nouzové schválení |
Kdo přiděluje jakou třídu, by mělo být stanoveno stejně jako kritéria. Samotné hodnocení patří do předchozího kroku, viz Řízení zranitelností pro střední firmy.
Důležité je předem udělené nouzové schválení. Vedení jednou v klidu rozhodne, že u nouzových záplat se smí jednat okamžitě, i když to znamená krátké přerušení. V krizi pak nemusí nikdo v noci shánět souhlas.
Stejně důležité jsou role. U každého systému by mělo být jasné, kdo instaluje aktualizace, kdo po odborné stránce testuje, zda po nich e-shop nebo portál funguje, a kdo je informován. U outsourcovaných systémů patří výslovně k věci poskytovatel hostingu a agentura, se jménem a dostupností. Pevné servisní okno by mělo být známé uvnitř firmy, aby obchod a zákaznický servis věděly, kdy jsou možná krátká přerušení.
Měřte také, jak dlouho váš proces skutečně trvá: od zveřejnění záplaty po doložené dokončení, odděleně podle třídy. Tyto vlastní hodnoty ukážou, kde to drhne, a zviditelní zlepšení. Proces, jehož délku nikdo nezná, lze stěží řídit.
Průběh záplaty v osmi krocích
Každá záplata, bez ohledu na třídu, prochází stejnými stanicemi. Liší se jen tempo a hloubka testování.
- Přijetí: Hlášení nebo dostupná aktualizace se zaeviduje s datem a zdrojem.
- Zařazení: Určit třídu, podle inventáře zjistit dotčené systémy.
- Příprava: Záloha nebo snapshot, popsat cestu zpět, informovat zúčastněné.
- Test: nejdřív na stagingu nebo na méně kritickém systému.
- Instalace: v dohodnutém okně, systém po systému.
- Restart: všechny dotčené služby a procesy, nejen balíčky.
- Doklad: zaznamenat stav balíčku, záznam v changelogu a spuštění procesu.
- Kontrola: ověřit funkci, u bezpečnostních zranitelností navíc dbát na stopy dřívějšího průniku.
Krok 6 se překvapivě často zapomíná. PHP načítá svůj kód při spuštění procesů. Dokud běží staří workeři PHP-FPM nebo procesy Apache s mod_php, pracují dál se starým, zranitelným stavem. Proč tomu tak je a jak správně restartovat, najdete v Po aktualizaci: restartovat PHP-FPM a všechny workery.
Doklady, na kterých později záleží
Záplata bez dokladu není v případě pochybností nainstalována, alespoň vůči zákazníkům, pojišťovnám nebo auditorům. U každého systému zaznamenejte, jaký stav balíčku je nainstalován, zda jsou čísla CVE uvedena v changelogu a kdy byly spuštěny běžící procesy. Na systémech Debian a Ubuntu v tom pomáhají čtecí příkazy jako tyto (název balíčku upravte podle svého systému):
# Obsahuje nainstalovaný balíček opravy?
apt-get changelog php8.3-fpm 2>/dev/null | grep -E "CVE-2026-109618|CVE-2026-109619"
# Kdy byly spuštěny běžící procesy PHP-FPM?
ps -eo pid,lstart,cmd | grep "php-fpm" | grep -v grep
Pokud je čas spuštění procesů dřívější než instalace balíčku, chybí restart. Podrobně to popisuje Doložení čísel CVE v changelogu balíčku.
Záplata uzavře zranitelnost do budoucna. Neodstraní škodlivý software, který byl vložen dříve, a nedokazuje, že se předtím nic nestalo. U nouzových záplat proto patří k postupu pevně i hledání stop.
Automatizovat tam, kde je to bezpečné
Automatické bezpečnostní aktualizace balíčků operačního systému ušetří mnoho rutinní práce. Uleví ale jen tehdy, pokud existují zálohy, někdo čte výsledky a restartují se i dotčené služby. Jak to na Linuxu nastavit a jaké má hranice, popisuje Automatické bezpečnostní aktualizace na linuxových serverech.
Kontejnery potřebují vlastní cestu. Neaktualizuje se v běžícím systému, ale znovu se sestaví image s opravenou verzí PHP a nasadí se. Proces záplatování, který zná jen servery, tyto systémy snadno přehlédne. Zařaďte proto do seznamu cest záplatování i build pipeline a registry image, s odpovědnou osobou a stejným dokladem jako u klasických serverů: Jaká verze PHP běží v nasazeném kontejneru a od kdy?
Aplikace, CMS a pluginy potřebují většinou vlastní, otestovanou cestu, protože aktualizace tam častěji mění funkce. Pevný měsíční termín je pro to správným místem. Nakonec je důležité, aby všechny cesty ústily do téže dokumentace: jednoho místa, kde je vidět, v jakém stavu je který systém.
Jak konkrétně pomáhá PHP SOS?
- Společně s vámi sepíšeme třídy záplat, okna a schválení, přizpůsobené vašim systémům a vaší organizaci.
- Tam, kde to dává smysl, nastavíme automatické bezpečnostní aktualizace s kontrolou restartu a upozorněním.
- Nouzové záplaty včetně restartu, dokladu a hledání stop přebíráme prostřednictvím naší služby záplatování PHP.
- Doklady vedeme u každého systému tak, abyste je mohli předložit zákazníkům, pojišťovnám nebo auditorům.
Závěr: Správa záplat působí nenápadně, dokud funguje. Přesně to je cíl: Když přijde další kritické hlášení, běží nacvičený postup a nikdo nemusí improvizovat.
Časté dotazy
Jaký je rozdíl mezi správou záplat a řízením zranitelností?
Řízení zranitelností zjišťuje a hodnotí zranitelnosti a rozhoduje, co je třeba udělat. Správa záplat rozhodnutí provádí: aktualizace testuje, instaluje, restartuje služby a dokládá úspěch. Obojí do sebe zapadá.
Mají se bezpečnostní aktualizace instalovat automaticky?
U balíčků operačního systému to často dává smysl, pokud existují zálohy a po běhu se provádí kontrola. Důležité je, aby se restartovaly i dotčené služby. U PHP jinak zůstávají v paměti staré procesy se zranitelným kódem.
Jak doložím, že záplata skutečně funguje?
Nainstalovaným stavem balíčku a čísly CVE v changelogu balíčku, časem instalace a časem spuštění běžících procesů, který musí být po instalaci.
Co dělat, když aktualizace něco pokazí?
K tomu slouží cesta zpět: záloha nebo snapshot před aktualizací a popsaný postup návratu. U bezpečnostních aktualizací by měl být návrat výjimkou a spojit se s přechodným opatřením.