Von der Idee zum produktiven KI-System

Was zwischen „funktioniert auf meinem Rechner“ und einer zuverlässig betriebenen Anwendung liegt

Fakten- und Recherchestand: 8. August 2026 Version: 1.0 Autor: Andreas Rüdiger Räumlicher Schwerpunkt: Deutschland / Europäische Union; technische Quellen international Zielgruppe: Unternehmer, Fachverantwortliche, Vibe Coder, Entwickler, Berater und Betreiber Quellenbasis: 175 dokumentierte Standards, Behörden-, Forschungs-, Projekt- und Primärquellen Vorgesehener Dateiname: 14_von-der-idee-zum-produktiven-ki-system-faktendossier_2026-08-08

Auftrag, Reichweite und Leselogik

AUFTRAGSRAHMEN: Dieses Dossier untersucht den vollständigen Übergang von Idee, Experiment und Vibe-Coding-Prototyp zu einer produktiv betriebenen Anwendung. Es behandelt Anforderungen, Architektur, Versionsverwaltung, Tests und KI-Evals, CI/CD, Lieferkette, Infrastruktur, Deployment, Datenmigration, Reliability, Observability, Backup, Incident Response, Wartung und Stilllegung. ^{[S-001; S-002; S-024; S-102]}

EINORDNUNG: Der Fokus liegt auf Software, die KI als Komponente nutzt. Die meisten Produktionsprobleme bleiben klassische Software- und Betriebsprobleme: Identität, Daten, Zustandsänderung, Schnittstellen, Wiederherstellung und Verantwortung. KI ergänzt probabilistische Qualität, Modell-/Promptversionen, Evals, Providerabhängigkeit und neue Angriffsflächen. ^{[S-058; S-029; S-024; S-056]}

Abgrenzung: Dossier 13 erklärt die Bauteile einer KI-Systemarchitektur. Dossier 14 behandelt den Lebenszyklus und die Evidenz, die diese Bauteile produktionsfähig machen. Kostenrechnung wird in Dossier 17 vertieft; Rechtsfragen werden in den Rechtsdossiers der Reihe behandelt.

Quellen- und Statuslogik

• Als Primärquelle markierte Einträge: 48 von 175; offizielle Produktdokumentation wird separat als Anbieter-/Projektquelle geführt.
• Living Documentation wird mit Prüfstichtag statt erfundenem Veröffentlichungsdatum geführt.
• Veränderliche Provider-, Kubernetes-, OpenTelemetry-, SBOM- und Sicherheitsangaben stehen zusätzlich im Refresh-Plan.
• Quellen-IDs in Aussagen verweisen auf das vollständige Register mit Herausgeber, Titel, Datum, Status und direkter URL.

Was dieses Dossier ausdrücklich nicht behauptet

• Es gibt keinen universellen Zertifikatsstempel „production ready“ für jede Anwendung. ^{[S-006; S-102]}
• Kein einzelnes Tool, Framework, Cloudprodukt oder Modell löst den vollständigen Lebenszyklus. ^{[S-001; S-002]}
• Mehr Automatisierung ist nicht automatisch mehr Sicherheit; Kontrollen müssen selbst nachvollziehbar und betreibbar sein. ^{[S-022; S-079]}
• Ein erfolgreicher Provider- oder Modelltest beweist keine dauerhafte Qualität nach Änderungen. ^{[S-134; S-066]}
• Rechtliche Zulässigkeit ist nicht allein aus technischer Robustheit ableitbar. ^{[S-149; S-150]}

Management Summary

1. Der größte Denkfehler: Ein Prototyp beweist eine technische Möglichkeit. Ein Produkt beweist wiederholbaren Nutzen, kontrollierte Änderung, sicheren Betrieb und Wiederherstellung. ^{[S-001; S-102]}

2. Die erste Architekturfrage: Welche Wirkung darf das System auslösen, wie groß ist der Schaden bei Fehlern und wie wird die Wirkung zurückgenommen oder kompensiert? ^{[S-006; S-093]}

3. Der wichtigste organisatorische Nachweis: Es gibt benannte Eigentümer für Produkt, Code, Infrastruktur, Daten, Security, Support, Incident und Abschaltung. ^{[S-001; S-106]}

4. Der wichtigste technische Nachweis: Ein freigegebenes Artefakt lässt sich eindeutig auf Quelle, Build, Tests, Evals, Abhängigkeiten und Deployment zurückführen. ^{[S-079; S-039]}

5. Der wichtigste KI-Nachweis: Die produktive Kombination aus Modell, Prompt, Tools, Kontext und Datenstand schlägt eine definierte Baseline auf einem versionierten Eval-Satz und verletzt keine harten Ausschlusskriterien. ^{[S-066; S-067; S-029]}

6. Der wichtigste Betriebsnachweis: Das Team erkennt Nutzerprobleme über SLI/SLO und Telemetrie, reagiert über Runbooks und kann Daten sowie Dienst innerhalb definierter Ziele wiederherstellen. ^{[S-104; S-028]}

7. Der wichtigste Releasegrundsatz: Einmal bauen, dasselbe Artefakt fördern, klein exponieren, messen und bei klaren Kriterien stoppen oder weiterrollen. ^{[S-014; S-103]}

8. Der wichtigste Datenbankgrundsatz: Schema und Anwendung werden übergangsweise kompatibel gehalten; destruktive Änderungen kommen erst nach Migration und Evidenz. ^{[S-126; S-127]}

9. Der wichtigste Reliability-Grundsatz: Timeouts, begrenzte Retries, Idempotenz, Backpressure und Fehlerklassifikation sind geplante Eigenschaften, keine spätere Optimierung. ^{[S-092; S-093; S-043]}

10. Der wichtigste Sicherheitsgrundsatz: CI/CD, Abhängigkeiten, Modelle, Daten und Konfigurationen sind Teil der Lieferkette und benötigen minimale Rechte, Inventar und überprüfbare Herkunft. ^{[S-022; S-024; S-079]}

11. Der wichtigste Backupgrundsatz: Eine Sicherung ist erst belastbar, wenn die Wiederherstellung erfolgreich und innerhalb RPO/RTO getestet wurde. ^{[S-028; S-140]}

12. Der wichtigste Providergrundsatz: Abkündigungen, Limits und Verhaltensänderungen externer Modelle sind normale Betriebsereignisse und brauchen Inventar, Evals und Exitpfad. ^{[S-134; S-136; S-135]}

13. Der wichtigste Vibe-Coding-Grundsatz: Generierung beschleunigt die Erzeugung von Code, aber nicht automatisch Verständnis, Verantwortlichkeit, Review, Tests, Security oder Wartung. ^{[S-010; S-024]}

14. Der wichtigste Lernmechanismus: Incidents werden über Fakten, Ursachenketten und überprüfbare Maßnahmen verarbeitet, nicht über die Suche nach einem Schuldigen. ^{[S-107; S-026]}

15. Die harte Schlussfolgerung: Produktion ist kein Termin. Sie ist ein dauernder Regelkreis aus Nutzerwert, Telemetrie, Steuerung, kontrollierter Änderung, Wiederherstellung und Lernen. ^{[S-001; S-101]}

Minimaldefinition eines produktiven Systems

Was Produktionsreife tatsächlich bedeutet

GESAMTSYNTHESE: Produktionsreife ist die hinreichende Evidenz, dass ein System in einem definierten Einsatzkontext Nutzen liefert, bekannte Risiken angemessen kontrolliert, überwacht und supportet werden kann und nach Fehlern oder Änderungen in einen akzeptablen Zustand zurückkehrt. Diese Definition ist eine Synthese aus Lebenszyklus-, Qualitäts-, Risiko- und SRE-Grundlagen. ^{[S-001; S-002; S-006; S-102]}

Die fünf Evidenzklassen

Praktische Entscheidungsregel: Je irreversibler, weniger erkennbar und folgenreicher eine fehlerhafte Wirkung ist, desto mehr unabhängige Evidenz und menschliche Freigabe braucht der Produktivstart. ^{[S-006; S-029]}

Wann bewusst keine KI verwendet werden sollte

• Wenn die Entscheidung vollständig durch klare Regeln, Datenbankabfragen oder Berechnungen beschrieben werden kann. ^{[S-002; S-006]}
• Wenn Fehler nicht tolerierbar, schwer erkennbar und nicht reversibel sind und keine belastbare Kontrollschicht existiert. ^{[S-029; S-102]}
• Wenn die notwendigen Datenrechte, Datenqualität oder Belege fehlen. ^{[S-149; S-064]}
• Wenn ein Modellprovider, seine Limits oder sein Lebenszyklus nicht betreibbar in die Anwendung integriert werden können. ^{[S-135; S-134]}
• Wenn Nutzen gegenüber einer klassischen Lösung nicht messbar oder kleiner als zusätzliche Betriebs- und Risikolast ist. ^{[S-009; S-004]}

Reifegradmodell vom Experiment zum kritischen Dienst

``mermaid flowchart LR A[Idee] --> B[Experiment] B --> C[Prototyp] C --> D[Proof of Value] D --> E[Pilot] E --> F[Produktion] F --> G[Kritischer Dienst] ``

ARBEITSMODELL: Die Stufen sind kein formeller Industriestandard, sondern ein Arbeitsmodell. Sie verhindern, dass ein technischer Versuch sprachlich zum Produkt hochgestuft wird, bevor Nutzennachweis, kontrollierte Exposition und Betriebsfähigkeit vorliegen. ^{[S-001; S-102; S-006]}

Übergangskriterien

• Experiment → Prototyp: reproduzierbarer Mechanismus, dokumentierte Eingaben und bekannte Grenzen. ^{[S-019; S-059]}
• Prototyp → Proof of Value: realistische Aufgaben, Baseline, messbarer Nutzen und Fehlertaxonomie. ^{[S-009; S-066]}
• Proof of Value → Pilot: echte Nutzer, begrenzte Daten-/Aktionsrechte, Monitoring, Support und Exit. ^{[S-102; S-029]}
• Pilot → Produktion: akzeptierte Risiken, SLO, On-Call, Restoretest, kontrollierte Releases und Wartung. ^{[S-104; S-028; S-022]}
• Produktion → kritischer Dienst: stärkere Redundanz, Übungen, Assurance, Lieferketten- und Notbetriebskontrollen. ^{[S-033; S-079; S-025]}

63 belastbare Kernaussagen

Die Kernaussagen verdichten die Quellenlage. Statuskennzeichnung und Quellen-IDs stehen direkt an jeder Aussage; vollständige URLs und Daten folgen im Quellenregister.

Ein Prototyp beweist eine Möglichkeit, kein belastbares Produkt

LEBENSZYKLUSGRUNDSATZ: Ein Prototyp beantwortet typischerweise die Frage, ob ein Lösungsansatz grundsätzlich funktioniert. Produktionsreife verlangt zusätzlich definierte Anforderungen, Qualitätsziele, Betrieb, Sicherheit, Support, Wiederherstellung und kontrollierte Stilllegung. Der aktuelle Lebenszyklusstandard ISO/IEC/IEEE 12207:2026 behandelt Software deshalb über Entwicklung, Betrieb und Unterstützung hinweg. ^{[S-001; S-005; S-002]}

Produktionsreife ist risikobasiert und nicht binär

ARCHITEKTUR-SYNTHESE: Eine interne, reversible Hilfsfunktion braucht andere Kontrollen als ein öffentliches, zahlungswirksames oder personenbezogene Daten verarbeitendes System. Der erforderliche Nachweis muss sich aus Schadenspotenzial, Kritikalität, Reversibilität, Datenklasse, Nutzerzahl und regulatorischem Kontext ableiten. Ein pauschales Etikett „production ready“ ohne definierten Einsatzkontext ist daher inhaltsleer. ^{[S-006; S-025; S-004]}

Qualität besteht aus mehreren gleichzeitig zu steuernden Eigenschaften

STANDARDGRUNDLAGE: ISO/IEC 25010:2023 beschreibt neun Produktqualitätsmerkmale. Funktionale Eignung allein genügt nicht: Auch Leistung, Kompatibilität, Interaktionsfähigkeit, Zuverlässigkeit, Sicherheit, Wartbarkeit, Flexibilität und Safety können relevant sein. Ein System kann fachlich richtige Ergebnisse liefern und trotzdem wegen schlechter Wiederherstellbarkeit, unklarer Bedienung oder fehlender Zugriffskontrolle unbrauchbar sein. ^{[S-002; S-003; S-004]}

Anforderungen müssen prüfbar werden

ANFORDERUNGSGRUNDSATZ: Aussagen wie „schnell“, „intelligent“, „skalierbar“ oder „sicher“ sind keine belastbaren Abnahmekriterien. Anforderungen müssen beobachtbares Verhalten, Randbedingungen und Messverfahren festlegen. Für KI-Funktionen gehören neben fachlichen Ergebnissen auch zulässige Fehler, Abstention, menschliche Eskalation, Modell- und Datenversionen sowie Betriebsgrenzen in die Spezifikation. ^{[S-005; S-029; S-066; S-067]}

Nutzerwert und Systemgesundheit müssen getrennt gemessen werden

MESSGRUNDSATZ: Liefergeschwindigkeit, Codeaktivität oder Tokenverbrauch beweisen keinen Produktnutzen. Das SPACE-Modell warnt vor einer eindimensionalen Produktivitätsmessung; DORA trennt Durchsatz und Stabilität der Softwarelieferung. Produktive Systeme benötigen deshalb mindestens fachliche Erfolgsindikatoren, technische Serviceindikatoren und Risikosignale. ^{[S-009; S-012; S-010]}

KI verstärkt vorhandene Entwicklungs- und Organisationsbedingungen

EMPIRISCHER BEFUND: Der DORA-Bericht 2025 beschreibt KI im Softwareentwicklungsprozess als Verstärker: Starke Plattformen, kleine Änderungen, gute Feedbackschleifen und klare Prozesse profitieren; instabile oder schlecht kontrollierte Systeme können schneller mehr Probleme erzeugen. Der Einsatz generierter Artefakte ersetzt daher keine Engineering-Disziplin. ^{[S-010; S-011]}

Jedes produktive System braucht benannte Eigentümer

BETRIEBSGRUNDSATZ: Vor einem Produktivstart müssen fachliche, technische, Sicherheits-, Datenschutz- und Betriebsverantwortung zugeordnet sein. Ein Repository, Cloudkonto oder KI-API-Schlüssel ersetzt keine Eigentümerschaft. Incident Response und SRE-Praxis setzen voraus, dass Alarmierung, Entscheidungen, Kommunikation und Wiederherstellung klar zugewiesen sind. ^{[S-026; S-106; S-107]}

Versionsverwaltung ist die Grundlage kontrollierter Änderung

ENGINEERING-GRUNDSATZ: Versionsverwaltung hält Änderungen, Urheber, Zeitpunkte und frühere Zustände nachvollziehbar. Für produktive Arbeit gehören auch Infrastrukturcode, Datenbankschemata, Promptvorlagen, Eval-Datensätze, Policies und Konfigurationen soweit möglich in kontrollierte Versions- und Freigabeprozesse. ^{[S-017; S-016; S-022]}

Reviewregeln müssen technisch durchgesetzt werden

AKTUELLER PRODUKTSTAND: Geschützte Branches und erforderliche Statusprüfungen können direkte oder ungeprüfte Änderungen an kritischen Zweigen verhindern. Die konkrete Plattformfunktion ist veränderlich; das stabile Prinzip lautet, dass Freigaben, Tests und Herkunftsnachweise nicht nur als Teamabrede, sondern als technische Gate-Konfiguration umgesetzt werden. ^{[S-034; S-035; S-022]}

Kleine, reversible Änderungen reduzieren den Blast Radius

BETRIEBSSYNTHESE: Große Bündeländerungen erschweren Review, Ursachenanalyse und Rückkehr zum letzten stabilen Zustand. DORA- und SRE-Praktiken bevorzugen kleinere Änderungen und kontrollierte Einführung. Reversibilität ist dabei fachlich zu prüfen: Ein Code-Rollback kann bereits veränderte Daten, versandte E-Mails oder externe Zahlungen nicht automatisch rückgängig machen. ^{[S-012; S-103; S-108]}

Ein Build muss nachvollziehbar und möglichst reproduzierbar sein

LIEFERKETTENGRUNDSATZ: Ein reproduzierbarer Build erzeugt unter definierten Bedingungen aus identischen Eingaben identische Artefakte. Vollständige Reproduzierbarkeit ist nicht in jedem Projekt sofort erreichbar; mindestens müssen Quellrevision, Toolchain, Abhängigkeiten, Build-Anweisung und erzeugtes Artefakt eindeutig verknüpft sein. ^{[S-019; S-079; S-080]}

Einmal bauen, dasselbe Artefakt durch die Umgebungen fördern

RELEASEGRUNDSATZ: Die Trennung von Build, Release und Run verhindert, dass in Test und Produktion unbemerkt unterschiedliche Software entsteht. Umgebungsabhängige Konfiguration wird beim Release gebunden; das ausführbare Artefakt bleibt unverändert. Neu kompilieren oder neue Abhängigkeiten erst im Produktionsdeploy zu laden schwächt Nachweis und Vergleichbarkeit. ^{[S-014; S-079; S-069]}

Konfiguration und Geheimnisse gehören nicht in den Anwendungscode

SICHERHEITSGRUNDSATZ: Deploy-spezifische Konfiguration sollte vom Code getrennt sein. Geheimnisse wie API-Schlüssel, Datenbankpasswörter und Signaturschlüssel benötigen Inventar, minimale Rechte, Rotation, Redaction und sichere Bereitstellung. Sie dürfen weder im Repository noch in Prompts, Buildlogs oder Containerimages landen. ^{[S-015; S-053; S-038]}

Abhängigkeiten sind Teil des Produkts

WARTUNGSGRUNDSATZ: Bibliotheken, Basisimages, Actions, Modelle, SDKs und externe APIs verändern die Angriffs- und Ausfallfläche. Lockdateien und Digest-Pinning verbessern Wiederholbarkeit; SBOM, Provenienz und kontinuierliche Schwachstellenbewertung verbessern Transparenz. Automatische Updatevorschläge sind hilfreich, ersetzen aber keine Tests und Freigaben. ^{[S-069; S-079; S-082; S-083; S-132]}

Ein SBOM ist ein Inventar, kein Sicherheitsnachweis

SICHERHEITSGRUNDSATZ: Ein Software Bill of Materials dokumentiert Komponenten und Beziehungen. Es beweist weder die Abwesenheit von Schwachstellen noch sichere Konfiguration oder vertrauenswürdige Herkunft. Für KI-Systeme erweitert sich das Inventar gegebenenfalls um Modelle, Datensätze, Prompt- und Toolartefakte; die Semantik solcher AI-BOM-Ansätze entwickelt sich noch. ^{[S-084; S-082; S-083; S-085]}

Architekturentscheidungen müssen später erklärbar bleiben

DOKUMENTATIONSGRUNDSATZ: Architecture Decision Records dokumentieren Kontext, Entscheidung und Folgen. Das C4-Modell unterstützt eine abgestufte Sicht vom Systemkontext bis zu Komponenten. Ziel ist keine Dokumentenmenge, sondern eine aktuelle Erklärung von Grenzen, Datenflüssen, Abhängigkeiten, Vertrauenszonen und bewussten Kompromissen. ^{[S-020; S-021; S-007]}

Tests müssen mehrere Ebenen abdecken

TESTGRUNDSATZ: Kleine Tests liefern schnelle, lokalisierbare Rückmeldung; Integrations-, Vertrags- und End-to-End-Tests prüfen andere Fehlerklassen. Nur End-to-End zu testen ist langsam und diagnostisch schwach, nur Unit-Tests zu verwenden übersieht reale Schnittstellen und Infrastruktur. Die Gewichtung ist systemspezifisch. ^{[S-046; S-047; S-048]}

Schnittstellen brauchen explizite Verträge

STANDARDGRUNDLAGE: OpenAPI, JSON Schema, AsyncAPI und CloudEvents können Eingaben, Ausgaben und Ereignisse formal beschreiben. Verträge ermöglichen Validierung, Kompatibilitätsprüfung und unabhängige Tests. Ein formal gültiges Objekt kann weiterhin fachlich falsch oder unzulässig sein; Schemaprüfung ist nur eine Prüfebene. ^{[S-040; S-041; S-045; S-044]}

Fehler müssen maschinenlesbar und fachlich unterscheidbar sein

SCHNITTSTELLENGRUNDSATZ: HTTP definiert Methoden- und Statussemantik; RFC 9457 standardisiert Problem Details für HTTP APIs. Produktive Systeme sollten temporäre Fehler, fachliche Ablehnung, fehlende Berechtigung, Konflikt und ungültige Eingabe unterscheiden. Sonst wiederholen Orchestratoren permanente Fehler oder behandeln Teilerfolg als Erfolg. ^{[S-042; S-043; S-040]}

Sicherheitstests gehören in den Entwicklungszyklus

SECURE-SDLC-GRUNDSATZ: NIST SSDF 1.1 ist am Stichtag der finale allgemeine Rahmen; Version 1.2 liegt als Entwurf vor. OWASP ASVS 5.0 und WSTG liefern prüfbare Anwendungssicherheitsanforderungen und Testmethoden. Die Auswahl muss Bedrohungsmodell und Kritikalität folgen, nicht einem unreflektierten Vollständigkeitsritual. ^{[S-022; S-023; S-050; S-049]}

Generative Systeme brauchen Evals zusätzlich zu klassischen Tests

KI-TESTGRUNDSATZ: Deterministische Softwaretests prüfen definierte Eingaben und erwartete Ausgaben. Generative Systeme können mehrere akzeptable Antworten und probabilistische Schwankungen besitzen. Versionierte Eval-Sätze, klar definierte Kriterien, Fehlertaxonomien, wiederholte Läufe und gegebenenfalls menschliche Bewertung ergänzen deshalb Unit-, Integrations- und Sicherheitstests. ^{[S-066; S-067; S-029; S-065]}

Ein Eval-Datensatz muss reale Risiken und Randfälle enthalten

KI-EVALUATIONSSYNTHESE: Ein ausschließlich aus einfachen Erfolgsfällen bestehender Testsatz überschätzt die Qualität. Relevante Fälle umfassen typische Nutzung, seltene aber folgenreiche Randfälle, missverständliche Eingaben, fehlende Daten, bekannte Fehlermuster, Sicherheitsangriffe und bewusste Abstention. Datenherkunft, Version und Leckage in Trainingsdaten müssen dokumentiert werden. ^{[S-029; S-030; S-067; S-064]}

Offline-Evals und Online-Monitoring beantworten unterschiedliche Fragen

KI-BETRIEBSGRUNDSATZ: Vorabtests können Regressionen und bekannte Risiken messen. Im Betrieb entstehen jedoch andere Eingabeverteilungen, Nutzerstrategien, Provideränderungen und Fehlerketten. Online-Signale müssen fachliche Korrekturen, Eskalationen, Abbruch, Toolfehler, Latenz, Kosten und Sicherheitsereignisse sichtbar machen, ohne sensible Inhalte unnötig zu protokollieren. ^{[S-061; S-116; S-029; S-054]}

Modelle, Prompts, Tools und Datenstände müssen gemeinsam versioniert werden

KI-REPRODUZIERBARKEIT: Die Modellbezeichnung allein reproduziert kein Ergebnis. Auch Systemanweisung, Prompttemplate, Toolschema, Retrievalindex, Embeddingmodell, Kontextaufbereitung, Samplingparameter, Policy- und Anwendungsversion beeinflussen das Verhalten. Telemetrie und Releaseprotokolle müssen diese Kombination ausreichend erfassen. ^{[S-063; S-064; S-116; S-134]}

Human-in-the-Loop ist nur wirksam, wenn der Mensch entscheiden kann

