Tekoäly muuttaa, kuka päättää, mitkä ohjelmistot pääsevät organisaatioon

Tekoäly on jo osa ohjelmistokehityksen arkipäivää. Ohjelmistokehittäjät luottavat tekoälyavustajiin, jotka auttavat heitä ratkaisemaan ongelmia ja toimittamaan ohjelmistoa nopeammin kuin koskaan aiemmin. Tuottavuuden parantuminen on kiistatonta, ja organisaatiot omaksuvat tekoälyn nopeasti koko ohjelmistokehityksen elinkaaren aikana.

Suurin osa keskustelusta on keskittynyt tekoälyn tuottamaan koodiin. Voivatko kehittäjät luottaa tekoälyllä tuotettuun koodiin? Tuottaa se haavoittuvuuksia? Miten turvallisuustiimit tulisi tarkastaa sitä? Nämä kysymykset ovat tärkeitä, mutta ne eivät ole suurin muutos, jonka tekoäly tuo ohjelmistokehitykseen. Tekoäly on edennyt koodin tuottamisesta ja vaikuttaa yhä enemmän siihen, mitkä ohjelmistot pääsevät organisaatioon.

Tekoälyavustajat harvoin rakentavat sovelluksia alusta alkaen, vaan ne koostavat ratkaisuja olemassa olevien kehysten, avoimen lähdekoodin kirjastojen, SDK:iden, konttikuvajen ja pakkausjärjestelmien avulla. Jokainen suositus muotoilee ohjelmiston perustaa, usein ennen kuin kehittäjä tarkastelee ensimmäistä koodiriviä.

Vuosikymmenien ajan ohjelmistokehityksen ensimmäinen luottamuspaatos kuului lähes kokonaan kehittäjille, mutta nyt tämä oletus alkaa muuttua. Yhä useammin tekoäly tekee ensimmäisen suosituksen, kun taas kehittäjät tarkastavat tuloksen myöhemmin. Tämä pieni muutos on merkittävä ohjelmistotuotantoketjun turvallisuuden kannalta, koska jokainen suositus sisältää implisiittisen luottamuspaatoksen.

Organisaatiot ovat viettäneet vuosia ohjelmistojen kehittämisen, testaamisen ja käyttöönoton sääntelyyn. Seuraava haaste on ohjelmistojen valinnan sääntely tekoälyominaisessa kehitysympäristössä.

Ensimmäinen luottamuspaatos

Jokainen sovellus riippuu ohjelmistoista, joita on luonut tuhannet avustajat lukuisissa avoimen lähdekoodin projekteissa. Ennen uuden riippuvuuden ottamista, kehittäjät arvioivat yleensä dokumentaatiota, vertasivat kehyksiä, tarkastivat yhteisön omaksumista, tarkastivat julkaisutahti ja miettivät, onko projekti tarpeeksi kypsä tuotantoon. Kehittäjät eivät aina tehneet oikein valintaa, mutta jokainen riippuvuus otettiin tietoisesti.

Nykyään kehittäjä voi yksinkertaisesti pyytää tekoälyavustajaa “rakentamaan turvallisen REST-rajapinnan, jossa on todennus ja PostgreSQL-tuki.” Muutamassa sekunnissa tekoäly luo toimivan projektin. Sen aikana se suosittelee suoritusaikaa, valitsee kehyksen, viittaa peruskonttikuvan, tuo todennuskirjastot, valitsee SDK:t ja luo riippuvuusmanifesteja, kuten package.json, requirements.txt tai pom.xml. Pakkausjärjestelmät ratkaisevat nämä riippuvuudet ja niiden transitiiviset riippuvuudet kokoamisprosessin aikana.

Useimmat kehittäjät tarkastelevat sovellusta, jonka tekoäly tuottaa, mutta vain harvat pysähtyvät tarkastelemaan jokaista ohjelmistopäätöstä, jonka tekoäly tekee matkalla. Tekoäly on pakannut ohjelmistovalinnan, joka aiemmin vei tunteja tutkimiseen, sekunneiksi, ja se tekee yhä useammin ensimmäisen suosituksen kehittäjien puolesta.

Jokainen suositus on luottamuspaatos

Jokaisella ohjelmistokomponentilla on oma luottamusketjunsä. Kirjastolla on ylläpitäjiä, avustajia, julkaisuprosesseja, allekirjoitustapoja, riippuvuuksia ja alkuperää. Konttikuvasta periytyy ohjelmistoa ylävirroista jakeluista, ja SDK tuo mukanaan lisää paketteja, jotka laajentavat luottamusketjua.

Yksi tekoälyn suositus voi nopeasti laajentua satoihin ohjelmistokomponentteihin, jotka tulevat osaksi sovellusta. Avoin lähdekoodi on aina toiminut tällä tavalla. Mitä muuttuu, on se, kuka tekee nämä luottamuspaatokset ensin. Historiallisesti kehittäjät arvioivat ja valitsivat komponentit, joissa he luottivat. Yhä useammin tekoälyjärjestelmät tekevät alkuperäiset suositukset, kun taas kehittäjät tarkastavat tuloksen myöhemmin.

Se kuulostaa pieneltä muutokselta, mutta se muuttaa perustavasti sitä, miten organisaatioiden tulisi ajatella ohjelmistotuotantoketjun turvallisuudesta.

