Zaid Al Hamani, CEO și fondator al Boost Security – Seria de interviuri

Zaid Al Hamani, CEO și fondator al Boost Security, este un lider în domeniul securității cibernetice și DevSecOps, cu peste două decenii de experiență în construirea și scalarea operațiunilor tehnologice globale. De la fondarea Boost Security în 2020, el s-a concentrat pe modernizarea modului în care organizațiile asigură dezvoltarea de software, folosind experiența sa anterioară în roluri precum VP de Securitate a Aplicațiilor la Trend Micro și Co-fondator/CEO al IMMUNIO. Mai devreme, el a deținut funcții de conducere la Canonical, conducând inițiative de produs, inginerie și suport global, și la SITA, unde a gestionat operațiuni IT de mare scară și critice pentru misiune. Cariera sa reflectă o puternică experiență în construirea de echipe, optimizarea sistemelor și promovarea practicilor moderne de securitate.

Boost Security este o companie de securitate cibernetică axată pe securizarea lanțului de aprovizionare modern de software prin intermediul unei platforme DevSecOps orientate către dezvoltatori. Tehnologia sa se integrează direct în pipeline-urile CI/CD pentru a detecta, prioritiza și remedia vulnerabilități în mod automat, reducând astfel sarcinile manuale și menținând viteza de dezvoltare. Prin unificarea securității aplicațiilor și a lanțului de aprovizionare într-un singur sistem, platforma oferă o vizibilitate completă asupra codului, dependențelor și infrastructurii, ajutând organizațiile să-și consolideze reziliența în medii cloud-native complexe.

Ai condus anterior securitatea aplicațiilor la Trend Micro și ai co-fondat IMMUNIO. Ce te-a determinat să fondezi Boost Security și ce lacună de pe piață ai identificat mai devreme?

IMMUN.IO a fost una dintre primele companii RASP fondate – și experiența noastră până în acel moment a fost că tehnologia de securitate runtime WAF era imposibil de întreținut și nu foarte eficientă. Am imaginat o cale prin care WAF-urile ar fi înlocuite cu o soluție mai precisă și mai ușor de întreținut – prin instrumentarea aplicației.

Acest lucru s-a întâmplat în 2012, DevOps era încă la început, majoritatea echipelor nu erau Agile, iar Kubernetes nu era încă o realitate.

Trend Micro a achiziționat IMMUN.IO în 2017. Până în acel moment, existau multe mai multe practici DevOps: pipeline-uri CI/CD, practici de dezvoltare Agile, iterații și cicluri de lansare mai rapide, cloud etc. Echipele de dezvoltare software erau mai bune la construirea de software și la lansarea lui mai rapid. Cu toate acestea, securitatea era încă defectuoasă:

• Scanările sunt prea lente sau rezultatele sosesc prea târziu
• Rezultatele sunt prea complexe pentru ca dezvoltatorii să le poată acționa
• Există o rată general inacceptabilă de fals pozitive
• Multe tipuri noi de artefacte nu sunt scanate: cod ca infrastructură, containere, API-uri, de exemplu

Producerea de software rapid era mai ușoară. Producerea de software securizat rapid era încă dificilă.

Acesta a fost problema originală pe care am încercat să o rezolvăm. Să facem DevSecOps să funcționeze în lumea reală; poți să faci o echipă de dezvoltare software să adauge ușor securitatea în SDLC, la o viteză care să corespundă noilor standarde de viteză? Poți să faci acoperirea largă – unde o singură platformă este tot ce ai nevoie? Poți să faci astfel încât dezvoltatorii, nu doar să adopte tehnologia, ci să o și îmbrățișeze și să vadă beneficiile? Poți să o faci să scaleze astfel încât să nu ai nevoie de armate de profesioniști în securitate pentru a ține pasul cu cantitatea de cod scris…

