Shahar Man, Mitgründer und CEO von Backslash Security – Interview-Serie

Shahar Man, Mitgründer und CEO von Backslash Security, ist ein erfahrener Technologie-Führer mit tiefen Kenntnissen in Cloud-Entwicklung, Cybersicherheit und Unternehmenssoftware. Er leitet derzeit Backslash Security, ein Unternehmen, das sich auf die Sicherung von AI-nativen Software-Entwicklungsumgebungen konzentriert und alles von IDEs und AI-Agents bis hin zu generiertem Code und Prompt-Workflows schützt. Zuvor hatte er Führungspositionen bei Aqua Security inne, wo er als Vice President of Product Management und Vice President of R&D tätig war und half, eine der führenden Plattformen für Container-Sicherheit über den gesamten Entwicklungslebenszyklus hinweg aufzubauen. Früher in seiner Karriere verbrachte Man über ein Jahrzehnt bei SAP, wo er die Entwicklung und Produktinitiativen wie SAP Web IDE leitete und eng mit globalen Unternehmenskunden zusammenarbeitete, während er auch zum Wachstum des Entwickler-Ökosystems beitrug. Seine Karriere begann in technischen und Führungspositionen in Start-up-Umgebungen und Israels Verteidigungstechnologie-Einheiten, was ihm eine starke Grundlage in Ingenieurwesen und großen Systemen verlieh.

Backslash Security ist eine aufstrebende Cybersicherheitsplattform, die speziell für die Ära der AI-getriebenen Software-Entwicklung entwickelt wurde. Das Unternehmen konzentriert sich auf die Sicherung des gesamten AI-nativen Entwicklungstacks, einschließlich AI-Agents, Code-Generierungspipelines und moderner Entwickler-Workflows, einem Bereich, den traditionelle Sicherheitstools oft übersehen. Durch die Bereitstellung von Sichtbarkeit, Governance und Echtzeit-Schutz ohne die Entwickler-Geschwindigkeit zu beeinträchtigen, zielt Backslash darauf ab, die wachsenden Risiken zu adressieren, die durch automatisierte Codierung und “Vibe-Coding”-Umgebungen eingeführt werden. Da die Software-Erstellung zunehmend in Richtung AI-gestützter Systeme verschoben wird, ist die Plattform darauf ausgelegt, sicherzustellen, dass die Sicherheit parallel zur Entwicklung und nicht als Engpass wird, was Backslash an der Schnittstelle zwischen DevSecOps und der nächsten Generation von AI-Entwicklung positioniert.

Sie haben Führungspositionen in Produkt- und R&D-Management bei Unternehmen wie Aqua Security und SAP innegehabt, bevor Sie Backslash gründeten. Was waren die frühen Signale, die Sie davon überzeugten, dass AI-nativer Entwicklung und Vibe-Coding die Software-Erstellung grundlegend verändern würden und dass die Sicherheit neu aufgebaut werden musste, um sie zu unterstützen?

Ich hatte bereits eine große Veränderung miterlebt, als die Software in cloud-nativen Architekturen umzog. Bei SAP und später bei Aqua sahen wir hautnah, dass die Sicherheit normalerweise hinterherhinkt, wenn die Entwicklung so sehr verändert wird. AI hat diese Wahrheit auf ein ganz neues Level gehoben, nicht nur, weil sie dabei hilft, Code schneller zu schreiben, sondern weil sie die gesamte Umgebung um die Software-Erstellung herum umgestaltet hat.

Die Sicherung von Code ist jetzt weniger eine Frage des Codes selbst, sondern mehr eine Frage der Umgebung, in der er erstellt wird. In weniger als einem Jahr hat sich, was früher eine relativ abgegrenzte und niedrigrisikoreiche Entwicklungsumgebung war, in eine riesige, hochgradig vernetzte Angriffsfläche mit wenig Aufsicht oder Governance ausgeweitet. Sobald das passierte, änderten sich die Sicherheitsfragen rund um Code-Schwachstellen grundlegend. Das eigentliche Problem ist nicht, ob ein bestimmter Code Schwachstellen aufweist. Das Problem ist, dass wir durch die Einführung von AI-getriebener Entwicklung Systeme, Agenten, Integrationen und Zugriffspfade eingeführt haben, die weit über den Code selbst hinausgehen. Die Sicherheit kann sich nicht mehr nur auf die Ausgabe von Code konzentrieren. Sie muss die gesamte Umgebung berücksichtigen, die es ermöglicht, dass der Code überhaupt erstellt wird.

