Implementierung & Härtung – aus dem Prototyp wird ein System

Im I-Schritt des ANVIL-Systems wird aus dem validierten Prototyp das MVP – die erste marktreife Version eines Produkts. Das ist der Moment, in dem Tempo auf Härte trifft. Eine funktionierende Demo beweist, dass eine Idee trägt; sie beweist nicht, dass der Code einem Angriff, einem Audit oder echter Last standhält. Genau diese Lücke schließt der I-Schritt: KI-beschleunigte Weiterentwicklung, Härtung jeder Funktion nach OWASP Top 10, jede Zeile im Senior-Review. Der Prototyp ist dabei kein Wegwerf-Artefakt, sondern das präziseste Lastenheft, das es gibt – er zeigt schwarz auf weiß, was das Produkt können muss, und spart Wochen an Anforderungsworkshops.

45 %

des KI-generierten Codes enthält Sicherheitslücken (Veracode 2025)

2,74×

häufiger Sicherheitsprobleme in KI-Code als in menschlichem Code (CodeRabbit)

+34 %

Ausnutzung von Schwachstellen als initialer Angriffsvektor (Verizon DBIR 2025)

3,87 Mio. €

durchschnittliche Kosten eines Datenlecks in Deutschland (IBM 2025)

Aus dem validierten Prototyp wird ein MVP

Im I-Schritt zahlt sich die Vorarbeit aus. Was Sie mit Cursor, Claude, Lovable oder einem Freelancer gebaut haben, wird nicht weggeworfen – es ist die Grundlage, denn es legt bereits fest, was das Produkt können muss. Drei Begriffe, drei Reifegrade, sauber getrennt:

Stufe	Was es ist	Wo im ANVIL-System
Prototyp	Ihr Werk – die funktionierende Demonstration Ihrer Idee	Eingang ins System
MVP	erste marktreife, gehärtete Version mit echten Nutzern	Ergebnis des I-Schritts
Plattform	die skalierte, im Betrieb laufende Version	Ergebnis von Schritt L

Nach der allen vier Einstiegspfaden gemeinsamen Analyse (Schritt A) erreichen zwei Pfade direkt diesen Schritt: Wer einen Prototyp mitbringt (der häufigste Fall), steigt hier bei I ein; wer eine bestehende, unsichere oder fragile Plattform sanieren lassen will, beginnt bei I oder L. In beiden Fällen liegt nach Schritt A bereits eine priorisierte Roadmap vor, und der Weg ist klar. Wie der Weg vom Prototyp über das MVP zur Plattform im Detail verläuft, beschreibt der Leitfaden: Vom Prototyp zur Produktion.

Härtung nach OWASP Top 10:2025

KI verkürzt die Bauzeit von Monaten auf Wochen – und reproduziert dieselben Schwachstellen im selben Tempo. Laut CodeRabbits Analyse von 470 Pull Requests treten Sicherheitsprobleme in KI-Code bis zu 2,74× häufiger auf als in rein menschlich geschriebenem Code; Veracode fand, dass 45 % des KI-generierten Codes Schwachstellen enthält. CodeRabbit: State of AI vs. Human Code Generation Report Veracode: GenAI Code Security Report 2025 Dass Angreifer genau hier ansetzen, belegt der Verizon DBIR 2025: Die Ausnutzung von Schwachstellen als initialer Angriffsvektor ist im Jahresvergleich um 34 % gestiegen. Verizon: Data Breach Investigations Report 2025

Deshalb wird das MVP systematisch gegen die zehn häufigsten Risiken der OWASP Top 10:2025 geprüft, und jeder Befund wird behoben: OWASP Top 10 (2025)

Broken Access Control – fehlende Berechtigungsprüfungen, IDOR-Schwachstellen
Security Misconfiguration – Default-Credentials, verbose Error-Messages, offene Debug-Endpoints
Software Supply Chain Failures – kompromittierte Dependencies, fehlende SBOMs, unsichere CI/CD
Injection – SQL-, NoSQL- und Command-Injection
Cryptographic Failures – unverschlüsselte Übertragung, schwache Algorithmen
Authentication Failures – schwache Policies, fehlende MFA; eingesetzt wird Keycloak als Self-Hosted Identity Provider mit Passwordless Auth und Magic Links
Logging & Monitoring Failures – strukturiertes Logging mit OpenTelemetry für lückenlose Nachvollziehbarkeit

