Wenn es sich lohnt, etwas zu bauen, ist es auch wert, es zu sichern.

Vibe Coding hat viel Aufsehen erregt. Die Automatisierung und Programmierung mit KI ist zwar nicht neu, aber Vibe Coding verspricht eine Demokratisierung der Softwareentwicklung: Beschreiben Sie einfach in natürlicher Sprache, was Sie wollen, und lassen Sie das LLM den Rest erledigen. 

Von KI-verbesserten IDEs wie Cursor, Copilot in VS Code und Windsurf bis hin zu Plattformen, die die Codierung komplett abstrahieren (wie Bolt, Lovable und v0) - die Zahl der Tools in diesem Bereich ist bereits explosionsartig gestiegen, und wir erwarten ein weiteres exponentielles Wachstum.

Besuchen Sie AINativeDev für einen Überblick über die KI-Entwicklungslandschaft  

Wir wollen nur gute Vibes

Es ist befreiend, schnell zu entwickeln und "zu vergessen, dass es den Code überhaupt gibt" - vor allem, wenn man kein professioneller Entwickler ist -, aber das größte Risiko beim Vibe Coding ist, dass man nicht weiß, was man nicht weiß, und oft versteht man nicht, was der von der KI generierte Code tut. 

Sicher, Sie können überprüfen, ob der Code das tut, was Sie erwarten, aber ohne zu wissen, was unter der Haube vor sich geht, werden Sie nicht immer wissen, welche Risiken der Code birgt, bis es zu spät ist (und das Debuggen ist bekanntermaßen schwieriger als das Schreiben des Codes ). Wenn Sie sich die Mühe machen, etwas zu entwickeln - selbst wenn Sie diesen Prozess durch Vibe Coding beschleunigen -, ist das Letzte, was Sie wollen, dass Sie durch Sicherheitsvorfälle zurückgeworfen werden.

Selbst erfahrene Entwickler haben blinde Flecken, wenn es um Sicherheit geht, und während Vibe Coding die Softwareentwicklung zugänglicher macht, wird es auch schneller und einfacher, Ihre Anwendung Schwachstellen und Angriffen auszusetzen, wie SQL-Injections, Path Traversal Attacks und secrets , die für böse Akteure anfällig sind. Zwar bemühen sich einige Vibe-Coding-Plattformen, Schwachstellen vorzubeugen(v0 ist standardmäßig skeptisch gegenüber LLM-Code), aber es besteht immer noch ein sehr reales Risiko von Sicherheitslücken beim Vibe-Coding, waszu der bissigen Bemerkung führt, dass Vibe-Coding = Vulnerability-as-a-Service. 

Nehmen Sie nur das folgende Beispiel:

‍

Leider gibt es nicht nur einen offensichtlichen Grund, warum unser unglücklicher Freund oben seine App schließen und neu beginnen musste. Es ist klar, dass seine API-Schlüssel durchgesickert sind, was es Hackern ermöglicht hat, sich als er auszugeben, was bedeutet, dass sie auf Daten, Funktionen oder Ressourcen zugreifen oder sie verändern konnten.

Hier könnte eine beliebige Anzahl von unsicheren API-Schlüsselverwaltungsfehlern am Werk gewesen sein: Hardcoding von secrets in seiner Anwendung, eine unwissentlich auf seinen Server hochgeladene Umgebungsvariablendatei oder eine Schwachstelle bei der Pfadumgehung (hey, das ist sogar Atlassian passiert). Ohne zusätzliche Sicherheitsprüfungen und -prozesse wäre es für einen Hacker oder Bot ein Leichtes gewesen, Zugang zu seinen API-Schlüsseln zu erhalten. 

Allgemeine Sicherheitslücken und Risiken

Egal, ob Sie nur mit ChatGPT arbeiten oder ob Sie mit einem speziellen Tool wie Lovable programmieren, Sie sind anfällig für diese häufigen Arten von Cyberangriffen. 

Cross-Site Scripting (XSS)

