# Udržiavanie závislostí aktuálnych: Composer, npm a pluginy

> Udržiavajte balíky Composer, moduly npm a pluginy CMS aktuálne: proces údržby s rytmom, zodpovednosťou, testami a plánom pre prípady bez záplaty.

Zdroj: https://phpsos.de/sk/blog/abhaengigkeiten-aktuell-halten/  
Stav: 25.10.2026  
Poskytovateľ: PHP SOS, Núdzová pomoc pri PHP a bezpečnosť serverov. Okamžitá pomoc cez WhatsApp: https://wa.me/491736494914?text=Dobr%C3%BD%20de%C5%88%2C%20PHP%20SOS%2C%20potrebujeme%20pomoc%20s%20na%C5%A1%C3%ADm%20serverom%20s%20PHP.%20Spolo%C4%8Dnos%C5%A5%3A%20%E2%80%A6%20Web%3A%20%E2%80%A6

**Stručne:** Kto chce aktualizovať závislosti, potrebuje proces pre tri svety balíkov: balíky Composer v kóde PHP, moduly npm v builde frontendu a pluginy alebo témy v CMS. K tomu patrí pevný rytmus, zodpovedná osoba, testy pred nasadením a plán pre balíky bez aktualizácie. Proti PHP2Shell to nepomôže, pretože táto zraniteľnosť sedí v samotnom PHP, ale pomôže to proti mnohým zraniteľnostiam v cudzom kóde.

## Tri svety balíkov, jedno slepé miesto

V týždni po 21. 10. 2026 sa všetko točilo okolo interpretera PHP. Mnohé tímy si pritom uvedomili, že presne nepoznajú verzie svojich vlastných stavebných kameňov. Web beží, stará sa o to agentúra, plugin sa ozve, keď je niečo nové: tak či podobne znejú predpoklady, kým sa niekto nepozrie.

Typický projekt PHP dnes pozostáva z výrazne väčšieho podielu cudzieho než vlastného kódu. OWASP Top 10 vedie zraniteľné a zastarané komponenty ako samostatnú kategóriu rizika. Problémom je zriedka chýbajúci nástroj, ale chýbajúca rutina: aktualizácie sa robia, keď má niekto čas, a bezpečnostné hlásenia končia v schránke, ktorú nikto nečíta.

## Ktoré závislosti aktualizujete kde?

Každý svet balíkov má vlastné nástroje a vlastné nástrahy. Nasledujúci prehľad pomáha nič neprehliadnuť.

| Svet balíkov | Zobraziť stav | Skontrolovať zraniteľnosti | Typická nástraha |
|---|---|---|---|
| Composer (knižnice PHP) | `composer show` | `composer audit` | nepriame balíky, ktoré nikto nepozná |
| npm (build frontendu) | `npm ls` | `npm audit` | aktualizácia bez nového buildu sa na server nikdy nedostane |
| Pluginy a témy CMS | admin rozhranie alebo CLI | upozornenia výrobcu, bezpečnostné služby | opustené pluginy, platené pluginy bez kanála aktualizácií |
| PHP a rozšírenia | správa balíkov | security tracker distribúcie | zobrazená verzia hovorí málo o backportoch |

