Shahar Man, Backslash Securityn perustaja ja toimitusjohtaja – Haastattelusarja

Shahar Man, Backslash Securityn perustaja ja toimitusjohtaja, on kokenut teknologiajohtaja, jolla on syvä osaaminen pilvikehityksessä, kyberturvallisuudessa ja yrityssovelluksissa. Hän johtaa tällä hetkellä Backslash Securitya, yritystä, joka on keskittynyt suojaamaan AI-käyttöön perustuvia ohjelmistokehitysympäristöjä, suojaamalla kaikkea IDE:istä ja AI-agenteista generoituun koodiin ja ohjausvirtoihin. Aikaisemmin hän on toiminut johtavissa rooleissa Aqua Securityssa, jossa hän toimi sekä tuotepäällikkönä että tutkimus- ja kehityspäällikkönä, auttaen rakentamaan yhtä johtavista alustoista konttien turvallisuuden kehittämiseen kehityksen elinkaaren aikana. Uransa alussa Man työskenteli yli kymmenen vuotta SAP:illa, jossa hän johti kehitys- ja tuotealoitteita, kuten SAP Web IDE:tä, ja työskenteli läheisesti kansainvälisten yritysasiakkaiden kanssa, sekä osallistui kehittäjäekosysteemin kasvuun. Hänen uransa alkoi teknisissä ja johtamistehtävissä sekä startup-ympäristössä että Israelin puolustusteknologian yksiköissä, antaen hänelle vahvan perustan sekä insinöörintyöhön että laajamittaisiin järjestelmiin.

Backslash Security on nousussa oleva kyberturvallisuusalusta, joka on suunniteltu AI-vetämän ohjelmistokehityksen aikakaudeksi. Yritys keskittyy turvaamaan koko AI-käyttöön perustuvan kehityspino, mukaan lukien AI-agentit, koodigenerointiputkit ja modernit kehittäjätyövirrat, alue, jota perinteiset turvallisuustyökalut usein ohittavat. Tarjoamalla näkyvyyden, hallinnan ja reaaliaikaisen suojelun ilman kehittäjien työn hidastamista, Backslash pyrkii ratkaisemaan kasvavia riskejä, jotka johtuvat automaattisesta koodauksesta ja “vibe-koodauksen” ympäristöistä. Kun ohjelmistojen luominen siirtyy yhä enemmän AI-tukeisiin järjestelmiin, alusta on suunniteltu varmistamaan, että turvallisuus kehittyy rinnakkain sen sijaan, että se muodostuisi pullonkaulaksi, asettamalla Backslashin DevSecOpsin ja seuraavan sukupolven AI-kehityksen risteykseen.

Olet toiminut johtavissa rooleissa tuotteissa ja tutkimuksessa ja kehityksessä yrityksissä kuten Aqua Security ja SAP ennen Backslashin perustamista. Mitkä varhaiset signaalit vakuuttivat sinut siitä, että AI-käyttöön perustuva kehitys ja vibe-koodaus muuttavat perustavanlaatuisesti ohjelmistojen luomisen, ja että turvallisuuden on oltava uudelleenrakennettu tukeakseen sitä?

Olin jo kokenut yhden suuren muutoksen, kun ohjelmistot siirtyivät pilviin perustuvien arkkitehtuureiden pariin. SAP:illa ja myöhemmin Aqualla näimme ensimmäisin käsin, että kun kehitys muuttuu tässä määrin, turvallisuus usein jää jälkeen. AI on vienyt tämän totuuden aivan uudelle tasolle, ei ainoastaan siksi, että se voi auttaa kirjoittamaan koodia nopeammin, vaan siksi, että se on alkanut muuttaa koko ympäristöä ohjelmistojen luomisen ympärillä.

