final fixes

2_0_vulns/translations/de-DE/LLM00_Preface.md

@@ -8,7 +8,7 @@ Die Liste von 2023 war ein großer Erfolg bei der Sensibilisierung und der Schaf
 
 Die Liste von 2025 spiegelt ein besseres Verständnis der bestehenden Risiken wider und enthält wichtige Aktualisierungen darüber, wie LLMs heute in realen Anwendungen eingesetzt werden. Beispielsweise wurde das Konzept des „Unbegrenzten Verbrauchs“ (Unbounded Consumption) erweitert, um Risiken im Zusammenhang mit dem Ressourcenmanagement und unerwarteten Kosten zu berücksichtigen - ein drängendes Problem bei der großflächigen Einführung von LLM-Anwendungen.
 
-Der Eintrag „Schwachstellen in Vektoren und Embeddings“ (Vector and Embeddings) ist eine Reaktion auf Anfragen aus der Community nach Anleitungen zur Absicherung von Retrieval-Augmented Generation (RAG) und anderen auf Einbettungen basierenden Methoden, die heute zu den grundlegenden Praktiken für die Absicherung von Modellausgaben gehören.
+Der Eintrag „Schwachstellen in Vektoren und Embeddings“ (Vector and Embedding Weaknesses) ist eine Reaktion auf Anfragen aus der Community nach Anleitungen zur Absicherung von Retrieval-Augmented Generation (RAG) und anderen auf Einbettungen basierenden Methoden, die heute zu den grundlegenden Praktiken für die Absicherung von Modellausgaben gehören.
 
 Wir haben auch „Offenlegung des Systems Prompts“ (System Prompt Leakage) hinzugefügt, um einen Bereich realer Exploits abzudecken, der von der Community stark nachgefragt wurde. Viele Anwendungen gingen davon aus, dass Prompts sicher isoliert sind, aber jüngste Vorfälle haben gezeigt, dass Entwickelnde nicht davon ausgehen können, dass die Informationen in diesen Prompts vertraulich bleiben.
 

2_0_vulns/translations/de-DE/LLM01_PromptInjection.md

@@ -31,19 +31,19 @@ Der Aufstieg multimodaler KI, die mehrere Datentypen gleichzeitig verarbeiten, b
 
 Aufgrund der Natur der generativen KI sind Schwachstellen bei Prompt Injections möglich. Angesichts des stochastischen Einflusses, der der Funktionsweise von Modellen zugrunde liegt, ist unklar, ob es absolut sichere Methoden zur Verhinderung von Prompt Injections gibt. Die folgenden Maßnahmen können jedoch die Auswirkungen von Prompt Injections abmildern:
 
-#### 1. Modellverhalten einschränken
+#### 1. Begrenzen Sie das Modellverhalten
   Geben Sie spezifische Anweisungen zur Rolle, zu den Fähigkeiten und zu den Beschränkungen des Modells innerhalb des System Prompts. Erzwingen Sie die strikte Einhaltung des Kontexts, beschränken Sie die Antworten auf bestimmte Aufgaben oder Themen und weisen Sie das Modell an, Versuche zur Änderung der Kernanweisungen zu ignorieren.
-#### 2. Definieren und validieren der erwarteten Ausgabeformate
+#### 2. Definieren und validieren Sie erwartete Ausgabeformate
   Legen Sie klare Ausgabeformate fest, fordern Sie detaillierte Begründungen und Quellenangaben an, und verwenden Sie deterministischen Code, um die Einhaltung dieser Formate zu überprüfen.
-#### 3. Implementierung von Eingabe- und Ausgabefilterung
+#### 3. Implementieren Sie Filter für Ein- und Ausgaben
   Definieren Sie sensible Kategorien und erstellen Sie Regeln zur Identifizierung und Handhabung solcher Inhalte. Wenden Sie semantische Filter an und prüfen Sie Strings, um nach nicht zulässigen Inhalten zu suchen. Bewerten Sie die Antworten mithilfe der RAG-Triade: Beurteilen Sie die Relevanz des Kontexts, die Begründetheit und die Relevanz der Frage/Antwort, um potenziell schädliche Ausgaben zu identifizieren.
