Trumpai: composer audit palygina jūsų PHP projekto paketus su žinomais saugumo pranešimais ir parodo paveiktas versijas. Komandą vykdykite su kiekvienu kūrimu ir reguliariai produkcinei būsenai. Svarbu po PHP2Shell: patikra aprėpia bibliotekas, o ne patį PHP interpretatorių.
Kodėl priklausomybėms dabar reikia dėmesio
Šiuolaikinės PHP programos didžiąja dalimi sudarytos iš svetimo kodo. Parduotuvė su Symfony ar portalas su Laravel greitai turi kelias dešimtis ar šimtus paketų, daugelį jų netiesiogiai per kitus paketus. Kiekviena iš šių bibliotekų gali turėti pažeidžiamumą. Todėl OWASP Top 10 pasenusius ir pažeidžiamus komponentus išskiria kaip atskirą rizikos kategoriją.
2026 m. spalį PHP2Shell parodė, kaip greitai kritinis pažeidžiamumas išplinta. Abu pažeidžiamumai, CVE-2026-109618 ir CVE-2026-109619, liečia patį PHP, o ne Composer paketus. Vis dėlto daugelis komandų tomis dienomis peržiūrėjo visą savo grandinę ir pamatė, kad tiksliai nežino savo priklausomybių būsenos.
Šią apžvalgos spragą galima užpildyti nedidelėmis pastangomis. Composer naujesnėse versijose tinkamą įrankį jau turi.
Ką composer audit tikrina ir ko netikrina
Komanda skaito įdiegtus paketus arba lock failą ir užklausia žinomų saugumo pranešimų apie šiuos paketus. Kiekvienam radiniui ji parodo paketą, paveiktų versijų intervalą, sunkumo lygį, pranešimo identifikatorių ir nuorodą į aprašymą.
| Lygmuo | Ar tikrina composer audit? | Kaip tikrinti vietoj to |
|---|---|---|
| Composer paketai projekte | taip | composer audit |
| PHP interpretatorius (pvz., PHP2Shell) | ne | Paketo būsena, hostingo teikėjo patvirtinimas |
| PHP plėtiniai iš sistemos | ne | Distribucijos paketų valdymas |
| JavaScript paketai priekinėje dalyje | ne | Atitinkamos paketų tvarkyklės įrankis |
| Nuosavas programos kodas | ne | Kodo peržiūra, saugumo auditas |
Komanda atsižvelgia ir į netiesiogines priklausomybes, t. y. paketus, kurių patys niekada neprašėte, bet kurie ateina kartu su kitais paketais. Būtent ten pažeidžiamumai dažnai lieka nepastebėti, nes komandoje šių paketų niekas nežino. Naujesnės Composer versijos taip pat nurodo paketus, kuriuos jų autoriai pažymėjo kaip apleistus. Tokie paketai paprastai pataisymų nebegauna ir turėtų būti pakeisti.
Švarus rezultatas todėl reiškia tik tiek, kad įdiegtoms paketų versijoms žinomo pranešimo nėra. Nežinomų pažeidžiamumų ir klaidų savo kode įrankis neranda. Kaip patiems patikrinti PHP būseną, aprašo straipsnis Kaip teisingai patikrinti PHP versiją ir pataisų būseną.
composer audit vykdymas ir rezultatų skaitymas
Projekto kataloge pakanka vienos komandos. Variantai skiriasi tuo, kas tikrinama ir kaip pateikiamas rezultatas.
# Patikrinti įdiegtus paketus
composer audit
# Tikrinti tik lock failą, pvz., kūrime be įdiegtų paketų
composer audit --locked
# Praleisti kūrimo priklausomybes (būsena kaip serveryje)
composer audit --no-dev
# Mašininiu būdu skaitoma išvestis analizei ar užduočių sistemai
composer audit --format=json > audit-$(date +%F).json
Radus pažeidžiamumų, komanda baigiasi klaidos kodu. Tai norima, nes taip automatizuotas kūrimas nutrūksta. Įvertinkite kiekvieną radinį: ar paketas naudojamas serveryje, ar naudojama paveikta funkcija, ar yra ištaisyta versija?
# Kurios tiesioginės priklausomybės pasenusios?
composer outdated --direct
# Kodėl įdiegtas konkretus paketas?
composer why vendor/paket
# Atnaujinti tikslingai, su priklausomybėmis
composer update vendor/paket --with-dependencies
Kiekvieną atnaujinimą išbandykite staging aplinkoje. Saugumo atnaujinimai tos pačios pagrindinės versijos viduje dažniausiai nekelia problemų, o nauja pagrindinė versija gali reikalauti kodo pakeitimų.
Patikros automatizavimas
Vienkartinis iškvietimas padeda mažai, nes nauji pažeidžiamumai skelbiami nuolat. Todėl composer audit integruokite dviejose vietose: į kūrimo procesą (pipeline) su kiekvienu pakeitimu ir į reguliarią produkcinės būsenos patikrą, net jei kodas nesikeičia.
Paprastas skriptas kasdieniam paleidimui kūrimo ar patikros serveryje gali atrodyti taip:
#!/bin/sh
# Kasdienis pateiktos būsenos auditas (pritaikykite kelią)
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
Pranešimą iš sistemos žurnalo nukreipkite į savo stebėseną, vidinį pašto adresą ar užduočių sistemą. Svarbu, kad kas nors būtų atsakingas už pranešimų vertinimą. Auditas, kurio įspėjimų niekas neskaito, neapsaugo.
composer.json skiltyje config.platform.php nurodykite serveryje veikiančią PHP versiją. Tuomet Composer parenka tik šiai būsenai tinkančius paketus, o composer check-platform-reqs parodo neatitikimus.
Tvarkingas pateikimas: diegimas be šalutinių poveikių
Ir kelias į serverį veikia saugumą. Pasiteisino kelios pagrindinės taisyklės:
composer.lockįtraukti į saugyklą, o serveryje vykdyti tikcomposer install, niekadacomposer update.- Diegti su
--no-dev, kad testavimo ir derinimo įrankiai nepatektų į produkcinį serverį. - Aplanką
vendor/laikyti už žiniatinklio šakninio katalogo, kad jis nebūtų tiesiogiai pasiekiamas per URL. - Kūrime vykdyti
composer validate, kad klaidingi ar prieštaringi įrašai būtų pastebėti anksti.
composer validate --strict
composer install --no-dev --prefer-dist --classmap-authoritative --no-interaction
Atkreipkite dėmesį ir į paties PHP palaikymą. Bibliotekos vis dažniau reikalauja naujų PHP šakų. Kas dar laikosi PHP 8.1 ar senesnėje versijoje, patiems PHP oficialių atnaujinimų nebegauna ir naujesnių paketų versijų su saugumo pataisymais dažnai nebegali įdiegti. Planavimą aprašo vadovas PHP End of Life: pasenusių versijų rizika. Karkasui būdingus patarimus rasite puslapyje Laravel programų apsauga.
Kaip PHP SOS padeda konkrečiai?
- Užfiksuojame visų priklausomybių būseną ir radinius vertiname pagal faktinį naudojimą.
- Kūrime ir veikloje įrengiame automatizuotas patikras su aiškia atsakomybe už radinius.
- Atnaujinimus planuojame ir išbandome, net kai naujos pagrindinės versijos reikalauja pakeitimų.
- Pageidaujant tikriname ir nuosavą kodą bei konfigūraciją ten, kur automatinis įrankis nežiūri.
Trečiųjų šalių patikrą aprėpia paslauga Saugumo auditas ir skverbties testas.
Dažni klausimai
Ar composer audit randa ir PHP2Shell?
Ne. composer audit tikrina jūsų projekto paketus, o ne serveryje veikiantį PHP interpretatorių. PHP2Shell glūdi pačiame PHP ir ištaisomas tik atnaujinus PHP bei iš naujo paleidus visus PHP procesus.
Ar composer.lock turi būti saugykloje?
Programoms taip. Lock failas užfiksuoja, kurios versijos tiksliai įdiegtos. Tik taip composer audit tikrina būseną, kuri iš tikrųjų veikia serveryje, o kiekvienas diegimas įdiegia tas pačias versijas.
Ką daryti, jei paveiktam paketui atnaujinimo nėra?
Patikrinkite, ar jūsų projektas apskritai naudoja paveiktą funkciją, ir dokumentuokite vertinimą. Jei pataisos nėra, galima apsvarstyti pakaitinį paketą, savo pataisą arba laikiną apsaugą serverio lygiu.
Kaip dažnai turėčiau vykdyti composer audit?
Su kiekvienu kūrimu (build) ir papildomai reguliariai, pavyzdžiui, kasdien, net be kodo pakeitimų. Nauji pažeidžiamumai skelbiami nuolat, o vakar švari būsena šiandien gali būti paveikta.