Shahar Man, współzałożyciel i CEO Backslash Security – seria wywiadów

Shahar Man, współzałożyciel i CEO Backslash Security, to doświadczony lider technologiczny z głęboką wiedzą w zakresie rozwoju chmury, bezpieczeństwa cybernetycznego i oprogramowania przedsiębiorstw. Obecnie kieruje Backslash Security, firmą zajmującą się zabezpieczaniem środowisk rozwoju oprogramowania opartych na sztucznej inteligencji, chroniąc wszystko, od środowisk programistycznych i agentów AI po wygenerowany kod i przepływy pracy. Wcześniej pełnił stanowiska kierownicze w firmie Aqua Security, gdzie był wiceprezesem ds. zarządzania produktem i wiceprezesem ds. badań i rozwoju, pomagając budować jedną z wiodących platform bezpieczeństwa kontenerów w całym cyklu rozwoju. Na początku swojej kariery Man spędził ponad dekadę w firmie SAP, gdzie kierował projektami rozwojowymi i produktowymi, w tym SAP Web IDE, oraz współpracował z klientami przedsiębiorstw na całym świecie, a także przyczynił się do rozwoju ekosystemu deweloperów. Jego kariera rozpoczęła się od ról technicznych i kierowniczych w środowiskach startupów i jednostek technologicznych obrony Izraela, dając mu silne podstawy w inżynierii i systemach wielkoskalowych.

Backslash Security to wschodząca platforma bezpieczeństwa cybernetycznego stworzona z myślą o erze rozwoju oprogramowania opartego na sztucznej inteligencji. Firma koncentruje się na zabezpieczaniu całego stosu rozwoju oprogramowania opartego na AI, w tym agentów AI, potoków generowania kodu i nowoczesnych przepływów pracy deweloperów, obszaru często pomijanego przez tradycyjne narzędzia bezpieczeństwa. Poprzez zapewnienie widoczności, zarządzania i ochrony w czasie rzeczywistym bez zakłócania prędkości deweloperów, Backslash ma na celu rozwiązanie rosnących ryzyk wprowadzonych przez środowiska kodowania automatycznego i „vibe coding”. Ponieważ tworzenie oprogramowania coraz bardziej przechodzi w kierunku systemów wspomaganych przez AI, platforma jest zaprojektowana tak, aby zapewnić, że bezpieczeństwo ewoluuje równolegle, a nie staje się wąskim gardłem, umieszczając Backslash na skrzyżowaniu DevSecOps i następnej generacji rozwoju AI.

Miałeś stanowiska kierownicze w dziale produktu i badań w firmach takich jak Aqua Security i SAP, zanim założyłeś Backslash. Jakie wczesne sygnały przekonały cię, że rozwój oprogramowania opartego na AI i vibe coding zmienią podstawy tworzenia oprogramowania, i że bezpieczeństwo musi być odbudowane, aby je wspierać?

Miałem już okazję przeżyć jeden wielki przeskok, kiedy oprogramowanie przeniosło się do architektur chmurowych. W SAP i później w Aqua widzieliśmy na własne oczy, że kiedy rozwój zmienia się tak bardzo, bezpieczeństwo zwykle pozostaje w tyle. AI podniosło tę prawdę na zupełnie nowy poziom, nie tylko dlatego, że może pomóc pisać kod szybciej, ale dlatego, że zaczęło zmieniać całe środowisko wokół tworzenia oprogramowania.

Zabezpieczanie kodu jest teraz mniej związane z samym kodem, a bardziej ze środowiskiem wokół niego. W ciągu weniger niż roku to, co kiedyś było stosunkowo zawartym i niskim ryzykiem środowiska rozwoju, rozrosło się w rozległą, wysoko połączoną powierzchnię ataku z niewielką kontrolą ani zarządzaniem. Gdy to się stało, pytania bezpieczeństwa dotyczące luk w zabezpieczeniach kodu zmieniły się całkowicie. Prawdziwy problem nie polega na tym, czy dany kawałek kodu jest podatny na ataki. Problem polega na tym, że wprowadzając rozwój oparty na AI, wprowadziliśmy systemy, agenci, integracje i ścieżki dostępu, które sięgają daleko poza sam kod. Bezpieczeństwo nie może już skupiać się tylko na wyjściu kodu. Musi uwzględniać całe środowisko, które umożliwia ten kod.