-#### 4. Durchsetzung der Zugriffsrechte und des Zugriffs mit geringsten Rechten
+#### 4. Erzwingen Sie Zugriffsrechte und einen Zugriff mit geringsten Rechten
   Stellen Sie der Anwendung eigene API-Token für erweiterbare Funktionen zur Verfügung und verwalten Sie diese Funktionen im Code, anstatt sie dem Modell zur Verfügung zu stellen. Beschränken Sie die Zugriffsrechte des Modells auf das für die vorgesehenen Vorgänge erforderliche Minimum.
-#### 5. Eine menschliche Freigabe für risikoreiche Aktionen
+#### 5. Fordern Sie manuelle Freigabe für risikoreiche Aktionen
   Implementieren Sie Kontrollen, bei denen der Mensch in den Prozess eingebunden ist, für privilegierte Vorgänge, um unbefugte Aktionen zu verhindern.
-#### 6. Externe Inhalte trennen und kennzeichnen
+#### 6. Trennen und kennzeichnen Sie externe Inhalte
   Trennen und kennzeichnen Sie nicht vertrauenswürdige Inhalte eindeutig, um ihren Einfluss auf die Eingabeaufforderungen für Benutzende zu begrenzen.
-#### 7. Durchführung von Adversarial-Tests und Angriffssimulationen
+#### 7. Führen Sie adversarial Tests und Angriffssimulationen durch
   Führen Sie regelmäßige Penetrationstests und Angriffssimulationen durch und behandeln Sie das Modell dabei als nicht vertrauenswürdige Person, um die Wirksamkeit von Vertrauensgrenzen und Zugriffskontrollen zu testen.
 
 ### Beispiele für Angriffsszenarien
@@ -55,17 +55,17 @@ Aufgrund der Natur der generativen KI sind Schwachstellen bei Prompt Injections
 #### Szenario 3: Unbeabsichtigte Injektion
   Ein Unternehmen fügt in eine Stellenbeschreibung eine Anweisung zur Identifizierung KI-generierter Anwendungen ein. Eine sich bewerbenden Person, die diese Anweisung nicht kennt, verwendet ein LLM, um ihren Lebenslauf zu optimieren, und löst damit versehentlich die KI-Erkennung aus.
 #### Szenario 4: Beabsichtigter Einfluss auf das Modell
-  Angreifenden ändern ein Dokument in einem Repository, das von einer Retrieval-Augmented Generation (RAG)-Anwendung verwendet wird. Wenn die Abfrage den geänderten Inhalt zurückgibt, ändern die bösartigen Anweisungen die Ausgabe des LLM und erzeugen irreführende Ergebnisse.
+  Angreifende ändern ein Dokument in einem Repository, das von einer Retrieval-Augmented Generation (RAG)-Anwendung verwendet wird. Wenn die Abfrage den geänderten Inhalt zurückgibt, ändern die bösartigen Anweisungen die Ausgabe des LLM und erzeugen irreführende Ergebnisse.
 #### Szenario 5: Code-Injection
   Angreifende nutzen eine Schwachstelle (CVE-2024-5184) in einem E-Mail-Assistenten mit LLM-Unterstützung aus, um schädliche Prompts einzufügen, die den Zugriff auf vertrauliche Informationen und die Manipulation von E-Mail-Inhalten ermöglichen.
 #### Szenario 6: Aufteilung des Payloads
-  Angreifenden laden einen Lebenslauf mit mehrteiligen, bösartigen Anweisungen hoch. Wenn ein LLM zur Bewertung des Kandidierenden verwendet wird, manipulieren die kombinierten Anweisungen die Antwort des Modells, was ungeachtet des Inhalts des Lebenslaufs zu einer positiven Empfehlung führt.
+  Angreifende laden einen Lebenslauf mit mehrteiligen, bösartigen Anweisungen hoch. Wenn ein LLM zur Bewertung des Kandidierenden verwendet wird, manipulieren die kombinierten Anweisungen die Antwort des Modells, was ungeachtet des Inhalts des Lebenslaufs zu einer positiven Empfehlung führt.
 #### Szenario 7: Multimodale Injektion
