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

> Za pomocą composer audit sprawdzą Państwo luki w zależnościach PHP. Polecenia, włączenie do CI i wdrożenia oraz dlaczego samo PHP trzeba łatać osobno.

Źródło: https://phpsos.de/pl/ratgeber/composer-abhaengigkeiten-pruefen/  
Stan: 25.10.2026  
Dostawca: PHP SOS, Pomoc awaryjna PHP i bezpieczeństwo serwerów. Natychmiastowa pomoc przez WhatsApp: https://wa.me/491736494914?text=Dzie%C5%84%20dobry%2C%20PHP%20SOS%2C%20potrzebujemy%20pomocy%20z%20naszym%20serwerem%20PHP.%20Firma%3A%20%E2%80%A6%20Strona%20internetowa%3A%20%E2%80%A6

**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.

| Poziom | Sprawdzane przez composer audit? | Jak sprawdzać zamiast tego |
|---|---|---|
| Pakiety Composera w projekcie | tak | composer audit |
| Interpreter PHP (np. PHP2Shell) | nie | stan pakietu, potwierdzenie hostingu |
| Rozszerzenia PHP z systemu | nie | menedżer pakietów dystrybucji |
| Pakiety JavaScript we frontendzie | nie | narzędzie właściwego menedżera pakietów |
| Własny kod aplikacji | nie | przegląd kodu, audyt bezpieczeństwa |

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](https://phpsos.de/pl/php2shell/php-version-pruefen/).

## 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.

```bash
# 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?

```bash
# 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:

```bash
#!/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.

> **Wskazówka:**
> Proszę ustawić w `composer.json` w `config.platform.php` wersję PHP, która działa na serwerze. Wtedy Composer rozwiązuje tylko pakiety pasujące do tego stanu, a `composer check-platform-reqs` pokazuje odchylenia.

## 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.

```bash
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](https://phpsos.de/pl/ratgeber/php-end-of-life-risiken/). Wskazówki specyficzne dla frameworków znajdą Państwo na stronie [Zabezpieczanie aplikacji Laravel](https://phpsos.de/pl/plattformen/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](https://phpsos.de/pl/leistungen/sicherheitsaudit-penetrationstest/).


## Częste pytania

**Czy composer audit znajdzie także PHP2Shell?**  
Nie. composer audit sprawdza pakiety w Państwa projekcie, a nie interpreter PHP na serwerze. PHP2Shell tkwi w samym PHP i usuwa się je wyłącznie aktualizacją PHP oraz restartem wszystkich procesów PHP.

**Czy composer.lock musi trafić do repozytorium?**  
W przypadku aplikacji tak. Plik lock określa, jakie dokładnie wersje są zainstalowane. Tylko wtedy composer audit sprawdza stan faktycznie działający na serwerze, a każde wdrożenie instaluje te same wersje.

**Co zrobić, jeśli dla dotkniętego pakietu nie istnieje aktualizacja?**  
Proszę sprawdzić, czy projekt w ogóle używa dotkniętej funkcji, i udokumentować ocenę. Jeśli nie ma poprawki, wchodzą w grę pakiet zastępczy, własna łatka lub tymczasowe zabezpieczenie na poziomie serwera.

**Jak często powinienem uruchamiać composer audit?**  
Przy każdym buildzie, a dodatkowo regularnie, na przykład codziennie, także bez zmian w kodzie. Nowe luki są zgłaszane stale, a stan, który wczoraj był czysty, dziś może być dotknięty.

## Źródła

- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
- [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)
- [php.net: komunikaty o bezpieczeństwie](https://www.php.net/)
- [php.net: wspierane wersje](https://www.php.net/supported-versions.php)