Kyberturvallisuuskeskus on nostanut Kybersää-raporteissaan kevään 2026 aikana esiin toimitusketjuhyökkäykset. Ilmiö koskettaa käytännössä kaikkia ohjelmistoja kehittäviä organisaatioita. Haastavimmissa tilanteissa toimitusketjuhyökkäyksen vaikutukset voivat ulottua organisaation toiminnan häiriintymisestä liiketoiminnan jatkuvuuden vaarantumiseen.
luotettavuusOhjelmistokehitys
DevSecOpsOhjelmistokehitysOhjelmistoturvallisuus
Toimitusketjuhyökkäykset osoittavat, että ohjelmiston turvallisuus ei riipu enää vain omasta lähdekoodista. Modernit ohjelmistot rakentuvat avoimen lähdekoodin kirjastoista, kolmannen osapuolen komponenteista, pilvipalveluista ja kehitystyökaluista. Jos jokin näistä vaarantuu, vaikutukset voivat ulottua myös lopputuotteeseen ja sen käyttäjiin.
Toimitusketjuriskien hallinta vaatii riippuvuuksien tunnistamista, komponenttien seurantaa, läpinäkyvyyttä ja tietoturvan tuomista osaksi koko ohjelmistokehityksen elinkaarta. DevSecOps-ajattelussa turvallisuus ei ole erillinen loppuvaiheen tarkastus, vaan osa kehitystä, laadunvarmistusta ja ylläpitoa. Luotettava ohjelmisto on hallittu kokonaisuus, jonka jokainen osa tunnetaan ja jota voidaan ylläpitää turvallisesti myös tulevaisuudessa.
Esimerkiksi maaliskuun Kybersäässä kerrottiin useamman ohjelmistokomponenttien kautta tehdyistä toimitusketjuhyökkäyksistä. Uhkatoimija TeamPCP toteutti hyökkäykset avoimen lähdekoodin ohjelmistojen (Trivy, Kicks, ja Python-paketti LibLLM) kautta. (Kyberturvallisuuskeskus, Kybersää maaliskuu 2026)
Toimitusketjuhyökkäykset eivät ole uusi ilmiö, mutta niiden merkitys kasvaa jatkuvasti ohjelmistojen monimutkaistuessa. Harva ohjelmisto rakentuu enää pelkästään oman organisaation kirjoittamasta koodista. Tämä muuttaa myös tapaa, jolla ohjelmistoturvallisuutta tarkastellaan. Vaikka oma lähdekoodi olisi laadukasta ja huolellisesti testattua, riskit voivat syntyä ohjelmiston ympärille rakentuneista toimitusketjusta.
Avoimen lähdekoodin kirjastot, kolmannen osapuolen komponentit, pilvipalvelut ja kehitystyökalut ovat olennainen osa modernia ohjelmistokehitystä ja samalla osa ohjelmiston turvallisuutta. Tämä on yksi ohjelmistokehityksen suurimmista vahvuuksista: kaikkea ei tarvitse rakentaa alusta asti itse, vaan kehitystyössä voidaan hyödyntää laajasti muiden toimijoiden tuottamia ratkaisuja.
Tällä on kuitenkin kääntöpuolensa, sillä samalla ohjelmistojen riippuvuuksien määrä on kasvanut merkittävästi. Vaikka kehittäjä lisää projektiin vain muutaman avoimen lähdekoodin kirjaston, niiden mukana voi tulla kymmeniä tai jopa satoja muita riippuvuuksia. Tämän vuoksi ohjelmiston turvallisuutta tulee tarkastella kriittisesti jokaisen käytetyn kirjaston, komponentin, palvelun ja työkalun kautta. Jos ketjun jokin osa vaarantuu, vaikutukset voivat ulottua myös lopputuotteeseen ja sen käyttäjiin.
Hyvä kysymys ohjelmistokehitystä tekeville organisaatioille kuuluukin: Kuinka hyvin tunnemme kaikki ne komponentit ja riippuvuudet, joiden varaan tuotteemme on rakennettu? Tämä kysymys on noussut yhä tärkeämmäksi samaan aikaan, kun toimitusketjuhyökkäykset ovat lisääntyneet ja hyökkääjät etsivät uusia tapoja päästä käsiksi mahdollisimman moniin kohteisiin yhden hyökkäyksen kautta.
Wirokitin järjestelmäasiantuntija Veijo Kingelinin mukaan riippuvuuksien hallinta näkyy käytännössä sekä tuotekehityksen että DevOpsin arjessa.
“Ohjelmistokehityksessä käytetyt kirjastot ja liitännäiset ovat pääosin tuotekehittäjän vastuulla, mutta DevOps joutuu joka tapauksessa ottamaan huomioon niistä johtuvia epävarmuuksia. Tietoturvailmoituksia ja versiovaatimuksia seurataan tarkasti tiedossa olevien lisäosien ja sovellusten osalta. Lisäksi avoimen lähdekoodin lisenssivaatimukset huomioidaan varsinaisessa sovelluskehityksessä, ja DevOps-puolella niitä auditoidaan esimerkiksi silloin, kun toimitukseen lisätään avoimen lähdekoodin sovelluksia käyttöjärjestelmätasolla”, Kingelin kertoo.
Toimitusketjuhyökkäysten tehokkuus perustuu niiden laajaan vaikutusalueeseen. Sen sijaan, että hyökkääjä kohdistaisi hyökkäyksen yksittäiseen organisaatioon, hän pyrkii murtautumaan ohjelmistokomponenttiin, palveluun tai toimittajaan, jota monet organisaatiot käyttävät osana omaa toimintaansa. Yksi onnistunut hyökkäys voi näin avata reitin kymmeniin, satoihin tai jopa tuhansiin kohteisiin.
Kyberturvallisuuskeskus kertoi tapauksesta, jossa kansainväliseen yritykseen kohdistuneen toimitusketjuhyökkäyksen välityksellä levitettiin haitallisia ohjelmia organisaatioille, jotka käyttivät yrityksen tuotteita ja palveluita. (Kyberturvallisuuskeskus, Kybersää toukokuu 2026) Tapaus havainnollistaa hyvin toimitusketjuhyökkäysten toimintalogiikkaa: hyökkäyksen kohteena ei ollut jokainen asiakasorganisaatio erikseen, vaan yksi toimittaja, jonka kautta vaikutukset levisivät laajalle.
Juuri tästä syystä toimitusketjuhyökkäykset ovat hyökkääjille houkutteleva toimintamalli. Ohjelmistokehityksessä käytetään laajasti samoja avoimen lähdekoodin kirjastoja, kehitystyökaluja, pilvipalveluita ja muita yhteisiä komponentteja. Kun yksi laajasti käytetty lenkki ketjussa vaarantuu, vaikutukset voivat ulottua huomattavasti alkuperäistä kohdetta laajemmalle.
Toimitusketjuriskien kasvu on muuttanut myös ohjelmistokehityksen toimintatapoja. Aiemmin tietoturvaa tarkasteltiin usein erillisenä vaiheena ohjelmiston kehityksen loppupuolella, mutta DevSecOps-ajattelussa turvallisuus tuodaan osaksi koko ohjelmiston elinkaarta suunnittelusta käyttöönottoon ja ylläpitoon asti. Tavoitteena on tunnistaa riskit mahdollisimman varhaisessa vaiheessa ja automatisoida tietoturvan tarkastuksia osaksi kehitysprosessia sen sijaan, että ongelmia korjattaisiin vasta julkaisun jälkeen.
DevSecOpsissa ohjelmistoturvallisuus ei ole pelkästään tietoturva-asiantuntijoiden vastuulla, vaan osa koko kehitystiimin toimintaa. Kehittäjät, laadunvarmistus ja ylläpidosta vastaavat tiimit osallistuvat yhdessä turvallisuuden varmistamiseen koko ohjelmiston elinkaaren ajan.
Kingelinin mukaan DevSecOps-ajattelu näkyy käytännössä myös käyttöoikeuksien rajaamisessa.
“Access tokenien oikeuksien kanssa ollaan jatkuvasti entistä tarkempia ja pääsyjä rajataan enemmän. Harvoin käytetään enää ‘kaikki oikeudet kerralla’ -access tokenia, vaan mietitään tarkasti, mitä pääsyjä todellisuudessa tarvitaan. Uusimisväli on usein myös tiukempi, ja noudatetaan periaatetta, jossa mahdollisimman pienillä oikeuksilla saavutetaan haluttu lopputulos. Harvoin kehittäjälläkään on kaikkialle pääsy yhdellä avaimella”, hän kuvailee.
Käyttöoikeuksien rajaamisen lisäksi DevSecOps näkyy käytännössä esimerkiksi riippuvuuksien automaattisena tarkastamisena, haavoittuvuusskannauksina sekä jatkuvana valvontana osana ohjelmiston kehitys- ja julkaisuputkea. Näin mahdollisiin toimitusketjuriskeihin voidaan reagoida jo ennen kuin ne päätyvät osaksi tuotantoympäristöä.
Toimitusketjuhyökkäyksiä ei voida estää täysin, mutta niiden vaikutuksia voidaan pienentää tunnistamalla ohjelmiston riippuvuudet ja hallitsemalla niitä systemaattisesti. Ensimmäinen askel on ymmärtää, mistä ohjelmisto todellisuudessa rakentuu. Jos käytössä olevia kirjastoja, komponentteja, palveluita ja niiden välisiä riippuvuuksia ei tunneta, niiden aiheuttamia riskejä on mahdotonta hallita.
Toimitusketjuriskien hallinta ei myöskään pääty ohjelmiston julkaisuun. Ohjelmistokomponentteja ylläpidetään jatkuvasti, niihin löydetään uusia haavoittuvuuksia ja niiden elinkaaret muuttuvat ajan myötä. Sonatypen vuoden 2026 Supply Chain -raportin mukaan jopa 65 prosenttia vuonna 2025 julkaistuista avoimen lähdekoodin CVE-haavoittuvuuksista jäi ilman virallista vakavuusluokitusta. Havainto korostaa organisaatioiden omaa vastuuta seurata käyttämiään komponentteja ja niiden turvallisuutta aktiivisesti. Siksi ohjelmiston turvallisuuden kannalta on tärkeää seurata käytettyjä komponentteja ja niiden tilaa myös tuotteen käyttöönoton jälkeen.
Kingelin kertoo, että toimitusketjuriskejä voidaan pienentää myös kehitys- ja julkaisuputken käytännöillä.
“CI/CD-putkessa riskejä pyritään minimoimaan automaattisilla haavoittuvuustarkastuksilla, riippuvuuksien pinnaamisella eli tiettyjen sovelluspakettien versioiden lukitsemisella sekä erottamalla lopullinen toimitettava versio CI/CD-putkesta erilliseen repositorioon. Näin uudempaa versiota ei ladata huomaamatta build-vaiheessa”, Kingelin toteaa.
Täydellinen kontrolli ohjelmiston koko toimitusketjuun on harvoin mahdollista. Sen sijaan keskeistä on läpinäkyvyys: organisaation tulisi tietää, mitä komponentteja tuotteessa käytetään, mistä ne ovat peräisin ja millaisia riippuvuuksia niihin liittyy. Mitä paremmin ohjelmiston kokonaisuus tunnetaan, sitä nopeammin mahdollisiin riskeihin voidaan reagoida.
Laadunvarmistuksen näkökulmasta toimitusketjujen merkitys korostuu entisestään. Ohjelmiston laatu ei muodostu ainoastaan organisaation itse kirjoittamasta koodista, vaan myös niistä komponenteista ja palveluista, joiden varaan ratkaisu rakentuu. Siksi myös riippuvuudet ovat osa ohjelmiston laadun ja turvallisuuden kokonaisuutta.
Toimitusketjuhyökkäykset ovat muistutus siitä, että ohjelmiston turvallisuutta ja laatua ei voida arvioida pelkästään oman lähdekoodin perusteella. Mitä paremmin organisaatio tuntee ohjelmistonsa komponentit ja niiden väliset riippuvuudet, sitä paremmin se pystyy reagoimaan muuttuviin uhkiin ja varmistamaan tuotteensa luotettavuuden.
Nykyaikainen ohjelmistokehitys ei ole enää yksittäisten komponenttien toteuttamista, vaan kokonaisuuksien rakentamista. Siksi myös ohjelmiston turvallisuutta ja laatua on tarkasteltava koko toimitusketjun näkökulmasta.
Lue lisää aiheesta artikkelistamme: Ohjelmistokehittäjän täytyy osata rakentaa myös turvallisuutta.
Lopulta kyse ei ole vain tietoturvasta, vaan myös ohjelmiston laadusta. Laadukas ohjelmisto on enemmän kuin hyvin kirjoitettua koodia. Se on hallittu kokonaisuus, jonka jokainen osa tunnetaan ja jonka toimintaa voidaan luotettavasti ylläpitää myös tulevaisuudessa. Kun ohjelmiston on toimittava varmasti, myös sen toimitusketjun on oltava hallinnassa.
Toimitusketjuriskien hallinta on yhä tärkeämpi osa ohjelmistokehitystä. Kun ohjelmistot rakentuvat avoimen lähdekoodin kirjastoista, komponenteista, palveluista ja kehitystyökaluista, turvallisuutta ei voida arvioida vain oman lähdekoodin perusteella. Myös riippuvuudet, käyttöoikeudet, lisenssit ja julkaisuputken käytännöt vaikuttavat lopputuotteen luotettavuuteen.
DevSecOps-ajattelu auttaa tuomaan tietoturvan osaksi koko ohjelmiston elinkaarta suunnittelusta ylläpitoon. Automaattiset haavoittuvuustarkastukset, riippuvuuksien hallinta ja jatkuva seuranta pienentävät riskiä, että toimitusketjun heikko lenkki päätyy osaksi tuotetta. Lopulta kyse ei ole vain tietoturvasta, vaan laadusta: kun ohjelmiston on toimittava varmasti, myös sen toimitusketjun on oltava hallinnassa.
Asiantunteva tuotekehityskumppanisi kriittisessä ohjelmistokehityksessä ja laadunvarmistuksessa.
Kovempaa koodia
