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

Накратко: 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 освен това сочат пакети, обявени от авторите си за изоставени. Такива пакети по правило вече не получават корекции и трябва да се заменят.

Чистият резултат значи само, че за инсталираните версии на пакетите няма известно съобщение. Неизвестни уязвимости и грешки в собствения код инструментът не открива. Как сами да проверите състоянието на PHP, описва статията Как да проверите правилно версията на PHP и състоянието на пача.

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

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

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

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

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

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

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

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

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

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

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

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

#!/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

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

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

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

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

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

Обърнете внимание и на поддръжката на самата версия на PHP. Библиотеките все по-често изискват актуални клонове на PHP. Който все още е на PHP 8.1 или по-стар, за самия PHP вече не получава официални актуализации и често не може да инсталира по-нови версии на пакети с корекции за сигурност. Планирането за това описва наръчникът PHP End of Life: рискове от остарели версии. Указания, специфични за фреймуърка, ще намерите на страницата Защита на приложения с Laravel.

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

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

Проверка от трети страни описва услугата Одит на сигурността и тест за проникване.

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

Източници

• OWASP Top 10
• OWASP Cheat Sheet Series
• php.net: Съобщения за сигурност
• php.net: Поддържани версии