Posledný riadok prísne vzaté nepatrí k závislostiam aplikácie, no často sa naň zabúda v tom istom okamihu. To isté platí pre skripty, ktoré sa vkladajú priamo z cudzích serverov, napríklad knižnice z CDN, chatové widgety alebo sledovací kód. Neobjavia sa v žiadnom súbore lock, ale bežia v prehliadači vašich návštevníkov. Zaraďte ich do zoznamu a skontrolujte, či sú vložené pevné verzie namiesto „vždy najnovšej“. Podrobnosti o `composer audit`, súbore lock a zapojení do buildu sú v sprievodcovi [Kontrola závislostí Composer na zraniteľnosti](https://phpsos.de/sk/ratgeber/composer-abhaengigkeiten-pruefen/). Ako Composer zásadne funguje, vysvetľuje [Composer: správca balíkov pre PHP](https://phpsos.de/sk/php/composer/).

## Cyklus údržby v šiestich krokoch

Udržateľný proces nemusí byť komplikovaný. Osvedčilo sa toto poradie:

1. **Zachytiť stav:** pre každý projekt zoznam priamych závislostí s verziou, pôvodom a účelom. Súbory lock (`composer.lock`, `package-lock.json`) patria do repozitára.
2. **Zbierať hlásenia:** kontrolné nástroje bežia pri každom builde a navyše pravidelne nad doručovaným stavom, aj bez zmeny kódu.
3. **Vyhodnotiť:** používa sa dotknutý balík v produkčnej prevádzke, je dotknutá funkcia dostupná, existuje opravená verzia?
4. **Aktualizovať v stagingu a testovať:** najprv bezpečnostné aktualizácie v rámci tej istej hlavnej verzie, skoky na nové hlavné verzie plánovať ako samostatný zámer.
5. **Nasadiť s cestou späť:** predchádzajúci stav zostáva k dispozícii ako balík alebo vydanie, záloha databázy pred aktualizáciou.
6. **Zdokumentovať:** čo sa kedy aktualizovalo, čo vedome nie a prečo.

Dávajte pritom pozor na údaje o verziách v `composer.json` a `package.json`. Príliš úzke požiadavky bránia tomu, aby sa bezpečnostné opravy vôbec dali nainštalovať. Príliš široké naopak vťahujú do projektu nepreskúmané nové hlavné verzie. Osvedčilo sa povoliť aktualizácie v rámci hlavnej verzie a skok na ďalšiu plánovať vedome.

Pri pluginoch v CMS sa dostupné aktualizácie často dajú zobraziť aj na príkazovom riadku, pri WordPresse napríklad pomocou WP-CLI:

```bash
# Zobraziť dostupné aktualizácie bez akejkoľvek zmeny
wp plugin list --update=available
wp theme list --update=available
# Balíky frontendu: zastarané verzie a známe zraniteľnosti
npm outdated
npm audit --omit=dev
```

> **Dôležité:**
> Automatické aktualizácie pluginov priamo na produkčnom systéme sú pohodlné, ale riskantné, ak potom nikto nekontroluje. Zapnite ich len vtedy, ak je zabezpečená záloha pred každým behom a kontrola po ňom.

## Keď aktualizácia neexistuje

Nie každé hlásenie sa dá vyriešiť kliknutím. OWASP Cheat Sheet o zaobchádzaní so zraniteľnými závislosťami rozlišuje viacero prípadov, ktoré sa dajú dobre preniesť do každodennej praxe:

- **Záplata je k dispozícii:** nasadiť v stagingu, otestovať, nasadiť ostro. Ak sa niečo pokazí, upraviť vlastný kód namiesto toho, aby aktualizácia ležala ladom.
- **Záplata je ohlásená, ale ešte nie je:** zaviesť workaround výrobcu, dotknutú funkciu podľa možnosti vypnúť alebo odtieniť, rozhodnutie zaznamenať.
- **Záplata sa neočakáva:** hľadať náhradný balík alebo opravu spätne portovať sám, s testom, ktorý rozlíši zraniteľnosť pred záplatou a po nej.

Pri pluginoch CMS sa často vyskytuje štvrtý prípad: plugin je opustený. Vtedy pomôže len náhrada alebo odstránenie. To isté platí pre pluginy z nejasných zdrojov, napríklad „bezplatné“ kópie platených pluginov. Nedostávajú aktualizácie cez oficiálny kanál a nie zriedka obsahujú samy škodlivý kód. Pokyny pre prevádzkovateľov WordPressu zhŕňa [WordPress a PHP2Shell](https://phpsos.de/sk/plattformen/wordpress/).

## Vyjasniť zodpovednosť skôr, než príde ďalšie hlásenie

Najčastejším dôvodom zastaraných balíkov nie je technická prekážka, ale otvorená otázka: kto to urobí? Pri projektoch, ktoré postavila agentúra a prevádzkujú sa interne, sa často necíti zodpovedný nikto. Určte pre každý projekt, kto dostáva hlásenia, kto vyhodnocuje a kto schvaľuje, a zapíšte to.

Naplánujte navyše čas. Pevný termín údržby v mesiaci, v ktorom sa závislosti kontrolujú a aktualizujú, zabráni tomu, aby sa aktualizácie hromadili roky. Čím dlhšie sa projekt neaktualizoval, tým väčší a riskantnejší je ďalší skok. Ako sa aktualizácie PHP a balíkov zapájajú do nadradeného postupu, opisuje [Správa záplat ako proces namiesto hasenia požiarov](https://phpsos.de/sk/blog/patch-management-prozess/).

## Ako konkrétne pomáha PHP SOS?

- Zachytíme všetky závislosti vašich projektov z Composeru, npm a CMS a označíme zastarané, zraniteľné a opustené balíky.
- Zavedieme automatické kontroly a určíme, kto ktoré hlásenie vyhodnocuje.
- Aktualizujeme v stagingu, otestujeme najdôležitejšie postupy a nasadzujeme s cestou späť.
- V rámci [zmluvy o bezpečnostnej údržbe](https://phpsos.de/sk/leistungen/security-wartungsvertrag/) preberáme mesačný cyklus trvalo, vrátane aktualizácií PHP.

**Záver:** Aktuálne závislosti nie sú projekt, ale rutina. Kto raz čisto upraví stav, rytmus a zodpovednosť, pri ďalšom veľkom hlásení musí už len kontrolovať, nie najprv hľadať.


## Časté otázky

**Ako často by sa mali závislosti aktualizovať?**  
Bezpečnostné aktualizácie čo najskôr po vyhodnotení, rutinné aktualizácie v pevnom rytme, napríklad mesačne. Dôležitejšie než presná frekvencia je, že termín je určený a niekto je za to zodpovedný.

**Chráni aktuálny plugin pred PHP2Shell?**  
Nie. PHP2Shell sedí v samotnom interpreteri PHP. Proti tomu pomáha len aktualizácia PHP s reštartom všetkých procesov PHP. Aktuálne pluginy a balíky sú napriek tomu dôležité, pretože uzatvárajú vlastné zraniteľnosti.

**Čo robiť s pluginom, ktorý sa už neudržiava?**  
Nahradiť alebo odstrániť. Opustený plugin už nedostáva opravy, aj keď dnes ešte funguje. Do nahradenia by ste mali skontrolovať, či sa funkcia naozaj potrebuje, a rozhodnutie zdokumentovať.

**Musí sa frontend s npm aktualizovať aj na serveri?**  
Balíky npm často ležia len v builde a na server sa dostanú ako hotové súbory. Zraniteľnosť v balíku môže napriek tomu sedieť v doručovanom JavaScripte. Po aktualizácii sa preto musí znova zostaviť a znova doručiť.

## 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/)