# composer audit: preverjanje odvisnosti na ranljivosti

> Z composer audit preverite odvisnosti PHP na ranljivosti. Ukazi, vključitev v CI in deployment ter zakaj je treba PHP sam popravljati ločeno.

Vir: https://phpsos.de/sl/ratgeber/composer-abhaengigkeiten-pruefen/  
Stanje: 25.10.2026  
Ponudnik: PHP SOS, Nujna pomoč za PHP in varnost strežnikov. Takojšnja pomoč po WhatsAppu: https://wa.me/491736494914?text=Pozdravljeni%2C%20PHP%20SOS%2C%20potrebujemo%20pomo%C4%8D%20z%20na%C5%A1im%20stre%C5%BEnikom%20PHP.%20Podjetje%3A%20%E2%80%A6%20Spletna%20stran%3A%20%E2%80%A6

**Na kratko:** `composer audit` pakete vašega projekta PHP primerja z znanimi varnostnimi obvestili in pokaže prizadete različice. Ukaz izvajajte ob vsaki gradnji in redno na produkcijskem stanju. Pomembno po PHP2Shell: preverjanje zajame knjižnice, ne pa samega interpreterja PHP.

## Zakaj odvisnosti zdaj potrebujejo pozornost

Sodobne aplikacije PHP so večinoma sestavljene iz tuje kode. Trgovina na osnovi Symfonyja ali portal z Laravelom hitro prinese več deset do sto paketov, mnoge posredno prek drugih paketov. Vsaka od teh knjižnic lahko vsebuje ranljivost. OWASP Top 10 zato zastarele in ranljive komponente navaja kot lastno kategorijo tveganja.

Oktobra 2026 je PHP2Shell pokazal, kako hitro se kritična ranljivost razširi. Ranljivosti CVE-2026-109618 in CVE-2026-109619 sicer zadevata sam PHP, ne paketov Composer. Številne ekipe pa so te dni preverile celotno verigo in ugotovile, da stanja svojih odvisnosti sploh ne poznajo natančno.

To vrzel v pregledu je mogoče zapreti z majhnim naporom. Composer v aktualnih različicah ustrezno orodje že vključuje.

## Kaj composer audit preveri in česa ne

Ukaz prebere nameščene pakete ali datoteko lock in poizveduje po znanih varnostnih obvestilih za te pakete. Za vsak zadetek prikaže paket, prizadeto območje različic, stopnjo resnosti, oznako obvestila in povezavo na opis.

| Raven | Ali composer audit preveri? | Kako preveriti drugače |
|---|---|---|
| Paketi Composer v projektu | da | composer audit |
| Interpreter PHP (npr. PHP2Shell) | ne | Stanje paketa, potrditev ponudnika gostovanja |
| Razširitve PHP iz sistema | ne | Upravljanje paketov distribucije |
| Paketi JavaScript v čelnem delu | ne | Orodje ustreznega upravljalnika paketov |
| Lastna koda aplikacije | ne | Pregled kode, varnostni pregled |

Ukaz upošteva tudi posredne odvisnosti, torej pakete, ki jih sami nikoli niste zahtevali, a pridejo zraven prek drugih paketov. Prav tam se ranljivosti pogosto skrivajo neopazno, ker teh paketov v ekipi nihče ne pozna. Novejše različice Composerja opozarjajo tudi na pakete, ki so jih avtorji označili kot opuščene. Takšni paketi praviloma ne prejemajo več popravkov in jih je treba zamenjati.

