Ronen Slavin, CTO og medgrunnlegger, Cycode – Intervju-serie

Ronen Slavin, CTO og medgrunnlegger, Cycode, er en serial entrepreneur og tidligere Unit 8200-offiser i Israels forsvar. Før han lanserte Cycode i 2019, var han medgrunnlegger av FileLock, som ble kjøpt opp av Reason Security i 2018, og han var også leder for forskning ved Reason Cybersecurity. Med dypt ekspertise i malware-oppdaging, sårbarhetsforskning og utnyttelse, har Slavin bygget en karriere i skjæringspunktet mellom avansert sikkerhetsforskning og produktinnovasjon.

Cycode er en AI-nativ applikasjonssikkerhetsplattform som forener sikkerhets- og utviklingsteam med handlebare kontekster fra kode til kjøretid. Ved å konvergere AST, ASPM og programvareforsyningskjede-sikkerhet, sikrer den både AI- og menneske-generert kode. Drevet av sin Risk Intelligence Graph (RIG), proprietære skannere og integrasjoner, tilbyr Cycode øyeblikkelig risikodeteksjon, Endring av Impaktanalyse (CIA) og AI-drevne fikser—lukker synsgap, akselerer retting og reduserer kostnader fra dag én.

Hva motiverte deg til å starte Cycode, og hvilket nøkkelproblem i programvaresikkerhet var du rettet mot å løse fra begynnelsen?

Idéen til Cycode oppstod fra noe vi hadde observert gjentatte ganger; kildekoden ble stjålet eller utilsiktet lekket til feil hender. Etter å ha tilbragt år i cybersikkerhet og offensiv sikkerhetsrom, og ledet endpoint-beskyttelse hos Reason, kom vi til å forstå hvor kritisk kildekoden var—ikke bare som kode, men som ett av et selskaps mest verdifulle aktiva. Det var ikke å få den sikkerheten det fortjente.

Denne øyeblikksopplysningen var det som inspirerte meg til å starte Cycode. Fra starten var vår misjon klar: beskytte kildekoden på hver fase, fra øyeblikket den skrives til øyeblikket den sendes, alt uten å hemme utviklerens drivkraft og fremdrift. Vi satte oss fore å sikre at sikkerhet og ingeniørarbeid kunne fungere side om side, med sikkerhet som var sømløst integrert i den daglige arbeidsflyten, i stedet for å være en hindring.

Hva betød mest var å gi teamene synlighet, ansvar og samarbeid de trengte. Utviklere burde ikke måtte ofre sin produktivitet for sikkerhet, og sikkerhetsteam burde ikke måtte fungere uten kontekst eller kontroll. Cycode ble skapt for å gjøre begge mulig.

Hvordan har din tidligere erfaring som cybersikkerhets-entrepreneur og din tjeneste i Israels elite-intelligence-enhet, Unit 8200, formet din tekniske tilnærming hos Cycode?

Min tid i Israels cybersikkerhets-økosystem, spesielt i tekniske miljøer, innprentet en holdning av presisjon, tilpasning og ustopperlig nysgjerrighet. Uansett om jeg var i Unit 8200 eller i mine tidlige startup-dager, lærte jeg å tenke som både en angriper og en forsvarer. Den doble perspektivet har vært grunnleggende for hvordan vi bygget Cycode.

Som en cybersikkerhets-entrepreneur, så jeg først hånd hvordan fragmentert og reaktivt sikkerhetslandskapet hadde blitt. Sikkerhetstverktøy var ofte boltet på etterpå, og lot utviklere navigere en labyrint av varsler uten kontekst. Det var det vi satte oss fore å endre.

Hos Cycode har vi tatt en systems-nivå-tilnærming, behandlet kildekoden som et kritisk aktivum og bygget sikkerhet inn i programvareutviklingslivssyklusen fra bunnen av. Min bakgrunn har lært meg at sikkerhet må være proaktiv, kontekstuell og utvikler-vennlig. Derfor fokuserer vi så mye på automatisering, synlighet og å lukke gapet mellom sikkerhet og programvareutvikling. Det handler ikke bare om å finne sårbarheter, men om å fikse hva som betyr noe, raskt.