Ein Cross-Site-Scripting (XSS)-Angriff nutzt Schwachstellen in Webanwendungen aus, bei denen vom Benutzer bereitgestellte Eingaben nicht ordnungsgemäß validiert oder bereinigt werden, bevor sie angezeigt oder verarbeitet werden. Hacker können dann über die Benutzereingabe bösartigen Code "einschleusen". Wenn das eingeschleuste Skript ausgeführt wird, kann es auf sensible Informationen zugreifen oder unbefugte Aktionen im Namen des Opfers (in diesem Fall einer Ihrer Benutzer) durchführen. XSS-Angriffe können ein harmloser Spaß sein (wie in diesem sich selbst retweetenden Tweet), aber sie setzen Ihre Nutzer dem Risiko aus, dass ihre Daten offengelegt oder sogar ihre Konten von Hackern übernommen werden. 

SQL-Injection-Angriffe

Wie bei XSS wird auch bei einem SQL-Injection-Angriff (SQLi) bösartiger Code in eine Anwendung eingeschleust, häufig über ein anfälliges Eingabefeld des Benutzers. Da SQL die Sprache ist, die viele Anwendungen zur Abfrage der zugrunde liegenden Datenbank verwenden, ermöglicht diese Art von Angriff Hackern, Ihre Datenbank einzusehen oder zu ändern - und so auf vertrauliche Daten zuzugreifen oder sogar Datensätze zu löschen. Die Datenpanne bei Equifax im Jahr 2017 war das Ergebnis eines SQL-Injection-Angriffs. Equifax selbst war nicht das Ziel - das Unternehmen hatte es versäumt, einen Sicherheitspatch für eine seiner Abhängigkeiten anzuwenden.  

Pfadüberquerungsangriffe

Angreifer können Dateipfadeingaben (in der Regel URLs oder Dateiparameter) manipulieren, um Ihre Anwendung dazu zu bringen, nicht öffentliche Dateien oder Verzeichnisse zurückzugeben, so dass sie die Zugriffskontrollen umgehen und Dateien mit vertraulichen Daten lesen und schreiben können. Diese Art von Angriff wird auch durch unsichere Benutzereingaben ermöglicht. Im Jahr 2010 entdeckten Forscher eine Path-Traversal-Schwachstelle in der Confluence-Anwendung von Atlassian, die es Angreifern ermöglicht hätte, jede beliebige Datei auf dem Server, auf dem Confluence ausgeführt wird, abzurufen, basierend auf den Berechtigungen des Benutzers, unter dem Confluence ausgeführt wird.

Leckage von Secrets

SecretsKennwörter, Verschlüsselungsschlüssel, API-Token und digitale Zertifikate - geben böswilligen Akteuren die Schlüssel zu Ihrem Reich. Diese sensiblen Daten können es Hackern ermöglichen, sich als Sie auszugeben, auf Ihre Daten zuzugreifen und Ihren Code zu ändern. Laut dem GitGuardian-Bericht "State of Secrets Sprawl" wurden im Jahr 2024 sage und schreibe 23 Millionen secrets in öffentlichen Quellcode-Repositories gefunden (25 % mehr als im Vorjahr). Secrets können durch versehentliches Hardcoding in Ihrer Anwendung oder durch eine Schwachstelle wie die tj-actions/changed-files-Kompromittierung vom März 2025 aufgedeckt werden: Angreifer änderten den Code der GitHub-Action tj-actions/changed-files, wodurch die kompromittierte Action secrets in den Build-Protokollen von GitHub Actions ausgab.

Angriffe auf die Lieferkette

Bis zu 85-95 % des Codes Ihrer Anwendung könnten auf Open-Source-Bibliotheken und -Projekten basieren. Angriffe auf die Lieferkette nutzen nicht eine bestimmte Art von Schwachstelle aus oder zielen auf eine bestimmte Anwendung ab, sondern haben es auf die zugrunde liegenden Open-Source-Projekte abgesehen, von denen viele Unternehmen abhängig sind. Die oben beschriebene Datenpanne bei Equifax war das Ergebnis eines Supply-Chain-Angriffs, der bereits entschärft worden war, was zeigt, wie wichtig es ist, seine Abhängigkeiten zu überwachen und Sicherheits-Patches umgehend anzuwenden. 

Vibe Coding ist ein großartiges Werkzeug für die Erforschung und den Aufbau eines Proof-of-Concept, aber sobald Sie daran interessiert sind, etwas in ein lebensfähiges Produkt und ein Unternehmen umzuwandeln, müssen Sie Sicherheitsprüfungen und bewährte Verfahren einrichten, um das zu schützen, was Sie aufgebaut haben. 

