Lyhyesti: Joka haluaa päivittää riippuvuuksia, tarvitsee prosessin kolmelle pakettimaailmalle: Composer-paketit PHP-koodissa, npm-moduulit frontend-buildissa sekä laajennukset tai teemat CMS:ssä. Siihen kuuluvat kiinteä rytmi, vastuuhenkilö, testit ennen käyttöönottoa ja suunnitelma paketeille ilman päivitystä. PHP2Shelliä vastaan tämä ei auta, sillä aukko on itse PHP:ssä, mutta auttaa vieraan koodin lukuisia aukkoja vastaan.
Kolme pakettimaailmaa, yksi sokea piste
21.10.2026 jälkeisellä viikolla kaikki pyöri PHP-tulkin ympärillä. Monet tiimit huomasivat samalla, etteivät tunne omien osiensa versioita tarkasti. Verkkosivusto toimii, toimisto hoitaa asian, laajennus ilmoittaa kyllä itsestään, jos on jotain uutta: näin tai samankaltaisesti kuuluvat oletukset, kunnes joku katsoo.
Tyypillinen PHP-projekti koostuu nykyään selvästi enemmän vieraasta kuin omasta koodista. OWASP Top 10 luettelee haavoittuvat ja vanhentuneet komponentit omana riskiluokkanaan. Ongelma on harvoin puuttuva työkalu vaan puuttuva rutiini: päivityksiä tehdään, kun jollakulla on aikaa, ja tietoturvailmoitukset päätyvät postilaatikkoon, jota kukaan ei lue.
Mitä riippuvuuksia päivitätte missä?
Jokaisella pakettimaailmalla on omat työkalunsa ja omat sudenkuoppansa. Seuraava yleiskatsaus auttaa olemaan unohtamatta mitään.
| Pakettimaailma | Kannan näyttö | Aukkojen tarkistus | Tyypillinen sudenkuoppa |
|---|---|---|---|
| Composer (PHP-kirjastot) | composer show |
composer audit |
välilliset paketit, joita kukaan ei tunne |
| npm (frontend-build) | npm ls |
npm audit |
päivitys ilman uudelleenrakennusta ei koskaan saavuta palvelinta |
| CMS-laajennukset ja teemat | hallintakäyttöliittymä tai CLI | valmistajan ilmoitukset, tietoturvapalvelut | hylätyt laajennukset, ostolaajennukset ilman päivityskanavaa |
| PHP ja laajennukset | paketinhallinta | jakelun tietoturvaseuranta | näytetty versio kertoo vähän backporteista |
Viimeinen rivi ei kuulu tarkkaan ottaen sovelluksen riippuvuuksiin, mutta unohtuu usein samalla kertaa. Sama pätee skripteihin, jotka sisällytetään suoraan vieraista palvelimista, esimerkiksi CDN:n kirjastot, chat-widgetit tai seurantakoodi. Ne eivät näy missään lock-tiedostossa, mutta toimivat kävijöidenne selaimessa. Ottakaa ne mukaan luetteloon ja tarkistakaa, onko niistä sisällytetty kiinteät versiot eikä ”aina uusin”. Yksityiskohdat composer audit -komennosta, lock-tiedostosta ja liittämisestä buildiin löytyvät oppaasta Composer-riippuvuuksien aukkojen tarkistus. Miten Composer yleisesti toimii, selittää Composer: PHP:n paketinhallinta.
Huoltokierto kuudessa vaiheessa
Kestävän prosessin ei tarvitse olla monimutkainen. Tämä järjestys on osoittautunut hyväksi:
- Kirjatkaa kanta: Jokaiselle projektille luettelo suorista riippuvuuksista versioineen, alkuperineen ja käyttötarkoituksineen. Lock-tiedostot (
composer.lock,package-lock.json) kuuluvat repositorioon. - Keratkaa ilmoitukset: Tarkistustyökalut ajetaan jokaisessa buildissa ja lisäksi säännöllisesti toimitetulle tilalle, myös ilman koodimuutosta.
- Arvioikaa: Käytetäänkö kyseistä pakettia tuotannossa, onko asianomainen toiminto saavutettavissa, onko korjattua versiota?
- Päivittäkää stagingissa ja testatkaa: Ensin tietoturvapäivitykset saman pääversion sisällä, hypyt uusiin päälversioihin suunnitellaan omana hankkeenaan.
- Ottakaa käyttöön paluutiellä: Edellinen tila säilyy pakettina tai julkaisuna, tietokannan varmuuskopio ennen päivitystä.
- Dokumentoikaa: Mitä päivitettiin milloin, mitä ei tietoisesti ja miksi.
Kiinnittäkää tässä huomiota versiomäärityksiin tiedostoissa composer.json ja package.json. Liian tiukat määritykset estävät tietoturvakorjausten asentamisen. Liian väljät taas tuovat tarkistamattomia uusia päälversioita projektiin. Hyväksi on osoittautunut sallia päivitykset päälversion sisällä ja suunnitella hyppy seuraavaan tietoisesti.
CMS-laajennusten saatavilla olevat päivitykset voi usein näyttää myös komentorivillä, WordPressissä esimerkiksi WP-CLI:llä:
# Näytä saatavilla olevat päivitykset muuttamatta mitään
wp plugin list --update=available
wp theme list --update=available
# Frontend-paketit: vanhentuneet versiot ja tunnetut aukot
npm outdated
npm audit --omit=dev
Automaattiset laajennuspäivitykset suoraan tuotantojärjestelmässä ovat kätevät mutta riskialttiit, jos kukaan ei tarkista niiden jälkeen. Kytkekää ne päälle vain, jos varmuuskopio ennen jokaista ajoa ja tarkistus sen jälkeen on varmistettu.
Kun päivitystä ei ole
Kaikkea ilmoitusta ei voi ratkaista yhdellä napsautuksella. OWASPin Cheat Sheet haavoittuvien riippuvuuksien käsittelystä erottaa useita tapauksia, jotka soveltuvat hyvin arkeen:
- Korjaus saatavilla: asentakaa stagingiin, testatkaa, ottakaa käyttöön. Jos jokin hajoaa, mukauttakaa oma koodi sen sijaan, että jättäisitte päivityksen tekemättä.
- Korjaus ilmoitettu, mutta ei vielä saatavilla: toteuttakaa valmistajan kiertotie, kytkekää asianomainen toiminto pois tai suojatkaa se mahdollisuuksien mukaan, kirjatkaa päätös.
- Korjausta ei odoteta: etsikää korvaava paketti tai takaisinportatkaa korjaus itse, testillä, joka erottaa aukon ennen korjausta ja sen jälkeen.
CMS-laajennuksissa neljäs tapaus on yleinen: laajennus on hylätty. Silloin auttaa vain korvaus tai poisto. Sama koskee epäselvistä lähteistä tulevia laajennuksia, esimerkiksi ostolaajennusten ”ilmaisia” kopioita. Ne eivät saa päivityksiä virallisen kanavan kautta ja sisältävät melko usein itse haittakoodia. Vihjeet WordPress-ylläpitäjille kokoaa WordPress ja PHP2Shell.
Selvittäkää vastuu, ennen kuin seuraava ilmoitus tulee
Yleisin syy vanhentuneisiin paketteihin ei ole tekninen este vaan avoin kysymys: kuka tekee sen? Projekteissa, jotka toimisto on rakentanut ja joita ylläpidetään sisäisesti, kukaan ei usein tunne olevansa vastuussa. Määritelkää jokaiselle projektille, kuka saa ilmoitukset, kuka arvioi ja kuka hyväksyy, ja kirjatkaa se ylös.
Varatkaa lisäksi aikaa. Kiinteä huoltoajankohta kuukaudessa, jolloin riippuvuudet tarkistetaan ja päivitetään, estää päivitysten kasaantumisen vuosien ajaksi. Mitä kauemmin projektia ei ole päivitetty, sitä suurempi ja riskialttiimpi seuraava hyppy on. Miten PHP:n ja pakettien päivitykset sopivat kokonaisvaltaiseen kulkuun, kuvaa Päivitysten hallinta prosessina palokunnan sijaan.
Miten PHP SOS auttaa konkreettisesti?
- Kartoitamme projektienne kaikki riippuvuudet Composerista, npm:stä ja CMS:stä ja merkitsemme vanhentuneet, haavoittuvat ja hylätyt paketit.
- Otamme käyttöön automaattiset tarkistukset ja määrittelemme, kuka arvioi minkäkin ilmoituksen.
- Päivitämme stagingissa, testaamme tärkeimmät kulut ja otamme käyttöön paluutiellä.
- Security-huoltosopimuksen puitteissa hoidamme kuukausittaisen kierron pysyvästi, PHP-päivitykset mukaan lukien.
Yhteenveto: Ajantasaiset riippuvuudet eivät ole projekti vaan rutiini. Joka kerran selvittää kannan, rytmin ja vastuun siististi, joutuu seuraavan suuren ilmoituksen kohdalla vain tarkistamaan, ei ensin etsimään.
Usein kysytyt kysymykset
Kuinka usein riippuvuudet pitäisi päivittää?
Tietoturvapäivitykset mahdollisimman pian arvioinnin jälkeen, rutiinipäivitykset kiinteällä rytmillä, esimerkiksi kuukausittain. Tarkkaa tiheyttä tärkeämpää on, että ajankohta on sovittu ja joku on vastuussa.
Suojaako ajantasainen laajennus PHP2Shelliltä?
Ei. PHP2Shell on itse PHP-tulkissa. Sitä vastaan auttaa vain PHP-päivitys ja kaikkien PHP-prosessien uudelleenkäynnistys. Ajantasaiset laajennukset ja paketit ovat silti tärkeitä, koska ne sulkevat omia aukkojaan.
Mitä teen laajennukselle, jota ei enää ylläpidetä?
Korvaa tai poista se. Hylätty laajennus ei saa enää korjauksia, vaikka se toimisi vielä tänään. Siihen asti, kunnes korvaaja on käytössä, kannattaa tarkistaa, tarvitaanko toimintoa todella, ja dokumentoida päätös.
Pitääkö npm-frontendi päivittää myös palvelimella?
Usein npm-paketit ovat vain buildissa ja päätyvät palvelimelle valmiina tiedostoina. Paketin aukko voi silti olla toimitetussa JavaScriptissä. Päivityksen jälkeen on siksi rakennettava ja toimitettava uudelleen.