Zaid Al Hamani, CEO i założyciel Boost Security – seria wywiadów

Zaid Al Hamani, CEO i założyciel Boost Security, jest liderem w dziedzinie cyberbezpieczeństwa i DevSecOps z ponad dwudziestoletnim doświadczeniem w budowaniu i skalowaniu globalnych operacji technologicznych. Od założenia Boost Security w 2020 roku, skupił się na modernizowaniu sposobu, w jaki organizacje zabezpieczają rozwój oprogramowania, wykorzystując doświadczenie z poprzednich ról, w tym VP of Application Security w Trend Micro i współzałożyciela/CEO IMMUNIO. Wcześniej zajmował stanowiska kierownicze w Canonical, gdzie kierował inicjatywami produktowymi, inżynieryjnymi i wsparcia globalnego, a także w SITA, gdzie zarządzał dużymi, krytycznymi dla misji operacjami IT. Jego kariera odzwierciedla silny rekord budowania zespołów, optymalizacji systemów i wprowadzania nowoczesnych praktyk bezpieczeństwa.

Boost Security to firma zajmująca się cyberbezpieczeństwem, skupiająca się na zabezpieczaniu nowoczesnego łańcucha dostaw oprogramowania za pomocą platformy DevSecOps dla deweloperów. Jej technologia integruje się bezpośrednio z potokami CI/CD, aby automatycznie wykrywać, priorytetowo traktować i naprawiać luki w zabezpieczeniach, redukując manualne obciążenie przy zachowaniu szybkości rozwoju. Poprzez połączenie bezpieczeństwa aplikacji i łańcucha dostaw w jeden system, platforma zapewnia pełną widoczność kodu, zależności i infrastruktury, pomagając organizacjom wzmocnić odporność w złożonych, natywnych środowiskach chmurowych.

Poprzednio kierowałeś zabezpieczeniami aplikacji w Trend Micro i byłeś współzałożycielem IMMUNIO. Co skłoniło Cię do założenia Boost Security, a jaka była luka na rynku, którą byłeś w stanie wczesnie zidentyfikować?

IMMUN.IO była jedną z pierwszych firm RASP, które zostały założone – a nasze doświadczenie do tego momentu było takie, że WAF-y jako technologia zabezpieczeń czasu wykonywania były niezwykle trudne do utrzymania i niezbyt skuteczne. Wyobraziliśmy sobie sposób, w którym WAF-y zostaną zastąpione przez rozwiązanie bardziej dokładne i łatwiejsze w utrzymaniu – poprzez instrumentację aplikacji.

To było w 2012 roku, DevOps wciąż było na wczesnym etapie, większość zespołów nie stosowała jeszcze metodyki Agile, a Kubernetes jeszcze nie istniał.

Trend Micro przejął IMMUN.IO w 2017 roku. Do tego czasu istniało już więcej praktyk DevOps: potoki CI/CD, metodyka Agile, szybsze iteracje i cykle wydawnicze, chmura itp. Zespoły rozwojowe były lepsze w tworzeniu oprogramowania i wysyłaniu go szybciej. Zabezpieczenia były jednak nadal złamane:

• Skany są zbyt wolne lub wyniki przychodzą zbyt późno
• Wyniki są zbyt skomplikowane dla deweloperów, aby mogli podjąć działanie
• Istnieje ogólnie nieakceptowalny poziom fałszywych alarmów
• Wiele nowych typów artefaktów nie jest skanowanych: infrastruktura jako kod, kontenery, API itp.

Wytwarzanie oprogramowania szybko było łatwiejsze. Wytwarzanie bezpiecznego oprogramowania szybko wciąż było trudne.

To był pierwotny problem, który postanowiliśmy rozwiązać. Uczynić DevSecOps skutecznym w świecie rzeczywistym; czy można uzyskać, aby zespół rozwojowy łatwo dodał zabezpieczenia do SDLC, z szybkością odpowiadającą nowym standardom prędkości? Czy można uczynić zasięg szerokim – gdzie jedna platforma jest wszystkim, czego potrzebujesz? Czy można to uczynić tak, aby deweloperzy, a nie tylko przyjmowali technologię, ale także widzieli korzyści? Czy można to uczynić skalowalnym, aby nie potrzebować armii specjalistów od zabezpieczeń, aby nadążyć za ilością napisanego kodu…

