Kniha úloh pro správu záplat (Patch Management Runbook): Zabezpečení CMS v 6 krocích

4 března, 2026
Martin Přibyl

Soubor pravidel pro správu záplat je operativní reakcí na situaci, kdy se počet hrozeb za poslední tři roky zčtyřnásobil:

Podle Verizon DBIR se podíl zneužití zranitelností jako vektoru útoku zvýšil z 5 % (2022) na 20 % (2025).

Tento článek obsahuje šablonu připravenou k použití pro projekty WordPress a TYPO3 v malých a středních podnicích: s maticí rolí, konkrétními příkazy CLI, strategií zpětného vrácení a kontrolním seznamem, který lze integrovat přímo do stávajících smluv o údržbě.

Proč je správa oprav pro malé a střední podniky provozním problémem?

Zpráva Verizon Data Breach Investigations Report 2025 ukazuje: Zneužití známých zranitelností bylo počátečním vektorem útoku ve 20 % všech analyzovaných bezpečnostních incidentů. To odpovídá nárůstu o 34 % oproti předchozímu roku.

Nezáplatované systémy se tak téměř vyrovnají ukradeným přístupovým údajům jako nejčastější vstupní bod pro útočníky.

Zároveň se zvyšuje počet známých zranitelností. V roce 2017 bylo zveřejněno přibližně 14 700 CVE. V roce 2024 jich bylo téměř 40 000. V roce 2025 bylo zaregistrováno 48 185 nových CVE. To je více než 130 nových zranitelností denně.

2017: přibližně 14 700 CVE
2018: přibližně 16 500 CVE
2019: přibližně 17 300 CVE
2020: přibližně 18 300 CVE
2021: přibližně 20 100 CVE
2022: přibližně 25 200 CVE
2023: cca 29 000 CVE
2024: 39 962 CVE
2025: 48 185 CVE (nový rekord, +20,6 % oproti předchozímu roku)

Pro středně velké společnosti s 50 až 250 zaměstnanci to znamená. firemní webové stránky. intranet nebo internetový obchod založené na systémech WordPress nebo TYPO3 nejsou izolovaným marketingovým nástrojem. Je to plocha pro útoky. A to, zda je tento povrch uzavřený nebo otevřený, nezávisí na technologii, ale na tom, zda existuje proces.

Skutečnost v mnoha firmách je jiná. Aktualizace se instalují, “když je čas”. Otázka, kdo vydání schvaluje, je nejasná. Neexistuje žádný plán zpětného vrácení. Výsledek: aktualizace jsou buď opožděné (riziko), nebo uspěchané (nestabilita).

Co dělá runbook pro správu záplat

Runbook není strategický dokument. Je to provozní příručka, která přesně popisuje, kdo, co a kdy dělá. Odpovídá na tři otázky, které ve většině smluv o údržbě zůstávají nezodpovězeny:

Kdo rozhoduje o použití záplaty?
Jak se záplata testuje před uvedením do provozu?
Co se stane, když po aktualizaci něco nefunguje?

Potřebujete správu záplat, která vyhovuje vašemu nastavení?

Obraťte se na náš tým

Naléhavost těchto otázek je vidět na třech obrázcích. Podíl zneužití zranitelností na všech narušeních dat se během dvou let zečtyřnásobil: z přibližně 5 % (Verizon DBIR 2023) na 14 % (DBIR 2024, způsobené útoky MOVEit) až 20 % (DBIR 2025).

Průměrná doba od zveřejnění zranitelnosti do prvního aktivního zneužití byla v roce 2024 přibližně pět dní.

Pokud nemáte strukturovaný proces oprav, dáváte útočníkům příležitost, kterou mohou spolehlivě využít. A to je právě rozdíl mezi runbookem a kontrolním seznamem: Kontrolní seznam vám říká, co máte dělat.

V příručce se také uvádí,