Die wiederkehrenden Muster bei KI-generierten Anwendungen sind die teuersten: hardcodierte API-Keys, fehlende Input-Validierung, exponierte Admin-Routen, personenbezogene Daten in Logfiles und fehlende Rate-Limits. Wie groß die Angriffsfläche ist, zeigt eine einzige Zahl: Allein 2025 wurden über 28,6 Millionen neue Secrets in öffentlichen GitHub-Repositories exponiert. GitGuardian: State of Secrets Sprawl 2026 Eine vertiefte Darstellung der wiederkehrenden Muster bietet der Artikel Vibe Coding richtig gemacht; die systematische Härtung dieser Schwachstellen ist fester Bestandteil von Schritt I.

Jede Zeile im Senior-Review: KI für Tempo, Expertise für Härte

Das Prinzip wird über ein festes Gate durchgesetzt: KI-Tools wie Claude Code generieren den Code, aber kein Commit erreicht die Produktion ohne Senior-Review und grünes Quality-Gate. Jede Zeile trägt am Ende eine namentliche Freigabe – erst dann gilt sie als fertig. GitHub: Quantifying Copilot's Impact on Productivity (2022)

Automatisierte Test-Suite: Unit-, Integrations- und E2E-Tests sichern jede Funktion ab. Jeder Fix wird mit einem Test verankert, damit Schwachstellen nicht zurückkehren.
CI/CD mit Quality Gates: Linting, Security-Scanning und GitOps-basierte Deployment-Pipeline. Kein Commit erreicht die Produktion ohne Review.
Senior-Review jeder Zeile: Keine Black Box. Architekturentscheidungen sind dokumentiert und begründet, der Code bleibt für Sie und jedes spätere Team nachvollziehbar.

Der Unterschied ist nicht akademisch. Zum Einsatz kommen Snyk und Trivy für kontinuierliches Vulnerability-Scanning – wichtig, weil laut Snyk und Linux Foundation 40 % aller Open-Source-Schwachstellen in transitiven Abhängigkeiten liegen, die nie direkt installiert wurden. Snyk & Linux Foundation: State of Open Source Security 2022

Gehärtete Infrastruktur, DSGVO und NIS2 von Anfang an

Härtung endet nicht an der Anwendungsgrenze. Die in Schritt N festgelegte Infrastruktur wird nach dem Least-Privilege-Prinzip abgesichert:

Netzwerk & WAF – Least-Privilege-Firewall-Regeln, Segmentierung, Web Application Firewall
TLS-Konfiguration – TLS 1.3, HSTS, Certificate Transparency
Container-Sicherheit – minimale Base-Images, keine Root-Prozesse, Image-Scanning, gehärtete K3s-Konfiguration
Secrets Management – keine Credentials in Code oder Environment-Variablen, Vault-Integration

Compliance ist dabei kein Nachrüstprodukt, sondern Bestandteil der Härtung: Verschlüsselung at rest und in transit, Zugriffsprotokolle, Löschkonzepte und ein dokumentiertes Verarbeitungsverzeichnis. Die sicherheitsrelevanten NIS2-Kernmaßnahmen nach Art. 21 werden technisch umgesetzt – relevant, da NIS2 seit Dezember 2025 von rund 29.500 deutschen Unternehmen dokumentierte Cybersicherheitsmaßnahmen verlangt. BSI: NIS2-Umsetzung in Deutschland Details liefern die NIS2-Sicherheits-Checkliste, die Seite NIS2 für Webplattformen und das DSGVO Vendor-Audit. Der wirtschaftliche Hebel ist erheblich: Laut IBM reduzieren Unternehmen mit umfassendem Security-Einsatz ihre durchschnittlichen Breach-Kosten um 1,9 Mio. $ und verkürzen den Breach-Lebenszyklus um 80 Tage. IBM: Cost of a Data Breach Report 2025

Wie läuft der I-Schritt ab?

Kriterium	Phase	Zeitrahmen
1. MVP-Bau aus dem validierten Prototyp	Kernfunktionalität, Datenmodell, API und Authentifizierung auf der Zielarchitektur aus Schritt N	Woche 1–6
2. Härtung & OWASP Top 10	Remediation, Rate-Limiting, Input-Validierung, sichere Header, Secrets Management	Woche 4–8
3. Tests & Senior-Review	Automatisierte Test-Suite, CI/CD-Quality-Gates, Review jeder Zeile	laufend
4. Verifikation	Unabhängiger Penetrationstest, Regressionstests, DSGVO-Prüfung	Woche 8–10
5. Übergabe an L	Dokumentierter Audit-Trail, Sicherheitsbericht, Übergang zu Launch & Betrieb	Woche 10