Pomogliśmy firmom wstrzyknąć zabezpieczenia do SDLC podczas ery DevOps. To było przechodzenie od 1 do 10. Teraz jesteśmy w erze kodowania agenty – gdzie agenci piszą ogromną ilość kodu – ale jest to fundamentalnie ten sam problem – prędkość i ilość kodu poszła od 10 do 100; a naszym celem jest kontynuowanie tej samej trajektorii.

Mówiłeś, że cykl życia rozwoju oprogramowania (SDLC) zmienił się fundamentalnie w górę. Jaki był moment, w którym zrozumiałeś, że tradycyjne podejścia DevSecOps już nie są wystarczające?

Było to obserwowanie, w jaki sposób atakujący naprawdę dostają się. Cały czas widzieliśmy ten sam wzorzec: narażony workflow GitHub Actions, który nikt nie przeglądał od momentu forkowania repozytorium, token z dostępem do produkcji w chmurze osadzony w konfiguracji uruchamiania, legitymowany job CI, który został przejęty w celu wdrożenia ładunku atakującego. Stały się one znane jako ataki “żyjące z potoku”, ponieważ przeciwnik wykorzystuje Twoją własną automatyzację przeciwko Tobie, z poświadczeniami, które Twoim zespołem bezpieczeństwa już zatwierdził.

Stos DevSecOps, który zbudowaliśmy przez dekadę, nie miał odpowiedzi na to. SAST skanuje źródło aplikacji. SCA skanuje zależności aplikacji. Oba zakładają, że potok, który je uruchamia, jest godny zaufania. Tymczasem sam potok jest plikiem YAML z poleceniami shell, dostępem do sieci i wrażliwymi poświadczeniami, i prawie nikt go nie przegląda.

Kiedy to staje się najłatwiejszą drogą, możesz wysłać idealnie czysty kod i nadal oddać atakującym Twoją chmurę.

Jak powinny firmy przemyśleć SDLC w świecie, w którym agenci AI generują kod w sposób ciągły, a nie deweloperzy piszą go krok po kroku?

Wszyscy musimy przestać myśleć o SDLC jako sekwencji punktów kontrolnych. Agenci AI skurczyli czas między “ktoś to napisał” a “to jest w produkcji” z tygodni do minut. Stary model zakładał ludzki rytm między przeglądem kodu, SAST, SCA i wdrożeniem, ale już tego nie mamy.

Zabezpieczenia muszą działać tam, gdzie działa agent: na maszynie deweloperskiej, w kontekście promptu, w połączeniach agenta z serwerami MCP i zewnętrznymi modelami. Zanim kod dotrze do potoku, straciłeś już szansę na jego ukształtowanie. Agent już pobrał zależność. Model już zobaczył poświadczenie. Przenieś kontrolę w górę, tam gdzie naprawdę się dzieje praca.

Wiele organizacji wciąż traktuje narzędzia do kodowania AI jako proste warstwy produktywności. Dlaczego uważasz, że reprezentują one całkowicie nową powierzchnię ataku, a nie tylko rozszerzenie istniejących przepływów pracy?

Traktowanie narzędzia do kodowania AI jako warstwy produktywności jest jak traktowanie junior developera z dostępem root jako warstwy produktywności. Etykieta jest technicznie poprawna, ale nie daje żadnego przydatnego ramienia do myślenia o tym, co może pójść nie tak.

Agent do kodowania czyta Twoją strukturę plików, wyłuskuje zmienne środowiskowe w celu uzyskania kontekstu, pobiera zależności z publicznych rejestrów, otwiera połączenia wychodzące do dostawców modeli i serwerów MCP, oraz wykonuje polecenia shell. Każde z tych działań wymagało wcześniej udziału człowieka. Teraz dzieje się to w milisekundach, z tymi samymi uprawnieniami co deweloper, który uruchomił agenta.

To kurczy granice zaufania, które wcześniej były oddzielone: uprawnienia deweloperów, to, co może pobrać zewnętrzne narzędzie, i to, co może wykonać niezaufany kod. To tworzy nowe możliwości dla atakujących i punkty ślepe, których obrońcy nawet nie widzą, nie mówiąc już o tym, że mogliby je obronić.

Boost przedstawia laptop deweloperski jako nowy plan kontrolny. Jakie ryzyka istnieją na punkcie końcowym, których zespoły bezpieczeństwa obecnie pomijają?

Największe z nich to inwentaryzacja. Większość zespołów bezpieczeństwa nie jest w stanie powiedzieć, które agenci AI działają na których laptopach, z którymi serwerami MCP te agenci są połączone, czy które rozszerzenia IDE są aktualnie wyłuskujące zawartość repozytorium. EDR nie ma widoczności w warstwie agenta; SIEM również nie widzi, co ci agenci robią lokalnie.

