Накратко: Процесът за управление на пачовете определя как минават ъпдейтите от получаването до доказателството: в кой клас попада един пач, в кой прозорец се инсталира, как се тества и връща назад, кой рестартира и как се доказва успехът. Рутинните ъпдейти минават планово по график, спешните пачове следват предварително договорен бърз път. Така от гасене на пожари се получава повтаряем процес.
Когато всеки пач е извънредна ситуация
Вечерта на 21.10.2026 г. в много фирми се разигра един и същи сценарий. Пачовете бяха налице, BSI (Федералната служба за информационна сигурност на Германия) настояваше и започнаха въпросите: Можем ли просто да актуализираме сега? Кой тества? Кой рестартира услугите? Кой казва на управителя, че магазинът ще бъде кратко недостъпен? И как ще докажем после, че е сработило?
Във фирми без процес всичко това трябва да се изясни в момента. Във фирми с процес отговорът вече е готов. Разликата не е в техниката, а в договорките, направени предварително.
Градивните елементи на процеса за управление на пачовете
Работещият процес първо разграничава колко спешен е един пач. Обикновено са достатъчни три класа:
| Клас | Типичен повод | Прозорец | Тест | Одобрение |
|---|---|---|---|---|
| Рутинен | поправки на грешки, ъпдейти за сигурност с нисък риск | фиксиран месечен срок | Staging, стандартни тестове | ИТ, по план |
| Спешен | висока оценка, системата е публично достъпна | с изпреварване в кратък срок | съкратен, най-важните процеси | ръководител ИТ |
| Извънреден | критична уязвимост, съобщени атаки, напр. PHP2Shell | веднага | бърз тест (smoke test) след инсталирането | предварително дадено одобрение за извънредни случаи |
Кой присъжда кой клас, трябва да е определено също като критериите за това. Самата оценка принадлежи на предходната стъпка, вижте Управление на уязвимостите в средния бизнес.
Важно е предварително даденото одобрение за извънредни случаи. Управителят решава веднъж на спокойствие, че при спешни пачове може да се действа веднага, дори това да означава кратко прекъсване. В критичен момент никой не трябва да търси съгласие посред нощ.
Също толкова важни са ролите. За всяка система трябва да е определено кой инсталира ъпдейтите, кой тества по същество дали магазинът или порталът работи след това и кой се информира. При външно поддържани системи хостинг доставчикът и агенцията изрично влизат в списъка, с име и данни за връзка. Фиксираният прозорец за поддръжка трябва да е известен вътрешно, за да знаят продажбите и обслужването на клиенти кога са възможни кратки прекъсвания.
Измервайте и колко време всъщност отнема Вашият процес: от публикуването на пача до доказаното приключване, поотделно за всеки клас. Тези собствени стойности показват къде се закучва и правят подобренията видими. Процес, чиято продължителност никой не знае, трудно може да се управлява.
Редът на един пач в осем стъпки
Всеки пач, независимо от класа, минава през същите етапи. Различават се само темпото и дълбочината на теста.
- Получаване: Съобщението или наличният ъпдейт се отчита с дата и източник.
- Класифициране: Определя се класът и според инвентара се установяват засегнатите системи.
- Подготовка: Резервно копие или snapshot, описание на пътя за връщане назад, информиране на участниците.
- Тест: първо в Staging или на по-малко критична система.
- Инсталиране: в договорения прозорец, система по система.
- Рестарт: всички засегнати услуги и процеси, не само пакетите.
- Доказателство: Записват се състоянието на пакета, записът в changelog-а и стартирането на процесите.
- Контрол: Проверява се функционалността, а при уязвимости в сигурността допълнително се търсят следи от по-ранно проникване.
Стъпка 6 учудващо често се забравя. PHP зарежда кода си при стартиране на процесите. Докато работят стари PHP-FPM работници (worker) или Apache процеси с mod_php, те продължават да работят със стария, уязвим код. Защо е така и как се рестартира правилно, е описано в След ъпдейта: рестартиране на PHP-FPM и на всички работници.
Доказателства, които имат значение по-късно
Пач без доказателство при съмнение не е инсталиран, поне пред клиенти, застрахователи или одитори. Записвайте за всяка система кое състояние на пакета е инсталирано, дали номерата на CVE са в changelog-а и кога са стартирани работещите процеси. На системи с Debian и Ubuntu помагат команди, които само четат, като тези (адаптирайте името на пакета към Вашата система):
# Съдържа ли инсталираният пакет корекциите?
apt-get changelog php8.3-fpm 2>/dev/null | grep -E "CVE-2026-109618|CVE-2026-109619"
# Кога са стартирани работещите PHP-FPM процеси?
ps -eo pid,lstart,cmd | grep "php-fpm" | grep -v grep
Ако моментът на стартиране на процесите е преди инсталирането на пакета, липсва рестартът. Подробно това е описано в Как да докажем номерата на CVE в changelog-а на пакета.
Пачът затваря уязвимост за в бъдеще. Той не премахва зловреден софтуер, внесен преди това, и не доказва, че преди това нищо не се е случило. При спешните пачове затова търсенето на следи е твърда част от процеса.
Автоматизиране там, където е безопасно
Автоматичните ъпдейти за сигурност на пакетите на операционната система спестяват много рутинна работа. Те обаче облекчават само ако има резервни копия, някой чете резултатите и засегнатите услуги също се рестартират. Как се настройва това под Linux и какви са границите, описва Автоматични ъпдейти за сигурност на Linux сървъри.
Контейнерите изискват собствен път. Там не се актуализира в работещата система, а образът (image) с коригираната версия на PHP се изгражда наново и се разгръща. Процес за пачове, който познава само сървъри, лесно пропуска тези системи. Затова включете в списъка с пътищата за пачове и build pipeline-ите и регистрите за образи, с отговорно лице и със същото доказателство като при класическите сървъри: каква версия на PHP работи в разгърнатия контейнер и от кога?
Приложенията, CMS и добавките обикновено изискват собствен, тестван път, защото там ъпдейтите по-често променят функции. Фиксираният месечен срок е подходящото място за това. Накрая е важно всички пътища да се събират в една и съща документация: едно място, където се вижда коя система на какво състояние е.
Как помага PHP SOS конкретно?
- Записваме с Вас класовете пачове, прозорците и одобренията, съобразени с Вашите системи и Вашата организация.
- Настройваме автоматични ъпдейти за сигурност с проверка на рестарта и известяване, където това има смисъл.
- Поемаме спешните пачове, включително рестарт, доказателство и търсене на следи, чрез нашата услуга за PHP пачове.
- Водим доказателствата по системи така, че да можете да ги представите на клиенти, застрахователи или одитори.
Извод: Управлението на пачовете изглежда нескопосано, докато функционира. Точно това е целта: когато дойде следващото критично съобщение, върви един упражнен процес и никой не трябва да импровизира.
Често задавани въпроси
Каква е разликата между управление на пачовете и управление на уязвимостите?
Управлението на уязвимостите отчита и оценява пропуските и решава какво да се прави. Управлението на пачовете изпълнява решението: тества ъпдейтите, инсталира ги, рестартира услугите и доказва успеха. Двете се допълват.
Трябва ли ъпдейтите за сигурност да се инсталират автоматично?
За пакетите на операционната система това често има смисъл, при условие че има резервни копия и след изпълнението се проверява. Важно е засегнатите услуги също да се рестартират. При PHP иначе в паметта остават стари процеси с уязвимия код.
Как да докажа, че пачът наистина действа?
С инсталираното състояние на пакета и номерата на CVE в changelog-а на пакета, с момента на инсталиране и с момента на стартиране на работещите процеси, който трябва да е след инсталирането.
Какво да направя, ако един ъпдейт счупи нещо?
За това има път за връщане назад: резервно копие или снимка (snapshot) преди ъпдейта и описана процедура за връщане. При ъпдейти за сигурност връщането назад трябва да е изключение и да се съчетае с временна мярка.