Am ajutat companiile să injecteze securitatea în SDLC în timpul erei DevOps. Acesta a fost drumul de la 1 la 10. Acum suntem în era codării agenților – unde agenții scriu o cantitate enormă de cod – dar este fundamental aceeași problemă – viteza și volumul de cod au trecut de la 10 la 100; și ne propunem să continuăm aceeași traiectorie.

Ai argumentat că ciclul de viață al dezvoltării software (SDLC) s-a schimbat fundamental upstream. Care a fost momentul în care ai realizat că abordările tradiționale DevSecOps nu mai sunt suficiente?

A fost atunci când am văzut cum atacatorii reușeau să pătrundă. Am văzut mereu același model: un flux de lucru GitHub Actions expus pe care nimeni nu l-a revizuit de când a fost bifurcat, un token cu acces la cloud de producție încorporat într-un config de runner, un job CI legitim deturnat pentru a deploya payload-uri de atacator. Acestea au devenit cunoscute sub numele de atacuri “living off the pipeline”, deoarece adversarul folosește propria dvs. automatizare împotriva dvs., cu credențiale pe care echipa dvs. de securitate le-a aprobat deja.

Stiva DevSecOps pe care am construit-o peste un deceniu nu avea nicio soluție pentru asta. Scanările SAST verifică sursa aplicației. Scanările SCA verifică dependențele aplicației. Ambele presupun că pipeline-ul care le rulează este de încredere. Între timp, pipeline-ul însuși este un fișier YAML cu comenzi shell, acces la rețea și credențiale sensibile, și aproape nimeni nu îl revizuiește.

Când acesta devine drumul cel mai ușor, puteți livra cod perfect curat și totuși oferi atacatorilor cloud-ul dvs.

Cum ar trebui să reconsidere întreprinderile SDLC într-o lume în care agenții AI generează cod continuu, în loc de dezvoltatori care scriu pas cu pas?

Trebuie să încetăm să ne gândim la SDLC ca la o secvență de puncte de control. Agenții AI au comprimat timpul dintre “cineva a scris asta” și “asta este în producție” de la săptămâni la minute. Modelul vechi presupunea un ritm uman între revizuirea codului, SAST, SCA și deploy, dar suntem dincolo de asta acum.

Securitatea trebuie să trăiască acolo unde operează agentul: pe mașina dezvoltatorului, în contextul promptului, în conexiunile agentului cu serverele MCP și modelele externe. Până când codul ajunge în pipeline, ați pierdut deja șansa de a-l modela. Agentul a extras deja dependența. Modelul a văzut deja credențiala. Mutăți controlul upstream, acolo unde se desfășoară lucrul.

De ce crezi că multe organizații încă tratează uneltele de codare AI ca simple straturi de productivitate, în loc de a le considera o suprafață de atac complet nouă?

Tratând un instrument de codare AI ca un strat de productivitate este ca și cum ai trata un dezvoltator junior cu acces root ca un strat de productivitate. Eticheta este tehnic corectă, dar nu oferă niciun cadru util pentru a gândi la ce ar putea merge prost.

Un agent de codare citește fișierul dvs. de sistem, extrage variabile de mediu pentru context, fetch-ează dependențe de la registre publice, deschide conexiuni outbound către furnizori de modele și servere MCP și execută comenzi shell. Fiecare dintre aceste acțiuni necesita anterior un om în buclă. Acum se întâmplă în milisecunde, cu aceleași privilegii ca și dezvoltatorul care a lansat agentul.

Acest colaps fuzionează limitele de încredere care erau separate: autoritatea dezvoltatorului, ceea ce poate obține o unealtă externă și ceea ce poate executa codul neîncredere. Acest lucru creează noi oportunități pentru atacatori și puncte oarbe pe care apărătorii nu le pot vedea, nici măcar apăra.

Boost Security prezintă laptopul dezvoltatorului ca noul plan de control. Care sunt riscurile care există la punctul de capăt pe care echipele de securitate le omit în prezent?

