Shahar Man, spoluzakladatel a CEO Backslash Security – Interview Series

Shahar Man, spoluzakladatel a CEO Backslash Security, je zkušený technologický lídr s hlubokými znalostmi v oblasti cloudového vývoje, kybernetické bezpečnosti a softwaru pro podniky. V současné době vede Backslash Security, společnost zaměřenou na zabezpečení vývojových prostředí pro AI-nativní software, chránící vše od integrovaných vývojových prostředí a agentů AI až po generovaný kód a pracovní postupy pro vyvolání. Předtím zastával seniorní vedoucí pozice v Aqua Security, kde působil jako viceprezident pro produktový management a viceprezident pro výzkum a vývoj, a pomáhal budovat jednu z předních platforem pro zabezpečení kontejnerů po整个 vývojovém cyklu. Na počátku své kariéry strávil Man více než deset let v SAP, kde vedl vývoj a produktové iniciativy, včetně SAP Web IDE, a úzce spolupracoval s globálními podnikovými zákazníky, zatímco také přispíval k růstu vývojářské ekosystémy. Jeho kariéra začala v technických a vedoucích rolích v startupových prostředích a izraelských obranných technických jednotkách, což mu poskytlo silný základ v oblasti inženýrství a velkých systémů.

Backslash Security je vznikající kybernetická bezpečnostní platforma, která je speciálně navržena pro éru AI-poháněného softwarového vývoje. Společnost se zaměřuje na zabezpečení celého AI-nativního vývojového stacku, včetně agentů AI, generátorů kódu a moderních vývojářských pracovních postupů, oblasti, kterou tradiční bezpečnostní nástroje často přehlížejí. Poskytováním viditelnosti, správy a ochraně v reálném čase bez narušení rychlosti vývojářů se Backslash snaží řešit rostoucí rizika, která jsou zaváděna automatizovaným kódováním a “vibe coding” prostředími. Jak se vytváření softwaru stále více přesouvá směrem k AI-asistovaným systémům, je platforma navržena tak, aby zajistila, že bezpečnost se vyvíjí paralelně, a nikoli se stává úzkým místem, a tím se Backslash nachází na rozhraní DevSecOps a další generace AI vývoje.

Měli jste vedoucí role v produktu a výzkumu ve společnostech jako Aqua Security a SAP, než jste založili Backslash. Jaké rané signály vás přesvědčily, že AI-nativní vývoj a “vibe coding” budou zásadně měnit tvorbu softwaru, a že bezpečnost musí být přestavěna, aby jim mohla čelit?

Již jsem prošel jednou velkou změnou, když se software přesunul do cloudových architektur. V SAP a později v Aqua jsme viděli na vlastní oči, že když se vývoj změní tak moc, bezpečnost obvykle zaostává. AI tuto pravdu vzala na úplně novou úroveň, nejen proto, že může pomoci psát kód rychleji, ale protože začala měnit celé prostředí kolem softwarové tvorby.

Zabezpečení kódu již není tolik o kódu samotném, ale spíše o prostředí kolem něj. Za méně než rok se co bývalo relativně uzavřeným a nízkorizikovým vývojovým nastavením rozrostlo do rozsáhlého, vysoce propojeného útočného povrchu s malou kontrolou nebo správou. Jakmile k tomu došlo, bezpečnostní otázky kolem zranitelností kódu se změnily úplně. Skutečný problém není, zda je určitý kus kódu zranitelný. Problém je, že při zavádění AI-poháněného vývoje jsme zavedli systémy, agenty, integrace a přístupové cesty, které sahají daleko za hranice kódu samotného. Bezpečnost již nemůže soustředit pouze na výstup kódu. Musí zohlednit celé prostředí, které umožňuje, aby kód existoval.

Popisujete “vibe coding” jako rozšíření útočného povrchu za hranice kódu do podnětů, agentů, serverů MCP a vrstev nástrojů. Jaká jsou nejčastěji nepochopená rizika v tomto novém stacku, která vývojáři a bezpečnostní týmy v současné době přehlížejí?

