Mitä tapahtuu, kun WordPressiin julkaistaan tietoturvapäivitys?

Kun WordPressin ytimeen julkaistaan tietoturvapäivitys, valtaosa sivustojen omistajista tuskin huomaa asiaa. Ja tavallaan juuri niin sen kuuluukin mennä. Harva kuitenkaan tietää, mitä kaikkea tapahtuu kulisseissa, jotta päivitys saadaan käyttöön sivustolle.

WordPressin tietoturvatiimissä Human Maden sponsoroimana toimiva John Blackbourn kuvasi hiljattain hyvin, miten haavoittuvuus etenee raportista valmiiksi korjaukseksi. Se on kuitenkin vasta puolet tarinasta.

Toinen puolisko alkaa siitä hetkestä, kun korjaus on julkaistu: miten WordPressin ytimen uusin versio päätyy sivustoille käyttöön? Katsotaan, miten tämä hoituu meillä.

Tietoturvapoikkeamat, eli tilanteet jossa haavoittuvuutta on jo ehditty hyödyntää tai sitä epäillään, ovat ytimen päivityksistä hieman erillinen asia. Silloin päivittäminen ei riitä, vaan painopiste siirtyy tilanteen rajaamiseen, selvittämiseen ja asiakkaan kanssa viestimiseen. Se on oma prosessinsa, josta kirjoitamme myöhemmin.

Ensin: mitä WordPressin päässä tapahtuu?

Kirjoitin aiemmin siitä, miten WordPressin kehitys tapahtuu lähes kokonaan julkisesti. Ytimen tietoturvapäivitykset ovat poikkeus tähän, ja hyvästä syystä. Keskeneräisestä korjauksesta keskusteleminen avoimesti olisi vähän kuin jättäisi talon avaimet ovenpieleen lapun kera.

Löydetyt haavoittuvuudet pyydetään ilmoittamaan WordPressin tietoturvatiimille HackerOne-alustan kautta. Raportin lähettäjälle on tarjolla porkkana: jos sen perusteella päädytään korjaamaan olemassa oleva haavoittuvuus, ilmoittaja saa julkaisun yhteydessä nimensä ja linkkinsä julkaisutiedotteeseen sekä rahallisen palkkion. Viimeisten 90 päivän aikana näitä palkkioita on maksettu 65 000 dollarin edestä.

Vastaanotettuaan ilmoituksen tietoturvatiimi tarkistaa, onko kyseessä aito haavoittuvuus ja luokittelee sen vakavuusasteen. Vuonna 2026 ilmoitusten määrä on räjähtänyt käsiin tekoälyavusteisen tietoturvatutkimuksen myötä. Kun aiemmin ilmoituksia tuli keskimäärin 20–30 kuukaudessa, on tiimi vastaanottanut kesän jälkeen noin 670 ilmoitusta kuukaudessa. Näistä iso osa osoittautuu lopulta vääriksi. Tiimi käyttää tekoälyä apuna haavoittuvuuden varmistamisessa, luokittelussa sekä suosituksissa, mutta lopulta noin 50 asiantuntijasta koostuva tiimi tekee tarkistuksen ja päätökset ihmisen toimesta.

Kun raportti on todettu aiheelliseksi, sen vakavuus ratkaisee tahdin. Kriittinen korjaus julkaistaan erillisenä päivityksenä normaalin julkaisuaikataulun ohi, kun taas vähäisempi korjaus odottaa seuraavaa suunniteltua versiota.

Vakavimmissa tapauksissa tiimi toimii tavalla, joka ei ole vielä kovin yleinen monessa avoimen lähdekoodin projektissa: se koordinoi julkaisuja suoraan suurten tietoturvapalveluiden ja hosting-palveluntarjoajien kanssa. Näin varmistetaan, että niillä on aikaa rakentaa palomuurisuojaukset ja valmistautua päivitysten jakeluun. Kun korjaus tulee julki, iso osa sivustoista on jo suojattu.