-  Angreifenden betten einen schädliche Prompt in ein Bild ein, das einen harmlosen Text begleitet. Wenn eine multimodale KI das Bild und den Text gleichzeitig verarbeitet, ändert der versteckte Prompt das Verhalten des Modells, was möglicherweise zu nicht autorisierten Aktionen oder zur Offenlegung sensibler Informationen führt.
+  Angreifende betten einen schädliche Prompt in ein Bild ein, das einen harmlosen Text begleitet. Wenn eine multimodale KI das Bild und den Text gleichzeitig verarbeitet, ändert der versteckte Prompt das Verhalten des Modells, was möglicherweise zu nicht autorisierten Aktionen oder zur Offenlegung sensibler Informationen führt.
 #### Szenario 8: Adversarial Suffix
-  Angreifenden hängen eine scheinbar bedeutungslose Zeichenfolge an einen Prompt an, der die Ausgabe des LLM auf böswillige Weise beeinflusst und Sicherheitsmaßnahmen umgeht.
+  Angreifende hängen eine scheinbar bedeutungslose Zeichenfolge an einen Prompt an, der die Ausgabe des LLM auf böswillige Weise beeinflusst und Sicherheitsmaßnahmen umgeht.
 #### Szenario 9: Mehrsprachiger/verschleierter Angriff
-  Angreifenden wenden mehrere Sprachen oder verschlüsseln böswillige Anweisungen (z. B. mit Base64 oder Emojis), um Filter zu umgehen und das Verhalten des LLM zu manipulieren.
+  Angreifende wenden mehrere Sprachen oder verschlüsseln böswillige Anweisungen (z. B. mit Base64 oder Emojis), um Filter zu umgehen und das Verhalten des LLM zu manipulieren.
 
 ### Referenzlinks
 

2_0_vulns/translations/de-DE/LLM02_SensitiveInformationDisclosure.md

@@ -6,7 +6,7 @@ Sensible Informationen können sowohl das LLM als auch seinen Anwendungskontext
 
 LLMs, insbesondere wenn sie in Anwendungen eingebettet sind, bergen das Risiko, dass durch ihre Ausgabe sensible Daten, proprietäre Algorithmen oder vertrauliche Details offengelegt werden. Dies kann zu unbefugtem Datenzugriff, Datenschutzverletzungen und Verstößen gegen das geistige Eigentum führen. Anwendende sollten wissen, wie sie sicher mit LLMs umgehen können. Sie müssen sich der Risiken bewusst sein, die mit der unbeabsichtigten Bereitstellung sensibler Daten verbunden sind, die später in der Ausgabe des Modells offengelegt werden können.
 
-Um dieses Risiko zu verringern, sollten LLM-Anwendungen eine angemessene Datenbereinigung durchführen, um zu verhindern, dass Daten von Anwendenden in das Trainingsmodell gelangen. Die Eigentümer der Anwendungen sollten außerdem klare Nutzungsbedingungen bereitstellen, die es Personen ermöglichen, die Aufnahme ihrer Daten in das Trainingsmodell abzulehnen. Das Hinzufügen von Einschränkungen innerhalb der Systemaufforderung zu den Datentypen, die das LLM zurückgeben sollte, kann eine Minderung der Offenlegung sensibler Informationen bewirken. Solche Einschränkungen werden jedoch möglicherweise nicht immer beachtet und können durch das Einfügen von Aufforderungen oder andere Methoden umgangen werden.
+Um dieses Risiko zu verringern, sollten LLM-Anwendungen eine angemessene Datenbereinigung durchführen, um zu verhindern, dass Daten von Anwendenden in das Trainingsmodell gelangen. Die Eigentümer der Anwendungen sollten außerdem klare Nutzungsbedingungen bereitstellen, die es Personen ermöglichen, die Aufnahme ihrer Daten in das Trainingsmodell abzulehnen. Das Hinzufügen von Einschränkungen innerhalb des System Prompts über die Datentypen, die das LLM zurückgeben sollte, kann eine Minderung der Offenlegung sensibler Informationen bewirken. Solche Einschränkungen werden jedoch möglicherweise nicht immer beachtet und können durch via Prompt Injection oder andere Methoden umgangen werden.
 
 ### Gängige Beispiele für Schwachstellen
 