Turvallisuus on nyt vähemmän koodin itsensä suojelua ja enemmän ympäristön suojaamista. Alle vuoden sisällä siitä, mitä aiemmin oli suhteellisen rajattu ja matalan riskin kehitysasetelma, on laajentunut laajaan, hyvin kytkettyyn ja valvomattomaan hyökkäyspintaan. Kun tämä tapahtui, koodin haavoittuvuuksien turvallisuuskysymykset muuttuivat kokonaan. Todellinen ongelma ei ole se, onko tietty koodinpätkä haavoittuvainen. Ongelma on, että AI-vetämän kehityksen mahdollistamiseksi olemme esittäneet järjestelmiä, agenteja, integraatioita ja pääsyteitä, jotka ulottuvat koodin ulkopuolelle. Turvallisuus ei voi enää keskittyä ainoastaan koodin tuotokseen. Se on otettava huomioon koko ympäristö, joka mahdollistaa kyseisen koodin.

Kuvailet vibe-koodausta laajentavan hyökkäyspintaa koodin ulkopuolelle ohjelmointivinkkeihin, agenteihin, MCP-palvelimiin ja työkaluversioihin. Mitkä ovat suurimmat väärin ymmärretyt riskit tässä uudessa pinossa, joita kehittäjät ja turvallisuustiimit ovat tällä hetkellä laiminlyöneet?

Suurin väärin ymmärrys on, että monet tiimit ajattelevat, että riski elää pääasiassa generoituessa koodissa. Se on vain yksi kerros. AI-käyttöön perustuvassa kehityksessä riski esitetään aikaisemmin ja monissa muissa paikoissa. Tämä voi olla ohjelmointivinkkeissä, kontekstissa, joka annetaan mallille, agenteille myönnettyjen valtuuksien, MCP-palvelimien, joihin ne kytketään, tai ulkoisissa työkaluissa ja laajennuksissa, jotka laajentavat niiden ulottuvuutta. Yksittäisen käyttäjän kannettava tietokone voidaan ottaa haltuun ja käyttää laajemman hyökkäyksen aloituskohtana. Se on päätepisteen kipupiste, joka naamiintuu AI-koodauksen ongelman kaltaiseksi. Toisin kuin koodin haavoittuvuudet, tämä ei vaan aseta sovelluksia vaaraan – se voi asettaa koko organisaation vaaraan. Jos tarkastelet ainoastaan koodia, olet väärässä suurimman osan kuvasta.

Perinteinen sovellusturvallisuus on keskittynyt voimakkaasti koodin tarkasteluun. Miten turvallisuuden ajatteluun on tarttava kehittyä, kun AI-agentit generoivat, muokkaavat ja käyttävät koodia reaaliajassa?

Turvallisuuden on siirryttävä jaksollisesta tarkastelusta jatkuvaan valvontaan. Luottamuksen käsite on täysin rikki – voit luottaa malleihin ja MCP-palvelimiin, mutta AI:n epädeterministisen luonteen vuoksi ne voidaan manipuloida tai vain käyttäytyä odottamattomalla tavalla luodakseen odottamattoman riskin.

Tämä tarkoittaa myös, että on oltava mielenmuutos, jossa turvallisuus toimii kehitysprosessin rinnalla sen tapahtuessa ja on syvempi hallinto, esteet ja havaitseminen ja reagointikykyisyys kyseisessä ympäristössä. Se tarkoittaa myös kriittistä ajattelua siitä, mitkä työkalut ovat käytössä, minkälaista kontekstia ne kuluttavat, mitkä käytäntöjä niiden on noudatettava ja mitä toimia ne tekevät reaaliajassa.

Lisäksi emme voi jättää huomiotta AI:n ja AI-mallien roolia haavoittuvuuksien käsittelyssä. Jos vuosi sitten AI-mallit tuottivat paljon haavoittuvuuksia oletusarvoisesti, asiat ovat parantuneet dramaattisesti, ja muita malleja käytetään nyt löytämään nollapäivien haavoittuvuuksia, joita ei aiemmin löydetty. Niinpä olemme menossa kohti parempia tuloksia – mutta kuka valvoo myymälää, kun teemme sitä? Hyökkääjät etsivät muualta.