Opisujesz vibe coding jako rozszerzanie powierzchni ataku poza kod w kierunku sugestii, agentów, serwerów MCP i warstw narzędzi. Jakie są najbardziej niezrozumiane ryzyka w tym nowym stosie, których deweloperzy i zespoły bezpieczeństwa obecnie pomijają?

Największe niezrozumienie polega na tym, że wiele zespołów nadal uważa, że ryzyko mieszka głównie w wygenerowanym kodzie. To jest tylko jedna warstwa. W rozwoju opartym na AI ryzyko jest wprowadzane wcześniej i w wielu więcej miejscach. Może to być w sugestiach, w kontekście dostarczonym do modelu, w uprawnieniach przyznanych agentom, w serwerach MCP, do których łączą się, lub w zewnętrznych narzędziach i wtyczkach, które rozszerzają ich zasięg. Jeden laptop użytkownika może zostać przejęty i użyty jako przyczółek szerszego ataku. To jest punkt bólu punktu końcowego maskujący się jako problem kodowania AI. W przeciwieństwie do luk w zabezpieczeniach kodu, to nie tylko naraża aplikacje na ryzyko – może narażać całą organizację na ryzyko. Jeśli spoglądasz tylko na kod, pomijasz większość obrazu.

Tradycyjne bezpieczeństwo aplikacji koncentrowało się głównie na przeglądzie kodu. Jak myślenie o bezpieczeństwie musi ewoluować, gdy agenci AI generują, modyfikują i wdrażają kod w czasie rzeczywistym?

Bezpieczeństwo musi przechodzić od okresowych inspekcji do ciągłego nadzoru. Pojęcie zaufania jest całkowicie złamane – możesz mieć zaufane modele i zaufane serwery MCP, ale ze względu na nieprzewidywalną naturę AI, mogą one być manipulowane lub po prostu źle się zachowywać, tworząc nieoczekiwane ryzyko.

To oznacza również, że musi nastąpić zmiana myślenia, w której bezpieczeństwo działa obok procesu rozwoju, gdy ten zachodzi, i ma znacznie głębsze zarządzanie, barierki i możliwości wykrywania i reagowania w tym środowisku. To oznacza myślenie krytycznie o tym, jakie narzędzia są używane, jaki kontekst są one konsumują, jakie polityki powinny je rządzić i jakie działania podejmują one w czasie rzeczywistym.

Dodatkowo, nie możemy ignorować roli AI i modeli AI w obsłudze luk w zabezpieczeniach. Jeśli rok temu modele AI dawały wiele luk w zabezpieczeniach domyślnie, rzeczy znacznie się poprawiły, a inne modele są teraz używane do znalezienia zero-day, które wcześniej nie były znalezione. Więc idziemy w kierunku lepszych wyników – ale kto dba o sklep, gdy to robimy? Atakujący szukają gdzie indziej.

Narzędzia takie jak Cursor, Claude Code i GitHub Copilot stają się standardem w przepływach pracy deweloperów. Gdzie widzisz największe luki bezpieczeństwa, gdy zespoły przyjmują te narzędzia bez odpowiedniej warstwy zarządzania?

Największa luka jest widoczność. W wielu organizacjach te narzędzia rozprzestrzeniają się szybko i bez formalnej recenzji. Zespoły bezpieczeństwa często nie wiedzą, które agenci są używane, jak są skonfigurowane, jakie dane mogą uzyskać dostęp i do jakich zewnętrznych systemów łączą się. To tworzy problem cieni AI, który jest podobny do cieni IT w zasadzie, tylko szybszy i bardziej dynamiczny.

Druga co do wielkości luka to brak egzekwowalnych polityk. Większość organizacji może mieć wytyczne, ale wytyczne same w sobie nie pomagają zbyt wiele, gdy deweloper porusza się szybko wewnątrz środowiska programistycznego. Bez zarządzania na poziomie narzędzi i przepływu pracy, zespoły ryzykują nadmiernie uprawnionymi narzędziami, które nie spełniają standardów przedsiębiorstwa. Te narzędzia same w sobie nie są złe, ale ich przyjęcie bez zarządzania oznacza, że skaliści prędkość rozwoju bez skali kontroli.

Trzecia pojawiająca się luka to to, że każdy może potencjalnie stać się deweloperem – co nazywamy citizen-deweloperami, używając narzędzi vibe coding. Gdy osoba z działu finansowego używa Claude Code do automatyzacji procesów i łączenia się z wewnętrznymi systemami, tworzy to potencjalne ryzyko i jest ogromną ślepą plamą nawet dzisiaj.

