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, joka on yritys, joka keskittyy suojaamaan AI-käyttöön perustuvia ohjelmistokehitysympäristöjä, suojaamalla kaikkea IDE:istä ja AI-agenteista generoituun koodiin ja ohjausvirtoihin. Ennen tätä hän toimi johtavissa rooleissa Aqua Securityssa, jossa hän toimi tuotejohtamisen ja tutkimus- ja kehitysjohtajana, auttaen rakentamaan yhden johtavista alustoista konttin turvallisuuden kehityksen elinkaaren aikana. Uransa alussa hän työskenteli yli kymmenen vuotta SAP:lla, jossa hän johti kehitys- ja tuotealoitteita, mukaan lukien SAP Web IDE, ja työskenteli läheisesti globaaleiden 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 uusi kyberturvallisuusalusta, joka on suunniteltu AI-vetämän ohjelmistokehityksen aikakaudelle. Yritys keskittyy suojaamaan koko AI-käyttöön perustuvan kehityspinoa, mukaan lukien AI-agenteja, koodigeneraatioputkia ja modernia kehittäjien työvirtoja, aluetta, jota perinteiset turvallisuustyökalut usein ohittavat. Tarjoamalla näkyvyyden, hallinnan ja reaaliaikaisen suojauksen ilman kehittäjien työn hidastamista, Backslash pyrkii ratkaisemaan kasvavia riskejä, jotka johtuvat automaattisesta koodauksesta ja “vibe-koodauksesta”. Koska ohjelmistojen luominen siirtyy yhä enemmän AI-tukeisiin järjestelmiin, alusta on suunniteltu varmistamaan, että turvallisuus kehittyy rinnakkain eikä muodostu pullonkaulaksi, asemoittaen Backslashin DevSecOpsin ja seuraavan sukupolven AI-kehityksen risteykseen.

Olet toiminut johtavissa rooleissa tuote- ja tutkimus- ja kehitystoiminnassa 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 perustavasti ohjelmistojen luomista, ja että turvallisuuden on oltava uudelleenrakennettu tukeakseen tätä?

Olin jo kokenut yhden suuren muutoksen, kun ohjelmistot siirtyivät pilviin. SAP:lla 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 vain 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 vuodessa siitä, mitä aiemmin oli suhteellisen rajattu ja matalan riskin kehitysasetelma, on laajentunut laajaan, hyvin kytkettyyn hyökkäyspintaan, jossa on vähän valvontaa tai hallintaa. Kun tämä tapahtui, turvallisuuskysymykset koodin haavoittuvuuksista muuttuivat kokonaan. Todellinen ongelma ei ole se, onko tietty koodinpätkä haavoittuvainen. Ongelma on, että AI-vetämässä kehityksessä olemme esittäneet järjestelmiä, agenteja, integraatioita ja pääsyteitä, jotka ulottuvat kauemmas kuin koodi itsessään. Turvallisuus ei voi enää keskittyä vain koodin tuloksiin. Se on otettava huomioon koko ympäristö, joka mahdollistaa sen koodin.

Kuvailet vibe-koodausta laajentavan hyökkäyspintaa koodin ulkopuolelle, mukaan lukien ohjauslauseet, agentit, MCP-palvelimet ja työkaluversiot. Mitkä ovat suurimmat väärinymmärrettyjä riskejä tässä uudessa pinossa, joita kehittäjät ja turvallisuustiimit ovat tällä hetkellä ohittamassa?

Suurin väärinymmärrys on, että monet tiimit ajattelevat, että riski elää pääasiassa generoidussa koodissa. Se on vain yksi kerros. AI-käyttöön perustuvassa kehityksessä riski esitetään aikaisemmin ja monissa muissa paikoissa. Tämä voi olla ohjauslauseissa, mallin kontekstissa, agenteille myönnettyjen valtuuksien määrässä, MCP-palvelimissa, 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 sillanpäänä. Se on päätepisteen kipupiste, joka maskeeraa itsensä AI-koodauksena. Toisin kuin koodin haavoittuvuudet, tämä ei vaan aseta sovelluksia vaarantuneiksi – se voi asettaa koko organisaation vaarantuneeksi. Jos vain tarkastelet koodia, olet väärässä suurimman osan kuvasta.