kdo to dělá,
v jakém pořadí a
co se stane v případě odchylek.

Pro vedoucího digitálního oddělení, který je zároveň zodpovědný za řízení projektu, kontrolu kvality a rozpočet, je to rozdíl mezi fungujícím procesem a procesem, který se zasekl na jediné osobě.

4 Role v procesu opravy: Kdo co dělá?

Fungující proces opravy nepotřebuje velkou organizaci. Potřebuje jasné zadání. Následující matice rolí odráží realitu ve středně velkých digitálních týmech: málo lidí, několik klobouků, ale jasné odpovědnosti.

Majitel záplaty

Vlastník záplaty je osoba, která je zodpovědná za celý cyklus aktualizace. Ve většině nastavení je to digitální vedoucí pracovník nebo externí agentura v rámci smlouvy o údržbě. Vlastník záplat rozhoduje o tom, které aktualizace mají být nainstalovány, definuje okno údržby a vydává konečný příkaz ke spuštění pro produkční prostředí.

Rozhodující: Vlastník záplaty nemusí záplatovat sám. Musí mít pravomoc rozhodovat a být kontaktní v případě problémů.

Exekutor

Provozovatel provádí aktualizaci technicky. Je to vývojář nebo inženýr DevOps, který testuje staging, nasazuje záplatu a provádí funkční test.

V projektech WordPress pracuje vykonavatel obvykle s WP-CLI.

Pro projekty TYPO3 s nástrojem Composer a TYPO3 CLI.

QA tester

Auditor kontroly kvality není totožný s vykonavatelem. To je záměrné. Ten, kdo nasazuje aktualizaci, by to neměl dělat sám. Tester QA testuje kritické cesty po nasazení:

Kontaktní formulář
Pokladna
Přihlášení
Funkce vyhledávání

V malých týmech to může být sám vlastník opravy.

Zúčastněné strany

Zúčastněná strana je informována, ale nerozhoduje. Obvykle se jedná o vedení nebo oddělení odpovědné za obsah webových stránek.

Zainteresovaná strana obdrží po opravě stručné shrnutí: Co bylo aktualizováno, vyskytly se nějaké anomálie, plánuje se následná aktualizace?

"Záplaty málokdy selžou kvůli technologii. Selhávají proto, že nikdo nedefinoval, kdo dává příkaz "go"."

Christian Koch Generální ředitel společnosti .hyperdigital Německo

"Runbook vás nutí předem si ujasnit, co budete dělat, když se něco pokazí. Bez něj plánujete pouze úspěch."

Tomáš Rihák Full-Stack Web & App Developer

Údržba s jasnými rolemi namísto ad hoc záplat?

TYPO3 a WordPress: Naše odborné znalosti CMS

Příručka pro správu záplat v 6 krocích

Následující příručka popisuje celý cyklus pravidelného spuštění opravy. Zahrnuje jak WordPress, tak TYPO3 a je přizpůsoben realitě středně velkých projektů:

jedna až pět zúčastněných osob
Žádný specializovaný operační tým
Smíšená hostitelská prostředí

Krok 1: Detekce a vyhodnocení záplat

Vlastník záplaty každý týden kontroluje, zda jsou k dispozici nové aktualizace.

Pro WordPress to znamená: aktualizace jádra, aktualizace zásuvných modulů a aktualizace témat.

Pro TYPO3: Základní opravy v rámci řady LTS a aktualizace rozšíření.

Každá aktualizace je zařazena do jedné ze tří kategorií.

3 kategorie náplastí: Jak naléhavá je aktualizace?

Kritické (aktualizace zabezpečení)

Instalace do 48 hodin. S aktivním exploitem: okamžitě. Verizon DBIR 2025 ukazuje, že průměrná doba od odhalení zranitelnosti po její aktivní zneužití klesla v roce 2024 na přibližně pět dní. U kritických záplat se počítá každý den.