Työkalut kuten Cursor, Claude Code ja GitHub Copilot ovat muodostumassa kehittäjien työvirtojen standardiksi. Missä näet suurimmat turvallisuusaukot, kun tiimit ottaa nämä työkalut käyttöön ilman asianmukaista hallintakerrosta?

Suurin aukko on näkyvyys. Monissa organisaatioissa nämä työkalut leviävät nopeasti ilman virallista tarkastelua. Turvallisuustiimit eivät usein tiedä, mitkä agentit ovat käytössä, miten ne on määritetty, mihin dataan ne voivat päästä käsiksi tai mihin ulkoisiin järjestelmiin ne ovat kytketty. Se luo varjoteknologian ongelman, joka on periaatteessa sama kuin varjoteknologia, mutta nopeampi ja dynaamisempi.

Toiseksi suurin aukko on puuttuvat pakottavat käytäntöjä. Useimmat organisaatiot saattavat olla ohjeita, mutta ohjeet eivät auta paljon, kun kehittäjä liikkuu nopeasti IDE:ssä. Ilman hallintaa työkalu- ja työvirratasolla tiimit vaarantavat yli-valtuutetut työkalut, jotka eivät täytä yrityksen standardeja. Nämä työkalut eivät ole itsessään huonoja, mutta niiden omaksuminen ilman hallintaa tarkoittaa, että kehityksen nopeutta skaalataan ilman valvontaa.

Kolmas kehittyvä aukko on, että kuka tahansa voi potentiaalisesti tulla kehittäjäksi – mitä me kutsumme kansalaiskehittäjiksi, jotka käyttävät vibe-koodauksen työkaluja. Kun taloushenkilöstö käyttää Claude Codea prosessien automatisointiin ja yhdistää sisäisiin järjestelmiin, se luo potentiaalisen riskin ja on valtava sokea piste jopa tänään.

Backslash keskittyy turvaamaan koko AI-kehitys ekosysteemin sijaan yksittäisiä työkaluja. Miksi tämä full-stack-lähestymistapa on välttämätön, ja mitä tapahtuu, jos organisaatiot jatkavat kohtaamalla nämä riskit eristyneisesti?

Koska riski ei asetu siististi mihinkään yksittäiseen tuotteeseen pinossa. AI-käyttöön perustuva kehitys on luonteeltaan ekosysteemin ongelma, koska se toimii monissa eri paikoissa, käyttäen monia eri työkaluja. IDE, malli, agentit, MCP-palvelimet, ulkoiset laajennukset, identiteetit ja kytketyt tietolähteet kaikki vaikuttavat siihen, mitä luodaan ja miten. Organisaatiot eivät ole vakiinnuttaneet yksittäistä työkalua, koska heidän suhteelliset vahvuutensa muuttuvat nopeasti. Jos turvalliset vain yhden pisteessä ketjussa, sinun on yhä väärä kuva siitä, miten riski liikkuu järjestelmän läpi.

Riskien käsittely eristyneisesti johtaa fragmentoituihin puolustuksiin ja vaarallisiin sokeisiin pisteisiin. Voit lujittaa koodin skannauksen, mutta ohittaa MCP-palvelimen, joka syötti riskialttiita tietoja malliin. Se on, miksi uskomme, että oikea lähestymistapa on full-stack-näkyvyys ja reaaliaikainen suojelu koko AI-kehitys ekosysteemin yli. Muuten organisaatiot jatkavat oireiden ratkaisemista, kun itse hyökkäyspinta jatkaa laajentumistaan heidän allaan.

Ohjelmointivinkit ovat nousemassa uutena ohjelmoitavuuden kerroksena. Miten organisaatioiden on lähestyttävä ohjelmointivinkkien turvallisuutta ja estettävä ongelmia, kuten ohjelmointivinkkien injektio, datavuoto tai manipulointi?

