Ukratko: Tko želi ažurirati ovisnosti, treba proces za tri svijeta paketa: Composer pakete u PHP kodu, npm module u frontend buildu te dodatke ili teme u CMS-u. Tome pripadaju fiksan ritam, odgovorna osoba, testovi prije isporuke i plan za pakete bez updatea. Protiv PHP2Shella to ne pomaže, jer se ta ranjivost nalazi u samom PHP-u, ali pomaže protiv mnogih ranjivosti u tuđem kodu.
Tri svijeta paketa, jedna slijepa točka
U tjednu nakon 21. 10. 2026. sve se vrtjelo oko PHP interpretera. Mnogi su timovi pritom shvatili da ne znaju točno verzije vlastitih sastavnica. Web-stranica radi, agencija se brine, dodatak se već javi kad ima nešto novo: tako ili slično glase pretpostavke, dok netko ne pogleda.
Tipičan PHP projekt danas se sastoji od znatno više tuđeg nego vlastitog koda. OWASP Top 10 ranjive i zastarjele komponente vode kao zasebnu kategoriju rizika. Problem rijetko nedostaje alat, nego rutina: updatei se događaju kad netko ima vremena, a sigurnosne obavijesti završavaju u poštanskom sandučiću koji nitko ne čita.
Koje ovisnosti ažurirate gdje?
Svaki svijet paketa ima vlastite alate i vlastite zamke. Sljedeći pregled pomaže da se ništa ne previdi.
| Svijet paketa | Prikaz stanja | Provjera ranjivosti | Tipična zamka |
|---|---|---|---|
| Composer (PHP biblioteke) | composer show |
composer audit |
neizravni paketi koje nitko ne poznaje |
| npm (frontend build) | npm ls |
npm audit |
update bez ponovne gradnje nikad ne stiže na poslužitelj |
| CMS dodaci i teme | administratorsko sučelje ili CLI | napomene proizvođača, sigurnosne usluge | napušteni dodaci, plaćeni dodaci bez kanala za update |
| PHP i proširenja | upravljanje paketima | Security Tracker distribucije | prikazana verzija govori malo o backportima |
Posljednji redak strogo uzevši ne pripada ovisnostima aplikacije, ali se često u istom dahu zaboravi. Isto vrijedi za skripte koje se uključuju izravno s tuđih poslužitelja, primjerice biblioteke iz CDN-a, chat widgete ili kod za praćenje. One se ne pojavljuju ni u jednoj lock datoteci, ali rade u pregledniku Vaših posjetitelja. Uvrstite ih na popis i provjerite uključuju li se fiksne verzije umjesto „uvijek najnovije“. Pojedinosti o composer audit, lock datoteci i uključivanju u build stoje u vodiču Provjeriti Composer ovisnosti na ranjivosti. Kako Composer u načelu radi, objašnjava Composer: upravitelj paketa za PHP.
Ciklus održavanja u šest koraka
Nosiv proces ne mora biti složen. Ovaj se redoslijed dokazao:
- Utvrditi stanje: za svaki projekt popis izravnih ovisnosti s verzijom, podrijetlom i svrhom. Lock datoteke (
composer.lock,package-lock.json) pripadaju u repozitorij. - Prikupljati obavijesti: alati za provjeru rade pri svakom buildu i dodatno redovito na isporučenom stanju, i bez promjene koda.
- Ocijeniti: koristi li se pogođeni paket u produkciji, je li pogođena funkcija dostupna, postoji li ispravljena verzija?
- Ažurirati i testirati na stagingu: najprije sigurnosni updatei unutar iste glavne verzije, skokove na nove glavne verzije planirati kao zaseban pothvat.
- Isporučiti s povratnim putem: prethodno stanje ostaje dostupno kao paket ili izdanje, sigurnosna kopija baze podataka prije updatea.
- Dokumentirati: što je kada ažurirano, što svjesno nije i zašto.
Pritom obratite pažnju na navode verzija u composer.json i package.json. Preuski zahtjevi sprječavaju da se sigurnosni ispravci uopće mogu instalirati. Preširoki zahtjevi pak u projekt neprovjereno donose nove glavne verzije. Dokazalo se dopuštati updatee unutar glavne verzije, a skok na sljedeću svjesno planirati.
Za dodatke u CMS-u dostupni updatei često se mogu prikazati i na naredbenoj liniji, kod WordPressa primjerice pomoću WP-CLI-ja:
# Prikazati dostupne updatee bez ikakve promjene
wp plugin list --update=available
wp theme list --update=available
# Frontend paketi: zastarjele verzije i poznate ranjivosti
npm outdated
npm audit --omit=dev
Automatski updatei dodataka izravno na produkcijskom sustavu su udobni, ali rizični ako nitko poslije ne provjerava. Uključite ih samo ako su osigurani backup prije svakog izvođenja i kontrola poslije.
Kad updatea nema
Nije svaka obavijest rješiva jednim klikom. OWASP Cheat Sheet o postupanju s ranjivim ovisnostima razlikuje više slučajeva koji se dobro mogu prenijeti na svakodnevicu:
- Zakrpa dostupna: primijeniti na stagingu, testirati, isporučiti. Ako nešto pukne, prilagoditi vlastiti kod umjesto ostaviti update neprimijenjen.
- Zakrpa najavljena, ali još nije stigla: provesti zaobilazno rješenje proizvođača, pogođenu funkciju po mogućnosti isključiti ili odvojiti, odluku zabilježiti.
- Zakrpa se ne očekuje: potražiti zamjenski paket ili sami vratiti ispravak (backport), uz test koji razlikuje ranjivost prije i poslije zakrpe.
Kod CMS dodataka često se javlja četvrti slučaj: dodatak je napušten. Tada pomaže samo zamjena ili uklanjanje. Isto vrijedi za dodatke iz nejasnih izvora, primjerice „besplatne“ kopije plaćenih dodataka. Oni ne primaju updatee preko službenog kanala i nerijetko sami sadrže zlonamjerni kod. Napomene za operatere WordPressa objedinjuje WordPress i PHP2Shell.
Razjasniti odgovornost prije nego stigne sljedeća obavijest
Najčešći razlog zastarjelih paketa nije tehnička prepreka, nego otvoreno pitanje: tko to radi? Kod projekata koje je izradila agencija, a interno se vode, često se nitko ne osjeća odgovornim. Za svaki projekt utvrdite tko prima obavijesti, tko ocjenjuje i tko odobrava, i zapišite to.
Planirajte i vrijeme. Fiksni termin održavanja jednom mjesečno, kad se ovisnosti provjeravaju i ažuriraju, sprječava da se updatei godinama gomilaju. Što je projekt dulje neažuriran, to je sljedeći skok veći i rizičniji. Kako se updatei PHP-a i paketa uklapaju u cjeloviti tijek, opisuje Upravljanje zakrpama kao proces umjesto gašenja požara.
Kako PHP SOS konkretno pomaže?
- Bilježimo sve ovisnosti Vaših projekata iz Composera, npm-a i CMS-a te označavamo zastarjele, ranjive i napuštene pakete.
- Postavljamo automatske provjere i utvrđujemo tko ocjenjuje koju obavijest.
- Ažuriramo na stagingu, testiramo najvažnije tijekove i isporučujemo s povratnim putem.
- U okviru ugovora o sigurnosnom održavanju trajno preuzimamo mjesečni ciklus, uključujući PHP updatee.
Zaključak: Ažurne ovisnosti nisu projekt, nego rutina. Tko jednom uredno uredi stanje, ritam i odgovornost, pri sljedećoj velikoj obavijesti treba samo provjeriti, a ne tek tražiti.
Česta pitanja
Koliko često treba ažurirati ovisnosti?
Sigurnosne updatee što prije nakon procjene, rutinske updatee u fiksnom ritmu, primjerice mjesečno. Važnije od točne učestalosti je da je termin utvrđen i da je netko za to odgovoran.
Štiti li aktualan dodatak od PHP2Shella?
Ne. PHP2Shell se nalazi u samom PHP interpreteru. Protiv toga pomaže samo PHP update s ponovnim pokretanjem svih PHP procesa. Aktualni dodaci i paketi ipak su važni jer zatvaraju vlastite ranjivosti.
Što učiniti s dodatkom koji se više ne održava?
Zamijeniti ga ili ukloniti. Napušteni dodatak više ne dobiva ispravke, čak i ako danas još radi. Do zamjene provjerite treba li se funkcija doista koristiti i dokumentirajte odluku.
Mora li se frontend s npm-om ažurirati i na poslužitelju?
Često npm paketi postoje samo u buildu i na poslužitelj dolaze kao gotove datoteke. Ranjivost u paketu ipak može biti u isporučenom JavaScriptu. Nakon updatea stoga treba ponovno izgraditi i ponovno isporučiti.