Cel mai mare risc este inventarul. Majoritatea echipelor de securitate nu pot spune care agenți AI rulează pe care laptopuri, care servere MCP acești agenți sunt conectați și care extensii IDE scanează conținutul depozitului în acest moment. EDR nu are vizibilitate în stratul agent; SIEM nu poate vedea ce fac agenții local.

Sub acesta se află haosul de credențiale. Am construit un instrument open-source numit Bagel, parțial pentru a face acest lucru concret. Un laptop tipic de dezvoltator conține token-uri GitHub cu acces de scriere la depozite de producție, credențiale cloud care pot crea infrastructură, token-uri npm sau PyPI care pot publica pentru milioane de utilizatori și chei de servicii AI pe care atacatorii le pot revinde. Niciuna dintre acestea nu este consolidată în modul în care un runner CI este consolidat. Mașina care deține aceste credențiale navighează și pe web și instalează extensii VS Code arbitrare.

Combinați-le și veți avea suprafața de atac reală. O extensie neîncredere care rulează cu privilegii de dezvoltator într-un mediu plin de chei cloud este ținta cu cea mai mare valoare în întreprinderea modernă. Majoritatea echipelor nu au început să se uite la asta.

Ai subliniat “capcana de context”, în care agenții AI pot accesa fișiere locale, variabile de mediu și configurări. Cât de răspândit este riscul de scurgere a datelor sensibile prin prompturi și de ce este atât de dificil de detectat?

Suficient de răspândit încât îl tratăm ca starea implicită a oricărui mediu de dezvoltator neadministrat. Fiecare agent de codare pe care l-am inspectat extrage contextul local agresiv. Ei citesc fișierele dot, variabilele de mediu, fișierele recente, uneori întregi copaci de directoare și expediază acest context către un model remote. Uneltele sunt proiectate să funcționeze astfel; extragerea agresivă a contextului este ceea ce le face utile.

Problema de detectare începe pentru că traficul dintr-o scurgere arată identic cu utilizarea normală a produsului. Este TLS către api.openai.com sau api.anthropic.com. Vine de la o aplicație de business aprobată. DLP standard vede un dezvoltator care folosește instrumentul AI pe care compania a cumpărat o licență. Nu vede că unul dintre șirurile din acea promptă este o cheie secretă AWS pe care agentul a extras-o dintr-un fișier .env uitat într-un director frate.

Prindeți-l doar inspectând prompturile înainte de a părăsi laptopul, ceea ce este exact acolo unde stiva de securitate aproape că nu este poziționată.

Poți să ne explici un scenariu realist în care un agent AI introduce o vulnerabilitate mai repede decât instrumentele de securitate tradiționale pot identifica?

Iată unul pe care l-am văzut în mod repetat. Dezvoltatorul solicită unui agent să adauge o funcționalitate care necesită o bibliotecă de retry HTTP. Agentul sugerează un nume de pachet. Pachetul pare plauzibil, dar nu există de fapt pe npm. Într-o oră, un atacator înregistrează pachetul, îl populează cu logică de retry funcțională, plus un script de post-instalare care citește ~/.aws/credentials și postează conținutul către un webhook. Agentul rulează npm install fără a verifica, pentru că agenții nu verifică reputația. Credențiala este pierdută înainte ca dezvoltatorul să ruleze codul.

Atacul în sine nu este tehnic sofisticat, dar securitatea lanțului de aprovizionare pe care am construit-o peste un deceniu nu are nicio soluție pentru asta. Scanările SAST verifică sursa aplicației. Scanările SCA verifică dependențele aplicației. Ambele presupun că pachetul care rulează este de încredere. Între timp, pachetul însuși este un fișier care poate fi creat pentru a se potrivi cu o halucinație AI și poate fi ingerrat înainte de a actualiza orice feed de amenințări.

Fereastra de la publicare la compromis este acum măsurată în minute. Orice verificare ulterioară este prea târziu.

Devind oare dependențele halucinate una dintre cele mai mari riscuri în dezvoltarea condusă de AI și care sunt pașii practici pe care organizațiile îi pot lua pentru a se apăra împotriva lor?

