Zaid Al Hamani, CEO und Gründer von Boost Security – Interview-Serie

Zaid Al Hamani, CEO und Gründer von Boost Security, ist ein Cybersicherheits- und DevSecOps-Experte mit über zwei Jahrzehnten Erfahrung im Aufbau und Skalieren globaler Technologieoperationen. Seit der Gründung von Boost Security im Jahr 2020 konzentriert er sich auf die Modernisierung der Art und Weise, wie Organisationen die Software-Entwicklung sichern, und baut auf vorherigen Rollen wie VP of Application Security bei Trend Micro und Co-Founder/CEO von IMMUNIO auf. Zuvor hatte er leitende Positionen bei Canonical inne, wo er Produkt-, Engineering- und globale Support-Initiativen leitete, und bei SITA, wo er groß angelegte, mission-kritische IT-Operationen leitete. Seine Karriere spiegelt eine starke Bilanz bei der Aufbau von Teams, Optimierung von Systemen und Förderung moderner Sicherheitspraktiken wider.

Boost Security ist ein Cybersicherheits-Unternehmen, das sich auf die Sicherung der modernen Software-Lieferkette durch eine developer-erste DevSecOps-Plattform konzentriert. Die Technologie integriert sich direkt in CI/CD-Pipelines, um Schwachstellen automatisch zu erkennen, zu priorisieren und zu beheben, wodurch manuelle Overhead reduziert und die Entwicklungs-Geschwindigkeit beibehalten wird. Durch die Vereinigung von Anwendungs- und Lieferketten-Sicherheit in einem System bietet die Plattform eine vollständige Sichtbarkeit über Code, Abhängigkeiten und Infrastruktur, was Organisationen hilft, ihre Widerstandsfähigkeit in komplexen, cloud-nativen Umgebungen zu stärken.

Sie haben zuvor die Anwendungssicherheit bei Trend Micro geleitet und IMMUNIO mitgegründet. Was hat Sie dazu veranlasst, Boost Security zu gründen, und welche Lücke im Markt konnten Sie frühzeitig identifizieren?

IMMUN.IO war eines der ersten RASP-Unternehmen, das gegründet wurde – und unsere Erfahrung bis zu diesem Punkt war, dass WAFs als Laufzeit-Sicherheitstechnologie unmaintainable und nicht sehr effektiv waren. Wir haben uns eine Möglichkeit vorgestellt, bei der WAFs durch eine genauere, einfacher zu maintainende Lösung ersetzt werden – durch die Instrumentierung der Anwendung.

Das war 2012, DevOps war noch in den Anfängen, und die meisten Teams waren nicht agil. Kubernetes war noch nicht existent.

Trend Micro erwarb IMMUN.IO 2017. Zu diesem Zeitpunkt gab es mehr DevOps-Praktiken: CI/CD-Pipelines, agile Entwicklungspraktiken, schnellere Iterationen und Release-Zyklen, Cloud usw. Software-Entwicklungsteams waren besser darin, Software zu erstellen und schneller zu liefern. Die Sicherheit war jedoch immer noch gebrochen:

• Scans sind zu langsam oder die Ergebnisse kommen zu spät
• Die Ergebnisse sind zu komplex für Entwickler, um darauf zu reagieren
• Es gab eine generell unannehmbare Falsch-Positiv-Rate
• Viele neue Arten von Artefakten wurden nicht gescannt: Infrastruktur als Code, Container, APIs usw.

Software schnell produzieren war einfacher. Sichere Software schnell produzieren war jedoch immer noch schwierig.

Das war das ursprüngliche Problem, das wir zu lösen versuchten. DevSecOps in der realen Welt machen; kann man ein Software-Entwicklungsteam dazu bringen, Sicherheit leicht in den SDLC aufzunehmen, mit einer Geschwindigkeit, die den neuen Velocity-Standards entspricht? Kann man die Abdeckung breit machen – wo eine Plattform alles ist, was man benötigt? Kann man es so machen, dass Entwickler nicht nur die Technologie annehmen, sondern auch ihre Vorteile erkennen? Kann man es so skalieren, dass man keine Armeen von Sicherheits-Experten benötigt, um mit der Menge an Code zu halten…

Wir halfen Unternehmen, Sicherheit in den SDLC während der DevOps-Ära einzuspritzen. Das war von 1 auf 10. Wir sind jetzt in der Ära des agentischen Codings – wo Agenten einen enormen Teil des Codes schreiben – aber es ist im Grunde das gleiche Problem – die Geschwindigkeit und der Umfang des Codes sind nur von 10 auf 100 gestiegen; und wir zielen darauf ab, die gleiche Traektorie fortzusetzen.