Kann ich die KI nicht einfach bitten, einen sichereren Code zu schreiben?

Das ist eine berechtigte Frage. Wir wissen, dass KI nicht standardmäßig sicheren Code schreibt, aber eine sehr schnelle und schmutzige Verbesserung besteht darin, sie explizit zu bitten, ihn sicher zu machen (d. h. wörtlich die Worte "und machen Sie ihn sicher" zu Ihrer Eingabeaufforderung hinzuzufügen). Überraschenderweise führt dies tatsächlich zu Code mit weniger Sicherheitslücken.

Sie können die KI auch veranlassen, ihren eigenen Code auf Schwachstellen und Sicherheitslücken zu überprüfen, indem Sie sie z. B. bitten, hart kodierte secrets zu finden, zu überprüfen, ob Daten nicht öffentlich zugänglich sind, das Projekt auf anfällige Abhängigkeiten zu scannen oder Benutzereingabefelder (z. B. Formulare) mit unzureichender Eingabevalidierung zu identifizieren. All diese Maßnahmen werden die Sicherheit Ihrer Anwendung verbessern.

Aber der Sinn der Überprüfung von KI-generiertem Code auf potenzielle Halluzinationen, Schwachstellen oder andere Sicherheitslücken besteht darin, dass es zu riskant ist, ihn ohne menschliche Aufsicht selbst zu korrigieren. KI kann durchaus in herkömmliche Scanning-Methoden integriert werden, um sie zu verbessern, aber nicht zu ersetzen (Aikido beispielsweise nutzt KI, um Sicherheitswarnungen automatisch zu sortieren und Korrekturen vorzuschlagen).

Die besten Software-Ingenieure sind in der Regel auch diejenigen, die am ehesten zugeben, wenn sie etwas nicht wissen. Das Problem, wenn man sich zu sehr auf KI verlässt, um sich selbst zu überwachen, ist, dass es nicht ungewöhnlich ist, dass sie eine sichere Behauptung über etwas aufstellt, das falsch ist, anstatt die Unsicherheit zuzugeben. Deshalb raten wir davon ab, sich bei der Absicherung Ihrer Anwendung allein auf KI zu verlassen.

Die gute Nachricht ist, dass sich viele Unternehmen und Open-Source-Projekte mit diesen Sicherheitsproblemen befasst haben, lange bevor Vibe Coding zu einem Begriff wurde. Eine der wichtigsten Lektionen, die neue Entwickler lernen, ist es, auf den Schultern von Riesen zu stehen. Es wird viele Komponenten in Ihrer Anwendung geben, die sensibel und unternehmenskritisch sind (Dinge wie Authentifizierung, Kryptographie oder auch nur die Art und Weise, wie Sie Benutzer Dateien auf Ihre Benutzeroberfläche hochladen lassen), und Cursor oder GPT zu bitten, diese für Sie zu bauen, ist ein Fehler: 

1. Sie tragen nicht zur Differenzierung Ihres Produkts bei.
2. Höchstwahrscheinlich ein Sicherheitsrisiko

In diesen Fällen ist es weitaus besser, sich an Anbieter zu wenden, die sich ausschließlich auf Lösungen für diese Probleme konzentrieren. LLMs sind nicht speziell auf Best Practices oder die effizienteste oder sicherste Lösung eines Problems geschult. In vielen Fällen besteht die eleganteste Lösung darin, einen bereits vorhandenen Dienst zu nutzen, anstatt einen eigenen zu entwickeln (selbst wenn Sie die schwere Arbeit an KI auslagern).

Man kann leicht überfordert sein und nicht wissen, wo man anfangen soll. Wir haben diese Checkliste zusammengestellt, um Ihnen den Einstieg in ein sicheres Gebäude zu erleichtern. 

‍

Stufe 0

Dies sind die grundlegenden Sicherheitsmaßnahmen, die Sie so schnell wie möglich einführen sollten. Sobald diese Praktiken eingerichtet und Teil Ihres Prozesses sind, können Sie ungehindert bauen, ohne die Stimmung zu zerstören.

Implementierung bewährter Git-Verfahren

