# composer audit: проверка на зависимостите за уязвимости

> С composer audit проверявате PHP зависимостите за уязвимости. Команди, включване в CI и deployment и защо самият PHP трябва да се пачва отделно.

Източник: https://phpsos.de/bg/ratgeber/composer-abhaengigkeiten-pruefen/  
Актуалност: 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

**Накратко:** `composer audit` сверява пакетите на Вашия PHP проект с известни съобщения за сигурност и показва засегнатите версии. Изпълнявайте командата при всеки build и редовно върху продуктивното състояние. Важно след PHP2Shell: проверката обхваща библиотеките, а не самия интерпретатор на PHP.

## Защо зависимостите се нуждаят от внимание именно сега

Съвременните PHP приложения се състоят най-вече от чужд код. Магазин на база Symfony или портал с Laravel бързо носи няколко десетки до стотици пакета, много от тях косвено през други пакети. Всяка от тези библиотеки може да съдържа уязвимост. Затова OWASP Top 10 отделя остарелите и уязвими компоненти в собствена категория риск.

През октомври 2026 г. PHP2Shell показа колко бързо една критична уязвимост се разпространява. Двете уязвимости CVE-2026-109618 и CVE-2026-109619 засягат самия PHP, а не пакетите на Composer. Много екипи обаче през тези дни проверяваха цялата си верига и установиха, че изобщо не познават точно състоянието на зависимостите си.

Тази празнина в прегледа може да се затвори с малко усилия. Composer носи подходящия инструмент вече в актуалните си версии.

## Какво проверява composer audit и какво не

Командата чете инсталираните пакети или lock файла и пита за известни съобщения за сигурност за тези пакети. За всяко съвпадение показва пакета, засегнатия диапазон на версиите, степента на тежест, идентификатора на съобщението и връзка към описанието.

| Ниво | Проверява ли се от composer audit? | Как да се провери иначе |
|---|---|---|
| Composer пакети в проекта | да | composer audit |
| Интерпретатор на PHP (напр. PHP2Shell) | не | Състояние на пакета, потвърждение от хостинг доставчика |
| PHP разширения от системата | не | Пакетният мениджър на дистрибуцията |
| JavaScript пакети във frontend | не | Инструмент на съответния пакетен мениджър |
| Собствен код на приложението | не | Преглед на кода, одит на сигурността |

Командата отчита и косвените зависимости, т.е. пакети, които никога не сте заявявали сами, но които идват през други пакети. Именно там често незабелязано се крият уязвимости, защото никой в екипа не познава тези пакети. По-новите версии на Composer освен това сочат пакети, обявени от авторите си за изоставени. Такива пакети по правило вече не получават корекции и трябва да се заменят.

