Olemme nähneet, kuinka turvallisuusympäristö on muuttunut nopeasti. Ohjelmistojen tietoturvan pettämisen seuraukset voivat olla vakavia. Ohjelmistokehittäjän työ ei ole enää pelkkää toimivan koodin kirjoittamista – kun ohjelmistot ohjaavat yhä useammin fyysisiä laitteita, kriittisiä palveluita ja liiketoimintaa, kasvavat myös odotukset niiden kehittäjiä kohtaan. Kyse ei enää ole siitä toimiiko ohjelmisto, vaan kuinka luotettavasti, turvallisesti ja ennakoitavasti se toimii.
luotettavuusOhjelmistokehitys
kriittinenkoodiOhjelmistoturvallisuus
Ohjelmistokehittäjältä on aina odotettu toimivaa koodia. Nyt sen lisäksi odotetaan myös luotettavuutta, turvallisuutta ja ratkaisujen perusteltavuutta turvallisuuden näkökulmasta.
“Laadukasta koodia ja toimivaa lopputulosta on aina vaadittu, mutta nykyään laadun ja varmennuksen merkitys ymmärretään eri tavalla”, kuvaa ohjelmistokehittäjämme Mika Maunumaa.
Muutos näkyy siinä, että laadusta, turvallisuudesta ja varmennuksesta ei enää voida tinkiä samalla tavalla kuin aiemmin. Uutta koodia otetaan käyttöön vasta laajan ja ennalta määritellyt kriteerit täyttävän testauksen jälkeen. Testien olisi katettava toimivuus, turvallisuus ja vaikutukset muihin järjestelmiin.
Myös toinen ohjelmistokehittäjämme Marko Koivuporras kuvaa kehitystä käytännön kautta:
“Ennen riitti kun oli editori ja kääntäjä, nyt täytyy osata huomioida turvallisuusvaatimukset kehitysympäristössä, ohjelmointikielessä ja projektissa. Jo pelkkä työympäristö on laajentunut merkittävästi, mutta sen lisäksi kehittäjältä vaaditaan kykyä välttää, löytää ja korjata haavoittuvuuksia koodissa.”
Ohjelmistokehitys ei ole enää yksittäisen komponentin toteutusta, vaan järjestelmien rakentamista, joissa yksittäiset ratkaisut vaikuttavat koko kokonaisuuteen – usein yllättävilläkin tavoilla.
Kriittisyydestä puhutaan kyllä, mutta harvemmin määritellään mitä sillä tarkoitetaan käytännössä.
“Raha ja ihmishenki. Yleisesti linjattuna ne määräävät kriittisyyden”, Maunumaa kiteyttää.
Koivuporras täydentää näkökulmaa:
“Turvallisuuden ja terveyden lisäksi kriittisyys liittyy suoraan liiketoimintavaikutuksiin ja henkilötietojen käsittelyyn – silloin vaatimustaso nousee olennaisesti.”
Kriittisyys ei siis ole pelkästään tekninen luokittelu, vaan seurausta siitä, mitä ohjelmiston virhe aiheuttaa. Kun ohjelmisto on osa järjestelmää, jossa virhe voi keskeyttää tuotannon, vaarantaa turvallisuuden tai rikkoa sääntelyvaatimuksia, muuttuu myös ohjelmistokehityksen luonne.
Turvallisuusympäristö on muuttunut nopeasti. Monessa organisaatiossa kriittisyys tunnistetaan kuitenkin liian myöhään. Ohjelmistoa kehitetään pitkään kuin se ei olisi kriittinen, vaikka sen käyttöympäristö tekee siitä sellaisen. Kun tämä havaitaan, ollaan usein tilanteessa, jossa kehitystapaa joudutaan korjaamaan kesken matkan – ja se tulee kalliiksi tai osoittautuu jopa mahdottomaksi.
“Turvallinen kehittäminen pienentää riskejä, on hyväksi liiketoiminnan jatkuvuudelle ja yleisesti parantaa työn laatua.”
Kriittisessä ohjelmistokehityksessä toimivuus ei ole riittävä mittari. Oleellisempaa on, voidaanko ohjelmiston toimintaan perustellusti luottaa.
“Ohjelmiston toimivuutta ei ikinä pysty todentamaan täysin”, Maunumaa sanoo. “Ei ole olemassa määrää testejä, joilla voisit osoittaa virheettömyyden. Siksi luotettavuus ei perustu täydellisyyteen, vaan siihen, miten järjestelmällisesti sitä rakennetaan ja varmistetaan.”
Jos vaatimuksia ei ole määritelty tavalla, jota voidaan testata, niiden toteutumista ei voida todentaa. Tällöin laatu jää oletusten varaan: ohjelmisto näyttää toimivan, mutta sen toimivuudelle ei ole perusteltua näyttöä.
Luotettavuus ei synny yksittäisestä testistä tai tarkastuksesta, vaan siitä, että koko kehitysprosessi – määrittely, suunnittelu, toteutus ja testaus – tukee sitä johdonmukaisesti. Ilman tätä luotettavuus jää helposti oletukseksi ja sen todellinen hinta näkyy vasta tuotannossa.
Yksi sitkeimmistä harhaluuloista ohjelmistokehityksessä on, että kokemus näkyy parempana koodina. Todellisuudessa se näkyy siinä, mitä jätetään tekemättä.
“Junior-tason tekijä kuulee lauseen ja alkaa koodata siitä sovellusta”, Maunumaa kuvaa.
Kokenut kehittäjä tekee toisin: hän tunnistaa riskit etukäteen ja ymmärtää, milloin yksinkertainen ratkaisu ei ole riittävä ja milloin sitä ei pidä valita.
Koivuporras kuvaa muutosta näin:
“Se ei ole enää selviytymistaistelua koodin kanssa, vaan fokus siirtyy järjestelmätasolle ja arkkitehtuuriin.”
Kriittisissä ympäristöissä tämä tarkoittaa ajattelutavan muutosta. Kehittäjä ei perusta ratkaisujaan oletuksiin, vaan varautuu siihen, että järjestelmä kohtaa virhetilanteita. Ennakoivat toimet, kuten testaukset, uhkamallinnukset, auditoinnit sekä järjestelmien turvallinen kehitys ja ylläpito, ovat aina halvempia kuin kriisinhallinta paineen alla.
“Kyse on siitä, että tunnistetaan, missä asiat voivat mennä pieleen, ja varmistetaan ne etukäteen”, Koivuporras kiteyttää.
Monessa organisaatiossa ajatellaan, että laatu ja turvallisuus ratkaistaan kehitysvaiheessa. Käytännössä suurimmat ongelmat syntyvät kuitenkin ennen sitä.
“Ennen kuin projekti on alkanut, se on aliarvioitu aina”, Maunumaa toteaa.
Ongelma ei yleensä ole yksittäinen virhe toteutuksessa, vaan se, että lähtötilanne on heikko. Vaatimuksia ei ole määritelty tavalla, jota voidaan testata, työn määrä arvioidaan liian optimistisesti ja testauksen rooli jää epäselväksi. Seuraukset näkyvät vasta myöhemmin, kun huomataan, ettei valmista ohjelmistoa pystytä enää kunnolla varmentamaan.
Käytännössä tämä näkyy Koivuportaan mukaan yksinkertaisissa, mutta kriittisissä asioissa:
“Käyttäjäsyötteisiin ei voi koskaan luottaa, vaan ne on aina validoitava.”
Kyse ei ole yksittäisistä käytännöistä, vaan siitä, miten ohjelmistokehitystä tehdään alusta lähtien huomioiden ohjelmistoturvallisuus. Tämä vaatii kehittäjiltä kattavaa turvallisuusymmärrystä ja kykyä toimia turvallisuuskriittisessä ympäristössä huomioiden turvallisuusohjeet ja -säädökset.
Kun ohjelmisto toimii osana fyysistä järjestelmää, virheiden käsittely ei ole enää sama asia kuin perinteisessä sovelluskehityksessä.
“Sitä ei bootata niin kuin läppäriä, vaan sen pitää toipua virhetilanteista itse”, Koivuporras kuvaa.
Tämä yksittäinen havainto muuttaa kehittäjän työn luonnetta. Ei riitä, että ohjelmisto toimii normaalitilanteessa, vaan sen täytyy kestää myös häiriötilanteita ja palautua niistä hallitusti.
Fyysisessä ympäristössä järjestelmän on kyettävä tunnistamaan virhetilanteet, rajaamaan niiden vaikutukset ja jatkamaan toimintaansa ilman ulkopuolista apua. Luotettavuus tarkoittaa tällöin kykyä toimia myös silloin, kun kaikki ei mene suunnitellusti.
Tämä on keskeinen ero aiempaan tapaan kehittää ohjelmistoja pelkästään toteuttamaan halutut toiminnallisuudet. Luotettavassa ohjelmistokehityksessä virhe ei ole poikkeus, vaan oletus, johon järjestelmän on oltava valmis reagoimaan.
Sekä Maunumaa että Koivuporras ovat samaa mieltä siitä, että ohjelmistokehitys ei ole yksinkertaistumassa.
“Tietoturva, testaus ja vaatimustenhallinta – niiden merkitys kasvaa koko ajan, mutta niitä ei vieläkään ymmärretä riittävästi”, Maunumaa sanoo.
Samaan aikaan tekoäly muuttaa kehitystyötä. Se voi nopeuttaa koodin tuottamista, mutta ei poista vastuuta – pikemminkin lisää sitä.
“Jos koodia tuotetaan enemmän ja nopeammin, testauksen ja varmistamisen merkitys korostuvat. Tekoälyllä voidaan tuottaa nopeasti suuria koodimassoja, mutta niiden oikeellisuudesta ei voida olla varmoja. Tämä tekee varmennuksesta entistä kriittisempää”, Koivuporras toteaa.
Tämä on ristiriita, jota moni organisaatio ei ole vielä ratkaissut. Kehitystä halutaan nopeuttaa, mutta samaan aikaan vaatimukset luotettavuudelle kasvavat. Ilman selkeitä käytäntöjä tämä johtaa helposti tilanteeseen, jossa nopeus kasvaa, mutta luottamus järjestelmän toimintaan heikkenee. Turvalliselle kehittämiselle on tärkeää laatia kehitystyötä koskevat pelisäännöt, joiden toteutumista valvotaan kaikessa tehtävässä kehityksessä.
Nykypäivän ohjelmistokehittäjä ei rakenna vain toiminnallisuuksia. Hän rakentaa järjestelmiä, joiden pitää kestää aikaa, käyttöä ja väistämättä tapahtuvia virheitä.
Tämä muuttaa työn luonnetta perustavanlaatuisesti. Kehittäjän ei riitä keskittyä siihen, että yksittäinen ominaisuus toimii suunnitellusti. Hänen täytyy ymmärtää, miten järjestelmä käyttäytyy kokonaisuutena – myös tilanteissa, joita ei ole ennalta täysin määritelty.
Kriittisissä ympäristöissä ohjelmistoa ei julkaista kertaalleen, vaan sitä päivitetään jatkuvasti. Se elää muutosten, turvallisuuspäivitysten ja uusien vaatimusten mukana. Samalla sen on kestettävä virhetilanteita, ulkoisia häiriöitä ja tilanteita, joita ei ole voitu täysin ennakoida.
Tämä tarkoittaa, että turvallisuutta, laatua ja luotettavuutta ei voi lisätä jälkikäteen. Ne syntyvät valinnoista, joita tehdään suunnittelussa, toteutuksessa ja koko kehityksen aikana.
Pelkkä toimivuus ei riitä. Olennaista on, onko ohjelmiston toiminta ymmärrettävää, ennakoitavaa ja sellaisella tavalla perusteltua, että siihen voidaan luottaa myös poikkeustilanteissa. Ohjelmistoturvallisuus on osa huoltovarmuutta, joten ohjelmistokehittäjä rakentaa lopulta luotettavampaa yhteiskuntaa.
Nykypäivän ohjelmistokehityksessä pelkkä toimiva koodi ei enää riitä, vaan tietoturvasta ja luotettavuudesta on tullut erottamaton osa kehittäjän ammattitaitoa. Koska ohjelmistot ohjaavat yhä useammin kriittisiä fyysisiä laitteita ja liiketoimintaprosesseja, virheiden seuraukset voivat olla vakavia niin taloudellisesti kuin turvallisuudenkin kannalta. Kriittisyys ei ole vain tekninen ominaisuus, vaan se määrittyy ohjelmiston käyttöympäristön ja mahdollisten vaikutusten kautta. Tästä syystä turvallisuusvaatimukset ja järjestelmällinen varmennus on integroitava osaksi kehitysprosessia heti määrittelystä lähtien, jotta vältytään kalliilta korjausliikkeiltä projektin myöhemmissä vaiheissa.
Kokeneen kehittäjän rooli painottuukin nykyään koodin kirjoittamisen sijaan kokonaisarkkitehtuurin hallintaan ja riskien ennakointiin. Järjestelmien on kyettävä toipumaan virhetilanteista itsenäisesti, ja tekoälyavusteisen kehityksen myötä testauksen ja laadunvarmistuksen merkitys korostuu entisestään koodimassojen kasvaessa. Luotettavuus ei synny yksittäisistä testeistä, vaan se on pystyttävä perustelemaan koko kehityskaaren läpi ulottuvalla järjestelmällisyydellä. Viime kädessä kyse on yhteiskunnan huoltovarmuuden ja turvallisuuden rakentamisesta, jossa ohjelmistokehittäjä toimii keskeisenä kestävämpien ja ennakoitavampien järjestelmien luojana.
Luotettavien ohjelmistojen asiantuntija ja turvallisten tietoverkkojen ammattilainen.
We Rock IT!
