composer audit: provjera ovisnosti na ranjivosti

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.

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.

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.

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

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

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

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.

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. Napomene specifične za framework nalaze se na stranici Zaštita Laravel aplikacija.

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.

Česta pitanja

Izvori

• OWASP Top 10
• OWASP Cheat Sheet Series
• php.net: sigurnosne objave
• php.net: podržane verzije