ISGroup Cybersicherheitsberatung

AWS Kiro und Spec-Driven Development: Struktur, Sicherheit und Prüfungen vor dem Go-Live

AWS Kiro und spec-driven development: Mehr Struktur bedeutet nicht automatisch mehr Sicherheit

Kiro greift ein echtes Bedürfnis von Teams auf, die mit “Vibe Coding” experimentiert haben: weniger Chaos, mehr Kontext, besser lesbare Spezifikationen, geordnetere Aufgaben und eine Dokumentation, die näher am Code liegt. Spec-driven Development bringt eine nützliche Disziplin in die KI-gestützte Entwicklung, insbesondere wenn es sich nicht mehr nur um eine Demo handelt, sondern um eine Funktion, einen Dienst, eine interne Plattform oder eine App für echte Nutzer.

[Callforaction-WAPT]

Der kritische Punkt ist, Struktur nicht mit Sicherheit zu verwechseln. Eine gut geschriebene Spezifikation kann eine verwundbare Architektur beschreiben. Eine Anforderung in EARS kann formal klar sein und dennoch nichts über Tenant-Isolation, Privilege Escalation, Secret-Management oder API-Missbrauch aussagen. Ein Implementierungsplan kann geordnet sein und nur den “Happy Path” abdecken. Vor dem Deployment ist die entscheidende Frage nicht, ob Kiro den Code organisierter macht, sondern ob Anforderungen, Design, Aufgaben, Hooks, MCP, Tests und Implementierung ausreichende Sicherheitskontrollen enthalten, um reale Daten, Benutzer, APIs, Cloud-Umgebungen und Unternehmenssysteme sicher miteinander zu verknüpfen.

Was Spec-driven Development verbessert und was es nicht abdeckt

Kiro führt das Team von natürlichen Prompts hin zu strukturierten Anforderungen, Designs und ausführbaren Aufgaben. Dadurch wird ein Teil des typischen Risikos von Vibe Coding reduziert: implizite Entscheidungen, veraltete Dokumentation sowie Funktionen, die spontan generiert wurden und schwer zu warten sind. Struktur garantiert jedoch nicht, dass die Anforderungen korrekt sind. Wenn eine Spezifikation keine Rollen, sensiblen Daten, objektbezogenen Berechtigungen, Rate-Limits, Logs, Aufbewahrungsfristen, Vertrauensgrenzen (Trust Boundaries), Fehlerbehandlung und Missbrauchsszenarien enthält, kann der Agent ein Produkt konsistent implementieren, das aus Sicherheitssicht unvollständig ist.

Dasselbe gilt für Tests. Ein gut generierter Plan kann zwar überprüfen, ob der Benutzer den vorgesehenen Ablauf abschließen kann, aber das beweist nicht, dass ein Benutzer eines anderen Tenants nicht denselben Datensatz lesen kann, dass eine API keine willkürlichen IDs akzeptiert, dass eine IAM-Policy nicht zu weit gefasst ist oder dass ein Hook keine nicht überprüften Befehle ausführt.

Das Risiko der perfekten, aber unvollständigen Spezifikation

Spezifikationen helfen dabei, die Absicht explizit zu machen, aber wenn diese ursprüngliche Absicht Sicherheit, Datenschutz und Missbrauch nicht einbezieht, bleibt das Ergebnis fragil. Ein Satz wie “Der Benutzer kann seine eigenen Dokumente einsehen” muss überprüfbar werden: Welche Dokumente, mit welcher Identität, mit welchen Rollen, was passiert bei einer ID-Änderung, was passiert bei einem abgelaufenen Token, was passiert, wenn ein Admin eines Tenants versucht, einen anderen Tenant zu lesen?

