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í prostředí pro vývoj softwaru s využitím umělé inteligence, chránící vše od integrovaných vývojových prostředí a agentů umělé inteligence až po generovaný kód a pracovní postupy. 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 vedoucích platforem pro zabezpečení kontejnerů napříč celým životním cyklem vývoje. Na počátku své kariéry strávil 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 vytvořená pro éru vývoje softwaru s využitím umělé inteligence. Společnost se zaměřuje na zabezpečení celého nativního vývojového stacku umělé inteligence, včetně agentů umělé inteligence, generování 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 reálné ochrany bez narušení vývojářské rychlosti Backslash Security cílí na řešení rostoucích rizik, 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 posouvá směrem k systémům asistovaným umělou inteligencí, platforma je navržena tak, aby zajistila, že bezpečnost se vyvíjí paralelně, spíše než aby se stala úzkým místem, a umisťuje Backslash Security na průsečík DevSecOps a další generace vývoje umělé inteligence.

Měl jste vedoucí role v produktu a výzkumu ve společnostech jako Aqua Security a SAP, než jste založil Backslash. Jaké早ní signály vás přesvědčily, že vývoj s využitím umělé inteligence a “vibe coding” bude zásadně měnit tvorbu softwaru, a že bezpečnost musí být přestavěna, aby ji podporovala?

Již jsem prožil jednu velkou změnu, 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í takto, bezpečnost obvykle zaostává. Umělá inteligence vzala tuto pravdu 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 tvorby softwaru.

Zabezpečení kódu již není jen o kódu samotném, ale více 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 umožnění vývoje s využitím umělé inteligence jsme zavedli systémy, agenty, integrace a přístupové cesty, které sahají daleko za kód samotný. Bezpečnost již nemůže zaměřit pouze na výstup kódu. Musí zohlednit celé prostředí, které činí ten kód možným.

Popisujete “vibe coding” jako rozšíření útočného povrchu za kód 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目前 přehlížejí?

Největší nedorozumění je, že mnoho týmů stále myslí, že riziko žije hlavně v generovaném kódu. To je pouze jedna vrstva. Ve vývoji s využitím umělé inteligence je riziko zaváděno dříve a na mnoha dalších 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, na serverech MCP, ke kterým se připojují, nebo ve vnějších nástrojích a pluginách, které rozšiřují jejich dosah. Jeden uživatelův laptop může být převzat a použit jako mostní hlava širšího útoku. Je to bod útočného povrchu, který se maskuje jako problém kódování umělou inteligencí. Na rozdíl od zranitelností kódu to 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 se musí myšlení o bezpečnosti vyvíjet, když agenty umělé inteligence generují, modifikují 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 umělé inteligence mohou být stále manipulovány nebo prostě nesprávně se chovat a vytvářet neočekávaná rizika.

To také znamená, že musí dojít k posunu v myšlení, ve kterém 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 toho 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 umělé inteligence a modelů umělé inteligence při zpracování zranitelností. Pokud před rokem modely umělé inteligence poskytly mnoho zranitelností výchozím nastavením, věci se dramaticky zlepšily, a další modely jsou nyní použity k nalezení zero-day zranitelností, které nebyly dříve nalezeny. Takže se vydáváme směrem k lepšímu výstupu – ale kdo dbá 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í revize. Bezpečnostní týmy často neví, které agenty se používají, jak jsou nakonfigurovány, jaký data mohou přistupovat, nebo které externí systémy jsou s nimi spojeny. To vytváří problém “stínové umělé inteligence”, který je podobný stínovému IT, pouze rychlejší a dynamičtější.

Druhá největší mezera je absence vynutitelných zásad. Mnoho organizací může mít pokyny, ale pokyny samy o sobě mnoho nepomohou, 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ů týmy riskují, ž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í škálování vývojářské rychlosti bez škálování kontroly.

Třetí vznikající mezera 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ý bod, dokonce i dnes.

Backslash Security se zaměřuje na zabezpečení celého ekosystému vývoje umělé inteligence, spíše než na jednotlivé nástroje. Proč je tento plnohodnotný přístup nutný, a co se stane, když organizace budou tyto rizika dále zpracovávat izolovaně?

Protože riziko nesedí pěkně uvnitř některého produktu ve vašem stacku. Vývoj s využitím umělé inteligence je inherentně problémem ekosystému, 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á data všech ovlivňují, co se staví a jak. Organizace úmyslně nestandardizují na jediný nástroj, protože jejich relativní síly se mění tak rychle. Pokud zabezpečujete pouze jeden bod v té řetězci, stále chybí, jak riziko přechází napříč systémem.