Důležité (oprava chyby, aktualizace funkce)

Instalace v příštím pravidelném okně údržby. To je pravidlo pro menší verze.

Volitelné (aktualizace funkcí, zásadní aktualizace)

Vědomě si naplánujte, otestujte a případně nastavte vlastní projekt. Upgrade z TYPO3 12 LTS na 13 LTS není oprava, ale migrační projekt.

Krok 2: Příprava prostředí

Žádná záplata nepůjde přímo do výroby. Výjimky nepotvrzují pravidlo, ale způsobují výpadky.

Staging prostředí musí co nejvíce odpovídat produkčnímu prostředí: stejná verze PHP, stejná verze databáze, stejná konfigurace serveru.

Pro projekty WordPress to znamená stejnou konstelaci zásuvných modulů.

Pro TYPO3: stejná konfigurace rozšíření a stejné nastavení TypoScriptu.

Před opravou na staging:

Vytvoření výpisu databáze prostředí staging
Snímek souborového systému dokumentu nebo hash revize systému Git
Vyprázdněte protokol chyb PHP, abyste okamžitě zjistili nové chyby.

Krok 3: Aplikace záplaty na staging

Zde se cesty rozcházejí v závislosti na systému CMS. Konkrétní příkazy pro Executor:

WordPress s WP-CLI (verze 2.12):

# Aktuelle Version prüfen
wp core version

# Verfügbare Updates anzeigen
wp core check-update

# Core-Update einspielen (nur Minor-Releases)
wp core update --minor

# Alle Plugins aktualisieren
wp plugin update --all

# Alle Themes aktualisieren
wp theme update --all

# Datenbank-Update ausführen
wp core update-db

# Prüfsummen verifizieren
wp core verify-checksums

TYPO3 s Composerem (LTS 13.4, aktuální verze opravy 13.4.26):

# Aktuell installierte Pakete anzeigen
composer info "typo3/*"

# Patch-Level-Update innerhalb der LTS-Linie
composer update "typo3/cms-*" --with-all-dependencies

# Datenbank-Schema aktualisieren
./vendor/bin/typo3 database:updateschema

# Caches leeren
./vendor/bin/typo3 cache:flush

# Upgrade Wizards ausführen (falls nötig)
./vendor/bin/typo3 upgrade:run

Důležité: Omezení composer v souboru composer.json zůstává pro aktualizace záplat nezměněno. Každý, kdo zadal adresu ^13.4, automaticky obdrží nejnovější úroveň záplaty v rámci řádku LTS.

TYPO3 13.4 LTS bude pravidelně podporován do prosince 2027, komerční ELTS do roku 2031.

Současně bude 21. dubna 2026 vydána verze TYPO3 14 LTS. Současná sprintová verze 14.1.1 (vydaná v únoru 2026) je vhodná pro testování a hodnocení, ale ne pro produktivní provoz.

Upgrade z verze 13 LTS na verzi 14 LTS není oprava, ale samostatný migrační projekt.

Pro projekty na platformě TYPO3 12 LTS to začíná být naléhavé: Pravidelná podpora končí v dubnu 2026. Kdo do té doby nepřejde na verzi 13 LTS nebo 14 LTS, nebude již dostávat bezpečnostní záplaty, s výjimkou placené služby ELTS.

Krok 4: Funkční testy pro etapizaci

Tester QA testuje následujících 5 kritických cest po stagingovém nasazení:

1. kontaktní formulář a formuláře: Odeslání, kontrola potvrzovacího e-mailu, ověření záznamů v databázi.

2. vyhledávání a navigace: hlavní navigace, odkazy v zápatí, interní vyhledávání.

3. média a soubory: Zobrazení obrázků, stahování PDF, vkládání videí.

4. přihlašování uživatelů: přihlašování ve frontendu a backendu, přidělování práv, správa relací.

