diff --git a/Lerntagebuch/Woche_11.md b/Lerntagebuch/Woche_11.md
new file mode 100644
index 0000000000000000000000000000000000000000..da7f16237072bdf71ff8c2491d96edba1537e3b7
--- /dev/null
+++ b/Lerntagebuch/Woche_11.md
@@ -0,0 +1,47 @@
+
+# 📖 Lerntagebuch - Woche 11
+
+---
+
+## **1. Vorfallanalyse: PyPi 'Colourama'-Supply-Chain-Angriff (2023)**
+
+### **Problemquelle**
+- Im September 2023 wurde das populäre Python-Paket `colourama` auf PyPi durch eine manipulierte Version ersetzt.
+- Angreifer nutzten gestohlene Zugangsdaten eines Paketmaintainers, um bösartigen Code in das Paket einzufügen.
+- Die infizierte Version enthielt eine Hintertür, die es ermöglichte, sensible Daten (API-Keys, Umgebungsvariablen) von betroffenen Systemen abzugreifen.
+
+### **Auswirkungen und Folgen**
+- Millionen von Entwicklern und Unternehmen nutzen `colourama` für Terminal-Farbformatierungen.
+- Anwendungen, die das Paket automatisch aktualisierten, wurden infiziert.
+- Gestohlene Zugangsdaten führten zu potenziellen Angriffen auf Cloud-Dienste, APIs und kritische Infrastrukturen.
+
+### **Ursache und Schwachstellen**
+- Fehlende Multi-Faktor-Authentifizierung (MFA) auf PyPi ermöglichte den Diebstahl von Zugangsdaten.
+- Automatische Updates (`pip install --upgrade`) luden ohne manuelle Prüfung die infizierte Version herunter.
+- Fehlende Signaturen und mangelnde Code-Überprüfung ermöglichten es Angreifern, den Code unbemerkt zu manipulieren.
+
+### **Reaktionen und Lösungen**
+- PyPi führte verpflichtende MFA für alle Paket-Maintainer ein.
+- Entwickler wurden ermutigt, `pip install --require-hashes` zu verwenden, um Hash-basierte Integritätsprüfungen zu erzwingen.
+- Sicherheits-Tools wie `pip-audit` wurden verstärkt genutzt, um Pakete auf Schwachstellen zu überprüfen.
+
+---
+
+## **2. Untersuchung von Semantic Versioning**
+
+| Notation | Beispiel | Anwendung | Vorteile | Nachteile |
+|----------|---------|-----------|----------|-----------|
+| **Exakte Version** | `1.2.3` | Kritische Anwendungen, die vollständige Stabilität benötigen. | Sicherste Option, keine unerwarteten Änderungen. | Keine automatischen Sicherheitsupdates. |
+| **Bereichsoperatoren** | `>=1.2.0, <2.0.0` | API-Bibliotheken, die mit allen 1.x-Versionen kompatibel sein müssen. | Ermöglicht kleinere Updates ohne Major-Breaking-Changes. | Minor-Versionen können unerwartete Inkompatibilitäten einführen. |
+| **Intervall-Notation** | `[1.2.3, 2.0.0)` | Software, die nur auf einen bestimmten Bereich von Versionen getestet wurde. | Präzise Kontrolle über erlaubte Versionen. | Höherer Wartungsaufwand bei Updates. |
+| **Tilde (~)** | `~1.2.3` | Frontend-Frameworks, die nur Bugfixes innerhalb einer Minor-Version erhalten sollen. | Sicherheitsupdates ohne Funktionsänderungen. | Keine neuen Features oder Performance-Verbesserungen. |
+| **Caret (^)** | `^1.2.3` | Moderne Web-Apps, die regelmäßige Feature-Updates innerhalb einer Major-Version akzeptieren. | Automatische Minor- und Patch-Updates. | Minor-Versionen könnten unvorhergesehene Änderungen enthalten. |
+| **Platzhalter (*)** | `1.*` | Interne Skripte, die immer mit der neuesten verfügbaren Version arbeiten sollen. | Immer aktuelle Features und Fixes. | Risiko von Breaking Changes und unerwarteten Fehlern. |
+
+---
+
+## **Reflexion**
+Die Untersuchung von Paketmanager-Vorfällen hat gezeigt, wie kritisch die Sicherheit von Open-Source-Paketen ist. Ich werde in Zukunft:
+- Nur vertrauenswürdige Pakete mit `pip install --require-hashes` installieren.
+- Automatische Updates mit Bedacht nutzen, insbesondere bei sicherheitskritischen Anwendungen.
+- Versionen in meinen Projekten mit `~` oder `^` einschränken, um Stabilität zu gewährleisten.