Kiro kann helfen, Anforderungen in Aufgaben umzuwandeln, aber die Qualität des Ergebnisses hängt von der Qualität der Anforderungen selbst ab. Deshalb sollte jede Spezifikation für eine exponierte Funktion negative Akzeptanzkriterien enthalten: Zugriff verweigert, Eingabe abgelehnt, Datei nicht autorisiert, Rolle unzureichend, falscher Tenant, Token abgelaufen, Callback nicht in der Allowlist, Secret nicht geloggt. Eine Spezifikation, die nichts darüber aussagt, was blockiert werden muss, lässt dem Agenten zu viel Spielraum bei der Implementierung – mit dem Risiko, eine beruhigende Dokumentation zu erstellen, die zeigt, was die App tun soll, aber nicht, was sie nicht erlauben darf.

Threat Modeling innerhalb des spec-driven Prozesses

Threat Modeling sollte kein schwerfälliges Dokument sein, das von der Entwicklung getrennt ist. In einem Kiro-Workflow kann es in die Anforderungs- und Designphase integriert werden und Assets, Akteure, Vertrauensgrenzen, sensible Daten, externe Systeme, Privilegien, Abläufe und Fehlermodi abdecken. Bei jeder Spezifikation sollte sich das Team fragen: Welche Daten werden verarbeitet, welche Rollen existieren, welche Aktionen sind sensibel, welche APIs sind öffentlich, welche externen Systeme werden aufgerufen, welche Secrets sind erforderlich und welche Cloud-Befehle oder -Ressourcen werden berührt? Wenn die App Multi-Tenant ist, muss Tenant-Isolation eine Anforderung erster Klasse sein, keine bloße Implementierungsnotiz.

Das von Kiro generierte oder unterstützte Design sollte auch mit einer offensiven Fragestellung gelesen werden: Wie könnte es missbraucht werden? Kann ein Einladungs-Workflow wiederverwendet werden? Kann ein Passwort-Reset Benutzer enthüllen? Ist eine Admin-Route serverseitig wirklich geschützt? Kann ein Upload aktive Inhalte ausführen? Erstellt eine IaC-Aufgabe Ressourcen, die aus dem Internet zugänglich sind?

Agent Hooks: Nützliche Automatisierung, zu steuernde Angriffsfläche

Agent Hooks sind eines der spezifischsten Elemente von Kiro. Sie können bei Ereignissen wie Prompt-Übermittlung, Agent-Stopp, Pre/Post-Tool-Use, Dateierstellung oder -speicherung, Dateilöschung, Aufgabenausführung und manuellen Triggern aktiviert werden. Die Aktionen umfassen Prompts an den Agenten oder Shell-Befehle. Diese Automatisierung kann sehr nützlich sein, um Code zu formatieren, Dokumentationen zu aktualisieren, Tests zu generieren, Standards zu prüfen, Tools zu blockieren oder den Kontext zu erweitern. Sie kann jedoch zu einer kritischen Angriffsfläche werden, wenn sie ohne Überprüfung Befehle ausführt, Dateien ändert, Abhängigkeiten installiert, Tests startet, mit Cloud-CLIs interagiert oder Konfigurationen ändert.

Bevor Hooks in einem Team eingeführt werden, sollte eine Bestandsaufnahme der .kiro/hooks-Dateien erfolgen, der Ereignisse, die sie auslösen, der ausgeführten Aktionen und der im Repository verfügbaren Berechtigungen. Shell-Befehle sollten wie operativer Code behandelt werden: Wer genehmigt sie, was können sie lesen, was können sie schreiben, welche Umgebungsvariablen sehen sie, können sie Deployments, Löschungen, Migrationen oder Cloud-Befehle ausführen? Ein Hook, der beim Speichern einer Datei läuft, sollte nicht in der Lage sein, Terraform anzuwenden, Ressourcen zu löschen, nicht genehmigte Pakete zu installieren oder sensible Daten an externe Systeme zu senden. Automatisierungen mit hoher Auswirkung müssen Schwellenwerte, Logs und eine separate Genehmigung haben.

Steering Files und Projektregeln

