# Udržování závislostí aktuálních: Composer, npm a pluginy

> Udržování balíčků Composer, modulů npm a pluginů CMS aktuálních: proces údržby s rytmem, odpovědností, testy a plánem pro případy bez záplaty.

Zdroj: https://phpsos.de/cs/blog/abhaengigkeiten-aktuell-halten/  
Stav: 25.10.2026  
Poskytovatel: PHP SOS, Nouzová pomoc pro PHP a bezpečnost serverů. Okamžitá pomoc přes WhatsApp: https://wa.me/491736494914?text=Dobr%C3%BD%20den%2C%20PHP%20SOS%2C%20pot%C5%99ebujeme%20pomoc%20s%20na%C5%A1%C3%ADm%20PHP%20serverem.%20Firma%3A%20%E2%80%A6%20Web%3A%20%E2%80%A6

**Stručně:** Kdo chce aktualizovat závislosti, potřebuje proces pro tři světy balíčků: balíčky Composer v kódu PHP, moduly npm v sestavení frontendu a pluginy či šablony v CMS. K tomu patří pevný rytmus, odpovědná osoba, testy před nasazením a plán pro balíčky bez aktualizace. Proti PHP2Shell to nepomůže, protože tato zranitelnost je přímo v PHP, ale pomáhá to proti mnoha zranitelnostem v cizím kódu.

## Tři světy balíčků, jedno slepé místo

V týdnu po 21. 10. 2026 se vše točilo kolem interpretu PHP. Mnoho týmů si přitom uvědomilo, že přesně neznají verze svých vlastních stavebních prvků. Web běží, agentura se stará, plugin se ozve sám, když je něco nového: tak nebo podobně znějí předpoklady, dokud se někdo nepodívá.

Typický projekt v PHP se dnes skládá z výrazně více cizího než vlastního kódu. OWASP Top 10 uvádí zranitelné a zastaralé komponenty jako samostatnou kategorii rizik. Problémem zřídka bývá chybějící nástroj, spíše chybějící rutina: aktualizace se dějí, když má někdo čas, a bezpečnostní hlášení končí ve schránce, kterou nikdo nečte.

## Které závislosti aktualizujete kde?

Každý svět balíčků má vlastní nástroje a vlastní úskalí. Následující přehled pomáhá nic nepřehlédnout.

| Svět balíčků | Zobrazení stavu | Kontrola zranitelností | Typické úskalí |
|---|---|---|---|
| Composer (knihovny PHP) | `composer show` | `composer audit` | nepřímé balíčky, které nikdo nezná |
| npm (sestavení frontendu) | `npm ls` | `npm audit` | aktualizace bez nového sestavení se na server nikdy nedostane |
| Pluginy a šablony CMS | administrační rozhraní nebo CLI | upozornění výrobců, bezpečnostní služby | opuštěné pluginy, placené pluginy bez kanálu aktualizací |
| PHP a rozšíření | správa balíčků | bezpečnostní tracker distribuce | zobrazená verze říká málo o backportech |

