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. Ako Composer zásadne funguje, vysvetľuje Composer: správca balíkov pre PHP.
Cyklus údržby v šiestich krokoch
Udržateľný proces nemusí byť komplikovaný. Osvedčilo sa toto poradie:
- 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. - 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.
- Vyhodnotiť: používa sa dotknutý balík v produkčnej prevádzke, je dotknutá funkcia dostupná, existuje opravená verzia?
- 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.
- 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.
- 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:
# 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
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.
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.
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 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ť.