Zpracovávání těchto rizik izolovaně vede k fragmentovaným obranám a nebezpečným slepým místům. Můžete zpevnit skener kódu, ale přehlédnout server MCP, který rizikový kontext nakrmil do modelu. To je proč věříme, že správný přístup je plnohodnotná viditelnost a reálná ochrana napříč celým ekosystémem vývoje umělé inteligence. Jinak organizace budou 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í promptů a prevenci problémů, jako je injekce promptů, únik dat nebo manipulace?

Prompting stále více formuje logiku a chování. Ve mnoha případech jsou to efektivní nová ovládací rovina pro tvorbu softwaru. To znamená, že potřebují zásady, monitorování a zábrany, stejně jako kód nebo definice infrastruktury by vyžadovaly. Prakticky to začíná omezením toho, co prompty mohou přistupovat, a co downstream akcí mohou spustit. To také znamená definování pravidel promptů, která se shodují s bezpečnostními a kvalitativními očekáváními, prevenci expozice citlivých dat prostřednictvím kontextových oken a sledování pokusů o manipulaci, jako je injekce promptů nebo nepřímé ovládání. A to také zahrnuje zajištění, že samotná pravidla nejsou použita jako zadní vrátka pro injekci promptů. Širší bod je, že nezabezpečujete prompting tím, že instruujete vývojáře a agenty, aby “byli opatrní”. Zabezpečujete ho tím, že vkládáte kontroly do prostředí, kde prompting skutečně probíhá.

Servery MCP a dovednosti agentů zavádějí dynamické spojení mezi systémy. Z hlediska bezpečnosti představují tyto nejvýznamnější nové vektor rizika ve vývoji s využitím umělé inteligence?

Servery MCP a dovednosti agentů představují velkou novou vrstvu rizika, protože definují, jak systémy umělé inteligence 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 ke 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 umělé inteligence 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 reálnou ochranu 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 efektivně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 záleží nyní ve vývoji s využitím umělé inteligence.

V praxi to znamená, že se objevují pouze několik otázek, které reprezentují skutečné riziko, a ne zaplavení vývojářů vším, co vypadá teoreticky podezřele. To znamená vynucování zásad v integrovaném vývojovém prostředí a pracovním postupu agenta, a ne poté. A to také znamená vytváření transparentních, deterministických zábran, aby týmy mohly pohybovat rychle, zatímco stále ví, 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í umělé inteligence, ale pomoci organizacím ji přijmout s důvěrou, aniž by ztratily kontrolu. V reálném smyslu to znamená, že vývojář bude mít méně prostoru pro chyby na prvním místě, ale pokud udělá chybu, bude chycena a zpracována rychle.

Vidíme, že ne-techničtí uživatelé stále více vytvářejí software pomocí nástrojů umělé inteligence. Jak se mění hrozivá krajina s rostoucím počtem “vibe coderů”, kteří nejsou vývojáři?

Šíří hrozivou krajinu ve dvou směrech. 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 cítit konverzačně a s nízkou tření.

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 vstupů, hygienu závislostí, kontrolu přístupu nebo expozici dat. Jinými slovy, útočný povrch se rozšiřuje nejen proto, že umělá inteligence 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 činí viditelnost a vestavěné zábrany ještě důležitějšími, protože již nelze předpokládat znalosti bezpečnosti v místě tvorby.

Pohledem vpřed 12 až 24 měsíců, jaké typy útoků nebo zranitelností očekáváte, že se objeví specificky kvůli pracovním postupům vývoje s využitím umělé inteligence?

Očekáváme, že mnoho běžných zranitelností kódu bude tránháno dopředu díky vylepšením v modelech umělé inteligence samotných, nebo díky lepšímu vloženému promptovým pravidlům v “harnessu”, který obklopuje tyto nástroje. Pokud jsme nyní viděli nárůst objemu zranitelností pouze kvůli zvýšené rychlosti, toto se opraví. A co není opraveno, bude pronásledováno umělou inteligencí zabezpečenou SAST a SCA (některé z nich budou také poskytovány dodavateli platformy umělé inteligence, například Claude Code Security a projekt Glasswing).

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

Jako důsledek si myslím, že uvidíme posun směrem k útokům, které cílí na ekosystém vývoje sám, spíše než pouze na produkční systémy. Jak se umělá inteligence stává součástí toho, jak se software vytváří, útočníci se zaměří na manipulaci s nástroji a spojeními, které formují ten proces, a efektivní kompromitaci softwaru, než je ever 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.