Pod tym leży bałagan poświadczeń. Zbudowaliśmy narzędzie open-source o nazwie Bagel częściowo po to, aby to uczynić konkretnym. Typowy laptop deweloperski zawiera tokeny GitHub z dostępem do repozytoriów produkcyjnych, poświadczenia chmury, które mogą uruchomić infrastrukturę, tokeny npm lub PyPI, które mogą opublikować do milionów użytkowników, oraz klucze usług AI, które atakujący odsprzedają. Żadne z nich nie jest zabezpieczone w sposób, w jaki zabezpiecza się uruchamianie CI. Ta sama maszyna, która zawiera te poświadczenia, również przegląda internet i instaluje losowe rozszerzenia VS Code.

Połącz to i masz rzeczywistą powierzchnię ataku. Nieuufany rozszerzenie działający z uprawnieniami deweloperskimi w środowisku pełnym kluczy chmury jest celem o najwyższej wydajności w nowoczesnym przedsiębiorstwie. Większość zespołów jeszcze nie zaczęła się tym zajmować.

Wskazałeś na “pułapkę kontekstu”, w której agenci AI mogą uzyskać dostęp do plików lokalnych, zmiennych środowiskowych i konfiguracji. Jak powszechny jest ryzyko wycieku danych wrażliwych za pośrednictwem promptów, i dlaczego jest tak trudno to wykryć?

Na tyle powszechny, że traktujemy to jako stan domyślny każdego niezarządzanego środowiska deweloperskiego. Każdy agent do kodowania, który sprawdziliśmy, agresywnie pobiera kontekst lokalny. Czytają pliki z kropką, zmienne środowiskowe, ostatnio używane pliki, czasem całe drzewa katalogów, i wysyłają ten kontekst do zdalnego modelu. Narzędzia są zaprojektowane, aby działać w ten sposób; agresywne pobieranie kontekstu jest tym, co sprawia, że są użyteczne.

Problem wykrywania zaczyna się od tego, że ruch z wyciekiem wygląda identycznie jak normalne użycie produktu. Jest to TLS do api.openai.com lub api.anthropic.com. Pochodzi z zatwierdzonej aplikacji biznesowej. Standardowy DLP widzi dewelopera używającego narzędzia AI, które firma właśnie kupiła. Nie widzi, że jeden ze stringów w tym prompcie jest kluczem tajnym AWS, który agent pobrał z półzapomnianego pliku .env w katalogu podrzędnym.

Można to złapać tylko przez zbadanie promptów przed ich opuszczeniem laptopa, co jest dokładnie tam, gdzie praktycznie żaden stos bezpieczeństwa nie jest obecnie umiejscowiony.

Mówiłeś o atakach łańcucha dostaw o prędkości maszyny. Przedstaw realistyczny scenariusz, w którym agent AI wprowadza lukę w zabezpieczeniach szybciej, niż tradycyjne narzędzia bezpieczeństwa mogą ją zidentyfikować.

Oto jeden, którego wariacje widzieliśmy wielokrotnie. Deweloper prosi agenta o dodanie funkcji, która wymaga biblioteki ponownego połączenia HTTP. Agent sugeruje nazwę pakietu. Pakiet brzmi prawdopodobnie, ale nie istnieje naprawdę w npm. W ciągu godziny atakujący rejestruje go, wypełnia go działającą logiką ponownego połączenia plus małym skryptem post-install, który czyta ~/.aws/credentials i wysyła zawartość do webhook. Agent uruchamia npm install bez sprawdzania, bo agenci nie sprawdzają reputacji. Poświadczenie znika, zanim deweloper nawet uruchomi kod.

Atak sam w sobie nie jest technicznie wyrafinowany, ale tradycyjne zabezpieczenia łańcucha dostaw są zbudowane wokół znanych luk w zabezpieczeniach w znanych pakietach: CVE, SBOM, skanowanie licencji. Ten framework nie ma nic do powiedzenia o pakiecie, który nie istniał, gdy ostatni raz uruchomiono skanowanie.

Okno od publikacji do naruszenia jest teraz mierzone w minutach. Cokolwiek sprawdza po fakcie sprawdza za późno.

Czy hallucynowane zależności stają się jednym z największych ryzyk w rozwoju napędzanym przez AI, i jakie praktyczne kroki mogą podjąć organizacje, aby się bronić przed nimi?