Ele sunt deja una dintre cele mai mari. Atacatorii monitorizează activ uneltele AI populare pentru halucinații și înregistrează numele de pachet sugerate în câteva minute. Cercetătorii, cu câțiva ani în urmă, când a început să se întâmple, au numit-o slopsquatting și numele a rămas. Odată ce un nume de dependență este halucinat suficient de des, așteptarea lui devine un atac de lanț de aprovizionare cu efort aproape zero.

Apărările practice arată diferit de ceea ce au majoritatea echipelor în prezent. Începeți cu ingestia. Blocați pachetele cu nume de tipoprint și înregistrate recent la momentul în care rulează npm install sau pip install, pe mașina dezvoltatorului, înainte ca orice să ajungă pe disc. Detectarea post-mortem în CI nu ajută atunci când un script de post-instalare aalready exfiltrat o credențială. Apoi dați agentului garduri de operare. Injectați lista dvs. de dependențe aprobate direct în contextul agentului, astfel încât modelul să vadă ce este permis înainte de a genera o sugestie. A cere dezvoltatorilor să scrie “prompturi securizate” nu este o strategie. Dacă sunteți strategici, înseamnă că securitatea stabilește limitele, iar agentul le moștenește. Și începeți să urmăriți o listă de materiale AI. Majoritatea echipelor nu pot spune care agenți, modele și pachete ating care depozite. Nu puteți apăra ceea ce nu puteți inventaria.

Ai spus că securitatea nu mai poate începe la CI/CD. Ce arată o conductă de securitate modernă atunci când protecția trebuie să înceapă mai devreme în procesul de dezvoltare?

Dacă securitatea începe la CI/CD, ați cedat întreaga fază pre-commit unui mediu pe care nu îl controlați. Agentul a ingestat deja contextul, credențiala dvs. poate fi deja în jurnalele cuiva altcuiva.

O conductă modernă de securitate începe pe laptop. Acest lucru înseamnă inventarierea agenților și extensiilor care rulează acolo, validarea serverelor MCP și modelelor cu care au voie să comunice, curățarea a ceea ce părăsește mașina și blocarea pachetelor maligne înainte de a se instala. De acolo, politica urmează lucrul în IDE. Noi injectăm standardele de securitate direct în contextul ferestrei agentului, astfel încât codul generat să rămână în garduri de la primul token. Conducta rulează în continuare, făcând verificări finale asupra controlului care a fost deja impus upstream.

Conducta însăși nu dispare. Rolul său devine verificare: confirmarea faptului că controlul upstream a fost menținut.

Pe măsură ce organizațiile continuă să adopte agenți de codare AI, care sunt cele mai critice schimbări pe care trebuie să le facă astăzi pentru a-și menține mediile de dezvoltare securizate în următorii ani?

Cea mai mare greșeală este securizarea doar a ceea ce este angajat. Riscul interesant trăiește în cele opt ore înainte de a se face un angajament. Dramă nevăzută poate avea loc pe laptop, în prompt sau în instalarea pachetului. Dacă uneltele dvs. încep la PR, protejați jumătatea greșită a fluxului de lucru.

Strâns legat de asta: încetați să tratați uneltele de codare AI ca software de productivitate. Ele sunt utilizatori non-umani cu acces shell, privilegii de scriere în depozit și conexiuni de rețea outbound. Guvernați-le în același mod în care guvernați orice altă identitate privilegiată, cu un inventar, capabilități aprobate și jurnale de audit.

Ultima schimbare este mai dificilă din punct de vedere cultural. Majoritatea instrumentelor actuale de “securitate AI” prezintă rezultate și le routează către oameni. Oamenii nu pot tria la viteza la care agenții generează. Orice adoptați trebuie să rezolve problemele în mod automat în interiorul fluxului de lucru, cu raționament trasabil, sau devine o altă dashboard pe care nimeni nu o citește.

Mulțumim pentru acest interviu minunat, cititorilor care doresc să afle mai multe, le recomandăm să viziteze Boost Security.