Perinteinen sovellusturvallisuus on keskittynyt voimakkaasti koodin tarkasteluun. Miten turvallisuuden ajattelun on kehittynä, kun AI-agenteja generoi, muokkaa ja ottaa käyttöön 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 mielentilamuutos, jossa turvallisuus toimii kehitysprosessin rinnalla sen tapahtuessa ja on syvempi hallinta, esteet ja havaitseminen ja reagointikapasiteetit kyseisessä ympäristössä. Se tarkoittaa kriittistä ajattelua siitä, mitkä työkalut ovat käytössä, mitä 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 antoivat paljon haavoittuvuuksia oletusarvoisesti, asiat ovat parantuneet dramaattisesti, ja muita malleja käytetään nyt löytämään nollapäivän haavoittuvuuksia, joita ei aiemmin löydetty. Niinpä olemme menossa kohti parempia tuloksia – mutta kuka valvoo kauppaa, kun teemme sitä? Hyökkääjät etsivät muualta.

Työkalut kuten Cursor, Claude Code ja GitHub Copilot ovat muodostumassa standardiksi kehittäjien työvirroissa. 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 pääsevät käsiksi tai mihin ulkoisiin järjestelmiin ne ovat kytketty. Se luo varjotun AI-ongelman, joka on periaatteessa samanlainen kuin varjotun IT, vain nopeampi ja dynaamisempi.

Toiseksi suurin aukko on puutteellinen valvottavissa olevat käytäntöjä. Useimmat organisaatiot saattavat olla ohjeita, mutta ohjeet eivät auta paljonkaan, 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 pahasta, mutta niiden omaksuminen ilman hallintaa tarkoittaa, että kehityksen nopeus skaalautuu ilman valvontaa.

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

Backslash keskittyy suojaamaan koko AI-kehitysEkosysteemiä yksittäisten työkalujen sijaan. Miksi tämä full-stack-lähestymistapa on välttämätön, ja mitä tapahtuu, jos organisaatiot jatkavat käsittelemällä nämä riskit eristyneinä?

Koska riski ei asetu siististi mihinkään yksittäiseen tuotteeseen pinossa. AI-käyttöön perustuva kehitys on luonteeltaan ekosysteemi-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 niin nopeasti. Jos turvalliset vain yhden pisteessä ketjussa, sinun on edelleen ymmärrettävä, miten riski liikkuu järjestelmän läpi.

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

Ohjauslauseet ovat nousemassa uutena ohjelmointikerroksena. Miten organisaatioiden on lähestyttävä ohjauslauseiden suojaamista ja estettävä ongelmia, kuten ohjauslauseen injektio, datavuoto tai manipulointi?

Ohjauslauseet 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öjä, valvontaa ja esteitä, kuten koodille tai infrastruktuurimäärityksille. Käytännössä se alkaa rajoittamalla sitä, mihin ohjauslauseet voivat päästä ja mitkä alisuoritukset ne voivat laukaista. Se tarkoittaa myös ohjauslauseiden määrittelyä, jotka ovat linjassa turvallisuuden ja laadun odotuksilla, estämällä herkkien tietojen paljastamista kontekstiuikkunoista ja valvomalla manipulointiyrityksiä, kuten ohjauslauseen injektio tai epäsuora ohjauskaappaus. Ja se sisältää myös varmistamisen, että itse ohjauslauseet eivät ole käytetty ohjauslauseen injektion takaporttina. Laajempi asia on, että et suojaat ohjauslauseita neuvomalla kehittäjiä ja agenteja “ole varovainen”. Sinun on upotettava valvonta ympäristöön, jossa ohjauslauseet todella tapahtuvat.

MCP-palvelimet ja agenttien taidot esittelevät dynaamiset yhteydet järjestelmien välillä. Turvallisuuden kannalta 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 todelliseen maailmaan. 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 ne tulevat epävarmemmiksi, kun niitä ketjuutetaan yhteen.