Backslash koncentruje się na zabezpieczaniu całego ekosystemu rozwoju AI, a nie poszczególnych narzędzi. Dlaczego jest to pełnoekranowy podejście konieczne, i co się stanie, jeśli organizacje będą nadal traktować te ryzyka w izolacji?

Ponieważ ryzyko nie siedzi ładnie wewnątrz żadnego produktu w Twoim stosie. Rozwój oparty na AI jest wewnętrznie problemem ekosystemu, ponieważ działa w tak wielu różnych miejscach, używając tak wielu różnych narzędzi. Środowisko programistyczne, model, agenci, serwery MCP, zewnętrzne wtyczki, tożsamości i połączone źródła danych wszystkie wpływają na to, co jest budowane i jak. Organizacje nie standaryzują się na jednym narzędziu, ponieważ ich względne siły zmieniają się tak szybko. Jeśli zabezpieczysz tylko jeden punkt w tym łańcuchu, nadal pomijasz, jak ryzyko porusza się przez system.

Traktowanie tych ryzyk w izolacji prowadzi do fragmentarycznych obron i niebezpiecznych ślepych plam. Możesz zahartować skaner kodu, ale pominąć serwer MCP, który wprowadził ryzykowny kontekst do modelu. To dlatego uważamy, że właściwe podejście to pełnoekranowa widoczność i ochrona w czasie rzeczywistym w całym ekosystemie rozwoju AI. W przeciwnym razie organizacje będą nadal rozwiązywać objawy, podczas gdy rzeczywista powierzchnia ataku nadal się rozszerza pod nimi.

Sugestie są coraz częściej nową warstwą programowalności. Jak organizacje powinny podejść do zabezpieczania sugestii i zapobiegania problemom takim jak iniekcja sugestii, wyciek danych lub manipulacja?

Sugestie coraz częściej kształtują logikę i zachowanie. W wielu przypadkach są one skutecznie nowym planem kontroli tworzenia oprogramowania. To oznacza, że potrzebują polityki, monitorowania i barierek, tak jak definicje kodu lub infrastruktury. W praktyce zaczyna się to od ograniczania tego, do czego sugestie mogą uzyskać dostęp, i jakie działania mogą wywołać. Oznacza to również definiowanie reguł sugestii, które są zgodne z oczekiwaniami bezpieczeństwa i jakości, zapobiegając narażeniu danych wrażliwych poprzez okna kontekstowe i obserwowanie prób manipulacji, takich jak iniekcja sugestii lub pośrednie przejęcie instrukcji. I również obejmuje to zapewnienie, że same reguły nie są używane jako tylna furtka do iniekcji sugestii. Szeroki punkt widzenia jest taki, że nie zabezpieczasz sugestii, mówiąc deweloperom i agentom, aby „byli ostrożni”. Zabezpieczasz je, wbudowując kontrolę w środowisku, w którym sugestie naprawdę zachodzą.

Serwery MCP i umiejętności agentów wprowadzają dynamiczne połączenia między systemami. Z punktu widzenia bezpieczeństwa, czy reprezentują one największy nowy wektor ryzyka w rozwoju opartym na AI?

Serwery MCP i umiejętności agentów reprezentują znaczącą nową warstwę ryzyka, ponieważ definiują, jak systemy AI łączą się z i wchodzą w interakcje ze światem rzeczywistym. Umiejętności definiują, co agent jest upoważniony do zrobienia, podczas gdy MCP rozszerza jego dostęp do kontekstu i systemów. Razem kształtują rzeczywiste zachowanie agenta. Jeśli te warstwy nie są ściśle kontrolowane, organizacje tracą widoczność w tym, czym są ich narzędzia AI w stanie i co one naprawdę robią. Przeskok od generowania kodu do podejmowania działań jest tym, co czyni tę dziedzinę tak krytyczną dla bezpieczeństwa, i stają się one bardziej nieprzewidywalne, gdy łączymy je razem.

Jeden z Twoich podstawowych tematów to „bycie departamentem Tak” – umożliwianie bezpieczeństwa bez spowalniania deweloperów. Jak balansujesz ochronę w czasie rzeczywistym z prędkością deweloperów w środowiskach, w których prędkość jest krytyczna?