Tehtäväkohtaisuus optimoi toimivaa ohjelmistoa, ei organisaatioiden luottamusta

Tämä ei tarkoita, että tekoäly tekee huonoja suosituksia. Päinvastoin.

Koodin tuottavat tekoälyavustajat ovat hyviä suosittamaan ohjelmistoa, koska ne ovat oppineet miljoonista esimerkeistä, joissa kehittäjät ratkaisevat samanlaisia ongelmia. Tämän seurauksena suositut kehykset, hyvin tuetut kirjastot ja tutut toteutusmallit luonnollisesti ilmestyvät niiden ehdotuksiin, ja juuri tämä tekee näistä työkaluista niin arvokkaita.

Mutta nämä optimointitavoitteet ovat perustavasti erilaisia kuin ne kysymykset, joita yritysten turvallisuustiimit tarvitsevat vastauksia. Tekoäly ei sisällä arviointia siitä, onko paketti linjassa organisaation ohjelmistopolitiikassa, onko konttikuvaa uudelleenrakennettu lähteestä, onko ohjelmistojen alkuperä varmistettu tai onko riippuvuus peräisin hyväksytystä ohjelmistolähteestä.

Toiminnallisuus, suosittelu ja todennäköisyys ovat hyödyllisiä signaaleja koodin tuottamiseen, mutta niitä ei pidä käyttää korvikkeena varmistamiselle.

Miksi meidän on integroida vasemmalle

Vuosien ajan ohjelmistotuotantoketjun turvallisuus on keskittynyt riskien tunnistamiseen ohjelmiston päästyä kehitysprosessiin. Haavoittuvuuskannoissa, ohjelmistojen koostumisen analyysissä ja SBOMeissa on parannettu merkittävästi ohjelmistojen näkyvyyttä sovelluksissa.

Nämä työkalut ovat edelleen olennaisia, mutta ne käsittelevät eri osaa ongelmaa.

Tekoäly siirtää ohjelmistovalinnan paljon aikaisemmaksi kehitysvaiheeseen, joten kun perinteiset turvallisuusohjaimet alkavat analyysiään, generoitu projekti voi jo viitata kymmeniin riippuvuuksiin, jotka vaativat arviointia, korjausta tai korvaamista. Organisaatiot reagoivat edelleen ohjelmistovalintoihin, jotka ovat jo tulleet kehitystyönkulkuihin.

Tämän vuoksi uskon, että organisaatioiden on integroida vasemmalle.

Integroida vasemmalle -ajatuksen taustalla on yksinkertainen periaate: luottamus on asetettava ennen kuin ohjelmisto tulee osaksi sovellusta, ei sen jälkeen. Kun tekoäly osallistuu ohjelmistokehitykseen, tämä periaate tulee entistä tärkeämmäksi. Sääntely on siirrettävä siihen pisteeseen, missä ohjelmistoa valitaan, ei siihen, missä se skannataan lopulta.

Organisaatioiden on määriteltävä luotettavat ohjelmistolähteet, määriteltävä, mitkä ohjelmistokomponentit tekoäly saa suositella, ja varmistettava näiden komponenttien turvallisuus ennen kuin ne tulevat kehitystyönkulkuihin. Tavoitteena on varmistaa, että tekoäly kiihdyttää ohjelmistojen toimittamista turvallisuuden, yhdenmukaisuuden ja insinööritasojen puitteissa.

Ohjelmistojen valinnan sääntely tekoälyaikakaudella

Organisaatiot määrittelevät jo, missä ohjelmistot voivat suorittaa, miten ne käyttöönotetaan ja kuka on valtuutettu niiden julkaisemiseen. Yhä useammin heidän on määriteltävä myös, mitä ohjelmistoa tekoäly on sallittu suositella.

Tässä ohjelmistotuotantoketjun asenema tulee yhä tärkeämmäksi. Organisaatioiden on oltava varmoja siitä, että heillä on luottamus siihen ohjelmistoon, jonka he itse kehittävät, mutta myös siihen ohjelmistoon, jonka tekoäly suosittelee heidän puolestaan. Tämä luottamus perustuu varmistamiseen, luotettaviin ohjelmistolähteisiin ja sääntelyyn, joka alkaa ennen kuin ohjelmisto tulee kehitystyönkulkuihin.

Tekoäly jatkaa ohjelmistokehityksen muuttamista, ja se on oikein. Tuottavuuden parantuminen on liian merkittävää, jotta sitä voisi jättää huomiotta, mutta kun organisaatiot omaksuvat tekoälyominaisen kehityksen, heidän on tunnustettava, että ohjelmistojen valinta on yhä enemmän automaattista.

Onnistujat ovat niitä, jotka määrittelevät luotettavat ohjelmistolähteet, varmistavat tekoälyn suosittelemat ohjelmistokomponentit ja integroivat sääntelyn ohjelmistojen valintaan alusta alkaen.

Tekoäly muuttaa, miten ohjelmistot kehitetään, mutta nyt, tärkeämpää, se muuttaa, miten ohjelmistot valitaan. Koska tekoälyaikakaudella luotettavat ohjelmistot riippuvat yhä enemmän siitä, mitä ohjelmistoa tekoäly valitsee ensin.