Lopuksi päivitys jaetaan maailmalle. WordPress on versiosta 3.7 lähtien asentanut pienet päivitykset oletuksena automaattisesti taustalla ilman, että sivuston omistajan tarvitsee tehdä mitään.

Ydin on harvoin se kohta, joka vaatii huomiota

Kaikki edellä kuvattu koskee kuitenkin vain WordPressin ydintä. Jos WordPress-sivustoa vertaa kerrostaloon, ydin on talon runko: sen on suunnitellut ja sitä valvoo kokenut porukka yhteisten sääntöjen mukaan. Lisäosat ja teemat taas ovat asuntoihin tehtyjä remontteja. Jokaisella niistä on oma tekijänsä ja omat käytäntönsä.

Ero näkyy myös tilastoissa. WordPress-ekosysteemin tietoturvaan erikoistuneen Patchstackin vuosiraportin mukaan 91 % viime vuonna löydetyistä haavoittuvuuksista oli lisäosissa.

Tämä ei tarkoita, että lisäosat olisivat jotenkin vaarallisia. Suuri osa löydöksistä on seurausta siitä, että ekosysteemiä tutkitaan aktiivisesti ja haavoittuvuuksien raportoinnista palkitaan. Se on oikeastaan merkki terveestä ekosysteemistä. Esimerkiksi edellä mainittu Patchstack, yksi alan monista tietoturvatoimijoista, on maksanut tietoturvatutkijoille yli puoli miljoonaa dollaria palkkioita vuodesta 2021 lähtien.

Ero on lähinnä siinä, että ytimellä on yksi yhteinen prosessi ja lisäosilla on tuhansia omiaan. Korjausten aikataulu ja tiedottaminen vaihtelevat tekijän mukaan, ja kaupallisten lisäosien päivitykset eivät kulje WordPress.orgin automaattisen päivityskoneiston kautta. Siksi jonkun täytyy pitää kokonaisuutta silmällä. Ja juuri siinä ylläpitäjän rooli korostuu.

Meillä tämä alkaa jo ennen ensimmäistä päivitystä: lisäosien valinta on myös tietoturvapäätös. Esimerkiksi välimuisti hoidetaan palvelintasolla lisäosan sijaan, ja suosimme vakiintuneita ja aktiivisesti ylläpidettyjä vaihtoehtoja. Mitä vähemmän liikkuvia osia, sitä helpompi kokonaisuus on pitää kunnossa. Käytössä on lisäksi teknologioita ja tapoja estää tunnettujen haavoittuvuuksien hyödyntämistä, vaikka lisäosasta ei olisi vielä saatavilla korjattua versiota.

Näin päivitys kulkee meillä – havainnosta asiakkaan sivustolle

Haavoittuvuuden korjaamiseen aikaa kuluu kahteen vaiheeseen: tiedon saamiseen ja korjauksen viemiseen tuotantoon. Olemme rakentaneet prosessimme niin, että kumpikin vaihe on mahdollisimman lyhyt.

Tieto. Seuraamme haavoittuvuustietoa jatkuvasti useista tietokannoista, WordPressin virallisista tiedotteista sekä yhteisön avoimista keskustelukanavista. Tieto tietoturvajulkaisusta tulee meille käytännössä viiveettä, viimeistään silloin, kun uusi versio julkaistaan. Yhteisön avoimilta keskustelukanavilta voimme huomata tulevan julkaisun jopa ennen virallista tiedotetta.

Jakelu. WordPressin tietoturvapäivitykset jaetaan asiakkaittemme sivustoille normaalin testausputken ohi, jotta korjattu versio on mahdollisimman nopeasti käytössä. Tavallisesti versiopäivitykset kulkevat CI-putken läpi, jossa suoritetaan muun muassa tekoälyavusteinen regressiotestaus. Tietoturvapäivitys aiheuttaa kuitenkin hyvin harvoin ongelmia sivuston toiminnassa. Jos näin kävisi, korjaamme sen erikseen. Rikkinäinen yksityiskohta on pienempi riski kuin hyödynnettävissä oleva haavoittuvuus.