Sie haben argumentiert, dass der Software-Entwicklungs-Lebenszyklus (SDLC) grundlegend nach oben verschoben wurde. Was war der Moment, in dem Sie erkannten, dass traditionelle DevSecOps-Ansätze nicht mehr ausreichten?

Es war, als ich sah, wie Angreifer tatsächlich hereinkamen. Wir sahen immer wieder das gleiche Muster: Eine offene GitHub-Actions-Workflow, die niemand seit der Fork des Repositorys überprüft hatte, ein Token mit Produktions-Cloud-Zugriff, der in einer Runner-Konfiguration eingebettet war, ein legitimer CI-Job, der von einem Angreifer gehijackt wurde, um Payloads zu deployen. Diese wurden als “Living off the Pipeline”-Angriffe bekannt, weil der Angreifer die eigene Automation des Opfers gegen es verwendet, mit den Credentials, die das Sicherheitsteam bereits genehmigt hatte.

Der DevSecOps-Stack, den wir über ein Jahrzehnt aufgebaut hatten, hatte keine Antwort darauf. SAST-Scans scannen die Anwendungs-Quelle. SCA-Scans scannen die Anwendungs-Abhängigkeiten. Beide nehmen an, dass die Pipeline, die sie ausführt, vertrauenswürdig ist. Währenddessen ist die Pipeline selbst eine YAML-Datei mit Shell-Befehlen, Netzwerk-Zugriff und sensitiven Credentials, und fast niemand überprüft sie.

Wenn das der Pfad mit der geringsten Widerstandsfähigkeit wird, können Sie perfekt sauberen Code ausliefern und den Angreifern trotzdem Ihre Cloud übergeben.

Wie sollten Unternehmen den SDLC in einer Welt umdenken, in der AI-Agenten Code kontinuierlich generieren, anstatt dass Entwickler ihn Schritt für Schritt schreiben?

Wir müssen alle aufhören, über den SDLC als eine Sequenz von Checkpoints nachzudenken. AI-Agenten haben die Zeit zwischen “jemand hat dies geschrieben” und “dies ist in Produktion” von Wochen auf Minuten reduziert. Das alte Modell nahm an, dass es einen menschlichen Rhythmus zwischen Code-Review, SAST, SCA und Deploy gibt, aber wir sind darüber hinaus.

Sicherheit muss dort leben, wo der Agent operiert: auf dem Entwickler-Rechner, innerhalb des Prompt-Kontexts, in den Verbindungen des Agents zu MCP-Servern und externen Modellen. Wenn der Code die Pipeline erreicht, haben Sie bereits die Chance verpasst, ihn zu formen. Der Agent hat bereits die Abhängigkeit gezogen. Das Modell hat bereits das Credential gesehen. Verschieben Sie die Kontrollen nach oben, dorthin, wo die Arbeit tatsächlich stattfindet.

Viele Organisationen behandeln AI-Coding-Tools immer noch als einfache Produktivitätsschichten. Warum glauben Sie, dass sie eine völlig neue Angriffsfläche darstellen und nicht nur eine Erweiterung bestehender Workflows?

Ein AI-Coding-Tool als Produktivitätsschicht zu behandeln, ist wie einen Junior-Entwickler mit Root-Zugriff als Produktivitätsschicht zu behandeln. Die Bezeichnung ist technisch korrekt, aber sie gibt Ihnen keinen nützlichen Rahmen für das Nachdenken über das, was schiefgehen könnte.

Ein Coding-Agent liest Ihre Dateisysteme, scrappt Umgebungsvariablen für Kontext, fetcht Abhängigkeiten von öffentlichen Registries, öffnet ausgehende Verbindungen zu Remote-Model-Providern und MCP-Servern und führt Shell-Befehle aus. Jede dieser Aktionen erforderte früher einen Menschen im Loop. Jetzt geschehen sie in Millisekunden, mit den gleichen Privilegien wie der Entwickler, der den Agenten startete.

Diese Kombination verschmilzt Vertrauensgrenzen, die früher getrennt waren: die Autorität des Entwicklers, was ein externes Tool fetchen kann und was untrusted Code ausführen kann. Das schafft neue Gelegenheiten für Angreifer und Blindspots, die Verteidiger nicht einmal sehen können, geschweige denn verteidigen können.

Boost Security betrachtet den Entwickler-Laptop als die neue Steuerungsebene. Welche Risiken bestehen auf dem Endgerät, die Sicherheitsteams derzeit übersehen?

Das größte Risiko ist die Inventarisierung. Die meisten Sicherheitsteams können nicht sagen, welche AI-Agenten auf welchen Laptops laufen, welche MCP-Server diese Agenten ansprechen oder welche IDE-Erweiterungen gerade Repository-Inhalte scannen. EDR hat keine Sichtbarkeit in die Agent-Schicht; SIEM kann nicht sehen, was diese Agenten lokal tun.

