Zaid Al Hamani, Boost Securityn toimitusjohtaja ja perustaja – Haastattelusarja

Zaid Al Hamani, Boost Securityn toimitusjohtaja ja perustaja, on kyberturva- ja DevSecOps-johtaja, jolla on yli kaksi vuosikymmentä kokemusta globaalien teknologiatoimintojen rakentamisesta ja skaalauttamisesta. Perustettuaan Boost Securityn vuonna 2020, hän on keskittynyt modernin ohjelmistokehityksen turvallisuuden kehittämiseen, hyödyntäen aikaisempia roolejaan, kuten Trend Microssa sovellusturvan varapuheenjohtajana ja IMMUNIO:n perustajana ja toimitusjohtajana. Aikaisemmin hän on toiminut johtavissa asemissa Canonicalissa, jossa hän johti tuote-, insinööri- ja globaalin tukitoimintoja, sekä SITA:ssa, jossa hän vastasi suurista, kriittisistä IT-toiminnosta. Hänen uransa osoittaa vahvan rekisterin tiimien rakentamisesta, järjestelmien optimoinnista ja modernin turvallisuuden käytännön edistämisestä.

Boost Security on kyberturva-alan yritys, joka keskittyy modernin ohjelmistotoimitusketjun turvallisuuteen kehittämällä developer-ensimmäisen DevSecOps-alustan. Sen teknologia integroituu suoraan CI/CD-pipelineen, jotta se voi automaattisesti havaita, priorisoida ja korjata haavoittuvuuksia, vähentäen manuaalista työmäärää samalla, kun kehityksen nopeus säilyy. Yhdistämällä sovellus- ja toimitusketjun turvallisuuden yhteen järjestelmään, alusta tarjoaa kattavan näkyvyyden koodiin, riippuvuuksiin ja infrastruktuuriin, auttaen organisaatioita vahvistamaan kestävyyttä monimutkaisissa, pilvipohjaisissa ympäristöissä.

Olit aikaisemmin johtanut sovellusturvaa Trend Microssa ja perustanut IMMUNIO:n. Mikä johti sinut perustamaan Boost Securityn, ja mikä aukko markkinassa sinä olit ainutlaatuinen tunnistamaan aikaisin?

IMMUN.IO oli yksi ensimmäisistä RASP-yrityksistä, ja kokemuksemme siihen asti oli, että WAF:t olivat mahdottomia ylläpitää ja eivät olleet kovin tehokkaita. Me kuvittelimmme tavan, jossa WAF:t korvataan tarkemmin ja helpommin ylläpidettävällä ratkaisulla – instrumentoimalla sovellusta.

Se oli vuonna 2012, DevOps oli vielä alkuvaiheessa, useimmat tiimit eivät olleet Agileja, eikä Kubernetesta ollut vielä olemassa.

Trend Micro hankki IMMUNIO:n vuonna 2017. Siihen mennessä DevOps-käytännöt olivat lisääntyneet: CI/CD-pipeline, Agile-kehitysmenetelmät, nopeammat iteroinnit ja julkaisujakso, pilvi jne. Ohjelmistokehitystiimit olivat parempia kehittämään ohjelmistoa ja toimittamaan sitä nopeammin. Turvallisuus oli kuitenkin edelleen rikkoontunut:

• Skannaukset ovat liian hitaita tai tulokset saapuvat liian myöhään
• Tulokset ovat liian monimutkaisia kehittäjille
• On yleisesti hyväksytty, että virheellisten positiivisten osuus on liian suuri
• Monia uusia artifacteja ei skannata: infrastruktuuri koodina, kontit, API:t jne.

Ohjelmistojen nopea tuottaminen oli helpompaa. Turvallisen ohjelmiston nopea tuottaminen oli edelleen vaikeaa.