GOVERNANCE-SYNTHESE: Eine formale Freigabeschaltfläche bietet wenig Schutz, wenn Belege fehlen, Zeitdruck besteht oder die Oberfläche die KI-Ausgabe als Standard setzt. Für folgenreiche Aktionen braucht der Prüfer verständliche Evidenz, eine echte Ablehnungsoption, klare Verantwortung und genügend Zeit. Wiederholtes blindes Bestätigen ist kein wirksamer Kontrollmechanismus. ^{[S-029; S-102; S-004]}

CI-Gates müssen schnell, stabil und risikoorientiert sein

CI/CD-GRUNDSATZ: Ein Commit- oder Pull-Request-Gate sollte mindestens Build, relevante Tests, statische Prüfungen, Geheimniserkennung und Vertragsvalidierung ausführen. Langsame oder fragile Gates werden umgangen. Umfangreiche Last-, Sicherheits- und KI-Evals können nach Risiko gestaffelt oder vor einem Release ausgeführt werden; kritische Kriterien dürfen nicht nur informativ sein. ^{[S-035; S-036; S-022; S-049]}

CI/CD selbst ist eine privilegierte Produktionskomponente

LIEFERKETTENSICHERHEIT: Workflows können Quellcode, Signaturschlüssel, Cloudrechte und Deploymentziele erreichen. Drittanbieter-Actions, untrusted Pull Requests, weitreichende Tokens und ungeschützte Runner sind deshalb Lieferkettenrisiken. Kurzlebige föderierte Identitäten, minimale Berechtigungen, Pinning und geschützte Umgebungen reduzieren die Angriffsfläche. ^{[S-036; S-038; S-037; S-147]}

Artefaktherkunft kann attestiert, aber nicht herbeigeprüft werden

LIEFERKETTENGRUNDSATZ: SLSA 1.2, in-toto und Sigstore liefern Bausteine für Provenienz und verifizierbare Lieferketten. Ein signiertes oder attestiertes Artefakt ist nur so vertrauenswürdig wie Buildsystem, Identität, Policy und verifizierte Aussage. Herkunftsnachweis beantwortet nicht automatisch, ob der Inhalt sicher oder fachlich korrekt ist. ^{[S-079; S-080; S-081]}

Umgebungen müssen getrennt, aber vergleichbar sein

BETRIEBSGRUNDSATZ: Entwicklung, Test, Staging und Produktion benötigen getrennte Daten, Identitäten und Rechte. Gleichzeitig sollten Laufzeit, Artefakt und wesentliche Infrastruktur vergleichbar sein, damit Tests aussagekräftig bleiben. Produktionsdaten dürfen nicht ungeprüft in Entwicklungsumgebungen kopiert werden. ^{[S-013; S-037; S-149; S-022]}

Infrastructure as Code schafft Nachvollziehbarkeit, nicht automatisch Richtigkeit

INFRASTRUKTURGRUNDSATZ: Deklarative Infrastrukturkonfiguration ermöglicht Review, Versionierung und wiederholbare Änderungen. Fehlkonfiguration, Drift, Geheimnisse und gefährliche Löschoperationen bleiben möglich. Planprüfung, Policy-Gates, getrennte Zustände, Backup und kontrollierte Rechte sind weiterhin erforderlich. ^{[S-078; S-077; S-148]}

Container lösen weder Architektur noch Betrieb

BETRIEBSSYNTHESE: Container verpacken Prozesse und Abhängigkeiten, doch sie garantieren keine Sicherheit, Persistenz, Skalierung, Beobachtbarkeit oder Wiederherstellung. Gute Images sind klein, deterministisch, nicht privilegiert und eindeutig referenziert. Der Betrieb braucht zusätzlich Netzwerk-, Secret-, Storage-, Health- und Rolloutkonzepte. ^{[S-068; S-069; S-070; S-071]}

Readiness, Liveness und Startup prüfen unterschiedliche Zustände

AKTUELLER PRODUKTSTAND: Kubernetes unterscheidet Bereitschaft zur Verkehrsannahme, fortdauernde Lebensfähigkeit und langsamen Start. Falsch konfigurierte Probes können gesunde Prozesse neu starten oder fehlerhafte Instanzen im Verkehr halten. Eine Probe sollte den Zustand messen, den der Orchestrator tatsächlich behandeln kann. ^{[S-073; S-071]}

Rolling Deployment ist keine vollständige Risikokontrolle

RELEASEGRUNDSATZ: Ein Rolling Update ersetzt Instanzen schrittweise, kann aber einen fachlichen Fehler trotzdem vollständig ausrollen. Progressive Delivery mit kleinem Traffic-Anteil, messbaren Guardrails und automatischer oder manueller Promotion begrenzt die Exposition. Voraussetzung sind kompatible Versionen und aussagekräftige Telemetrie. ^{[S-072; S-076; S-103]}

Feature Flags trennen Deployment und Freigabe

RELEASEGRUNDSATZ: Feature Flags erlauben, Code bereitzustellen, ohne ihn sofort für alle Nutzer zu aktivieren. Sie unterstützen Pilotgruppen, Kill Switches und schrittweise Einführung. Dauerhafte, unübersichtliche Flags erzeugen jedoch zusätzliche Zustände und technische Schulden; Eigentümer, Ablaufdatum und Entfernung müssen festgelegt sein. ^{[S-075; S-103; S-012]}

Datenbankschema und Anwendung müssen übergangsweise kompatibel sein

MIGRATIONSGRUNDSATZ: Bei laufenden Systemen werden Anwendungsversionen und Datenmigration selten atomar gleichzeitig wirksam. Das Expand-and-Contract-Muster führt zunächst additive, rückwärtskompatible Änderungen ein, migriert oder befüllt Daten, schaltet Leser und Schreiber kontrolliert um und entfernt Altstrukturen erst später. ^{[S-126; S-127; S-128]}

Rollback endet an irreversiblen Nebenwirkungen

MIGRATIONSGRUNDSATZ: Eine alte Binärversion kann nach einer destruktiven Schemamigration, extern versandten Nachricht, Zahlung oder unwiderruflichen Datenänderung nicht den ursprünglichen Gesamtzustand herstellen. Releases benötigen daher explizite Rollback-, Roll-forward- und Kompensationspläne. Besonders Datenmigrationen müssen vorab mit realistischen Volumina getestet werden. ^{[S-108; S-127; S-093]}

Timeouts begrenzen Warten und Ressourcenbindung

RELIABILITY-GRUNDSATZ: Jeder externe Aufruf kann langsam oder unerreichbar werden. Ohne Timeouts stauen sich Threads, Verbindungen und Queue-Arbeit. Timeoutwerte müssen End-to-End-Budget, normale Latenzverteilung und mögliche Wiederholungen berücksichtigen; zu aggressive Werte erzeugen selbst zusätzliche Fehler. ^{[S-092; S-098; S-104]}

Retries müssen begrenzt, gestreut und zustandsbewusst sein

RELIABILITY-GRUNDSATZ: Wiederholungen helfen bei vorübergehenden Fehlern, können aber Überlastung verstärken und Seiteneffekte duplizieren. Exponentielles Backoff, Jitter, Versuchslimits und Fehlerklassifikation sind grundlegende Kontrollen. Nicht jede Ebene einer Aufrufkette sollte unabhängig aggressiv wiederholen. ^{[S-092; S-098]}

Idempotenz schützt vor doppelten Nebenwirkungen

RELIABILITY-GRUNDSATZ: Netzwerkabbrüche lassen offen, ob ein Server eine Aktion bereits ausgeführt hat. Idempotency Keys oder fachlich eindeutige Operationen ermöglichen eine sichere Wiederholung, ohne Bestellung, Zahlung oder Nachricht doppelt anzulegen. Schlüsselbereich, Aufbewahrung und Antwortwiederholung müssen definiert sein. ^{[S-093; S-094; S-042]}

Circuit Breaker und Bulkhead begrenzen Kaskaden

RELIABILITY-GRUNDSATZ: Ein Circuit Breaker stoppt zeitweise aussichtslose Aufrufe; Bulkheads trennen Ressourcenpools, damit ein fehlerhafter Dienst nicht alles blockiert. Beide Muster erfordern messbare Zustände, Rückkehrlogik und verständliches Fallback. Sie heilen keinen fachlich falschen Dienst. ^{[S-098; S-099]}

Queues liefern Entkopplung, aber keine magische Exactly-once-Wirkung

MESSAGING-GRUNDSATZ: Nachrichten können je nach Broker und Fehlerzeitpunkt erneut zugestellt, verspätet oder in anderer Reihenfolge verarbeitet werden. Acknowledgements, Consumer-Zustand und Transaktionen beeinflussen die Semantik. Verbraucher müssen Duplikate, Poison Messages und partielle Side Effects behandeln. ^{[S-095; S-096; S-093]}

Durable Workflows machen langen Zustand explizit

WORKFLOW-GRUNDSATZ: Mehrstufige Prozesse mit Wartezeiten, Freigaben und externen Diensten benötigen persistierten Ablaufzustand. Durable-Execution-Systeme können nach Prozessabsturz fortsetzen; Activities und Side Effects müssen dennoch timeout-, retry- und idempotenzsicher entworfen sein. Eine Workflow Engine ersetzt keine fachliche Zustandsmaschine. ^{[S-097; S-093; S-107]}

Kapazität wird aus Nachfrage, SLO und Engpässen geplant

KAPAZITÄTSGRUNDSATZ: Autoscaling reagiert auf beobachtete Signale und besitzt Verzögerungen, Mindest- und Maximalgrenzen. Datenbanken, externe APIs, Rate Limits und Modellkontingente können trotz skalierender Frontends Engpässe bleiben. Lasttests müssen typische, Spitzen- und Ausfallmodi sowie Queue-Aufbau berücksichtigen. ^{[S-074; S-135; S-137; S-104]}

Observability beginnt am Nutzerpfad

OBSERVABILITY-GRUNDSATZ: Metriken, Logs und Traces haben unterschiedliche Rollen. Ein End-to-End-Trace verbindet Request, Datenbank, Queue, Modell, Tool und Antwort; Metriken zeigen Verteilungen und Trends; Logs erklären konkrete Ereignisse. Telemetrie muss aus den zu steuernden Nutzer- und Betriebsfragen abgeleitet werden. ^{[S-110; S-111; S-112; S-113]}

Kontextweitergabe ist Voraussetzung für verteilte Ursachenanalyse

STANDARDGRUNDLAGE: W3C Trace Context und OpenTelemetry-Kontextmechanismen tragen Korrelationsinformationen über Prozess- und Dienstgrenzen. Ohne konsistente Weitergabe entstehen isolierte Logzeilen und unvollständige Traces. Sicherheitsgrenzen müssen verhindern, dass untrusted Kontext ungeprüft für Autorisierung oder sensible Metadaten genutzt wird. ^{[S-117; S-114; S-111]}

KI-Telemetrie ist noch in Bewegung

AKTUELLER STANDARDSTAND: OpenTelemetry entwickelt semantische Konventionen für generative KI weiter; einzelne Signal- und Attributstände können experimentell sein. Produktionssysteme sollten eigene stabile interne Felder, Schema- und Instrumentierungsversionen verwenden, statt sich unbemerkt an eine veränderliche Anbieterstruktur zu koppeln. ^{[S-116; S-110; S-115]}

Logs dürfen keine Schattenkopie sensibler Daten erzeugen

DATENSCHUTZGRUNDSATZ: Prompts, Dokumente, Tokens, Sessiondaten und Toolargumente können personenbezogene oder vertrauliche Informationen enthalten. Logging braucht Zweck, Datenminimierung, Zugriffsschutz, Redaction, Aufbewahrung und Löschregeln. Ein vollständiger Prompt in jedem Debugtrace ist keine neutrale technische Entscheidung. ^{[S-054; S-149; S-116]}

SLI, SLO und Error Budget verbinden Technik und Geschäftsrisiko

SRE-GRUNDSATZ: Ein Service Level Indicator misst ein Nutzermerkmal wie erfolgreiche, rechtzeitige Antworten. Das Service Level Objective setzt ein Ziel; das Error Budget beschreibt den zulässigen Fehlraum. Diese Logik kann Releasegeschwindigkeit gegen Zuverlässigkeit steuern, sofern Messung und Ziel wirklich den Nutzerpfad abbilden. ^{[S-104; S-101; S-105]}

Alarmierung muss Handlungen auslösen

SRE-GRUNDSATZ: Alarme sollten Symptome mit Nutzerwirkung oder unmittelbar gefährliche Zustände adressieren und eine bekannte Reaktion ermöglichen. Alarmflut, flüchtige Spitzen und nicht verantwortete Warnungen erzeugen Müdigkeit. Runbook, Eigentümer, Eskalation und erwartete Diagnoseinformationen gehören zur Alarmdefinition. ^{[S-105; S-106; S-026]}

Backup ist erst nach erfolgreichem Restore belastbar

WIEDERHERSTELLUNGSGRUNDSATZ: Ein vorhandenes Backup beweist nicht, dass es vollständig, lesbar, aktuell und innerhalb des Zielzeitraums wiederherstellbar ist. GitLabs Datenbankausfall zeigte, dass mehrere nominelle Sicherungswege versagen können. Wiederherstellung muss regelmäßig in einer isolierten Umgebung geübt und protokolliert werden. ^{[S-122; S-140; S-028]}

RPO und RTO müssen konkret und getestet sein

NOTFALLGRUNDSATZ: Recovery Point Objective begrenzt den akzeptablen Datenverlustzeitraum; Recovery Time Objective begrenzt die Wiederherstellungszeit. Beide Werte ergeben sich aus Geschäftsfolgen und Architektur. Point-in-Time-Recovery, Replikation und Dumps decken unterschiedliche Szenarien ab und müssen gegen definierte Ziele geprüft werden. ^{[S-028; S-123; S-124; S-125]}

Replikation ist kein Schutz vor jeder logischen Beschädigung

DATENBETRIEBSGRUNDSATZ: Replikate können versehentliche Löschungen oder fehlerhafte Änderungen schnell übernehmen. Sie verbessern Verfügbarkeit und Failover, ersetzen aber keine unabhängigen, zeitlich zurücksetzbaren Sicherungen. Umgekehrt kann ein Dump allein für große Recovery-Ziele zu langsam sein. ^{[S-124; S-122; S-123]}

Vulnerability Management muss Ausnutzbarkeit und Kontext berücksichtigen

SICHERHEITSGRUNDSATZ: CVSS bewertet technische Schwere, während der CISA-KEV-Katalog bekannte aktive Ausnutzung signalisiert. Priorisierung braucht zusätzlich Erreichbarkeit, Datenwert, verfügbare Gegenmaßnahmen, Komponentenrolle und Exposition. Ein hoher Score ohne erreichbaren Pfad kann weniger dringend sein als eine tatsächlich ausgenutzte mittlere Schwachstelle. ^{[S-130; S-131; S-129]}

Automatisierte Abhängigkeitsupdates brauchen gestaffelte Kontrolle

WARTUNGSGRUNDSATZ: Dependabot und Renovate können veraltete oder verwundbare Abhängigkeiten erkennen und Änderungsvorschläge erzeugen. Automatisches Mergen ist nur dort vertretbar, wo Versionierung, Vertrauensquelle, Tests, Rollback und Auswirkungsbereich passen. Große Versionssprünge und Laufzeitabhängigkeiten verlangen stärkere Prüfung. ^{[S-132; S-133; S-018]}

Provider- und Modellabkündigungen sind planbare Betriebsereignisse

AKTUELLER PRODUKTSTAND: KI-Anbieter veröffentlichen Modell- und API-Abkündigungen mit unterschiedlichen Fristen. Ein produktives System benötigt Inventar, Eigentümer, Benachrichtigung, Ersatzmodell-Evals, Migrationsfenster und Rollback. Ein Modellalias ohne festgehaltene Version kann Verhalten ändern, ohne dass der eigene Anwendungscode geändert wurde. ^{[S-134; S-136; S-138]}

Rate Limits und Kontingente sind Teil der Architektur

AKTUELLER PRODUKTSTAND: Provider begrenzen Requests, Tokens oder andere Ressourcen nach Konto und Modell. Lastspitzen, parallele Batchjobs und Retry-Stürme können die Grenze treffen. Queueing, Backpressure, Prioritäten, Fallback und ein kontrolliertes Fehlverhalten müssen vor dem Produktivstart getestet werden. ^{[S-135; S-137; S-100; S-092]}

Ein Fallback ist nur nach eigenem Test ein Fallback

KI-BETRIEBSSYNTHESE: Ein anderes Modell oder ein zweiter Provider kann abweichende Schemata, Sicherheitsregeln, Toolsemantik, Qualität, Kosten und Latenz besitzen. Blindes Umschalten kann fachlich schlechter sein als eine transparente Nichtverfügbarkeit. Jede Route benötigt Vertrags-, Sicherheits- und Qualitätsevals. ^{[S-066; S-067; S-134; S-029]}

Incident Response beginnt vor dem ersten Incident

BETRIEBSGRUNDSATZ: Kontakte, Rollen, Eskalationswege, Kommunikationskanäle, Logzugriff, Notfallrechte und Wiederherstellungsverfahren müssen vorbereitet sein. NIST SP 800-61 Rev. 3 bindet Incident Response in das laufende Cyber-Risikomanagement ein; SRE-Praxis ergänzt On-Call, Runbooks und strukturierte Koordination. ^{[S-026; S-106; S-107]}

Post-Mortems müssen Ursachenketten und Maßnahmen adressieren

LERNGRUNDSATZ: Ein einzelner menschlicher Fehler erklärt komplexe Ausfälle selten ausreichend. Gute Analysen betrachten technische Schutzbarrieren, Rollout, Berechtigungen, Tests, Alarmierung und organisatorische Bedingungen. Maßnahmen benötigen Eigentümer, Termin und Wirksamkeitsnachweis; sonst bleibt das Dokument folgenlos. ^{[S-107; S-139; S-142; S-144]}

Runbooks müssen mit dem System altern

BETRIEBSGRUNDSATZ: Ein Runbook beschreibt Diagnose, sichere Eingriffe, Eskalation und Rückkehr zum Normalbetrieb. Es ist nur nützlich, wenn Befehle, Rechte, Kontakte und Annahmen noch stimmen. Übungen, echte Incidents und Architekturänderungen müssen daher in seine Pflege zurückfließen. ^{[S-106; S-028; S-001]}

Wartung und Stilllegung sind Produktarbeit

LEBENSZYKLUSGRUNDSATZ: Abhängigkeiten, Zertifikate, Domains, Datenbanken, Modelle und APIs verändern sich auch ohne neue Fachfunktion. Der Lebenszyklus umfasst Korrektur, Anpassung, Überwachung und geordnete Stilllegung. Dabei müssen Datenexport, Aufbewahrung, Löschung, Widerruf von Credentials und Abschaltung von Integrationen geplant sein. ^{[S-001; S-007; S-149; S-134]}

KI-generierter Code unterliegt denselben oder strengeren Gates

ENGINEERING-GRUNDSATZ: Die Herkunft aus einem Coding Agent ändert nichts an Verantwortung, Lizenz-, Sicherheits-, Test- oder Betriebsanforderungen. Hohe Generierungsgeschwindigkeit kann Review- und Testkapazität überholen. Kritische Komponenten brauchen nachvollziehbare Anforderungen, menschliche Prüfung und automatisierte Nachweise unabhängig davon, wer den Text erzeugt hat. ^{[S-010; S-024; S-022; S-008]}

Produktion ist ein laufender Regelkreis, kein Zieltermin

GESAMTSYNTHESE: Der Produktivstart ist der Beginn realer Beobachtung. Nutzerverhalten, Last, Daten, Angriffe, Anbieteränderungen und Organisationsprozesse verändern das System. Belastbarer Betrieb verbindet Telemetrie, SLO, Feedback, Incident-Lernen, Wartung, sichere Releases und regelmäßige Neubewertung des Nutzens. ^{[S-001; S-101; S-010; S-025]}

Produktionskapitel: 27 Arbeitsfelder

``mermaid flowchart LR A[Commit] --> B[Build] B --> C[Tests und Evals] C --> D[SBOM und Provenienz] D --> E[Staging] E --> F[Canary] F --> G[Produktion] G --> H[Lernen und Wartung] ``

Problem, Nutzen und Abnahmekriterien

PRAXIS- UND QUELLENSYNTHESE: Die erste Produktionsentscheidung ist nicht die Wahl von Framework oder Modell, sondern die Frage, welches beobachtbare Problem für wen gelöst werden soll und woran Erfolg, Fehler und Abbruch erkannt werden. ^{[S-005; S-004; S-029]}

Prinzipien

• Ist-Zustand und Baseline festhalten: Bearbeitungszeit, Fehlerquote, Durchsatz, Kosten, Eskalationen oder Nutzerabbrüche. ^{[S-005; S-009]}
• Fachliche Zielgröße von technischer Metrik trennen. Eine niedrige API-Latenz beweist noch keine richtige Entscheidung. ^{[S-004; S-012]}
• Für jede KI-Ausgabe zulässige Fehler, Belegpflicht, Abstention und Eskalationsweg definieren. ^{[S-029; S-066]}
• Die einfachere regelbasierte oder klassische Softwarelösung als Vergleich aufnehmen. ^{[S-006; S-002]}

Mindestnachweise vor Produktivfreigabe

• Einseitige Problemdefinition mit Nutzer, Trigger, erwarteter Entscheidung und ausgeschlossenen Anwendungsfällen. ^[S-005]
• Messbare Akzeptanzkriterien und ein benannter fachlicher Abnehmer. ^{[S-005; S-003]}
• Risiko- und Datenklassifizierung vor Zugriff auf reale Daten. ^{[S-006; S-149]}

Rote Flaggen

• „Die KI soll alles können“ oder Erfolg wird nur an einer überzeugenden Demo gemessen. ^[S-029]
• Keine Baseline; Nutzen wird nach dem Start durch ausgewählte Einzelfälle behauptet. ^[S-009]
• Die Lösung erzeugt irreversible Wirkungen, ohne dass Fehlergrenzen beschrieben sind. ^[S-006]

Erwartete Artefakte

Kritikalität, Risiko und Freigabestufe

PRAXIS- UND QUELLENSYNTHESE: Produktionsreife muss aus dem konkreten Schaden abgeleitet werden. Nutzerzahl allein ist kein ausreichendes Maß: Ein einzelner fehlerhafter Zahlungslauf kann kritischer sein als tausend unverbindliche Zusammenfassungen. ^{[S-006; S-025; S-102]}

Prinzipien

• Schaden nach Vertraulichkeit, Integrität, Verfügbarkeit, finanzieller Wirkung, Rechtsfolge, Safety und Reputation betrachten. ^{[S-006; S-025]}
• Reversibilität und Erkennbarkeit gesondert bewerten: Ein sichtbarer Entwurf ist leichter kontrollierbar als eine unbemerkte Datenänderung. ^{[S-029; S-102]}
• Höhere Kritikalität verlangt stärkere Nachweise, strengere Freigabe und belastbareren Notbetrieb. ^{[S-033; S-028]}
• Rechtliche Pflichten, etwa Datenschutz und AI Act, werden als eigener Prüfstrang geführt und nicht durch technische Tests ersetzt. ^{[S-149; S-150]}

Mindestnachweise vor Produktivfreigabe

• Risikoregister mit Szenario, Wahrscheinlichkeit, Auswirkung, Kontrolle, Restrisiko und Eigentümer. ^[S-006]
• Freigabematrix für Test, Pilot, Produktion und kritische Funktionen. ^{[S-102; S-022]}
• Explizite Liste irreversibler Side Effects und erforderlicher Freigaben. ^{[S-093; S-029]}

Rote Flaggen

• „Nur intern“ wird als pauschale Begründung für fehlende Sicherheit verwendet. ^[S-025]
• Ein Admin-Schlüssel wird für alle Nutzer und Mandanten eingesetzt. ^{[S-055; S-053]}
• Regulatorische Einordnung erfolgt erst nach dem Launch. ^{[S-149; S-150]}