Einer der häufigsten Fehler bei der KI-Programmierung besteht darin, dass es beim Hinzufügen neuer Funktionen oder beim Versuch, ein Problem zu beheben, intuitiver ist, den bisherigen Code einfach durch den neuen, von der KI generierten Code zu ersetzen. Das funktioniert so lange, bis es nicht mehr funktioniert. Irgendwann stößt man an eine Wand, an der nichts mehr hilft, was die KI produziert, und man ist noch schlechter dran als vorher.

Dafür ist die Versionskontrolle da

Versionskontrollen wie Git wurden entwickelt, um Entwicklern die Möglichkeit zu geben, gemeinsam an Projekten zu arbeiten, ohne die Arbeit der anderen zu überschreiben. Aber auch wenn Sie alleine arbeiten, können Sie damit Ihren Fortschritt sichern, Fehler eingrenzen und Änderungen rückgängig machen, wenn etwas schief läuft. Im Folgenden finden Sie drei wichtige Git-Verfahren, die Ihnen helfen, sicherer zu arbeiten:

Erstellen einer .gitignore-Datei für sensible Dateien

Eine .gitignore-Datei ist eine einfache Textdatei, die Git mitteilt, was es ignorieren (d. h. nicht in Ihr Repository übertragen) soll. Normalerweise soll Git computergenerierte Dateien wie Protokolle ignorieren, da diese Ihr Repository unübersichtlich machen und Informationen über die Anwendung enthalten könnten, die zur Kompromittierung verwendet werden könnten. Ihre .env-Datei sollte ebenfalls ignoriert werden, da sie sensible Umgebungsvariablen (wie API-Schlüssel und Kennwörter) enthält, die Hacker verwenden könnten, um sich als Sie auszugeben und Zugriff auf Ihr System zu erhalten. 

Behalten Sie einen klaren Commit-Verlauf bei

Wenn Sie Änderungen so in sich geschlossen wie möglich halten, ist es einfacher zu erkennen, wann ein Fehler oder eine Schwachstelle aufgetreten ist, und es ist einfacher, sie rückgängig zu machen, ohne andere Arbeiten erneut durchführen zu müssen. Wenn Sie einen Schritt weiter gehen und signierte Übertragungen einrichten, können Sie sicherstellen, dass die richtigen Entwickler den Code in Ihr Repository übertragen (auch wenn das nur Sie selbst sind!). 

Getrennte Entwicklungs-, Staging- und Produktionszweige für Funktionen

Verzweigungen in Git helfen dabei, verschiedene, in sich geschlossene Bereiche für die Arbeit, die Vorschau und die Veröffentlichung von Code zu schaffen. Die aktive Entwicklung neuer Funktionen in einem separaten Zweig hilft zu verhindern, dass unfertiger, fehlerhafter oder unsicherer Code versehentlich in Ihre Live-Anwendung übertragen wird. Sobald ein neues Feature oder eine neue Funktionalität vollständig entwickelt und getestet ist, fungiert ein Staging-Zweig als weitere Sicherheits- und Qualitätskontrolle, die es Ihnen ermöglicht, die Änderungen vor der Freigabe für die Produktion zu überprüfen und zu finalisieren. Nur vollständig getestete und stabile Funktionen können dann in den Produktionszweig (in der Regel als Hauptzweig bezeichnet) überführt werden.

Gehostete Git-Repositories: GitHub GitLab   

secrets vom Code getrennt halten

‍

‍

SecretsIhre Passwörter, Verschlüsselungsschlüssel, API-Token und digitalen Zertifikate - sollten getrennt vom Code behandelt werden, um eine direkte Übertragung in Ihre Codebasis zu vermeiden. Sie können Ihren Code mit Aikido auf secrets überprüfen, sogar von Ihrer Cursor-IDE aus.

Schützen Sie Ihre Anwendung vor DDoS-Angriffen

Bei einem Distributed-Denial-of-Service-Angriff (DDoS) wird versucht, den normalen Datenverkehr eines angegriffenen Servers, Dienstes oder Netzwerks zu stören, indem das Ziel oder die umliegende Infrastruktur mit einer Spitze des Internetverkehrs überflutet wird. Diese Angriffe können verheerende Folgen haben, und es ist erstaunlich einfach, sich zu schützen, indem man grundlegende DDoS-Schutzmaßnahmen in ein Content Delivery Network (CDN) wie CloudFlare oder CloudFront integriert. Einige Domain-Hosting-Provider bieten sogar ein CDN als integrierten Service an. 

Nehmen Sie die Authentifizierung nicht selbst vor

