composer audit: kontrola zależności pod kątem luk

Krótko: composer audit porównuje pakiety Państwa projektu PHP ze znanymi komunikatami bezpieczeństwa i pokazuje dotknięte wersje. Proszę uruchamiać to polecenie przy każdym buildzie i regularnie na stanie produkcyjnym. Ważne po PHP2Shell: kontrola obejmuje biblioteki, a nie sam interpreter PHP.

Dlaczego zależności wymagają uwagi właśnie teraz

Nowoczesne aplikacje PHP składają się w większości z obcego kodu. Sklep oparty na Symfony czy portal z Laravelem szybko wnosi kilkadziesiąt do kilkuset pakietów, wiele z nich pośrednio przez inne pakiety. Każda z tych bibliotek może zawierać lukę. OWASP Top 10 wymienia dlatego przestarzałe i podatne komponenty jako osobną kategorię ryzyka.

W październiku 2026 PHP2Shell pokazało, jak szybko krytyczna luka się rozprzestrzenia. Obie luki, CVE-2026-109618 i CVE-2026-109619, dotyczą wprawdzie samego PHP, a nie pakietów Composera. Wiele zespołów przejrzało jednak w tych dniach cały swój łańcuch i stwierdziło, że w ogóle nie zna dokładnie stanu swoich zależności.

Tę lukę w przeglądzie można zamknąć niewielkim nakładem. Composer ma odpowiednie narzędzie już w aktualnych wersjach.

Co composer audit sprawdza, a czego nie

Polecenie czyta zainstalowane pakiety lub plik lock i odpytuje o znane komunikaty bezpieczeństwa dotyczące tych pakietów. Dla każdego trafienia pokazuje pakiet, dotknięty zakres wersji, wagę, identyfikator komunikatu i link do opisu.

Polecenie uwzględnia także zależności pośrednie, czyli pakiety, których Państwo nigdy sami nie zamawiali, a które przychodzą z innymi pakietami. Właśnie tam luki często pozostają niezauważone, ponieważ nikt w zespole nie zna tych pakietów. Nowsze wersje Composera wskazują ponadto pakiety oznaczone przez ich autorów jako porzucone. Takie pakiety zwykle nie otrzymują już poprawek i należy je zastąpić.

Czysty wynik oznacza więc tylko tyle, że dla zainstalowanych wersji pakietów nie ma znanego komunikatu. Nieznanych luk i błędów we własnym kodzie narzędzie nie znajdzie. Jak samodzielnie sprawdzić stan PHP, opisuje artykuł Jak prawidłowo sprawdzić wersję PHP i stan poprawek.

Uruchamianie composer audit i czytanie wyników

W katalogu projektu wystarczy jedno polecenie. Warianty różnią się tym, co jest sprawdzane i jak wynik jest wyświetlany.

# Sprawdź zainstalowane pakiety
composer audit

# Sprawdź tylko plik lock, np. w buildzie bez zainstalowanych pakietów
composer audit --locked

# Pomiń zależności deweloperskie (stan jak na serwerze)
composer audit --no-dev

# Wyjście czytelne maszynowo do analizy lub systemu zgłoszeń
composer audit --format=json > audit-$(date +%F).json

Jeśli polecenie znajdzie luki, kończy się kodem błędu. Jest to zamierzone, ponieważ dzięki temu zautomatyzowany build się przerywa. Każde trafienie proszę ocenić: czy pakiet jest używany na serwerze, czy używana jest dotknięta funkcja, czy istnieje naprawiona wersja?

# Które bezpośrednie zależności są przestarzałe?
composer outdated --direct
# Dlaczego zainstalowano dany pakiet?
composer why vendor/paket
# Aktualizacja celowana, z zależnościami
composer update vendor/paket --with-dependencies

Każdą aktualizację proszę przetestować w środowisku stagingowym. Aktualizacje bezpieczeństwa w obrębie tej samej wersji głównej są zwykle bezproblemowe, nowa wersja główna może natomiast wymagać zmian w kodzie.

Automatyzacja kontroli

Jednorazowe wywołanie niewiele daje, ponieważ nowe luki są stale ujawniane. Proszę więc włączyć composer audit w dwóch miejscach: do pipeline'u buildu przy każdej zmianie oraz do regularnej kontroli stanu produkcyjnego, także gdy w kodzie nic się nie zmienia.

Prosty skrypt do codziennego uruchamiania na serwerze buildów lub kontrolnym może wyglądać tak:

#!/bin/sh
# Codzienny audyt wdrażanego stanu (dostosuj ścieżkę)
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

Komunikat z dziennika systemowego proszę przekazywać do Państwa monitoringu, wewnętrznej skrzynki lub systemu zgłoszeń. Ważne jest, aby ktoś był odpowiedzialny za ocenę komunikatów. Audyt, którego ostrzeżeń nikt nie czyta, nie chroni.

Czyste dostarczanie: wdrożenie bez skutków ubocznych

Także droga na serwer wpływa na bezpieczeństwo. Sprawdziło się kilka podstawowych zasad:

• Dodać composer.lock do repozytorium i na serwerze wykonywać wyłącznie composer install, nigdy composer update.
• Instalować z --no-dev, aby narzędzia testowe i debugowania nie trafiały na serwer produkcyjny.
• Trzymać folder vendor/ poza głównym katalogiem WWW, tak aby nie był bezpośrednio dostępny przez adres URL.
• Uruchamiać composer validate w buildzie, aby wcześnie wykrywać błędne lub sprzeczne dane.

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

Proszę zwracać też uwagę na wsparcie samej wersji PHP. Biblioteki coraz częściej wymagają aktualnych gałęzi PHP. Kto nadal tkwi w PHP 8.1 lub starszym, nie otrzymuje dla samego PHP żadnych oficjalnych aktualizacji i często nie może już instalować nowszych wersji pakietów z poprawkami bezpieczeństwa. Planowanie w tym zakresie opisuje poradnik Koniec wsparcia PHP: ryzyko przestarzałych wersji. Wskazówki specyficzne dla frameworków znajdą Państwo na stronie Zabezpieczanie aplikacji Laravel.

Jak konkretnie pomaga PHP SOS?

• Ustalamy stan wszystkich zależności i oceniamy trafienia według rzeczywistego użycia.
• Wdrażamy zautomatyzowane kontrole w buildzie i w eksploatacji, z jasną odpowiedzialnością za ustalenia.
• Planujemy i testujemy aktualizacje, także gdy nowe wersje główne wymagają dostosowań.
• Na życzenie sprawdzamy także własny kod i konfigurację, tam gdzie nie zagląda żadne automatyczne narzędzie.

Kontrolę przez osoby trzecie opisuje usługa Audyt bezpieczeństwa i test penetracyjny.

Częste pytania

Źródła

• OWASP Top 10
• OWASP Cheat Sheet Series
• php.net: komunikaty o bezpieczeństwie
• php.net: wspierane wersje