Se oli alkuperäinen ongelma, jonka halusimme ratkaista. Tehdä DevSecOps toimivaksi todellisessa maailmassa; voitko saada ohjelmistokehitystiimin helposti lisäämään turvallisuutta SDLC:hen, nopeudella, joka vastaa uusia nopeusstandardeja? Voitko tehdä kattavuuden laajaksi – jossa yksi alusta on kaikki, mitä tarvitset? Voitko tehdä sen niin, että kehittäjät eivät vain omaksu teknologiaa, vaan myös näkevät sen hyödyt? Voitko tehdä sen skaalautuvaksi, jotta et tarvitse armeija turvallisuusammattilaisia ylläpitämään määrää koodia…

Autimme yrityksiä injektoimaan turvallisuutta SDLC:hen DevOps-ajan alla. Se oli siirtymä 1:stä 10:een. Olemme nyt agenteilla kirjoitetun koodin aikakaudella – jossa agentit kirjoittavat valtavan määrän koodia – mutta se on perimmältään sama ongelma – nopeus ja koodin määrä ovat vain siirtyneet 10:stä 100:aan; ja pyrimme jatkamaan samaa trajectoriaa.

Olet väittänyt, että ohjelmistokehityksen elinkaari on perustavanlaatuisesti muuttunut ylöspäin. Mikä oli se hetki, jolloin tajusit, että perinteiset DevSecOps-lähestymistavat eivät enää riittäneet?

Se oli katsomalla, miten hyökkääjät todella pääsivät sisään. Näimme jatkuvasti saman kuvion: paljastettu GitHub Actions -työvoima, jota kukaan ei ollut tarkastanut siitä lähtien, kun repo forkattiin, token tuotantopilveen pääsyyn sisällytetty runner-konfiguraatioon, legitiimi CI-työ kaapattu hyökkääjien payloadien lähettämiseen. Nämä tulivat tunnetuksi “pipelineen elävistä” hyökkäyksistä, koska vihollinen käyttää omaa automaatiotaan sinua vastaan, johtuen turvallisuustiimisi jo hyväksymistä.

DevSecOps-pino, jonka olimme rakentaneet viiden vuoden ajan, ei ollut vastaus sille. SAST-skannaa sovelluksen lähdekoodia. SCA-skannaa sovelluksen riippuvuuksia. Molemmat oletetaan, että pipeline, joka ajaa niitä, on luotettava. Samaan aikaan pipeline itsessään on YAML-tiedosto, jossa on shell-komennot, verkkoyhteys ja arkaluontoiset tunnistetiedot, ja lähes kukaan ei tarkastele sitä.

Kun se tulee helpoimmaksi reitiksi, voit toimittaa täydellisen puhdas koodin ja antaa hyökkääjille pilvesi.

Miten yritysten tulisi uudelleenarvioida ohjelmistokehityksen elinkaari maailmassa, jossa AI-agentit generoivat koodia jatkuvasti eikä kehittäjät kirjoita sitä askel askeleelta?

Meidän on lopetettava ajattelu ohjelmistokehityksen elinkaaresta tarkistuspisteenä. AI-agentit ovat kutistaneet ajan “joku kirjoitti tämän” ja “tämä on tuotannossa” viikoista minuuteiksi. Vanha malli oletti ihmisen tahti koodin tarkastelun, SAST:n, SCA:n ja käyttöönoton välillä, mutta olemme siirtymässä siitä.

Turvallisuuden on oltava siellä, missä agentti toimii: kehittäjän koneella, ohjauskontekstissa, agentin yhteyksissä MCP-palvelimiin ja ulkoisiin malleihin. Kun koodi saapuu pipelineen, olet jo menettänyt mahdollisuuden muotoilla sitä. Agentti on jo vetänyt riippuvuuden. Malli on jo nähnyt tunnistetiedot. Siirrä valvontaa ylöspäin, sinne, missä työ todella tapahtuu.

Monet organisaatiot käsittelevät edelleen AI-koodausvälineitä yksinkertaisina tuottavuuskerroksina. Miksi uskot, että ne edustavat täysin uuden hyökkäyspinnan eikä vain olemassa olevien työnkulkujen laajennusta?