Die Authentifizierung (wie auch der Anmeldevorgang) ist eine sensible Komponente Ihrer Anwendung, die Sie lieber den Experten überlassen. Die Verwendung eines speziellen Tools zur Durchsetzung von Passwortrichtlinien und zur einfachen Bereitstellung von Single-Sign-On oder sogar Multi-Faktor-Authentifizierung für Ihre Anwendung, während Sie diese skalieren, schützt Ihre Benutzerkonten und Ihren Ruf. 

Großartige Werkzeuge: Auth0, Quasr 

Führen Sie niemals Ihre eigene Kryptographie durch

Ebenso ist die Kryptographie ein Fachgebiet, daher sollten Sie sich immer auf bewährte Mechanismen, Bibliotheken und Werkzeuge verlassen. Bauen Sie Ihre eigenen Implementierungen, oder verwenden Sie Flags und Optionen, die Sie nicht vollständig verstehen,

wird Sie großen Risiken aussetzen. Bibliotheken wie NaCL bieten nur wenige Optionen und beschränken Sie auf eine gute Auswahl.

‍

Stufe 1

Einrichten einer CI/CD-Pipeline zur Überwachung Ihres Codes

Die Implementierung einer CI/CD-Pipeline mit Tests ist wie das Hinzufügen von Qualitätskontrollpunkten am Fließband für Ihren Anwendungscode. Sie können Tools zur statischen Codeanalyse integrieren, um statische Anwendungssicherheitstests (SAST) durchzuführen, die Ihren Code auf Schwachstellen untersuchen, die zu Sicherheitslücken führen können. Sie können auch ein Tool für die dynamische Anwendungssicherheitsprüfung (DAST, manchmal auch Oberflächenüberwachung genannt) integrieren, um Angriffe zu simulieren und Schwachstellen im Frontend Ihrer Webanwendung zu identifizieren (z. B. Suche nach offenen Ports oder ungehindertem eingehenden Datenverkehr). 

DAST mit offenem Quellcode: ZAP

Opensource SAST: Opengrep

Überwachen Sie Ihre Abhängigkeiten  

Ob Sie sich dessen bewusst sind oder nicht: Der Großteil des Codes Ihrer Anwendung stammt wahrscheinlich aus Open-Source-Projekten und Bibliotheken von Drittanbietern, auf denen KI-Modelle trainiert werden. Dies sind Ihre Abhängigkeiten, und manchmal haben sogar diese ihre eigenen Abhängigkeiten - die alle Ihre Software-Lieferkette ausmachen. Ein einziger Fehler in einer dieser Bibliotheken könnte Ihre gesamte Anwendung gefährden. Sie können das Risiko jedoch verringern, indem Sie die richtigen Tools verwenden, um Ihre Abhängigkeiten auf bekannte Schwachstellen zu überwachen.

Empfohlenes Werkzeug: Trivy

Mit Aikido in Sekundenschnelle einrichten

Überprüfen Sie Ihre Abhängigkeiten auf Malware

Auch Ihre Lieferkette kann bösartige Pakete mit Malware enthalten. Diese sind besonders gefährlich, da Angreifer in der Regel schnell handeln, nachdem es ihnen gelungen ist, Malware in Ihren Code einzuschleusen. Sie müssen also ebenfalls schnell reagieren. Beachten Sie, dass die CVE-Datenbanken (Common Vulnerabilities and Exposures) zu langsam sind und Sie nicht vor dieser Art von Angriffen schützen können.

Werkzeuge: Aikido Intel

Mit Aikido in Sekundenschnelle einrichten

Nutzen Sie Lockfiles zum Schutz Ihrer Lieferkette

Wenn Sie keine Lockfiles verwenden, ziehen Sie jedes Mal, wenn Sie Ihre Anwendung bauen, die neuesten Versionen aller Open-Source-Pakete ein. Lockfiles ermöglichen reproduzierbare Builds, indem sie dieselben Versionen Ihrer Open-Source-Abhängigkeiten einbinden. Dadurch bleibt Ihre Anwendung stabil, wenn sich an den Abhängigkeiten etwas ändert, und sie ist auch gegen Angriffe auf die Versorgungskette geschützt, wenn die neueste Version einer Abhängigkeit kompromittiert wurde. Ein aktuelles Beispiel hierfür ist die tj-actions/changed-files-Schwachstelle vom März 2025: Angreifer änderten den Code der GitHub-Action tj-actions/changed-files, was dazu führte, dass die kompromittierte Action secrets in den Build-Protokollen von GitHub-Actions ausgab.