Erwartete Artefakte

Eigentümerschaft, Rollen und Entscheidungswege

PRAXIS- UND QUELLENSYNTHESE: Ein System ist nicht betreibbar, wenn niemand verbindlich über Funktion, Daten, Sicherheit, Kosten, Störung und Abschaltung entscheidet. ^{[S-001; S-026; S-106]}

Prinzipien

• Produktverantwortung, technische Verantwortung und Betriebsverantwortung können verteilt sein, müssen aber namentlich zugeordnet werden. ^{[S-001; S-106]}
• Freigabe und Notfallrechte werden vorab dokumentiert; im Incident dürfen sie nicht erst gesucht werden. ^{[S-026; S-107]}
• Externe Dienstleister ändern nichts an der eigenen Verantwortungs- und Kontrollpflicht. ^{[S-022; S-145]}
• Vertretung, Offboarding und Übergabe sind Teil der Rollenplanung. ^{[S-007; S-033]}

Mindestnachweise vor Produktivfreigabe

• RACI oder vergleichbare Zuordnung für Produkt, Code, Infrastruktur, Daten, Security, Datenschutz, Support und Incident. ^[S-001]
• On-Call- und Eskalationsliste mit funktionierenden Kontakten. ^[S-106]
• Entscheidungsprotokoll für Go-live, Stop, Rollback und Datenwiederherstellung. ^{[S-102; S-028]}

Rote Flaggen

• Das System gehört „dem Entwickler“, der zugleich alleinigen Produktionszugang besitzt. ^{[S-106; S-022]}
• Ein ausscheidender Mitarbeiter besitzt persönliche Cloud-, Domain- oder API-Konten. ^{[S-053; S-033]}
• Support und Incident-Kommunikation sind nicht eingeplant. ^[S-026]

Erwartete Artefakte

Repository, Branches und nachvollziehbare Änderungen

PRAXIS- UND QUELLENSYNTHESE: Das Repository ist die überprüfbare Quelle für Softwareänderungen. Es muss nicht nur Code, sondern auch die für Build, Test und Betrieb relevanten Artefakte kontrolliert führen. ^{[S-016; S-034; S-035]}

Prinzipien

• Commits sind klein, verständlich und einer Anforderung oder Fehlerursache zuordenbar. ^{[S-016; S-012]}
• Kritische Branches verlangen Review und erfolgreiche Checks. ^{[S-034; S-035]}
• Generated Code wird nicht anders behandelt als handgeschriebener Code. ^{[S-024; S-010]}
• Binärdateien, Datenexporte und Secrets gehören nicht unkontrolliert in die Historie. ^{[S-053; S-149]}

Mindestnachweise vor Produktivfreigabe

• Repository mit README, Lizenz-/Rechteklärung, Build- und Testanweisung. ^{[S-016; S-007]}
• Geschützter Hauptbranch, Reviewpflicht und dokumentierte Ausnahmeprozedur. ^[S-034]
• CODEOWNERS oder gleichwertige fachliche Zuständigkeit für kritische Bereiche. ^{[S-034; S-022]}

Rote Flaggen

• Produktionsänderungen werden direkt auf dem Server vorgenommen. ^{[S-014; S-017]}
• „Final_final2.zip“ ist die einzige Versionshistorie. ^[S-017]
• Der Coding Agent darf selbständig in Produktion mergen. ^{[S-024; S-037]}

Erwartete Artefakte

Entwicklungsumgebung und reproduzierbarer Build

PRAXIS- UND QUELLENSYNTHESE: „Funktioniert auf meinem Rechner“ ist kein übertragbarer Nachweis. Toolchain, Abhängigkeiten und Buildschritte müssen für andere Personen und automatisierte Systeme nachvollziehbar sein. ^{[S-019; S-079; S-014]}

Prinzipien

• Versionen von Laufzeit, Paketmanager, Compiler und Systemabhängigkeiten festhalten. ^{[S-019; S-079]}
• Abhängigkeiten sperren und aus vertrauenswürdigen Quellen beziehen. ^{[S-068; S-087]}
• Build nicht von zufälligem lokalen Zustand, persönlichen Pfaden oder unversionierten Dateien abhängig machen. ^{[S-019; S-014]}
• Buildartefakt eindeutig mit Commit, Pipeline und Provenienz verknüpfen. ^{[S-080; S-081; S-039]}

Mindestnachweise vor Produktivfreigabe

• Ein dokumentierter, automatisierbarer Buildbefehl auf einer sauberen Umgebung. ^[S-019]
• Lockdateien beziehungsweise Digest-Pinning für relevante Abhängigkeiten. ^{[S-069; S-018]}
• CI erzeugt das gleiche auslieferbare Artefakt wie lokal vorgesehen. ^{[S-035; S-014]}

Rote Flaggen

• Pakete werden im Produktionsstart ohne Pinning nachinstalliert. ^[S-069]
• Ein lokales, nicht dokumentiertes Modell oder Datenfile ist zwingend erforderlich. ^{[S-064; S-063]}
• Builds sind nicht einem Commit zuordenbar. ^[S-079]

Erwartete Artefakte

Konfiguration, Secrets und Identitäten

PRAXIS- UND QUELLENSYNTHESE: Konfiguration steuert das Verhalten einer ansonsten identischen Anwendung. Geheimnisse und Dienstidentitäten brauchen einen eigenen Lebenszyklus. ^{[S-015; S-053; S-038]}

Prinzipien

• Code, nicht geheime Konfiguration und Geheimnisse logisch trennen. ^{[S-015; S-053]}
• Jede Umgebung nutzt eigene Konten, Schlüssel und Datenbankrechte. ^{[S-037; S-055]}
• Kurzlebige, föderierte Workload-Identitäten sind statischen Cloudschlüsseln vorzuziehen, sofern Plattform und Risiko passen. ^[S-038]
• Rotation und Widerruf müssen ohne Quellcodeänderung möglich sein. ^{[S-053; S-025]}

Mindestnachweise vor Produktivfreigabe

• Secret-Inventar mit Eigentümer, Zweck, Scope, Umgebung und Rotation. ^[S-053]
• Keine Secrets in Repository, Image, Prompt oder Log. ^{[S-053; S-054]}
• Minimal berechtigte Laufzeit- und Deploymentidentitäten. ^{[S-022; S-038]}

Rote Flaggen

• Eine .env-Datei wird per Messenger weitergegeben. ^[S-053]
• Entwicklung und Produktion teilen denselben API-Schlüssel. ^[S-037]
• Der KI-Provider erhält unkontrolliert interne Zugangsdaten im Kontext. ^{[S-056; S-053]}

Erwartete Artefakte

Architektur, Grenzen und Datenflüsse

PRAXIS- UND QUELLENSYNTHESE: Eine produktive Architektur muss erklären, welche Komponenten existieren, welchen Vertrauensgrenzen sie unterliegen und wie Daten und Entscheidungen fließen. ^{[S-021; S-020; S-102]}

Prinzipien

• Systemkontext, Container/Dienste und kritische Komponenten in angemessener Tiefe darstellen. ^[S-021]
• Wesentliche Entscheidungen mit Kontext und Folgen dokumentieren. ^[S-020]
• Single Points of Failure, externe Abhängigkeiten und System of Record sichtbar machen. ^{[S-102; S-006]}
• KI-Komponente als Teil einer klassischen Systemarchitektur modellieren, nicht als unsichtbare Blackbox. ^{[S-058; S-029]}

Mindestnachweise vor Produktivfreigabe

• Kontext- und Containerdiagramm mit Datenflüssen und Vertrauenszonen. ^{[S-021; S-025]}
• ADRs für Datenhaltung, Providerwahl, Mandantentrennung, Queueing und Deployment. ^[S-020]
• Inventar externer Dienste einschließlich Ausfall- und Exit-Verhalten. ^{[S-102; S-134]}

Rote Flaggen

• Die Architektur ist nur im Kopf einer Person vorhanden. ^[S-007]
• Es ist unklar, welches System verbindliche Fachdaten hält. ^[S-108]
• Alle Komponenten besitzen pauschalen Datenbank-Adminzugriff. ^[S-055]

Erwartete Artefakte

Teststrategie für klassische Software

PRAXIS- UND QUELLENSYNTHESE: Tests sind ein Portfolioproblem: verschiedene Ebenen liefern unterschiedliche Geschwindigkeit, Realitätsnähe und Diagnosefähigkeit. ^{[S-046; S-047; S-048]}

Prinzipien

• Viele schnelle, isolierte Tests für Logik; gezielte Integrations- und Vertragstests für Grenzen; wenige kritische End-to-End-Pfade. ^{[S-046; S-047]}
• Fehlerfälle, Zeitüberschreitungen, konkurrierende Änderungen und Berechtigungsgrenzen explizit prüfen. ^{[S-050; S-092]}
• Tests müssen deterministisch genug sein, um als Gate zu dienen; Flakiness wird als Defekt behandelt. ^{[S-035; S-012]}
• Testdaten sind versioniert und datenschutzgerecht. ^{[S-149; S-064]}

Mindestnachweise vor Produktivfreigabe

• Testplan mit Ebenen, Verantwortlichen, Daten und Ausführungshäufigkeit. ^[S-046]
• Automatisierte Regression der kritischen Nutzerpfade. ^[S-047]
• Vertragstests für externe und interne APIs. ^{[S-048; S-040]}

Rote Flaggen

• Ein erfolgreicher manueller Klicktest gilt als vollständige Abnahme. ^[S-047]
• End-to-End-Tests sind so instabil, dass Fehler regelmäßig ignoriert werden. ^[S-012]
• Tests laufen nur lokal beim ursprünglichen Entwickler. ^[S-035]

Erwartete Artefakte

Evaluation generativer KI

PRAXIS- UND QUELLENSYNTHESE: Generative Komponenten benötigen messbare Qualitätsdefinitionen. Ein einzelner „sieht gut aus“-Test ist weder reproduzierbar noch ausreichend für Modell-, Prompt- oder Retrievaländerungen. ^{[S-066; S-067; S-029]}

Prinzipien

• Aufgaben in bewertbare Dimensionen zerlegen: Korrektheit, Vollständigkeit, Belege, Format, Sicherheit, Abstention und Kosten/Latenz. ^{[S-066; S-067]}
• Goldenset und Fehlertaxonomie aus realen Fällen, Randfällen und Angriffen bilden. ^{[S-029; S-030]}
• Automatische Judges kalibrieren und bei wichtigen Kriterien menschlich gegenprüfen. ^{[S-067; S-065]}
• Modell-, Prompt-, Tool-, Daten- und Indexversion mit jedem Lauf speichern. ^{[S-063; S-064; S-116]}

Mindestnachweise vor Produktivfreigabe

• Versionierter Eval-Satz mit Herkunft, Zweck und Split. ^{[S-064; S-066]}
• Akzeptanzschwellen und harte Ausschlusskriterien. ^[S-029]
• Regressionvergleich gegen das aktuell produktive System. ^{[S-067; S-059]}
• Separate Sicherheits- und Prompt-Injection-Prüfung. ^{[S-056; S-057]}

Rote Flaggen

• Das Modell bewertet ausschließlich seine eigene Antwort. ^[S-067]
• Nur durchschnittliche Qualität wird betrachtet; kritische Fehlertypen verschwinden im Mittel. ^[S-029]
• Produktionsprompt wird geändert, ohne Evals erneut auszuführen. ^[S-066]

Erwartete Artefakte

CI-Pipeline und Qualitätsgates

PRAXIS- UND QUELLENSYNTHESE: Continuous Integration führt Änderungen regelmäßig zusammen und prüft sie automatisiert. Ein Gate muss verlässlich genug sein, um schlechte Änderungen tatsächlich zu stoppen. ^{[S-035; S-036; S-022]}

Prinzipien

• Schnelle Checks früh, teure und systemspezifische Prüfungen gestaffelt ausführen. ^{[S-035; S-046]}
• Build, Tests, Linting, Typprüfung, Schema-, Secret- und Dependencyprüfungen automatisieren. ^{[S-022; S-053; S-129]}
• Für KI-Änderungen risikobasierte Evals und Sicherheitsfälle ergänzen. ^{[S-024; S-066]}
• Pipelineänderungen selbst reviewen und privilegierte Schritte isolieren. ^{[S-036; S-079]}

Mindestnachweise vor Produktivfreigabe

• Required Checks für den Hauptbranch. ^{[S-035; S-034]}
• Artefakt wird in CI erzeugt, versioniert und unveränderlich gespeichert. ^{[S-014; S-079]}
• Pipelinefehler besitzen Eigentümer und dürfen nicht dauerhaft übersprungen werden. ^[S-012]

Rote Flaggen

• Tests werden vor dem Merge regelmäßig mit Admin-Ausnahme umgangen. ^[S-034]
• CI hat dauerhafte Administrator-Credentials für die Cloud. ^[S-038]
• Untrusted Pull Requests können Secrets lesen oder produktive Runner ausführen. ^[S-036]

Erwartete Artefakte

Artefakt, Provenienz und Softwarelieferkette

PRAXIS- UND QUELLENSYNTHESE: Produktionssoftware wird als überprüfbares Artefakt ausgeliefert. Herkunft, Bestandteile und Freigabeweg müssen nachvollziehbar sein. ^{[S-079; S-082; S-081]}

Prinzipien

• Image oder Paket über unveränderliche Digest-/Versionskennung referenzieren. ^{[S-069; S-070]}
• Buildprovenienz und Signatur an eine vertrauenswürdige Identität binden. ^{[S-079; S-081; S-080]}
• SBOM in einem interoperablen Format erzeugen und mit dem Artefakt verknüpfen. ^{[S-082; S-083; S-084]}
• Abhängigkeiten, Actions und Base Images kontinuierlich auf Schwachstellen und Abkündigung prüfen. ^{[S-129; S-131; S-132]}

Mindestnachweise vor Produktivfreigabe

• Unveränderliches Releaseartefakt mit Commit- und Pipelinebezug. ^[S-079]
• SBOM und Provenienz für freigegebene Releases. ^{[S-039; S-082]}
• Verifikationspolicy vor Deployment. ^{[S-081; S-080]}

Rote Flaggen

• Deployment verwendet das bewegliche Tag latest. ^[S-069]
• Produktionsimage wird manuell verändert. ^[S-014]
• Ein Drittanbieter-Skript wird ohne Pinning und Review in CI ausgeführt. ^{[S-147; S-036]}

Erwartete Artefakte

Umgebungen, Infrastruktur und Deploymentziel

PRAXIS- UND QUELLENSYNTHESE: Eine produktive Umgebung besteht aus mehr als einem Server. Netzwerk, Identitäten, Daten, Runtime, Konfiguration, Storage, DNS und Zertifikate müssen gemeinsam versioniert und betrieben werden. ^{[S-078; S-077; S-037]}

Prinzipien

• Entwicklungs-, Test- und Produktionskonten sowie Daten strikt trennen. ^{[S-037; S-149]}
• Infrastrukturänderungen über reviewbare Deklarationen und kontrollierte Ausführung steuern. ^{[S-078; S-077]}
• Drift und manuelle Notfalländerungen nachträglich erfassen. ^{[S-077; S-026]}
• Single Points of Failure und Providerabhängigkeit bewusst dokumentieren. ^{[S-102; S-006]}

Mindestnachweise vor Produktivfreigabe

• Infrastructure-as-Code oder gleichwertig dokumentierte, wiederholbare Bereitstellung. ^[S-078]
• Inventar von DNS, Zertifikaten, Netzwerken, Storage, Datenbanken und Cloudressourcen. ^[S-025]
• Getrennte Deploymentrechte und Auditspur. ^{[S-037; S-022]}

Rote Flaggen

• Produktionsressourcen werden ausschließlich über eine persönliche Konsole verwaltet. ^[S-033]
• Es existiert kein vollständiges Infrastrukturinventar. ^[S-025]
• Test und Produktion nutzen dieselbe Datenbank. ^{[S-149; S-037]}

Erwartete Artefakte

Release, Promotion und progressive Auslieferung

PRAXIS- UND QUELLENSYNTHESE: Deployment bringt Software in eine Umgebung; Release macht eine Funktion für Nutzer wirksam. Beide Vorgänge sollten getrennt steuerbar und beobachtbar sein. ^{[S-103; S-076; S-075]}

Prinzipien

• Dasselbe Artefakt von Staging nach Produktion fördern. ^[S-014]
• Änderungen schrittweise exponieren: interner Nutzer, Pilotgruppe, kleiner Traffic-Anteil, breiter Rollout. ^{[S-103; S-076]}
• Promotion an technische und fachliche Guardrails binden. ^{[S-104; S-066]}
• Feature Flags mit Eigentümer, Ablauf und Kill Switch führen. ^[S-075]

Mindestnachweise vor Produktivfreigabe

• Releaseplan mit Zielgruppe, Zeitfenster, Beobachtungszeit und Abbruchkriterien. ^[S-103]
• Automatisierter oder dokumentierter Rollback/Roll-forward. ^{[S-072; S-108]}
• Versionsanzeige und Releasejournal. ^{[S-018; S-007]}

Rote Flaggen

• Alle Nutzer erhalten eine große Änderung gleichzeitig. ^[S-103]
• Die einzige Rückfalloption ist ein Hotfix unter Zeitdruck. ^[S-107]
• Feature Flags bleiben ohne Eigentümer dauerhaft aktiv. ^[S-075]

Erwartete Artefakte

Datenbankmigration und Zustandsänderung

PRAXIS- UND QUELLENSYNTHESE: Daten sind langlebiger als einzelne Anwendungsversionen. Migrationen brauchen eigene Planung, Messung und Rückkehrstrategie. ^{[S-126; S-127; S-128]}

Prinzipien

• Additive, rückwärtskompatible Schritte vor destruktiven Änderungen. ^{[S-126; S-127]}
• Schemaänderung, Backfill, Umschalten und Entfernen zeitlich trennen. ^{[S-126; S-128]}
• Laufzeit, Locks, Datenvolumen und Replikationsfolgen unter realistischen Bedingungen testen. ^{[S-120; S-121]}
• Vor irreversiblen Schritten Backup und Restorefähigkeit verifizieren. ^{[S-122; S-028]}

Mindestnachweise vor Produktivfreigabe

• Versionierte Migration mit Vorwärts- und, soweit möglich, Rückweg. ^[S-128]
• Kompatibilitätsmatrix alter und neuer Anwendungsversionen. ^[S-127]
• Messpunkte für Fortschritt, Fehler und Datenkonsistenz. ^[S-108]

Rote Flaggen

• Spalte wird entfernt, während alte Instanzen sie noch nutzen. ^[S-126]
• Großer Backfill läuft ungedrosselt im Produktivzeitfenster. ^[S-121]
• Rollback wurde nur für Code, nicht für Daten betrachtet. ^[S-108]

Erwartete Artefakte

``mermaid flowchart LR A[Expand] --> B[Dualkompatibel] B --> C[Backfill] C --> D[Umschalten] D --> E[Beobachten] E --> F[Contract] ``

Fehlerbehandlung, Timeouts, Retries und Idempotenz

PRAXIS- UND QUELLENSYNTHESE: Ein verteiltes System muss davon ausgehen, dass Aufrufe langsam, mehrfach, teilweise oder gar nicht beantwortet werden. ^{[S-092; S-093; S-043]}

Prinzipien

• Timeoutbudget entlang der gesamten Kette verteilen. ^{[S-092; S-104]}
• Nur temporäre und sichere Fehler mit begrenztem Backoff und Jitter wiederholen. ^[S-092]
• Schreibende Operationen idempotent oder kompensierbar gestalten. ^{[S-093; S-094]}
• Fehlerzustände maschinenlesbar unterscheiden und in Telemetrie sichtbar machen. ^{[S-043; S-111]}

Mindestnachweise vor Produktivfreigabe

• Timeouts für jeden externen Aufruf. ^[S-092]
• Retrypolicy nach Fehlerklasse und Side Effect. ^{[S-092; S-093]}
• Idempotency Keys für kritische Create-/Send-/Pay-Operationen. ^[S-094]

Rote Flaggen

• Unbegrenzte Wiederholung ohne Backoff. ^[S-092]
• Nach Timeout wird eine Zahlung blind erneut ausgelöst. ^[S-094]
• Alle Fehler werden als HTTP 500 mit Freitext behandelt. ^[S-043]

Erwartete Artefakte

Queues, Ereignisse und lange Workflows

PRAXIS- UND QUELLENSYNTHESE: Asynchronität verbessert Entkopplung und Spitzenaufnahme, erzeugt aber neuen Zustand, verzögerte Fehler und Zustellungssemantik. ^{[S-044; S-095; S-097]}

Prinzipien

• Ereignisse mit stabiler ID, Typ, Quelle, Zeit und Schema versionieren. ^{[S-044; S-045]}
• Consumer auf Duplikate, verzögerte Reihenfolge und Wiederanlauf vorbereiten. ^{[S-095; S-096]}
• Poison Messages und Dead-Letter-Verfahren mit Eigentümer und Rückführung definieren. ^[S-100]
• Lange fachliche Abläufe als explizite Zustandsmaschine oder durable Workflow modellieren. ^[S-097]

Mindestnachweise vor Produktivfreigabe

• Ereignisvertrag und Schemaevolution. ^{[S-045; S-044]}
• Ack-, Retry-, Dedup- und Dead-Letter-Regeln. ^{[S-095; S-100]}
• Monitoring für Queuealter, Rückstand und Fehlerrate. ^{[S-112; S-118]}

Rote Flaggen

• Producer und Consumer interpretieren dasselbe Feld unterschiedlich. ^[S-045]
• Fehlgeschlagene Nachrichten verschwinden oder rotieren endlos. ^[S-100]
• Ein Workflow hält tagelang nur In-Memory-Zustand. ^[S-097]

Erwartete Artefakte

Kapazität, Skalierung und externe Limits

PRAXIS- UND QUELLENSYNTHESE: Skalierung ist ein Systemthema. Mehr Anwendungsinstanzen helfen nicht, wenn Datenbank, Queue, Modellprovider oder externe API bereits begrenzen. ^{[S-074; S-135; S-104]}

Prinzipien

• Nachfrage, Servicezeit, Parallelität und SLO als Kapazitätsgrundlage messen. ^{[S-104; S-074]}
• Autoscaling-Signal und Verzögerung zum tatsächlichen Engpass passend wählen. ^[S-074]
• Providerlimits, Kontingente und Kostenbudgets in Lasttests einbeziehen. ^{[S-135; S-137]}
• Backpressure und Prioritäten statt unkontrollierter Queuevergrößerung einsetzen. ^{[S-100; S-095]}

Mindestnachweise vor Produktivfreigabe

• Lastprofil mit Normal-, Peak- und Degradationsszenario. ^{[S-074; S-101]}
• Kapazitätsgrenzen jeder kritischen Abhängigkeit. ^[S-102]
• Rate-Limit- und Backpressure-Verhalten. ^{[S-135; S-092]}

Rote Flaggen

• Autoscaling wird als Ersatz für Lasttest betrachtet. ^[S-074]
• Batchjob und interaktive Nutzer teilen unpriorisiert dasselbe Kontingent. ^[S-135]
• Queue wächst, ohne dass Alter oder Abbauzeit alarmiert werden. ^[S-112]

Erwartete Artefakte

Observability: Logs, Metriken, Traces und Profile

PRAXIS- UND QUELLENSYNTHESE: Beobachtbarkeit ermöglicht, aus externem Verhalten auf internen Zustand zu schließen. Dafür müssen Signale miteinander korreliert und aus konkreten Diagnosefragen abgeleitet werden. ^{[S-110; S-117; S-118]}

Prinzipien