Kiro ermöglicht es, Agenten mit Steering Files und Projektregeln zu steuern, wodurch Konventionen, Standards und Präferenzen explizit gemacht werden. Auch hier werden die persistenten Anweisungen jedoch Teil des Sicherheitsperimeters. Eine Regel, die den Agenten dazu drängt, “Tests bestehen zu lassen”, “Mocks zu verwenden, wenn Dienste fehlen”, “die Authentifizierung zu vereinfachen” oder “auch bei unvollständigem Kontext fortzufahren”, kann riskante Abkürzungen normalisieren. Umgekehrt können gut geschriebene Regeln Änderungen an der Authentifizierung ohne negative Tests verhindern, Secrets im Frontend blockieren, Überprüfungen bei IAM/IaC erfordern und “Default Deny”-Policies erzwingen.

Steering Files sollten wie Code überprüft werden. Sie müssen Stil, Architektur und Sicherheit trennen, Secrets und unnötige interne Endpunkte vermeiden und keine mehrdeutigen Anweisungen enthalten. Jede Änderung an diesen Dateien sollte einen PR-Review durchlaufen, da sie alle zukünftigen Aufgaben beeinflusst.

MCP, externe Tools und Spezifikationskontext

Kiro unterstützt MCP und kann eine Verbindung zu Dokumentationen, Datenbanken, APIs, AWS-Tools, Terraform oder anderen Systemen herstellen. Dies erhöht die Qualität des Kontexts erheblich, erweitert aber auch die Vertrauensgrenzen des Workflows. Wenn ein MCP-Server Zugriff auf Datenbanken, Tickets, Repositories, Cloud-Umgebungen, interne Dokumentationen oder Terraform-Registries gewährt, kann der Agent diese Informationen in die Spezifikation und in Implementierungsentscheidungen einfließen lassen. Das Risiko ist nicht MCP an sich, sondern die Verwendung von zu weit gefassten Tools und Anmeldeinformationen: geteilte Token, Read-Write-Berechtigungen, wo Read-Only ausreicht, Zugriff auf reale Daten während der Planung, Deployment-Tools, die in unkontrollierten Phasen verfügbar sind.

Die MCP-Governance für Kiro sollte eine Allowlist für Server, dedizierte Token, minimale Privilegien, eine Trennung zwischen Projekt- und globalen Konfigurationen, ein Audit der Tool-Aufrufe und die Deaktivierung nicht benötigter Tools in kritischen Repositories umfassen. Wenn AWS-Tools oder Terraform verwendet werden, müssen die resultierenden Änderungen eine IaC-Überprüfung und Genehmigung durchlaufen, bevor sie angewendet werden.

Terraform, IaC und Cloud: Wenn die Spezifikation Infrastruktur schafft

Eines der heikelsten Szenarien ist die Verwendung von Kiro zur Planung oder Generierung von Infrastruktur: Terraform, CloudFormation, CDK, Security Groups, IAM, VPCs, Datenbanken, Speicher, Load Balancer, Pipelines. Die Spezifikation kann die Arbeit ordnen, aber das Cloud-Risiko bleibt konkret. Eine Spezifikation, die “eine Umgebung für die App erstellen” fordert, kann zu weit gefassten Security Groups, öffentlichen Buckets, generischen IAM-Rollen, erreichbaren Datenbanken, Ausgaben mit Secrets, kaum getrennten Dev/Prod-Umgebungen sowie fehlender Verschlüsselung, Logging oder Backups führen. Das Ergebnis kann konsistent mit der Anfrage und dennoch in der Produktion inakzeptabel sein.

Vor der Anwendung von IaC, das mit Kiro generiert oder geändert wurde, sind Plan-Diffs, IaC-Scanner, manuelle Überprüfungen, Least-Privilege-Kontrollen, Tagging, Umgebungstrennung, Rollback-Pläne und eine explizite Genehmigung für kritische Ressourcen erforderlich. Die Anwendung von IaC darf kein Nebeneffekt einer Agenten-Aufgabe oder eines Hooks sein.

Generierte Tests: Funktional, nicht unbedingt offensiv