Verhinderung von Cross-Site-Scripting-Angriffen mit strengen CSP-Headern

CSP-Header können Sie vor gängigen XSS-Angriffen schützen, indem sie eine zusätzliche Sicherheitsebene bieten, die kontrolliert, welche dynamischen Ressourcen geladen werden dürfen. Das hindert Angreifer daran, Skripte in Ihre Webseiten einzuschleusen.

Prüfen Sie, ob Sie sie mit Aikido richtig eingestellt haben

Verwenden Sie eine Web Application Firewall

Verwenden Sie eine Web Application Firewall (WAF) oder Runtime Application Self-Protection (RASP) zum Schutz von Web-Servern vor unbekannten Zero-Day-Bedrohungen, einschließlich unbekannter SQL-Injection- oder XSS-Bedrohungen. Das Tool scannt und verhindert Benutzeranfragen mit verdächtigem oder bösartigem Verhalten (z. B. eine Injektionsnutzlast) und fungiert als letzte Verteidigungslinie gegen Angriffe. 

Großartige Tools: AWS WAF Aikido Zen

‍

Stufe 2

Nach der Umsetzung der oben genannten Sicherheitsmaßnahmen ist es an der Zeit, Ihre Sicherheitslage zu verbessern.

Implementierung bewährter Verfahren für Container

Container verpacken Software so, dass sie zuverlässig ausgeführt werden kann, wenn sie von einer Computerumgebung in eine andere verschoben wird. Sie bündeln eine Anwendung mit all ihren notwendigen Abhängigkeiten, wie Bibliotheken, Frameworks und Konfigurationsdateien (alles in Ihrer Lieferkette), in einem einzigen Paket. Dadurch wird sichergestellt, dass die Anwendung unabhängig von der Umgebung, in der sie bereitgestellt wird, konsistent ausgeführt wird. 

Wenn Sie Container für die Bereitstellung verwenden, gibt es einige bewährte Verfahren, die dazu beitragen, Ihre Anwendung zu sichern.

Halten Sie Ihre Docker-Basis-Images auf dem neuesten Stand 

Schwachstellen in Ihrem Basis-Container-Image (die Blaupause dafür, woraus Ihr Container besteht) gefährden Ihre Anwendung. Laden Sie regelmäßig alle Sicherheitsupdates für Ihr Basis-Image herunter. Für Server können Sie dies an einen PaaS-Anbieter wie Heroku oder AWS Beanstalk delegieren.

Scannen Sie Ihre Docker-Sicherheit mit: Syft Grype Trivy

Mit Aikido in Sekundenschnelle einrichten

Docker-Container mit eingeschränkten Rechten ausführen

Eingeschränkte Privilegien machen es erfolgreichen Angreifern schwer, den Host zu übernehmen oder zu anderen Diensten vorzudringen. Vermeiden Sie die Ausführung von Containern mit privilegierten Benutzerrollen, wie z. B. root auf Unix-Systemen oder Administrator oder System auf Windows-Systemen.

Schützen Sie Ihre secrets

Die Trennung von secrets und Code ist ein guter Anfang. Wenn Sie Container verwenden, müssen Sie auch sicherstellen, dass Ihre geheimen Dateien und andere sensible Daten angemessen geschützt sind. Dazu gehören Tools zur Verwaltung von secrets (viele Cloud-Anbieter bieten ihre eigenen an), secrets , wenn Sie Kubernetes verwenden, regelmäßige Rotation von secrets und das Festlegen von Verfallsdaten für Ihre secrets. 

Tools zur Verwaltung von Secrets : HashiCorp Vault AWS Secrets Manager Google Cloud Secret Manager

Lesen Sie weiter: Sichere Verwaltung von Secrets in Containern: Bewährte Praktiken und Strategien

Überprüfen Sie Ihre Pakete auf ihr End of Life (EOL)

Je älter die Pakete werden und je länger sie nicht mehr unterstützt werden, desto größer ist das Risiko von Sicherheitslücken. Sie sollten darauf achten, dass Sie Pakete aktualisieren, die bald ihr Lebensende erreichen.