Cycode kombinerer flere lag med beskyttelse, inkludert AST (Applikasjonssikkerhetstesting) og ASPM (Applikasjonssikkerhetsposture-management). For de som er ukyndige, kan du forklare hvordan disse elementene fungerer sammen—og hva som gjør Cycode sin tilnærming unik?

Absolutt. Hos Cycode krever sikring av moderne programvare mer enn bare å skanne kode; det krever en helhetlig forståelse av hvordan koden er bygget, distribuert og vedlikeholdt. Nå som en AI-nativ applikasjonssikkerhetsplattform, er vår tilnærming en differensierer på grunn av konvergensen av Applikasjonssikkerhetstesting (AST), Applikasjonssikkerhetsposture-management (ASPM) og programvareforsyningskjede-sikkerhet (SSCS).

AST-verktøy, som SAST, DAST og SCA, er effektive i å identifisere sårbarheter i kode, avhengigheter og infrastruktur. Men de opererer ofte i siloer, genererer varsler uten kontekst. Det er der ASPM kommer inn. ASPM kobler punktene over hele programvareutviklingslivssyklusen. Det gir synlighet inn i applikasjonssikkerhetsposturen med risikoprioritering og handlebar remediering, SSCS sandwicher plattformen for å sikre CI/CD-pipelines.

Hva som gjør Cycode unik er hvordan vi samler disse lagene og setter en ny bedriftsstandard. I dag i denne æraen av AI, vil sikkerhet måtte bli smartere. Vi har bygget på vår grunn med AST, ASPM og SSCS med AI-agenter for å prioritere og fikse hva som betyr noe, raskere, lukker sikkerhetsgapet jeg nevnte tidligere.

Hvordan integrerer Cycode med moderne DevOps-pipelines som GitHub, GitLab eller Azure DevOps for å oppdage risiko tidligere i livssyklusen?

Cycode ble bygget med moderne DevOps i tankene. Vi integrerer direkte i plattformer som GitHub, GitLab og Azure DevOps for å innbygge sikkerhet i hver fase av programvareutviklingslivssyklusen, uten å bremse teamene ned.

Vår plattform kobler seg til kildekodemottak og CI/CD-systemer for å kontinuerlig overvåke kode, konfigurasjoner og arbeidsflyter. Vi skanner og trekker forespørsler i sanntid, så utviklere mottar umiddelbar tilbakemelding på sårbarheter før koden er slått sammen. Vi analyserer også commit-historikk og metadata for å tildele problemer til riktige eiere, redusere friksjon og akselerere remediering.

I vår tilnærming, overflater vi ikke bare varsler; vi gir full kontekst. Dette inkluderer opphavet til problemet, dens potensielle påvirkning og stegene for å løse det. Og fordi vi integrerer med verktøy som JIRA, kan vi automatisk opprette og spore billetter, holde sikkerhet og ingeniørarbeid i sync.

Til slutt er vårt mål å flytte sikkerhet til venstre på en kontrollert, utvikler-vennlig måte, så risikoer blir identifisert tidlig, adressert prompte og ikke blir blokkere senere i pipelinen.

Kan du gå gjennom hvordan Cycode sin Risk Intelligence Graph hjelper team å koble trusler over kode, containere, infrastruktur og kjøretid?

Ja, det er en funksjon vi er stolte av å tilby. Risk Intelligence Graph, hva vi kaller RIG, er motoren bak Cycode sin evne til å korrelere og kontekstualisere sikkerhetsdata over hele programvareforsyningskjeden.

Tenk på RIG som en dynamisk kart som binder sammen alt fra kildekode og åpne kildekodemiljøer til CI/CD-pipelines, artifact-registre og kjøretid-miljøer. Det samler ikke bare inn data—det forstår relasjoner. Så når en sårbarhet blir funnet i en container, kan RIG spore den tilbake til den eksakte kodelinjen, utvikleren som committet den, pipelinen som bygde den og infrastrukturen den kjører på.

Denne typen synlighet er kritisk. Det muliggjør sikkerhetsteam å prioritere risikoer basert på deres faktiske påvirkning, i stedet for bare alvorlighetspoeng. Med AI bygget inn, gir det utviklere handlebare innsikter og full kontekst, som lar dem fikse problemer raskere og mer selvbevisst.