Největší nedorozumění spočívá v tom, že mnoho týmů stále myslí, že riziko žije hlavně v generovaném kódu. To je pouze jedna vrstva. V AI-nativním vývoji je riziko zaváděno dříve a na mnoha více místech. To může být v podnětech, v kontextu dodaném modelu, v oprávněních udělených agentům, v serverech MCP, ke kterým se připojují, nebo v externích nástrojích a pluginích, které rozšiřují jejich dosah. Jeden uživatelský laptop může být převzat a použit jako mostní hlava širšího útoku. Je to bod bolesti koncového bodu, který se maskuje jako problém kódování AI. Na rozdíl od zranitelností kódu toto neohrožuje pouze vaše aplikace – může ohrozit celou vaši organizaci. Pokud se díváte pouze na kód, přehlížíte většinu obrazu.

Tradiční bezpečnost aplikací se soustředila silně na kontrolu kódu. Jak musí bezpečnostní myšlení evoluvat, když agenty AI generují, mění a nasazují kód v reálném čase?

Bezpečnost musí přejít z periodické inspekce na nepřetržitou kontrolu. Pojem důvěry je zcela rozbitý – můžete mít důvěryhodné modely a důvěryhodné servery MCP, ale kvůli nedeterministické povaze AI mohou být stále manipulovány nebo prostě chovat neočekávaným způsobem a vytvářet neočekávaná rizika.

To také znamená, že musí dojít k posunu v myšlení, kdy bezpečnost funguje vedle vývojového procesu, jak se udál, a má mnohem hlubší správu, zábrany a detekční a reakční schopnosti v rámci tohoto prostředí. To znamená kriticky uvažovat o tom, které nástroje se používají, jaký kontext spotřebují, jaké zásady by je měly řídit, a jaké akce provádějí v reálném čase.

Dále nelze ignorovat roli AI a modelů AI při zpracování zranitelností. Pokud před rokem modely AI poskytly mnoho zranitelností ve výchozím nastavení, věci se dramaticky zlepšily, a další modely jsou nyní použity k nalezení nulových dnů, které nebyly dříve nalezeny. Takže se blížíme k lepšímu výstupu – ale kdo dohlíží na obchod, zatímco to děláme? Útočníci hledají jinde.

Nástroje jako Cursor, Claude Code a GitHub Copilot se stávají standardem ve vývojářských pracovních postupech. Kde vidíte největší bezpečnostní mezery, když týmy přijmou tyto nástroje bez řádné vrstvy správy?

Největší mezera je viditelnost. Ve mnoha organizacích se tyto nástroje šíří rychle a bez formální kontroly. Bezpečnostní týmy často neví, které agenty se používají, jak jsou nakonfigurovány, jaké údaje mohou získat přístup, nebo které externí systémy jsou s nimi spojeny. To vytváří problém “stínové AI”, který je podobný “stínové IT” principu, pouze rychlejší a dynamičtější.

Druhou největší mezerou je absence vynutitelných zásad. Většina organizací může mít pokyny, ale pokyny samotné nepomohou mnoho, když vývojář se pohybuje rychle uvnitř integrovaného vývojového prostředí. Bez správy na úrovni nástrojů a pracovních postupů riskují týmy, že budou mít nástroje s nadměrnými oprávněními, které nesplňují podnikové standardy. Tyto nástroje nejsou samy o sobě špatné, ale jejich přijetí bez správy znamená, že efektivní vývojová rychlost není doprovázena kontrolou.

Třetí vznikající mezerou je, že každý může potenciálně stát se vývojářem – co nazýváme “občanskými vývojáři”, kteří používají nástroje “vibe coding”. Když finanční pracovník používá Claude Code k automatizaci procesů a připojení k interním systémům, vytváří potenciální riziko a je to obrovská slepá skvrna, dokonce i dnes.