Kiro kann helfen, Tests zu generieren, die mit den Anforderungen verknüpft sind, aber die aus der Spezifikation abgeleiteten Tests neigen dazu, zu überprüfen, ob das System das tut, was angefordert wurde. Sicherheit erfordert auch den Nachweis, dass das System das ablehnt, was es nicht erlauben darf. Für jede exponierte Funktion sind negative Tests erforderlich: nicht authentifizierter Benutzer, unzureichende Rolle, falscher Tenant, Objekt eines anderen Benutzers, bösartige Eingabe, ungültige Datei, Anfrage außerhalb der Sequenz, abgelaufenes Token, Rate-Limit, nicht erlaubter Callback, kontrollierter Fehler. Wenn diese Fälle nicht in die Spezifikation einfließen, wird der Agent sie kaum robust abdecken.

Automatisierte Tests sollten durch Code-Reviews und, sobald Apps oder APIs online sind, durch manuelle WAPT-Tests ergänzt werden. Die schwerwiegendsten Schwachstellen sind oft keine syntaktischen Bugs, sondern Inkonsistenzen zwischen Anforderungen, Implementierung und tatsächlichem Verhalten.

Drift zwischen Spezifikation, Implementierung und Dokumentation

Einer der Vorteile von Spec-driven Development ist es, Absicht, Design und Implementierung zusammenzuhalten. Das Risiko besteht darin, zu glauben, dass diese Rückverfolgbarkeit automatisch und immer korrekt ist. Während der Entwicklung kann der Agent feststellen, dass die Spezifikation unvollständig ist, und die Implementierung ändern; der Entwickler kann einen Workaround akzeptieren, ohne Anforderungen und Design zu aktualisieren; ein Hook kann eine Dokumentation aktualisieren, die beschreibt, was passieren sollte, nicht was der Code tatsächlich anwendet. Die Spezifikation kann geordnet bleiben und dennoch falsch werden.

Für Sicherheitsbereiche muss die Rückverfolgbarkeit überprüft werden: Jede Anforderung an die Zugriffskontrolle muss eine Implementierung, einen positiven Test, einen negativen Test und einen Verantwortlichen haben. Jede Vertrauensgrenze muss Kontrollen im Design und im Code haben. Jede akzeptierte Ausnahme muss eine Begründung und einen Sanierungsplan (Remediation) haben.

Permission Fatigue und Genehmigungen

Kiro kann viele Genehmigungspunkte einführen: Aufgaben, Hooks, Tool-Use, Shell-Befehle, MCP, Dateiänderungen, Tests, PRs, IaC. Wenn alles das gleiche Maß an Aufmerksamkeit erfordert, riskiert das Team “Permission Fatigue” und neigt dazu, automatisch zuzustimmen. Die Lösung ist nicht, alles zu blockieren, sondern das Risiko zu klassifizieren. Formatierung, Dokumentation und lokales Refactoring können einen leichten Pfad haben, während Authentifizierung, IAM, Secrets, öffentliche APIs, Datenbanken, Speicher, Migrationen, Deployments, Löschungen, Terraform und Cloud-CLIs stärkere Genehmigungen und kompetente Prüfer erfordern müssen. Diese Unterscheidung muss getroffen werden, bevor Kiro in den Produktions-Workflow gelangt, denn wenn die Regel während eines dringenden Releases improvisiert wird, wird das Team dazu neigen, die Geschwindigkeit zu priorisieren.

Kiro-Checkliste vor dem Go-Live

Spezifikationen und Design

  • Überprüfen Sie die EARS-Anforderungen und stellen Sie sicher, dass sie Sicherheit, Rollen, Daten, Berechtigungen, Tenant-Isolation, Logging, Fehlerbehandlung, Aufbewahrung und Missbrauchsszenarien enthalten.
  • Fügen Sie negative Akzeptanzkriterien für das hinzu, was abgelehnt werden muss.
  • Verknüpfen Sie jede kritische Anforderung mit Design, Aufgaben, Code und Tests.

Hooks, Steering und MCP

  • Erstellen Sie ein Inventar von .kiro/hooks, Triggern, Shell-Befehlen, Prompt-Aktionen und beteiligten Tools.
  • Überprüfen Sie Steering Files wie Code.
  • Erfassen Sie MCP-Server, Token, Privilegien, zugängliche Daten und verfügbare Tools.
  • Deaktivieren Sie, was in kritischen Repositories nicht benötigt wird.