Już są jednym z największych. Atakujący aktywnie monitorują popularne narzędzia AI w celu hallucynacji i rejestrują sugerowane nazwy pakietów w ciągu kilku minut. Badacze kilka lat temu, gdy to się zaczęło dziać, nazywali to slopsquatting i nazwa przyjęła się. Jak tylko nazwa zależności jest hallucynowana często, siedzenie na niej jest biernym atakiem łańcucha dostaw o prawie zerowym wysiłku.

Praktyczne obrony wyglądają inaczej niż to, co większość zespołów obecnie posiada. Zacznij od pobierania. Blokuj pakiety podszyte i nowo zarejestrowane w momencie, gdy npm install lub pip install są uruchamiane, na maszynie deweloperskiej, przed tym, jak cokolwiek trafi na dysk. Wykrywanie post-mortem w CI nie pomaga, gdy skrypt post-install już wyeksfiltruje poświadczenie. Następnie daj agentowi barierki, aby mógł działać wewnątrz. Wstrzyknij listę zatwierdzonych zależności bezpośrednio do kontekstu agenta, aby model widział, co jest dozwolone, zanim wygeneruje sugestię. Proszanie deweloperów o pisanie “bezpiecznych promptów” nie jest strategią. Jeśli jesteś strategiczny, oznacza to, że bezpieczeństwo ustawia granicę, a agent dziedziczy ją. I zacznij śledzić AI Bill of Materials. Większość zespołów nie jest w stanie powiedzieć, które agenci, modele i pakiety dotykają których repozytoriów. Nie można obronić tego, czego nie można inwentaryzować.

Mówiłeś, że zabezpieczenia już nie mogą zaczynać się w CI/CD. Wygląda jak nowoczesny potok zabezpieczeń, gdy ochrona musi zaczynać się wcześniej w procesie rozwoju.

Jeśli zabezpieczenia zaczynają się w CI/CD, to oddałeś całą fazę przed zapisaniem do środowiska, której nie kontrolujesz. Agent już pobrał kontekst, twoje poświadczenie może już być w czyichś logach. Skanujesz zwłoki.

Nowoczesny potok zaczyna się na laptopie. Oznacza to inwentaryzowanie agentów i rozszerzeń działających tam, walidację, do których serwerów MCP i modeli są dozwolone, sanitarne czyszczenie tego, co opuszcza maszynę, i blokowanie pakietów złośliwych przed ich zainstalowaniem. Stamtąd polityka podąża za pracą do IDE. Wstrzykujemy standardy zabezpieczeń bezpośrednio do kontekstu okna agenta, aby wygenerowany kod pozostał w barierkach od pierwszego tokenu. Potok nadal działa, wykonując ostateczną weryfikację kontroli, które zostały już wymuszone na górze.

Potok sam w sobie nie znika. Jego rola staje się weryfikacją: potwierdzeniem, że kontrola na górze się utrzymała.

Jak organizacje kontynuują przyjmowanie agentów do kodowania AI, jakie są najbardziej krytyczne zmiany, które muszą wprowadzić dzisiaj, aby ich środowiska rozwojowe pozostały bezpieczne w ciągu najbliższych kilku lat?

Największy błąd polega na zabezpieczaniu tylko tego, co zostaje zatwierdzone. Najbardziej interesujące ryzyko teraz żyje w ośmiu godzinach przed zatwierdzeniem. Niewidoczna dramatyczna sytuacja może rozegrać się na laptopie, w prompcie lub w instalacji pakietu. Jeśli Twoje narzędzia zaczynają się od PR, chronisz niewłaściwą połowę przepływu pracy.

Ściśle związane z tym: przestań traktować agenci do kodowania jako oprogramowanie produktywności. Są to nie-ludzkie użytkownicy z dostępem do shell, uprawnieniami do zapisu repozytorium i połączeniami wychodzącymi. Rządzaj nimi w taki sam sposób, w jaki rządzisz każdą inną tożsamością uprzywilejowaną, z inwentaryzacją, zatwierdzonymi możliwościami i logami inspekcji.

Ostatnia zmiana jest trudniejsza kulturowo. Większość obecnych narzędzi “zabezpieczeń AI” prezentuje wyniki i kieruje je do ludzi. Ludzie nie mogą triażować z prędkością, z jaką agenci generują. Cokolwiek przyjmujesz, musi rozwiązywać problemy automatycznie wewnątrz przepływu pracy, z możliwym do prześledzenia powodem, lub staje się kolejnym dashboardem, który nikt nie czyta.

Dziękuję za wspaniały wywiad, czytelnicy, którzy chcą dowiedzieć się więcej, powinni odwiedzić Boost Security.