Unterhalb davon liegt das Credential-Chaos. Wir haben ein Open-Source-Tool namens Bagel teilweise entwickelt, um dies konkreter zu machen. Ein typischer Entwickler-Laptop enthält GitHub-Tokens mit Schreibzugriff auf Produktions-Repositorys, Cloud-Credentials, die Infrastruktur spinnen können, npm- oder PyPI-Tokens, die zu Millionen von Benutzern publishen können, und AI-Service-Schlüssel, die Angreifer weiterverkaufen. Keines davon ist so gehärtet wie ein CI-Runner. Der gleiche Rechner, der diese Credentials enthält, surfed auch im Internet und installierte zufällige VS-Code-Erweiterungen.

Kombinieren Sie beides, und Sie haben die tatsächliche Angriffsfläche. Eine nicht vertrauenswürdige Erweiterung, die mit Entwickler-Privilegien in einer Umgebung voller Cloud-Schlüssel läuft, ist das höchste Ziel in der modernen Unternehmensumgebung. Die meisten Teams haben noch nicht einmal begonnen, sich damit auseinanderzusetzen.

Sie haben den “Kontext-Fehler” hervorgehoben, bei dem AI-Agenten auf lokale Dateien, Umgebungsvariablen und Konfigurationen zugreifen können. Wie weit verbreitet ist das Risiko von sensitiven Daten, die durch Prompts ausgelöst werden, und warum ist es so schwierig, sie zu erkennen?

Ausreichend weit verbreitet, dass wir es als den Standardzustand jeder unverwalteten Entwicklerumgebung behandeln. Jeder Coding-Agent, den wir untersucht haben, zieht lokalen Kontext aggressiv. Sie lesen Dotfiles, Umgebungsvariablen, kürzlich geöffnete Dateien, manchmal ganze Verzeichnisbäume, und schicken diesen Kontext zu einem Remote-Modell. Die Tools sind so konzipiert, dass sie auf diese Weise funktionieren; aggressives Kontext-Grabbing ist das, was sie nützlich macht.

Das Erkennungsproblem beginnt, weil der Datenverkehr von einem Leak identisch mit normalem Produkt-Usage aussieht. Es ist TLS zu api.openai.com oder api.anthropic.com. Es kommt von einer genehmigten Geschäftsanwendung. Standard-DLP sieht einen Entwickler, der das AI-Tool verwendet, das das Unternehmen gerade lizenziert hat. Es sieht nicht, dass eine der Zeichenfolgen in diesem Prompt ein AWS-Geheimnis-Schlüssel ist, den der Agent aus einer halb vergessenen .env-Datei in einem Nebenverzeichnis gezogen hat.

Sie können es nur erkennen, indem Sie Prompts vor ihrem Verlassen des Laptops untersuchen, was genau der Ort ist, an dem fast kein Sicherheits-Stack derzeit positioniert ist.

Sie erwähnten maschinelle Angriffe auf die Lieferkette. Können Sie ein realistisches Szenario durchgehen, in dem ein AI-Agent eine Schwachstelle einführt, bevor traditionelle Sicherheits-Tools sie identifizieren können?

Hier ist eines, das wir wiederholt gesehen haben. Ein Entwickler bittet einen Agenten, ein Feature hinzuzufügen, das eine HTTP-Retry-Bibliothek benötigt. Der Agent schlägt einen Paket-Namen vor. Das Paket klingt plausibel, existiert aber nicht auf npm. Innerhalb einer Stunde registriert ein Angreifer es, füllt es mit funktionierender Retry-Logik und einem kleinen Post-Install-Skript, das ~/.aws/credentials liest und den Inhalt an einen Webhook postet. Der Agent führt npm install aus, ohne zu überprüfen, weil Agenten nicht überprüfen; weil Agenten nicht überprüfen, ob die Reputation stimmt. Das Credential ist verschwunden, bevor der Entwickler den Code sogar ausführt.

Der Angriff selbst ist nicht technisch anspruchsvoll, aber traditionelle Lieferketten-Sicherheit basiert auf bekannten Schwachstellen in bekannten Paketen: CVEs, SBOMs, Lizenz-Scans. Dieses Framework hat nichts zu sagen über ein Paket, das nicht existierte, als der Scan zuletzt ausgeführt wurde, das speziell zur Übereinstimmung mit einer AI-Halluzination erstellt wurde und vor jedem Threat-Feed-Update eingenommen wird.

Das Fenster von der Veröffentlichung bis zur Kompromittierung wird jetzt in Minuten gemessen. Alles, was nachträglich überprüft wird, überprüft zu spät.

Sind halluzinierte Abhängigkeiten bereits eines der größten Risiken in der AI-getriebenen Entwicklung, und welche praktischen Schritte können Organisationen unternehmen, um sich davor zu schützen?