Sie beschreiben Vibe-Coding als die Erweiterung der Angriffsfläche über den Code hinaus in Prompts, Agenten, MCP-Server und Tooling-Schichten. Welche sind die am meisten missverstandenen Risiken in diesem neuen Stack, die Entwickler und Sicherheitsteams derzeit übersehen?

Das größte Missverständnis ist, dass viele Teams immer noch glauben, das Risiko liege hauptsächlich im generierten Code. Das ist nur eine Schicht. Bei AI-nativer Entwicklung wird das Risiko früher und an vielen mehr Orten eingeführt. Dies kann in Prompts, im Kontext, der dem Modell geliefert wird, in den Berechtigungen, die Agenten erteilt werden, in den MCP-Servern, mit denen sie verbunden sind, oder in den externen Tools und Plugins, die ihre Reichweite erweitern, liegen. Ein einzelner Benutzers Laptop kann übernommen und als Brückenkopf für einen umfassenderen Angriff verwendet werden. Es ist ein Endpunkt-Schmerzpunkt, der sich als AI-Coding-Problem tarnt. Im Gegensatz zu Code-Schwachstellen gefährdet dies nicht nur die Anwendungen, sondern auch die gesamte Organisation. Wenn Sie nur auf den Code achten, verpassen Sie den größten Teil des Bildes.

Die traditionelle Anwendungssicherheit hat sich stark auf Code-Überprüfung konzentriert. Wie muss das Sicherheitsdenken sich ändern, wenn AI-Agents Code generieren, modifizieren und bereitstellen, und zwar in Echtzeit?

Die Sicherheit muss von periodischer Inspektion zu kontinuierlicher Überwachung wechseln. Der Begriff “Vertrauen” ist völlig gebrochen – Sie können vertrauenswürdige Modelle und vertrauenswürdige MCP-Server haben, aber aufgrund der nicht-deterministischen Natur von AI können diese manipuliert oder einfach falsch verhalten und unerwartete Risiken erzeugen.

Dies bedeutet auch, dass es einen Denkwechsel geben muss, bei dem die Sicherheit neben dem Entwicklungsprozess agiert, während er passiert, und viel tiefer in die Governance, Schutzmechanismen und Erkennung und Reaktion in dieser Umgebung eingebunden ist. Das bedeutet, kritisch über die verwendeten Tools nachzudenken, welchen Kontext sie konsumieren, welche Richtlinien sie regeln sollten und welche Aktionen sie in Echtzeit ausführen. Zusätzlich dürfen wir die Rolle von AI und AI-Modellen bei der Behandlung von Schwachstellen nicht ignorieren. Wenn AI-Modelle vor einem Jahr viele Schwachstellen standardmäßig lieferten, haben sich die Dinge dramatisch verbessert, und andere Modelle werden jetzt verwendet, um Zero-Days zu finden, die zuvor nie gefunden wurden. Wir sind also auf dem Weg zu besseren Ausgaben – aber wer passt auf den Laden auf, während wir das tun? Die Angreifer suchen woanders.

Tools wie Cursor, Claude Code und GitHub Copilot werden in Entwickler-Workflows zur Standardausstattung. Wo sehen Sie die größten Sicherheitslücken, wenn Teams diese Tools ohne angemessene Governance-Ebene einsetzen?

Die größte Lücke ist die Sichtbarkeit. In vielen Organisationen verbreiten sich diese Tools schnell und ohne formale Überprüfung. Sicherheitsteams wissen oft nicht, welche Agenten verwendet werden, wie sie konfiguriert sind, auf welche Daten sie zugreifen können oder mit welchen externen Systemen sie verbunden sind. Das schafft ein Schatten-AI-Problem, das dem Schatten-IT-Problem ähnelt, nur schneller und dynamischer.

Die zweitgrößte Lücke ist der Mangel an durchsetzbaren Richtlinien. Die meisten Organisationen haben Richtlinien, aber Richtlinien allein helfen nicht viel, wenn ein Entwickler schnell innerhalb der IDE arbeitet. Ohne Governance auf der Tool- und Workflow-Ebene riskieren Teams, überberechtigte Tools zu haben, die nicht den Unternehmensstandards entsprechen. Diese Tools sind nicht von Natur aus schlecht, aber ihre Einführung ohne Governance bedeutet, dass Sie die Entwicklungs-Geschwindigkeit skalieren, ohne die Kontrolle zu skalieren.

Ein drittes aufkommendes Problem ist, dass jeder potenziell zu einem Entwickler werden kann – was wir “Citizen-Entwickler” nennen, die Vibe-Coding-Tools verwenden. Wenn die Finanzperson Claude Code verwendet, um Prozesse zu automatisieren und mit internen Systemen zu verbinden, entsteht ein potenzielles Risiko und eine enorme Blindzone, selbst heute.

