În episodul anterior am povestit despre cele două vulnerabilități critice descoperite în PHP și despre motivul pentru care am preferat să-mi opresc câteva ore întregul server web decât să-l las expus cât timp făceam actualizările necesare.
Între timp, lucrurile au început să devină interesante dintr-un alt motiv. Unele site-uri și servicii au revenit repede. Altele au rămas închise, iar în anumite cazuri revenirea lor nu mai este o chestiune de câteva ore.
Și aici începe, de fapt, partea mai importantă a poveștii.
Când auzi că a apărut o vulnerabilitate și că producătorul a publicat o actualizare, instinctiv îți imaginezi ceva asemănător cu telefonul mobil: apare mesajul „Update available”, apeși un buton, aștepți câteva minute, dispozitivul repornește și viața continuă.
În cazul sistemelor informatice vechi, lucrurile pot arăta cu totul altfel.
PHP a publicat versiunile corectate pentru ramurile aflate încă în suport. Dacă ai un serviciu construit și întreținut corect, care rulează deja pe PHP 8.2, 8.3, 8.4 sau 8.5, actualizarea către versiunea corectată din aceeași ramură este, în principiu, o intervenție relativ banală. Instalezi pachetele noi, repornești serviciile, faci testele necesare și, dacă totul este în regulă, continui să funcționezi.
Exact asta ar trebui să însemne administrarea normală a unei infrastructuri informatice.
Problema începe atunci când descoperi că aplicația ta nu rulează pe o versiune recentă de PHP. Poate rulează pe 8.0, pe 7.4 sau chiar pe ceva și mai vechi, pentru că „mergea și așa”, iar ani de zile nimeni nu a considerat necesar să plătească pentru aducerea ei la zi.
În acel moment nu mai ai de făcut un update. Ai de recuperat ani.
Să ne întoarcem puțin la hotel
În primul articol am comparat serverul cu un hotel. Site-ul era recepția, aplicațiile erau angajații și sistemele interne, iar serverul era clădirea în care funcționau toate acestea.
Să continuăm aceeași comparație.
Să presupunem că autoritățile descoperă o problemă gravă la un anumit model de tablou electric folosit în hoteluri. Există riscul unui incendiu, iar producătorul spune: „Schimbați imediat componenta X cu versiunea nouă.”
Un hotel întreținut normal cheamă electricianul. Instalația a fost modernizată periodic, documentația există, circuitele sunt cunoscute, tabloul este relativ recent. Electricianul oprește curentul, schimbă piesa, verifică instalația și după câteva ore hotelul funcționează din nou.
Acum imaginați-vă un alt hotel în care instalația electrică nu a mai fost modernizată de cincisprezece ani. Între timp s-au mai tras fire pe unde s-a putut, s-au adăugat aparate de aer condiționat, două etaje au fost renovate, liftul depinde de o automatizare veche, sistemul de acces în camere comunică printr-un echipament care nu se mai fabrică, iar nimeni nu mai știe exact de ce un cablu din tablou intră într-un perete și reapare trei etaje mai sus.
Vine electricianul și spune că trebuie înlocuit tabloul. Doar că noul tablou nu mai lucrează cu jumătate dintre improvizațiile existente. Dintr-o dată, ceea ce trebuia să fie o intervenție de două ore devine renovare.
Cam asta se întâmplă acum în unele aplicații PHP.
„De ce nu puneți pur și simplu PHP-ul nou?”
Pentru că PHP este limbajul în care rulează aplicația, nu aplicația însăși.
O aplicație poate conține sute de mii sau milioane de linii de cod. Poate folosi biblioteci scrise de alții, framework-uri, module, extensii, sisteme de autentificare, conexiuni la baze de date și componente dezvoltate în perioade diferite.
Între timp, PHP evoluează. Unele funcții sunt retrase, altele își schimbă comportamentul, anumite practici sunt declarate depășite, iar în versiunile următoare pot fi eliminate complet. Se schimbă regulile limbajului, apar verificări mai stricte și dispar mecanisme păstrate ani întregi doar pentru compatibilitate.
Asta nu este o problemă specifică PHP și nici un defect al limbajului. Este normal în software. Windows evoluează, Android evoluează, browserele evoluează, bazele de date evoluează, protocoalele de securitate evoluează.
Anormal este să construiești o aplicație și să pretinzi că ea poate rămâne neschimbată zece sau cincisprezece ani, în timp ce toate lucrurile de sub ea continuă să evolueze.
Problema nu este PHP 8. Problema sunt anii săriți
Merită făcută aici o precizare, tocmai pentru a nu transforma discuția într-o acuzație nedreaptă la adresa PHP.
Nu PHP 8.2 sau 8.3 „strică” automat aplicațiile vechi. Necazul apare atunci când sari mai multe generații dintr-o dată.
PHP 7.4 a ieșit din suport oficial în 2022. PHP 8.0 a urmat în 2023, iar PHP 8.1 la sfârșitul lui 2025. În 2026, ramurile susținute oficial sunt 8.2, 8.3, 8.4 și 8.5.
Dacă astăzi descoperi că o aplicație esențială depinde încă de PHP 7.4, problema nu a apărut săptămâna aceasta. Săptămâna aceasta doar ai aflat că nu o mai poți ignora.
Dacă o aplicație ar fi fost mutată treptat de la o versiune la alta, problemele de compatibilitate ar fi fost rezolvate pe rând, în perioade liniștite, cu timp pentru teste și cu posibilitatea revenirii la versiunea precedentă în caz că ceva nu funcționa.
Când sari însă câțiva ani într-o singură noapte, toate modificările acumulate în perioada respectivă ajung pe masă în același timp.
Și ce faci când aplicația nu pornește?
Începi să repari.
Descoperi funcții care nu mai există, biblioteci care nu mai sunt compatibile și framework-uri atât de vechi încât nici ele nu mai pot fi actualizate direct la ultima versiune. Înlocuiești o bibliotecă și constați că noua versiune are altă interfață. Modifici codul care o folosește, apoi afli că o altă componentă depinde de comportamentul vechi.
Uneori trebuie refăcută conexiunea la baza de date. Alteori sistemul de autentificare. Alteori module dezvoltate special pentru instituția respectivă. Mai apar extensii PHP care nu mai există, servere care trebuie reconfigurate sau dependințe instalate cândva manual și despre care nu mai știe nimeni exact de ce sunt acolo.
Dacă vorbim despre o aplicație întreținută decent, aceste probleme sunt gestionabile.
Dacă vorbim însă despre un sistem construit cu zece sau cincisprezece ani în urmă, modificat succesiv de mai multe firme, fără teste automate, cu documentație incompletă și fără oamenii care l-au scris inițial, ceea ce administrativ se numește „update” poate deveni tehnic un proiect de modernizare în toată regula.
Uneori ajungi chiar în punctul în care este mai ieftin și mai sănătos să rescrii anumite componente decât să continui să repari o construcție dependentă de un ecosistem dispărut.
De ce unele instituții și-au închis serviciile
În urma vulnerabilităților din această săptămână, au existat instituții care au ales să scoată temporar din funcțiune anumite site-uri și aplicații până la efectuarea verificărilor și implementarea măsurilor necesare.
Universitatea Babeș-Bolyai, de exemplu, a anunțat indisponibilitatea temporară a unor site-uri, aplicații și servicii web în perioada 22–26 octombrie, pentru verificări și măsuri legate de vulnerabilitățile PHP.
Este important să nu interpretăm greșit această decizie. Oprirea unui serviciu despre care nu ești sigur că poate fi exploatat în siguranță este, în sine, o măsură responsabilă. Dacă ai de ales între indisponibilitate și posibilitatea compromiterii unui sistem, alegerea corectă este de multe ori indisponibilitatea.
Problema cea mai mare nu este că serviciul a fost oprit, ci cât de greu poate fi repornit în siguranță.
Dacă răspunsul este „câteva ore”, probabil discutăm despre o infrastructură menținută relativ aproape de actualitate.
Dacă răspunsul devine „nu știm exact, trebuie mai întâi să modificăm aplicația”, atunci vulnerabilitatea a scos la lumină altceva: ani de mentenanță amânată.
Datoria tehnică nu se vede la inaugurare
Aici ajungem, de fapt, la problema digitalizării.
Este relativ ușor să finanțezi construirea unei platforme. Ai un proiect, un buget, niște termene, niște funcționalități care trebuie livrate și, la final, ceva care poate fi prezentat public.
Mentenanța este mult mai puțin spectaculoasă.
Nu tai nicio panglică pentru faptul că un programator a înlocuit o bibliotecă veche înainte să devină vulnerabilă. Nu faci conferință de presă pentru că ai migrat un serviciu de la PHP 7.4 la PHP 8.0, apoi la 8.1 și mai departe. Nu apar fotografii cu oficiali atunci când se actualizează framework-uri, se rescriu funcții depreciate sau se testează dacă aplicația va funcționa pe următoarea generație a platformei.
Dar exact aceste lucruri sunt cele care fac diferența atunci când apare o vulnerabilitate serioasă.
În software există termenul de „datorie tehnică”. Este o comparație foarte potrivită, pentru că funcționează aproape ca o datorie financiară: poți amâna plata, dar ea nu dispare. Cu cât amâni mai mult modernizarea, cu atât intervenția viitoare devine mai complicată și mai costisitoare.
Ceea ce ai economisit neactualizând o aplicație timp de cinci ani poate ajunge să fie cheltuit într-o singură săptămână de criză, sub presiune și cu servicii oprite.
Digitalizarea nu se termină în ziua lansării
Aici cred că se află una dintre cele mai mari greșeli ale proiectelor publice de digitalizare: software-ul este tratat prea des ca un produs cumpărat o singură dată.
Plătim aplicația, o instalăm, o recepționăm și avem impresia că proiectul este terminat.
Dar o aplicație conectată la Internet seamănă mult mai mult cu un automobil decât cu un dulap. Nu contează doar prețul de achiziție. Contează dacă ai bani pentru revizii, piese, consumabile, actualizări și oameni care știu să intervină atunci când apare o problemă.
Un proiect serios de digitalizare ar trebui să includă încă de la început întregul ciclu de viață al aplicației: actualizarea periodică a platformei, înlocuirea componentelor care ies din suport, audituri de securitate, teste, documentație, medii separate de dezvoltare și testare, backup-uri, proceduri de revenire în caz de eșec și, nu în ultimul rând, oameni care să cunoască sistemul și peste cinci, zece ani sau și mai mult.
Altfel, construim servicii digitale care funcționează impecabil în fotografia de la inaugurare și devin din ce în ce mai fragile pe măsură ce trece timpul.
Vulnerabilitatea nu a creat problema. Doar a venit și a scos mizeria de sub preș
Asta mi se pare, până la urmă, concluzia corectă a episodului.
Cele două vulnerabilități PHP nu au făcut ca aplicațiile vechi să devină brusc vechi. Nu ele au eliminat mentenanța din bugete și nici nu ele au ținut servicii ani întregi pe versiuni ieșite din suport.
Doar au schimbat termenul problemei din „ar trebui să facem cândva” în „trebuie să rezolvăm acum”.
Iar acesta este momentul în care se vede diferența dintre un sistem care a fost îngrijit permanent și unul care a fost doar ținut în viață. Pentru primul, o vulnerabilitate critică înseamnă o perioadă neplăcută de mentenanță și câteva ore de muncă intensă. Pentru al doilea, poate însemna descoperirea faptului că pentru a instala patch-ul trebuie mai întâi modernizată jumătate din aplicație.
Nu cred că lecția este că nu trebuie să digitalizăm deloc. Doar că trebuie să încetăm să confundăm digitalizarea cu simpla finanțare a dezvoltării inițiale.
Un serviciu public nu este cu adevărat digitalizat în momentul în care a apărut pe Internet. Este digitalizat atunci când există și resursele, oamenii și procedurile necesare ca el să rămână funcțional și mai ales sigur pe termen lung.
Altfel, doar mutăm problema dintr-un dosar cu șină într-un server. Și așteptăm următoarea vulnerabilitate ca să aflăm cât ne costă.