Backslash se zaměřuje na zabezpečení celého ekosystému AI vývoje, spíše než na jednotlivé nástroje. Proč je tento plnohodnotný přístup nutný, a co se stane, když organizace budou pokračovat v léčbě těchto rizik izolovaně?

Protože riziko nesedí pěkně uvnitř žádného produktu ve vašem stacku. AI-nativní vývoj je inherentně ekosystémovým problémem, protože funguje na mnoha různých místech, pomocí mnoha různých nástrojů. Integrované vývojové prostředí, model, agenty, servery MCP, externí pluginy, identity a připojené datové zdroje všechny ovlivňují, co se vytváří a jak. Organizace úmyslně nestandardizují na jeden nástroj, protože jejich relativní síly se mění tak rychle. Pokud zabezpečujete pouze jeden bod v této řetězci, stále chybí, jak riziko přechází přes systém.

Léčba těchto rizik izolovaně vede k fragmentovaným obranám a nebezpečným slepým skvrnám. Můžete zpevnit skener kódu, ale přehlédnout server MCP, který rizikový kontext dodal modelu. To je důvod, proč věříme, že správný přístup je plnohodnotná viditelnost a ochrana v reálném čase napříč celým ekosystémem AI vývoje. Jinak budou organizace pokračovat v řešení symptomů, zatímco skutečný útočný povrch bude i nadále expandovat pod nimi.

Prompting se objevuje jako nová vrstva programovatelnosti. Jak by organizace měly přistupovat k zabezpečení podnětů a prevenci problémů, jako je injekce podnětů, únik dat nebo manipulace?

Podněty stále více formují logiku a chování. Ve mnoha případech jsou efektivní novou řídicí rovinou pro softwarovou tvorbu. To znamená, že potřebují zásady, monitorování a zábrany, stejně jako kód nebo definice infrastruktury by. Prakticky to začíná omezením toho, co podněty mohou získat přístup, a co následné akce mohou vyvolat. To také znamená definování pravidel pro podněty, která jsou v souladu s bezpečnostními a kvalitativními očekáváními, prevenci expozice citlivých údajů prostřednictvím kontextových oken a sledování pokusů o manipulaci, jako je injekce podnětů nebo nepřímé převzetí instrukcí. A to také zahrnuje zajištění, aby pravidla sama o sobě nebyla použita jako zadní vrátka pro injekci podnětů. Širší bod je, že nezabezpečujete podněty tím, že developerům a agentům řeknete “buďte opatrní”. Zabezpečujete je tím, že vložíte kontroly do prostředí, kde se podněty skutečně vyskytují.

Servery MCP a dovednosti agentů zavádějí dynamické spojení mezi systémy. Z bezpečnostního hlediska zastupují tyto nejnovější vektor rizika v AI-poháněném vývoji?

Servery MCP a dovednosti agentů zastupují velkou novou vrstvu rizika, protože definují, jak systémy AI se připojují a interagují s reálným světem. Dovednosti definují, co je agent oprávněn dělat, zatímco MCP rozšiřuje jeho přístup k kontextu a systémům. Společně formují skutečné chování agenta. Pokud tyto vrstvy nejsou těsně kontrolovány, organizace ztrácí viditelnost do toho, co jejich nástroje AI jsou schopny dělat a co skutečně dělají. Přechod od generování kódu k provádění akcí je to, co dělá tuto oblast tak kritickou pro bezpečnost, a stává se ještě nepředvídatelnější, když je spojíte.

Jedním z vašich hlavních témat je “být oddělením ano” – umožnit bezpečnost bez zpomalení vývojářů. Jak vyvažujete ochranu v reálném čase s vývojářskou rychlostí v prostředích, kde rychlost je kritická?

