Julkaisin väärän johtopäätöksen AI:n kirjoittamasta koodista

Heinäkuussa annoimme Claude Codelle ja GitHub Copilot CLI:lle saman yhden sivun määrittelyn. Tehtävänä oli rakentaa laskujen hyväksyntäjärjestelmä. Ajoimme tehtävän kummallakin kolme kertaa.

Kuusi toteutusta. Jokainen kirjoitti myös omat testinsä, yhteensä 71 nimettyä testitapausta. Kaikki menivät läpi.

Julkaisimme kokeen koko aineistoineen. Kirjoitin ensimmäiseen analyysiin, että löysimme yhden oikean tietoturvaongelman: koodiin jätetyn oletussalaisuuden, jonka avulla kirjautumistunnisteen pystyi väärentämään. Löydös oli oikea. En vain ollut löytänyt läheskään kaikkea. Viikkoa myöhemmin valmistunut uusi katselmus osoitti, että analyysi piti korjata.

Kahden hyväksyjän sääntö oli helppo kiertää

Toisella kierroksella seurasimme käyttäjä- ja käyttöoikeuspolut läpi. Kuka saa luoda käyttäjän? Kuka saa tehdä itsestään hyväksyjän? Näkeekö kirjautunut käyttäjä vain omat laskunsa?

Neljässä järjestelmässä hyväksyjätilin pystyi luomaan ilman kirjautumista.

Järjestelmän piti vaatia yli 10 000 euron laskulle kaksi eri hyväksyjää. Koodissa tuo sääntö kyllä oli. Sama henkilö pystyi vain luomaan kaksi hyväksyjätiliä ja kiertämään koko kontrollin.

Viidessä pääsi lukemaan toisen käyttäjän laskut vaihtamalla osoiterivillä yhden numeron. Oma lasku on numero 16, kirjoitat 17, ja luet naapurin laskut. Kaikki kuusi muistivat kirjata laskun vastapuolen sähköpostiosoitteen lukemisen lokiin. Useimmat eivät tarkistaneet, saiko kyseinen käyttäjä nähdä sitä ylipäätään. Loki kirjasi luvattoman lukemisen kiltisti. Läpi se meni silti.

Testit eivät huomanneet näistä yhtäkään. 71/71, koko ajan. Nolla kuudesta oli turvallinen julkaistavaksi. Koodi ei muuttunut katselmusten välillä. Kysymykset muuttuivat.

Julkaisimme korjauksen ja koko lähdekoodiin sidotun tietoturvakatselmuksen. Koodista löytyi paljon korjattavaa. Eniten minua häiritsi silti oma ensimmäinen analyysini. Olin lopettanut tutkimisen, kun löysin ensimmäisen uskottavan vastauksen.

Tunnistan tilanteen vähän liiankin hyvin. Demo toimii, testit ovat vihreinä ja asiakas odottaa. Mennään eteenpäin.

Omat testit eivät haastaneet omia ratkaisuja

Varsinainen hyväksyntälogiikka teki sen, mitä määrittely pyysi: se esti oman laskun hyväksymisen ja vaati kahta eri käyttäjätunnusta. Määrittely ei kertonut, kuka saa luoda tunnuksia tai nähdä minkäkin laskun. Toteutukset täyttivät nämä aukot omilla ratkaisuillaan, eivätkä niiden omat testit haastaneet niitä.

Parempi määrittely ei silti ratkaise kaikkea. Yhdessä toteutuksessa 0,001 euron lasku kaatoi laskutuksen, vaikka määrittely vaati positiivisen summan ja koodi tarkisti sen. Pyöristys nollasi summan, ja tietokanta hylkäsi laskun. Sääntö oli koodissa. Testi, joka olisi rikkonut sen, puuttui.

Tuotantopäätös on eri työ

Pyysimme Claude Codelta ja Copilot CLI:ltä koodia ja testejä. Emme organisaation riskihyväksyntää emmekä päätöstä siitä, mitä tuotantoon viedään. Se päätös ei siirry työkalulle.

Vihreä testipaketti ei ole tuotantopäätös. Jäädytetyn version voi katselmoida, korjata ja hyväksyä myöhemmin. Näin tässä kokeessa kävikin.