Code, APIs und Tests

  • Führen Sie Code-Reviews für Authentifizierung, Middleware, APIs, Validierung, Geschäftslogik, Fehlerbehandlung, Secrets und Abhängigkeiten durch.
  • Integrieren Sie negative Tests für Rollen, Tenants, IDOR/BOLA, bösartige Eingaben, Sitzungen, Uploads und Rate-Limits.
  • Wenn die App exponiert ist, planen Sie einen WAPT für die reale Umgebung.

Cloud, IaC und Produktion

  • Überprüfen Sie Terraform, CloudFormation, CDK, Security Groups, IAM, Speicher, Datenbanken, Networking, Pipelines und Secrets vor dem “Apply”.
  • Überprüfen Sie Least-Privilege, Umgebungstrennung, Logging, Backups, Rollbacks und Genehmigungen.
  • Kein Deployment- oder Destroy-Befehl sollte ein automatischer Nebeneffekt eines Hooks oder einer Aufgabe ohne Kontrolle sein.

Wann reicht ein interner Review und wann ist eine unabhängige Prüfung erforderlich?

Ein interner Review kann ausreichen, wenn Kiro für Spezifikationen oder Refactoring verwendet wird, die nicht exponiert sind, ohne reale Daten, ohne IaC, ohne öffentliche APIs und ohne Automatisierungen mit hoher Auswirkung. Eine unabhängige Prüfung ist hingegen erforderlich, wenn Spezifikationen Funktionen mit realen Daten, Rollen, Tenants, Zahlungen, Integrationen, öffentlichen APIs, IaC, AWS, Terraform, MCP oder Hooks steuern, die Befehle ausführen, oder wenn das Team Kiro kontinuierlich einsetzen möchte und Richtlinien, Überprüfungsschwellenwerte, Verantwortlichkeiten und wiederholbare Kontrollen definieren muss.

Der Punkt ist nicht, Kiro zu verlangsamen, sondern das zu trennen, was beschleunigt werden kann, von dem, was validiert werden muss: Anforderungen, Vertrauensgrenzen, Automatisierungen, Tools, Cloud, Code und tatsächliches Verhalten.

Wie ISGroup ein mit Kiro entwickeltes Projekt überprüfen kann

Die Kontrolle ändert sich je nachdem, was Kiro strukturiert, generiert oder automatisiert hat. Wenn das Risiko in den Anforderungen, dem Threat Model oder den architektonischen Entscheidungen liegt, hilft das Secure Architecture Review dabei, Design, Vertrauensgrenzen und Datenflüsse zu validieren. Wenn das Risiko AWS, Terraform, IAM, Security Groups, Speicher oder Pipelines betrifft, überprüft das Cloud Security Assessment Konfigurationen und Privilegien. Wenn das Ziel darin besteht, die Einführung, Richtlinien und Überprüfungsschwellenwerte zu steuern, hilft das Risk Assessment dabei, Prioritäten und Verantwortlichkeiten zu definieren.

Wenn Kiro berührt hat… Hauptrisiko Empfohlene Kontrolle
Spezifikationen, Anforderungen, Design, Vertrauensgrenzen, Datenflüsse Schwache architektonische Annahmen Secure Architecture Review
AWS, Terraform, IaC, IAM, Speicher, Datenbanken, Security Groups, Pipelines Cloud-Fehlkonfigurationen oder übermäßige Privilegien Cloud Security Assessment
Interne Richtlinien, Genehmigungsschwellen, Governance des Agenten-Workflows Nicht klassifiziertes Risiko oder nicht wiederholbare Kontrollen Risk Assessment
Anwendungscode, APIs, Middleware, Validierung, Secrets, Abhängigkeiten Schwachstellen oder Regressionen im Code Code Review
Web-Apps oder öffentliche APIs, die aus Spezifikationen generiert wurden Von außen missbrauchbare Verhaltensweisen Web Application Penetration Testing