5. výkon a protokol o chybách: namátkově kontrolujte dobu načítání, hledejte v protokolu o chybách PHP nové záznamy, kontrolujte konzolu prohlížeče na chyby JavaScriptu.

Teprve když tester QA odškrtne všech pět bodů, nahlásí vlastníkovi opravy: Staging OK. Pokud se objeví nějaké nesrovnalosti, záplata se vrátí zpět do staging a chyba se zdokumentuje.

Krok 5: Nasazení do výroby

Vlastník záplaty dává souhlas k použití v produkčním prostředí. Před:

Vytvoření kompletní zálohy produkčního systému (databáze a souborového systému).
Sdělte, kdy je možné provádět údržbu (nejlépe v úterý nebo ve středu od 6:00 do 8:00, kdy je nejnižší intenzita provozu v B2B).
Aktivace režimu údržby (pro WordPress: wp maintenance-mode activate)

Poté proveďte stejné příkazy jako ve fázi Staging. Poté: Deaktivujte režim údržby, proveďte rychlý test QA na produkci (kontaktní formulář, úvodní stránka, jedna podstránka), informujte zúčastněné strany.

Krok 6: Dokumentace a připravenost na vrácení

Prováděcí jednotka po každém cyklu oprav dokumentuje:

Které balíčky byly aktualizovány (verze před → po)?
Vyskytly se nějaké abnormality ve stádiu nebo produkci?
Jak dlouho celý proces trval?

Strategie rollback zůstává aktivní po dobu 72 hodin po nasazení. To znamená, že záloha zůstává dostupná, vykonavatel je přístupný a existuje zdokumentovaná cesta zpět k předchozímu stavu.

Pro WordPress: Import zálohy (databáze a wp-content).

Pro TYPO3: composer install z předchozího composer.lock, obnovte výpis databáze.

Věděli jste, že...?

Podle studie, kterou provedl Ponemon Institute jménem společnosti ServiceNow, 60 % dotázaných obětí narušení uvedlo, že incident byl způsoben známou, ale neopravenou zranitelností.

V samostatném průzkumu společnosti Tanium uvedlo 81 % dotázaných ředitelů IT a CISO, že alespoň jednou záměrně odložili nasazení kritické záplaty, aby neohrozili probíhající obchodní operace.

A 80 % IT manažerů následně zjistilo, že záplata, o které si mysleli, že byla plně zavedena, nebyla nainstalována do všech systémů.

Zdroje: Ponemon Institute / ServiceNow: “Costs and Consequences of Gaps in Vulnerability Response”, 2019; Tanium: “Global Resilience Gap Study”, 2019.

Nastavení strukturovaných aktualizačních procesů pro WordPress nebo TYPO3?

Naše řešení pro malé a střední podniky

Kontrolní seznam správy záplat: Šablona pro přijetí

Následující kontrolní seznam shrnuje runbook v kompaktní formě, kterou lze vytisknout, přenést do systému ticketů nebo použít jako šablonu pro smlouvy o údržbě.

6 kroků kontrolního seznamu správy záplat:

Detekce: Týdenní kontrola nových aktualizací (jádro, pluginy/rozšíření, témata). Kategorizace na kritické, důležité a nepovinné.
Příprava etapy: Vytvoření výpisu databáze, dokumentace stavu souborového systému, vymazání chybových protokolů.
Staging deployment: Použijte záplatu, proveďte příkazy CLI pro každý CMS, ověřte kontrolní součty.
QA test: Test 5 kritických cest (formuláře, navigace, média, přihlášení, výkon). Staging-OK nebo rollback.
Produkce: Vytvoření zálohy, sdělení okna údržby, nasazení opravy, rychlé testování QA, informování zúčastněných stran.
Dokumentace: Dokumentujte stavy verzí, zaznamenávejte anomálie, udržujte připravenost k vrácení po dobu 72 hodin.

3 časté chyby, kterým runbook předchází

Chyba 1: Instalace záplat bez etapizace