Jos järjestelmä olisi ehditty viedä tuotantoon, jälkikäteinen katselmus ei enää kertoisi, mitä riskejä ennen julkaisua ymmärrettiin ja hyväksyttiin.

Mitä kilpailija ei saa ominaisuuden mukana?

AI nopeuttaa ensimmäisen version rakentamista, ja hyvä ominaisuus antaa siksi etumatkaa lyhyemmän ajan kuin ennen. Kuuden järjestelmän koe ei todista tätä. Se ei mitannut kehitysnopeutta, kustannusta eikä kilpailijoita.Rakentaminen, julkaiseminen, valvonta ja ylläpito ovat SaaS-yhtiön perustyötä. Se osa, jota ei voi kopioida, kertyy vasta julkaisun jälkeen. Kahden vuoden päästä yhtiö tuntee asiakkaidensa käytön ja tuotantonsa ongelmat. Se tietää myös, mihin aiemmat päätökset johtivat.

Historiasta on hyötyä vain, jos se vaikuttaa seuraaviin julkaisuihin. Siinä on minusta uusi vallihauta.

Kilpailija voi kopioida ominaisuuden. Hän ei saa mukaan asiakkaan luottamusta eikä tietoa siitä, miksi aiemmat muutokset tehtiin ja miten ne käyttäytyivät tuotannossa. Kahden vuoden kokemusta ei generoida torstai-iltana ennen perjantaiaamun hankintapalaveria.

Ottaisin seuraavaan johtoryhmään yhden julkaisun

Valitsisin yhden viime viikolla julkaistun muutoksen. En roadmapia tai yleistä tietoturvaraporttia, vaan yhden oikean tuotantojulkaisun.

1. Miksi muutos tehtiin, ja saavuttiko se tavoitteensa?
2. Mikä versio on nyt tuotannossa? Kertovatko koodi ja dokumentaatio samaa versiota?
3. Mitä riskejä julkaisu muutti? Jos henkilötietojen käsittely muuttui, näkyykö muutos DPIA:ssa ja riskirekisterissä?
4. Kuka hyväksyi jäljelle jääneet riskit?
5. Mikä muutos pysähtyi viimeksi ennen tuotantoa, ja miksi?
6. Mitä valvonta havaitsi julkaisun jälkeen, ja mitä tehtiin?

Vastausten ei tarvitse olla toimitusjohtajan muistissa. Niiden pitää koskea samaa versiota ja sopia yhteen. Jos koodi, dokumentaatio, riskirekisteri ja tuotantonäkymä kertovat eri tarinaa, teillä ei ole näyttöä. Teillä on neljä mielipidettä.

Näin tätä työtä tehdään Taigassa

Tässä kohtaa minulla on tietenkin oma lehmä ojassa.

Kokeessa ei käytetty Taigaa, joten se ei kerro, mitä julkaisuporttimme olisi toteutuksista löytänyt.

Juuri tätä varten Taiga on rakennettu. Sama versio kulkee rakentamisesta julkaisuun ja ylläpitoon, ja asiakas saa ylläpidetyn tuotanto-ohjelmiston palveluna. Ennen tuotantoa versio käy läpi julkisen 22 kohdan julkaisuportin. Julkaisun jälkeen taloon jäävät julkaisuhistoria, monitoroinnin havainnot ja niiden perusteella tehdyt
korjaukset.

Kun asiakas kysyy, mikä versio on tuotannossa ja millä perusteella se hyväksyttiin,
vastaus on jo olemassa.

Jatketaan SaaS-klubissa

SaaS-klubin webinaarissa 26.8. ”AI tappoi ominaisuuskilpailun – Mikä on uusi vallihauta?” pidän tunnin session ostajan näkökulmasta. Aloitan siitä, mitä ostaja ei enää katso, ja päädyn siihen, mitä hän katsoo sen sijaan. Välissä näytän oman tehtaamme sisältä myös ne kohdat, jotka menivät pieleen. Kuusi kysymystä ovat jo tässä jutussa. Käyn ne lopussa läpi, joten lue ne valmiiksi. Teknistä taustaa ei tarvita. Jatketaan tästä SaaS-klubissa.