Backslash konzentriert sich auf die Sicherung des gesamten AI-Entwicklungsumfelds und nicht nur auf einzelne Tools. Warum ist dieser Vollstack-Ansatz notwendig, und was passiert, wenn Organisationen diese Risiken isoliert behandeln?

Weil das Risiko nicht ordentlich innerhalb eines Produkts in Ihrem Stack sitzt. AI-nativer Entwicklung ist inhärent ein Ökosystem-Problem, da es in so vielen verschiedenen Orten mit so vielen verschiedenen Tools operiert. Die IDE, das Modell, die Agenten, die MCP-Server, die externen Tools und Plugins, die Identitäten und die verbundenen Datenquellen beeinflussen alle, was gebaut wird und wie. Organisationen standardisieren nicht auf ein einzelnes Tool, weil ihre relativen Stärken so schnell wechseln. Wenn Sie nur einen Punkt in dieser Kette sichern, verpassen Sie, wie das Risiko durch das System wandert.

Die Behandlung dieser Risiken in Isolation führt zu fragmentierten Verteidigungen und gefährlichen Blindstellen. Sie können den Code-Scanner härten, aber den MCP-Server übersehen, der riskanten Kontext in das Modell einbrachte. Das ist, warum wir glauben, dass der richtige Ansatz Vollstack-Sichtbarkeit und Echtzeit-Schutz über das gesamte AI-Entwicklungsumfeld hinweg ist. Andernfalls werden Organisationen weiterhin Symptome lösen, während die tatsächliche Angriffsfläche unter ihnen weiter wächst.

Prompting wird als neue Schicht der Programmierbarkeit immer wichtiger. Wie sollten Organisationen Prompting sichern und Probleme wie Prompt-Injektion, Datenlecks oder Manipulation verhindern?

Prompting formt zunehmend Logik und Verhalten. In vielen Fällen sind sie effektiv eine neue Steuerungsebene für Software-Erstellung. Das bedeutet, dass sie Richtlinien, Überwachung und Schutzmechanismen benötigen, genau wie Code- oder Infrastruktur-Definitionen. Praktisch beginnt das damit, zu begrenzen, was Prompts zugreifen können und welche nachgelagerten Aktionen sie auslösen können. Es bedeutet auch, Prompt-Regeln zu definieren, die mit Sicherheits- und Qualitätsanforderungen übereinstimmen, sensible Daten vor dem Zugriff durch Kontextfenster zu schützen und auf Manipulationsversuche wie Prompt-Injektion oder indirekte Anweisungshijacking zu achten. Und es beinhaltet auch, sicherzustellen, dass die Regeln selbst nicht als Hintertüren für Prompt-Injektion verwendet werden. Der umfassendere Punkt ist, dass Sie Prompting nicht sichern, indem Sie Entwickler und Agenten anweisen, “vorsichtig zu sein”. Sie sichern es, indem Sie Kontrollen in die Umgebung einbauen, in der Prompting tatsächlich passiert.

MCP-Server und Agenten-Fähigkeiten introduzieren dynamische Verbindungen zwischen Systemen. Aus Sicherheitssicht stellen sie den größten neuen Risikovektor in der AI-getriebenen Entwicklung dar?

MCP-Server und Agenten-Fähigkeiten stellen eine wichtige neue Risikoschicht dar, da sie definieren, wie AI-Systeme mit der realen Welt interagieren und darauf zugreifen. Fähigkeiten definieren, was ein Agent zu tun befugt ist, während MCP den Zugriff auf Kontext und Systeme erweitert. Zusammen formen sie das tatsächliche Verhalten des Agents. Wenn diese Schichten nicht streng kontrolliert werden, verlieren Organisationen die Sichtbarkeit darüber, was ihre AI-Tools können und tun. Der Wechsel von der Code-Generierung zu Aktionen ist es, was dies zu einem so kritischen Bereich für die Sicherheit macht, und sie werden noch unvorhersehbarer, wenn Sie sie verketten.

Eines Ihrer Kernthemen ist “die Abteilung des Ja” – die Sicherheit ermöglichen, ohne die Entwickler zu bremsen. Wie balancieren Sie Echtzeit-Schutz mit Entwickler-Geschwindigkeit in Umgebungen, in denen Geschwindigkeit kritisch ist?

Sicherheit erzeugt Reibung, wenn sie spät oder losgelöst von der tatsächlichen Arbeit der Entwickler passiert. Sie wird viel effektiver, wenn sie direkt in den Workflow eingebettet ist und sich auf das konzentriert, was wirklich zählt. Das war Teil unseres Denkens, seit Backslash begann, und es zählt noch mehr in der AI-getriebenen Entwicklung.

