# Управление на пачовете като процес, а не като гасене на пожари

> Управление на пачовете като процес: класове, прозорци за поддръжка, тест, връщане назад, рестарт и доказателства, за да пасват критичните ъпдейти.

Източник: https://phpsos.de/bg/blog/patch-management-prozess/  
Актуалност: 25.10.2026  
Доставчик: PHP SOS, Спешна помощ за PHP и сигурност на сървъри. Незабавна помощ по WhatsApp: https://wa.me/491736494914?text=%D0%97%D0%B4%D1%80%D0%B0%D0%B2%D0%B5%D0%B9%D1%82%D0%B5%2C%20PHP%20SOS%2C%20%D0%B8%D0%BC%D0%B0%D0%BC%D0%B5%20%D0%BD%D1%83%D0%B6%D0%B4%D0%B0%20%D0%BE%D1%82%20%D0%BF%D0%BE%D0%BC%D0%BE%D1%89%20%D1%81%20%D0%BD%D0%B0%D1%88%D0%B8%D1%8F%20PHP%20%D1%81%D1%8A%D1%80%D0%B2%D1%8A%D1%80.%20%D0%A4%D0%B8%D1%80%D0%BC%D0%B0%3A%20%E2%80%A6%20%D0%A3%D0%B5%D0%B1%D1%81%D0%B0%D0%B9%D1%82%3A%20%E2%80%A6

**Накратко:** Процесът за управление на пачовете определя как минават ъпдейтите от получаването до доказателството: в кой клас попада един пач, в кой прозорец се инсталира, как се тества и връща назад, кой рестартира и как се доказва успехът. Рутинните ъпдейти минават планово по график, спешните пачове следват предварително договорен бърз път. Така от гасене на пожари се получава повтаряем процес.

## Когато всеки пач е извънредна ситуация

Вечерта на 21.10.2026 г. в много фирми се разигра един и същи сценарий. Пачовете бяха налице, BSI (Федералната служба за информационна сигурност на Германия) настояваше и започнаха въпросите: Можем ли просто да актуализираме сега? Кой тества? Кой рестартира услугите? Кой казва на управителя, че магазинът ще бъде кратко недостъпен? И как ще докажем после, че е сработило?

Във фирми без процес всичко това трябва да се изясни в момента. Във фирми с процес отговорът вече е готов. Разликата не е в техниката, а в договорките, направени предварително.

## Градивните елементи на процеса за управление на пачовете

Работещият процес първо разграничава колко спешен е един пач. Обикновено са достатъчни три класа:

| Клас | Типичен повод | Прозорец | Тест | Одобрение |
|---|---|---|---|---|
| Рутинен | поправки на грешки, ъпдейти за сигурност с нисък риск | фиксиран месечен срок | Staging, стандартни тестове | ИТ, по план |
| Спешен | висока оценка, системата е публично достъпна | с изпреварване в кратък срок | съкратен, най-важните процеси | ръководител ИТ |
| Извънреден | критична уязвимост, съобщени атаки, напр. PHP2Shell | веднага | бърз тест (smoke test) след инсталирането | предварително дадено одобрение за извънредни случаи |