Yksi sinun keskeisistä teemoista on “oleva osasto Kyllä” – mahdollistaen turvallisuuden ilman kehittäjien hidastamista. Miten tasapainotat reaaliaikaisen suojauksen kehittäjien nopeuden kanssa ympäristöissä, joissa nopeus on kriittistä?

Turvallisuus luo kitkaa, kun se tapahtuu myöhässä tai on irrotettu siitä, miten kehittäjät todella työskentelevät. Se tulee paljon tehokkaammaksi, kun se on upotettu suoraan työvirran sisään ja keskittyy siihen, mikä todella on tärkeää. Se on ollut osa ajattelutapaa siitä lähtien, kun Backslash aloitti, ja se on tärkeämpää nyt AI-vetämässä kehityksessä.

Käytännössä se tarkoittaa, että sinun on tuotettava ne harvat ongelmat, jotka edustavat todellista riskiä, eikä tulvata kehittäjiä kaikella teoreettisesti epäilyttävällä. Se tarkoittaa käytäntöjen pakottamista IDE:ssä ja agenttityövirrassa, ei jälkikäteen. Ja se tarkoittaa 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-omaksumista, vaan auttaa organisaatioita omaksumaan sitä luottavaisesti ilman hallinnan menettämistä. Todellisissa termeissä se tarkoittaa, että kehittäjällä on vähemmän tilaa tehdä virheitä ensimmäisessä paikassa, 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ä rakentamassa ohjelmistoa AI-työkalujen avulla. Miten ei-kehittäjien vibe-koodareiden nousu muuttaa uhkauskuvaa?

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

Se tarkoittaa, että organisaatiot näkevät enemmän sovelluksia, automaatioita ja integraatioita, joita luovat henkilöt, jotka eivät ole koulutettu huomioimaan turvallisuusrajoja, syötteen validointia, riippuvuushygieniaa, pääsyä ja datan paljastamista. Toisin sanoen hyökkäyspinta laajenee ei vain 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 perustavaa insinöörien hygieniaa. Se tekee näkyvyyden ja sisäänrakennetun varmistuksen entistä tärkeämmäksi, koska et voi enää olettaa turvallisuustietoutta luomisen kohdalla.

Etäältä 12-24 kuukauden päähän, mitä hyökkäyksiä tai haavoittuvuuksia odotat nousevan nimenomaan AI-käyttöön perustuvien kehitystyövirtojen vuoksi?

Odotamme, että monet yleiset koodin haavoittuvuudet voidaan välttää etukäteen parantuneiden LLM:ien ansiosta tai paremmin upotettujen ohjauslauseiden sääntöjen ansiosta “harness”-työkaluissa, jotka ympäröivät nämä työkalut. Jos viime vuonna AI-mallit antoivat paljon haavoittuvuuksia oletusarvoisesti, asiat ovat parantuneet dramaattisesti, ja toisia malleja käytetään nyt löytämään nollapäivän haavoittuvuuksia, joita ei aiemmin löydetty. Ja mitä ei korjata, sitä jaetaan AI-kiihdytetyn SAST- ja SCA:n (jotkut niistä tarjoavat myös AI-alustojen myyjät, esim. Claude Code Security ja projekti Glasswing) avulla.

Kuitenkin odotan paljon huonompia lopputuloksia, kun otetaan huomioon altistuminen aiemmin käyttämättömien ja valvomattomien AI-työkalujen käytölle sovelluksen kehityksessä – kuten avoimen lähdekoodin agenteja (OpenClaw on hyvä esimerkki), joilla on hyvin heikko turvallisuus oletusarvojen kanssa ja käyttäjäkunta, jonka turvallisuustietous on paljon jäljessä heidän vibe-koodauksen innostustaan.

Seurauksena odotan, että hyökkäykset siirtyvät kehitysEkosysteemin itse kohtaan eikä vain tuotantojärjestelmiin. Kun AI tulee osaksi sitä, miten ohjelmistoja luodaan, hyökkääjät tulevat keskittymään manipuloimaan työkaluja ja yhteyksiä, jotka muotoilevat prosessin, tehden ohjelmistot vaarantuneiksi ennen kuin ne on koskaan käyttöön otettu.

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