Oder richten Sie es in Sekundenschnelle mit der Container-Scan-Funktion von Aikido ein

Implementierung von Best Practices für Ihre Cloud-Konten

Trennen Sie die Cloud-Konten für Entwicklung, Staging und Produktion 

Genauso wie Sie Ihre Git-Zweige für Entwicklung, Staging und Produktion getrennt halten sollten, gilt dies auch für Ihre Cloud-Konten. Sie könnten zwar virtuelle Netzwerke innerhalb Ihrer Cloud-Konten erstellen, um Staging und Produktion voneinander zu trennen, aber das kann später, wenn Sie wachsen, umständlich werden, da Sie am Ende ständig Benutzerzugriffsrechte für neue Entwickler verwalten müssen. Wir empfehlen, die Entwicklungs-, Staging- und Produktionsinfrastruktur in vollständig getrennten Cloud-Konten zu halten. Alle Cloud-Anbieter bieten eine einheitliche Abrechnung an, was Ihnen eine Sorge weniger bereitet.

Verwendung von Tools zur Verwaltung der Cloud-Position

Cloud bieten so viele Funktionen an, dass man leicht etwas übersehen oder falsch konfigurieren kann, was ein Risiko für Sie darstellt. Verwenden Sie ein Cloud Security Posture ManagementCSPM)-Tool, um Ihre Cloud auf Anomalien zu überprüfen.

CSPM : Cloudsploit AWS Inspector

Mit Aikido in Sekundenschnelle einrichten

Cloud-Budget-Warnungen aktivieren

Für den Fall, dass Ihr Cloud-Konto gehackt wird, ist eine sichere Methode, um zu erkennen, dass jemand Bitcoin über Ihr Konto schürft, die Einrichtung von Budget-Warnungen zur Überwachung der Ausgaben. Ihr Cloud-Anbieter sollte hierfür integrierte Warnmeldungen anbieten, oder Sie können mit Aikido einen Cloud-Scan einrichten, um nach Budgetproblemen und riskanten Fehlkonfigurationen zu suchen. 

Prüfen Sie Ihre LLMs auf die häufigsten Schwachstellen

Sie bauen nicht nur mit LLMs, sondern integrieren LLMs vielleicht auch in Ihr öffentlich zugängliches Produkt. Sie könnten einen Chatbot haben, der den Nutzern Unterstützung bietet, oder einen KI-Assistenten, der ihnen beim Einstieg hilft. Wenn Ihre Kunden in irgendeiner Form mit einem LLM interagieren, ist es eine gute Idee, sie auf die häufigsten Schwachstellen zu testen, damit Sie Ihre Kunden keinen Sicherheitsrisiken aussetzen. 

Prüfen Sie die am häufigsten auftretenden Exploits: OWASP Top 10 für LLMs

Jenseits von

Implementierung eines sicheren Entwicklungslebenszyklus

Ein großer Teil der modernen Sicherheitspraxis besteht darin, Sicherheitsmaßnahmen früher in den Entwicklungszyklus einzubringen. Dies hilft Ihnen, sich gute Praktiken in jeder Phase des Projekts anzugewöhnen und Probleme früher zu erkennen, bevor sie zu einer echten Bedrohung werden. Das bedeutet, dass Sie sich an eine Sicherheitscheckliste wie diese halten, sich mit typischen Sicherheitsmängeln vertraut machen und bei der Codeüberprüfung darauf achten und auch bei Pull-Requests Sicherheitsüberprüfungen durchführen. 

Lesen Sie mehr: OWASP Top Ten

Lesen Sie mehr: Wikipedia-Artikel zum Lebenszyklus der Systementwicklung

Jeder kann Opfer eines Cyberangriffs werden - selbst multinationale Unternehmen mit eigenen Sicherheitsabteilungen sind immer noch anfällig für Sicherheitsverletzungen. Auch wenn der Code von Vibes nicht standardmäßig sicher ist, können Sie sich dennoch voll und ganz auf die Vibes einlassen, wenn Sie von Anfang an die besten Sicherheitsverfahren anwenden. Was auch immer Sie bauen, es ist die Mühe wert. 

Weitere Lektüre

• Aikidos SaaS CTO-Sicherheitscheckliste 2025
• Der Open-Source-Leitfaden des Startups für Anwendungssicherheit

‍