Ohjelmointivinkit muotoilevat yhä enemmän logiikkaa ja käyttäytymistä. Monissa tapauksissa ne ovat käytännössä uusi ohjauskerros ohjelmistojen luomiselle. Se tarkoittaa, että niiden on oltava käytäntö, valvonta ja esteet, kuten koodille tai infrastruktuurimäärityksille. Käytännössä se alkaa rajoittamalla sitä, mihin ohjelmointivinkit voivat päästä käsiksi ja mitä alihankkeita ne voivat laukaista. Se tarkoittaa myös määrittämistä ohjelmointivinkkisääntöjä, jotka ovat linjassa turvallisuuden ja laadun odotuksilla, estämistä herkkien tietojen paljastumista kontekstiuikkunoista ja valvontaa manipulointiyrityksistä, kuten ohjelmointivinkkien injektio tai epäsuora ohjauskaappaus. Ja se sisältää myös varmistamisen, että säännöt itsessään eivät ole käytetty ohjelmointivinkkien injektion takaporttina. Laajempi pointti on, että et turvaa ohjelmointivinkkejä ohjeistamalla kehittäjiä ja agenteja “ole varovainen”. Turvaa ohjelmointivinkkejä upottamalla valvontaa ympäristöön, jossa ohjelmointivinkit todella tapahtuvat.

MCP-palvelimet ja agenttien taidot esittävät dynaamisia yhteyksiä järjestelmien välillä. Turvallisuuden näkökulmasta edustavatko ne suurimman uuden riskivektorin AI-vetämässä kehityksessä?

MCP-palvelimet ja agenttien taidot edustavat suurta uutta riskikerrosta, koska ne määrittävät, miten AI-järjestelmät kytketään ja vuorovaikuttavat todellisen maailman kanssa. Taidot määrittävät, mitä agentti on valtuutettu tekemään, kun taas MCP laajentaa sen pääsyä kontekstiin ja järjestelmiin. Yhdessä ne muotoilevat agentin todellista käyttäytymistä. Jos nämä kerrokset eivät ole tiukasti hallinnassa, organisaatiot menettävät näkyvyyden siihen, mihin heidän AI-työkalunsa pystyvät ja mitä he todella tekevät. Siirtymä koodin generoimisesta toiminnan suorittamiseen on se, mikä tekee tämän niin kriittiseksi alueeksi turvallisuudelle, ja se tulee epävarmaksi, kun niitä ketjetään yhteen.

Yksi sinun keskeisistä teemoista on “oleva yes-osasto” – turvallisuuden mahdollistaminen ilman kehittäjien hidastamista. Miten balanssit reaaliaikaisen suojelun ja kehittäjien nopeuden välillä ympäristöissä, joissa nopeus on kriittinen?

Turvallisuus luo kitkaa, kun se tapahtuu myöhään tai on irrotettu siitä, miten kehittäjät todella työskentelevät. Se tulee paljon tehokkaammaksi, kun se on upotettu suoraan työvirran ja keskittyneeseen siihen, mitä todella on tärkeää. Tämä on ollut osa ajattelutapaa Backslashin alusta alkaen, ja se on tärkeämpää kuin koskaan AI-vetämässä kehityksessä.

Käytännössä se tarkoittaa esittämistä vain harvoja ongelmia, jotka edustavat todellista riskiä, eikä tulvaa kehittäjiä kaikella, mikä näyttää teoreettisesti epäilyttävältä. Se tarkoittaa myös käytäntöjen pakottamista IDE:ssä ja agenttityövirrassa, ei jälkikäteen. Ja se tarkoittaa myös läpinäkyvien, determinististen esteiden luomista, jotta tiimit voivat liikkua nopeasti, tietäen, mitkä työkalut ovat käytössä, mitkä valtuudet niillä on ja milloin jotain epätavallista tapahtuu. Tavoitteena ei ole hidastaa AI:n omaksumista, vaan auttaa organisaatioita omaksumaan sitä luottavaisesti ilman valvonnan menettämistä. Käytännössä se tarkoittaa, että kehittäjällä on vähemmän tilaa tehdä virheitä ensimmäisen kerran, mutta jos hän tekee virheen, se havaitaan ja käsitellään nopeasti.