Чистият резултат значи само, че за инсталираните версии на пакетите няма известно съобщение. Неизвестни уязвимости и грешки в собствения код инструментът не открива. Как сами да проверите състоянието на PHP, описва статията [Как да проверите правилно версията на PHP и състоянието на пача](https://phpsos.de/bg/php2shell/php-version-pruefen/).

## Изпълнение на composer audit и четене на резултатите

В директорията на проекта е достатъчна една команда. Вариантите се различават по това какво се проверява и как се извежда резултатът.

```bash
# Проверка на инсталираните пакети
composer audit

# Проверка само на lock файла, напр. в build без инсталирани пакети
composer audit --locked

# Без зависимостите за разработка (състояние като на сървъра)
composer audit --no-dev

# Машинночетим изход за оценка или система за тикети
composer audit --format=json > audit-$(date +%F).json
```

Ако командата намери уязвимости, завършва с код за грешка. Това е нарочно, защото така автоматизираният build се прекъсва. Оценете всяко съвпадение: пакетът използва ли се на сървъра, използва ли се засегнатата функция, има ли поправена версия?

```bash
# Кои директни зависимости са остарели?
composer outdated --direct
# Защо е инсталиран определен пакет?
composer why vendor/paket
# Целево актуализиране със зависимостите
composer update vendor/paket --with-dependencies
```

Тествайте всяка актуализация в staging среда. Актуализациите за сигурност в рамките на същата основна версия обикновено са безпроблемни, докато нова основна версия може да изисква корекции в кода.

## Автоматизиране на проверката

Еднократното изпълнение помага малко, защото нови уязвимости стават известни непрекъснато. Затова включете `composer audit` на две места: в build pipeline при всяка промяна и в редовна проверка на продуктивното състояние, дори когато в кода нищо не се променя.

Прост скрипт за ежедневно изпълнение на build или проверяващия сървър може да изглежда така:

```bash
#!/bin/sh
# Ежедневен одит на доставеното състояние (адаптирайте пътя)
cd /srv/build/meine-anwendung || exit 1
if ! composer audit --locked --no-dev --format=plain > /var/log/composer-audit.log 2>&1; then
  logger -t composer-audit "Lücken in meine-anwendung gefunden, siehe /var/log/composer-audit.log"
fi
```

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

> **Съвет:**
> Задайте в `composer.json` под `config.platform.php` версията на PHP, която работи на сървъра. Тогава Composer разрешава само пакети, които пасват на това състояние, а `composer check-platform-reqs` показва отклоненията.

## Чисто доставяне: deployment без странични ефекти

И пътят към сървъра влияе на сигурността. Доказаха се няколко основни правила:

- Включете `composer.lock` в хранилището и на сървъра изпълнявайте само `composer install`, никога `composer update`.
- Инсталирайте с `--no-dev`, за да не попадат инструменти за тестване и дебъгване на продуктивния сървър.
- Дръжте папката `vendor/` извън кореновата директория на уеб сървъра, така че да не е достъпна директно през URL.
- Изпълнявайте `composer validate` в build, за да откривате рано грешни или противоречиви данни.

```bash
composer validate --strict
composer install --no-dev --prefer-dist --classmap-authoritative --no-interaction
```

Обърнете внимание и на поддръжката на самата версия на PHP. Библиотеките все по-често изискват актуални клонове на PHP. Който все още е на PHP 8.1 или по-стар, за самия PHP вече не получава официални актуализации и често не може да инсталира по-нови версии на пакети с корекции за сигурност. Планирането за това описва наръчникът [PHP End of Life: рискове от остарели версии](https://phpsos.de/bg/ratgeber/php-end-of-life-risiken/). Указания, специфични за фреймуърка, ще намерите на страницата [Защита на приложения с Laravel](https://phpsos.de/bg/plattformen/laravel/).

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

- Установяваме състоянието на всички зависимости и оценяваме съвпаденията според действителната употреба.
- Въвеждаме автоматизирани проверки в build и експлоатацията, с ясна отговорност за констатациите.
- Планираме и тестваме актуализациите, дори когато нови основни версии изискват корекции.
- При желание проверяваме и собствения код и конфигурацията, където никой автоматичен инструмент не поглежда.

Проверка от трети страни описва услугата [Одит на сигурността и тест за проникване](https://phpsos.de/bg/leistungen/sicherheitsaudit-penetrationstest/).


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

**Открива ли composer audit и PHP2Shell?**  
Не. composer audit проверява пакетите във Вашия проект, а не интерпретатора на PHP на сървъра. PHP2Shell е в самия PHP и се отстранява само чрез актуализация на PHP и рестарт на всички PHP процеси.

**Трябва ли composer.lock да е в хранилището?**  
При приложенията да. Lock файлът фиксира кои точно версии са инсталирани. Само така composer audit проверява състоянието, което действително работи на сървъра, а всеки deployment инсталира едни и същи версии.

**Какво да направя, ако за засегнат пакет няма актуализация?**  
Проверете дали Вашият проект изобщо използва засегнатата функция и документирайте оценката. Ако няма поправка, идват предвид заместващ пакет, собствен пач или временна защита на ниво сървър.

**Колко често да изпълнявам composer audit?**  
При всеки build и допълнително редовно, например ежедневно, дори без промени в кода. Нови уязвимости се съобщават непрекъснато и състояние, което вчера е било чисто, днес може да е засегнато.

## Източници

- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
- [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)
- [php.net: Съобщения за сигурност](https://www.php.net/)
- [php.net: Поддържани версии](https://www.php.net/supported-versions.php)