Det er viktig å merke seg at RIG ikke bare er en dashboard; det er et beslutningsverktøy. Det hjelper team å gå fra oppdaging til løsning i DevOps-hastighet, kobler punktene over fragmenterte systemer og overflater risikoer som virkelig betyr noe.

Hvordan oppdager og håndterer Cycode risiko knyttet til AI-generert kode og integrasjoner med tjenester som OpenAI eller Hugging Face?

AI-generert kode introduserer et nytt lag av kompleksitet og risiko, spesielt når den oppstår fra eksterne tjenester som OpenAI eller Hugging Face. Hos Cycode har vi bygget evner spesifikt for å håndtere denne utviklende trussel-landskapet. For nylig har vår AI-utnyttbarhetsagent og MCP-server sikret AI-utvikling og vibe-koding-arbeidsflyter.

For vår plattform, tilbyr vi en sentralisert Applikasjons-Asset-Inventory som kartlegger alle komponenter i et programvare-økosystem, inkludert AI-modeller, tredjeparts AI-biblioteker og integrasjoner med tjenester som OpenAI eller Hugging Face. Dette gir teamene full synlighet inn i hvor AI brukes, selv om det er dypt innbygget i staken.

For det andre, bruker vi proprietære kode-analyse-verktøy som gjør mer enn grunnleggende mønster-matching. Disse verktøyene kan oppdage AI-generert kode-mønster og identifisere biblioteker eller rammer vanligvis forbundet med maskinlæring, NLP eller generativ AI—selv om de ikke er eksplisitt merket som sådan.

Vi integrerer også med issue-sporing-systemer og utvikler-arbeidsflyter for å holde alt sammenhengende. Når en sårbarhet eller hemmelighet er bekreftet og fikset, hjelper denne tilbakemeldingen oss å gjøre våre modeller smartere. Ved å tildele problemer basert på kode-eierskap, hjelper vi å sikre at problemer rettes mot riktige personer uten unødvendig duplisering.

Til slutt hjelper vi organisasjoner å holde seg i samsvar med reguleringer som EU AI-loven ved å automatisere dokumentasjon og gi gjennomsiktighet i hvordan AI brukes over applikasjonen. Dette inkluderer å generere rapporter om AI-komponenter, deres formål og deres potensielle påvirkning, som er kritisk for både intern styring og eksterne auditor.

Kort sagt, Cycode oppdager ikke bare AI-relatert risiko; det hjelper å håndtere den med full kontekst, ansvar og samsvar i tankene.

Hva er de største utfordringene i hemmelighets-oppdaging over moderne SDLC-miljøer, og hvordan løser Cycode dem?

Hemmelighets-oppdaging er en av de mest kritiske og oversete utfordringene i moderne programvareutvikling. Hemmeligheter, som API-nøkler, token og legitimasjonsdata, er ofte hardkodet inn i kildekoden, CI/CD-pipelines og konfigurasjonsfiler. Og med økningen av distribuerte team, åpne kildekodemiljøer og raske utgivelser, kan disse hemmelighetene lett lekke ut til offentlige repositorier eller bli utnyttet av angripere.

Utfordringen er at hemmeligheter ikke lenger bare er i koden. De er overalt, i bygge-miljøer, artifact-registre og selv tredjeparts-verktøy. Tradisjonelle skannere oppdager ofte ikke dem eller genererer for mye støy, gjør det vanskelig for team å handle.

Hos Cycode tar vi en helhetlig tilnærming til sikkerhet. Vår plattform skanner hele SDLC, fra kode-repositorier til CI/CD-pipelines og kjøretid-miljøer, for å oppdage eksponerte hemmeligheter i sanntid. Vi korrelerer funn med kontekst, så team vet ikke bare hva som ble eksponert, men hvor, av hvem og hvor kritisk det er.

Vi tvinger også minst-privilegie-tilgang og sikre pipeline-konfigurasjoner for å forhindre hemmeligheter fra å bli misbrukt. Og fordi vi integrerer med issue-sporing-systemer og utvikler-arbeidsflyter, er remediering rask og friksjonsfri.

Til slutt er hemmelighets-oppdaging ikke bare om å finne lekkasjen, men om å sikre hele programvare-fabrikken. Det er hva Cycode sin plattform er bygget for å gjøre.

Hvordan sikrer du nøyaktighet og reduserer falske positiver når du skanner for sårbarheter eller hemmeligheter?

