Shahar Man, Mitgründer und CEO von Backslash Security – Interviewreihe

Shahar Man, Mitgründer und CEO von Backslash Security, ist ein erfahrener Technologiefü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, um alles von IDEs und AI-Agents bis hin zu generiertem Code und Prompt-Workflows zu schützen. Zuvor hatte er leitende Positionen 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 solide Grundlage in Ingenieurwesen und großen Systemen gab.

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 Entwicklungspiles, 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 Entwicklergeschwindigkeit 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ützte Systeme verschoben wird, ist die Plattform darauf ausgelegt, sicherzustellen, dass die Sicherheit parallel zur Entwicklung und nicht als Engpass entsteht, 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-Bereichen bei Unternehmen wie Aqua Security und SAP vor der Gründung von Backslash innegehabt. Was waren die frühen Signale, die Sie davon überzeugt haben, 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-native Architekturen wechselte. Bei SAP und später bei Aqua sahen wir hautnah, dass die Sicherheit normalerweise hinterherhinkt, wenn die Entwicklung so stark verändert wird. AI hat diese Wahrheit auf ein ganz neues Level gehoben, nicht nur, weil sie dabei helfen kann, Code schneller zu schreiben, sondern auch, weil sie die gesamte Umgebung um die Software-Erstellung herum neu gestaltet hat.

Die Sicherung von Code ist jetzt weniger eine Frage des Codes selbst und mehr eine Frage der Umgebung, in der er erstellt wird. In weniger als einem Jahr hat sich, was früher eine relativ abgeschlossene und niedrig risikobehaftete Entwicklungssetup war, in eine riesige, hoch vernetzte Angriffsfläche mit wenig Überwachung oder Governance ausgeweitet. Sobald das passierte, änderten sich die Sicherheitsfragen um Code-Schwachstellen vollkommen. 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 Zugriffswege eingeführt haben, die weit über den Code hinausgehen. Die Sicherheit kann sich nicht mehr nur auf die Ausgabe des Codes 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 auf 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 bereitgestellt wird, in den Berechtigungen, die Agenten erhalten, 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 genutzt werden. Es handelt sich um einen Endgeräte-Schmerzpunkt, der sich als AI-Coding-Problematik tarnt. Im Gegensatz zu Code-Schwachstellen gefährdet dies nicht nur die Anwendungen, sondern das gesamte Unternehmen. Wenn Sie nur auf den Code achten, verpassen Sie den größten Teil des Bildes.

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

Die Sicherheit muss von periodischer Inspektion zu kontinuierlicher Überwachung wechseln. Das Konzept von 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 dennoch 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 läuft und tiefer in die Governance, Schutzmechanismen und Erkennung und Reaktion innerhalb dieser Umgebung eingebunden ist. Das bedeutet, kritisch über die verwendeten Tools nachzudenken, welchen Kontext sie konsumieren, welche Richtlinien sie regieren 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 steuern also auf bessere Ausgaben zu – aber wer achtet auf den Laden, während wir das tun? Die Angreifer suchen woanders.

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

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-Prinzip ähnelt, nur schneller und dynamischer.

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

Ein drittes aufkommendes Problem ist, dass jeder potenziell zu einem Entwickler werden kann – was wir als “Citizen-Entwickler” bezeichnen, 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 noch.

Backslash konzentriert sich auf die Sicherung des gesamten AI-Entwicklungsumfelds und nicht nur auf einzelne Tools. Warum ist dieser Full-Stack-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 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 noch, wie das Risiko über das System wandert.

Das isolierte Behandeln dieser Risiken 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 Full-Stack-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 vorgehen, um Prompts zu sichern und Probleme wie Prompt-Injektion, Datenlecks oder Manipulation zu verhindern?

Prompts formen 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, ähnlich wie Code oder Infrastruktur-Definitionen. Praktisch beginnt das damit, zu begrenzen, was Prompts zugänglich machen 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 breitere 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 Agent-Skills führen dynamische Verbindungen zwischen Systemen ein. Aus Sicherheitssicht stellen sie das größte neue Risiko in der AI-getriebenen Entwicklung dar?

MCP-Server und Agent-Skills stellen eine große neue Risikoebene dar, da sie definieren, wie AI-Systeme mit der realen Welt interagieren und verbinden. Skills definieren, was ein Agent befugt ist zu tun, während MCP seinen 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, wozu ihre AI-Tools in der Lage sind und was sie tatsächlich tun. Der Wechsel von der Code-Generierung zu Aktionen ist es, was dies zu einem so kritischen Bereich für die Sicherheit macht, und es wird noch unvorhersehbarer, wenn Sie sie verkettet haben.

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

Sicherheit schafft Reibung, wenn sie spät eintritt oder von der Art und Weise, wie Entwickler tatsächlich arbeiten, getrennt ist. 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 Entwickler mit allem zu überfluten, was theoretisch verdächtig aussieht. Es bedeutet, Richtlinien in der IDE und Agent-Workflow durchzusetzen, und nicht danach. Und es bedeutet, transparente, deterministische Schutzmechanismen zu schaffen, damit Teams schnell agieren können, während sie immer noch 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 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 gehandhabt.

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 Personen, die Software-ähnliche Ausgaben ohne Verständnis der Sicherheitsimplikationen produzieren können. Zweitens schafft es ein falsches Gefühl von Sicherheit, weil die Tools die Entwicklung wie eine konversationale, niedrige Reibung erscheinen lassen.

Das bedeutet, dass Organisationen mehr Anwendungen, Automatisierungen und Integrationen sehen werden, die von Personen erstellt werden, die nicht darauf trainiert sind, Vertrauensgrenzen, Eingabevalidierung, Abhängigkeitshygiene, 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 nun Workflows und Systeme generieren können, die sich 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 Sie in die nächsten 12 bis 24 Monate blicken, welche Arten von Angriffen oder Schwachstellen erwarten Sie speziell aufgrund von AI-nativen Entwicklungsumgebungen?

Wir erwarten, dass viele der gängigen Code-Schwachstellen von vornherein durch Verbesserungen in den LLMs selbst oder durch bessere eingebettete Prompt-Regeln in der “Harness”, 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 von AI-aktivierte SAST und SCA (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 unüberwachter und unkontrollierter 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 denke ich, dass wir einen Wechsel hin zu Angriffen sehen werden, die sich auf die Entwicklungsumgebung selbst und nicht nur auf Produktionsumgebungen konzentrieren. Da AI Teil davon wird, wie Software erstellt wird, werden Angreifer sich auf die Manipulation der Tools und Verbindungen konzentrieren, die diesen Prozess prägen, 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.