Näemme yhä enemmän ei-tekniikkaa käyttäviä henkilöitä, jotka rakentavat ohjelmistoa AI-työkalujen avulla. Miten ei-kehittäjien vibe-koodaajien nousu muuttaa uhkauskuvaa?

Se laajentaa uhkauskuvaa kahdella tavalla. Ensinnäkin se lisää dramaattisesti määrää ihmisiä, jotka voivat tuottaa ohjelmistokaltaisia tuloksia ymmärtämättä turvallisuuden vaikutuksia. Toiseksi se luo väärän turvallisuuden tunteen, koska työkalut tekevät kehityksestä keskustelumaisen ja matalan kitkan prosessin.

Se tarkoittaa, että organisaatiot näkevät enemmän sovelluksia, automaatioita ja integraatioita, jotka on luotu henkilöiden toimesta, jotka eivät ole koulutettuina tietämään luottamuksen rajoja, syötteen validointia, riippuvuuden hygieniaa, pääsyoikeuksien hallintaa tai tietojen paljastumista. Toisin sanoen hyökkäyspinta laajenee ei ainoastaan siksi, että AI kirjoittaa enemmän koodia, vaan koska enemmän ihmisiä voi nyt luoda työvirtoja ja järjestelmiä, jotka käyttäytyvät ohjelmistojen kaltaisesti ilman perusinsinöörintutkintaa. Se tekee näkyvyyden ja sisäänrakennetut varmistukset entistä tärkeämmiksi, koska et voi enää olettaa turvallisuustietämystä luomisen kohdassa.

Etäältä 12-24 kuukauden päähän, mitä hyökkäyksiä tai haavoittuvuuksia odotat nousevan erityisesti AI-käyttöön perustuvista kehitysvirroista?

Odotamme, että monet yleiset koodin haavoittuvuudet voidaan välttää aluksi parantamalla LLM:itä itse tai paremmin upotettujen ohjelmointivinkkisääntöjen kautta “harness”-työkaluissa, jotka ympäröivät nämä työkalut. Jos viime vuonna AI-mallit tuottivat paljon haavoittuvuuksia oletusarvoisesti, asiat ovat parantuneet dramaattisesti, ja toisia malleja käytetään nyt löytämään nollapäivien haavoittuvuuksia, joita ei aiemmin löydetty. Niinpä olemme menossa kohti parempia tuloksia – mutta mitä ei korjata, se jaetaan AI-kiihdytetyn SAST- ja SCA:n (jotkut niistä tarjoavat AI-alustojen myyjät, esim. Claude Code Security ja projekti Glasswing) kautta.

Kuitenkin odotan paljon huonompia lopputuloksia, kun on kyse altistumisista, jotka johtuvat avoimen lähdekoodin agenttien (OpenClaw on hyvä esimerkki) käytöstä sovelluksen kehityksessä – joilla on huonot turvallisuus oletukset yhdistettynä käyttäjäkuntaan, jonka turvallisuustietämys on paljon heikompaa kuin heidän vibe-koodaukseen liittyvä innostuksensa.

Seurauksena odotan, että hyökkäykset siirtyvät kehitys ekosysteemin itse kohti eikä ainoastaan tuotantojärjestelmiä. Kun AI tulee osaksi ohjelmistojen luomista, hyökkääjät keskittyvät manipuloimaan työkaluja ja yhteyksiä, jotka muotoilevat kyseisen prosessin, tehden ohjelmistot turvattaviksi ennen kuin ne on koskaan käyttöön otettu.

Kiitos hienosta haastattelusta, lukijat, jotka haluavat oppia lisää, kannattaa vierailla Backslash Security-sivustolla.