# composer audit: provjera ovisnosti na ranjivosti

> Uz composer audit provjerite PHP ovisnosti na ranjivosti. Naredbe, ugradnja u CI i deployment te zašto se sam PHP zakrpava zasebno.

Izvor: https://phpsos.de/hr/ratgeber/composer-abhaengigkeiten-pruefen/  
Stanje: 25.10.2026  
Pružatelj: PHP SOS, PHP hitna pomoć i sigurnost poslužitelja. Hitna pomoć putem WhatsAppa: https://wa.me/491736494914?text=Pozdrav%20PHP%20SOS%2C%20trebamo%20pomo%C4%87%20s%20na%C5%A1im%20PHP%20poslu%C5%BEiteljem.%20Tvrtka%3A%20%E2%80%A6%20Web-stranica%3A%20%E2%80%A6

**Ukratko:** `composer audit` uspoređuje pakete Vašeg PHP projekta s poznatim sigurnosnim objavama i prikazuje pogođene verzije. Naredbu izvršavajte pri svakom buildu i redovito na produkcijskom stanju. Važno nakon PHP2Shella: provjera obuhvaća biblioteke, a ne sam PHP interpreter.

## Zašto ovisnosti upravo sada trebaju pozornost

Moderne PHP aplikacije većim dijelom čini tuđi kod. Shop na osnovi Symfonyja ili portal s Laravelom brzo donosi nekoliko desetaka do stotine paketa, mnoge neizravno preko drugih paketa. Svaka od tih biblioteka može sadržavati ranjivost. OWASP Top 10 zato zastarjele i ranjive komponente vode kao zasebnu kategoriju rizika.

U listopadu 2026. PHP2Shell je pokazao koliko se brzo kritična ranjivost proširi. Dvije ranjivosti CVE-2026-109618 i CVE-2026-109619 doduše pogađaju sam PHP, a ne Composer pakete. No mnogi su timovi tih dana provjerili cijeli svoj lanac i pritom utvrdili da stanje svojih ovisnosti uopće ne poznaju točno.

Tu prazninu u pregledu moguće je zatvoriti uz malo truda. Composer u aktualnim verzijama već donosi odgovarajući alat.

## Što composer audit provjerava, a što ne

Naredba čita instalirane pakete ili lock datoteku i traži poznate sigurnosne objave za te pakete. Za svaki pogodak prikazuje paket, pogođeni raspon verzija, razinu težine, oznaku objave i poveznicu na opis.

| Razina | Provjerava li composer audit? | Kako umjesto toga provjeriti |
|---|---|---|
| Composer paketi u projektu | da | composer audit |
| PHP interpreter (npr. PHP2Shell) | ne | Stanje paketa, potvrda pružatelja hostinga |
| PHP ekstenzije iz sustava | ne | Upravljanje paketima distribucije |
| JavaScript paketi u frontendu | ne | Alat odgovarajućeg upravitelja paketa |
| Vlastiti aplikacijski kod | ne | Pregled koda, sigurnosni audit |

Naredba uzima u obzir i neizravne ovisnosti, dakle pakete koje nikad niste sami zatražili, ali dolaze preko drugih paketa. Upravo se tamo ranjivosti često kriju neprimijećene jer te pakete nitko u timu ne poznaje. Novije verzije Composera upozoravaju i na pakete koje su njihovi autori označili kao napuštene. Takvi paketi u pravilu više ne dobivaju ispravke i trebalo bi ih zamijeniti.