Bezpieczeństwo tworzy tarcie, gdy występuje późno lub jest odłączone od tego, jak deweloperzy naprawdę pracują. Staje się znacznie bardziej skuteczne, gdy jest wbudowane bezpośrednio w przepływ pracy i skupione na tym, co naprawdę ma znaczenie. To było częścią naszego myślenia od samego początku Backslash, i ma to jeszcze większe znaczenie teraz w rozwoju opartym na AI.

W praktyce oznacza to prezentowanie tylko kilku problemów, które reprezentują prawdziwe ryzyko, a nie zalewanie deweloperów wszystkim, co wygląda podejrzanie. Oznacza to egzekwowanie polityki w środowisku programistycznym i przepływie pracy agenta, a nie po fakcie. I oznacza to tworzenie przejrzystych, deterministycznych barier, aby zespoły mogły poruszać się szybko, wiedząc, jakie narzędzia są używane, jakie uprawnienia mają i kiedy coś niezwykłego się dzieje. Celem nie jest spowolnienie adopcji AI, ale pomoc organizacjom w przyjęciu jej z zaufaniem, nie tracąc kontroli. W rzeczywistych warunkach oznacza to, że deweloper miałby mniej miejsca na popełnienie błędów na pierwszym miejscu, ale jeśli popełni jeden, zostanie on szybko wykryty i rozwiązany.

Widzimy, jak nie-techniczni użytkownicy coraz częściej budują oprogramowanie za pomocą narzędzi AI. Jak wzrost nie-deweloperskich vibe coderów zmienia krajobraz zagrożeń?

Rozszerza krajobraz zagrożeń na dwa sposoby. Po pierwsze, dramatycznie zwiększa liczbę ludzi, którzy mogą produkować dane wyjściowe podobne do oprogramowania bez zrozumienia implikacji bezpieczeństwa. Po drugie, tworzy fałszywe poczucie bezpieczeństwa, ponieważ narzędzia sprawiają, że rozwój wydaje się konwersacyjny i niskotarcie.

Oznacza to, że organizacje zobaczą więcej aplikacji, automacji i integracji stworzonych przez ludzi, którzy nie są przeszkoleni do rozważania granic zaufania, walidacji danych wejściowych, higieny zależności, kontroli dostępu lub narażenia danych. Innymi słowy, powierzchnia ataku rozszerza się nie tylko dlatego, że AI pisze więcej kodu, ale dlatego, że więcej ludzi może teraz generować przepływy pracy i systemy, które zachowują się jak oprogramowanie, nie stosując podstawowych, higienicznych zasad inżynierskich. To sprawia, że widoczność i wbudowane zabezpieczenia stają się jeszcze ważniejsze, ponieważ nie można już założyć wiedzy o bezpieczeństwie w punkcie tworzenia.

Spójrzając w przyszłość 12-24 miesięcy, jakie typy ataków lub luk w zabezpieczeniach oczekujesz, które pojawią się specjalnie z powodu przepływów pracy rozwoju opartego na AI?

Oczekujemy, że wiele wspólnych luk w zabezpieczeniach kodu będzie unikanych na początku dzięki ulepszeniom w samych LLM, lub dzięki lepszym wbudowanym regułom sugestii w „harnessie”, który otacza te narzędzia. Jeśli teraz widzimy wzrost ilości luk w zabezpieczeniach z powodu zwiększonej prędkości, to się poprawi. A to, co nie zostanie poprawione, zostanie rozwiązane przez narzędzia SAST i SCA wspomagane przez AI (niektóre z nich będą również dostarczane przez samych dostawców platform AI, np. Claude Code Security i projekt Glasswing).

Jednak spodziewam się znacznie gorszych skutków, gdy chodzi o narażenia spowodowane użyciem niezweryfikowanych i niesupervizowanych narzędzi AI w rozwoju aplikacji – takich jak agenci open-source (OpenClaw jest dobrym przykładem), które mają bardzo słabe domyślne ustawienia bezpieczeństwa, połączone z użytkownikami, których wiedza o bezpieczeństwie jest znacznie przewyższona przez ich entuzjazm dla vibe coding.

W konsekwencji uważam, że będziemy świadkami przesunięcia ku atakom na sam ekosystem rozwoju, a nie tylko systemy produkcyjne. Ponieważ AI staje się częścią tworzenia oprogramowania, atakujący będą koncentrować się na manipulowaniu narzędziami i połączeniami, które kształtują ten proces, skutecznie kompromitując oprogramowanie, zanim zostanie wdrożone.

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