Bezpečnost vytváří tření, když se vyskytuje pozdě nebo je odpojena od toho, jak vývojáři skutečně pracují. Stává se mnohem účinnější, když je vložena přímo do pracovního postupu a zaměřena na to, co skutečně záleží. To bylo součástí našeho myšlení od začátku Backslash, a ještě více to platí nyní v AI-poháněném vývoji.

V praxi to znamená, že se zobrazují pouze několik problémů, které reprezentují skutečné riziko, a ne zaplňují vývojáře vším, co vypadá teoreticky podezřele. To znamená vynucovat zásady v integrovaném vývojovém prostředí a pracovním postupu agenta, a ne až poté. A to znamená vytvářet transparentní, deterministické zábrany, aby týmy mohly pohybovat rychle, zatímco stále vědí, které nástroje se používají, jaké oprávnění mají a kdy se něco neobvyklého děje. Cílem není zpomalit přijetí AI, ale pomoci organizacím přijmout ji s důvěrou, aniž by ztratily kontrolu. V reálných termínech to znamená, že vývojář bude mít méně prostoru pro chyby na prvním místě, ale pokud udělá chybu, bude chyba zachycena a zpracována rychle.

Stále více vidíme, že ne-techničtí uživatelé vytvářejí software pomocí nástrojů AI. Jak se mění hrozivá krajina s rostoucím počtem “vibe coding” ne-developerů?

Rozšiřuje se hrozivá krajina dvěma způsoby. Za prvé, dramaticky zvyšuje počet lidí, kteří mohou produkovat software-like výstupy, aniž by chápali bezpečnostní důsledky. Za druhé, vytváří falešný pocit bezpečí, protože nástroje dělají vývoj feel konverzační a nízkorizikový.

To znamená, že organizace uvidí více aplikací, automatizací a integrací vytvořených lidmi, kteří nejsou školeni, aby zvažovali hranice důvěry, validaci vstupu, hygienu závislostí, kontrolu přístupu nebo expozici dat. Jinými slovy, útočný povrch se rozšiřuje nejen proto, že AI píše více kódu, ale protože více lidí může nyní generovat pracovní postupy a systémy, které se chovají jako software, aniž by aplikovali základní, hygienické inženýrské disciplíny. To dělá viditelnost a vestavěné zábrany ještě důležitější, protože již nelze předpokládat znalosti bezpečnosti v místě tvorby.

Pohledem na budoucnost 12 až 24 měsíců, jaké typy útoků nebo zranitelností očekáváte, že se objeví specificky kvůli AI-nativním vývojovým pracovním postupům?

Očekáváme, že mnoho běžných zranitelností kódu bude避nuto předem díky vylepšením LLM, nebo díky lepšímu vloženému pravidel pro podněty v “harness”, který obklopuje tyto nástroje. Pokud jsme před rokem viděli nárůst objemu zranitelností pouze kvůli zvýšené rychlosti, toto se napraví. A co nebude napraveno, bude pronásledováno AI-umožněným SAST a SCA (některé z nich budou také poskytovány dodavateli AI platformy, např. Claude Code Security a projekt Glasswing).

Avšak očekávám horší výsledky, pokud jde o expozice způsobené použitím neověřených a nesupervizovaných nástrojů AI v aplikacím – jako jsou open-source agenty (OpenClaw je dobrým příkladem), které mají velmi špatné bezpečnostní výchozí hodnoty spojené s uživatelskou základnou, jejíž znalost bezpečnosti je daleko překročena jejich nadšením pro “vibe coding”.

Jako důsledek očekávám, že dojde ke změně směrem k útokům, které cílí na vývojový ekosystém sám, spíše než pouze na produkční systémy. Jak se AI stává součástí toho, jak se software vytváří, útočníci se zaměří na manipulaci s nástroji a spojeními, které formují tento proces, efektivní kompromitace softwaru, ještě předtím, než je nasazen.

Děkuji za skvělý rozhovor, čtenáři, kteří chtějí se dozvědět více, by měli navštívit Backslash Security.