Īsi: composer audit salīdzina jūsu PHP projekta paketes ar zināmiem drošības ziņojumiem un parāda skartās versijas. Palaidiet komandu katrā būvējumā un regulāri produkcijas stāvoklim. Svarīgi pēc PHP2Shell: pārbaude aptver bibliotēkas, nevis pašu PHP interpretatoru.
Kāpēc atkarībām tieši tagad vajadzīga uzmanība
Mūsdienu PHP lietojumprogrammas lielākoties sastāv no svešā koda. Veikals uz Symfony bāzes vai portāls ar Laravel ātri ienes vairākas desmitus līdz simtiem pakotņu, daudzas no tām netieši caur citām pakotnēm. Katra no šīm bibliotēkām var saturēt ievainojamību. Tāpēc OWASP Top 10 novecojušas un ievainojamas komponentes min kā atsevišķu riska kategoriju.
- gada oktobrī PHP2Shell parādīja, cik ātri kritiska ievainojamība izplatās plašumā. Abas ievainojamības CVE-2026-109618 un CVE-2026-109619 gan skar pašu PHP, nevis Composer paketes. Taču daudzas komandas šajās dienās pārbaudīja visu savu ķēdi un konstatēja, ka precīzi nepazīst savu atkarību stāvokli.
Šo robu pārskatā var aizvērt ar nelielu piepūli. Composer aktuālajās versijās piemērotu rīku jau satur.
Ko composer audit pārbauda un ko ne
Komanda nolasa uzstādītās paketes vai lock failu un pieprasa zināmos drošības ziņojumus par šīm pakotnēm. Katram atradumam tā parāda pakotni, skarto versiju diapazonu, nopietnības pakāpi, ziņojuma identifikatoru un saiti uz aprakstu.
| Līmenis | Vai composer audit pārbauda? | Kā pārbaudīt citādi |
|---|---|---|
| Composer paketes projektā | jā | composer audit |
| PHP interpretators (piem., PHP2Shell) | nē | pakotnes stāvoklis, hostinga sniedzēja apstiprinājums |
| PHP paplašinājumi no sistēmas | nē | distribūcijas pakotņu pārvaldība |
| JavaScript paketes priekšpusē | nē | attiecīgā pakotņu pārvaldnieka rīks |
| Pašu lietojumprogrammas kods | nē | koda pārskats, drošības audits |
Komanda ņem vērā arī netiešās atkarības, tātad pakotnes, ko paši nekad neesat pieprasījuši, bet kas nāk līdzi caur citām pakotnēm. Tieši tur ievainojamības bieži paliek nepamanītas, jo komandā šīs pakotnes neviens nepazīst. Jaunākās Composer versijas turklāt norāda uz pakotnēm, ko autori ir atzīmējuši kā pamestas. Šādas pakotnes parasti vairs nesaņem labojumus, un tās jāaizstāj.
Tīrs rezultāts tātad nozīmē tikai to, ka uzstādītajām pakotņu versijām nav zināma ziņojuma. Nezināmas ievainojamības un kļūdas pašu kodā rīks neatrod. Kā paši pārbaudīt PHP stāvokli, apraksta raksts PHP versijas un ielāpa stāvokļa pareiza pārbaude.
composer audit palaišana un rezultātu lasīšana
Projekta direktorijā pietiek ar vienu komandu. Varianti atšķiras ar to, kas tiek pārbaudīts un kā rezultāts tiek izvadīts.
# Pārbaudīt uzstādītās paketes
composer audit
# Pārbaudīt tikai lock failu, piem., būvējumā bez uzstādītām pakotnēm
composer audit --locked
# Izlaist izstrādes atkarības (stāvoklis kā serverī)
composer audit --no-dev
# Mašīnlasāma izvade izvērtēšanai vai biļešu sistēmai
composer audit --format=json > audit-$(date +%F).json
Ja komanda atrod ievainojamības, tā beidzas ar kļūdas kodu. Tas ir vēlams, jo tā automatizēts būvējums tiek pārtraukts. Izvērtējiet katru atradumu: vai pakotne serverī tiek lietota, vai skartā funkcija tiek izmantota, vai ir izlabota versija?
# Kuras tiešās atkarības ir novecojušas?
composer outdated --direct
# Kāpēc konkrēta pakotne ir uzstādīta?
composer why vendor/paket
# Mērķtiecīgi atjaunināt, ar atkarībām
composer update vendor/paket --with-dependencies
Katru atjauninājumu pārbaudiet starpposma (staging) vidē. Drošības atjauninājumi vienas galvenās versijas ietvaros parasti nav kritiski, jauna galvenā versija turpretī var prasīt koda pielāgojumus.
Pārbaudes automatizēšana
Vienreizējs izsaukums palīdz maz, jo jaunas ievainojamības kļūst zināmas nepārtraukti. Tāpēc iekļaujiet composer audit divās vietās: būvēšanas konveijerā pie katras izmaiņas un regulārā produkcijas stāvokļa pārbaudē, arī ja kods nemainās.
Vienkāršs skripts ikdienas palaišanai būvēšanas vai pārbaudes serverī var izskatīties šādi:
#!/bin/sh
# Piegādātā stāvokļa ikdienas audits (pielāgojiet ceļu)
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
Ziņojumu no sistēmas žurnāla pārsūtiet uz savu uzraudzību, iekšējo pastkasti vai biļešu sistēmu. Svarīgi, lai kāds būtu atbildīgs par ziņojumu izvērtēšanu. Audits, kura brīdinājumus neviens nelasa, neaizsargā.
Failā composer.json sadaļā config.platform.php nofiksējiet PHP versiju, kas darbojas serverī. Tad Composer atrisina tikai pakotnes, kas atbilst šim stāvoklim, un composer check-platform-reqs parāda atšķirības.
Tīra piegāde: izvietošana bez blakusefektiem
Arī ceļš uz serveri ietekmē drošību. Ir noderējuši daži pamatnoteikumi:
composer.lockiekļaut repozitorijā un serverī izpildīt tikaicomposer install, nekadcomposer update.- Instalēt ar
--no-dev, lai testēšanas un atkļūdošanas rīki nenonāktu produkcijas serverī. - Mapi
vendor/turēt ārpus tīmekļa saknes direktorija, lai tā nebūtu tieši pieejama caur URL. - Būvējumā izpildīt
composer validate, lai agrīni atklātu kļūdainus vai pretrunīgus datus.
composer validate --strict
composer install --no-dev --prefer-dist --classmap-authoritative --no-interaction
Ņemiet vērā arī pašas PHP versijas atbalstu. Bibliotēkas arvien biežāk prasa aktuālus PHP atzarus. Kas joprojām ir iestrēdzis uz PHP 8.1 vai vecākas, pašam PHP oficiālus atjauninājumus vairs nesaņem un jaunākās pakotņu versijas ar drošības labojumiem bieži vairs nevar uzstādīt. Plānošanu apraksta ceļvedis PHP End of Life: novecojušu versiju riski. Ietvariem specifiskas norādes atradīsiet rakstā Laravel lietojumprogrammu nostiprināšana.
Kā PHP SOS palīdz konkrēti?
- Apzinām visu atkarību stāvokli un vērtējam atradumus pēc faktiskās lietošanas.
- Ierīkojam automatizētas pārbaudes būvēšanā un ekspluatācijā ar skaidru atbildību par atradumiem.
- Plānojam un pārbaudām atjauninājumus, arī ja jaunas galvenās versijas prasa pielāgojumus.
- Pēc vēlēšanās pārbaudām arī savu kodu un konfigurāciju, kur automātisks rīks neskatās.
Trešās puses veiktu pārbaudi apraksta pakalpojums Drošības audits un penetrācijas tests.
Biežāk uzdotie jautājumi
Vai composer audit atrod arī PHP2Shell?
Nē. composer audit pārbauda paketes jūsu projektā, nevis PHP interpretatoru serverī. PHP2Shell ir pašā PHP, un to novērš tikai PHP atjauninājums un visu PHP procesu pārstartēšana.
Vai composer.lock jāliek repozitorijā?
Lietojumprogrammām jā. Lock fails fiksē, kuras versijas tieši ir uzstādītas. Tikai tā composer audit pārbauda stāvokli, kas patiešām darbojas serverī, un katra izvietošana uzstāda tās pašas versijas.
Ko darīt, ja skartajai pakotnei nav atjauninājuma?
Pārbaudiet, vai jūsu projekts vispār izmanto skarto funkciju, un dokumentējiet vērtējumu. Ja labojuma nav, var apsvērt aizstājējpakotni, savu ielāpu vai pagaidu aizsardzību servera līmenī.
Cik bieži jāpalaiž composer audit?
Katrā būvējumā un papildus regulāri, piemēram, katru dienu, arī bez koda izmaiņām. Jaunas ievainojamības tiek ziņotas nepārtraukti, un stāvoklis, kas vakar bija tīrs, šodien var būt skarts.