Poslední řádek přísně vzato nepatří k závislostem aplikace, ale často se zapomíná ve stejném dechu. Totéž platí pro skripty, které se vkládají přímo z cizích serverů, například knihovny z CDN, chatové widgety nebo kód pro sledování. Nevyskytují se v žádném lock souboru, ale běží v prohlížeči vašich návštěvníků. Zařaďte je do seznamu a ověřte, zda jsou vloženy pevné verze místo „vždy nejnovější“. Podrobnosti o `composer audit`, lock souboru a začlenění do sestavení najdete v příručce [Kontrola zranitelností v závislostech Composeru](https://phpsos.de/cs/ratgeber/composer-abhaengigkeiten-pruefen/). Jak Composer funguje obecně, vysvětluje stránka [Composer: správce balíčků pro PHP](https://phpsos.de/cs/php/composer/).

## Cyklus údržby v šesti krocích

Funkční proces nemusí být složitý. Osvědčilo se toto pořadí:

1. **Zachytit stav:** Pro každý projekt seznam přímých závislostí s verzí, původem a účelem. Lock soubory (`composer.lock`, `package-lock.json`) patří do repozitáře.
2. **Sbírat hlášení:** Kontrolní nástroje běží při každém sestavení a navíc pravidelně na doručovaném stavu, i bez změny kódu.
3. **Posoudit:** Používá se dotčený balíček v produkčním provozu, je dotčená funkce dosažitelná, existuje opravená verze?
4. **Aktualizovat a testovat ve stagingu:** Nejdřív bezpečnostní aktualizace v rámci stejné hlavní verze, skoky na nové hlavní verze plánovat jako samostatný záměr.
5. **Nasadit se zpětnou cestou:** Předchozí stav zůstává k dispozici jako balíček nebo vydání, záloha databáze před aktualizací.
6. **Zdokumentovat:** Co bylo kdy aktualizováno, co vědomě ne a proč.

Dávejte přitom pozor na údaje o verzích v `composer.json` a `package.json`. Příliš úzká omezení brání tomu, aby se bezpečnostní opravy vůbec daly nainstalovat. Příliš široká naopak přinášejí do projektu nezkontrolované nové hlavní verze. Osvědčilo se povolit aktualizace v rámci hlavní verze a skok na další plánovat vědomě.

U pluginů v CMS lze dostupné aktualizace často zobrazit i na příkazové řádce, u WordPressu například pomocí WP-CLI:

```bash
# Zobrazit dostupné aktualizace, aniž by se cokoli měnilo
wp plugin list --update=available
wp theme list --update=available
# Balíčky frontendu: zastaralé verze a známé zranitelnosti
npm outdated
npm audit --omit=dev
```

> **Důležité:**
> Automatické aktualizace pluginů přímo na produkčním systému jsou pohodlné, ale riskantní, pokud potom nikdo nekontroluje. Zapněte je jen tehdy, pokud je zajištěna záloha před každým během a kontrola po něm.

## Když neexistuje aktualizace

Ne každé hlášení se vyřeší jedním kliknutím. OWASP Cheat Sheet k zacházení se zranitelnými závislostmi rozlišuje několik případů, které se dobře přenášejí do každodenní praxe:

- **Záplata k dispozici:** nasadit ve stagingu, otestovat, nasadit. Pokud se něco rozbije, upravit vlastní kód, místo aby aktualizace zůstala ležet.
- **Záplata oznámena, ale ještě není:** provést obejití výrobce, dotčenou funkci pokud možno vypnout nebo odstínit, rozhodnutí zaznamenat.
- **Záplata se nečeká:** najít náhradní balíček nebo opravu zpětně portovat sám, s testem, který zranitelnost před záplatou a po ní rozliší.

U pluginů CMS se často vyskytuje čtvrtý případ: plugin je opuštěný. Pak pomůže jen náhrada nebo odstranění. Totéž platí pro pluginy z nejasných zdrojů, například „bezplatné“ kopie placených pluginů. Nedostávají aktualizace oficiálním kanálem a nezřídka samy obsahují škodlivý kód. Poznámky pro provozovatele WordPressu shrnuje stránka [WordPress a PHP2Shell](https://phpsos.de/cs/plattformen/wordpress/).

## Vyjasněte odpovědnost dříve, než přijde další hlášení

Nejčastějším důvodem zastaralých balíčků není technická překážka, ale otevřená otázka: kdo to udělá? U projektů, které postavila agentura a které se provozují interně, se často nikdo necítí odpovědný. Pro každý projekt stanovte, kdo dostává hlášení, kdo posuzuje a kdo schvaluje, a napište to.

Naplánujte také čas. Pevný termín údržby jednou měsíčně, kdy se závislosti kontrolují a aktualizují, brání tomu, aby se aktualizace hromadily po léta. Čím déle projekt nebyl aktualizován, tím větší a riskantnější je další skok. Jak se aktualizace PHP a balíčků začleňují do celkového postupu, popisuje článek [Správa záplat jako proces, ne hašení požárů](https://phpsos.de/cs/blog/patch-management-prozess/).

## Jak konkrétně pomáhá PHP SOS?

- Zaznamenáme všechny závislosti vašich projektů z Composeru, npm a CMS a označíme zastaralé, zranitelné a opuštěné balíčky.
- Nastavíme automatické kontroly a stanovíme, kdo které hlášení posuzuje.
- Aktualizujeme ve stagingu, otestujeme nejdůležitější postupy a nasadíme se zpětnou cestou.
- V rámci [smlouvy o bezpečnostní údržbě](https://phpsos.de/cs/leistungen/security-wartungsvertrag/) převezmeme měsíční cyklus trvale, včetně aktualizací PHP.

**Závěr:** Aktuální závislosti nejsou projekt, ale rutina. Kdo jednou čistě upraví stav, rytmus a odpovědnost, musí při příštím velkém hlášení už jen kontrolovat, ne nejprve hledat.


## Časté dotazy

**Jak často by se měly závislosti aktualizovat?**  
Bezpečnostní aktualizace co nejdříve po posouzení, rutinní aktualizace v pevném rytmu, například měsíčně. Důležitější než přesná frekvence je, aby byl termín stanoven a někdo za něj odpovídal.

**Chrání aktuální plugin před PHP2Shell?**  
Ne. PHP2Shell je přímo v interpretu PHP. Pomáhá jen aktualizace PHP s restartem všech procesů PHP. Aktuální pluginy a balíčky jsou přesto důležité, protože uzavírají vlastní zranitelnosti.

**Co dělat s pluginem, který už není udržován?**  
Nahradit nebo odstranit. Opuštěný plugin už opravy nedostává, i když dnes ještě funguje. Do nahrazení byste měli ověřit, zda je funkce skutečně potřeba, a rozhodnutí zdokumentovat.

**Musí se frontend s npm aktualizovat i na serveru?**  
Balíčky npm často leží jen v sestavení a na server se dostanou jako hotové soubory. Zranitelnost v balíčku může přesto být v doručovaném JavaScriptu. Po aktualizaci je proto nutné znovu sestavit a znovu doručit.

## Zdroje

- [OWASP: Vulnerable Dependency Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerable_Dependency_Management_Cheat_Sheet.html)
- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
- [Composer](https://getcomposer.org/)
- [WordPress](https://wordpress.org/)