Koodausagentin käsittely tuottavuuskerroksena on kuin nuoren kehittäjän käsittely tuottavuuskerroksena, jolla on root-oikeudet. Label on teknisesti oikein, mutta se ei anna sinulle mitään hyödyllistä kehysrakennetta miettiäksesi, mitä voi mennä pieleen.

Koodausagentti lukee tiedostojärjestelmääsi, etsii ympäristömuuttujia kontekstia varten, noutaa riippuvuuksia julkisista rekistereistä, avaa ulospäin suunnatut yhteydet etäisiin mallipalvelimiin ja MCP-palvelimiin, ja suorittaa shell-komennot. Nämä toimet vaativat aikaisemmin ihmisen toimintaa. Nyt ne tapahtuvat millisekunteja, samalla etuoikeuksilla kuin kehittäjällä, joka käynnisti agentin.

Se yhdistää luottamuksen rajat, jotka olivat aikaisemmin erillisiä: kehittäjän valtuudet, mitä ulkoinen työkalu voi noutaa, ja mitä epäluotettava koodi voi suorittaa. Se luo uusia mahdollisuuksia hyökkääjille ja sokeita pisteitä, joita puolustajat eivät voi edes nähdä, saati puolustaa.

Boost Security määrittelee kehittäjän kannettavan tietokoneen uudeksi valvontatasoksi. Mitkä riskit ovat päätepisteessä, joita turvallisuustiimit eivät tällä hetkellä huomioi?

Suurin on inventaario. Useimmat turvallisuustiimit eivät voi kertoa, mitkä AI-agentit ovat käynnissä mitä kannettavia tietokoneita, mitä MCP-palvelimia nämä agentit ovat yhteydessä, tai mitkä IDE-laajennukset lukevat tällä hetkellä repositorion sisältöä. EDR:llä ei ole näkyvyyttä agenttikerrokseen; SIEM ei voi nähdä, mitä nämä agentit tekevät paikallisesti.

Tämän alla on salasanaongelma. Rakensimme avoimen lähdekoodin työkalun nimeltä Bagel osittain konkreettiseksi. Tyypillinen kehittäjän kannettava tietokone sisältää GitHub-tunnisteita, joilla on kirjoitusoikeus tuotantorepositorioihin, pilvitunnisteita, joilla voidaan luoda infrastruktuuria, npm- tai PyPI-tunnisteita, joilla voidaan julkaista miljoonille käyttäjille, ja AI-palvelun avaimia, joita hyökkääjät myyvät. Yhtäkään näistä ei ole kovennettu siten kuin CI-suoritin. Sama kone, jolla on nämä tunnistetiedot, myös selaa internetiä ja asentaa satunnaisia VS Code -laajennuksia.

Yhdistä kaksi, ja sinulla on todellinen hyökkäyspinta. Epäluotettava laajennus, joka suoritetaan kehittäjän etuoikeuksilla ympäristössä, joka on täynnä pilvitunnisteita, on korkein hyödyke suurissa yrityksissä. Useimmat tiimit eivät ole vielä aloittaneet sen tarkastelua.

Olet korostanut “kontekstiloukkausta”, jossa AI-agentit voivat päästä käsiksi paikallisiin tiedostoihin, ympäristömuuttujiin ja määrityksiin. Kuinka laaja on riski arkaluontoisen datan vuotamisesta ohjauksien kautta, ja miksi se on niin vaikea havaita?

Tarpeeksi yleinen, että kohtelemme sitä oletuksena, että mikä tahansa kehittäjän ympäristö on hallitsematon. Jokainen koodausagentti, jonka olemme tarkastaneet, lukee paikallista kontekstia aggressiivisesti. Ne lukevat pistetiedostoja, ympäristömuuttujia, viimeisiä tiedostoja, joskus koko hakemistorakenteita, ja lähettävät tämän kontekstin etäiseen malliin. Työkalut on suunniteltu toimimaan tässä mielessä; aggressiivinen kontekstin etsintä on se, mikä tekee niistä hyödyllisiä.