Čist rezultat torej pomeni samo, da za nameščene različice paketov ni znanega obvestila. Neznanih ranljivosti in napak v lastni kodi orodje ne najde. Kako sami preverite stanje PHP, opisuje prispevek [Pravilno preverjanje različice PHP in stanja popravkov](https://phpsos.de/sl/php2shell/php-version-pruefen/).

## Izvedba composer audit in branje rezultatov

V projektni mapi zadošča en ukaz. Različice se razlikujejo po tem, kaj se preverja in kako je rezultat izpisan.

```bash
# Preverite nameščene pakete
composer audit

# Preverite samo datoteko lock, npr. pri gradnji brez nameščenih paketov
composer audit --locked

# Izpustite razvojne odvisnosti (stanje kot na strežniku)
composer audit --no-dev

# Strojno berljiv izpis za obdelavo ali sistem prijav
composer audit --format=json > audit-$(date +%F).json
```

Če ukaz najde ranljivosti, se konča s kodo napake. To je zaželeno, saj samodejna gradnja tako prekine. Ocenite vsak zadetek: je paket na strežniku v uporabi, se prizadeta funkcija uporablja, ali obstaja odpravljena različica?

```bash
# Katere neposredne odvisnosti so zastarele?
composer outdated --direct
# Zakaj je določen paket nameščen?
composer why vendor/paket
# Ciljna posodobitev, z odvisnostmi
composer update vendor/paket --with-dependencies
```

Vsako posodobitev preizkusite v okolju staging. Varnostne posodobitve znotraj iste glavne različice so praviloma nekritične, nova glavna različica pa lahko zahteva prilagoditve kode.

## Avtomatizirajte preverjanje

Enkraten klic malo pomaga, saj nove ranljivosti postajajo znane sproti. `composer audit` zato vključite na dveh mestih: v cevovod gradnje ob vsaki spremembi in v redno preverjanje produkcijskega stanja, tudi če se koda ne spremeni.

Preprosta skripta za dnevni zagon na strežniku za gradnjo ali preverjanje je lahko takšna:

```bash
#!/bin/sh
# Dnevni audit dostavljenega stanja (pot prilagodite)
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
```

Sporočilo iz sistemskega dnevnika posredujte svojemu nadzoru, internemu nabiralniku ali sistemu prijav. Pomembno je, da je nekdo odgovoren za oceno sporočil. Audit, katerega opozoril nihče ne prebere, ne ščiti.

> **Nasvet:**
> V `composer.json` pod `config.platform.php` določite različico PHP, ki teče na strežniku. Composer tedaj razrešuje samo pakete, ki ustrezajo temu stanju, `composer check-platform-reqs` pa pokaže odstopanja.

## Čista dostava: deployment brez stranskih učinkov

Tudi pot na strežnik vpliva na varnost. Obnesla so se nekatera osnovna pravila:

- `composer.lock` vključite v repozitorij in na strežniku izvajajte samo `composer install`, nikoli `composer update`.
- Namestite z `--no-dev`, da orodja za preizkušanje in odpravljanje napak ne pristanejo na produkcijskem strežniku.
- Mapo `vendor/` hranite zunaj korenskega imenika spleta, da ni neposredno dosegljiva prek URL.
- `composer validate` izvedite pri gradnji, da napačne ali nasprotujoče si podatke prepoznate zgodaj.

```bash
composer validate --strict
composer install --no-dev --prefer-dist --classmap-authoritative --no-interaction
```

Bodite pozorni tudi na podporo same različice PHP. Knjižnice vse pogosteje predpostavljajo aktualne veje PHP. Kdor je še na PHP 8.1 ali starejšem, za PHP samega ne prejema več uradnih posodobitev in novejših različic paketov z varnostnimi popravki pogosto ne more več namestiti. Načrtovanje opisuje vodnik [PHP End of Life: tveganja zastarelih različic](https://phpsos.de/sl/ratgeber/php-end-of-life-risiken/). Napotke za posamezna ogrodja najdete na strani [Zaščita aplikacij Laravel](https://phpsos.de/sl/plattformen/laravel/).

## Kako PHP SOS pomaga konkretno?

- Zajamemo stanje vseh odvisnosti in zadetke ocenimo glede na dejansko uporabo.
- Vzpostavimo samodejna preverjanja pri gradnji in v delovanju, z jasno odgovornostjo za ugotovitve.
- Posodobitve načrtujemo in preizkušamo, tudi kadar nove glavne različice zahtevajo prilagoditve.
- Na željo preverimo tudi lastno kodo in konfiguracijo, kamor nobeno samodejno orodje ne pogleda.

Preverjanje s strani tretjih oseb opisuje storitev [Varnostni pregled in penetracijski test](https://phpsos.de/sl/leistungen/sicherheitsaudit-penetrationstest/).


## Pogosta vprašanja

**Ali composer audit najde tudi PHP2Shell?**  
Ne. composer audit preverja pakete v vašem projektu, ne interpreterja PHP na strežniku. PHP2Shell je v samem PHP in ga odpravita samo posodobitev PHP in ponovni zagon vseh procesov PHP.

**Ali mora biti composer.lock v repozitoriju?**  
Pri aplikacijah da. Datoteka lock določa, katere različice so natančno nameščene. Samo tako composer audit preveri stanje, ki dejansko teče na strežniku, vsak deployment pa namesti iste različice.

**Kaj storiti, če za prizadeti paket posodobitev ne obstaja?**  
Preverite, ali vaš projekt prizadeto funkcijo sploh uporablja, in oceno dokumentirajte. Če popravka ni, pridejo v poštev nadomestni paket, lasten popravek ali začasna zaščita na ravni strežnika.

**Kako pogosto naj izvajam composer audit?**  
Ob vsaki gradnji in poleg tega redno, na primer dnevno, tudi brez spremembe kode. Nove ranljivosti se objavljajo sproti, stanje, ki je bilo včeraj čisto, je lahko danes prizadeto.

## Viri

- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
- [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)
- [php.net: varnostna obvestila](https://www.php.net/)
- [php.net: podprte različice](https://www.php.net/supported-versions.php)