Å håndtere falske positiver kan være usedvanlig frustrerende for utviklere. Når teamene konstant bombastes med irrelevante varsler, er det lett å begynne å ignorere dem, og det er nettopp da faktiske trusler kan gli gjennom. Gjennom vår SAST-motor, hjelper vi team å identifisere kode-svakheter, oppnå nøyaktighet og fokusere på sanne positiver for å spare tid og akselerere programvare-levering. I OWASP-benchmark-tester, oppnådde Cycode en falsk positiv rate på 2,1%, representert en >94% reduksjon sammenlignet med alternative metoder.

Først, fokuserer vi på kontekstuell korrelasjon. I stedet for bare å flagge en potensiell problem og gå videre, kartlegger vår plattform det til det større bildet av en organisasjon sin programvare-forsyningskjede. Derfor, hvis en hemmelighet oppdages i en commit, assosierer vi funnet med pipelinen som bygde den, miljøet den ble deployert i og utvikleren som la den til. Denne ekstra konteksten hjelper oss å bestemme om noe utgjør en reel risiko eller bare er harmløs.

Neste, bruker vår proprietære skannings-algoritmer mye mer enn grunnleggende mønster-matching. Vår hemmelighets-oppdagelses-motor analyserer mønster, entropi og måten strengen brukes, lar oss skille mellom ekte hemmeligheter og lignende-utseende enheter, som test-data eller placeholder-tekst.

Vi integrerer også med issue-sporing-systemer og utvikler-arbeidsflyter for å holde alt sammenhengende. Når en sårbarhet eller hemmelighet er bekreftet og fikset, hjelper denne tilbakemeldingen oss å gjøre våre modeller smartere. Ved å tildele problemer basert på kode-eierskap, hjelper vi å sikre at problemer rettes mot riktige personer uten unødvendig duplisering.

Til slutt er vårt mål rett frem. Vi sikter på å gjøre sikkerhet til noe team kan stole på: færre falske varsler, mer nøyaktige funn og raskere løsninger. Så team kan fokusere på å løse de virkelige problemene som betyr mest.

Hva er verdien av “utvikler-først” sikkerhetsverktøy, og hvordan unngår Cycode å forstyrre arbeidsflyter?

Hos Cycode er utvikler-først sikkerhet i sin kjerne om å gjøre beskyttelse rask, relevant og bare så synlig som nødvendig. Det er hvordan vi holder utvikling gående fremover samtidig som vi vedlikeholder programvaresikkerhet.

Hvis sikkerhetsverktøy bremser utviklere ned eller overvelder dem med for mange varsler, risikerer disse verktøyene å bli ignorert. Det er derfor Cycode ble designet for å hjelpe utviklere i stedet for å hindre dem.

Den virkelige verdien kommer fra å bringe sikkerhet direkte inn i utviklerens daglige arbeidsflyt. Med Cycode, skjer sikkerhets-sjekker øyeblikkelig, rett der utviklere skriver og gjennomgår kode, som i IDE eller under pull-forespørsler. Dette betyr at utviklere får tilbakemelding i det øyeblikk de trenger det, gjør det enkelt å fange problemer tidlig og bygge sikre kodevaner uten ekstra besvær.

Kontekst er også nøkkel. I stedet for å sende ut vagt varsler, gir Cycode utviklere presise detaljer: hva sårbarheten er, hvor den oppstod, hvem er ansvarlig og hvordan løse den. Denne typen informasjon hjelper å redusere forvirring og lar team løse problemer mer effektivt.

Ved å integrere med populære CI/CD-verktøy og issue-sporing, sikrer Cycode at sikkerhet blir en integrert del av programvareutviklingsprosessen, i stedet for å være noe separat eller frakoblet. Utviklere kan holde seg på oppgaven, og sikkerhetsteam får oversikten de trenger.

Hva slags angrep eller sårbarheter forventer du å øke når flere selskaper adopterer AI i sine utviklingsarbeidsflyter?

Ettersom AI blir en stadig mer integrert del av daglig utviklingsarbeid, vil vi sannsynligvis møte en ny rekke sårbarheter. Disse vil ikke bare være tekniske utfordringer—noen vil komme fra måten mennesker og team samhandler med disse verktøyene.