• Metriken für Trends und Verteilungen, Traces für Pfade, Logs für konkrete Ereignisse nutzen. ^{[S-110; S-112; S-111; S-113]}
• Trace Context über Dienst- und Queuegrenzen weitergeben. ^{[S-117; S-114]}
• Semantische Namen, Einheiten und Labels stabil halten; hohe Kardinalität kontrollieren. ^{[S-119; S-112]}
• Profile gezielt zur Ressourcenanalyse nutzen; der OpenTelemetry-Signalstand war 2026 noch Public Alpha. ^[S-115]

Mindestnachweise vor Produktivfreigabe

• Korrelations-ID vom Nutzerrequest bis zu externen Side Effects. ^[S-117]
• Dashboards für Nutzerpfad, Abhängigkeiten, Fehler, Latenz und Sättigung. ^{[S-118; S-104]}
• Redaction und Aufbewahrung für Logs und Traces. ^{[S-054; S-149]}

Rote Flaggen

• Nur CPU und RAM werden überwacht. ^[S-104]
• Logs enthalten vollständige Tokens, Prompts und Kundendokumente. ^{[S-054; S-149]}
• Jede Nutzer-ID wird unkontrolliert als Metriklabel verwendet. ^[S-119]

Erwartete Artefakte

SLO, Alarmierung und Error Budget

PRAXIS- UND QUELLENSYNTHESE: Ein SLO übersetzt Nutzererwartung in eine messbare Betriebsgrenze. Es ist kein Marketingversprechen, sondern ein interner Steuerungsmechanismus. ^{[S-104; S-105; S-101]}

Prinzipien

• SLI auf Nutzerergebnis und nicht nur Infrastrukturzustand beziehen. ^[S-104]
• Ziel und Messfenster so wählen, dass reale Risiken sichtbar werden. ^[S-101]
• Alarmierung auf schnelles Error-Budget-Burn oder konkrete kritische Symptome ausrichten. ^[S-105]
• Bei verbrauchtem Budget Stabilitätsarbeit und Releasegeschwindigkeit neu gewichten. ^{[S-104; S-012]}

Mindestnachweise vor Produktivfreigabe

• Zwei bis fünf zentrale SLI/SLO pro Dienst statt einer unübersichtlichen Metriksammlung. ^[S-104]
• Actionable Alerts mit Runbook und Eigentümer. ^{[S-105; S-106]}
• Regelmäßige SLO- und Incident-Review. ^[S-101]

Rote Flaggen

• 100 Prozent Verfügbarkeit wird ohne Architektur- und Kostenbezug versprochen. ^[S-104]
• Jede einzelne Fehlermeldung paged On-Call. ^[S-105]
• SLO wird nachträglich so angepasst, dass es immer erfüllt ist. ^[S-101]

Erwartete Artefakte

Backup, Restore und Disaster Recovery

PRAXIS- UND QUELLENSYNTHESE: Wiederherstellung ist eine ausführbare Fähigkeit. Sie muss Daten, Konfiguration, Infrastruktur, Schlüssel und externe Abhängigkeiten gemeinsam betrachten. ^{[S-028; S-122; S-140]}

Prinzipien

• RPO und RTO aus Geschäftsfolgen ableiten. ^{[S-028; S-033]}
• Dumps, physische Backups, PITR und Replikation nach Szenario kombinieren. ^{[S-122; S-123; S-124; S-125]}
• Restore regelmäßig isoliert und automatisiert testen. ^{[S-028; S-140]}
• Auch DNS, Secrets, Objektstorage, Queuezustand und Modell-/Promptartefakte sichern oder reproduzierbar halten. ^{[S-108; S-079]}

Mindestnachweise vor Produktivfreigabe

• Dokumentierte RPO/RTO und Backupabdeckung. ^[S-028]
• Erfolgreicher Restoretest mit Zeit, Datenprüfung und Verantwortlichem. ^[S-122]
• Notfallzugang und Kommunikationsweg unabhängig vom ausgefallenen System. ^{[S-143; S-026]}

Rote Flaggen

• „Der Cloudanbieter macht das Backup“ ohne konkrete Konfiguration und Restoretest. ^[S-028]
• Alle Sicherungen liegen im selben Konto und Berechtigungsbereich. ^[S-025]
• Replikat wird als unveränderliches Backup betrachtet. ^[S-124]

Erwartete Artefakte

Secure SDLC, Anwendungssicherheit und Bedrohungsmodell

PRAXIS- UND QUELLENSYNTHESE: Sicherheit wird nicht am Ende „getestet“, sondern in Anforderungen, Architektur, Implementierung, Lieferkette, Betrieb und Incident Response integriert. ^{[S-022; S-050; S-056]}

Prinzipien

• SSDF-Praktiken an den vorhandenen Entwicklungsprozess anpassen. ^{[S-022; S-024]}
• Bedrohungsmodell aus Assets, Akteuren, Trust Boundaries und Missbrauchsfällen ableiten. ^{[S-025; S-057]}
• ASVS/WSTG für prüfbare Anwendungskontrollen nutzen. ^{[S-050; S-049]}
• KI-spezifisch Prompt Injection, übermäßige Autonomie, Datenabfluss und Modell-/Toolmissbrauch prüfen. ^{[S-056; S-030]}

Mindestnachweise vor Produktivfreigabe

• Bedrohungsmodell und Sicherheitsanforderungen. ^{[S-022; S-050]}
• Authentisierung, Autorisierung und Mandantentrennung serverseitig getestet. ^{[S-055; S-052]}
• SAST/Dependency/Secret- und gezielte dynamische Tests. ^{[S-022; S-129; S-049]}

Rote Flaggen

• Modelloutput wird als vertrauenswürdiger Code, SQL oder HTML ausgeführt. ^[S-056]
• Ein Penetrationstest kurz vor Launch soll fehlende Secure-SDLC-Prozesse ersetzen. ^[S-022]
• Berechtigungen werden nur in der Benutzeroberfläche geprüft. ^[S-055]

Erwartete Artefakte

Vulnerability- und Dependency-Management

PRAXIS- UND QUELLENSYNTHESE: Nach dem Launch entstehen neue Schwachstellen und neue Versionen, auch wenn der eigene Code unverändert bleibt. ^{[S-129; S-131; S-082]}

Prinzipien

• Komponenteninventar mit Paketversion, Herkunft und Einsatzort pflegen. ^{[S-082; S-083]}
• Schwachstellen mit OSV, Herstellerinformationen und KEV-Signalen korrelieren. ^{[S-129; S-131]}
• Priorität aus Schwere, Ausnutzbarkeit, Exposition und Geschäftsfolgen bestimmen. ^{[S-130; S-131]}
• Updates automatisiert vorschlagen, aber gestaffelt testen und ausrollen. ^{[S-132; S-133; S-012]}

Mindestnachweise vor Produktivfreigabe

• SBOM je Release und Zuordnung zum laufenden Bestand. ^[S-084]
• SLA oder interne Fristen nach Risikoklasse. ^[S-025]
• Ausnahme mit Eigentümer, Ablaufdatum und Kompensation. ^[S-022]

Rote Flaggen

• Nur das Betriebssystem wird gepatcht; Libraries, Images und Actions bleiben unbeachtet. ^[S-079]
• CVSS allein bestimmt Priorität ohne Erreichbarkeitsprüfung. ^{[S-130; S-131]}
• Automatische Updates landen ungeprüft direkt in Produktion. ^{[S-132; S-133]}

Erwartete Artefakte

KI-Anbieter, Modelle und Fallbackbetrieb

PRAXIS- UND QUELLENSYNTHESE: Externe Modell-APIs sind veränderliche Abhängigkeiten mit Versionen, Kontingenten, Preis-, Policy- und Qualitätsunterschieden. ^{[S-134; S-135; S-136]}

Prinzipien

• Verwendete Modell-IDs, Regionen, Features, Limits und Datenpfade inventarisieren. ^{[S-135; S-137; S-138]}
• Abkündigungsfeeds und Migrationsfristen überwachen. ^{[S-134; S-136]}
• Ersatzmodelle gegen eigene Evals, Verträge und Sicherheitsfälle prüfen. ^{[S-066; S-067]}
• Degradationsmodus definieren: Queue, Read-only, klassischer Fallback, Mensch oder transparente Nichtverfügbarkeit. ^{[S-102; S-029]}

Mindestnachweise vor Produktivfreigabe

• Provider-/Modellinventar mit Eigentümer und Abkündigungsmonitoring. ^{[S-134; S-136]}
• Rate-Limit- und Ausfalltests. ^{[S-135; S-092]}
• Validierter Fallback oder bewusst dokumentiertes Fail-Closed. ^[S-102]

Rote Flaggen

• Produktionssystem nutzt einen Alias ohne Eval bei Modellwechsel. ^[S-134]
• Fallback ist nur „wir nehmen dann ein anderes Modell“. ^[S-067]
• Providerfehler löst unkontrollierte Retry-Stürme aus. ^[S-092]

Erwartete Artefakte

Incident Response, On-Call und Kommunikation

PRAXIS- UND QUELLENSYNTHESE: Störungen werden unter Zeitdruck bearbeitet. Vorbereitung reduziert improvisierte, riskante Eingriffe und widersprüchliche Kommunikation. ^{[S-026; S-107; S-106]}

Prinzipien

• Incident Commander, Technik, Kommunikation und Protokollierung als Rollen trennen, soweit Teamgröße erlaubt. ^{[S-107; S-026]}
• Severity und Eskalation an Nutzerwirkung und Risiko binden. ^{[S-106; S-104]}
• Notfalländerungen minimal, dokumentiert und nachträglich reviewt ausführen. ^{[S-026; S-022]}
• Statuskommunikation faktisch, zeitnah und ohne unbelegte Ursache führen. ^[S-107]

Mindestnachweise vor Produktivfreigabe

• Incident-Plan, Kontakte und unabhängig erreichbarer Kommunikationskanal. ^[S-026]
• Runbooks für Top-Ausfälle und Sicherheitsereignisse. ^[S-106]
• Zugriff auf Logs, Backups und Kill Switch im Notfall. ^{[S-028; S-075]}

Rote Flaggen

• Einzelner Entwickler diagnostiziert, entscheidet, ändert und kommuniziert gleichzeitig. ^[S-107]
• Statusseite hängt vom ausgefallenen System ab. ^[S-143]
• Produktionszugriff wird im Incident über private Accounts geteilt. ^[S-053]

Erwartete Artefakte

Post-Mortem, Maßnahmen und Organisationslernen

PRAXIS- UND QUELLENSYNTHESE: Nach einem Incident geht es nicht um Schuldzuweisung, sondern um die Bedingungen, unter denen ein Fehler Wirkung entfalten konnte. ^{[S-107; S-025; S-142]}

Prinzipien

• Zeitlinie und Fakten von Annahmen trennen. ^[S-107]
• Technische und organisatorische Schutzbarrieren analysieren. ^{[S-139; S-145]}
• Maßnahmen nach Prävention, Erkennung, Begrenzung und Wiederherstellung ordnen. ^[S-025]
• Jede Maßnahme mit Eigentümer, Termin und Wirksamkeitskriterium versehen. ^[S-107]

Mindestnachweise vor Produktivfreigabe

• Auswirkung, Dauer, betroffene Nutzer/Daten und aktuelle Restunsicherheit. ^[S-026]
• Ursachen- und Beitragsfaktoren statt nur Auslöser. ^{[S-142; S-144]}
• Nachverfolgbares Maßnahmenregister. ^[S-107]

Rote Flaggen

• „Menschliches Versagen“ ist die einzige Ursache. ^[S-139]
• Post-Mortem enthält keine überprüfbaren Maßnahmen. ^[S-107]
• Gleiche Incidentklasse tritt wiederholt auf, ohne Systemänderung. ^[S-025]

Erwartete Artefakte

Dokumentation, Support und Übergabe

PRAXIS- UND QUELLENSYNTHESE: Dokumentation muss den Nutzer, den Betreiber und den nächsten Entwickler befähigen. Sie ist kein nachträglicher Screenshot-Ordner. ^{[S-007; S-001; S-106]}

Prinzipien

• Nutzerdokumentation nach Aufgaben und Fehlerfällen gestalten. ^[S-007]
• Betriebsdokumentation mit Architektur, Dependencies, Deploy, Rollback, Restore und Troubleshooting verbinden. ^{[S-001; S-106]}
• Dokumente versionieren und mit Releases aktualisieren. ^{[S-016; S-018]}
• Bekannte Grenzen, Datenverwendung und KI-spezifisches Verhalten transparent machen. ^{[S-063; S-029]}

Mindestnachweise vor Produktivfreigabe

• README und lokale Startanweisung. ^[S-007]
• Betriebshandbuch, Runbooks und Wiederherstellungsanweisung. ^{[S-028; S-106]}
• Nutzerhilfe, Supportweg und bekannte Einschränkungen. ^[S-007]

Rote Flaggen

• Nur der ursprüngliche Entwickler kann deployen oder Fehler verstehen. ^[S-001]
• Screenshots zeigen veraltete Oberfläche und Rechte. ^[S-007]
• Keine Dokumentation der Modell- und Promptversionen. ^[S-063]

Erwartete Artefakte

Wartung, Abkündigung und Stilllegung

PRAXIS- UND QUELLENSYNTHESE: Produktionssysteme verändern sich auch ohne Featureentwicklung. Zertifikate laufen ab, Provider stellen Modelle ein und Abhängigkeiten verlieren Support. ^{[S-001; S-134; S-149]}

Prinzipien

• Regelmäßige Wartungsfenster für Abhängigkeiten, Datenbank, Runtime und Infrastruktur planen. ^{[S-001; S-132]}
• Abkündigungen und End-of-Life-Termine als inventarisierte Risiken führen. ^{[S-134; S-136]}
• Technische Schulden mit Auswirkung und Eigentümer priorisieren. ^{[S-058; S-010]}
• Stilllegung inklusive Datenexport, Löschung, Credential-Widerruf, DNS und Integrationen planen. ^{[S-149; S-001]}

Mindestnachweise vor Produktivfreigabe

• Wartungskalender und Dependency-SLA. ^[S-001]
• EOL-/Deprecation-Register. ^[S-134]
• Exit- und Decommission-Runbook. ^{[S-033; S-149]}

Rote Flaggen

• Das System hat keinen aktiven Eigentümer, läuft aber weiter. ^[S-001]
• Zertifikate, Domains oder Modelle werden erst nach Ausfall erneuert. ^[S-134]
• Bei Abschaltung bleiben Schlüssel, Webhooks und Datenkopien aktiv. ^{[S-053; S-149]}

Erwartete Artefakte

20 Standards, Rahmenwerke und Forschungsprofile

QUELLENSYNTHESE: Kein einzelner Standard deckt die gesamte Produktionsreife ab. Lebenszyklus, Qualität, sichere Entwicklung, Lieferkette, Reliability, Observability, Datenbetrieb und KI-Risikomanagement ergänzen sich. Die Profile zeigen Beitrag und Grenze jeder Quelle. ^{[S-001; S-002; S-022; S-101; S-029]}

ISO/IEC/IEEE 12207:2026

ISO/IEC 25010:2023 und SQuaRE-Qualitätsmodelle

ISO/IEC/IEEE 29148:2018

NIST SSDF 1.1 / Entwurf 1.2

NIST SP 800-218A

NIST AI RMF Generative AI Profile

DORA 2025

SPACE Framework

SLSA 1.2, in-toto und Sigstore

SPDX 3.0.1, CycloneDX 1.7 und CISA SBOM 2026

OWASP ASVS 5.0 und WSTG

OWASP Top 10:2025 / API Top 10:2023

OWASP LLM Top 10:2026 und MITRE ATLAS

Google SRE Workbook

OpenTelemetry und W3C Trace Context

Twelve-Factor App

OpenAPI, JSON Schema, AsyncAPI und CloudEvents

Kubernetes Deployment, Probes und HPA

PostgreSQL 18 Backup/PITR/Standby

EU AI Act und DSGVO

Reale Ausfälle: 10 dokumentierte Lessons Learned

FALLSYNTHESE: Die Fälle sind keine Sensationssammlung. Sie zeigen wiederkehrende Produktionsmuster: zu großer Blast Radius, unvollständiges Deployment, ungetestete Wiederherstellung, fehlerhafte Konfiguration, schwache Lieferkette, unzureichende Migration und fehlende Schutzbarrieren. ^{[S-139; S-140; S-142; S-145]}

Knight Capital, 2012 — alte Funktion durch unvollständiges Deployment reaktiviert

GitLab, 2017 — Produktionsdaten gelöscht, Sicherungswege versagten

AWS S3, 2017 — Wartungsbefehl hatte zu großen Blast Radius

Cloudflare, 2019 — WAF-Regel verbrauchte weltweit CPU

Meta, 2021 — Backbone-Änderung trennte Dienste und erschwerte Reparatur

CrowdStrike, 2024 — fehlerhafte Content-Konfiguration weltweit ausgerollt

TSB, 2018 — kritische Bankmigration mit Governance- und Testmängeln

Equifax, 2017 — bekannte Schwachstelle, Asset- und Erkennungsprobleme

Codecov, 2021 — kompromittiertes Uploadskript als Lieferkettenkanal

Atlassian, 2022 — Wartungsskript löschte Kundensites

Wiederkehrende Muster über die Fälle

18 Referenzszenarien

REFERENZARCHITEKTUR-SYNTHESE: Die Szenarien sind keine fertigen Baupläne. Sie zeigen, welche klassische Softwarestruktur eine KI-Funktion umgeben muss und welche Produktionsnachweise je nach Wirkung besonders wichtig werden. ^{[S-006; S-102; S-029]}

Interne Einzweck-Automation ohne KI

Öffentliche Unternehmenswebsite

Kontaktformular mit CRM-Übergabe

Interner RAG-Wissensassistent

Dokumentenextraktion in ein ERP

E-Mail-Klassifikation und Antwortentwurf

CRM-Notiz und Angebotsentwurf

Kundenchatbot auf öffentlicher Website

Batch-Zusammenfassung großer Dokumentmengen

Echtzeit-Copilot für Fachanwender

Eventgetriebene KI-Automation mit mehreren Systemen

Multi-Tenant-SaaS mit KI-Funktion

Self-hosted LLM-Inferenz

Multi-Provider-Modellgateway

Mobile Außendienstanwendung mit Offlinebetrieb

Hochwirksame Entscheidungshilfe

Legacy-System-Migration

Kleines internes Tool eines Vibe Coders

Der 48-stufige Weg vom Konzept zum laufenden Dienst

UMSETZUNGSSYNTHESE: Die Schritte sind als prüfbarer Arbeitsweg formuliert. Sie können iterativ und risikobasiert komprimiert werden, dürfen aber bei höherer Kritikalität nicht durch eine pauschale Toolentscheidung ersetzt werden. ^{[S-001; S-006; S-102]}

Phase A — Problem und Grenze

Phase B — Architektur und Reproduzierbarkeit

Phase C — Test und Evaluation

Phase D — Sichere Lieferkette

Phase E — Infrastruktur und Release

Phase F — Beobachtbarkeit und Bereitschaft

Phase G — Wiederherstellung und Produktivstart

Phase H — Betrieb, Lernen und Exit

Go-live-Entscheidung in einem Satz

Entscheidungsformel: Go-live ist vertretbar, wenn der definierte Nutzen auf realistischer Evidenz beruht, die wesentlichen Risiken kontrolliert oder ausdrücklich akzeptiert sind, der Dienst beobachtbar und wiederherstellbar ist und benannte Personen Änderung, Incident, Wartung und Exit verantworten. ^{[S-006; S-102; S-028; S-001]}

Produktionsreife- und Go-live-Checklisten

``mermaid flowchart LR A[Nutzerwert] --> B[Telemetry] B --> C[SLO und Steuerung] C --> D[Änderung] D --> E[Lernen] E --> A ``

Gate 0 — Problem und Risiko

Gate 1 — Build, Code und Lieferkette

Gate 2 — Test, KI-Evaluation und Security

Gate 3 — Release, Migration und Reliability

Gate 4 — Betrieb und Wiederherstellung

Vollständige Arbeitscheckliste nach Themenfeld

Stop-Kriterien

Kein Go-live: Produktivstart stoppen, wenn kritische Daten- oder Berechtigungsgrenzen ungeklärt sind, irreversible Side Effects keinen sicheren Kontrollweg besitzen, die produktive Version nicht reproduzierbar ist, der Dienst nicht beobachtet oder wiederhergestellt werden kann oder niemand die Betriebsverantwortung übernimmt. ^{[S-006; S-022; S-028; S-102]}

20 Mythenprüfungen

„Wenn die Demo funktioniert, ist die Anwendung fast fertig.“

Urteil: Falsch. Die Demo belegt nur einen engen Pfad. Betrieb, Rechte, Datenmigration, Last, Wiederherstellung, Missbrauch, Wartung und Support können den größeren Teil des Risikos ausmachen. ^{[S-001; S-002; S-102]}

„Cloud Hosting macht eine Anwendung automatisch hochverfügbar.“

Urteil: Falsch. Verfügbarkeit hängt von Architektur, Region, Datenbank, Deployment, Backups, Limits und eigener Fehlerbehandlung ab. Cloudressourcen können genauso falsch konfiguriert oder gemeinsam ausfallgefährdet sein. ^{[S-028; S-141; S-102]}

„Container bedeuten reproduzierbaren und sicheren Betrieb.“

Urteil: Zu kurz gegriffen. Container verbessern Verpackung und Isolation, aber nur bei gepinnten Inputs, kontrollierten Builds, minimalen Rechten und sicherem Runtimebetrieb. ^{[S-068; S-069; S-079]}

„Kubernetes löst Skalierung und Ausfallsicherheit.“

Urteil: Falsch. Kubernetes stellt Mechanismen bereit. Falsche Probes, nicht skalierbare Datenbanken, Providerlimits oder fachliche Fehler bleiben bestehen. ^{[S-073; S-074; S-072]}

„Mehr Tests bedeuten automatisch mehr Qualität.“

Urteil: Falsch. Tests müssen relevante Risiken, reale Verträge und Fehlerfälle abdecken. Eine große Zahl redundanter oder instabiler Tests kann Scheinsicherheit und Wartungslast erzeugen. ^{[S-046; S-047; S-012]}

„End-to-End-Tests reichen, weil sie das echte System prüfen.“

Urteil: Falsch. Sie sind wichtig, aber langsam und schwer zu diagnostizieren. Schnelle Komponenten- und Vertragstests liefern andere, notwendige Evidenz. ^{[S-047; S-048]}

„Ein LLM-Eval ist einfach ein Unit-Test mit Text.“

Urteil: Falsch. Generative Ergebnisse können variieren und mehrere akzeptable Formen besitzen. Kriterien, Stichprobe, Judge-Kalibrierung und Fehlertaxonomie sind zusätzliche Aufgaben. ^{[S-066; S-067; S-065]}

„Ein besseres Modell behebt schlechte Produktarchitektur.“

Urteil: Falsch. Rechte, Datenqualität, Toolgrenzen, Systemzustand, Transaktionen und Wiederherstellung liegen außerhalb des Modells. Ein stärkeres Modell kann die Wirkung einer schlechten Integration sogar vergrößern. ^{[S-058; S-029; S-010]}

„Human-in-the-Loop macht jede KI-Anwendung sicher.“

Urteil: Falsch. Der Mensch braucht Evidenz, Zeit, Kompetenz, eine echte Ablehnungsoption und klare Verantwortung. Sonst entsteht nur ritualisierte Bestätigung. ^{[S-029; S-004]}

„Ein SBOM beweist, dass ein Release sicher ist.“

Urteil: Falsch. Es inventarisiert Bestandteile. Sichere Konfiguration, Herkunft, Ausnutzbarkeit und fachliche Richtigkeit müssen separat geprüft werden. ^{[S-084; S-082; S-079]}

„Eine Signatur beweist, dass der Inhalt vertrauenswürdig ist.“

Urteil: Falsch. Sie beweist eine kryptografisch gebundene Aussage oder Identität. Ein korrekt signierter fehlerhafter Build bleibt fehlerhaft. ^{[S-081; S-080]}