Varmistus. Ohjelmallisen jakelun ja seurannan ansiosta pystymme varmistamaan heti, että jokainen sivusto on saanut päivityksen onnistuneesti. Käytännössä kysymykseen ”onko kaikki varmasti päivitetty?” ei tarvitse etsiä vastausta käymällä sivustoja läpi yksi kerrallaan. Jos päivitys on jostain syystä epäonnistunut, järjestelmä yrittää sitä heti uudelleen ja hälyttää tarvittaessa ihmisen varmistamaan päivityksen.

Tavoitteena on, että homma toimii taustalla luotettavasti eikä tietoturva jää yksittäisen ihmisen manuaalisesti tehtävien toimien tai muistin varaan.

Miksi ei vain automaattipäivityksiä?

WordPressissä on ollut automaattiset taustapäivitykset jo yli kymmenen vuotta. Miksi emme siis käytä niitä? Lyhyesti: automaattipäivitys ratkaisee yksittäisen sivuston ongelman, mutta se ei sovi siihen, miten ylläpidämme satoja sivustoja suurille enterprise-tason asiakkaille.

Automaattipäivitys ei ole välitön

Moni olettaa, että automaattipäivitys asentuu heti, kun korjaus julkaistaan. Käytännössä WordPress tarkistaa tietoturvapäivitykset kerran tunnissa, ja automaattipäivitykset ajetaan vain tämän tarkistuksen yhteydessä. Lisäksi ytimen automaattipäivitykset on porrastettu: päivitysohje lähetetään aluksi vain osalle sivustoista, sitten hieman suuremmalle joukolle ja lopulta kaikille. Viive voi siis olla minuuteista useisiin tunteihin.

Kun haavoittuvuuden tiedot ovat julkisia, juuri niinä tunteina hyökkääjät ehtivät liikkeelle. Oman päivitysputkemme kautta viemme tietoturvapäivitykset sivustoille mahdollisimman nopeasti heti, kun päivitys on hyväksytty jakeluun.

Tietoturvan pitää olla todennettavissa

Kilpailutusten tietoturvakyselyissä ja tietoturva-auditoinneissa kysytään yhä useammin, kuinka nopeasti toimittaja asentaa kriittiset tietoturvapäivitykset ja miten sen voi todentaa. Taustalla on usein NIS2-direktiivi, joka pantiin Suomessa täytäntöön kyberturvallisuuslailla ja joka edellyttää lain piiriin kuuluvilta organisaatioilta myös toimitusketjun tietoturvan hallintaa. ”Hoidossa” ei riitä enää vastaukseksi.

Meillä prosessin tarkastaa säännöllisesti ulkopuolinen auditoija osana ISO 27001 -sertifiointiamme, ja jokaisesta päivityksestä jää jälki: voimme näyttää tarkasti, milloin päivitys on asennettu millekin sivustolle. Sama tieto näkyy suoraan sivuston hallintapaneelissa luomamme ylläpitolisäosan välityksellä. Ytimen automaattipäivityksistä vastaavaa jälkeä ei synny.

Hoituvatko päivityksenne luotettavasti?

Palataan vielä alkuun: hyvin hoidettu tietoturvapäivitys on sellainen, jota sivuston omistaja ei huomaa. Taustalla on silti prosessi, jonka jokaisesta vaiheesta jää jälki.

Tiedätkö, milloin viimeisin tietoturvapäivitys asennettiin teidän sivustollenne ja kuinka kauan sen julkaisusta oli silloin kulunut? Jos vastauksen selvittäminen vaatisi useamman sähköpostin, jutellaan.