composer audit: sõltuvuste kontroll turvaaukude suhtes

Lühidalt: composer audit võrdleb teie PHP projekti pakette teadaolevate turvateadetega ja näitab mõjutatud versioone. Käivitage käsk igal ehitusel ja regulaarselt tootmisseisu peal. Oluline pärast PHP2Shelli: kontroll hõlmab teeke, mitte PHP interpretaatorit ennast.

Miks sõltuvused vajavad just praegu tähelepanu

Kaasaegsed PHP rakendused koosnevad suures osas võõrast koodist. Symfony-põhine pood või Laravelil portaal toob endaga kiiresti kaasa mitukümmend kuni sadu pakette, paljud neist kaudselt teiste pakettide kaudu. Iga selline teek võib sisaldada turvaauku. OWASP Top 10 loetleb vananenud ja haavatavad komponendid seetõttu eraldi riskikategooriana.

2026. aasta oktoobris näitas PHP2Shell, kui kiiresti kriitiline turvaauk laiali läheb. Kaks turvaauku CVE-2026-109618 ja CVE-2026-109619 puudutavad küll PHP-d ennast, mitte Composeri pakette. Paljud meeskonnad on neil päevil siiski kogu oma ahela üle kontrollinud ja avastanud, et ei tea oma sõltuvuste seisu üldse täpselt.

Selle ülevaate lünga saab väikese vaevaga sulgeda. Composer toob sobiva tööriista värskemates versioonides juba kaasa.

Mida composer audit kontrollib ja mida mitte

Käsk loeb paigaldatud pakette või lukufaili ja pärib nende pakettide kohta teadaolevaid turvateateid. Iga tabamuse kohta näitab see paketti, mõjutatud versioonivahemikku, raskusastet, teate tunnust ja linki kirjeldusele.

Käsk arvestab ka kaudseid sõltuvusi, see tähendab pakette, mida te kunagi ise ei küsinud, kuid mis tulevad teiste pakettidega kaasa. Just seal peituvad turvaaugud sageli märkamatult, sest keegi meeskonnas neid pakette ei tunne. Uuemad Composeri versioonid juhivad lisaks tähelepanu pakettidele, mille autorid on need hüljatuks märkinud. Sellised paketid üldjuhul enam parandusi ei saa ja need tuleks asendada.

Puhas tulemus tähendab seega ainult seda, et paigaldatud paketiversioonide kohta ei ole teadaolevat teadet. Tundmatuid turvaauke ja vigu oma koodis tööriist ei leia. Kuidas PHP seisu ise kontrollida, kirjeldab artikkel PHP versiooni ja paigaseisu õige kontrollimine.

composer audit käivitamine ja tulemuste lugemine

Projektikataloogis piisab ühest käsust. Variandid erinevad selle poolest, mida kontrollitakse ja kuidas tulemus väljastatakse.

# Paigaldatud pakettide kontroll
composer audit

# Kontrollida ainult lukufaili, nt ehitusel ilma paigaldatud pakettideta
composer audit --locked

# Arendussõltuvused välja jätta (seis nagu serveris)
composer audit --no-dev

# Masinloetav väljund hindamiseks või piletisüsteemi jaoks
composer audit --format=json > audit-$(date +%F).json

Kui käsk leiab turvaauke, lõpeb see veakoodiga. See on soovitud, sest nii katkeb automatiseeritud ehitus. Hinnake iga tabamust: kas pakett on serveris kasutusel, kas mõjutatud funktsiooni kasutatakse, kas parandatud versioon on olemas?

# Millised otsesed sõltuvused on vananenud?
composer outdated --direct
# Miks on teatud pakett paigaldatud?
composer why vendor/paket
# Sihipäraselt uuendada, koos sõltuvustega
composer update vendor/paket --with-dependencies

Testige iga uuendust staging-keskkonnas. Turvauuendused sama põhiversiooni sees on enamasti probleemitud, uus põhiversioon võib aga nõuda koodi kohandamist.

Kontrolli automatiseerimine

Ühekordsest käivitusest on vähe abi, sest uusi turvaauke teatatakse pidevalt. Lisage composer audit seetõttu kahte kohta: ehituse torusse (build pipeline) igal muudatusel ja tootmisseisu regulaarsesse kontrolli, ka siis, kui kood ei muutu.

Lihtne skript igapäevaseks käivituseks ehitus- või kontrollserveris võib välja näha nii:

#!/bin/sh
# Päevane audit väljastatud seisu kohta (kohandage teed)
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

Suunake teade süsteemilogist edasi oma seirele, sisemisele postkastile või piletisüsteemile. Oluline on, et keegi vastutaks teadete hindamise eest. Audit, mille hoiatusi keegi ei loe, ei kaitse.

Puhas väljastamine: juurutus ilma kõrvalmõjudeta

Ka tee serverisse mõjutab turvalisust. Mõned põhireeglid on end tõestanud:

• Võtke composer.lock hoidlasse ja käivitage serveris ainult composer install, mitte kunagi composer update.
• Paigaldage võtmega --no-dev, et test- ja silumistööriistad ei satuks tootmisserverisse.
• Hoidke kausta vendor/ veebi juurkataloogist väljaspool, nii et see ei ole URL-i kaudu otse kättesaadav.
• Käivitage ehitusel composer validate, et vigased või vastuolulised andmed varakult tuvastada.

composer validate --strict
composer install --no-dev --prefer-dist --classmap-authoritative --no-interaction

Pöörake tähelepanu ka PHP versiooni enda toetusele. Teegid eeldavad üha enam värskeid PHP harusid. Kes on veel PHP 8.1 või vanema külge kinni, ei saa PHP-le endale enam ametlikke uuendusi ja ei saa sageli enam paigaldada turvaparandustega uuemaid paketiversioone. Planeerimist kirjeldab juhend PHP End of Life: vananenud versioonide riskid. Raamistikuspetsiifilised vihjed leiate lehelt Laravel-rakenduste turvamine.

Kuidas PHP SOS konkreetselt aitab?

• Kaardistame kõigi sõltuvuste seisu ja hindame tabamusi tegeliku kasutuse järgi.
• Seame üles automatiseeritud kontrollid ehituses ja töös, selge vastutusega leidude eest.
• Planeerime ja testime uuendusi, ka siis, kui uued põhiversioonid nõuavad kohandusi.
• Kontrollime soovi korral ka oma koodi ja seadistust, kuhu ükski automaattööriist ei vaata.

Kolmanda poole tehtavat kontrolli kirjeldab teenus Turvaaudit ja penetratsioonitest.

Korduma kippuvad küsimused

Allikad

• OWASP Top 10
• OWASP Cheat Sheet Series
• php.net: turvateated
• php.net: toetatud versioonid