„Rolling Deployment verhindert großflächige Fehler.“

Urteil: Falsch. Es verteilt schrittweise Instanzen, kann aber einen fachlichen Fehler trotzdem vollständig ausrollen. Guardrails und progressive Exposition bleiben nötig. ^{[S-072; S-103]}

„Rollback ist immer die schnellste Rettung.“

Urteil: Falsch. Nach Datenmigrationen oder externen Side Effects kann die alte Version inkompatibel sein. Roll-forward oder Kompensation kann sicherer sein. ^{[S-108; S-126; S-093]}

„Retries erhöhen automatisch die Verfügbarkeit.“

Urteil: Falsch. Unbegrenzte oder geschichtete Retries verstärken Überlastung und duplizieren Side Effects. Sie brauchen Backoff, Jitter, Limits und Idempotenz. ^{[S-092; S-093]}

„Eine Queue garantiert genau einmalige Verarbeitung.“

Urteil: Meist falsch formuliert. Zustell- und Verarbeitungssemantik hängt von Broker, Acknowledgement, Transaktion und Consumer ab. Anwendungen müssen Duplikate bewusst behandeln. ^{[S-095; S-096]}

„Backups sind Aufgabe des Cloudanbieters.“

Urteil: Falsch. Konfiguration, Umfang, Aufbewahrung, Rechte und Wiederherstellung bleiben kundenspezifisch. Ohne erfolgreichen Restoretest ist die Fähigkeit unbewiesen. ^{[S-028; S-140]}

„Replikation ist ein Backup.“

Urteil: Falsch. Logische Löschung und Korruption können repliziert werden. Replikation und zeitlich unabhängige Sicherung erfüllen unterschiedliche Zwecke. ^{[S-124; S-122]}

„Monitoring bedeutet, CPU und Speicher zu beobachten.“

Urteil: Unzureichend. Nutzererfolg, Latenz, Fehler, Abhängigkeiten, Sättigung, Queuealter und KI-Qualität sind häufig entscheidender als Hostmetriken. ^{[S-104; S-110]}

„Ein zweiter KI-Provider ist automatisch ein Fallback.“

Urteil: Falsch. Ohne Vertragstests, Evals, Datenfreigabe und getestete Umschaltung ist er nur eine weitere ungesicherte Abhängigkeit. ^{[S-066; S-067; S-102]}

„KI-generierter Code kann schneller direkt ausgerollt werden.“

Urteil: Falsch. Schnellere Erzeugung erhöht nicht automatisch Verständnis oder Nachweis. Review-, Test-, Security- und Betriebsanforderungen bleiben bestehen. ^{[S-010; S-024; S-022]}

20 offene Forschungs- und Praxisfragen

FORSCHUNGSSTATUS: Offene Fragen werden nicht mit Scheingenauigkeit beantwortet. Die Tabelle trennt etablierte Richtung von systemspezifischer oder noch in Entwicklung befindlicher Evidenz. ^{[S-029; S-116; S-085]}

Glossar

Abnahmekriterium

Prüfbare Bedingung, unter der eine Anforderung als erfüllt gilt. ^[S-005]

ADR

Architecture Decision Record; kurze versionierte Dokumentation von Kontext, Entscheidung und Folgen. ^[S-020]

Artefakt

Auslieferbares Ergebnis eines Builds, etwa Paket, Binary oder Containerimage. ^[S-014]

Attestation

Signierte oder anderweitig verifizierbare Aussage über einen Prozess oder ein Artefakt. ^{[S-080; S-079]}

Backfill

Nachträgliches Befüllen oder Transformieren vorhandener Daten nach einer Schema-/Logikänderung. ^[S-127]

Backoff

Zunehmende Wartezeit zwischen Wiederholungsversuchen. ^[S-092]

Backpressure

Mechanismus, der Eingangslast begrenzt, wenn nachgelagerte Verarbeitung nicht nachkommt. ^[S-100]

Backup

Unabhängige Sicherung zur späteren Wiederherstellung. ^[S-122]

Blast Radius

Umfang der Systeme, Nutzer oder Daten, die durch einen Fehler betroffen werden können. ^[S-006]

Blue-Green Deployment

Zwei Produktionsumgebungen, zwischen denen Traffic kontrolliert umgeschaltet wird. ^[S-076]

Branch Protection

Technische Regeln, die direkte oder ungeprüfte Änderungen an einem Branch begrenzen. ^[S-034]

Build

Umwandlung von Quellen und Abhängigkeiten in ein auslieferbares Artefakt. ^[S-014]

Build Provenance

Nachweis, wo, wie und aus welchen Eingaben ein Artefakt erzeugt wurde. ^[S-079]

Bulkhead

Trennung von Ressourcenpools zur Begrenzung kaskadierender Ausfälle. ^[S-099]

Canary Release

Einführung einer Änderung bei einem kleinen Anteil von Traffic oder Nutzern vor breiter Freigabe. ^[S-103]

CD

Continuous Delivery/Deployment; automatisierte Bereitstellung beziehungsweise Auslieferung nach definierten Gates. ^[S-012]

Change Failure Rate

Anteil von Änderungen, die zu Störung oder Korrekturbedarf führen; Teil der DORA-Messlogik. ^[S-012]

CI

Continuous Integration; häufiges Zusammenführen und automatisches Prüfen von Änderungen. ^[S-035]

Circuit Breaker

Zustandsautomat, der aussichtslose Aufrufe vorübergehend stoppt. ^[S-098]

CloudEvents

Standardisiertes Ereignisformat mit gemeinsamen Metadaten. ^[S-044]

Compensation

Fachliche Gegenaktion für einen bereits ausgeführten, nicht technisch zurückrollbaren Schritt. ^[S-093]

Contract Test

Test, ob Anbieter und Verbraucher einer Schnittstelle denselben Vertrag erfüllen. ^[S-048]

Correlation ID

Kennung zur Verbindung zusammengehöriger Ereignisse über Komponenten hinweg. ^[S-117]

CVSS

Standardisiertes System zur technischen Bewertung von Schwachstellenschwere. ^[S-130]

Dead Letter Queue

Ablage für Nachrichten, die nach definierten Versuchen nicht verarbeitet werden konnten. ^[S-100]

Deployment

Technische Bereitstellung einer Softwareversion in einer Umgebung. ^[S-071]

Digest

Kryptografischer Inhaltsbezeichner eines Artefakts. ^[S-069]

Disaster Recovery

Planung und Fähigkeit zur Wiederherstellung nach schwerwiegendem Ausfall. ^[S-028]

Drift

Abweichung des tatsächlichen Infrastrukturzustands von der deklarierten Sollkonfiguration. ^[S-077]

Durable Execution

Persistierte Workflowausführung, die nach Prozess- oder Infrastrukturausfall fortgesetzt werden kann. ^[S-097]

Error Budget

Zulässiger Fehlraum, der sich aus einem SLO ergibt. ^[S-104]

Eval

Systematischer Test einer KI-Funktion anhand definierter Fälle und Kriterien. ^[S-066]

Expand and Contract

Migrationsmuster aus additiver Erweiterung, Übergang und späterer Entfernung alter Strukturen. ^[S-126]

Feature Flag

Laufzeitsteuerung, die Deployment und Nutzerfreigabe einer Funktion trennt. ^[S-075]

Flaky Test

Test, der ohne relevante Codeänderung unzuverlässig zwischen Erfolg und Fehler schwankt. ^[S-012]

Golden Set

Versionierter Referenzsatz repräsentativer Aufgaben und erwarteter Bewertung. ^[S-067]

Health Probe

Maschinenlesbare Prüfung von Start, Lebensfähigkeit oder Bereitschaft einer Instanz. ^[S-073]

IaC

Infrastructure as Code; Infrastruktur wird deklarativ oder programmatisch versioniert beschrieben. ^[S-078]

Idempotenz

Eigenschaft, dass eine identische Wiederholung keine zusätzliche unerwünschte Wirkung erzeugt. ^[S-093]

Immutable Artifact

Nach dem Build unverändertes, eindeutig identifiziertes Releaseartefakt. ^{[S-014; S-069]}

Incident

Ereignis, das Dienstqualität, Sicherheit oder Geschäftsbetrieb beeinträchtigt. ^[S-026]

Infrastructure Drift

Siehe Drift; ungeplante Abweichung zwischen Soll- und Ist-Zustand. ^[S-077]

Jitter

Zufällige Streuung von Retry-Wartezeiten zur Vermeidung synchroner Lastspitzen. ^[S-092]

KEV

CISA-Katalog bekannter, tatsächlich ausgenutzter Schwachstellen. ^[S-131]

Kill Switch

Kontrollierter Mechanismus zum schnellen Deaktivieren einer Funktion oder Aktion. ^[S-075]

Lead Time for Changes

Zeit von einer Änderung bis zur erfolgreichen Bereitstellung; DORA-Metrik. ^[S-012]

Liveness Probe

Prüft, ob ein Prozess fortgesetzt werden kann oder neu gestartet werden sollte. ^[S-073]

Lockfile

Datei, die konkret aufgelöste Abhängigkeitsversionen festhält. ^[S-019]

Model Card

Strukturierte Dokumentation eines Modells, seiner Nutzung und Grenzen. ^[S-063]

MTTR

Häufig verwendete Abkürzung für Mean Time to Restore/Recovery; Definition muss im Projekt eindeutig sein. ^[S-012]

Observability

Fähigkeit, internen Zustand aus Telemetrie und externem Verhalten zu verstehen. ^[S-110]

OpenAPI

Spezifikation zur Beschreibung synchroner HTTP-APIs. ^[S-040]

PITR

Point-in-Time Recovery; Wiederherstellung auf einen gewählten Zeitpunkt. ^[S-123]

Poison Message

Nachricht, die wiederholt nicht verarbeitet werden kann und gesondert behandelt werden muss. ^[S-100]

Post-Mortem

Strukturierte Analyse eines Incidents, seiner Faktoren und Folgemaßnahmen. ^[S-107]

Production Readiness Review

Risikobasierte Prüfung vor oder während der Übernahme eines Dienstes in den Betrieb. ^[S-102]

Progressive Delivery

Schrittweise Freigabe mit Messung und kontrollierter Promotion. ^[S-076]

Prompt Regression

Qualitätsverschlechterung nach Änderung von Prompt, Modell, Kontext oder Tools. ^[S-066]

Provenance

Nachvollziehbare Herkunft und Entstehung eines Artefakts oder Datensatzes. ^{[S-079; S-064]}

RACI

Rollenmodell für Responsible, Accountable, Consulted und Informed; projektspezifisches Governanceinstrument. ^[S-001]

Rate Limit

Begrenzung der zulässigen Nutzung innerhalb eines Zeitraums oder Kontingents. ^[S-135]

Readiness Probe

Prüft, ob eine Instanz aktuell Traffic annehmen soll. ^[S-073]

Recovery Point Objective

Maximal akzeptierter Zeitraum des Datenverlusts. ^[S-028]

Recovery Time Objective

Maximal angestrebte Zeit bis zur Wiederherstellung. ^[S-028]

Release

Freigabe einer Version oder Funktion für eine Nutzergruppe. ^{[S-014; S-075]}

Reproducible Build

Build, der aus gleichen Eingaben reproduzierbar dasselbe Artefakt erzeugt. ^[S-019]

Restore Test

Praktische Wiederherstellung und Verifikation gesicherter Daten/Systeme. ^[S-028]

Retry

Erneuter Versuch nach Fehler; braucht Fehlerklassifikation und Grenzen. ^[S-092]

Roll-forward

Behebung durch eine neue korrigierte Version statt Rückkehr. ^[S-108]

Rollback

Rückkehr zu einer früheren Software- oder Konfigurationsversion. ^[S-072]

Runbook

Handlungsanweisung für Diagnose und Betriebssituationen. ^[S-106]

SBOM

Software Bill of Materials; maschinenlesbares Komponenten- und Beziehungsinventar. ^[S-084]

Secret

Vertraulicher Authentisierungs- oder Kryptografiewert. ^[S-053]

Semantic Versioning

Versionsschema, das kompatible und inkompatible Änderungen ausdrückt. ^[S-018]

Side Effect

Wirkung außerhalb einer reinen Berechnung, etwa Schreiben, Senden oder Bezahlen. ^[S-093]

SLI

Service Level Indicator; gemessene Größe eines Dienstmerkmals. ^[S-104]

SLO

Service Level Objective; Zielwert für einen SLI über ein Zeitfenster. ^[S-104]

SLSA

Supply-chain Levels for Software Artifacts; Framework für Lieferkettenintegrität. ^[S-079]

Startup Probe

Prüft den Abschluss eines langsamen Anwendungsstarts. ^[S-073]

System of Record

Führendes System für verbindliche Fachdaten. ^[S-108]

Telemetry

Messdaten aus Logs, Metriken, Traces und weiteren Signalen. ^[S-110]

Trace

Darstellung eines verteilten Request- oder Workflowpfads aus zusammengehörigen Spans. ^[S-111]

Trace Context

Standardisierte Korrelationsinformation, die zwischen Diensten weitergegeben wird. ^[S-117]

Trust Boundary

Grenze, an der sich Vertrauens- oder Berechtigungsannahmen ändern. ^[S-025]

Vulnerability Management

Laufender Prozess zur Erkennung, Bewertung, Behebung und Nachverfolgung von Schwachstellen. ^[S-025]

Workload Identity

Technische Identität eines Dienstes oder Jobs statt eines Menschen. ^[S-038]

Quellenmethodik und Belegmatrix

Auswahlprinzip

• Primärrecht, Behördenstandards, internationale Normen, Originalstudien und offizielle Projektdokumentation werden bevorzugt.
• Hersteller- und Projektdokumentationen werden dort genutzt, wo sie den aktuellen Produkt- oder Protokollstand beschreiben; sie sind nicht als unabhängige Wirksamkeitsstudien behandelt.
• Post-Mortems stammen möglichst vom Betreiber, Hersteller, Aufsichts- oder Untersuchungsorgan.
• Unklare Veröffentlichungsdaten werden als UNKLAR mit Prüfstichtag geführt statt erfunden.
• Schnell veränderliche Quellen erhalten hohe oder sehr hohe Refresh-Priorität.

Quellenverteilung

Kompakte Belegmatrix

Vollständiges Quellenregister — 175 Einträge

Jeder Eintrag enthält Herausgeber, Titel, Veröffentlichungsdatum beziehungsweise explizit UNKLAR, Dokumenttyp, Status, Relevanz, Refresh-Priorität und direkte URL.

Lebenszyklus und Qualität

^[S-001] ISO/IEC/IEEE 12207:2026 — Systems and software engineering — Software life cycle processes

