Накратко: Който иска да актуализира зависимостите, се нуждае от процес за три свята на пакети: Composer пакети в PHP кода, npm модули във фронтенд build-а и добавки или теми в CMS. Към това спадат твърд ритъм, отговорно лице, тестове преди внедряване и план за пакети без актуализация. Срещу PHP2Shell това не помага, защото тази уязвимост е в самия PHP, а срещу многото уязвимости в чужд код помага.
Три свята на пакети, едно сляпо петно
В седмицата след 21.10.2026 г. всичко се въртеше около интерпретатора на PHP. Много екипи при това забелязаха, че не познават точно версиите на собствените си градивни елементи. Уебсайтът работи, агенцията се грижи, добавката сама се обажда, когато има нещо ново: така или подобно гласят предположенията, докато някой не погледне.
Един типичен PHP проект днес се състои от значително повече чужд код, отколкото собствен. OWASP Top 10 водят уязвимите и остарелите компоненти като отделна категория риск. Проблемът рядко е в липсващия инструмент, а в липсващата рутина: актуализации се правят, когато някой има време, а съобщенията за сигурност попадат в пощенска кутия, която никой не чете.
Кои зависимости къде актуализирате?
Всеки свят на пакети има собствени инструменти и собствени клопки. Следващият преглед помага да не пропуснете нищо.
| Свят на пакети | Показване на състоянието | Проверка за уязвимости | Типична клопка |
|---|---|---|---|
| Composer (PHP библиотеки) | composer show |
composer audit |
непреки пакети, които никой не познава |
| npm (фронтенд build) | npm ls |
npm audit |
актуализация без ново изграждане никога не стига до сървъра |
| Добавки и теми за CMS | административен интерфейс или CLI | указания на производителя, услуги за сигурност | изоставени добавки, платени добавки без канал за актуализации |
| PHP и разширения | управление на пакетите | Security Tracker на дистрибуцията | показаната версия казва малко за backport корекции |
Последният ред строго погледнато не спада към зависимостите на приложението, но често се забравя в същия дъх. Същото важи за скриптове, които се включват директно от чужди сървъри, например библиотеки от CDN, чат уиджети или код за проследяване. Те не се появяват в нито един lock файл, но работят в браузъра на Вашите посетители. Включете ги в списъка и проверете дали са вградени с фиксирани версии вместо „винаги най-новата“. Подробностите за composer audit, lock файла и включването в build-а са в наръчника Проверка на Composer зависимостите за уязвимости. Как Composer работи по принцип, обяснява Composer: управлението на пакети за PHP.
Цикълът на поддръжка в шест стъпки
Един устойчив процес не трябва да е сложен. Тази последователност се е доказала:
- Фиксирайте състоянието: за всеки проект списък на директните зависимости с версия, произход и предназначение. Lock файловете (
composer.lock,package-lock.json) принадлежат в хранилището. - Събирайте съобщенията: инструментите за проверка работят при всеки build и допълнително редовно върху доставеното състояние, дори без промяна в кода.
- Оценявайте: ползва ли се засегнатият пакет в продукция, достъпна ли е засегнатата функция, има ли отстранена версия?
- Актуализирайте и тествайте в staging: първо актуализации за сигурност в рамките на същата основна версия, преходите към нови основни версии планирайте като отделно начинание.
- Внедрявайте с път за връщане: предишното състояние остава налично като пакет или издание, резервно копие на базата данни преди актуализацията.
- Документирайте: какво кога е актуализирано, какво съзнателно не и защо.
Обърнете внимание при това на указанията за версии в composer.json и package.json. Твърде тесните изисквания пречат изобщо да се инсталират корекции за сигурност. Твърде широките изисквания пък внасят непроверени нови основни версии в проекта. Доказало се е да се позволяват актуализации в рамките на основната версия, а преходът към следващата да се планира съзнателно.
За добавките в CMS наличните актуализации често могат да се покажат и в командния ред, при WordPress например с WP-CLI:
# Показване на наличните актуализации, без да се променя нещо
wp plugin list --update=available
wp theme list --update=available
# Фронтенд пакети: остарели версии и известни уязвимости
npm outdated
npm audit --omit=dev
Автоматичните актуализации на добавки директно върху продуктивната система са удобни, но рискови, ако никой не проверява след това. Включвайте ги само ако са осигурени резервно копие преди всяко изпълнение и проверка след него.
Когато няма актуализация
Не всяко съобщение се решава с едно щракване. OWASP Cheat Sheet за работа с уязвими зависимости разграничава няколко случая, които добре се пренасят в ежедневието:
- Налице е пач: внесете го в staging, тествайте, внедрете. Ако нещо се счупи, приспособете собствения код, вместо да оставите актуализацията.
- Пачът е обявен, но още го няма: приложете заобиколното решение на производителя, изключете или скрийте засегнатата функция, ако е възможно, и запишете решението.
- Не се очаква пач: потърсете заместващ пакет или сами пренесете корекцията назад (backport), с тест, който различава уязвимостта преди и след пача.
При добавките за CMS често се среща четвърти случай: добавката е изоставена. Тогава помагат само замяна или премахване. Същото важи за добавки от неясни източници, например „безплатни“ копия на платени добавки. Те не получават актуализации през официалния канал и не рядко самите съдържат злонамерен код. Насоки за операторите на WordPress обобщава WordPress и PHP2Shell.
Изяснете отговорността, преди да дойде следващото съобщение
Най-честата причина за остарели пакети не е техническа пречка, а отворен въпрос: кой го прави? При проекти, които е изградила агенция и които се експлоатират вътрешно, често никой не се чувства отговорен. Определете за всеки проект кой получава съобщенията, кой оценява и кой одобрява, и го запишете.
Планирайте освен това време. Фиксиран срок за поддръжка веднъж месечно, в който зависимостите се проверяват и актуализират, предотвратява актуализациите да се трупат с години. Колкото по-дълго един проект не е актуализиран, толкова по-голям и рисков става следващият скок. Как актуализациите на PHP и пакетите се вписват в общ процес, описва Управление на пачовете като процес, а не гасене на пожари.
Как помага PHP SOS конкретно?
- Отчитаме всички зависимости на Вашите проекти от Composer, npm и CMS и маркираме остарелите, уязвимите и изоставените пакети.
- Въвеждаме автоматични проверки и определяме кой оценява кое съобщение.
- Актуализираме в staging, тестваме най-важните процеси и внедряваме с път за връщане.
- В рамките на договор за поддръжка на сигурността поемаме месечния цикъл трайно, включително актуализациите на PHP.
Заключение: Актуалните зависимости не са проект, а рутина. Който веднъж подреди чисто състоянието, ритъма и отговорността, при следващото голямо съобщение трябва само да провери, а не първо да търси.
Често задавани въпроси
Колко често трябва да се актуализират зависимостите?
Актуализациите за сигурност възможно най-скоро след оценка, рутинните актуализации с твърд ритъм, например месечно. По-важно от точната честота е срокът да е определен и някой да отговаря за него.
Защитава ли актуална добавка от PHP2Shell?
Не. PHP2Shell е в самия интерпретатор на PHP. Срещу това помага само актуализация на PHP с рестарт на всички PHP процеси. Актуалните добавки и пакети все пак са важни, защото затварят собствени уязвимости.
Какво да правя с добавка, която вече не се поддържа?
Заменете я или я премахнете. Изоставена добавка не получава повече корекции, дори ако днес още работи. До замяната проверете дали функцията наистина е необходима и документирайте решението.
Трябва ли фронтендът с npm да се актуализира и на сървъра?
Често npm пакетите са само в build-а и стигат до сървъра като готови файлове. Уязвимост в пакет все пак може да се крие в доставения JavaScript. След актуализация затова трябва да се изгради наново и да се достави наново.