Sie sind bereits eines der größten. Angreifer überwachen aktiv populäre AI-Tools auf Halluzinationen und registrieren die vorgeschlagenen Paket-Namen innerhalb von Minuten. Forscher vor ein paar Jahren, als es erst begann, nannten es Slopsquatting, und der Name blieb haften. Sobald ein Abhängigkeits-Name häufig genug halluziniert wird, ist das Sitzen darauf ein passiver Lieferketten-Angriff mit nahezu null Aufwand.

Die praktischen Verteidigungen sehen anders aus als das, was die meisten Teams derzeit haben. Fangen Sie bei der Aufnahme an. Blockieren Sie typosquattierte und neu registrierte Pakete im Moment, in dem npm install oder pip install ausgeführt wird, auf dem Entwickler-Rechner, bevor etwas auf die Festplatte gelangt. Postmortem-Erkennung in CI hilft nicht, wenn ein Post-Install-Skript bereits ein Credential exfiltrated hat. Dann geben Sie dem Agenten Schutzvorkehrungen, um darin zu operieren. Injizieren Sie Ihre Liste der genehmigten Abhängigkeiten direkt in den Kontext des Agents, sodass das Modell sieht, was erlaubt ist, bevor es eine Vorschlagung generiert. Entwicklern zu sagen, sie sollten “sichere Prompts” schreiben, ist keine Strategie. Wenn Sie strategisch werden, bedeutet Sicherheit, die Grenze zu setzen, den Agenten zu vererben. Und beginnen Sie mit der Nachverfolgung einer AI-Bill-of-Materials. Die meisten Teams können nicht sagen, welche Agenten, Modelle und Pakete welche Repositorys berühren. Sie können nicht verteidigen, was Sie nicht inventarisieren können.

Sie sagten, Sicherheit kann nicht mehr bei CI/CD beginnen. Wie sieht eine moderne Sicherheits-Pipeline aus, wenn der Schutz früher im Entwicklungsprozess beginnen muss?

Wenn Sicherheit bei CI/CD beginnt, haben Sie die gesamte vorherige Phase der Entwicklungs- Pipeline einer Umgebung überlassen, die Sie nicht kontrollieren. Der Agent hat bereits Kontext eingenommen, Ihr Credential kann bereits in jemand anderem’s Logs sein. Sie scannen eine Leiche.

Eine moderne Pipeline beginnt auf dem Laptop. Das bedeutet, die Agenten und Erweiterungen, die darauf laufen, zu inventarisieren, zu validieren, welche MCP-Server und Modelle sie ansprechen dürfen, zu sanitisieren, was das Gerät verlässt, und bösartige Pakete zu blockieren, bevor sie installiert werden. Von dort aus folgt die Richtlinie der Arbeit in die IDE. Wir injizieren Sicherheits-Standards direkt in das Kontext-Fenster des Agents, sodass generierter Code von Anfang an innerhalb der Schutzvorkehrungen bleibt. Die Pipeline selbst verschwindet nicht. Ihre Rolle wird zur Verifizierung: Bestätigung, dass die Kontrollen, die vorher angewendet wurden, greifen.

Die Pipeline selbst verschwindet nicht. Ihre Rolle wird zur Verifizierung: Bestätigung, dass die vorher angewendeten Kontrollen greifen.

Wenn Organisationen AI-Coding-Agenten weiterhin adoptieren, welche kritischen Änderungen müssen sie heute vornehmen, um sicherzustellen, dass ihre Entwicklerumgebungen in den nächsten Jahren sicher bleiben?

Der größte Fehler ist, nur das zu sichern, was committet wird. Das interessante Risiko liegt jetzt in den acht Stunden vor einem Commit. Ungesehene Dramen können auf dem Laptop, im Prompt oder in der Paket-Installation entfalten. Wenn Ihre Tools bei der PR beginnen, schützen Sie die falsche Hälfte der Arbeitsabläufe.

Eng damit verbunden: Hören Sie auf, Coding-Agenten als Produktivitäts-Software zu behandeln. Sie sind nicht-menschliche Benutzer mit Shell-Zugriff, Repository-Schreibzugriff und ausgehenden Netzwerk-Verbindungen. Regeln Sie sie wie jeden anderen privilegierten Benutzer, mit einer Inventarisierung, genehmigten Fähigkeiten und Audit-Logs.

Der letzte Schritt ist kulturell schwieriger. Die meisten aktuellen “AI-Sicherheits”-Tools liefern Ergebnisse und leiten sie an Menschen weiter. Menschen können nicht mit der Geschwindigkeit triagieren, mit der Agenten generieren. Alles, was Sie adoptieren, muss Probleme automatisch innerhalb der Arbeitsabläufe lösen, mit nachvollziehbarem Denken, oder es wird zu einem weiteren Dashboard, das niemand liest.

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