Lyhyesti: composer audit vertaa PHP-projektinne paketteja tunnettuihin tietoturvailmoituksiin ja näyttää koskettavat versiot. Ajakaa komento jokaisen buildin yhteydessä ja säännöllisesti tuotantotilaan. Tärkeää PHP2Shellin jälkeen: tarkistus kattaa kirjastot, ei itse PHP-tulkkia.
Miksi riippuvuudet kaipaavat huomiota juuri nyt
Nykyaikaiset PHP-sovellukset koostuvat suurimmaksi osaksi vieraasta koodista. Symfonyyn perustuva verkkokauppa tai Laravelilla tehty portaali tuo mukanaan helposti useita kymmeniä tai satoja paketteja, joista monet epäsuorasti muiden pakettien kautta. Jokainen näistä kirjastoista voi sisältää haavoittuvuuden. OWASP Top 10 listaa siksi vanhentuneet ja haavoittuvat komponentit omana riskiluokkanaan.
Lokakuussa 2026 PHP2Shell osoitti, kuinka nopeasti kriittinen haavoittuvuus leviää laajalle. Molemmat haavoittuvuudet, CVE-2026-109618 ja CVE-2026-109619, koskevat tosin PHP:tä itseään eikä Composer-paketteja. Monet tiimit kävivät näinä päivinä kuitenkin läpi koko ketjunsa ja huomasivat, etteivät tunne riippuvuuksiensa tilaa tarkasti.
Tämän yleiskuvan aukon voi paikata pienellä vaivalla. Composer tuo sopivan työkalun mukanaan jo uusissa versioissa.
Mitä composer audit tarkistaa ja mitä ei
Komento lukee asennetut paketit tai lock-tiedoston ja hakee näihin paketteihin liittyvät tunnetut tietoturvailmoitukset. Jokaisesta osumasta se näyttää paketin, koskettavan versioalueen, vakavuusasteen, ilmoituksen tunnisteen ja linkin kuvaukseen.
| Taso | Tarkistaako composer audit? | Miten tarkistaa muuten |
|---|---|---|
| Projektin Composer-paketit | kyllä | composer audit |
| PHP-tulkki (esim. PHP2Shell) | ei | Paketin tila, hosting-yrityksen vahvistus |
| Järjestelmän PHP-laajennukset | ei | Jakelun paketinhallinta |
| Frontendin JavaScript-paketit | ei | Kyseisen paketinhallinnan työkalu |
| Oma sovelluskoodi | ei | Koodikatselmointi, tietoturva-auditointi |
Komento huomioi myös epäsuorat riippuvuudet, siis paketit, joita ette ole itse pyytäneet mutta jotka tulevat muiden pakettien mukana. Juuri niissä haavoittuvuudet piileskelevät usein huomaamatta, koska kukaan tiimissä ei tunne näitä paketteja. Uudemmat Composer-versiot huomauttavat lisäksi paketeista, jotka niiden tekijät on merkinneet hylätyiksi. Tällaisiin paketteihin ei yleensä enää tule korjauksia, ja ne pitäisi korvata.
Puhdas tulos tarkoittaa siis vain, ettei asennetuista paketeista tunneta ilmoitusta. Tuntemattomia haavoittuvuuksia ja virheitä omassa koodissa työkalu ei löydä. Miten PHP-tilan tarkistatte itse, kuvataan artikkelissa PHP-version ja korjaustilan tarkistaminen oikein.
composer auditin ajaminen ja tulosten lukeminen
Projektihakemistossa riittää yksi komento. Muunnelmat eroavat siinä, mitä tarkistetaan ja miten tulos tulostetaan.
# Tarkista asennetut paketit
composer audit
# Tarkista vain lock-tiedosto, esim. buildissa ilman asennettuja paketteja
composer audit --locked
# Jätä kehitysriippuvuudet pois (tila kuten palvelimella)
composer audit --no-dev
# Koneluettava tuloste arviointia tai tikettijärjestelmää varten
composer audit --format=json > audit-$(date +%F).json
Jos komento löytää haavoittuvuuksia, se päättyy virhekoodiin. Se on tarkoituksellista, sillä näin automaattinen build keskeytyy. Arvioikaa jokainen osuma: onko paketti käytössä palvelimella, käytetäänkö kosketettua toimintoa, onko korjattu versio olemassa?
# Mitkä suorat riippuvuudet ovat vanhentuneet?
composer outdated --direct
# Miksi tietty paketti on asennettu?
composer why vendor/paket
# Päivitä kohdennetusti riippuvuuksineen
composer update vendor/paket --with-dependencies
Testatkaa jokainen päivitys staging-ympäristössä. Saman pääversion sisällä tehtävät tietoturvapäivitykset ovat yleensä ongelmattomia, uusi pääversio voi sen sijaan vaatia muutoksia koodiin.
Tarkistuksen automatisointi
Kertaluonteisesta ajosta on vähän hyötyä, sillä uusia haavoittuvuuksia tulee tietoon jatkuvasti. Liittäkää composer audit siksi kahteen kohtaan: build-putkeen jokaisen muutoksen yhteydessä ja tuotantotilan säännölliseen tarkistukseen, vaikka koodiin ei tulisi muutoksia.
Yksinkertainen komentosarja päivittäiseen ajoon build- tai tarkistuspalvelimella voi näyttää tältä:
#!/bin/sh
# Päivittäinen audit toimitetusta tilasta (muokkaa polku)
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
Ohjatkaa ilmoitus järjestelmälokista valvontaanne, sisäiseen postilaatikkoonne tai tikettijärjestelmäänne. Tärkeää on, että joku vastaa ilmoitusten arvioinnista. Audit, jonka varoituksia kukaan ei lue, ei suojaa.
Määrittäkää composer.json-tiedostossa kohdassa config.platform.php palvelimella toimiva PHP-versio. Silloin Composer ratkaisee vain tähän tilaan sopivia paketteja, ja composer check-platform-reqs näyttää poikkeamat.
Siisti toimitus: deployment ilman sivuvaikutuksia
Myös tie palvelimelle vaikuttaa turvallisuuteen. Muutama perussääntö on osoittautunut toimivaksi:
- Ottakaa
composer.lockmukaan repositorioon ja ajakaa palvelimella vaincomposer install, ei koskaancomposer update. - Asentakaa
--no-dev-valitsimella, jotta testi- ja virheenkorjaustyökalut eivät päädy tuotantopalvelimelle. - Pitäkää
vendor/-kansio verkon juurihakemiston ulkopuolella, jotta se ei ole suoraan tavoitettavissa URL-osoitteella. - Ajakaa
composer validatebuildissa virheellisten tai ristiriitaisten tietojen havaitsemiseksi ajoissa.
composer validate --strict
composer install --no-dev --prefer-dist --classmap-authoritative --no-interaction
Kiinnittäkää lisäksi huomiota itse PHP-version tukeen. Kirjastot edellyttävät yhä useammin uusia PHP-haaroja. Joka on yhä PHP 8.1:ssä tai vanhemmassa, ei saa PHP:lle enää virallisia päivityksiä eikä usein pysty asentamaan uudempia, tietoturvakorjauksia sisältäviä pakettiversioita. Suunnittelua varten on opas PHP:n tuen päättyminen: vanhentuneiden versioiden riskit. Viitekehyskohtaisia vinkkejä löydätte sivulta Laravel-sovellusten suojaaminen.
Miten PHP SOS auttaa konkreettisesti?
- Kartoitamme kaikkien riippuvuuksien tilan ja arvioimme osumat todellisen käytön mukaan.
- Perustamme automaattiset tarkistukset buildiin ja käyttöön, selkeällä vastuulla havainnoista.
- Suunnittelemme ja testaamme päivitykset, vaikka uudet pääversiot vaatisivat muutoksia.
- Tarkistamme pyynnöstä myös oman koodin ja asetukset siellä, minne mikään automaattinen työkalu ei katso.
Kolmannen osapuolen tekemän tarkistuksen kuvaa palvelu Tietoturva-auditointi ja penetraatiotesti.
Usein kysytyt kysymykset
Löytääkö composer audit myös PHP2Shellin?
Ei. composer audit tarkistaa projektinne paketit, ei palvelimen PHP-tulkkia. PHP2Shell on PHP:ssä itsessään, ja se korjataan vain PHP-päivityksellä ja kaikkien PHP-prosessien uudelleenkäynnistyksellä.
Pitääkö composer.lock olla repositoriossa?
Sovelluksissa kyllä. Lock-tiedosto kirjaa tarkasti, mitkä versiot on asennettu. Vain näin composer audit tarkistaa tilan, joka todella toimii palvelimella, ja jokainen deployment asentaa samat versiot.
Mitä tehdä, jos koskettuun pakettiin ei ole päivitystä?
Tarkistakaa, käyttääkö projektinne ylipäänsä kyseistä toimintoa, ja dokumentoikaa arvio. Jos korjausta ei ole, vaihtoehtoina ovat korvaava paketti, oma korjaus tai väliaikainen suojaus palvelintasolla.
Kuinka usein composer audit pitäisi ajaa?
Jokaisen buildin yhteydessä ja lisäksi säännöllisesti, esimerkiksi päivittäin, myös ilman koodimuutoksia. Uusia haavoittuvuuksia ilmoitetaan jatkuvasti, ja eilen puhdas tila voi tänään olla altis.