Čist rezultat stoga znači samo da za instalirane verzije paketa nema poznate objave. Nepoznate ranjivosti i pogreške u vlastitom kodu alat ne pronalazi. Kako sami provjeriti stanje PHP-a, opisuje članak [Ispravna provjera verzije PHP-a i razine zakrpe](https://phpsos.de/hr/php2shell/php-version-pruefen/).

## Izvršavanje composer audit i čitanje rezultata

U direktoriju projekta dovoljna je jedna naredba. Varijante se razlikuju u onome što se provjerava i kako se rezultat ispisuje.

```bash
# Provjeriti instalirane pakete
composer audit

# Provjeriti samo lock datoteku, npr. u buildu bez instaliranih paketa
composer audit --locked

# Izostaviti razvojne ovisnosti (stanje kao na poslužitelju)
composer audit --no-dev

# Strojno čitljiv ispis za analizu ili sustav tiketa
composer audit --format=json > audit-$(date +%F).json
```

Ako naredba pronađe ranjivosti, završava s kodom pogreške. To je namjerno jer tako automatizirani build prekida rad. Procijenite svaki pogodak: je li paket u uporabi na poslužitelju, koristi li se pogođena funkcija, postoji li ispravljena verzija?

```bash
# Koje su izravne ovisnosti zastarjele?
composer outdated --direct
# Zašto je određeni paket instaliran?
composer why vendor/paket
# Ciljano ažurirati, s ovisnostima
composer update vendor/paket --with-dependencies
```

Svako ažuriranje testirajte u staging okruženju. Sigurnosna ažuriranja unutar iste glavne verzije obično su nekritična, dok nova glavna verzija može zahtijevati prilagodbe koda.

## Automatizacija provjere

Jednokratni poziv malo pomaže jer se nove ranjivosti stalno otkrivaju. Zato `composer audit` ugradite na dva mjesta: u build pipeline pri svakoj promjeni i u redovitu provjeru produkcijskog stanja, čak i kad se kod ne mijenja.

Jednostavna skripta za dnevno izvršavanje na build ili poslužitelju za provjeru može izgledati ovako:

```bash
#!/bin/sh
# Dnevni audit isporučenog stanja (prilagodite putanju)
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
```

Poruku iz sistemskog zapisa proslijedite svom nadzoru, internom poštanskom sandučiću ili sustavu tiketa. Važno je da je netko odgovoran za procjenu poruka. Audit čija upozorenja nitko ne čita ne štiti.

> **Savjet:**
> U `composer.json` pod `config.platform.php` odredite verziju PHP-a koja radi na poslužitelju. Tada Composer razrješava samo pakete koji odgovaraju tom stanju, a `composer check-platform-reqs` prikazuje odstupanja.

## Uredna isporuka: deployment bez nuspojava

I put do poslužitelja utječe na sigurnost. Nekoliko osnovnih pravila se pokazalo dobrim:

- `composer.lock` uključiti u repozitorij, a na poslužitelju izvršavati samo `composer install`, nikad `composer update`.
- Instalirati s `--no-dev` kako alati za testiranje i otklanjanje pogrešaka ne bi završili na produkcijskom poslužitelju.
- Mapu `vendor/` držati izvan korijenskog direktorija weba kako ne bi bila izravno dostupna putem URL-a.
- U buildu izvršiti `composer validate` radi ranog otkrivanja pogrešnih ili proturječnih podataka.

```bash
composer validate --strict
composer install --no-dev --prefer-dist --classmap-authoritative --no-interaction
```

Obratite pozornost i na podršku same verzije PHP-a. Biblioteke sve češće zahtijevaju aktualne PHP grane. Tko još zapinje na PHP-u 8.1 ili starijem, za sam PHP više ne dobiva službena ažuriranja i novije verzije paketa sa sigurnosnim ispravcima često više ne može instalirati. Planiranje za to opisuje vodič [PHP End of Life: rizici zastarjelih verzija](https://phpsos.de/hr/ratgeber/php-end-of-life-risiken/). Napomene specifične za framework nalaze se na stranici [Zaštita Laravel aplikacija](https://phpsos.de/hr/plattformen/laravel/).

## Kako PHP SOS konkretno pomaže?

- Bilježimo stanje svih ovisnosti i pogotke ocjenjujemo prema stvarnoj uporabi.
- Postavljamo automatizirane provjere u buildu i radu, s jasnom odgovornošću za nalaze.
- Planiramo i testiramo ažuriranja, i kad nove glavne verzije zahtijevaju prilagodbe.
- Na željeno provjeravamo i vlastiti kod i konfiguraciju, gdje nijedan automatski alat ne gleda.

Provjeru od strane trećih opisuje usluga [Sigurnosni audit i penetracijski test](https://phpsos.de/hr/leistungen/sicherheitsaudit-penetrationstest/).


## Česta pitanja

**Pronalazi li composer audit i PHP2Shell?**  
Ne. composer audit provjerava pakete u Vašem projektu, a ne PHP interpreter na poslužitelju. PHP2Shell je u samom PHP-u i otklanja se samo ažuriranjem PHP-a i ponovnim pokretanjem svih PHP procesa.

**Mora li composer.lock u repozitorij?**  
Kod aplikacija da. Lock datoteka bilježi koje su točno verzije instalirane. Samo tako composer audit provjerava stanje koje zaista radi na poslužitelju, a svaki deployment instalira iste verzije.

**Što učiniti ako za pogođeni paket ne postoji ažuriranje?**  
Provjerite koristi li Vaš projekt pogođenu funkciju uopće i dokumentirajte procjenu. Ako nema ispravka, u obzir dolaze zamjenski paket, vlastita zakrpa ili privremena zaštita na razini poslužitelja.

**Koliko često trebam izvršavati composer audit?**  
Pri svakom buildu i dodatno redovito, primjerice svakodnevno, i bez promjene koda. Nove se ranjivosti prijavljuju stalno, a stanje koje je jučer bilo čisto danas može biti pogođeno.

## Izvori

- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
- [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)
- [php.net: sigurnosne objave](https://www.php.net/)
- [php.net: podržane verzije](https://www.php.net/supported-versions.php)