Am Ende des I-Schritts steht ein verifizierbares Ergebnis, kein Dokument: ein lauffähiges, gehärtetes MVP mit Git-Repository-Übergabe und Dokumentation, eine eingerichtete CI/CD-Pipeline mit automatisierten Tests, ein Sicherheitsbericht mit den Ergebnissen des Penetrationstests und eine Architektur-Dokumentation für die Weiterentwicklung. Von hier ist es nur noch ein Schritt bis zum Launch & laufenden Betrieb (L).

Warum sich diese Disziplin über die Laufzeit auszahlt

Die strenge Reihenfolge – erst bauen, dann härten, kein Code in Produktion ohne Review – kostet im Moment Zeit und spart sie über die Laufzeit. Ungehärteter Code verschwindet nicht von selbst; er wird zur Hypothek. McKinsey beziffert technische Schulden auf 20–40 % des gesamten Technologie-Bestands eines Unternehmens, und Martin Fowler beschreibt, wie sie zum Engpass wachsender Unternehmen werden. McKinsey: Tech debt – Reclaiming tech equity Martin Fowler: Bottleneck #01 – Tech Debt Jede Schwachstelle, die in der Härtung geschlossen wird, ist eine, die nicht später unter Last, im Audit oder nach einem Vorfall behoben werden muss – wenn sie ungleich teurer ist.

Im Vergleich zum Weiterbetrieb eines vibe-gecodeten Projekts zeigt sich der Unterschied genau hier: nicht in der Demo, die in beiden Fällen läuft, sondern in dem, was danach kommt. Der I-Schritt ist die günstigste Stelle, um diese Disziplin einzuziehen – jede später geschlossene Lücke kostet ein Vielfaches.

Sie haben einen validierten Prototyp oder eine Plattform, die produktionsreif werden soll? Schreiben Sie uns eine kurze Beschreibung Ihres Projekts. Im Erstgespräch besprechen wir den konkreten Weg zum gehärteten MVP.

Häufig gestellte Fragen

Was ist der I-Schritt – Implementierung und Härtung?

Der I-Schritt ist die vierte Stufe des ANVIL-Systems. Aus dem validierten Prototyp entsteht das MVP – die erste marktreife Version. Die Entwicklung läuft KI-beschleunigt weiter, gehärtet nach OWASP Top 10, jede Funktion durch automatisierte Tests abgesichert, jede Zeile Code im Senior-Review. Das Ergebnis ist ein System, das einem Sicherheits-Audit und echten Kunden standhält.

Ich habe einen KI-gebauten Prototyp – steige ich hier ein?

Ja. Der Prototyp-Pfad ist der häufigste Einstieg und beginnt – nach der Analyse (Schritt A) – direkt im I-Schritt. Der Prototyp ist dabei kein Wegwerf-Artefakt, sondern die Grundlage des MVP: Er belegt unmissverständlich, was das Produkt können muss, und genau darauf wird aufgesetzt.

Wie wird KI-generierter Code abgesichert?

Über die Dualität von Tempo und Härte. KI-Tools beschleunigen die Entwicklung, aber jede Zeile durchläuft ein Senior-Review und automatisierte Tests. Geprüft wird systematisch gegen die OWASP Top 10:2025, jede gefundene Schwachstelle behoben und der Fix mit einem Test abgesichert. Das Tempo der KI bleibt, die Sicherheitslücken nicht.

Was ist der Unterschied zwischen Prototyp, MVP und Plattform?

Ein Prototyp ist Ihr Werk – die funktionierende Demonstration Ihrer Idee und der Eingang ins ANVIL-System. Das MVP ist das Ergebnis dieses I-Schritts: die erste marktreife, gehärtete Version mit echten Nutzern, Tests und Compliance-Grundlagen. Die Plattform ist die skalierte, im Betrieb laufende Version – das Ergebnis des Launch-Schritts (L).

Ist das MVP von Anfang an DSGVO- und NIS2-konform?

Ja. Verschlüsselung, Zugriffskontrolle, Audit-Logging und ein dokumentiertes Verarbeitungsverzeichnis sind Bestandteil der Härtung. Die sicherheitsrelevanten NIS2-Kernmaßnahmen nach Art. 21 werden technisch umgesetzt, gehostet wird EU-souverän, ohne CLOUD-Act-Exposition. Am Ende steht ein Audit-Trail, keine bloße Absichtserklärung.

Wie lange dauert der I-Schritt?

Typischerweise zehn bis zwanzig Werktage, abhängig vom Umfang des validierten Prototyps und der Zielarchitektur. MVP-Bau und Härtung laufen überlappend, Senior-Review und automatisierte Tests durchgehend. Den genauen Rahmen legt die Analyse (Schritt A) fest, bevor der Bau beginnt.