• Autor/Herausgeber: ISO / IEC / IEEE
• Datum: 2026
• Dokumenttyp: Internationaler Standard
• Status: Aktuelle Ausgabe; Ausgabe 2017 zurückgezogen
• Relevanz: Gemeinsamer Prozessrahmen für Konzeption, Entwicklung, Betrieb, Unterstützung und Stilllegung von Software.
• Refresh-Priorität: niedrig
• Direkte URL: [https://www.iso.org/standard/90219.html](https://www.iso.org/standard/90219.html)

^[S-002] ISO/IEC 25010:2023 — Product quality model

• Autor/Herausgeber: ISO / IEC
• Datum: 2023
• Dokumenttyp: Internationaler Standard
• Status: Aktuelle Ausgabe
• Relevanz: Produktqualitätsmodell mit neun Qualitätsmerkmalen.
• Refresh-Priorität: niedrig
• Direkte URL: [https://www.iso.org/standard/78176.html](https://www.iso.org/standard/78176.html)

^[S-003] ISO/IEC 25002:2024 — Quality model overview and usage

• Autor/Herausgeber: ISO / IEC
• Datum: 2024
• Dokumenttyp: Internationaler Standard
• Status: Aktuelle Ausgabe
• Relevanz: Rahmen zur Definition und Anwendung von Qualitätsmodellen.
• Refresh-Priorität: niedrig
• Direkte URL: [https://www.iso.org/standard/78175.html](https://www.iso.org/standard/78175.html)

^[S-004] ISO/IEC 25019:2023 — Quality-in-use model

• Autor/Herausgeber: ISO / IEC
• Datum: 2023
• Dokumenttyp: Internationaler Standard
• Status: Aktuelle Ausgabe
• Relevanz: Qualität aus Sicht der Nutzung und Stakeholder.
• Refresh-Priorität: niedrig
• Direkte URL: [https://www.iso.org/standard/78177.html](https://www.iso.org/standard/78177.html)

Anforderungen

^[S-005] ISO/IEC/IEEE 29148:2018 — Requirements engineering

• Autor/Herausgeber: ISO / IEC / IEEE
• Datum: 2018; Nachfolgedokument in Entwicklung, geprüft 08.08.2026
• Dokumenttyp: Internationaler Standard
• Status: Gültige Ausgabe am Stichtag
• Relevanz: Anforderungen, deren Eigenschaften und Requirements-Prozesse.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.iso.org/standard/72089.html](https://www.iso.org/standard/72089.html)

Governance und Risiko

^[S-006] ISO/IEC/IEEE 16085:2021 — Life cycle processes — Risk management

• Autor/Herausgeber: ISO / IEC / IEEE
• Datum: 2021
• Dokumenttyp: Internationaler Standard
• Status: Aktuelle Ausgabe
• Relevanz: Risikomanagement über den System- und Softwarelebenszyklus.
• Refresh-Priorität: niedrig
• Direkte URL: [https://www.iso.org/standard/74371.html](https://www.iso.org/standard/74371.html)

Dokumentation

^[S-007] ISO/IEC/IEEE 26514:2022 — Design and development of information for users

• Autor/Herausgeber: ISO / IEC / IEEE
• Datum: 2022
• Dokumenttyp: Internationaler Standard
• Status: Aktuelle Ausgabe
• Relevanz: Nutzerdokumentation als geplanter Bestandteil eines Produkts.
• Refresh-Priorität: niedrig
• Direkte URL: [https://www.iso.org/standard/77451.html](https://www.iso.org/standard/77451.html)

Lebenszyklus und Qualität

^[S-008] Guide to the Software Engineering Body of Knowledge — SWEBOK Guide V4.0

• Autor/Herausgeber: IEEE Computer Society
• Datum: 10.2024
• Dokumenttyp: Fachstandard / Body of Knowledge
• Status: Aktuelle Ausgabe am Stichtag
• Relevanz: Systematische Wissensgebiete professioneller Softwareentwicklung.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.computer.org/education/bodies-of-knowledge/software-engineering](https://www.computer.org/education/bodies-of-knowledge/software-engineering)

Organisation und Messung

^[S-009] The SPACE of Developer Productivity: There’s more to it than you think

• Autor/Herausgeber: Forsgren et al. / ACM / Microsoft Research
• Datum: 27.02.2021
• Dokumenttyp: Peer-reviewter Forschungsbeitrag
• Status: ACM Queue / Developer-Productivity-Forschung
• Relevanz: Produktivität ist mehrdimensional und nicht durch eine Einzelmetrik messbar.
• Refresh-Priorität: niedrig
• Direkte URL: [https://www.microsoft.com/en-us/research/publication/the-space-of-developer-productivity-theres-more-to-it-than-you-think/](https://www.microsoft.com/en-us/research/publication/the-space-of-developer-productivity-theres-more-to-it-than-you-think/)

^[S-010] State of AI-assisted Software Development 2025

• Autor/Herausgeber: DORA / Google Cloud
• Datum: 09.2025
• Dokumenttyp: Empirischer Branchenforschungsbericht
• Status: Aktueller Jahresbericht
• Relevanz: AI als Verstärker vorhandener organisatorischer Stärken und Schwächen.
• Refresh-Priorität: hoch
• Direkte URL: [https://dora.dev/dora-report-2025/](https://dora.dev/dora-report-2025/)

^[S-011] Accelerate State of DevOps Report 2024

• Autor/Herausgeber: DORA / Google Cloud
• Datum: 2024; Korrekturfassung v2024.3, geprüft 08.08.2026
• Dokumenttyp: Empirischer Branchenforschungsbericht
• Status: Revidierte Berichtsfassung
• Relevanz: Softwarelieferung, Plattformengineering, Nutzerfokus und KI-Nutzung.
• Refresh-Priorität: hoch
• Direkte URL: [https://dora.dev/research/2024/dora-report/](https://dora.dev/research/2024/dora-report/)

^[S-012] DORA software delivery performance metrics

• Autor/Herausgeber: DORA / Google Cloud
• Datum: 05.01.2026
• Dokumenttyp: Offizielle Forschungs-/Methodendokumentation
• Status: Living Documentation
• Relevanz: Metriken für Durchsatz und Stabilität der Softwarelieferung.
• Refresh-Priorität: hoch
• Direkte URL: [https://dora.dev/guides/dora-metrics/](https://dora.dev/guides/dora-metrics/)

Build und Betrieb

^[S-013] The Twelve-Factor App

• Autor/Herausgeber: Adam Wiggins / Twelve-Factor App
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Technische Referenz
• Status: Living Documentation
• Relevanz: Prinzipien für Konfiguration, Abhängigkeiten, Build-Release-Run und Umgebungsparität.
• Refresh-Priorität: mittel
• Direkte URL: [https://12factor.net/](https://12factor.net/)

^[S-014] Build, release, run

• Autor/Herausgeber: Twelve-Factor App
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Technische Referenz
• Status: Living Documentation
• Relevanz: Strikte Trennung von Build, Release und Laufzeit.
• Refresh-Priorität: mittel
• Direkte URL: [https://12factor.net/build-release-run](https://12factor.net/build-release-run)

Konfiguration und Secrets

^[S-015] Config

• Autor/Herausgeber: Twelve-Factor App
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Technische Referenz
• Status: Living Documentation
• Relevanz: Trennung deploy-spezifischer Konfiguration vom Code.
• Refresh-Priorität: mittel
• Direkte URL: [https://12factor.net/config](https://12factor.net/config)

Versionsverwaltung

^[S-016] Pro Git, Second Edition

• Autor/Herausgeber: Scott Chacon und Ben Straub / Git
• Datum: Living Book; geprüft 08.08.2026
• Dokumenttyp: Offizielles Fachbuch
• Status: Living Documentation
• Relevanz: Grundlage für verteilte Versionsverwaltung und nachvollziehbare Änderungen.
• Refresh-Priorität: mittel
• Direkte URL: [https://git-scm.com/book/en/v2](https://git-scm.com/book/en/v2)

^[S-017] About Version Control

• Autor/Herausgeber: Git
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Dokumentation
• Status: Living Documentation
• Relevanz: Zweck und Nutzen von Versionsverwaltung.
• Refresh-Priorität: mittel
• Direkte URL: [https://git-scm.com/book/en/v2/Getting-Started-About-Version-Control](https://git-scm.com/book/en/v2/Getting-Started-About-Version-Control)

Versionierung

^[S-018] Semantic Versioning 2.0.0

• Autor/Herausgeber: Semantic Versioning
• Datum: 2013
• Dokumenttyp: Offene Spezifikation
• Status: Version 2.0.0
• Relevanz: Maschinen- und menschenlesbare Regeln für kompatible und inkompatible Versionsänderungen.
• Refresh-Priorität: niedrig
• Direkte URL: [https://semver.org/](https://semver.org/)

Build und Lieferkette

^[S-019] Definitions — Reproducible Builds

• Autor/Herausgeber: Reproducible Builds project
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Reproduzierbare Artefakte aus identischen Quellen, Abhängigkeiten und Build-Anweisungen.
• Refresh-Priorität: mittel
• Direkte URL: [https://reproducible-builds.org/docs/definition/](https://reproducible-builds.org/docs/definition/)

Architektur und Dokumentation

^[S-020] Documenting Architecture Decisions

• Autor/Herausgeber: Michael Nygard
• Datum: 2011
• Dokumenttyp: Technischer Fachbeitrag
• Status: Originalbeitrag zum ADR-Muster
• Relevanz: Leichte, versionierbare Dokumentation wichtiger Architekturentscheidungen.
• Refresh-Priorität: niedrig
• Direkte URL: [https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions](https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions)

^[S-021] The C4 model for visualising software architecture

• Autor/Herausgeber: Simon Brown
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Methodendokumentation
• Status: Living Documentation
• Relevanz: Hierarchische Architekturdarstellung von Kontext bis Code.
• Refresh-Priorität: mittel
• Direkte URL: [https://c4model.com/](https://c4model.com/)

Secure SDLC

^[S-022] SP 800-218 — Secure Software Development Framework (SSDF) Version 1.1

• Autor/Herausgeber: NIST
• Datum: 03.02.2022
• Dokumenttyp: Behördenstandard
• Status: Final
• Relevanz: Sicherheitspraktiken, die in unterschiedliche SDLC-Modelle integriert werden können.
• Refresh-Priorität: mittel
• Direkte URL: [https://csrc.nist.gov/pubs/sp/800/218/final](https://csrc.nist.gov/pubs/sp/800/218/final)

^[S-023] SP 800-218 Rev. 1 — SSDF Version 1.2

• Autor/Herausgeber: NIST
• Datum: 17.12.2025
• Dokumenttyp: Behördenentwurf
• Status: Draft am Stichtag; nicht als final behandeln
• Relevanz: Aktueller Entwicklungsstand des SSDF; Statusabgrenzung zu Version 1.1.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://csrc.nist.gov/projects/ssdf/publications](https://csrc.nist.gov/projects/ssdf/publications)

Secure AI Development

^[S-024] SP 800-218A — Secure Software Development Practices for Generative AI and Dual-Use Foundation Models

• Autor/Herausgeber: NIST
• Datum: 26.07.2024
• Dokumenttyp: Behördenstandard / Community Profile
• Status: Final
• Relevanz: Ergänzt SSDF 1.1 um Praktiken für KI-Modelle und KI-Systeme.
• Refresh-Priorität: hoch
• Direkte URL: [https://csrc.nist.gov/pubs/sp/800/218/a/final](https://csrc.nist.gov/pubs/sp/800/218/a/final)

Cybersecurity-Governance

^[S-025] The NIST Cybersecurity Framework (CSF) 2.0

• Autor/Herausgeber: NIST
• Datum: 26.02.2024
• Dokumenttyp: Behördenrahmenwerk
• Status: Final
• Relevanz: Govern, Identify, Protect, Detect, Respond und Recover als Cyber-Risikofunktionen.
• Refresh-Priorität: mittel
• Direkte URL: [https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final)

Incident Response

^[S-026] SP 800-61 Rev. 3 — Incident Response Recommendations and Considerations for Cybersecurity Risk Management

• Autor/Herausgeber: NIST
• Datum: 03.04.2025
• Dokumenttyp: Behördenstandard / Community Profile
• Status: Final
• Relevanz: Incident Response als Teil des laufenden Cyber-Risikomanagements.
• Refresh-Priorität: mittel
• Direkte URL: [https://csrc.nist.gov/pubs/sp/800/61/r3/final](https://csrc.nist.gov/pubs/sp/800/61/r3/final)

Security Testing

^[S-027] SP 800-115 — Technical Guide to Information Security Testing and Assessment

• Autor/Herausgeber: NIST
• Datum: 09.2008
• Dokumenttyp: Behördenleitfaden
• Status: Final; methodische Grundlage
• Relevanz: Planung und Durchführung technischer Sicherheitsprüfungen.
• Refresh-Priorität: niedrig
• Direkte URL: [https://csrc.nist.gov/pubs/sp/800/115/final](https://csrc.nist.gov/pubs/sp/800/115/final)

Backup und Notfallbetrieb

^[S-028] SP 800-34 Rev. 1 — Contingency Planning Guide for Federal Information Systems

• Autor/Herausgeber: NIST
• Datum: 11.11.2010
• Dokumenttyp: Behördenleitfaden
• Status: Final; älter, aber weiterhin referenziert
• Relevanz: Business Impact Analysis, Wiederanlauf, Übungen und Pflege von Notfallplänen.
• Refresh-Priorität: mittel
• Direkte URL: [https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final](https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final)

KI-Governance und Evaluation

^[S-029] NIST AI 600-1 — Artificial Intelligence Risk Management Framework: Generative AI Profile

• Autor/Herausgeber: NIST
• Datum: 26.07.2024
• Dokumenttyp: Behördenprofil
• Status: Final
• Relevanz: Risikomanagementmaßnahmen für generative KI über den Lebenszyklus.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence](https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence)

KI-Sicherheit

^[S-030] NIST AI 100-2e2025 — Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations

• Autor/Herausgeber: NIST
• Datum: 03.2025
• Dokumenttyp: Behördenbericht
• Status: Final
• Relevanz: Taxonomie adversarialer Angriffe und Gegenmaßnahmen.
• Refresh-Priorität: mittel
• Direkte URL: [https://doi.org/10.6028/NIST.AI.100-2e2025](https://doi.org/10.6028/NIST.AI.100-2e2025)

Backup und Notfallbetrieb

^[S-031] BSI-Standard 200-4 — Business Continuity Management

• Autor/Herausgeber: Bundesamt für Sicherheit in der Informationstechnik
• Datum: 14.06.2023
• Dokumenttyp: Behördenstandard
• Status: Final
• Relevanz: Praxisrahmen zum Aufbau eines BCMS.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/BSI_Standards/standard_200_4.html](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/BSI_Standards/standard_200_4.html)

Cybersecurity-Governance

^[S-032] ISO/IEC 27001:2022 — Information security management systems — Requirements

• Autor/Herausgeber: ISO / IEC
• Datum: 2022
• Dokumenttyp: Internationaler Standard
• Status: Aktuelle Ausgabe
• Relevanz: Anforderungen an ein Informationssicherheits-Managementsystem.
• Refresh-Priorität: niedrig
• Direkte URL: [https://www.iso.org/standard/27001](https://www.iso.org/standard/27001)

Backup und Notfallbetrieb

^[S-033] ISO 22301:2019 — Security and resilience — Business continuity management systems

• Autor/Herausgeber: ISO
• Datum: 2019
• Dokumenttyp: Internationaler Standard
• Status: Aktuelle Ausgabe am Stichtag
• Relevanz: Anforderungen an Business-Continuity-Managementsysteme.
• Refresh-Priorität: niedrig
• Direkte URL: [https://www.iso.org/standard/75106.html](https://www.iso.org/standard/75106.html)

Versionsverwaltung und Review

^[S-034] About protected branches

• Autor/Herausgeber: GitHub
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Schutzregeln, Reviews und Statusprüfungen für zentrale Branches.
• Refresh-Priorität: hoch
• Direkte URL: [https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches](https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches)

CI und Qualitätsgates

^[S-035] About status checks

• Autor/Herausgeber: GitHub
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Automatisierte Prüfergebnisse als Merge-Bedingung.
• Refresh-Priorität: hoch
• Direkte URL: [https://docs.github.com/en/pull-requests/reference/status-checks](https://docs.github.com/en/pull-requests/reference/status-checks)

CI/CD-Sicherheit

^[S-036] Secure use reference — GitHub Actions

• Autor/Herausgeber: GitHub
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Sicherheitskontrollen für CI/CD-Workflows und Umgebungsfreigaben.
• Refresh-Priorität: hoch
• Direkte URL: [https://docs.github.com/en/actions/reference/security/secure-use](https://docs.github.com/en/actions/reference/security/secure-use)

Deployment

^[S-037] Managing environments for deployment

• Autor/Herausgeber: GitHub
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Deployment-Schutzregeln und getrennte Umgebungssecrets.
• Refresh-Priorität: hoch
• Direkte URL: [https://docs.github.com/actions/deployment/targeting-different-environments/using-environments-for-deployment](https://docs.github.com/actions/deployment/targeting-different-environments/using-environments-for-deployment)

CI/CD-Sicherheit

^[S-038] OpenID Connect in GitHub Actions

• Autor/Herausgeber: GitHub
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Kurzlebige föderierte Cloud-Anmeldung statt dauerhaft gespeicherter Zugangsschlüssel.
• Refresh-Priorität: hoch
• Direkte URL: [https://docs.github.com/en/actions/concepts/security/openid-connect](https://docs.github.com/en/actions/concepts/security/openid-connect)

Software-Lieferkette

^[S-039] Using artifact attestations to establish provenance for builds

• Autor/Herausgeber: GitHub
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Provenienz- und Attestierungsfunktionen für Build-Artefakte.
• Refresh-Priorität: hoch
• Direkte URL: [https://docs.github.com/en/actions/security-for-github-actions/using-artifact-attestations/using-artifact-attestations-to-establish-provenance-for-builds](https://docs.github.com/en/actions/security-for-github-actions/using-artifact-attestations/using-artifact-attestations-to-establish-provenance-for-builds)

Schnittstellen und Verträge

^[S-040] OpenAPI Specification 3.2.0

• Autor/Herausgeber: OpenAPI Initiative
• Datum: 19.09.2025
• Dokumenttyp: Offene Spezifikation
• Status: Aktuelle Fassung am Stichtag
• Relevanz: Maschinenlesbarer Vertrag für HTTP-APIs.
• Refresh-Priorität: hoch
• Direkte URL: [https://spec.openapis.org/oas/v3.2.0.html](https://spec.openapis.org/oas/v3.2.0.html)

^[S-041] JSON Schema — Draft 2020-12 Core

• Autor/Herausgeber: JSON Schema project
• Datum: 31.08.2022
• Dokumenttyp: Offene Spezifikation
• Status: Aktuelle stabile Draft-Familie am Stichtag
• Relevanz: Validierung und Beschreibung strukturierter JSON-Daten.
• Refresh-Priorität: mittel
• Direkte URL: [https://json-schema.org/draft/2020-12/json-schema-core](https://json-schema.org/draft/2020-12/json-schema-core)

Schnittstellen und Reliability

^[S-042] RFC 9110 — HTTP Semantics

• Autor/Herausgeber: IETF / Fielding, Nottingham und Reschke
• Datum: 06.2022
• Dokumenttyp: Internetstandard
• Status: Standards Track
• Relevanz: HTTP-Semantik, Methoden, Statuscodes und Idempotenz.
• Refresh-Priorität: niedrig
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc9110.html](https://www.rfc-editor.org/rfc/rfc9110.html)

Schnittstellen und Fehlerbehandlung

^[S-043] RFC 9457 — Problem Details for HTTP APIs

• Autor/Herausgeber: IETF / Nottingham, Wilde und Dalal
• Datum: 07.2023
• Dokumenttyp: Internetstandard
• Status: Standards Track
• Relevanz: Standardisiertes Fehlerformat für HTTP-APIs.
• Refresh-Priorität: niedrig
• Direkte URL: [https://www.rfc-editor.org/rfc/rfc9457.html](https://www.rfc-editor.org/rfc/rfc9457.html)

Ereignisse und Integration

^[S-044] CloudEvents Specification 1.0.2

• Autor/Herausgeber: Cloud Native Computing Foundation
• Datum: 03.02.2022
• Dokumenttyp: Offene Spezifikation
• Status: Version 1.0.2
• Relevanz: Standardisiertes Ereignisformat für verteilte Systeme.
• Refresh-Priorität: mittel
• Direkte URL: [https://github.com/cloudevents/spec/blob/v1.0.2/cloudevents/spec.md](https://github.com/cloudevents/spec/blob/v1.0.2/cloudevents/spec.md)

^[S-045] AsyncAPI Specification 3.1.0

• Autor/Herausgeber: AsyncAPI Initiative
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offene Spezifikation
• Status: Aktuelle Fassung am Stichtag
• Relevanz: Maschinenlesbare Verträge für ereignis- und nachrichtenbasierte Schnittstellen.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.asyncapi.com/docs/reference/specification/v3.1.0](https://www.asyncapi.com/docs/reference/specification/v3.1.0)

Softwaretests

^[S-046] Test Sizes

• Autor/Herausgeber: Google Testing Blog
• Datum: 14.12.2010
• Dokumenttyp: Technischer Fachbeitrag
• Status: Google-Testpraxis; historisch stabil
• Relevanz: Abgrenzung kleiner, mittlerer und großer Tests nach Ressourcen und Laufzeit.
• Refresh-Priorität: niedrig
• Direkte URL: [https://testing.googleblog.com/2010/12/test-sizes.html](https://testing.googleblog.com/2010/12/test-sizes.html)

^[S-047] The Practical Test Pyramid

• Autor/Herausgeber: Martin Fowler
• Datum: 01.02.2018
• Dokumenttyp: Technischer Fachbeitrag
• Status: Praxisreferenz
• Relevanz: Mehrschichtige Teststrategie statt ausschließlicher End-to-End-Tests.
• Refresh-Priorität: niedrig
• Direkte URL: [https://martinfowler.com/articles/practical-test-pyramid.html](https://martinfowler.com/articles/practical-test-pyramid.html)

^[S-048] Contract testing

• Autor/Herausgeber: Pact Foundation
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Konsumentengetriebene Vertragsprüfungen zwischen Diensten.
• Refresh-Priorität: hoch
• Direkte URL: [https://docs.pact.io/](https://docs.pact.io/)

Security Testing

^[S-049] Web Security Testing Guide

• Autor/Herausgeber: OWASP
• Datum: Version 4.2; Version 5 in Entwicklung, geprüft 08.08.2026
• Dokumenttyp: Offener Security-Standard
• Status: Aktuelle veröffentlichte Ausgabe 4.2
• Relevanz: Systematische Webanwendungs-Sicherheitstests.
• Refresh-Priorität: hoch
• Direkte URL: [https://owasp.org/www-project-web-security-testing-guide/](https://owasp.org/www-project-web-security-testing-guide/)

^[S-050] Application Security Verification Standard 5.0.0

• Autor/Herausgeber: OWASP
• Datum: 30.05.2025
• Dokumenttyp: Offener Security-Standard
• Status: Aktuelle Hauptversion
• Relevanz: Prüfbare Sicherheitsanforderungen für Webanwendungen und Services.
• Refresh-Priorität: hoch
• Direkte URL: [https://owasp.org/www-project-application-security-verification-standard/](https://owasp.org/www-project-application-security-verification-standard/)

^[S-051] OWASP Top 10:2025

• Autor/Herausgeber: OWASP
• Datum: 2025
• Dokumenttyp: Offener Security-Standard
• Status: Aktuelle Ausgabe
• Relevanz: Häufige und folgenreiche Risiken in Webanwendungen.
• Refresh-Priorität: hoch
• Direkte URL: [https://owasp.org/Top10/2025/](https://owasp.org/Top10/2025/)

API-Sicherheit

^[S-052] OWASP API Security Top 10 — 2023

• Autor/Herausgeber: OWASP
• Datum: 2023
• Dokumenttyp: Offener Security-Standard
• Status: Aktuelle Ausgabe am Stichtag
• Relevanz: Risikokategorien für APIs, einschließlich Autorisierung und Ressourcenverbrauch.
• Refresh-Priorität: hoch
• Direkte URL: [https://owasp.org/API-Security/editions/2023/en/0x11-t10/](https://owasp.org/API-Security/editions/2023/en/0x11-t10/)

Konfiguration und Secrets

^[S-053] Secrets Management Cheat Sheet

• Autor/Herausgeber: OWASP Cheat Sheet Series
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Security-Leitlinie
• Status: Living Documentation
• Relevanz: Lebenszyklus und Schutz von Zugangsdaten und Schlüsseln.
• Refresh-Priorität: hoch
• Direkte URL: [https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html)

Observability und Security

^[S-054] Logging Cheat Sheet

• Autor/Herausgeber: OWASP Cheat Sheet Series
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Security-Leitlinie
• Status: Living Documentation
• Relevanz: Sicherheitsrelevante Protokollierung ohne unnötige Geheimnis- oder Personendaten.
• Refresh-Priorität: hoch
• Direkte URL: [https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html)

Anwendungssicherheit

^[S-055] Authorization Cheat Sheet

• Autor/Herausgeber: OWASP Cheat Sheet Series
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Security-Leitlinie
• Status: Living Documentation
• Relevanz: Serverseitige Autorisierung und Least Privilege.
• Refresh-Priorität: hoch
• Direkte URL: [https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html)

KI-Sicherheit

^[S-056] OWASP GenAI LLM Top 10 2026

• Autor/Herausgeber: OWASP GenAI Security Project
• Datum: 03.08.2026
• Dokumenttyp: Offener Security-Standard
• Status: Aktuelle Ausgabe am Stichtag
• Relevanz: Aktuelle Risikokategorien für generative KI-Anwendungen.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/](https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/)

^[S-057] MITRE ATLAS — Adversarial Threat Landscape for Artificial-Intelligence Systems

• Autor/Herausgeber: MITRE
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offene Wissensbasis
• Status: Living Knowledge Base
• Relevanz: Taktiken und Techniken gegen KI-fähige Systeme.
• Refresh-Priorität: hoch
• Direkte URL: [https://atlas.mitre.org/](https://atlas.mitre.org/)

KI-Produktion

^[S-058] Hidden Technical Debt in Machine Learning Systems

• Autor/Herausgeber: Sculley et al. / Google Research
• Datum: 2015
• Dokumenttyp: Peer-reviewter Forschungsbeitrag
• Status: NeurIPS 2015
• Relevanz: ML-Systeme erzeugen zusätzliche Daten-, Abhängigkeits- und Rückkopplungsschulden.
• Refresh-Priorität: niedrig
• Direkte URL: [https://research.google/pubs/hidden-technical-debt-in-machine-learning-systems/](https://research.google/pubs/hidden-technical-debt-in-machine-learning-systems/)

^[S-059] The ML Test Score: A Rubric for ML Production Readiness and Technical Debt Reduction

• Autor/Herausgeber: Breck et al. / Google Research
• Datum: 2017
• Dokumenttyp: Forschungsbeitrag
• Status: Publizierte Praxisforschung
• Relevanz: 28 Test- und Monitoringbedarfe für produktive ML-Systeme.
• Refresh-Priorität: niedrig
• Direkte URL: [https://research.google/pubs/the-ml-test-score-a-rubric-for-ml-production-readiness-and-technical-debt-reduction/](https://research.google/pubs/the-ml-test-score-a-rubric-for-ml-production-readiness-and-technical-debt-reduction/)

^[S-060] Rules of Machine Learning

• Autor/Herausgeber: Google for Developers
• Datum: 25.08.2025
• Dokumenttyp: Offizielle technische Leitlinie
• Status: Aktualisierte Living Documentation
• Relevanz: Messung vor Modellierung, einfache Baselines und langfristiger ML-Betrieb.
• Refresh-Priorität: hoch
• Direkte URL: [https://developers.google.com/machine-learning/guides/rules-of-ml](https://developers.google.com/machine-learning/guides/rules-of-ml)

^[S-061] Production ML systems: Monitoring pipelines

• Autor/Herausgeber: Google for Developers
• Datum: 16.10.2025
• Dokumenttyp: Offizielle technische Leitlinie
• Status: Living Documentation
• Relevanz: Daten-, Transformations- und Modellüberwachung in ML-Pipelines.
• Refresh-Priorität: hoch
• Direkte URL: [https://developers.google.com/machine-learning/crash-course/production-ml-systems/monitoring](https://developers.google.com/machine-learning/crash-course/production-ml-systems/monitoring)

^[S-062] ML pipelines

• Autor/Herausgeber: Google for Developers
• Datum: 25.08.2025
• Dokumenttyp: Offizielle technische Leitlinie
• Status: Living Documentation
• Relevanz: Automatisierte Entwicklung, Prüfung, Auslieferung und Erneuerung von Modellen.
• Refresh-Priorität: hoch
• Direkte URL: [https://developers.google.com/machine-learning/managing-ml-projects/pipelines](https://developers.google.com/machine-learning/managing-ml-projects/pipelines)

KI-Dokumentation

^[S-063] Model Cards for Model Reporting

• Autor/Herausgeber: Mitchell et al.
• Datum: 05.10.2018
• Dokumenttyp: Originalarbeit / arXiv
• Status: Peer-reviewter Beitrag 2019
• Relevanz: Dokumentation von Einsatzzweck, Evaluation, Grenzen und Gruppenleistung eines Modells.
• Refresh-Priorität: niedrig
• Direkte URL: [https://arxiv.org/abs/1810.03993](https://arxiv.org/abs/1810.03993)

Daten-Governance

^[S-064] Datasheets for Datasets

• Autor/Herausgeber: Gebru et al.
• Datum: 23.03.2018
• Dokumenttyp: Originalarbeit / arXiv
• Status: Peer-reviewter Beitrag 2021
• Relevanz: Strukturierte Dokumentation von Herkunft, Zusammensetzung und Nutzung eines Datensatzes.
• Refresh-Priorität: niedrig
• Direkte URL: [https://arxiv.org/abs/1803.09010](https://arxiv.org/abs/1803.09010)

KI-Evaluation

^[S-065] Holistic Evaluation of Language Models

• Autor/Herausgeber: Liang et al.
• Datum: 16.11.2022
• Dokumenttyp: Originalarbeit / arXiv
• Status: Forschungsbenchmark
• Relevanz: Mehrdimensionale Modellbewertung statt einzelner Benchmarkzahl.
• Refresh-Priorität: mittel
• Direkte URL: [https://arxiv.org/abs/2211.09110](https://arxiv.org/abs/2211.09110)

^[S-066] Evaluation best practices

• Autor/Herausgeber: OpenAI
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Aktueller Leitfaden; Evals-Plattform mit angekündigter Abschaltung zum 30.11.2026
• Relevanz: Herstellerpraxis für aufgabenspezifische Datensätze, Evaluatoren, menschliche Kalibrierung und kontinuierliche Evaluation.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://developers.openai.com/api/docs/guides/evaluation-best-practices](https://developers.openai.com/api/docs/guides/evaluation-best-practices)

^[S-067] Define success criteria and build evaluations

• Autor/Herausgeber: Anthropic
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Erfolgskriterien, Testfälle und Evaluation für LLM-Anwendungen.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://platform.claude.com/docs/en/test-and-evaluate/develop-tests](https://platform.claude.com/docs/en/test-and-evaluate/develop-tests)

Container und Build

^[S-068] Building best practices

• Autor/Herausgeber: Docker
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Kleine Build-Kontexte, Multi-Stage Builds, Version-Pinning und regelmäßige Rebuilds.
• Refresh-Priorität: hoch
• Direkte URL: [https://docs.docker.com/build/building/best-practices/](https://docs.docker.com/build/building/best-practices/)

^[S-069] Image digests and immutability

• Autor/Herausgeber: Docker
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Unveränderliche Inhaltsadressierung von Containerbildern.
• Refresh-Priorität: hoch
• Direkte URL: [https://docs.docker.com/dhi/explore/security-concepts/digests/](https://docs.docker.com/dhi/explore/security-concepts/digests/)

^[S-070] OCI Image Format Specification

• Autor/Herausgeber: Open Container Initiative
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offene Spezifikation
• Status: Living Specification
• Relevanz: Standardisiertes Format für Container-Images und Manifeste.
• Refresh-Priorität: mittel
• Direkte URL: [https://specs.opencontainers.org/image-spec/](https://specs.opencontainers.org/image-spec/)

Deployment und Skalierung

^[S-071] Deployments

• Autor/Herausgeber: Kubernetes
• Datum: 18.06.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Rollout, ReplicaSets, Status und Rollback von Deployments.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://kubernetes.io/docs/concepts/workloads/controllers/deployment/](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/)

^[S-072] Performing a Rolling Update

• Autor/Herausgeber: Kubernetes
• Datum: 12.03.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Schrittweiser Ersatz laufender Instanzen bei einem Release.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://kubernetes.io/docs/tutorials/kubernetes-basics/update/update-intro/](https://kubernetes.io/docs/tutorials/kubernetes-basics/update/update-intro/)

^[S-073] Configure Liveness, Readiness and Startup Probes

• Autor/Herausgeber: Kubernetes
• Datum: 17.04.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Unterscheidung von Startbereitschaft, Verkehrsbereitschaft und Lebenszeichen.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)

^[S-074] Horizontal Pod Autoscaling

• Autor/Herausgeber: Kubernetes
• Datum: 15.03.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Automatische Replikaanpassung anhand definierter Metriken.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://kubernetes.io/docs/concepts/workloads/autoscaling/horizontal-pod-autoscale/](https://kubernetes.io/docs/concepts/workloads/autoscaling/horizontal-pod-autoscale/)

Release-Steuerung

^[S-075] OpenFeature Specification and Documentation

• Autor/Herausgeber: OpenFeature / CNCF
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offene Spezifikation
• Status: Living Documentation
• Relevanz: Anbieterneutrale API für Feature-Flag-Auswertung.
• Refresh-Priorität: hoch
• Direkte URL: [https://openfeature.dev/specification/](https://openfeature.dev/specification/)

^[S-076] Argo Rollouts Documentation

• Autor/Herausgeber: Argo Project / CNCF
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Progressive Delivery mit Canary- und Blue-Green-Strategien.
• Refresh-Priorität: hoch
• Direkte URL: [https://argo-rollouts.readthedocs.io/](https://argo-rollouts.readthedocs.io/)

Infrastructure as Code

^[S-077] OpenGitOps Principles

• Autor/Herausgeber: OpenGitOps / CNCF
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offene Spezifikation
• Status: Living Documentation
• Relevanz: Deklarative, versionierte, automatisch abgeglichene und kontinuierlich angewandte Zustände.
• Refresh-Priorität: hoch
• Direkte URL: [https://opengitops.dev/](https://opengitops.dev/)

^[S-078] Infrastructure as Code

• Autor/Herausgeber: HashiCorp
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Deklarative Verwaltung von Infrastruktur.
• Refresh-Priorität: hoch
• Direkte URL: [https://developer.hashicorp.com/terraform/intro](https://developer.hashicorp.com/terraform/intro)

Software-Lieferkette

^[S-079] SLSA Specification Version 1.2

• Autor/Herausgeber: SLSA Community / Linux Foundation
• Datum: 24.11.2025
• Dokumenttyp: Offene Lieferketten-Spezifikation
• Status: Approved Specification
• Relevanz: Anforderungen für Quell- und Build-Provenienz sowie Lieferkettenhärtung.
• Refresh-Priorität: hoch
• Direkte URL: [https://slsa.dev/spec/v1.2/](https://slsa.dev/spec/v1.2/)

^[S-080] in-toto Specification and Attestation Framework

• Autor/Herausgeber: in-toto project
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offene Spezifikation
• Status: Living Documentation
• Relevanz: Nachweis und Verifikation von Schritten einer Software-Lieferkette.
• Refresh-Priorität: hoch
• Direkte URL: [https://in-toto.io/](https://in-toto.io/)

^[S-081] Sigstore Documentation

• Autor/Herausgeber: Sigstore project
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Signierung, Transparenz und Verifikation von Software-Artefakten.
• Refresh-Priorität: hoch
• Direkte URL: [https://docs.sigstore.dev/](https://docs.sigstore.dev/)

SBOM und Transparenz

^[S-082] SPDX Specifications

• Autor/Herausgeber: SPDX / Linux Foundation
• Datum: Living Documentation; geprüft 08.08.2026
• Dokumenttyp: Offene Spezifikation
• Status: SPDX 3.0 als aktuelle Hauptversion; Status einzelner Unterversionen schnell veraltend
• Relevanz: Maschinenlesbare BOM-Informationen einschließlich Software-, Security-, AI- und Dataset-Profilen.
• Refresh-Priorität: hoch
• Direkte URL: [https://spdx.dev/use/specifications/](https://spdx.dev/use/specifications/)

^[S-083] CycloneDX v1.7

• Autor/Herausgeber: OWASP CycloneDX
• Datum: 21.10.2025
• Dokumenttyp: Offene Spezifikation
• Status: Aktuelle finale 1.x-Version
• Relevanz: xBOM-Format mit Software-, Daten-, ML-, Kryptografie- und Provenienzinformationen.
• Refresh-Priorität: hoch
• Direkte URL: [https://cyclonedx.org/news/cyclonedx-v1.7-released/](https://cyclonedx.org/news/cyclonedx-v1.7-released/)

^[S-084] 2026 Minimum Elements for a Software Bill of Materials

• Autor/Herausgeber: CISA
• Datum: 29.07.2026
• Dokumenttyp: Behördenleitlinie
• Status: Aktuelle Ausgabe
• Relevanz: Aktualisierte Mindestinhalte einer SBOM.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://www.cisa.gov/resources-tools/resources/2026-minimum-elements-software-bill-materials-sbom](https://www.cisa.gov/resources-tools/resources/2026-minimum-elements-software-bill-materials-sbom)

^[S-085] Software Bill of Materials for AI — Minimum Elements

• Autor/Herausgeber: CISA
• Datum: 12.05.2026
• Dokumenttyp: Behördenleitlinie
• Status: Aktuelle Ausgabe
• Relevanz: Transparenzanforderungen für Komponenten von KI-Systemen.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://www.cisa.gov/resources-tools/resources/software-bill-materials-ai-minimum-elements](https://www.cisa.gov/resources-tools/resources/software-bill-materials-ai-minimum-elements)

Abhängigkeitsrisiko

^[S-086] OpenSSF Scorecard

• Autor/Herausgeber: OpenSSF
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielles Open-Source-Projekt
• Status: Living Documentation
• Relevanz: Automatisierte Hinweise auf Sicherheitspraktiken von Open-Source-Projekten.
• Refresh-Priorität: hoch
• Direkte URL: [https://securityscorecards.dev/](https://securityscorecards.dev/)

^[S-087] Open Source Project Security Baseline — Version 2025-10-10

• Autor/Herausgeber: OpenSSF
• Datum: 10.10.2025
• Dokumenttyp: Offener Security-Standard
• Status: Aktuelle veröffentlichte Version am Stichtag
• Relevanz: Maturitätsgestufte Sicherheitskontrollen für Open-Source-Projekte.
• Refresh-Priorität: hoch
• Direkte URL: [https://baseline.openssf.org/versions/2025-10-10.html](https://baseline.openssf.org/versions/2025-10-10.html)

Secure SDLC

^[S-088] Secure by Design

• Autor/Herausgeber: CISA
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Behördenleitlinie
• Status: Living Guidance
• Relevanz: Herstellerverantwortung und sichere Standardeinstellungen.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.cisa.gov/resources-tools/resources/secure-by-design](https://www.cisa.gov/resources-tools/resources/secure-by-design)

^[S-089] Product Security Bad Practices

• Autor/Herausgeber: CISA
• Datum: 17.01.2025
• Dokumenttyp: Behördenleitlinie
• Status: Final
• Relevanz: Klar benannte Praktiken, die bei kritischer Software vermieden werden sollen.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.cisa.gov/resources-tools/resources/product-security-bad-practices](https://www.cisa.gov/resources-tools/resources/product-security-bad-practices)

Recht und Produktbetrieb

^[S-090] Verordnung (EU) 2024/2847 — Cyber Resilience Act

• Autor/Herausgeber: Europäische Union
• Datum: 23.10.2024; ABl. 20.11.2024
• Dokumenttyp: EU-Verordnung
• Status: In Kraft; gestaffelte Anwendung
• Relevanz: Horizontale Cybersicherheitsanforderungen für Produkte mit digitalen Elementen.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng)

^[S-091] Horizontal cybersecurity requirements for products with digital elements — summary

• Autor/Herausgeber: EUR-Lex
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Amtliche Zusammenfassung
• Status: Aktueller Überblick
• Relevanz: Anwendungsfristen und Pflichtenüberblick zum Cyber Resilience Act.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://eur-lex.europa.eu/EN/legal-content/summary/horizontal-cybersecurity-requirements-for-products-with-digital-elements-cyber-resilience-act.html](https://eur-lex.europa.eu/EN/legal-content/summary/horizontal-cybersecurity-requirements-for-products-with-digital-elements-cyber-resilience-act.html)

Reliability

^[S-092] Timeouts, retries, and backoff with jitter

• Autor/Herausgeber: Amazon Web Services
• Datum: 12.06.2026
• Dokumenttyp: Offizieller Engineering-Fachbeitrag
• Status: Aktualisierte Fassung
• Relevanz: Timeouts, begrenzte Wiederholungen, Backoff, Jitter und Retry-Amplifikation.
• Refresh-Priorität: hoch
• Direkte URL: [https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)

^[S-093] Making retries safe with idempotent APIs

• Autor/Herausgeber: Amazon Web Services
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizieller Engineering-Fachbeitrag
• Status: Living Documentation
• Relevanz: Idempotenzschlüssel und sichere Wiederholbarkeit zustandsändernder Operationen.
• Refresh-Priorität: hoch
• Direkte URL: [https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/)

^[S-094] Idempotent requests

• Autor/Herausgeber: Stripe
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Konkrete API-Praxis für Idempotenzschlüssel.
• Refresh-Priorität: hoch
• Direkte URL: [https://docs.stripe.com/api/idempotent_requests](https://docs.stripe.com/api/idempotent_requests)

Messaging und Reliability

^[S-095] Consumer Acknowledgements and Publisher Confirms

• Autor/Herausgeber: RabbitMQ
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Bestätigungen, erneute Zustellung und Publisher Confirms.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.rabbitmq.com/docs/confirms](https://www.rabbitmq.com/docs/confirms)

^[S-096] Kafka 4.3 Documentation

• Autor/Herausgeber: Apache Kafka
• Datum: 22.05.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Version 4.3
• Relevanz: Nachrichtenpersistenz, Zustellsemantik und Replikation.
• Refresh-Priorität: hoch
• Direkte URL: [https://kafka.apache.org/43/documentation/](https://kafka.apache.org/43/documentation/)

Workflows und Reliability

^[S-097] Durable Execution and Temporal Documentation

• Autor/Herausgeber: Temporal
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Persistenter Workflow-Zustand, Wiederaufnahme und deterministische Workflow-Ausführung.
• Refresh-Priorität: hoch
• Direkte URL: [https://docs.temporal.io/](https://docs.temporal.io/)

Reliability

^[S-098] Circuit Breaker pattern

• Autor/Herausgeber: Microsoft Azure Architecture Center
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Architekturleitlinie
• Status: Living Documentation
• Relevanz: Begrenzung wiederholter Aufrufe zu gestörten Abhängigkeiten.
• Refresh-Priorität: hoch
• Direkte URL: [https://learn.microsoft.com/en-us/azure/architecture/patterns/circuit-breaker](https://learn.microsoft.com/en-us/azure/architecture/patterns/circuit-breaker)

^[S-099] Bulkhead pattern

• Autor/Herausgeber: Microsoft Azure Architecture Center
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Architekturleitlinie
• Status: Living Documentation
• Relevanz: Isolation von Ressourcen und Fehlerdomänen.
• Refresh-Priorität: hoch
• Direkte URL: [https://learn.microsoft.com/en-us/azure/architecture/patterns/bulkhead](https://learn.microsoft.com/en-us/azure/architecture/patterns/bulkhead)

^[S-100] Queue-Based Load Leveling pattern

• Autor/Herausgeber: Microsoft Azure Architecture Center
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Architekturleitlinie
• Status: Living Documentation
• Relevanz: Pufferung von Lastspitzen durch asynchrone Warteschlangen.
• Refresh-Priorität: hoch
• Direkte URL: [https://learn.microsoft.com/en-us/azure/architecture/patterns/queue-based-load-leveling](https://learn.microsoft.com/en-us/azure/architecture/patterns/queue-based-load-leveling)

Site Reliability Engineering

^[S-101] The Site Reliability Workbook

• Autor/Herausgeber: Google
• Datum: 2018
• Dokumenttyp: Offizielles Fachbuch
• Status: Online-Ausgabe
• Relevanz: Praxisrahmen für SLOs, Releases, On-Call, Incident Response und Zuverlässigkeitsarbeit.
• Refresh-Priorität: mittel
• Direkte URL: [https://sre.google/workbook/index/](https://sre.google/workbook/index/)

^[S-102] SRE Engagement Model / Production Readiness Review

• Autor/Herausgeber: Google
• Datum: 2018; Online-Ausgabe geprüft 08.08.2026
• Dokumenttyp: Offizielles Fachbuchkapitel
• Status: Online-Ausgabe
• Relevanz: Produktionsreife, Übergabe und gemeinsame Betriebsverantwortung.
• Refresh-Priorität: mittel
• Direkte URL: [https://sre.google/workbook/engagement-model/](https://sre.google/workbook/engagement-model/)

^[S-103] Canarying Releases

• Autor/Herausgeber: Google
• Datum: 2018; Online-Ausgabe geprüft 08.08.2026
• Dokumenttyp: Offizielles Fachbuchkapitel
• Status: Online-Ausgabe
• Relevanz: Risikoreduktion durch schrittweise Releases und SLO-basierte Bewertung.
• Refresh-Priorität: mittel
• Direkte URL: [https://sre.google/workbook/canarying-releases/](https://sre.google/workbook/canarying-releases/)

^[S-104] Implementing SLOs

• Autor/Herausgeber: Google
• Datum: 2018; Online-Ausgabe geprüft 08.08.2026
• Dokumenttyp: Offizielles Fachbuchkapitel
• Status: Online-Ausgabe
• Relevanz: Definition, Messung und Nutzung von Service Level Objectives.
• Refresh-Priorität: mittel
• Direkte URL: [https://sre.google/workbook/implementing-slos/](https://sre.google/workbook/implementing-slos/)

^[S-105] Alerting on SLOs

• Autor/Herausgeber: Google
• Datum: 2018; Online-Ausgabe geprüft 08.08.2026
• Dokumenttyp: Offizielles Fachbuchkapitel
• Status: Online-Ausgabe
• Relevanz: Burn-Rate-basierte Alarmierung statt rein technischer Schwellenwerte.
• Refresh-Priorität: mittel
• Direkte URL: [https://sre.google/workbook/alerting-on-slos/](https://sre.google/workbook/alerting-on-slos/)

^[S-106] On-Call

• Autor/Herausgeber: Google
• Datum: 2018; Online-Ausgabe geprüft 08.08.2026
• Dokumenttyp: Offizielles Fachbuchkapitel
• Status: Online-Ausgabe
• Relevanz: Betriebsbereitschaft, Eskalation und Balance zwischen Änderung und Stabilität.
• Refresh-Priorität: mittel
• Direkte URL: [https://sre.google/workbook/on-call/](https://sre.google/workbook/on-call/)

Incident Response

^[S-107] Incident Response

• Autor/Herausgeber: Google
• Datum: 2018; Online-Ausgabe geprüft 08.08.2026
• Dokumenttyp: Offizielles Fachbuchkapitel
• Status: Online-Ausgabe
• Relevanz: Incident Command, Kommunikation, Mitigation und Übungen.
• Refresh-Priorität: mittel
• Direkte URL: [https://sre.google/workbook/incident-response/](https://sre.google/workbook/incident-response/)

Datenbetrieb

^[S-108] Data Processing Pipelines

• Autor/Herausgeber: Google
• Datum: 2018; Online-Ausgabe geprüft 08.08.2026
• Dokumenttyp: Offizielles Fachbuchkapitel
• Status: Online-Ausgabe
• Relevanz: Canarying und sichere Mutationen in zustandsbehafteten Datenpipelines.
• Refresh-Priorität: mittel
• Direkte URL: [https://sre.google/workbook/data-processing/](https://sre.google/workbook/data-processing/)

Betrieb und Wartung

^[S-109] Eliminating Toil

• Autor/Herausgeber: Google
• Datum: 2018; Online-Ausgabe geprüft 08.08.2026
• Dokumenttyp: Offizielles Fachbuchkapitel
• Status: Online-Ausgabe
• Relevanz: Reduktion manueller, wiederholbarer Betriebsarbeit.
• Refresh-Priorität: mittel
• Direkte URL: [https://sre.google/workbook/eliminating-toil/](https://sre.google/workbook/eliminating-toil/)

Observability

^[S-110] Signals

• Autor/Herausgeber: OpenTelemetry
• Datum: 10.03.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Traces, Metrics, Logs, Baggage und Profiles als Telemetriesignale.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://opentelemetry.io/docs/concepts/signals/](https://opentelemetry.io/docs/concepts/signals/)

^[S-111] Traces

• Autor/Herausgeber: OpenTelemetry
• Datum: 14.01.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: End-to-End-Sicht auf verteilte Requests.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://opentelemetry.io/docs/concepts/signals/traces/](https://opentelemetry.io/docs/concepts/signals/traces/)

^[S-112] Metrics

• Autor/Herausgeber: OpenTelemetry
• Datum: 02.07.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Laufzeitmessungen und zugeordnete Metadaten.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://opentelemetry.io/docs/concepts/signals/metrics/](https://opentelemetry.io/docs/concepts/signals/metrics/)

^[S-113] Logs

• Autor/Herausgeber: OpenTelemetry
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Log-API, Bridges und Korrelation mit Traces.
• Refresh-Priorität: hoch
• Direkte URL: [https://opentelemetry.io/docs/concepts/signals/logs/](https://opentelemetry.io/docs/concepts/signals/logs/)

^[S-114] Context propagation

• Autor/Herausgeber: OpenTelemetry
• Datum: 14.01.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Korrelation verteilter Telemetriesignale über Prozess- und Netzgrenzen.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://opentelemetry.io/docs/concepts/context-propagation/](https://opentelemetry.io/docs/concepts/context-propagation/)

^[S-115] OpenTelemetry Profiles enters public alpha

• Autor/Herausgeber: OpenTelemetry
• Datum: 26.03.2026
• Dokumenttyp: Offizielle Projektankündigung
• Status: Public Alpha am Stichtag
• Relevanz: Reifegrad kontinuierlicher Profiling-Telemetrie.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://opentelemetry.io/blog/2026/profiles-alpha/](https://opentelemetry.io/blog/2026/profiles-alpha/)

KI-Observability

^[S-116] GenAI semantic conventions

• Autor/Herausgeber: OpenTelemetry
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Spezifikation
• Status: Teilweise experimentell; Living Specification
• Relevanz: Semantische Konventionen für Modellaufrufe, Agenten und GenAI-Ereignisse.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://opentelemetry.io/docs/specs/semconv/gen-ai/](https://opentelemetry.io/docs/specs/semconv/gen-ai/)

Observability

^[S-117] Trace Context — Recommendation

• Autor/Herausgeber: W3C
• Datum: 23.11.2021
• Dokumenttyp: Webstandard
• Status: W3C Recommendation
• Relevanz: Interoperable Weitergabe von Trace-Kontext über Systeme.
• Refresh-Priorität: niedrig
• Direkte URL: [https://www.w3.org/TR/trace-context/](https://www.w3.org/TR/trace-context/)

^[S-118] Instrumentation

• Autor/Herausgeber: Prometheus
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Praktiken zur Instrumentierung von Diensten.
• Refresh-Priorität: hoch
• Direkte URL: [https://prometheus.io/docs/practices/instrumentation/](https://prometheus.io/docs/practices/instrumentation/)

^[S-119] Metric and label naming

• Autor/Herausgeber: Prometheus
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Konsistente Metrik- und Labelbenennung.
• Refresh-Priorität: hoch
• Direkte URL: [https://prometheus.io/docs/practices/naming/](https://prometheus.io/docs/practices/naming/)

Datenbankbetrieb

^[S-120] PostgreSQL 18 Released

• Autor/Herausgeber: PostgreSQL Global Development Group
• Datum: 25.09.2025
• Dokumenttyp: Offizielle Release-Mitteilung
• Status: Version 18
• Relevanz: Aktueller Major-Stand der referenzierten PostgreSQL-Dokumentation.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.postgresql.org/about/news/postgresql-18-released-3142/](https://www.postgresql.org/about/news/postgresql-18-released-3142/)

^[S-121] PostgreSQL 18 Documentation — Transactions

• Autor/Herausgeber: PostgreSQL Global Development Group
• Datum: Version 18; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Atomare Änderungen und Rollback innerhalb von Transaktionen.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.postgresql.org/docs/18/tutorial-transactions.html](https://www.postgresql.org/docs/18/tutorial-transactions.html)

Backup und Restore

^[S-122] PostgreSQL 18 Documentation — Backup and Restore

• Autor/Herausgeber: PostgreSQL Global Development Group
• Datum: Version 18; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: SQL-Dumps, Dateisystem-Backups und kontinuierliche Archivierung.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.postgresql.org/docs/current/backup.html](https://www.postgresql.org/docs/current/backup.html)

^[S-123] Continuous Archiving and Point-in-Time Recovery

• Autor/Herausgeber: PostgreSQL Global Development Group
• Datum: Version 18; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: WAL-Archivierung und Wiederherstellung auf einen früheren Zeitpunkt.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.postgresql.org/docs/current/continuous-archiving.html](https://www.postgresql.org/docs/current/continuous-archiving.html)

^[S-124] Log-Shipping Standby Servers

• Autor/Herausgeber: PostgreSQL Global Development Group
• Datum: Version 18; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Warm-Standby- und Streaming-Replikationsgrundlagen.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.postgresql.org/docs/current/warm-standby.html](https://www.postgresql.org/docs/current/warm-standby.html)

^[S-125] SQL Dump

• Autor/Herausgeber: PostgreSQL Global Development Group
• Datum: Version 18; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Logische Exporte und Wiederherstellung, auch über Versionsgrenzen hinweg.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.postgresql.org/docs/current/backup-dump.html](https://www.postgresql.org/docs/current/backup-dump.html)

Datenmigration

^[S-126] Parallel Change

• Autor/Herausgeber: Martin Fowler
• Datum: 18.05.2017
• Dokumenttyp: Technischer Fachbeitrag
• Status: Praxisreferenz
• Relevanz: Expand-Migrate-Contract-Muster für kompatible Änderungen.
• Refresh-Priorität: niedrig
• Direkte URL: [https://martinfowler.com/bliki/ParallelChange.html](https://martinfowler.com/bliki/ParallelChange.html)

^[S-127] Evolutionary Database Design

• Autor/Herausgeber: Martin Fowler und Pramod Sadalage
• Datum: 2003; aktualisiert 2016
• Dokumenttyp: Technischer Fachbeitrag
• Status: Praxisreferenz
• Relevanz: Versionierte, inkrementelle Datenbankschemaänderungen.
• Refresh-Priorität: niedrig
• Direkte URL: [https://martinfowler.com/articles/evodb.html](https://martinfowler.com/articles/evodb.html)

^[S-128] Migrations and transaction handling

• Autor/Herausgeber: Redgate Flyway
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Versionierte Datenbankmigrationen.
• Refresh-Priorität: hoch
• Direkte URL: [https://documentation.red-gate.com/flyway/reference/commands/migrate](https://documentation.red-gate.com/flyway/reference/commands/migrate)

Vulnerability Management

^[S-129] Open Source Vulnerabilities schema and OSV.dev

• Autor/Herausgeber: OpenSSF / Google
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offene Spezifikation und Datenbank
• Status: Living Service
• Relevanz: Maschinenlesbare Zuordnung von Schwachstellen zu Paketversionen und Commits.
• Refresh-Priorität: hoch
• Direkte URL: [https://osv.dev/](https://osv.dev/)

^[S-130] Common Vulnerability Scoring System Version 4.0

• Autor/Herausgeber: FIRST
• Datum: 01.11.2023
• Dokumenttyp: Offene Spezifikation
• Status: Version 4.0
• Relevanz: Standardisierte technische Bewertung von Schwachstellenschwere.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.first.org/cvss/v4.0/](https://www.first.org/cvss/v4.0/)

^[S-131] Known Exploited Vulnerabilities Catalog

• Autor/Herausgeber: CISA
• Datum: Living Catalog; geprüft 08.08.2026
• Dokumenttyp: Behördenkatalog
• Status: Kontinuierlich aktualisiert
• Relevanz: Priorisierung tatsächlich ausgenutzter Schwachstellen.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://www.cisa.gov/known-exploited-vulnerabilities-catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)

Wartung und Abhängigkeiten

^[S-132] Dependabot security updates

• Autor/Herausgeber: GitHub
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Automatisierte Vorschläge für verwundbare Abhängigkeiten.
• Refresh-Priorität: hoch
• Direkte URL: [https://docs.github.com/en/code-security/dependabot/dependabot-security-updates/about-dependabot-security-updates](https://docs.github.com/en/code-security/dependabot/dependabot-security-updates/about-dependabot-security-updates)

^[S-133] Renovate Documentation

• Autor/Herausgeber: Mend Renovate
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Automatisierte, konfigurierbare Abhängigkeitsaktualisierung.
• Refresh-Priorität: hoch
• Direkte URL: [https://docs.renovatebot.com/](https://docs.renovatebot.com/)

KI-Anbieterbetrieb

^[S-134] Deprecations

• Autor/Herausgeber: OpenAI
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Modell- und API-Abkündigungen sowie Migrationsfristen.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://platform.openai.com/docs/deprecations](https://platform.openai.com/docs/deprecations)

^[S-135] Rate limits

• Autor/Herausgeber: OpenAI
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Ratenbegrenzungen, Kontingente und Fehlerbehandlung.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://platform.openai.com/docs/guides/rate-limits](https://platform.openai.com/docs/guides/rate-limits)

^[S-136] Model deprecations

• Autor/Herausgeber: Anthropic
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Abkündigungs- und Migrationsinformationen für Claude-Modelle.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://docs.anthropic.com/en/docs/about-claude/model-deprecations](https://docs.anthropic.com/en/docs/about-claude/model-deprecations)

^[S-137] Rate limits

• Autor/Herausgeber: Anthropic
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Kontingent- und Ratenlimitmodell der API.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://docs.anthropic.com/en/api/rate-limits](https://docs.anthropic.com/en/api/rate-limits)

^[S-138] Gemini models and model versions

• Autor/Herausgeber: Google
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Modellbezeichner, Fähigkeiten und Lebenszyklusinformationen.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://ai.google.dev/gemini-api/docs/models](https://ai.google.dev/gemini-api/docs/models)

Post-Mortems

^[S-139] SEC Charges Knight Capital With Violations of Market Access Rule

• Autor/Herausgeber: U.S. Securities and Exchange Commission
• Datum: 16.10.2013
• Dokumenttyp: Behördenmitteilung zur finalen Entscheidung
• Status: Primärquelle
• Relevanz: Fehlerhafte Teilbereitstellung, reaktivierter Altcode und fehlende Sicherheitsgrenzen.
• Refresh-Priorität: niedrig
• Direkte URL: [https://www.sec.gov/newsroom/press-releases/2013-222](https://www.sec.gov/newsroom/press-releases/2013-222)

^[S-140] Postmortem of database outage of January 31

• Autor/Herausgeber: GitLab
• Datum: 10.02.2017
• Dokumenttyp: Unternehmens-Post-Mortem
• Status: Primärbericht des Betreibers
• Relevanz: Datenlöschung, unzureichend funktionsfähige Backups und Wiederherstellungsprobleme.
• Refresh-Priorität: niedrig
• Direkte URL: [https://about.gitlab.com/blog/postmortem-of-database-outage-of-january-31/](https://about.gitlab.com/blog/postmortem-of-database-outage-of-january-31/)

^[S-141] Summary of the Amazon S3 Service Disruption in the Northern Virginia Region

• Autor/Herausgeber: Amazon Web Services
• Datum: 28.02.2017
• Dokumenttyp: Unternehmens-Post-Mortem
• Status: Primärbericht des Betreibers
• Relevanz: Fehlerhafte Wartungsanweisung, großer Blast Radius und Wiederanlaufabhängigkeiten.
• Refresh-Priorität: niedrig
• Direkte URL: [https://aws.amazon.com/message/41926/](https://aws.amazon.com/message/41926/)

^[S-142] Details of the Cloudflare outage on July 2, 2019

• Autor/Herausgeber: Cloudflare
• Datum: 02.07.2019
• Dokumenttyp: Unternehmens-Post-Mortem
• Status: Primärbericht des Betreibers
• Relevanz: Katastrophales Regex-Backtracking, globale Schnellverteilung und fehlender Performance-Gate.
• Refresh-Priorität: niedrig
• Direkte URL: [https://blog.cloudflare.com/details-of-the-cloudflare-outage-on-july-2-2019/](https://blog.cloudflare.com/details-of-the-cloudflare-outage-on-july-2-2019/)

^[S-143] More details about the October 4 outage

• Autor/Herausgeber: Meta Engineering
• Datum: 05.10.2021
• Dokumenttyp: Unternehmens-Post-Mortem
• Status: Primärbericht des Betreibers
• Relevanz: Backbone-Konfigurationsänderung, kaskadierende Kontrollsystemausfälle und erschwerter Zugriff.
• Refresh-Priorität: niedrig
• Direkte URL: [https://engineering.fb.com/2021/10/05/networking-traffic/outage-details/](https://engineering.fb.com/2021/10/05/networking-traffic/outage-details/)

^[S-144] Executive Summary: Root Cause Analysis — Channel File 291

• Autor/Herausgeber: CrowdStrike
• Datum: 06.08.2024
• Dokumenttyp: Unternehmens-Root-Cause-Analyse
• Status: Primärbericht des Herstellers
• Relevanz: Fehlerhafte Content-Konfiguration, unzureichende Validierung und weltweite Ausrollung.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.crowdstrike.com/wp-content/uploads/2024/08/Executive-Summary_Root-Cause-Analysis_Channel-File-291.pdf](https://www.crowdstrike.com/wp-content/uploads/2024/08/Executive-Summary_Root-Cause-Analysis_Channel-File-291.pdf)

^[S-145] Final Notice — TSB Bank plc

• Autor/Herausgeber: Financial Conduct Authority
• Datum: 20.12.2022
• Dokumenttyp: Behördenentscheidung
• Status: Primärquelle
• Relevanz: Governance-, Test-, Lieferanten- und Migrationsmängel bei einem kritischen Plattformwechsel.
• Refresh-Priorität: niedrig
• Direkte URL: [https://www.fca.org.uk/publication/final-notices/tsb-bank-plc-2022.pdf](https://www.fca.org.uk/publication/final-notices/tsb-bank-plc-2022.pdf)

^[S-146] Data Protection: Actions Taken by Equifax and Federal Agencies in Response to the 2017 Breach

• Autor/Herausgeber: U.S. Government Accountability Office
• Datum: 30.08.2018
• Dokumenttyp: Behördenbericht
• Status: Primär-/Untersuchungsquelle
• Relevanz: Asset-Erkennung, Patchen, Segmentierung, Erkennung und Datengovernance als Ausfallfaktoren.
• Refresh-Priorität: niedrig
• Direkte URL: [https://www.gao.gov/products/gao-18-559](https://www.gao.gov/products/gao-18-559)

^[S-147] Security Update — Bash Uploader Incident

• Autor/Herausgeber: Codecov
• Datum: 15.04.2021; fortlaufend aktualisiert
• Dokumenttyp: Unternehmens-Sicherheitsbericht
• Status: Primärbericht des Anbieters
• Relevanz: Manipulation eines Lieferketten-Skripts und potenzieller Geheimnisabfluss.
• Refresh-Priorität: mittel
• Direkte URL: [https://about.codecov.io/security-update/](https://about.codecov.io/security-update/)

^[S-148] Post-incident review: April 2022 outage

• Autor/Herausgeber: Atlassian Engineering
• Datum: 04.05.2022
• Dokumenttyp: Unternehmens-Post-Mortem
• Status: Primärbericht des Betreibers
• Relevanz: Fehlerhafte Skriptausführung, Löschung von Kundensites und langwierige Wiederherstellung.
• Refresh-Priorität: niedrig
• Direkte URL: [https://www.atlassian.com/engineering/post-incident-review-april-2022-outage](https://www.atlassian.com/engineering/post-incident-review-april-2022-outage)

Recht und Compliance

^[S-149] Verordnung (EU) 2016/679 — Datenschutz-Grundverordnung

• Autor/Herausgeber: Europäische Union
• Datum: 27.04.2016
• Dokumenttyp: EU-Verordnung
• Status: In Kraft
• Relevanz: Datenschutzrechtliche Anforderungen an personenbezogene Daten in Entwicklung und Betrieb.
• Refresh-Priorität: mittel
• Direkte URL: [https://eur-lex.europa.eu/eli/reg/2016/679/oj](https://eur-lex.europa.eu/eli/reg/2016/679/oj)

^[S-150] Verordnung (EU) 2024/1689 — AI Act

• Autor/Herausgeber: Europäische Union
• Datum: 13.06.2024
• Dokumenttyp: EU-Verordnung
• Status: In Kraft; gestaffelte Anwendung
• Relevanz: Pflichten über den Lebenszyklus bestimmter KI-Systeme, einschließlich Qualität und Monitoring.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://eur-lex.europa.eu/eli/reg/2024/1689/oj](https://eur-lex.europa.eu/eli/reg/2024/1689/oj)

Secure SDLC

^[S-151] TR-03185 — Sicherer Software-Lebenszyklus

• Autor/Herausgeber: Bundesamt für Sicherheit in der Informationstechnik (BSI)
• Datum: 27.08.2024
• Dokumenttyp: Technische Richtlinie / Behördenquelle
• Status: Aktuelle Themenseite; Dokumentstände separat prüfen
• Relevanz: Best Practices für einen sicheren Software-Lebenszyklus.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/Technische-Richtlinien/TR-nach-Thema-sortiert/tr03185/TR-03185_node.html](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/Technische-Richtlinien/TR-nach-Thema-sortiert/tr03185/TR-03185_node.html)

^[S-152] CON.8 Software-Entwicklung — Edition 2023

• Autor/Herausgeber: Bundesamt für Sicherheit in der Informationstechnik (BSI)
• Datum: 2023
• Dokumenttyp: IT-Grundschutz-Baustein / Behördenquelle
• Status: Edition 2023; aktuelle Edition beim Refresh prüfen
• Relevanz: Sicherheitsanforderungen bei eigener oder beauftragter Softwareentwicklung.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/IT-GS-Kompendium_Einzel_PDFs_2023/03_CON_Konzepte_und_Vorgehensweisen/CON_8_Software_Entwicklung_Edition_2023.html](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/IT-GS-Kompendium_Einzel_PDFs_2023/03_CON_Konzepte_und_Vorgehensweisen/CON_8_Software_Entwicklung_Edition_2023.html)

Backup und Restore

^[S-153] CON.3 Datensicherungskonzept — Edition 2023

• Autor/Herausgeber: Bundesamt für Sicherheit in der Informationstechnik (BSI)
• Datum: 2023
• Dokumenttyp: IT-Grundschutz-Baustein / Behördenquelle
• Status: Edition 2023; aktuelle Edition beim Refresh prüfen
• Relevanz: Planung, Durchführung, Kontrolle und Wiederherstellung von Datensicherungen.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/IT-GS-Kompendium_Einzel_PDFs_2023/03_CON_Konzepte_und_Vorgehensweisen/CON_3_Datensicherungskonzept_Edition_2023.html](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/IT-GS-Kompendium_Einzel_PDFs_2023/03_CON_Konzepte_und_Vorgehensweisen/CON_3_Datensicherungskonzept_Edition_2023.html)

Test und Freigabe

^[S-154] OPS.1.1.6 Software-Tests und -Freigaben — Edition 2022

• Autor/Herausgeber: Bundesamt für Sicherheit in der Informationstechnik (BSI)
• Datum: 2022
• Dokumenttyp: IT-Grundschutz-Baustein / Behördenquelle
• Status: Edition 2022; Nachfolgestand beim Refresh prüfen
• Relevanz: Tests, Abnahme und kontrollierte Freigabe von Software.
• Refresh-Priorität: hoch
• Direkte URL: [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/IT-GS-Kompendium_Einzel_PDFs_2022/04_OPS_Betrieb/OPS_1_1_6_Software_Tests_und_Freigaben_Edition_2022.pdf?__blob=publicationFile&v=3](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/IT-GS-Kompendium_Einzel_PDFs_2022/04_OPS_Betrieb/OPS_1_1_6_Software_Tests_und_Freigaben_Edition_2022.pdf?__blob=publicationFile&v=3)

Daten- und Modellherkunft

^[S-155] About OpenLineage and the OpenLineage specification

• Autor/Herausgeber: OpenLineage Project
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offene Spezifikation / Projektdokumentation
• Status: Living Documentation
• Relevanz: Standardisierte Metadaten zu Jobs, Runs und Datensätzen für Data Lineage.
• Refresh-Priorität: hoch
• Direkte URL: [https://openlineage.io/docs/](https://openlineage.io/docs/)

KI-Lebenszyklus

^[S-156] ML Model Registry

• Autor/Herausgeber: MLflow Project / Linux Foundation
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Versionierung, Lineage, Aliase und Metadaten für Modellartefakte.
• Refresh-Priorität: hoch
• Direkte URL: [https://mlflow.org/docs/latest/ml/model-registry/](https://mlflow.org/docs/latest/ml/model-registry/)

KI-Governance

^[S-157] Artificial Intelligence Risk Management Framework (AI RMF 1.0)

• Autor/Herausgeber: NIST
• Datum: 26.01.2023
• Dokumenttyp: Behördenrahmenwerk
• Status: Final
• Relevanz: Govern, Map, Measure und Manage für KI-Risiken.
• Refresh-Priorität: mittel
• Direkte URL: [https://www.nist.gov/itl/ai-risk-management-framework](https://www.nist.gov/itl/ai-risk-management-framework)

KI-Integration

^[S-158] Function calling

• Autor/Herausgeber: OpenAI
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Strukturierte Werkzeugaufrufe durch Modelle; Ausführung und Autorisierung bleiben bei der Anwendung.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://platform.openai.com/docs/guides/function-calling](https://platform.openai.com/docs/guides/function-calling)

^[S-159] Structured Outputs

• Autor/Herausgeber: OpenAI
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Schema-gebundene Modellausgaben; Formtreue ersetzt keine fachliche Validierung.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://platform.openai.com/docs/guides/structured-outputs](https://platform.openai.com/docs/guides/structured-outputs)

^[S-160] Tool use with Claude

• Autor/Herausgeber: Anthropic
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Werkzeugdefinition, Aufrufvorschlag und Toolresultate bei Claude.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/overview](https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/overview)

^[S-161] Function calling with the Gemini API

• Autor/Herausgeber: Google
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Strukturierte Funktionsaufrufe in der Gemini API.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://ai.google.dev/gemini-api/docs/function-calling](https://ai.google.dev/gemini-api/docs/function-calling)

KI-Systemarchitektur

^[S-162] Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks

• Autor/Herausgeber: Lewis et al.
• Datum: 22.05.2020
• Dokumenttyp: Originalarbeit / arXiv
• Status: Peer-reviewter Konferenzbeitrag (NeurIPS 2020)
• Relevanz: Grundlage für Retrieval-Augmented Generation und externes Wissen zur Laufzeit.
• Refresh-Priorität: mittel
• Direkte URL: [https://arxiv.org/abs/2005.11401](https://arxiv.org/abs/2005.11401)

^[S-163] Lost in the Middle: How Language Models Use Long Contexts

• Autor/Herausgeber: Liu et al.
• Datum: 06.07.2023
• Dokumenttyp: Originalarbeit / arXiv
• Status: Peer-reviewter Beitrag (TACL 2024)
• Relevanz: Grenzen effektiver Kontextnutzung trotz großem nominellem Kontextfenster.
• Refresh-Priorität: mittel
• Direkte URL: [https://arxiv.org/abs/2307.03172](https://arxiv.org/abs/2307.03172)

Observability und SRE

^[S-164] Site Reliability Engineering — Monitoring Distributed Systems

• Autor/Herausgeber: Google
• Datum: 2016; Onlinefassung geprüft 08.08.2026
• Dokumenttyp: Offizielles SRE-Fachbuchkapitel
• Status: Stabile Referenz
• Relevanz: Monitoring, Nutzerwirkung, Symptome und Alarmierungsprinzipien.
• Refresh-Priorität: niedrig
• Direkte URL: [https://sre.google/sre-book/monitoring-distributed-systems/](https://sre.google/sre-book/monitoring-distributed-systems/)

Test und SRE

^[S-165] Site Reliability Engineering — Testing for Reliability

• Autor/Herausgeber: Google
• Datum: 2016; Onlinefassung geprüft 08.08.2026
• Dokumenttyp: Offizielles SRE-Fachbuchkapitel
• Status: Stabile Referenz
• Relevanz: Tests als Bestandteil der Zuverlässigkeitsarbeit.
• Refresh-Priorität: niedrig
• Direkte URL: [https://sre.google/sre-book/testing-reliability/](https://sre.google/sre-book/testing-reliability/)

Incident Response

^[S-166] Site Reliability Engineering — Postmortem Culture: Learning from Failure

• Autor/Herausgeber: Google
• Datum: 2016; Onlinefassung geprüft 08.08.2026
• Dokumenttyp: Offizielles SRE-Fachbuchkapitel
• Status: Stabile Referenz
• Relevanz: Lernorientierte Incident-Analyse und systemische Maßnahmen.
• Refresh-Priorität: niedrig
• Direkte URL: [https://sre.google/sre-book/postmortem-culture/](https://sre.google/sre-book/postmortem-culture/)

Release Engineering

^[S-167] Site Reliability Engineering — Release Engineering

• Autor/Herausgeber: Google
• Datum: 2016; Onlinefassung geprüft 08.08.2026
• Dokumenttyp: Offizielles SRE-Fachbuchkapitel
• Status: Stabile Referenz
• Relevanz: Konsistente, wiederholbare und automatisierte Releases.
• Refresh-Priorität: niedrig
• Direkte URL: [https://sre.google/sre-book/release-engineering/](https://sre.google/sre-book/release-engineering/)

Reliability Engineering

^[S-168] Site Reliability Engineering — Addressing Cascading Failures

• Autor/Herausgeber: Google
• Datum: 2016; Onlinefassung geprüft 08.08.2026
• Dokumenttyp: Offizielles SRE-Fachbuchkapitel
• Status: Stabile Referenz
• Relevanz: Überlast, Lastabwurf und Begrenzung kaskadierender Ausfälle.
• Refresh-Priorität: niedrig
• Direkte URL: [https://sre.google/sre-book/addressing-cascading-failures/](https://sre.google/sre-book/addressing-cascading-failures/)

Datenmigration

^[S-169] Backwards compatibility across updates — Expand and contract pattern

• Autor/Herausgeber: GitLab
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Mehrstufige, rückwärtskompatible Änderungen und Datenmigrationen.
• Refresh-Priorität: hoch
• Direkte URL: [https://docs.gitlab.com/development/multi_version_compatibility/](https://docs.gitlab.com/development/multi_version_compatibility/)

Teststrategie

^[S-170] Just Say No to More End-to-End Tests

• Autor/Herausgeber: Google Testing Blog
• Datum: 22.04.2015
• Dokumenttyp: Technischer Fachbeitrag
• Status: Praxisreferenz
• Relevanz: Grenzen übermäßiger End-to-End-Testanteile.
• Refresh-Priorität: niedrig
• Direkte URL: [https://testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html](https://testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html)

Observability und SRE

^[S-171] Alerting rules

• Autor/Herausgeber: Prometheus Project
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Projektdokumentation
• Status: Living Documentation
• Relevanz: Auswertung und Stabilisierung von Alarmierungsregeln.
• Refresh-Priorität: hoch
• Direkte URL: [https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/)

Build und Infrastruktur

^[S-172] Dependency Lock File

• Autor/Herausgeber: HashiCorp
• Datum: Veröffentlichungsdatum UNKLAR; geprüft 08.08.2026
• Dokumenttyp: Offizielle Produktdokumentation
• Status: Living Documentation
• Relevanz: Fixierung und Prüfsummen von Terraform-Providerabhängigkeiten.
• Refresh-Priorität: hoch
• Direkte URL: [https://developer.hashicorp.com/terraform/language/files/dependency-lock](https://developer.hashicorp.com/terraform/language/files/dependency-lock)

Resilienztest

^[S-173] Principles of Chaos Engineering

• Autor/Herausgeber: Principles of Chaos Engineering
• Datum: 2017; geprüft 08.08.2026
• Dokumenttyp: Offene Praxisreferenz
• Status: Stabile Grundprinzipien
• Relevanz: Kontrollierte Experimente zu Systemverhalten unter Störungen.
• Refresh-Priorität: mittel
• Direkte URL: [https://principlesofchaos.org/](https://principlesofchaos.org/)

Post-Mortems

^[S-174] Cloudflare outage on November 18, 2025

• Autor/Herausgeber: Cloudflare
• Datum: 18.11.2025
• Dokumenttyp: Unternehmens-Post-Mortem
• Status: Primärbericht des Betreibers
• Relevanz: Aktueller offizieller Ausfallbericht zu Konfigurations- und Kontrollpfaden.
• Refresh-Priorität: mittel
• Direkte URL: [https://blog.cloudflare.com/18-november-2025-outage/](https://blog.cloudflare.com/18-november-2025-outage/)

Observability und SRE

^[S-175] Semantic conventions

• Autor/Herausgeber: OpenTelemetry Project
• Datum: Version 1.43.0; geprüft 08.08.2026
• Dokumenttyp: Offene Spezifikation / Projektdokumentation
• Status: Living Specification
• Relevanz: Standardisierte Namen und Attribute für Telemetriedaten.
• Refresh-Priorität: sehr hoch
• Direkte URL: [https://opentelemetry.io/docs/specs/semconv/](https://opentelemetry.io/docs/specs/semconv/)

Schnell veraltend — Refresh-Plan

REFRESH-HINWEIS: Living Documentation und regulatorische Umsetzung können sich nach dem Stichtag ändern. Die folgende Liste soll vor Buchsatz, Veröffentlichung und größeren Folgeauflagen erneut geprüft werden. ^{[S-023; S-134; S-116; S-090]}

Empfohlene Prüffrequenz

Qualitätssicherung und Dossiergrenzen

Strukturprüfungen

Inhaltliche Grenzen

• Normen sind teilweise kostenpflichtig; öffentlich sichtbare ISO-Metadaten belegen Ausgabe und Gegenstand, nicht den vollständigen Normtext.
• Living Documentation kann nach dem 8. August 2026 geändert werden; der Refresh-Plan ist verbindlicher Teil des Dossiers.
• Providerdokumentation beschreibt den Produktstand aus Anbietersicht und wird nicht als unabhängiger Wirksamkeitsbeleg interpretiert.
• Post-Mortems können trotz Primärnähe unvollständige Perspektiven enthalten; das Dossier leitet nur die dokumentierten Betriebslehren ab.
• Rechtsquellen werden zur Lebenszykluseinordnung genannt; eine individuelle juristische Bewertung ist nicht enthalten.
• Konkrete Toolwahl, SLO-Zielwerte, Testmengen und Kontrolltiefe müssen aus dem realen Risikoprofil abgeleitet werden.

Schlussbefund: Die belastbare Grenze zwischen Prototyp und Produkt verläuft nicht bei der letzten Codezeile. Sie verläuft dort, wo Nutzen, Verantwortlichkeit, reproduzierbare Änderung, kontrollierte Wirkung, Beobachtbarkeit, Wiederherstellung und langfristige Pflege erstmals gemeinsam nachgewiesen sind. ^{[S-001; S-002; S-102; S-028]}