En av de største risikoene er at utviklere kan bli for avhengige av AI-generert kode. Mens AI kan hjelpe å akselerere prosessen, er det ikke perfekt. Hvis utviklere antar at hver AI-forslag er korrekt, kan de utilsiktet introdusere skjulte feil eller sikkerhetsproblemer. Ettersom linjene av ansvar kan bli uklare når kode oppstår fra en maskin, kan disse problemene gli gjennom uoppdaget.

Det er også en voksende bekymring om forsyningskjede-angrep som spesifikt målretter AI-modeller og API-er. For eksempel, hvis pålitelige tjenester som OpenAI eller Hugging Face blir kompromittert, eller hvis noen smugler en skadelig modell inn i en arbeidsflyt, kan angripere endre utdata eller stjele følsomme data.

En annen fremvoksende trussel er data-forgiftning. I denne scenariet, gjør angripere subtile, strategiske modifikasjoner til treningdata som kan senere påvirke hvordan AI-modellen oppfører seg. Denne typen angrep er spesielt farlig i områder som bedrageri-oppdaging eller tilgangskontroll, hvor sikkerhet er kritisk.

På toppen av dette, vil selskaper møte økende press rundt forklarbarhet og samsvar. Ny lovgivning, som EU AI-loven, vil kreve at organisasjoner forklarer hvordan deres AI-systemer tar beslutninger og grunnlaget for disse beslutningene. Dette kan være svært utfordrende hvis modellene er svarte bokser eller hvis team bruker tredjeparts-verktøy som mangler gjennomsiktighet.

Hos Cycode utvikler vi verktøy som hjelper team å identifisere AI-spesifikke risikoer, som adversarial-sårbarheter, modell-misbruk og usikre integrasjoner. Vi ønsker også å sikre at utviklere forblir ansvarlige for koden de leverer, uavhengig av om den er skrevet av en person eller generert autonomt.

Ser fem år fremover, hvordan ser du på AI sin rolle i å sikre programvare-forsyningskjeder?

AI er allerede i ferd med å transformere hvordan vi nærmer oss applikasjonssikkerhet, men dets fullstendige innflytelse på programvare-forsyningskjeden er bare i begynnelsen. Over de neste fem årene, tror jeg AI vil bli en integrert del av hvordan vi identifiserer, prioriterer og håndterer risikoer gjennom hele utviklingsprosessen.

Først og fremst, vil AI hjelpe til å bringe sikkerhets- og utviklingsteam nærmere hverandre. For tiden er det ofte spenning, ettersom sikkerhetsverktøy kan avbryte arbeidsflyter eller mangle essensiell kontekst. AI har potensialet til å glatte ut disse kantene ved å transformere sikkerhetsfunn til handlebare innsikter, anbefale fikser automatisk og sogar generere sikre kode-løsninger tilpasset hver teams arbeidsflyt.

AI vil også bli stadig viktigere i å forstå hva som skjer i sanntid. Det vil overvåke bygge-miljøer, containere og API-er, og identifisere uvanlig aktivitet mens det skjer. Dette sanntids-overvåkingen vil være essensielt ettersom forsyningskjede-angrep blir stadig mer sofistikerte og vanskeligere å oppdage med tradisjonell scanning alene.

I tillegg, vil AI hjelpe selskaper å navigere i den voksende labyrinten av reguleringer. Ettersom regjeringer introduserer flere regler om hvordan AI skal brukes, vil organisasjoner trenge verktøy som kan forklare grunnlaget for hver AI-beslutning, spore hvor modellene kommer fra og holde personer ansvarlige. Jeg ser AI som går inn for å lage dokumentasjon, kartlegge avhengigheter og hjelpe med å håndheve politikker over komplekse systemer.

Likevel, med alle disse fremgangene, vil menneskelig oversikt fortsatt være kritisk. AI er ikke her for å erstatte mennesker, men for å empowermente dem. Utviklere og sikkerhetsteam må alltid ta ansvar, spesielt når AI-generert kode kan introdusere nye risikoer. Det er en stor grunn til at vi er dedikert til å bygge verktøy som gjør AI så gjennomsiktig, forståelig og ansvarlig som mulig.

Til slutt, vil AI bli den sammenkoblede tråden som gjør programvare-forsyningskjeder sikrere, men bare hvis vi bruker det tankefullt og holder mennesker involvert hver skritt på veien.