Trumpai: kas nori atnaujinti priklausomybes, reikia proceso trims paketų pasauliams: Composer paketams PHP kode, npm moduliams frontend kūrime ir papildiniams ar temoms CMS. Prie to priklauso fiksuotas ritmas, atsakingas asmuo, bandymai prieš paskleidimą ir planas paketams be atnaujinimo. Nuo PHP2Shell tai nepadeda, nes ši spraga slypi pačiame PHP, bet padeda nuo daugelio svetimo kodo spragų.
Trys paketų pasauliai, viena akloji dėmė
Savaitę po 2026-10-21 viskas sukosi apie PHP interpretatorių. Daugelis komandų tuo metu suprato, kad tiksliai nežino savo pačių komponentų versijų. Svetainė veikia, agentūra rūpinasi, papildinys pats praneša, kai yra kas nors naujo: tokios ar panašios prielaidos, kol kas nors nepažiūri.
Tipinį PHP projektą šiandien sudaro gerokai daugiau svetimo nei savo kodo. OWASP Top 10 pažeidžiamus ir pasenusius komponentus išskiria kaip atskirą rizikos kategoriją. Problema retai yra trūkstamas įrankis, o trūkstama rutina: atnaujinimai vyksta, kai kas nors turi laiko, o saugumo pranešimai patenka į pašto dėžutę, kurios niekas neskaito.
Kurias priklausomybes kur atnaujinate?
Kiekvienas paketų pasaulis turi savų įrankių ir savų spąstų. Toliau pateikta apžvalga padeda nieko nepraleisti.
| Paketų pasaulis | Parodyti inventorių | Tikrinti spragas | Tipiniai spąstai |
|---|---|---|---|
| Composer (PHP bibliotekos) | composer show |
composer audit |
netiesioginiai paketai, kurių niekas nežino |
| npm (frontend kūrimas) | npm ls |
npm audit |
atnaujinimas be perkūrimo serverio niekada nepasiekia |
| CMS papildiniai ir temos | administravimo sąsaja arba CLI | gamintojo nurodymai, saugumo paslaugos | apleisti papildiniai, pirkti papildiniai be atnaujinimo kanalo |
| PHP ir plėtiniai | paketų valdymas | distribucijos saugumo sekiklis (tracker) | rodoma versija mažai pasako apie atgalinius perkėlimus (backport) |
Paskutinė eilutė, griežtai kalbant, nepriklauso programos priklausomybėms, bet dažnai pamirštama tuo pačiu atodūsiu. Tas pats galioja scenarijams, įtraukiamiems tiesiai iš svetimų serverių, pavyzdžiui, bibliotekoms iš CDN, pokalbių valdikliams (widget) ar sekimo kodui. Jie neatsiranda jokiame lock faile, bet veikia jūsų lankytojų naršyklėje. Įtraukite juos į sąrašą ir patikrinkite, ar įtrauktos fiksuotos versijos, o ne „visada naujausia“. Detalės apie composer audit, lock failą ir įtraukimą į kūrimą pateiktos vadove Composer priklausomybių spragų patikra. Kaip Composer iš esmės veikia, aiškina Composer: PHP paketų valdymas.
Priežiūros ciklas šešiais žingsniais
Tvirtas procesas neturi būti sudėtingas. Ši eiga pasiteisino:
- Užfiksuoti inventorių: kiekvienam projektui tiesioginių priklausomybių sąrašas su versija, kilme ir paskirtimi. Lock failai (
composer.lock,package-lock.json) priklauso saugyklai. - Rinkti pranešimus: tikrinimo įrankiai veikia kiekvieno kūrimo metu ir papildomai reguliariai pateiktoje būsenoje, net be kodo pakeitimų.
- Įvertinti: ar paveiktas paketas naudojamas gamyboje, ar paveikta funkcija pasiekiama, ar yra ištaisyta versija?
- Atnaujinti parengiamojoje aplinkoje (staging) ir išbandyti: pirmiausia saugumo atnaujinimai toje pačioje pagrindinėje versijoje, šuolius į naujas pagrindines versijas planuoti kaip atskirą projektą.
- Paskleisti su kelio atgal galimybe: ankstesnė būsena lieka kaip paketas ar leidimas, prieš atnaujinimą duomenų bazės atsarginė kopija.
- Dokumentuoti: kas ir kada atnaujinta, kas sąmoningai ne ir kodėl.
Atkreipkite dėmesį į versijų nurodymus composer.json ir package.json. Per siauri reikalavimai neleidžia net įdiegti saugumo pataisų. Per platūs reikalavimai į projektą netikrinta atneša naujas pagrindines versijas. Pasiteisino leisti atnaujinimus pagrindinės versijos viduje, o šuolį į kitą sąmoningai planuoti.
CMS papildinių galimus atnaujinimus dažnai galima parodyti ir komandinėje eilutėje, WordPress pavyzdžiui, su WP-CLI:
# Parodyti galimus atnaujinimus nieko nekeičiant
wp plugin list --update=available
wp theme list --update=available
# Frontend paketai: pasenusios versijos ir žinomos spragos
npm outdated
npm audit --omit=dev
Automatiniai papildinių atnaujinimai tiesiai gamybos sistemoje yra patogūs, bet rizikingi, jei po to niekas netikrina. Įjunkite juos tik jei užtikrinta atsarginė kopija prieš kiekvieną paleidimą ir patikra po jo.
Kai atnaujinimo nėra
Ne kiekvieną pranešimą galima išspręsti vienu paspaudimu. OWASP Cheat Sheet apie elgesį su pažeidžiamomis priklausomybėmis skiria kelis atvejus, kuriuos gerai galima perkelti į kasdienybę:
- Yra pataisa: įdiegti parengiamojoje aplinkoje (staging), išbandyti, paskleisti. Jei kas nors sulūžta, pritaikyti savą kodą, o ne palikti atnaujinimą gulėti.
- Pataisa paskelbta, bet dar nėra: įgyvendinti gamintojo laikiną sprendimą (workaround), paveiktą funkciją kuo įmanoma išjungti ar apsaugoti, sprendimą užfiksuoti.
- Pataisos nesitikima: ieškoti pakaitinio paketo arba pačiam atgaline data perkelti ištaisymą, su bandymu, atskiriančiu spragą prieš pataisą ir po jos.
CMS papildiniams dažnai pasitaiko ketvirtas atvejis: papildinys apleistas. Tada padeda tik pakeitimas arba pašalinimas. Tas pats galioja papildiniams iš neaiškių šaltinių, pavyzdžiui, „nemokamoms“ pirktų papildinių kopijoms. Jie negauna atnaujinimų oficialiu kanalu ir nemažai dažnai patys turi kenkėjiško kodo. Nuorodas WordPress operatoriams pateikia WordPress ir PHP2Shell.
Atsakomybę išsiaiškinti prieš kitą pranešimą
Dažniausia pasenusių paketų priežastis nėra techninė kliūtis, o atviras klausimas: kas tai daro? Projektuose, kuriuos sukūrė agentūra, o vidujė eksploatuoja kiti, dažnai niekas nesijaučia atsakingas. Kiekvienam projektui nustatykite, kas gauna pranešimus, kas vertina ir kas patvirtina, ir tai užsirašykite.
Taip pat suplanuokite laiką. Fiksuotas priežiūros terminas kiekvieną mėnesį, kai tikrinamos ir atnaujinamos priklausomybės, neleidžia atnaujinimams kauptis metų metus. Kuo ilgiau projektas neatnaujintas, tuo didesnis ir rizikingesnis kitas šuolis. Kaip PHP ir paketų atnaujinimai įsilieja į bendrą eigą, aprašo Pataisų valdymas kaip procesas, o ne gaisrų gesinimas.
Kaip PHP SOS padeda konkrečiai?
- Surenkame visas jūsų projektų priklausomybes iš Composer, npm ir CMS ir pažymime pasenusius, pažeidžiamus ir apleistus paketus.
- Įrengiame automatines patikras ir nustatome, kas kuriuos pranešimus vertina.
- Atnaujiname parengiamojoje aplinkoje (staging), išbandome svarbiausias eigas ir paskleidžiame su kelio atgal galimybe.
- Saugumo priežiūros sutarties rėmuose mėnesinį ciklą perimame ilgam, įskaitant PHP atnaujinimus.
Išvada: atnaujintos priklausomybės nėra projektas, o rutina. Kas inventorių, ritmą ir atsakomybę sutvarko vieną kartą, kito didelio pranešimo metu turi tik patikrinti, o ne pirmiausia ieškoti.
Dažni klausimai
Kaip dažnai reikėtų atnaujinti priklausomybes?
Saugumo atnaujinimus kuo greičiau po įvertinimo, įprastus atnaujinimus fiksuotu ritmu, pavyzdžiui, kas mėnesį. Svarbiau už tikslų dažnį, kad terminas būtų nustatytas ir kažkas už tai atsakytų.
Ar naujas papildinys saugo nuo PHP2Shell?
Ne. PHP2Shell slypi pačiame PHP interpretatoriuje. Nuo to padeda tik PHP atnaujinimas su visų PHP procesų paleidimu iš naujo. Nauji papildiniai ir paketai vis tiek svarbūs, nes uždaro savas spragas.
Ką daryti su papildiniu, kuris nebeprižiūrimas?
Pakeisti arba pašalinti. Apleistas papildinys nebegauna pataisų, nors šiandien dar veikia. Iki pakeitimo patikrinkite, ar funkcijos tikrai reikia, ir sprendimą dokumentuokite.
Ar frontend su npm turi būti atnaujinamas ir serveryje?
Dažnai npm paketai yra tik kūrimo (build) metu ir patenka į serverį kaip baigti failai. Paketo spraga vis tiek gali slypėti pateikiamame JavaScript. Todėl po atnaujinimo reikia iš naujo sukurti ir iš naujo pateikti.