Praktisch bedeutet das, die wenigen Probleme zu identifizieren, die ein echtes Risiko darstellen, und nicht die Entwickler mit allem zu überfluten, was theoretisch verdächtig aussieht. Es bedeutet, Richtlinien in der IDE und im Agenten-Workflow durchzusetzen, und nicht nachträglich. Und es bedeutet, transparente, deterministische Schutzmechanismen zu schaffen, damit Teams schnell agieren können, während sie gleichzeitig wissen, welche Tools verwendet werden, welche Berechtigungen sie haben und wann etwas Ungewöhnliches passiert. Das Ziel ist nicht, die AI-Adoption zu verlangsamen, sondern Organisationen dabei zu helfen, sie mit Vertrauen und ohne die Kontrolle zu verlieren zu adoptieren. In realen Begriffen bedeutet das, dass ein Entwickler weniger Raum hat, Fehler zu machen, aber wenn er einen macht, wird er schnell erkannt und behoben.

Wir sehen, dass nicht-technische Benutzer zunehmend Software mit AI-Tools erstellen. Wie verändert der Aufstieg von nicht-entwickler-Vibe-Codern das Bedrohungslandschaft?

Es erweitert die Bedrohungslandschaft auf zwei Arten. Erstens erhöht es dramatisch die Anzahl der Menschen, die Software-ähnliche Ausgaben erzeugen können, ohne die Sicherheitsimplikationen zu verstehen. Zweitens schafft es ein falsches Gefühl der Sicherheit, weil die Tools die Entwicklung wie eine konversationale und reibungslose Erfahrung erscheinen lassen.

Das bedeutet, dass Organisationen mehr Anwendungen, Automatisierungen und Integrationen sehen werden, die von Menschen erstellt werden, die nicht darauf trainiert sind, Vertrauensgrenzen, Eingabe-Validierung, Abhängigkeits-Hygiene, Zugriffskontrolle oder Datenexposition zu berücksichtigen. Mit anderen Worten, die Angriffsfläche erweitert sich nicht nur, weil AI mehr Code schreibt, sondern auch, weil mehr Menschen in der Lage sind, Workflows und Systeme zu erstellen, die wie Software verhalten, ohne grundlegende ingenieurtechnische Disziplin anzuwenden. Das macht Sichtbarkeit und eingebaute Sicherheitsvorkehrungen noch wichtiger, da Sie nicht länger davon ausgehen können, dass Sicherheitswissen am Punkt der Erstellung vorhanden ist.

Wenn wir in den nächsten 12 bis 24 Monaten blicken, welche Arten von Angriffen oder Schwachstellen erwarten Sie, die speziell aufgrund von AI-nativen Entwicklungsumgebungen auftreten?

Wir erwarten, dass viele der gängigen Code-Schwachstellen durch Verbesserungen in den LLMs selbst oder durch bessere eingebettete Prompt-Regeln in der “Harnische”, die diese Tools umgibt, vermieden werden. Wenn wir derzeit eine Zunahme der Anzahl von Schwachstellen aufgrund der erhöhten Geschwindigkeit sehen, wird sich das korrigieren. Und was nicht korrigiert wird, wird durch AI-ermöglichte SAST- und SCA-Tools (einige davon werden auch von den AI-Plattform-Anbietern bereitgestellt, z. B. Claude Code Security und Projekt Glasswing) verfolgt.

Ich erwarte jedoch schlechtere Ergebnisse, wenn es um Expositionen aufgrund der Verwendung von unüberwachten und nicht überprüften AI-Tools in der Anwendungsentwicklung geht – wie z. B. Open-Source-Agents (OpenClaw ist ein gutes Beispiel), die sehr schlechte Sicherheitsstandards haben und eine Benutzerbasis haben, deren Kenntnisse in Sicherheit von ihrer Begeisterung für Vibe-Coding übertroffen werden.

Als Folge davon denke ich, dass wir einen Wechsel zu Angriffen sehen werden, die sich auf die Entwicklungsumgebung selbst und nicht nur auf Produktionsumgebungen konzentrieren. Wenn AI Teil der Software-Erstellung wird, werden Angreifer sich auf die Manipulation der Tools und Verbindungen konzentrieren, die diesen Prozess formen, und somit die Software effektiv kompromittieren, bevor sie jemals bereitgestellt wird.

Vielen Dank für das großartige Interview. Leser, die mehr erfahren möchten, sollten Backslash Security besuchen.