V praxi se to týká především projektů WordPress s aktivovanými automatickými aktualizacemi.

WordPress ve výchozím nastavení automaticky instaluje menší verze a bezpečnostní záplaty. Na jednoduchých firemních stránkách je to přijatelné.

Projekty s 20 a více aktivními pluginy, vlastním kódem nebo integrací WooCommerce mohou být rizikové. Konflikt zásuvných modulů po automatické aktualizaci jádra může ochromit celý obchod.

Doporučení: Zachovejte automatické aktualizace pro menší verze jádra, ale nastavte aktualizace zásuvných modulů na ruční a ovládejte je prostřednictvím knihy běhů. V souboru wp-config.php: define('WP_AUTO_UPDATE_CORE', 'minor');

Chyba 2: Žádný plán vrácení

Podle odborníků z oboru mnoho týmů vytváří zálohy, ale nikdy netestuje proces obnovy. Záloha, jejíž obnova nebyla nikdy otestována, nepředstavuje záchrannou síť. Je to naděje.

V příručce je uvedeno: alespoň jednou za čtvrtletí provést test obnovy v prostředí staging. Doba trvání opatření. Zdokumentujte výsledek. Tým tak ví, zda obnovení trvá 15 minut nebo 4 hodiny.

Chyba 3: Písemné neupravení povinností

Ve smlouvách o údržbě mezi agenturami a zákazníky se často uvádí: “Pravidelné aktualizace jsou zahrnuty v rozsahu služeb.” Co znamená “pravidelně”, kdo testuje a kdo je k dispozici v noci v případě problémů, zůstává nejasné. Právě tuto jasnost poskytuje runbook s maticí rolí, který by měl být součástí každé smlouvy o údržbě jako její příloha.

"Automatické aktualizace zní dobře, dokud konflikt zásuvných modulů ve dvě hodiny v noci nevypne obchod a nikdo neví, co se změnilo."

Martin Přibyl CEO .hyperdigital CZ | TYPO3 Developer

"Jeden test obnovy za čtvrtletí zní jako spousta práce. Ale stojí to dvě hodiny, ne dva dny jako skutečná pohotovost."

Alex Fernandez Design a řízení projektů

Okna údržby a četnost oprav: co je reálné

Otázka, jak často záplatovat, závisí na rizikovém profilu. Pro většinu středně velkých projektů CMS se doporučuje následující kadence:

Týdenní: Kontrola nových aktualizací zabezpečení. Kritické záplaty nainstalujte do 48 hodin.

Měsíčně: Pravidelné okno údržby pro všechny zbývající aktualizace (opravy chyb, drobné verze). Pro WordPress se to přirozeně shoduje s neoficiálním “záplatovacím úterým”, kdy Microsoft a mnoho dalších poskytovatelů vydává své aktualizace.

Čtvrtletně: Kontrola runbooku, test obnovy, kontrola kompatibility verzí PHP a databáze, vyhodnocení nadcházejících významných aktualizací.

U projektů TYPO3 je cyklus oprav určen cykly LTS. Současná verze LTS 13.4 (opravná verze: 13.4.26, únor 2026) získává pravidelnou podporu do konce roku 2027, komerční ELTS do roku 2031. Opravné verze v rámci řady LTS obsahují pouze opravy chyb a bezpečnostní záplaty a obecně nejsou kritické pro nasazení. Další generace, TYPO3 14 LTS, bude k dispozici od 21. dubna 2026.

Menší verze pro projekty WordPress se objevují nepravidelně, ale obvykle jednou za čtyři až šest týdnů. Aktualizace zásuvných modulů se mohou objevovat denně. Týdenní testování je zde obzvláště důležité, protože prostředí zásuvných modulů představuje největší plochu pro útoky.

Často kladené dotazy - Často kladené dotazy týkající se sady runbook pro správu záplat

Co je to runbook správy záplat?

