---
title: "Implementierung & Härtung – aus dem Prototyp wird ein System"
description: "Schritt I im ANVIL-System: vom validierten Prototyp zum MVP – nach OWASP Top 10 gehärtet, automatisiert getestet, jede Zeile im Senior-Review."
lastUpdated: "2026-06-27"
canonical: "https://anvilstack.eu/services/mvp-engineering"
---

> Sitemap für Agenten: https://anvilstack.eu/llms.txt

# 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)

> **Info:** **Kein Härten heißt Datenleck statt Launch.** 45 % des KI-generierten Codes enthalten Sicherheitslücken; ein ungehärtetes System wird zum Risiko, nicht zum Produkt. Laut IBM kostet ein Datenleck in Deutschland im Schnitt 3,87 Mio. €. Die Konsequenz ist keine zweite Codebasis, sondern eine Reihenfolge: KI baut schnell, Senior-Expertise härtet nach – automatisierte Tests, saubere CI/CD, jede Zeile im Review. Das Tempo der KI bleibt, die Sicherheitslücken nicht. Was bleibt, ist ein System, das einem Audit standhält. Und echten Kunden.

## 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)](https://anvilstack.eu/services/prototype-audit.md) 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](https://anvilstack.eu/insights/prototype-to-production.md).

## 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](https://www.coderabbit.ai/blog/state-of-ai-vs-human-code-generation-report)) ([Veracode: GenAI Code Security Report 2025](https://www.veracode.com/blog/genai-code-security-report/)) 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](https://www.verizon.com/business/resources/reports/dbir/))

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)](https://owasp.org/Top10/))

- **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](https://blog.gitguardian.com/the-state-of-secrets-sprawl-2026-pr/)) Eine vertiefte Darstellung der wiederkehrenden Muster bietet der Artikel [Vibe Coding richtig gemacht](https://anvilstack.eu/insights/vibe-coding-done-right.md); 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)](https://github.blog/news-insights/research/research-quantifying-github-copilots-impact-on-developer-productivity-and-happiness/))

- **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](https://www.linuxfoundation.org/press/press-release/state-of-open-source-security))

## 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](https://www.bsi.bund.de/DE/Themen/Regulierte-Wirtschaft/NIS-2-regulierte-Unternehmen/nis-2-regulierte-unternehmen_node.html)) Details liefern die [NIS2-Sicherheits-Checkliste](https://anvilstack.eu/insights/nis2-security-checklist.md), die Seite [NIS2 für Webplattformen](https://anvilstack.eu/compliance/nis2-web-platforms.md) und das [DSGVO Vendor-Audit](https://anvilstack.eu/compliance/gdpr-vendor-audit.md). 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](https://www.ibm.com/reports/data-breach))

## 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)](https://anvilstack.eu/services/platform-development.md).

## 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](https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/tech-debt-reclaiming-tech-equity)) ([Martin Fowler: Bottleneck #01 – Tech Debt](https://martinfowler.com/articles/bottlenecks-of-scaleups/01-tech-debt.html)) 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](https://anvilstack.eu/compare/vibe-coded-vs-engineered.md) 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.

[Unverbindliches Erstgespräch vereinbaren](https://anvilstack.eu/contact)

## 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.

## Quellen

- [Veracode: GenAI Code Security Report 2025](https://www.veracode.com/blog/genai-code-security-report/)
- [CodeRabbit: State of AI vs. Human Code Generation Report](https://www.coderabbit.ai/blog/state-of-ai-vs-human-code-generation-report)
- [Verizon: Data Breach Investigations Report 2025](https://www.verizon.com/business/resources/reports/dbir/)
- [OWASP Top 10 (2025)](https://owasp.org/Top10/)
- [GitGuardian: State of Secrets Sprawl 2026](https://blog.gitguardian.com/the-state-of-secrets-sprawl-2026-pr/)
- [GitHub: Quantifying Copilot's Impact on Productivity (2022)](https://github.blog/news-insights/research/research-quantifying-github-copilots-impact-on-developer-productivity-and-happiness/)
- [Snyk & Linux Foundation: State of Open Source Security 2022](https://www.linuxfoundation.org/press/press-release/state-of-open-source-security)
- [BSI: NIS2-Umsetzung in Deutschland](https://www.bsi.bund.de/DE/Themen/Regulierte-Wirtschaft/NIS-2-regulierte-Unternehmen/nis-2-regulierte-unternehmen_node.html)
- [IBM: Cost of a Data Breach Report 2025](https://www.ibm.com/reports/data-breach)
- [McKinsey: Tech debt – Reclaiming tech equity](https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/tech-debt-reclaiming-tech-equity)
- [Martin Fowler: Bottleneck #01 – Tech Debt](https://martinfowler.com/articles/bottlenecks-of-scaleups/01-tech-debt.html)