@@ -49,9 +49,9 @@ Um dieses Risiko zu verringern, sollten LLM-Anwendungen eine angemessene Datenbe
 
 ###@ Sichere Systemkonfiguration:
 
-#### 1. Verbergen des Systems Präambel
+#### 1. Verbergen der System Präambel
   Schränken Sie die Möglichkeit für Nutzende ein, die ursprünglichen Einstellungen des Systems zu überschreiben oder darauf zuzugreifen, um das Risiko einer Offenlegung interner Konfigurationen zu verringern.
-#### 2. Referenz für bewährte Verfahren zur Sicherheit bei Fehlkonfigurationen
+#### 2. Best Practices für bewährte Verfahren zur Sicherheit bei Fehlkonfigurationen berücksichtigen
   Befolgen Sie Richtlinien wie „OWASP API8:2023 Security Misconfiguration“, um zu verhindern, dass vertrauliche Informationen durch Fehlermeldungen oder Konfigurationsdetails durchsickern.
   (Ref. link:[OWASP API8:2023 Security Misconfiguration](https://owasp.org/API-Security/editions/2023/en/0xa8-security-misconfiguration/))
 

2_0_vulns/translations/de-DE/LLM03_SupplyChain.md

@@ -8,7 +8,7 @@ Diese externen Elemente können durch Manipulationen oder Poisoning-Angriffe ver
 
 Die Erstellung von LLMs ist eine anspruchsvolle Aufgabe, die oft von Modellen Dritter abhängt. Das Aufkommen offen zugänglicher LLMs und neuer Fine-Tuning-Methoden wie „LoRA“ (Low-Rank Adaptation) und „PEFT“ (Parameter-Efficient Fine-Tuning), insbesondere auf Plattformen wie Hugging Face, bringen neue Risiken in die Lieferkette. Schließlich erhöht das Aufkommen von On-Device-LLMs die Angriffsfläche und die Supply-Chain-Risiken für LLM-Anwendungen.
 
-Einige der hier diskutierten Risiken werden auch in „LLM04 Data and Model Poisoning“ behandelt. Dieser Text konzentriert sich auf den Supply-Chain-Aspekt der Risiken.
+Einige der hier diskutierten Risiken werden auch in „LLM04 Poisoning von Daten und Modellen“ behandelt. Dieser Text konzentriert sich auf den Supply-Chain-Aspekt der Risiken.
 Ein einfaches Bedrohungsmodell finden Sie [hier](https://github.com/jsotiro/ThreatModels/blob/main/LLM%20Threats-LLM%20Supply%20Chain.png).
 
 ### Gängige Beispiele für Risiken
@@ -21,7 +21,7 @@ Ein einfaches Bedrohungsmodell finden Sie [hier](https://github.com/jsotiro/Thre
 #### 3. Überholte oder veraltete Modelle
   Die Verwendung veralteter oder überholter Modelle, die nicht mehr gepflegt werden, führt zu Sicherheitsproblemen.
 #### 4. Anfälliges vortrainiertes Modell
-  Modelle sind binäre Blackboxen und im Gegensatz zu Open Source kann eine statische Prüfung nur wenig zur Sicherheit beitragen. Anfällige vortrainierte Modelle können versteckte Verzerrungen, Hintertüren oder andere bösartige Merkmale enthalten, die bei den Sicherheitsbewertungen des Modellspeichers nicht erkannt wurden. Anfällige Modelle können sowohl durch manipulierte Datensätze als auch durch direkte Modellmanipulationen mit Techniken wie ROME, auch bekannt als Lobotomisierung, erstellt werden.
+  Modelle sind binäre Blackboxen und im Gegensatz zu Open Source kann eine statische Prüfung nur wenig zur Sicherheit beitragen. Anfällige vortrainierte Modelle können versteckte Verzerrungen, Hintertüren oder andere bösartige Merkmale enthalten, die bei den Sicherheitsbewertungen des Modell Repositories nicht erkannt wurden. Anfällige Modelle können sowohl durch vergiftete Datensätze als auch durch direkte Manipulation des Modells entstehen, beispielsweise durch Techniken wie ROME, auch bekannt als „Lobotomisierung“.
 #### 5. Schwache Modellherkunft
   Derzeit gibt es in veröffentlichten Modellen keine strengen Herkunftsnachweise. Model Cards und die dazugehörige Dokumentation liefern zwar Informationen über das Modell und sind für Nutzende verlässlich, bieten aber keine Garantien über die Herkunft des Modells. Angreifende können ein Konto eines Anbietenden in einem Modell-Repository kompromittieren oder ein ähnliches Konto erstellen und mit Social-Engineering-Techniken kombinieren, um die Lieferkette einer LLM-Anwendung zu kompromittieren. 
 #### 6. Anfällige LoRA-Adapter
@@ -44,7 +44,7 @@ Ein einfaches Bedrohungsmodell finden Sie [hier](https://github.com/jsotiro/Thre
 6. Verwenden Sie nur Modelle aus überprüfbaren Quellen und führen Sie Integritätsprüfungen von Drittanbietern mit Signaturen und Datei-Hashes durch, um das Fehlen einer sicheren Modellherkunft auszugleichen. Setzen Sie zudem Code-Signierung für extern gelieferten Code ein.
 7. Implementieren Sie strenge Überwachungs- und Prüfungspraktiken für kollaborative Modellentwicklungsumgebungen, um Missbrauch zu verhindern und schnell zu erkennen. Nutzen Sie automatisierte Skripte wie den „HuggingFace SF_Convertbot Scanner“ als Beispiel für effektive Tools.
   (Ref. Link: [HuggingFace SF_Convertbot Scanner](https://gist.github.com/rossja/d84a93e5c6b8dd2d4a538aa010b29163))
-8. Die Erkennung von Anomalien und Robustheitstests für bereitgestellte Modelle und Daten können dazu beitragen, Manipulationen und Poisoning aufzudecken, wie in "LLM04 Data and Model Poisoning" beschrieben; idealerweise sollte dies Teil der MLOps- und LLM-Pipelines sein.
+8. Die Erkennung von Anomalien und Robustheitstests für bereitgestellte Modelle und Daten können dazu beitragen, Manipulationen und Poisoning aufzudecken, wie in "LLM04 Poisoning von Daten und Modellen" beschrieben; idealerweise sollte dies Teil der MLOps- und LLM-Pipelines sein.
 9. Implementieren Sie eine Patching-Policy, um verwundbare oder veraltete Komponenten zu entschärfen. Stellen Sie sicher, dass die Anwendung auf einer gepflegten Version der APIs und des zugrunde liegenden Modells basiert.
 10. Verschlüsseln Sie Modelle, die am KI-Edge bereitgestellt werden, mit Integritätsprüfungen, und nutzen Sie die Attestierungs-APIs der Hersteller, um manipulierte Anwendungen und Modelle zu verhindern und Anwendungen mit nicht anerkannten Firmware zu beenden.
 
@@ -55,13 +55,13 @@ Ein einfaches Bedrohungsmodell finden Sie [hier](https://github.com/jsotiro/Thre
 #### Szenario 2: Direkte Manipulation
   Direkte Manipulation und Veröffentlichung eines Modells zur Verbreitung von Fehlinformationen. Dies ist ein tatsächlicher Angriff, bei dem PoisonGPT die Sicherheitsfunktionen von Hugging Face umgeht, indem es die Modellparameter direkt ändert.
 #### Szenario 3: Fine-Tuning eines beliebten Modells
-  Angreifende fine-tunen ein beliebtes, frei zugängliches Modell so, dass wichtige Sicherheitsmerkmale entfernt werden und es in einem bestimmten Bereich (Versicherungen) besonders gut abschneidet. Das Modell ist so eingestellt, dass es bei den Sicherheitsbenchmarks gut abschneidet, aber sehr gezielte Trigger hat. Die Angreifende verbreiten es auf Hugging Face, damit Opfer es nutzen und auf Benchmark-Zusicherungen vertrauen.
+  Angreifende fine-tunen ein beliebtes, frei zugängliches Modell so, dass wichtige Sicherheitsmerkmale entfernt werden und es in einem bestimmten Bereich (Versicherungen) besonders gut abschneidet. Das Modell ist so eingestellt, dass es bei den Sicherheitsbenchmarks gut abschneidet, aber sehr gezielte Trigger hat. Die Angreifenden verbreiten es auf Hugging Face, damit Opfer es nutzen und auf Benchmark-Zusicherungen vertrauen.
 #### Szenario 4: Vortrainierte Modelle
   Ein LLM-System setzt vortrainierte Modelle aus einem weit verbreiteten Repository ohne gründliche Überprüfung ein. Ein kompromittiertes Modell führt bösartigen Code ein, der in bestimmten Kontexten verzerrte Ergebnisse verursacht und zu schädlichen oder manipulierten Resultaten führt.
 #### Szenario 5: Kompromittierter Drittanbieter
   Ein kompromittierter Drittanbieter stellt einen anfälligen LoRA-Adapter zur Verfügung, der mithilfe von Model Merge auf Hugging Face zu einem LLM zusammengeführt wird.
 #### Szenario 6: Infiltration eines Lieferanten
-  Angreifende infiltrieren einen Drittanbieter und kompromittiert die Produktion eines LoRA-Adapters (Low-Rank Adaptation), der für die Integration in einen On-Device-LLM bestimmt ist, der mit Frameworks wie vLLM oder OpenLLM bereitgestellt wird. Der kompromittierte LoRA-Adapter ist so verändert, dass er versteckte Schwachstellen und bösartigen Code enthält. Sobald dieser Adapter mit dem LLM verbunden ist, bietet er dem Angreifer einen versteckten Einstiegspunkt in das System. Der bösartige Code kann während des Modellbetriebs aktiviert werden und ermöglicht es dem Angreifer, die Ergebnisse des LLM zu manipulieren.
+  Angreifende infiltrieren einen Drittanbieter und kompromittiert die Produktion eines LoRA-Adapters (Low-Rank Adaptation), der für die Integration in ein On-Device-LLM bestimmt ist, der mit Frameworks wie vLLM oder OpenLLM bereitgestellt wird. Der kompromittierte LoRA-Adapter ist so verändert, dass er versteckte Schwachstellen und bösartigen Code enthält. Sobald dieser Adapter mit dem LLM verbunden ist, bietet er Angreifenden einen versteckten Einstiegspunkt in das System. Der bösartige Code kann während des Modellbetriebs aktiviert werden und ermöglicht es Angreifenden, die Ergebnisse des LLM zu manipulieren.
 #### Szenario 7: CloudBorne und CloudJacking Angriffe
   Diese Angriffe zielen auf Cloud-Infrastrukturen ab, indem sie gemeinsam genutzte Ressourcen und Schwachstellen in den Virtualisierungsschichten ausnutzen. Bei CloudBorne werden Firmware-Schwachstellen in gemeinsam genutzten Cloud-Umgebungen ausgenutzt, um die physischen Server zu kompromittieren, auf denen virtuelle Instanzen laufen. CloudJacking bezieht sich auf die böswillige Kontrolle oder den Missbrauch von Cloud-Instanzen, was zu einem unbefugten Zugriff auf wichtige LLM-Einsatzplattformen führen kann. Beide Angriffe stellen erhebliche Risiken für Lieferketten dar, die auf Cloud-basierte ML-Modelle angewiesen sind, da kompromittierte Umgebungen sensible Daten preisgeben oder weitere Angriffe erleichtern könnten. 
 #### Szenario 8: LeftOvers (CVE-2023-4969)