Příručka pro správu záplat je provozní příručka, která popisuje celý proces cíleného odstraňování známých bezpečnostních nedostatků v instalacích CMS.

Definuje role, procesy, testovací kroky a strategie pro zpětný návrat. Na rozdíl od jednoduchého kontrolního seznamu jsou v runbooku objasněny také odpovědnosti a eskalační cesty.

Jak často by se měly instalovat aktualizace systému CMS?

Aktualizace zabezpečení by měly být nainstalovány do 48 hodin od vydání.

Pravidelné opravy chyb a drobné aktualizace jsou nasazovány každý měsíc v definovaném okně údržby.

Větší upgrady (např. TYPO3 12 až 13) vyžadují samostatné plánování projektu s dobou přípravy několika týdnů.

Potřebuji pro WordPress stagingový systém?

Pro každý projekt WordPress s více než hrstkou pluginů, vlastním kódem nebo funkcemi elektronického obchodu je nezbytné stagingové prostředí.

Automatické aktualizace jádra bez staging jsou odůvodnitelné pouze u velmi jednoduchých webových stránek se standardní konfigurací.

Kolik stojí proces chybějící záplaty?

Podle zprávy IBM Cost of a Data Breach Report 2025 činí průměrné náklady na narušení bezpečnosti dat celosvětově 4,44 milionu USD.

Pro malé a střední podniky jsou náklady výrazně nižší, ale několikadenní výpadek kritických webových stránek s následnou forenzní analýzou a komunikací může rychle dosáhnout pětimístných částek.

Jak funguje vrácení zpět ve WordPressu?

Zpětné obnovení WordPressu spočívá v obnovení výpisu databáze a adresáře wp-content ze zálohy. Pomocí WP-CLI lze databázi obnovit prostřednictvím adresy wp db import backup.sql.

Souborový systém je obnoven prostřednictvím poskytovatele hostingu nebo zálohovacího modulu.

Jak funguje vrácení TYPO3?

U instalací TYPO3 založených na nástroji Composer se předchozí zámek composer.lock obnoví pomocí adresy composer install.

Tím se nasadí přesné verze balíčků, které byly aktivní před aktualizací. Kromě toho se obnoví výpis databáze a vymaže mezipaměť.

Kdo je zodpovědný za správu záplat?

Odpovědnost nese vlastník náplasti. V mnoha středně velkých sestavách je to interní vedoucí digitální oddělení nebo podpůrná agentura v rámci smlouvy o údržbě.

Zásadní je, aby tato úloha byla písemně definována a zakotvena ve smlouvě o údržbě.

Další kroky

Nastavení knihy úloh

Použijte šestikrokový kontrolní seznam z tohoto článku jako šablonu, aby bezpečnostní mezery nezůstaly otevřené celé týdny.

Přizpůsobte si role, okna údržby a kategorie oprav podle svého nastavení. Ukotvěte knihu běhů jako přílohu ve smlouvě o údržbě.

Nastavení stagingového prostředí

Pokud ještě není k dispozici: Nastavte staging, který co nejpřesněji odráží produkční prostředí. Stejná verze PHP, stejná konfigurace CMS, stejný zásuvný modul nebo rozšíření.

Provedení prvního cyklu opravy

Kontrola otevřených aktualizací jádra, pluginů/rozšíření a témat
Proveďte kategorizaci (kritické, důležité, nepovinné).
Nasazení záplaty do staging a provedení testu QA
Výsledek dokumentu

Naplánujte test obnovení

Během následujících 30 dnů proveďte kompletní test obnovení ve stagingovém prostředí. Změřte a zdokumentujte dobu trvání. To je základ pro realistické plánování obnovení.

Potřebuje váš projekt CMS strukturovaný proces oprav?

Vytváříme smlouvy o údržbě s jasnými seznamy běhů, definovanými smlouvami SLA a zárukou zpětného vrácení.