Кой присъжда кой клас, трябва да е определено също като критериите за това. Самата оценка принадлежи на предходната стъпка, вижте [Управление на уязвимостите в средния бизнес](https://phpsos.de/bg/blog/schwachstellenmanagement-mittelstand/).

Важно е предварително даденото одобрение за извънредни случаи. Управителят решава веднъж на спокойствие, че при спешни пачове може да се действа веднага, дори това да означава кратко прекъсване. В критичен момент никой не трябва да търси съгласие посред нощ.

Също толкова важни са ролите. За всяка система трябва да е определено кой инсталира ъпдейтите, кой тества по същество дали магазинът или порталът работи след това и кой се информира. При външно поддържани системи хостинг доставчикът и агенцията изрично влизат в списъка, с име и данни за връзка. Фиксираният прозорец за поддръжка трябва да е известен вътрешно, за да знаят продажбите и обслужването на клиенти кога са възможни кратки прекъсвания.

Измервайте и колко време всъщност отнема Вашият процес: от публикуването на пача до доказаното приключване, поотделно за всеки клас. Тези собствени стойности показват къде се закучва и правят подобренията видими. Процес, чиято продължителност никой не знае, трудно може да се управлява.

## Редът на един пач в осем стъпки

Всеки пач, независимо от класа, минава през същите етапи. Различават се само темпото и дълбочината на теста.

1. **Получаване:** Съобщението или наличният ъпдейт се отчита с дата и източник.
2. **Класифициране:** Определя се класът и според инвентара се установяват засегнатите системи.
3. **Подготовка:** Резервно копие или snapshot, описание на пътя за връщане назад, информиране на участниците.
4. **Тест:** първо в Staging или на по-малко критична система.
5. **Инсталиране:** в договорения прозорец, система по система.
6. **Рестарт:** всички засегнати услуги и процеси, не само пакетите.
7. **Доказателство:** Записват се състоянието на пакета, записът в changelog-а и стартирането на процесите.
8. **Контрол:** Проверява се функционалността, а при уязвимости в сигурността допълнително се търсят следи от по-ранно проникване.

Стъпка 6 учудващо често се забравя. PHP зарежда кода си при стартиране на процесите. Докато работят стари PHP-FPM работници (worker) или Apache процеси с mod_php, те продължават да работят със стария, уязвим код. Защо е така и как се рестартира правилно, е описано в [След ъпдейта: рестартиране на PHP-FPM и на всички работници](https://phpsos.de/bg/php2shell/php-fpm-neustart/).

## Доказателства, които имат значение по-късно

Пач без доказателство при съмнение не е инсталиран, поне пред клиенти, застрахователи или одитори. Записвайте за всяка система кое състояние на пакета е инсталирано, дали номерата на CVE са в changelog-а и кога са стартирани работещите процеси. На системи с Debian и Ubuntu помагат команди, които само четат, като тези (адаптирайте името на пакета към Вашата система):

```bash
# Съдържа ли инсталираният пакет корекциите?
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-а на пакета](https://phpsos.de/bg/blog/cve-im-changelog-nachweisen/).

> **Важно:**
> Пачът затваря уязвимост за в бъдеще. Той не премахва зловреден софтуер, внесен преди това, и не доказва, че преди това нищо не се е случило. При спешните пачове затова търсенето на следи е твърда част от процеса.

## Автоматизиране там, където е безопасно

Автоматичните ъпдейти за сигурност на пакетите на операционната система спестяват много рутинна работа. Те обаче облекчават само ако има резервни копия, някой чете резултатите и засегнатите услуги също се рестартират. Как се настройва това под Linux и какви са границите, описва [Автоматични ъпдейти за сигурност на Linux сървъри](https://phpsos.de/bg/blog/automatische-sicherheitsupdates/).

Контейнерите изискват собствен път. Там не се актуализира в работещата система, а образът (image) с коригираната версия на PHP се изгражда наново и се разгръща. Процес за пачове, който познава само сървъри, лесно пропуска тези системи. Затова включете в списъка с пътищата за пачове и build pipeline-ите и регистрите за образи, с отговорно лице и със същото доказателство като при класическите сървъри: каква версия на PHP работи в разгърнатия контейнер и от кога?

Приложенията, CMS и добавките обикновено изискват собствен, тестван път, защото там ъпдейтите по-често променят функции. Фиксираният месечен срок е подходящото място за това. Накрая е важно всички пътища да се събират в една и съща документация: едно място, където се вижда коя система на какво състояние е.

## Как помага PHP SOS конкретно?

- Записваме с Вас класовете пачове, прозорците и одобренията, съобразени с Вашите системи и Вашата организация.
- Настройваме автоматични ъпдейти за сигурност с проверка на рестарта и известяване, където това има смисъл.
- Поемаме спешните пачове, включително рестарт, доказателство и търсене на следи, чрез нашата [услуга за PHP пачове](https://phpsos.de/bg/leistungen/php-patch-service/).
- Водим доказателствата по системи така, че да можете да ги представите на клиенти, застрахователи или одитори.

**Извод:** Управлението на пачовете изглежда нескопосано, докато функционира. Точно това е целта: когато дойде следващото критично съобщение, върви един упражнен процес и никой не трябва да импровизира.


## Често задавани въпроси

**Каква е разликата между управление на пачовете и управление на уязвимостите?**  
Управлението на уязвимостите отчита и оценява пропуските и решава какво да се прави. Управлението на пачовете изпълнява решението: тества ъпдейтите, инсталира ги, рестартира услугите и доказва успеха. Двете се допълват.

**Трябва ли ъпдейтите за сигурност да се инсталират автоматично?**  
За пакетите на операционната система това често има смисъл, при условие че има резервни копия и след изпълнението се проверява. Важно е засегнатите услуги също да се рестартират. При PHP иначе в паметта остават стари процеси с уязвимия код.

**Как да докажа, че пачът наистина действа?**  
С инсталираното състояние на пакета и номерата на CVE в changelog-а на пакета, с момента на инсталиране и с момента на стартиране на работещите процеси, който трябва да е след инсталирането.

**Какво да направя, ако един ъпдейт счупи нещо?**  
За това има път за връщане назад: резервно копие или снимка (snapshot) преди ъпдейта и описана процедура за връщане. При ъпдейти за сигурност връщането назад трябва да е изключение и да се съчетае с временна мярка.

## Източници

- [php.net: Съобщения за сигурност](https://www.php.net/)
- [Debian Security Tracker](https://security-tracker.debian.org/)
- [Ubuntu Security Notices](https://ubuntu.com/security/notices)
- [BSI IT-Grundschutz](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)