Die Wahl der Kontrolle hängt davon ab, was sich tatsächlich geändert hat: Spezifikation, Architektur, Automatisierung, Cloud, Code oder exponiertes Verhalten. Vor dem Go-Live ist es ratsam, diesen Perimeter abzugrenzen und das tatsächliche Risiko für das Produkt zu überprüfen. Haben Sie Kiro verwendet, um Anforderungen in Design, Aufgaben, Code oder Infrastruktur umzuwandeln? ISGroup kann Ihnen helfen zu überprüfen, ob die von der KI erzeugte Struktur auch die notwendigen Sicherheitskontrollen enthält: Threat Model, Berechtigungen, IaC, IAM, Hooks, MCP, Tests und Sanierungspläne.

Nachweise, die vor dem Review vorzubereiten sind

Bevor ein externes Team hinzugezogen wird, ist es ratsam, Spezifikationen, EARS-Anforderungen, Design, Aufgaben, Repository, Diffs, Tests, .kiro/hooks-Dateien, Steering Files, konfigurierte MCP-Server, IaC-Templates, Plan-Diffs, beteiligte Konten oder Umgebungen, Rollen, verarbeitete Daten und bereits getroffene Entscheidungen zu akzeptierten Risiken zu sammeln. Diese Nachweise ermöglichen es zu verstehen, ob Sicherheit in der Spezifikation, im Design, in der Implementierung und in den Tests vorhanden ist, und ein methodisches Problem von einer Anwendungsschwachstelle oder einer Cloud-Fehlkonfiguration zu unterscheiden.

Die finale Frage sollte nicht abstrakt “Ist die Spezifikation vollständig?” lauten, sondern: Welche Sicherheitsanforderungen enthält sie, welche Bedrohungen deckt sie ab, welche Automatisierungen ermöglicht sie, welche Ressourcen erstellt sie, welche Daten legt sie offen und welche Tests beweisen, dass die Kontrollen auch gegen Missbrauch funktionieren? Kiro kann Ordnung in die KI-gestützte Entwicklung bringen; Sicherheit dient dazu, zu verhindern, dass diese Ordnung es einfacher macht, eine gut dokumentierte Schwachstelle in die Produktion zu bringen. Wurde das mit Kiro entwickelte Projekt als exponiertes Produkt überprüft oder nur als konsistente Spezifikation?

FAQ

  • Macht Spec-driven Development den Code sicherer?
  • Es macht den Prozess expliziter und nachvollziehbarer, garantiert aber keine Sicherheit. Wenn die Anforderungen keine Authentifizierung, Berechtigungen, Threat Models, Daten und negativen Tests enthalten, kann der Agent ein verwundbares System auf geordnete Weise implementieren.
  • Reichen EARS-Spezifikationen aus, um Sicherheitsanforderungen abzudecken?
  • Nein. EARS hilft dabei, klare Anforderungen zu schreiben, aber man muss explizit Sicherheit, Missbrauchsszenarien, Zugriffskontrolle, Fehlerbehandlung, Logging, Datenschutz und Sanierungspläne einbeziehen.
  • Sind Agent Hooks riskant?
  • Sie sind nützlich, werden aber riskant, wenn sie Shell-Befehle ausführen, Dateien ändern, Abhängigkeiten installieren, Cloud-CLIs starten oder mit externen Tools interagieren, ohne angemessene Genehmigung und Protokollierung.
  • Wann ist ein Secure Architecture Review erforderlich?
  • Wenn Kiro zu Spezifikationen, Design, Vertrauensgrenzen, Datenflüssen, Multi-Tenancy, Integrationen oder architektonischen Entscheidungen beigetragen hat, die in die Produktion gehen.
  • Wann ist ein Cloud Security Assessment erforderlich?
  • Wenn Kiro Terraform, CloudFormation, CDK, IAM, Security Groups, Speicher, Datenbanken, Pipelines oder AWS-Ressourcen generiert oder geändert hat.

[Callforaction-WAPT-Footer]

Quellen und nützliche Referenzen

In

, , ,

Leave a Reply

Your email address will not be published. Required fields are marked *