Ukratko: Proces upravljanja zakrpama određuje kako ažuriranja teku od zaprimanja do dokaza: u koju klasu zakrpa spada, u kojem se prozoru instalira, kako se testira i vraća, tko ponovno pokreće i kako se dokazuje uspjeh. Rutinska ažuriranja teku planski u ritmu, a hitne zakrpe slijede unaprijed dogovoren brzi put. Tako od gašenja požara nastaje ponovljiv postupak.
Kad je svaka zakrpa hitni slučaj
Navečer 21. 10. 2026. u mnogim se tvrtkama odvijao isti obrazac. Zakrpe su bile tu, BSI (njemački Savezni ured za informacijsku sigurnost) je navaljivao i počela su pitanja: Smijemo li sada jednostavno ažurirati? Tko testira? Tko ponovno pokreće usluge? Tko javlja upravi da će shop nakratko biti nedostupan? I kako poslije dokazujemo da je uspjelo?
U tvrtkama bez procesa sve se to mora razjasniti u trenutku. U tvrtkama s procesom odgovor je već utvrđen. Razlika nije u tehnici, nego u dogovorima postignutima unaprijed.
Građevni elementi procesa upravljanja zakrpama
Održiv proces najprije razlikuje koliko je zakrpa hitna. Najčešće su dovoljne tri klase:
| Klasa | Tipičan povod | Prozor | Test | Odobrenje |
|---|---|---|---|---|
| Rutina | ispravci pogrešaka, sigurnosna ažuriranja niskog rizika | čvrst mjesečni termin | staging, standardni testovi | IT, prema planu |
| Hitno | visoka ocjena, sustav javno dostupan | kratkoročno ubrzano | skraćeno, najvažniji tijekovi | voditelj IT-a |
| Hitni slučaj | kritična ranjivost, prijavljeni napadi, npr. PHP2Shell | odmah | brzi test nakon instalacije | unaprijed dano odobrenje za hitne slučajeve |
Tko dodjeljuje koju klasu, treba biti jednako utvrđeno kao i kriteriji za to. Sama procjena pripada prethodnom koraku, vidi Upravljanje ranjivostima za srednje tvrtke.
Važno je unaprijed dano odobrenje za hitne slučajeve. Uprava jednom, u miru, odluči da se kod hitnih zakrpa smije djelovati odmah, čak i ako to znači kratak prekid. U kritičnom trenutku tada nitko ne mora noću tražiti suglasnost.
Jednako su važne uloge. Za svaki sustav treba biti utvrđeno tko instalira ažuriranja, tko stručno testira funkcionira li shop ili portal nakon toga i tko se obavještava. Kod izvanjskih sustava pružatelj hostinga i agencija izričito pripadaju tamo, s imenom i dostupnošću. Čvrsti prozor održavanja trebao bi biti poznat unutar tvrtke kako bi prodaja i korisnička služba znali kada su moguće kratke prekide.
Mjerite i koliko Vaš proces stvarno traje: od objave zakrpe do dokazanog zaključenja, odvojeno po klasama. Te vlastite vrijednosti pokazuju gdje zapinje i čine poboljšanja vidljivima. Procesom čije trajanje nitko ne zna teško se upravlja.
Tijek zakrpe u osam koraka
Svaka zakrpa, bez obzira na klasu, prolazi iste postaje. Razlikuju se samo tempo i dubina testiranja.
- Zaprimanje: obavijest ili dostupno ažuriranje bilježi se s datumom i izvorom.
- Razvrstavanje: odrediti klasu, prema popisu utvrditi pogođene sustave.
- Priprema: sigurnosna kopija ili snapshot, opisati povratni put, obavijestiti sudionike.
- Test: najprije na stagingu ili na manje kritičnom sustavu.
- Instalacija: u dogovorenom prozoru, sustav po sustav.
- Ponovno pokretanje: sve pogođene usluge i procesi, ne samo paketi.
- Dokaz: zabilježiti stanje paketa, unos u changelogu i pokretanje procesa.
- Kontrola: provjeriti funkciju, a kod sigurnosnih ranjivosti dodatno paziti na tragove ranije provale.
Korak 6 začudo se često zaboravi. PHP učitava svoj kod pri pokretanju procesa. Dok god rade stari PHP-FPM workeri ili Apache procesi s mod_php-om, nastavljaju raditi sa starim, ranjivim stanjem. Zašto je tome tako i kako se ispravno ponovno pokreće, piše u članku Nakon ažuriranja: ponovno pokretanje PHP-FPM-a i svih workera.
Dokazi koji kasnije vrijede
Zakrpa bez dokaza, u slučaju sumnje, nije instalirana, barem prema kupcima, osigurateljima ili revizorima. Za svaki sustav zabilježite koje je stanje paketa instalirano, nalaze li se CVE brojevi u changelogu i kada su pokrenuti aktivni procesi. Na Debian i Ubuntu sustavima pomažu naredbe koje samo čitaju, poput ovih (naziv paketa prilagodite svom sustavu):
# Sadrži li instalirani paket ispravke?
apt-get changelog php8.3-fpm 2>/dev/null | grep -E "CVE-2026-109618|CVE-2026-109619"
# Kada su pokrenuti aktivni PHP-FPM procesi?
ps -eo pid,lstart,cmd | grep "php-fpm" | grep -v grep
Ako je vrijeme pokretanja procesa prije instalacije paketa, nedostaje ponovno pokretanje. Detaljno to opisuje članak Dokazivanje CVE brojeva u changelogu paketa.
Zakrpa zatvara ranjivost za ubuduće. Ne uklanja zlonamjerni softver koji je prije ubačen i ne dokazuje da se prije ništa nije dogodilo. Kod hitnih zakrpa traženje tragova stoga čvrsto pripada tijeku.
Automatizirati gdje je sigurno
Automatska sigurnosna ažuriranja paketa operacijskog sustava preuzimaju mnogo rutinskog posla. Rasterećuju ipak samo ako postoje sigurnosne kopije, ako netko čita rezultate i ako se ponovno pokreću i pogođene usluge. Kako se to postavlja na Linuxu i koje su granice, opisuje Automatska sigurnosna ažuriranja na Linux poslužiteljima.
Kontejneri trebaju vlastiti put. Tamo se ne ažurira u pokrenutom sustavu, nego se image s ispravljenom verzijom PHP-a ponovno izgradi i isporuči. Proces zakrpanja koji poznaje samo poslužitelje lako previdi te sustave. Zato u popis putova zakrpanja uvrstite i build pipelineove i registre image-a, s odgovornom osobom i istim dokazom kao kod klasičnih poslužitelja: Koja verzija PHP-a radi u isporučenom kontejneru i od kada?
Aplikacije, CMS i dodaci najčešće trebaju vlastiti, testiran put jer ažuriranja tamo češće mijenjaju funkcije. Čvrst mjesečni termin za to je pravo mjesto. Na kraju je važno da se svi putovi slijevaju u istu dokumentaciju: jedno mjesto na kojem se vidi koji je sustav na kojem stanju.
Kako PHP SOS konkretno pomaže?
- S Vama zapisujemo klase zakrpa, prozore i odobrenja, prilagođene Vašim sustavima i Vašoj organizaciji.
- Postavljamo automatska sigurnosna ažuriranja s provjerom ponovnog pokretanja i obavijesti gdje je to smisleno.
- Preuzimamo hitne zakrpe, uključujući ponovno pokretanje, dokaz i traženje tragova, putem naše usluge PHP zakrpa.
- Dokaze vodimo po sustavu tako da ih možete predočiti kupcima, osigurateljima ili revizorima.
Zaključak: Upravljanje zakrpama djeluje nespektakularno dok funkcionira. Upravo je to cilj: kad stigne sljedeća kritična obavijest, teče uvježban postupak i nitko ne mora improvizirati.
Česta pitanja
Koja je razlika između upravljanja zakrpama i upravljanja ranjivostima?
Upravljanje ranjivostima evidentira i procjenjuje ranjivosti te odlučuje što učiniti. Upravljanje zakrpama provodi odluku: testira ažuriranja, instalira ih, ponovno pokreće usluge i dokazuje uspjeh. Oboje se međusobno nadopunjuju.
Treba li sigurnosna ažuriranja instalirati automatski?
Za pakete operacijskog sustava to je često smisleno, ako postoje sigurnosne kopije i ako se nakon izvođenja provjerava ishod. Važno je da se ponovno pokrenu i pogođene usluge. Kod PHP-a inače u memoriji ostaju stari procesi s ranjivim kodom.
Kako dokazati da zakrpa stvarno djeluje?
Stanjem instaliranog paketa i CVE brojevima u changelogu paketa, vremenom instalacije i vremenom pokretanja aktivnih procesa, koje mora biti nakon instalacije.
Što učiniti ako ažuriranje nešto pokvari?
Za to postoji povratni put: sigurnosna kopija ili snapshot prije ažuriranja i opisan postupak vraćanja. Kod sigurnosnih ažuriranja vraćanje bi trebalo biti iznimka i treba ga povezati s prijelaznom mjerom.