Havainnon ongelma alkaa siitä, että vuotaneen liikenteen näyttää samalta kuin normaali tuotteen käyttö. Se on TLS:ää api.openai.comiin tai api.anthropic.comiin. Se tulee hyväksytystä liiketoimintasovelluksesta. Standardi-DLP näkee kehittäjän käyttävän AI-työkalua, jonka yritys on juuri lisännyt. Se ei näe, että yksi merkkijono kyseisessä ohjausmerkissä on AWS-salausavain, jonka agentti etsi puolivahingossa .env-tiedostosta sisarhakemistosta.

Sinun on tarkasteltava ohjauksia ennen kuin ne poistuvat kannettavalta tietokoneelta, mikä on tarkalleen se paikka, jossa lähes mikään turvallisuuspino ei ole tällä hetkellä sijoitettu.

Voitko kuljettaa realistisen skenaarion kautta, jossa AI-agentti tuo haavoittuvuuden nopeammin kuin perinteiset turvallisuustyökalut voivat tunnistaa sen?

Tässä on yksi, jonka olemme nähneet useita variaatioita toistuvasti. Kehittäjä pyytää agentilta lisäämään ominaisuutta, joka tarvitsee HTTP-yritysten kirjastoa. Agentti ehdottaa paketin nimeä. Paketti on uskottava, mutta se ei todella ole olemassa npm:ssä. Tunneissa hyökkääjä rekisteröi sen, täyttää sen toimivalla retry-logiikalla ja pienellä post-asennus-skriptillä, joka lukee ~/.aws/credentials-tiedoston ja lähettää sisällön webhookiin. Agentti suorittaa npm-asennuksen ilman tarkastusta, koska agentit eivät tarkasta mainetta. Tunniste on poissa ennen kuin kehittäjä suorittaa koodin.

Itse hyökkäys ei ole teknisesti kehittynyt, mutta perinteinen turvallisuuspohjainen toimitusketjun turvallisuus on rakennettu tunnettuja haavoittuvuuksia tunnetuissa paketeissa: CVE:t, SBOM:t, lisensointiskannaus. Tämä kehys ei voi sanoa mitään paketista, joka ei ollut olemassa, kun skannaus suoritettiin viimeksi, luotiin yksinomaan vastaamaan AI-hallusinaatiota ja otettiin käyttöön ennen kuin mitkään uhkakuvaus päivittyi.

Ikkuva ajan julkaisusta kompromissiin on nyt mitattu minuuteissa. Mitä tahansa tarkastetaan jälkikäteen, se on liian myöhäistä.

Tulevatko kuvitteelliset riippuvuudet yhdeksi suurimmista riskeistä AI-vetämässä kehityksessä, ja mitkä käytännön toimet organisaatiot voivat tehdä puolustautuakseen niitä vastaan?

Ne ovat jo yksi suurimmista. Hyökkääjät seuraavat aktiivisesti suosittuja AI-työkaluja ja rekisteröivät ehdotetut paketin nimet minuuteissa. Tutkijat pari vuotta sitten, kun se alkoi tapahtua, kutsuivat sitä slopsquattingiksi, ja nimi on jäänyt. Kun paketin nimi on ehdotettu usein, istuminen siinä on passiivinen toimitusketjun hyökkäys, jossa on lähes nolla vaivaa.

Käytännön puolustus keinoja näyttää erilaiselta kuin mitä useimmat tiimit tällä hetkellä omistavat. Aloita ottamalla. Estä typosquattaus- ja uudelleen rekisteröityneet paketit hetkellä, kun npm-asennus tai pip-asennus suoritetaan, kehittäjän koneella, ennen kuin mitään menee levyyn. Postmortem-havainnointi CI:ssä ei auta, kun post-asennus-skripti on jo vuotanut tunnisteen. Sitten anna agentille rajoitukset toimia. Liitä hyväksytty riippuvuuslista suoraan agentin kontekstiin, jotta malli näkee, mitä on sallittua ennen kuin se luo ehdotuksen. Pyytäminen kehittäjältä “turvallisia ohjauksia” ei ole strategia. Jos olet strategista, se tarkoittaa, että turvallisuus asettaa rajan, agentti perii sen. Ja aloita seuranta AI-luetteloa. Useimmat tiimit eivät voi kertoa, mitkä agentit, mallit ja paketit koskevat mitäkä repositorioita. Et voi puolustaa mitä et voi inventoida.

Sanoit, että turvallisuus ei voi enää alkaa CI/CD:stä. Miltä moderni turvallisuuspöytäkirja näyttää, kun suojelu on aloitettava aikaisemmin kehitysprosessissa?

Jos turvallisuus alkaa CI/CD:stä, olet antanut koko ennen commitoimista vaiheen ympäristölle, jota et hallitse. Agentti on jo etsinyt kontekstia, salasanasi voi jo olla jossakin muualla. Skannaat vain ruumiin.

Moderni pöytäkirja alkaa kannettavalta tietokoneelta. Se tarkoittaa inventaariota agenteista ja laajennuksista, jotka suoritetaan siellä, validointia, mitä MCP-palvelimia ne ovat yhteydessä, puhdistamista, mitä lähtee koneelta, ja estämistä, mitä pahaa paketteja asennetaan. Siitä alkaa politiikka seurata työtä IDE:hen. Me injektoidaan turvallisuusstandardeja suoraan agentin konteksti-ikkunaan, jotta generoitu koodi pysyy rajojen sisällä ensimmäisestä tokenista alkaen. Pipeline itse ei katoa. Sen rooli muuttuu vahvistukseksi: vahvistaa, että ylätasolla olevat valvontatoimet pidettiin yllä.

Pipeline itsessään ei häviä. Sen rooli on vahvistus: vahvistaa, että yläpuolella olevat valvontatoimet pidettiin yllä.

Mitä ovat tärkeimmät muutokset, joita organisaatioiden on tehtävä tänään, jotta heidän kehitysympäristönsä säilyvät turvallisina seuraavien muutamien vuosien ajan, kun he jatkavat AI-koodausagenttien omaksumista?

Suurin virhe on turvallisuuden suojaaminen vain sitä, mitä committoidaan. Mielenkiintoinen riski asuu nykyään kahdeksan tuntia ennen commitoimista. Näkymätön draama voi kehkeytyä kannettavalla tietokoneella, ohjauksessa tai paketin asennuksessa. Jos työkalusi alkavat PR:stä, sinä suojelet väärää puoliskoa työnkulkua.

Läheinen: lopeta koodausagenttien käsittely tuottavuuskerroksina. Ne ovat epä-ihmisiä käyttäjiä, joilla on shell-pääsy, repositorio-oikeudet ja ulospäin suunnatut verkkoyhteydet. Hallitse niitä samalla tavalla kuin hallitset minkä tahansa etuoikeutetun identiteetin: inventaariolla, hyväksyttyjä kyvyillä ja audit-lokeilla.

Viimeinen siirtymä on vaikeampi kulttuurisesti. Useimmat nykyiset “AI-turvallisuustyökalut” ilmaisevat löydöksiä ja ohjaa ne ihmisille. Ihmiset eivät voi priorisoida nopeudella, jolla agentit generoivat. Mitä tahansa otat käyttöön, sen on korjattava ongelmat automaattisesti työnkulkussa, jäljitettävällä logiikalla, tai se tulee toiseksi dashboardiksi, jota kukaan ei lue.

Kiitos hienosta haastattelusta, lukijat, jotka haluavat oppia lisää, voivat vierailla Boost Security:ssa.