# Lagune > Security-Driven Hardening für jede Codebasis Lagune ist ein ausschließlich defensiver Open-Source-Workflow für Security-Driven Hardening (SDH). Er hilft deinem KI-Agenten, jede Codebasis in jeder Sprache jederzeit zu härten: Die Phase charter legt die Sicherheitsregeln fest, bevor du entwickelst, der universelle Befehl /lagune härtet die Arbeit, während sie geschrieben wird, und der Blue-Team-Workflow in fünf Phasen erkennt, was dein System tatsächlich tut, und treibt die Korrekturen voran, die in diesem Kontext zählen. Die Befehle installierst du mit der CLI von skills in deinem Agenten, und ein API-Schlüssel ist nicht nötig. --- # Installation: Sicherheitshärtung für jeden KI-Agenten > Installiere Lagune in jedem Projekt, als Plugin, wo dein Agent eines unterstützt, sonst mit der CLI von skills, und wähle dann die Sicherheitsspezialisierungen, die dazu passen. Kanonische URL: https://lagune.ai/de-DE/docs Sprache: de-DE Original: https://lagune.ai/docs Zuletzt aktualisiert: 2026-11-03 **Lagune** hilft deinem KI-Agenten, ein Projekt sicherer zu machen. Du setzt es auf deinen Code an, und der Agent findet heraus, was dein System tatsächlich tut, und führt dich dann durch die Sicherheitsarbeit, die dafür zählt. **Lagune** ist das erste Projekt der Methodik [Security-Driven Hardening (SDH)](https://lagune.ai/de-DE/docs/references/paper). **Open Source unterstützen** Gefällt dir **Lagune**? [Gib uns einen ⭐ auf **GitHub**](https://github.com/wellwelwel/lagune) ## Wähle deinen Agenten - [Claude Code](https://lagune.ai/de-DE/docs/install/claude-code): Das agentische Coding-Tool von Anthropic - [Codex](https://lagune.ai/de-DE/docs/install/codex): Der Coding-Agent von OpenAI - [Cursor](https://lagune.ai/de-DE/docs/install/cursor): Der Code-Editor mit KI - [GitHub Copilot](https://lagune.ai/de-DE/docs/install/github-copilot-cli): Der KI-Pair-Programmer von GitHub - [Gemini CLI](https://lagune.ai/de-DE/docs/install/gemini-cli): Der Open-Source-Agent für das Terminal von Google - [Antigravity](https://lagune.ai/de-DE/docs/install/antigravity-cli): Die agentische Entwicklungsplattform von Google - [OpenCode](https://lagune.ai/de-DE/docs/install/opencode): Der Open-Source-Coding-Agent - [Devin for Terminal](https://lagune.ai/de-DE/docs/install/devin-cli): Der Terminal-Agent von Cognition - [Factory Droid](https://lagune.ai/de-DE/docs/install/factory-droid): Der Agent für Softwareentwicklung von Factory - [Grok Build](https://lagune.ai/de-DE/docs/install/grok-build): Der Coding-Agent von xAI - [Qwen Code](https://lagune.ai/de-DE/docs/install/qwen-code): Der Coding-Agent für das Terminal von Qwen - [Kimi Code](https://lagune.ai/de-DE/docs/install/kimi-code): Der Coding-Agent von Moonshot AI - [Muse Code](https://lagune.ai/de-DE/docs/install/muse-code): Der Coding-Agent von Meta - [Pi](https://lagune.ai/de-DE/docs/install/pi): Ein minimalistischer Coding-Agent für das Terminal - [Hermes Agent](https://lagune.ai/de-DE/docs/install/hermes-agent): Der Open-Source-Agent von Nous Research - [Universell](https://lagune.ai/de-DE/docs/install/universal): Cline, Kiro CLI, Windsurf, Zed und 66 weitere **Info** - **Lagune** läuft unter der Haube mit **Node.js**, aber du arbeitest in der Sprache deiner Wahl. - Um **Lagune** komplett offline auszuführen, installiere es mit `npm i -D lagune@0.16.0` in deinem Projekt. ## Kategorien Das Sicherheitswissen von **Lagune** steckt in [**Spezialisierungen**](https://lagune.ai/de-DE/docs/catalog), gruppiert in [**Kategorien**](https://lagune.ai/de-DE/docs/categories). - **OWASP** (`owasp`): Härte deine Anwendungen gegen die Sicherheitsrisiken, die OWASP aufführt: Injection, mangelhafte Zugriffskontrolle sowie Fehler bei Authentifizierung und Kryptografie - **Infrastruktur** (`infra`): Härte die Konfiguration von Containern, Workloads und Serverless: Dockerfile, Compose, Pod-Sicherheit, IAM und Trigger von FaaS - **KI / LLM** (`ai`): Härte KI- und LLM-Integrationen gegen Prompt Injection und unsichere Anbindungen an Tools, Agenten, Retrieval und MCP - **Lovable** (`lovable`): Härte KI-generierte Supabase-Apps (Lovable und ähnliche): Lücken in RLS, geleakte Schlüssel der Rolle service_role und unsichere Standardwerte - **JavaScript** (`javascript`): Härte JavaScript und seine Laufzeitumgebungen gegen RCE über eval und child_process, Path Traversal und Prototype Pollution - **Python** (`python`): Härte Python-Code gegen RCE durch Deserialisierung mit pickle und YAML, Traversal über Format-Strings von str.format und Class Pollution - **Rust** (`rust`): Härte Rust-Code gegen unsound implementierte unsafe-APIs, den Missbrauch von transmute, Integer-Überläufe und undefiniertes Verhalten an der FFI-Grenze - **Java** (`java`): Härte Java-Code gegen Gadget-Chains bei der Deserialisierung mit ObjectInputStream, die in Remotecodeausführung münden - **Ruby** (`ruby`): Härte Ruby-Code gegen Gadget-Chains bei der Deserialisierung mit Marshal.load und YAML, die bis zur Remotecodeausführung reichen - **PHP** (`php`): Härte PHP-Code gegen die Umgehung der Authentifizierung durch Type Juggling, Gadget-Chains über Object Injection und unsichere Standardwerte in der Konfiguration - **Go** (`go`): Härte Go-Code gegen Typed-nil-Fehler bei Interfaces, Data Races zwischen Goroutinen und unsichere Nebenläufigkeit in sicherheitsrelevanten Codepfaden - **C / C++** (`c-cpp`): Härte C- und C++-Code gegen Format-String-Fehler, Pufferüberläufe und Out-of-Bounds-Schreibzugriffe, die Codeausführung ermöglichen - **.NET** (`dotnet`): Härte .NET- und C#-Code gegen RCE durch Deserialisierung mit BinaryFormatter und gegen Encoder-Umgehungen, die zu XSS führen Führe `npx lagune write add --categories` mit den Schlüsseln der Kategorien aus, die du auswählst. **Tipp** Ein Projekt beginnt mit `owasp`, und [`/lagune-charter`](https://lagune.ai/de-DE/docs/commands/charter) fügt die Kategorien hinzu, für die seine Lesart des Projekts spricht. ## Voraussetzungen Auf deinem System muss [**Node.js (LTS)**](https://nodejs.org/en/download/package-manager) installiert sein. ## Nutze ein Badge ✨ Du nutzt **Lagune**? Füge eins in deine **README** ein: **Zweifarbig** ![Secured By Lagune](https://img.shields.io/badge/Lagune-2f7bff?logo=springsecurity&logoColor=white&label=Secured%20By&labelColor=303952) ```md [![Secured By Lagune](https://img.shields.io/badge/Lagune-2f7bff?logo=springsecurity&logoColor=white&label=Secured%20By&labelColor=303952)](https://lagune.ai) ``` ![Security Powered By Lagune](https://img.shields.io/badge/Lagune-2f7bff?logo=springsecurity&logoColor=white&label=Security%20Powered%20By&labelColor=303952) ```md [![Security Powered By Lagune](https://img.shields.io/badge/Lagune-2f7bff?logo=springsecurity&logoColor=white&label=Security%20Powered%20By&labelColor=303952)](https://lagune.ai) ``` ![Security-Driven Hardening with Lagune](https://img.shields.io/badge/Lagune-2f7bff?logo=springsecurity&logoColor=white&label=Security-Driven%20Hardening&labelColor=303952) ```md [![Security-Driven Hardening with Lagune](https://img.shields.io/badge/Lagune-2f7bff?logo=springsecurity&logoColor=white&label=Security-Driven%20Hardening&labelColor=303952)](https://lagune.ai) ``` **Einfarbig** ![Secured By Lagune](https://img.shields.io/badge/Secured%20By%20Lagune-2f7bff?logo=springsecurity&logoColor=white) ```md [![Secured By Lagune](https://img.shields.io/badge/Secured%20By%20Lagune-2f7bff?logo=springsecurity&logoColor=white)](https://lagune.ai) ``` ![Security Powered By Lagune](https://img.shields.io/badge/Security%20Powered%20By%20Lagune-2f7bff?logo=springsecurity&logoColor=white) ```md [![Security Powered By Lagune](https://img.shields.io/badge/Security%20Powered%20By%20Lagune-2f7bff?logo=springsecurity&logoColor=white)](https://lagune.ai) ``` ![Security-Driven Hardening](https://img.shields.io/badge/Security--Driven%20Hardening-2f7bff?logo=springsecurity&logoColor=white) ```md [![Security-Driven Hardening](https://img.shields.io/badge/Security--Driven%20Hardening-2f7bff?logo=springsecurity&logoColor=white)](https://lagune.ai) ``` ## Nächster Schritt Erfahre, was jeder der [**Skills**](https://lagune.ai/de-DE/docs/get-started/commands) von **Lagune** macht. ## Häufige Fragen ### Was ist Lagune? Lagune ist ein Open-Source-Workflow für ausschließlich defensive Sicherheit, der deinem KI-Agenten hilft, jede Codebasis zu härten. Du setzt Lagune auf deinen Code an, es erkennt, was dein System tatsächlich tut, und führt dich dann durch die Sicherheitskorrekturen, die in diesem Kontext zählen. ### Wie installiere ich Lagune? Wähle deinen Agenten: Claude Code, GitHub Copilot CLI, Muse Code, Antigravity CLI, Cursor, Kimi Code, OpenCode, Codex CLI, Factory Droid, Grok Build, Devin CLI und Hermes Agent installieren Lagune als Plugin, Gemini CLI und Qwen Code als Erweiterung, Pi als Paket und alle anderen Agenten mit npx skills add wellwelwel/lagune. Es funktioniert in neuen wie in bestehenden Projekten. ### Braucht Lagune einen API-Schlüssel? Nein. Es läuft über deinen eigenen KI-Agenten, daher brauchst du keine API-Schlüssel. ### Welche Voraussetzungen gibt es? Auf deinem System muss Node.js (LTS) installiert sein. ### Welche Programmiersprachen unterstützt Lagune? Alle. Lagune läuft unter der Haube mit Node.js, auditiert und härtet aber Projekte in jeder Programmiersprache. ### Was fügt Lagune meinem Projekt hinzu? Einen Ordner .lagune/ mit dem Sicherheitszustand deines Projekts, den der erste Befehl anlegt, der etwas schreibt. Die CLI von skills installiert außerdem die Slash-Befehle im Projekt, wo dein Agent sie liest, während ein Plugin sie im Agenten selbst behält. ### Wie aktualisiere ich Lagune? Genauso, wie du es installiert hast. Die Installationsseite jedes Agenten zeigt, wie du Lagune dort aktualisierst, und die CLI von skills aktualisiert es mit npx skills update. Deine Sicherheitsprinzipien, die Artefakte der Phasen und deine eigenen Spezialisierungen bleiben unangetastet. ### Welche Spezialisierungen nutzt ein Projekt? Die integrierten seiner Kategorien und dazu seine eigenen. Die Phase charter hält die Kategorien fest, für die ihre Lesart des Projekts spricht, und npx lagune write add --categories ändert sie. ### Muss ich mit der Entwicklung fertig sein, bevor ich mein Projekt absichere? Nein. Der Befehl /lagune härtet die Arbeit schon beim Schreiben: Er nimmt jeden Prompt an, setzt um, was du verlangt hast, und härtet es mit sicheren Standardwerten, geleitet von den Sicherheitsprinzipien. Der Blue-Team-Workflow in fünf Phasen auditiert, was bereits existiert. ### Kann Lagune ein bestehendes Projekt auditieren? Ja. Der Blue-Team-Workflow in fünf Phasen auditiert, was bereits existiert: charter legt deine Sicherheitsregeln fest, detect erfasst, was das System tut und wo die Risiken liegen, plan bewertet jeden Befund und ordnet ihm eine Korrektur zu, harden setzt die Korrekturen um, und verify weist nach, dass sie greifen, und schließt sie ab. ### Was unterscheidet die Arbeit mit Lagune davon, den Agenten einfach zu bitten, Schwachstellen und Sicherheitslücken zu erfassen? Ein Agent, der den Code auf eigene Faust liest, findet, was nach einer Schwachstelle aussieht, und übergeht, was nach einer Schutzmaßnahme aussieht. Eine Liste gesperrter Adressen wirkt, als hätte sich schon jemand um das Risiko gekümmert, also prüft niemand nach, dass ihr die meisten fehlen, und der Code wird ausgeliefert. Lagune kehrt diese Grundannahme um: Eine Schutzvorkehrung, die schon im Code steht, gilt als nicht nachgewiesen, bis sie geprüft ist, jede Spezialisierung im Katalog bekommt ein ausdrückliches Urteil, und verify fragt, ob das Risiko beseitigt ist, nicht, ob eine Schutzmaßnahme vorhanden ist. Außerdem bleibt jeder Befund über alle Durchläufe hinweg ein einziger nachverfolgter Eintrag, sodass sich sein Abschluss nachweisen lässt und er ausgetragen werden kann, während dir eine einfache Anfrage jedes Mal einen anderen Bericht liefert, ohne Vergleichsgrundlage. ### Was unterscheidet die Entwicklung mit Lagune davon, den Agenten einfach zu bitten, sicheren Code zu schreiben? Die Bitte um sicheren Code überlässt dem Agenten, was sicher bedeutet, und setzt voraus, dass du weißt, wonach du fragen musst. Die Anforderung steckt meist schon in deiner Anfrage, ohne dass einer von euch beiden sie sieht: Wenn du eine Seite verlangst, die die Kurse zeigt, auf die ein Nutzer Zugriff hat, formulierst du damit eine Autorisierungsregel, und eine Prüfung, die nie geschrieben wird, hinterlässt im Code nichts, was auffallen könnte. Der Befehl /lagune lädt deine Sicherheitsprinzipien und die Spezialisierungen, die zu dem passen, was gleich entstehen soll, bevor die erste Zeile geschrieben ist, und prüft das Ergebnis danach noch einmal anhand der Verteidigung, die er eingesetzt hat. Die sichere Variante kostet selten mehr als die unsichere, also entscheidet das Wissen, zu welcher du greifen musst, über das Ergebnis, und genau dieses Wissen ist von Anfang an da. ### Führt Lagune DAST (Dynamic Application Security Testing) durch oder testet es meine laufende Anwendung? Nein. Lagune liest Code und führt dein System nie aus oder schickt ihm manipulierte Anfragen. Die Phase verify bestätigt, dass eine Schutzmaßnahme im Quellcode vorhanden und korrekt ist, und das ist eine andere Frage als die, ob sie einem Angriff auf ein laufendes Ziel standhält, daher ist "cannot tell from the code" ein legitimes Urteil statt eines stillschweigenden Durchwinkens. DAST beantwortet die Frage zur Laufzeit und Lagune die Frage zum Quellcode, sodass keines das andere ersetzt. Selbst der optionale Befehl prove hält sich an diese Grenze: Seine Tests prüfen das sichere Verhalten, nie Angriffs-Payloads. ### Ersetzt Lagune einen Pentest (Penetrationstest)? Nein, auf keinen Fall! Ein Pentest ist ein autorisierter Auftrag, bei dem eine Fachperson mit eigenem Urteilsvermögen gegen dein laufendes System vorgeht, Befunde verkettet und die Geschäftslogik untersucht, die keine Regel pro Angriffsfläche beschreibt. Befunde aus einem Pentest können in den Blue-Team-Workflow von Lagune einfließen, indem du sie der Phase detect als Anliegen übergibst, sodass das, was eine Fachperson meldet, geplant, gehärtet und überprüft wird. ## Sicherheitsrichtlinie Bitte lies die [SECURITY.md](https://github.com/wellwelwel/lagune/blob/main/SECURITY.md). ## Lizenz **Lagune** steht unter der [Apache License 2.0](https://github.com/wellwelwel/lagune/blob/main/LICENSE). Copyright © 2026-heute [Weslley Araújo](https://github.com/wellwelwel) und [Mitwirkende](https://github.com/wellwelwel/lagune/graphs/contributors). --- # Lagune als Plugin in Antigravity CLI installieren > Installiere Lagune als Plugin in Antigravity CLI, halte es aktuell und gib die Engine vorab frei. Kanonische URL: https://lagune.ai/de-DE/docs/install/antigravity-cli Sprache: de-DE Original: https://lagune.ai/docs/install/antigravity-cli Zuletzt aktualisiert: 2026-11-03 Installiere das Plugin über dein Terminal: ```bash agy plugin install https://github.com/wellwelwel/lagune/tree/plugin-antigravity ``` ## Aktualisierung Um **Lagune** zu aktualisieren, installiere das Plugin erneut: ```bash agy plugin install https://github.com/wellwelwel/lagune/tree/plugin-antigravity ``` ## Befehle Gib die Befehle mit vorangestelltem Plugin-Namen ein, etwa `/lagune:lagune-charter` für `/lagune-charter`. --- **Berechtigungen** Die Engine läuft über zwei Tools: `lagune_read` liest nur dein Projekt und `lagune_write` schreibt nur in `.lagune/`. Ein Befehl, den du als erste Nachricht einer Sitzung sendest, läuft, bevor sie geladen sind, und nutzt deshalb stattdessen **npx**. Um die Tools und **npx** vorab zu erlauben, füge diese Regeln zu `~/.gemini/antigravity-cli/settings.json` hinzu: ```json { "permissions": { "allow": [ "mcp(lagune_lagune/lagune_read)", "mcp(lagune_lagune/lagune_write)", "command(regex:npx --yes lagune@[0-9.]+)" ] } } ``` ## Häufige Fragen ### Wie installiere ich Lagune in Antigravity CLI? Führe agy plugin install https://github.com/wellwelwel/lagune/tree/plugin-antigravity aus. ### Wie aktualisiere ich Lagune in Antigravity CLI? Führe agy plugin install https://github.com/wellwelwel/lagune/tree/plugin-antigravity erneut aus. ### Wie führe ich die Befehle von Lagune in Antigravity CLI aus? Gib sie mit vorangestelltem Plugin-Namen ein, etwa /lagune:lagune-charter. ### Kann Antigravity CLI Lagune ohne Rückfrage ausführen? Ja. Erlaube mcp(lagune_lagune/lagune_read), mcp(lagune_lagune/lagune_write) und command(regex:npx --yes lagune@[0-9.]+) in den Einstellungen von Antigravity CLI. Die Regel für npx deckt einen Befehl ab, den du als erste Nachricht einer Sitzung sendest. --- # Lagune als Plugin in Claude Code installieren > Installiere Lagune als Plugin in Claude Code, im Terminal, in der Erweiterung oder in der Desktop-App, halte es aktuell und gib die Engine vorab frei. Kanonische URL: https://lagune.ai/de-DE/docs/install/claude-code Sprache: de-DE Original: https://lagune.ai/docs/install/claude-code Zuletzt aktualisiert: 2026-11-03 **Terminal** Installiere das Plugin über dein Terminal: ```bash claude plugin install lagune --marketplace wellwelwel/lagune ``` Oder in einer Sitzung von **Claude Code**: ```text /plugin marketplace add wellwelwel/lagune /plugin install lagune@lagune ``` **Erweiterung** - Gib `/plugin` ein und wähle **Manage plugins**. - Füge `wellwelwel/lagune` im Tab **Marketplaces** hinzu. - Installiere `lagune` im Tab **Plugins**. **Desktop** - Installiere **Lagune** über das Terminal oder die Erweiterung und wähle in der Erweiterung **Install for you**. - Starte eine neue Sitzung in der Desktop-App: Sie lädt die Plugins, die du für dich selbst installierst. ## Aktualisierung **Terminal** Um **Lagune** zu aktualisieren, führe Folgendes aus: ```bash claude plugin marketplace update lagune claude plugin update lagune@lagune ``` Für automatische Aktualisierungen wähle beim Marketplace `lagune` unter `/plugin` die Option **Enable auto-update**. **Erweiterung** - Gib `/plugin` ein und wähle **Manage plugins**. - Öffne den Tab **Marketplaces**. - Wähle das Aktualisierungssymbol bei `lagune`. **Desktop** - Aktualisiere **Lagune** über das Terminal oder die Erweiterung. - Starte eine neue Sitzung in der Desktop-App. ## Befehle Gib die Befehle mit ihrem Namen ein, etwa `/lagune-charter`, oder mit vorangestelltem Plugin-Namen, etwa `/lagune:lagune-charter`. --- **Berechtigungen** Die Engine läuft über zwei Tools: `lagune_read` liest nur dein Projekt und `lagune_write` schreibt nur in `.lagune/`. Um sie vorab zu erlauben, füge diese Regeln für ein einzelnes Projekt zu `.claude/settings.json` hinzu oder für alle Projekte zu `~/.claude/settings.json`: ```json { "permissions": { "allow": [ "mcp__plugin_lagune_lagune__lagune_read", "mcp__plugin_lagune_lagune__lagune_write" ] } } ``` Läuft die Engine über **npx**, wie bei **skills.sh**, erlaube `Bash(npx --yes lagune@*)`. Ist die Sandbox aktiv, füge außerdem `registry.npmjs.org` zu `sandbox.network.allowedDomains` hinzu. ## Häufige Fragen ### Wie installiere ich Lagune in Claude Code? Führe claude plugin install lagune --marketplace wellwelwel/lagune aus. In einer Sitzung oder in der Erweiterung fügst du über die Plugin-Verwaltung den Marketplace wellwelwel/lagune hinzu und installierst lagune. Die Desktop-App lädt das Plugin, sobald du es im Terminal oder in der Erweiterung für dich selbst installierst. ### Wie aktualisiere ich Lagune in Claude Code? Führe claude plugin marketplace update lagune aus, dann claude plugin update lagune@lagune, oder wähle beim Marketplace lagune unter /plugin die Option Enable auto-update. In der Erweiterung öffnest du über /plugin den Bereich Manage plugins und wählst das Aktualisierungssymbol beim Marketplace lagune. Die Desktop-App lädt die Aktualisierung in ihrer nächsten Sitzung. ### Wie führe ich die Befehle von Lagune in Claude Code aus? Gib sie mit ihrem Namen ein, etwa /lagune-charter, oder mit vorangestelltem Plugin-Namen, etwa /lagune:lagune-charter. ### Kann Claude Code Lagune ohne Rückfrage ausführen? Ja. Erlaube mcp__plugin_lagune_lagune__lagune_read und mcp__plugin_lagune_lagune__lagune_write in den Einstellungen von Claude Code, dazu Bash(npx --yes lagune@*), wenn die Engine über npx läuft. --- # Lagune als Plugin in Codex CLI installieren > Installiere Lagune als Plugin in Codex CLI, halte es aktuell und führe die Engine in der Sandbox aus. Kanonische URL: https://lagune.ai/de-DE/docs/install/codex Sprache: de-DE Original: https://lagune.ai/docs/install/codex Zuletzt aktualisiert: 2026-11-03 Installiere das Plugin über dein Terminal: ```bash codex plugin marketplace add wellwelwel/lagune codex plugin add lagune@lagune ``` ## Aktualisierung Um **Lagune** zu aktualisieren, führe Folgendes aus: ```bash codex plugin marketplace upgrade lagune ``` ## Befehle Gib `$` und den Befehl mit vorangestelltem Plugin-Namen ein, gefolgt von deiner Eingabe, etwa `$lagune:lagune-charter` für `/lagune-charter`. Gibst du `$` ein, erscheinen die Befehle in einer Liste, und wählst du einen aus, wird sein vollständiger Name eingefügt. --- **Berechtigungen** Die Sandbox von **Codex** hat keinen Netzwerkzugriff. Installiere die Engine über dein eigenes Terminal in deinem Projekt, einmal und nach jeder Aktualisierung erneut: ```bash npm i -D lagune@0.16.0 ``` ## Häufige Fragen ### Wie installiere ich Lagune in Codex CLI? Führe codex plugin marketplace add wellwelwel/lagune aus, dann codex plugin add lagune@lagune. ### Wie aktualisiere ich Lagune in Codex CLI? Führe codex plugin marketplace upgrade lagune aus. ### Wie führe ich die Befehle von Lagune in Codex CLI aus? Gib $ und den Befehl mit vorangestelltem Plugin-Namen ein, gefolgt von deiner Eingabe, etwa $lagune:lagune-charter. ### Funktioniert Lagune in der Sandbox von Codex? Ja, sobald du die Engine mit npm i -D lagune@0.16.0 über dein eigenes Terminal in deinem Projekt installierst, einmal und nach jeder Aktualisierung erneut. --- # Lagune als Plugin in Cursor installieren > Installiere Lagune als Plugin in Cursor und in der Cursor CLI, halte es aktuell und gib die Engine vorab frei. Kanonische URL: https://lagune.ai/de-DE/docs/install/cursor Sprache: de-DE Original: https://lagune.ai/docs/install/cursor Zuletzt aktualisiert: 2026-11-03 **Cursor** - Öffne **Customize**. - Wähle **From GitHub Repository** und gib `https://github.com/wellwelwel/lagune` ein. - Wähle bei **Lagune** die Option **Install** und lege als Geltungsbereich das Projekt oder den Benutzer fest. **Cursor CLI** - Füge den Marketplace über dein Terminal hinzu: ```bash agent plugin marketplace add https://github.com/wellwelwel/lagune --git-ref plugin-cursor ``` - Gib `/plugins` in einer Sitzung von `agent` ein. - Installiere **Lagune**. Ist **Lagune** bereits in **Claude Code** installiert, lädt die **Cursor CLI** das Plugin von dort. ## Aktualisierung **Cursor** - Öffne **Customize**. - Wähle beim Marketplace `lagune` die Option **Refresh**. **Cursor CLI** - Ersetze den Marketplace über dein Terminal: ```bash agent plugin marketplace remove lagune agent plugin marketplace add https://github.com/wellwelwel/lagune --git-ref plugin-cursor ``` - Gib `/plugins` in einer Sitzung von `agent` ein. - Installiere **Lagune** erneut. ## Befehle Gib die Befehle mit ihrem Namen ein, etwa `/lagune-charter`. --- **Berechtigungen** In **Cursor** starten die Befehle die Engine über **npx**, und der Standardmodus Auto-review erlaubt das ohne Rückfrage. In der **Cursor CLI** läuft die Engine über zwei Tools: `lagune_read` liest nur dein Projekt und `lagune_write` schreibt nur in `.lagune/`. Um sie vorab zu erlauben, füge diese Regeln für ein einzelnes Projekt zu `.cursor/cli.json` hinzu oder für alle Projekte zu `~/.cursor/cli-config.json`: ```json { "permissions": { "allow": [ "Mcp(plugin-lagune-lagune:lagune_read)", "Mcp(plugin-lagune-lagune:lagune_write)" ] } } ``` Läuft die Engine über **npx**, wie bei **skills.sh**, erlaube `Shell(npx:--yes lagune@*)`. ## Häufige Fragen ### Wie installiere ich Lagune in Cursor? Öffne in Cursor Customize, wähle From GitHub Repository, gib https://github.com/wellwelwel/lagune ein und installiere Lagune. Führe in der Cursor CLI agent plugin marketplace add https://github.com/wellwelwel/lagune --git-ref plugin-cursor aus und installiere Lagune dann über /plugins. ### Wie aktualisiere ich Lagune in Cursor? Wähle in Cursor unter Customize beim Marketplace lagune die Option Refresh. Entferne in der Cursor CLI den Marketplace lagune, füge ihn erneut hinzu und installiere Lagune dann über /plugins neu. ### Wie führe ich die Befehle von Lagune in Cursor aus? Gib sie mit ihrem Namen ein, etwa /lagune-charter. ### Kann Cursor Lagune ohne Rückfrage ausführen? Ja. Der Standardmodus Auto-review von Cursor erlaubt das bereits. Erlaube in der Cursor CLI Mcp(plugin-lagune-lagune:lagune_read) und Mcp(plugin-lagune-lagune:lagune_write), dazu Shell(npx:--yes lagune@*), wenn die Engine über npx läuft. --- # Lagune als Plugin in Devin CLI installieren > Installiere Lagune als Plugin in Devin CLI und halte es aktuell. Kanonische URL: https://lagune.ai/de-DE/docs/install/devin-cli Sprache: de-DE Original: https://lagune.ai/docs/install/devin-cli Zuletzt aktualisiert: 2026-11-03 Melde dich bei **Devin** an und installiere dann das Plugin über dein Terminal: ```bash devin auth login devin plugins install wellwelwel/lagune ``` ## Aktualisierung Um **Lagune** zu aktualisieren, führe Folgendes aus: ```bash devin plugins update lagune ``` ## Befehle Gib die Befehle mit vorangestelltem Plugin-Namen ein, etwa `/lagune:lagune-charter` für `/lagune-charter`. Auch das Menü `/` listet sie auf. ## Häufige Fragen ### Wie installiere ich Lagune in Devin CLI? Melde dich mit devin auth login an und führe dann devin plugins install wellwelwel/lagune aus. ### Wie aktualisiere ich Lagune in Devin CLI? Führe devin plugins update lagune aus. ### Wie führe ich die Befehle von Lagune in Devin CLI aus? Gib sie mit vorangestelltem Plugin-Namen ein, etwa /lagune:lagune-charter. Auch das Menü / listet sie auf. --- # Lagune als Plugin in Factory Droid installieren > Installiere Lagune als Plugin in Factory Droid, halte es aktuell und erlaube die Tools der Engine. Kanonische URL: https://lagune.ai/de-DE/docs/install/factory-droid Sprache: de-DE Original: https://lagune.ai/docs/install/factory-droid Zuletzt aktualisiert: 2026-11-03 Installiere das Plugin über dein Terminal: ```bash droid plugin marketplace add wellwelwel/lagune droid plugin install lagune@lagune ``` ## Aktualisierung Um **Lagune** zu aktualisieren, führe Folgendes aus: ```bash droid plugin marketplace update lagune droid plugin update lagune@lagune ``` ## Befehle Gib die Befehle mit ihrem Namen ein, etwa `/lagune-charter`. --- **Berechtigungen** Die Engine läuft über zwei Tools: `lagune_read` liest nur dein Projekt und `lagune_write` schreibt nur in `.lagune/`. Wenn **Factory Droid** nachfragt, erlaube jedes davon dauerhaft. Es fragt erneut, nachdem es einen neuen Commit im Marketplace `lagune` synchronisiert hat, was beim Start passieren kann. ## Häufige Fragen ### Wie installiere ich Lagune in Factory Droid? Führe droid plugin marketplace add wellwelwel/lagune aus, dann droid plugin install lagune@lagune. ### Wie aktualisiere ich Lagune in Factory Droid? Führe droid plugin marketplace update lagune aus, dann droid plugin update lagune@lagune. ### Wie führe ich die Befehle von Lagune in Factory Droid aus? Gib sie mit ihrem Namen ein, etwa /lagune-charter. ### Kann Factory Droid Lagune ohne Rückfrage ausführen? Ja. Erlaube lagune_read und lagune_write dauerhaft, wenn Factory Droid nachfragt. Es fragt erneut, nachdem es einen neuen Commit im Marketplace lagune synchronisiert hat. --- # Lagune als Erweiterung in Gemini CLI installieren > Installiere Lagune als Erweiterung in Gemini CLI, halte sie aktuell und gib die Engine vorab frei. Kanonische URL: https://lagune.ai/de-DE/docs/install/gemini-cli Sprache: de-DE Original: https://lagune.ai/docs/install/gemini-cli Zuletzt aktualisiert: 2026-11-03 Installiere die Erweiterung über dein Terminal: ```bash gemini extensions install https://github.com/wellwelwel/lagune ``` ## Aktualisierung Um **Lagune** zu aktualisieren, führe Folgendes aus: ```bash gemini extensions update lagune ``` Für automatische Aktualisierungen installiere die Erweiterung mit `--auto-update`. ## Befehle Gib die Befehle mit vorangestelltem Namen der Erweiterung ein, etwa `/lagune:lagune-charter` für `/lagune-charter`. --- **Berechtigungen** Die Engine läuft über zwei Tools: `lagune_read` liest nur dein Projekt und `lagune_write` schreibt nur in `.lagune/`. **Gemini CLI** startet sie nur in einem vertrauenswürdigen Ordner. Um sie vorab zu erlauben, speichere diese Regel als `~/.gemini/policies/lagune.toml`: ```toml [[rule]] mcpName = "lagune" toolName = ["lagune_read", "lagune_write"] decision = "allow" priority = 100 ``` Läuft die Engine über **npx**, wie bei **skills.sh**, ergänze dieselbe Datei um diese Regel: ```toml [[rule]] toolName = "run_shell_command" commandRegex = 'npx --yes lagune@\d+\.\d+\.\d+\s' decision = "allow" priority = 100 ``` ## Häufige Fragen ### Wie installiere ich Lagune in Gemini CLI? Führe gemini extensions install https://github.com/wellwelwel/lagune aus. ### Wie aktualisiere ich Lagune in Gemini CLI? Führe gemini extensions update lagune aus oder installiere die Erweiterung mit --auto-update. ### Wie führe ich die Befehle von Lagune in Gemini CLI aus? Gib sie mit vorangestelltem Namen der Erweiterung ein, etwa /lagune:lagune-charter. ### Kann Gemini CLI Lagune ohne Rückfrage ausführen? Ja. Füge eine Policy-Regel hinzu, die die Tools lagune_read und lagune_write des Servers lagune erlaubt, dazu eine für run_shell_command mit npx --yes lagune@ und einer Version, wenn die Engine über npx läuft. --- # Lagune als Plugin in GitHub Copilot CLI installieren > Installiere Lagune als Plugin in GitHub Copilot CLI und halte es aktuell. Kanonische URL: https://lagune.ai/de-DE/docs/install/github-copilot-cli Sprache: de-DE Original: https://lagune.ai/docs/install/github-copilot-cli Zuletzt aktualisiert: 2026-11-03 Installiere das Plugin über dein Terminal: ```bash copilot plugin marketplace add wellwelwel/lagune copilot plugin install lagune@lagune ``` Installiere **Lagune** für **GitHub Copilot** in einem Editor mit [**skills.sh**](https://lagune.ai/de-DE/docs/install/universal). ## Aktualisierung Um **Lagune** zu aktualisieren, führe Folgendes aus: ```bash copilot plugin marketplace update lagune copilot plugin update lagune@lagune ``` ## Befehle Gib die Befehle mit ihrem Namen ein, etwa `/lagune-charter`. ## Häufige Fragen ### Wie installiere ich Lagune in GitHub Copilot CLI? Führe copilot plugin marketplace add wellwelwel/lagune aus, dann copilot plugin install lagune@lagune. ### Wie aktualisiere ich Lagune in GitHub Copilot CLI? Führe copilot plugin marketplace update lagune aus, dann copilot plugin update lagune@lagune. ### Wie führe ich die Befehle von Lagune in GitHub Copilot CLI aus? Gib sie mit ihrem Namen ein, etwa /lagune-charter. ### Kann ich Lagune mit GitHub Copilot in VS Code nutzen? Ja. Installiere Lagune in VS Code oder einem anderen Editor mit skills.sh statt mit dem Plugin. --- # Lagune als Plugin in Grok Build installieren > Installiere Lagune als Plugin in Grok Build, halte es aktuell und gib die Engine vorab frei. Kanonische URL: https://lagune.ai/de-DE/docs/install/grok-build Sprache: de-DE Original: https://lagune.ai/docs/install/grok-build Zuletzt aktualisiert: 2026-11-03 Installiere das Plugin über dein Terminal: ```bash grok plugin install wellwelwel/lagune@plugin-grok --trust ``` ## Aktualisierung Um **Lagune** zu aktualisieren, führe Folgendes aus: ```bash grok plugin update lagune ``` ## Befehle Gib die Befehle mit ihrem Namen ein, etwa `/lagune-charter`, oder mit vorangestelltem Plugin-Namen, etwa `/lagune:lagune-charter`. --- **Berechtigungen** Die Engine läuft über zwei Tools: `lagune_read` liest nur dein Projekt und `lagune_write` schreibt nur in `.lagune/`. Um sie vorab zu erlauben, füge diese Regeln zu `~/.grok/config.toml` hinzu: ```toml [permission] allow = ["MCPTool(lagune__lagune_read)", "MCPTool(lagune__lagune_write)"] ``` Läuft die Engine über **npx**, wie bei **skills.sh**, erlaube `Bash(npx --yes lagune@*)`. ## Häufige Fragen ### Wie installiere ich Lagune in Grok Build? Führe grok plugin install wellwelwel/lagune@plugin-grok --trust aus. ### Wie aktualisiere ich Lagune in Grok Build? Führe grok plugin update lagune aus. ### Wie führe ich die Befehle von Lagune in Grok Build aus? Gib sie mit ihrem Namen ein, etwa /lagune-charter, oder mit vorangestelltem Plugin-Namen, etwa /lagune:lagune-charter. ### Kann Grok Build Lagune ohne Rückfrage ausführen? Ja. Erlaube MCPTool(lagune__lagune_read) und MCPTool(lagune__lagune_write) in der Konfiguration von Grok Build, dazu Bash(npx --yes lagune@*), wenn die Engine über npx läuft. --- # Lagune als Plugin in Hermes Agent installieren > Installiere Lagune als Plugin in Hermes Agent und halte es aktuell. Kanonische URL: https://lagune.ai/de-DE/docs/install/hermes-agent Sprache: de-DE Original: https://lagune.ai/docs/install/hermes-agent Zuletzt aktualisiert: 2026-11-03 Installiere das Plugin über dein Terminal: ```bash hermes plugins install wellwelwel/lagune --enable ``` - Wenn **Hermes Agent** dich bittet, ein Plugin von außerhalb seines Katalogs zu bestätigen, **bestätige es**. - Wenn er anbietet, die Abhängigkeiten des Repositorys für **Node.js** zu installieren, **lehne ab**. ## Aktualisierung Um **Lagune** zu aktualisieren, führe Folgendes aus: ```bash hermes plugins update lagune ``` ## Befehle Gib die Befehle mit vorangestelltem Plugin-Namen ein, etwa `/lagune:lagune-charter` für `/lagune-charter` und `/lagune:lagune` für `/lagune`. ## Häufige Fragen ### Wie installiere ich Lagune in Hermes Agent? Führe hermes plugins install wellwelwel/lagune --enable aus. Bestätige das Plugin, wenn du gefragt wirst, und lehne es ab, die Abhängigkeiten des Repositorys für Node.js zu installieren. ### Wie aktualisiere ich Lagune in Hermes Agent? Führe hermes plugins update lagune aus. ### Wie führe ich die Befehle von Lagune in Hermes Agent aus? Gib sie mit vorangestelltem Plugin-Namen ein, etwa /lagune:lagune-charter und /lagune:lagune. --- # Lagune als Plugin in Kimi Code installieren > Installiere Lagune als Plugin in Kimi Code und halte es aktuell. Kanonische URL: https://lagune.ai/de-DE/docs/install/kimi-code Sprache: de-DE Original: https://lagune.ai/docs/install/kimi-code Zuletzt aktualisiert: 2026-11-03 Installiere das Plugin in einer Sitzung von **Kimi Code**, wähle **Trust and install** und starte dann eine neue Sitzung, um es zu laden: ```text /plugins install https://github.com/wellwelwel/lagune /new ``` ## Aktualisierung Um **Lagune** zu aktualisieren, installiere das Plugin erneut: ```text /plugins install https://github.com/wellwelwel/lagune /new ``` ## Befehle Gib die Befehle mit vorangestelltem Plugin-Namen ein, etwa `/lagune:lagune-charter` für `/lagune-charter`. Das Menü `/` listet sie als `/skill:lagune:lagune-charter` auf, was ebenfalls funktioniert. ## Häufige Fragen ### Wie installiere ich Lagune in Kimi Code? Führe in einer Sitzung von Kimi Code /plugins install https://github.com/wellwelwel/lagune aus, wähle Trust and install und führe dann /new aus. ### Wie aktualisiere ich Lagune in Kimi Code? Führe /plugins install https://github.com/wellwelwel/lagune erneut aus, dann /new. ### Wie führe ich die Befehle von Lagune in Kimi Code aus? Gib sie mit vorangestelltem Plugin-Namen ein, etwa /lagune:lagune-charter, oder so, wie das Menü / sie auflistet, etwa /skill:lagune:lagune-charter. --- # Lagune als Plugin in Muse Code installieren > Installiere Lagune als Plugin in Muse Code, halte es aktuell und führe die Engine in der Sandbox aus. Kanonische URL: https://lagune.ai/de-DE/docs/install/muse-code Sprache: de-DE Original: https://lagune.ai/docs/install/muse-code Zuletzt aktualisiert: 2026-11-03 Installiere das Plugin über dein Terminal: ```bash muse plugins marketplace add lagune wellwelwel/lagune muse plugins install lagune@lagune ``` ## Aktualisierung Um **Lagune** zu aktualisieren, lade den Marketplace neu und installiere das Plugin erneut: ```bash muse plugins marketplace update lagune muse plugins remove lagune muse plugins install lagune@lagune ``` ## Befehle Gib die Befehle mit ihrem Namen ein, etwa `/lagune-charter`, oder mit vorangestelltem Plugin-Namen, etwa `/lagune:lagune-charter`. --- **Berechtigungen** Die Sandbox von **Muse Code** kann die Engine nicht herunterladen. Installiere sie über dein eigenes Terminal in deinem Projekt, einmal und nach jeder Aktualisierung erneut: ```bash npm i -D lagune@0.16.0 ``` ## Häufige Fragen ### Wie installiere ich Lagune in Muse Code? Führe muse plugins marketplace add lagune wellwelwel/lagune aus, dann muse plugins install lagune@lagune. ### Wie aktualisiere ich Lagune in Muse Code? Führe muse plugins marketplace update lagune aus und installiere das Plugin dann mit muse plugins remove lagune und muse plugins install lagune@lagune neu. ### Wie führe ich die Befehle von Lagune in Muse Code aus? Gib sie mit ihrem Namen ein, etwa /lagune-charter, oder mit vorangestelltem Plugin-Namen, etwa /lagune:lagune-charter. ### Funktioniert Lagune in der Sandbox von Muse Code? Ja, sobald du die Engine mit npm i -D lagune@0.16.0 über dein eigenes Terminal in deinem Projekt installierst, einmal und nach jeder Aktualisierung erneut. --- # Lagune als Plugin in OpenCode installieren > Installiere Lagune als Plugin in OpenCode 1.x und 2.x und halte es aktuell. Kanonische URL: https://lagune.ai/de-DE/docs/install/opencode Sprache: de-DE Original: https://lagune.ai/docs/install/opencode Zuletzt aktualisiert: 2026-11-03 **OpenCode 2.x** Installiere das Plugin über dein Terminal: ```bash opencode plugin add lagune ``` Oder füge es der Liste `plugins` in `opencode.json` hinzu: ```json { "plugins": ["lagune"] } ``` **OpenCode 1.x** Installiere das Plugin über dein Terminal in deinem Projekt oder ergänze `-g`, um es für alle deine Projekte zu installieren: ```bash opencode plugin lagune ``` Oder füge es der Liste `plugin` in `opencode.json` hinzu: ```json { "plugin": ["lagune"] } ``` ## Aktualisierung **OpenCode 2.x** Um **Lagune** zu aktualisieren, führe Folgendes aus: ```bash opencode plugin update lagune opencode reload ``` **OpenCode 1.x** Um **Lagune** zu aktualisieren, installiere die neue Version über die alte und ergänze `-g`, falls du das Plugin für alle deine Projekte installiert hast: ```bash opencode plugin lagune@0.16.0 --force ``` ## Befehle **OpenCode 2.x** Gib `@` ein, wähle den Befehl, etwa `@lagune-charter`, und schreibe deine Eingabe dann in dieselbe Nachricht. **OpenCode 1.x** Gib die Befehle mit ihrem Namen ein, etwa `/lagune-charter`. Sie stehen unter `/skills`, nicht im Menü `/`. --- **Berechtigungen** Die Engine läuft über zwei Tools: `lagune_read` liest nur dein Projekt und `lagune_write` schreibt nur in `.lagune/`. **OpenCode** führt sie ohne Rückfrage aus. ## Häufige Fragen ### Wie installiere ich Lagune in OpenCode? Führe in OpenCode 2.x opencode plugin add lagune aus. Führe in OpenCode 1.x opencode plugin lagune aus und ergänze -g, um das Plugin für alle deine Projekte zu installieren. ### Wie aktualisiere ich Lagune in OpenCode? Führe in OpenCode 2.x opencode plugin update lagune aus, dann opencode reload. Führe in OpenCode 1.x opencode plugin lagune@0.16.0 --force aus. ### Wie führe ich die Befehle von Lagune in OpenCode aus? Gib in OpenCode 2.x @ ein, wähle den Befehl, etwa @lagune-charter, und schreibe deine Eingabe dann in dieselbe Nachricht. Gib sie in OpenCode 1.x mit ihrem Namen ein, etwa /lagune-charter, oder finde sie unter /skills. ### Fragt OpenCode um Erlaubnis, bevor Lagune läuft? Nein. OpenCode führt die beiden Tools der Engine, lagune_read und lagune_write, ohne Rückfrage aus. --- # Lagune als Paket in Pi installieren > Installiere Lagune als Paket in Pi, über npm oder GitHub, und halte es aktuell. Kanonische URL: https://lagune.ai/de-DE/docs/install/pi Sprache: de-DE Original: https://lagune.ai/docs/install/pi Zuletzt aktualisiert: 2026-11-03 **npm** Installiere das Paket über dein Terminal: ```bash pi install npm:lagune ``` **GitHub** Installiere den neuesten Commit von **GitHub**, der die Engine über **npx** startet: ```bash pi install git:github.com/wellwelwel/lagune ``` ## Aktualisierung **npm** Um **Lagune** zu aktualisieren, führe Folgendes aus: ```bash pi update npm:lagune ``` **GitHub** Um **Lagune** zu aktualisieren, führe Folgendes aus: ```bash pi update git:github.com/wellwelwel/lagune ``` `pi update --extensions` aktualisiert jedes Paket, das du installiert hast, während `pi update` allein nur **Pi** aktualisiert. ## Befehle Gib die Befehle mit dem Präfix `skill:` ein, etwa `/skill:lagune-charter` für `/lagune-charter`. ## Häufige Fragen ### Wie installiere ich Lagune in Pi? Führe pi install npm:lagune aus, oder pi install git:github.com/wellwelwel/lagune für den neuesten Commit von GitHub. ### Wie aktualisiere ich Lagune in Pi? Führe pi update npm:lagune aus, oder pi update git:github.com/wellwelwel/lagune bei einer Installation von GitHub. pi update --extensions aktualisiert jedes Paket, das du installiert hast. ### Wie führe ich die Befehle von Lagune in Pi aus? Gib sie mit dem Präfix skill: ein, etwa /skill:lagune-charter. --- # Lagune als Erweiterung in Qwen Code installieren > Installiere Lagune als Erweiterung in Qwen Code, halte sie aktuell und gib die Engine vorab frei. Kanonische URL: https://lagune.ai/de-DE/docs/install/qwen-code Sprache: de-DE Original: https://lagune.ai/docs/install/qwen-code Zuletzt aktualisiert: 2026-11-03 Installiere die Erweiterung über dein Terminal: ```bash qwen extensions install lagune ``` ## Aktualisierung Um **Lagune** zu aktualisieren, führe Folgendes aus: ```bash qwen extensions update lagune ``` Für automatische Aktualisierungen installiere die Erweiterung mit `--auto-update`. ## Befehle Gib die Befehle mit vorangestelltem Namen der Erweiterung ein, etwa `/lagune:lagune-charter` für `/lagune-charter`. --- **Berechtigungen** Die Engine läuft über zwei Tools: `lagune_read` liest nur dein Projekt und `lagune_write` schreibt nur in `.lagune/`. Um sie vorab zu erlauben, füge diese Regeln für ein einzelnes Projekt zu `.qwen/settings.json` hinzu oder für alle Projekte zu `~/.qwen/settings.json`: ```json { "permissions": { "allow": ["mcp__lagune__lagune_read", "mcp__lagune__lagune_write"] } } ``` Läuft die Engine über **npx**, wie bei **skills.sh**, erlaube `Shell(npx --yes lagune@*)`. ## Häufige Fragen ### Wie installiere ich Lagune in Qwen Code? Führe qwen extensions install lagune aus. ### Wie aktualisiere ich Lagune in Qwen Code? Führe qwen extensions update lagune aus oder installiere die Erweiterung mit --auto-update. ### Wie führe ich die Befehle von Lagune in Qwen Code aus? Gib sie mit vorangestelltem Namen der Erweiterung ein, etwa /lagune:lagune-charter. ### Kann Qwen Code Lagune ohne Rückfrage ausführen? Ja. Erlaube mcp__lagune__lagune_read und mcp__lagune__lagune_write in den Einstellungen von Qwen Code, dazu Shell(npx --yes lagune@*), wenn die Engine über npx läuft. --- # Lagune mit skills.sh in jedem Agenten installieren > Installiere und aktualisiere Lagune in jedem KI-Agenten mit der CLI von skills. Kanonische URL: https://lagune.ai/de-DE/docs/install/universal Sprache: de-DE Original: https://lagune.ai/docs/install/universal Zuletzt aktualisiert: 2026-11-03 **Terminal** Installiere die Befehle von **Lagune** über dein Terminal mit [**skills.sh**](https://www.skills.sh/wellwelwel/lagune): ```bash npx skills add wellwelwel/lagune ``` **Prompt** Füge diesen Prompt in deinen Agenten ein: ```md Führe `npx --yes skills add wellwelwel/lagune` aus und folge jetzt den generierten Skill-Anweisungen. Lies die vollständige Ausgabe, die du bei Bedarf zuerst in eine temporäre Datei umleitest. Löse relative Pfade ausgehend vom Verzeichnis der Begleitdateien auf, das die Ausgabe nennt. ``` ## Aktualisierung **Terminal** Um **Lagune** zu aktualisieren, führe Folgendes aus: ```bash npx skills update ``` **Prompt** Um **Lagune** zu aktualisieren, füge diesen Prompt in deinen Agenten ein: ```md Führe `npx --yes skills update -y` aus und lies die vollständige Ausgabe, die du bei Bedarf zuerst in eine temporäre Datei umleitest. ``` --- **Ein Installationsweg pro Agent** Installiere **Lagune** entweder über **skills.sh** oder über das **Plugin**, nie über beides. **Berechtigungen** Die Befehle starten die Engine als `npx --yes lagune@0.16.0`, und die [Installationsseite jedes Agenten](https://lagune.ai/de-DE/docs) zeigt die Regel, die das vorab erlaubt. Hat deine Sandbox keinen Netzwerkzugriff, installiere die Engine über dein eigenes Terminal in deinem Projekt, einmal und nach jeder Aktualisierung erneut: ```bash npm i -D lagune@0.16.0 ``` ## Häufige Fragen ### Wie installiere ich Lagune in einem beliebigen KI-Agenten? Führe npx skills add wellwelwel/lagune in deinem Projekt aus oder füge den Prompt zur Installation in deinen Agenten ein. ### Wie aktualisiere ich Lagune nach der Installation mit der CLI von skills? Führe npx skills update aus oder füge den Prompt zur Aktualisierung in deinen Agenten ein. ### Kann ich Lagune gleichzeitig mit der CLI von skills und als Plugin installieren? Nein. Mit beiden Wegen listet der Agent jeden Befehl doppelt auf oder nutzt eine Kopie und blendet die andere aus. --- # Sicherheits-Skills für KI-Agenten > Die Skills, die dein KI-Agent mit Lagune freischaltet: ein bestehendes Projekt auditieren oder neue Arbeit schon beim Entwickeln absichern, stets nach deinen Sicherheitsprinzipien. Kanonische URL: https://lagune.ai/de-DE/docs/get-started/commands Sprache: de-DE Original: https://lagune.ai/docs/get-started/commands Zuletzt aktualisiert: 2026-11-03 Sobald **Lagune** [installiert](https://lagune.ai/de-DE/docs) ist, schaltet dein **KI**-Agent eine Reihe von Skills frei. Es gibt zwei Wege, sie zu nutzen, und beide folgen deinen **Sicherheitsprinzipien**: neue Arbeit schon beim Entwickeln absichern oder das vollständige Audit über ein Projekt laufen lassen. **⌨️ Bauen / Entwickeln** Du musst deine Arbeit nicht erst fertigstellen, bevor du sie absicherst. Nutze [**`/lagune`**](https://lagune.ai/de-DE/docs/commands/lagune) für die Arbeit, die du **gerade jetzt** schreibst: | Skill | Was er für dich tut | | --------------------------------------------- | ----------------------------------------------------------------------------------------------------- | | [**/lagune-charter**](https://lagune.ai/de-DE/docs/commands/charter) | Legt die Sicherheitsregeln deines Projekts fest, die Grundlage, auf der `/lagune` aufbaut | | [**/lagune**](https://lagune.ai/de-DE/docs/commands/lagune) | Baut, worum du bittest, und härtet es schon beim Schreiben, geleitet von deinen Sicherheitsprinzipien | **Nutze ihn jederzeit** [**`/lagune`**](https://lagune.ai/de-DE/docs/commands/lagune) befolgt die Regeln deiner Sicherheitsprinzipien bei jeder Ausführung. Er nimmt jeden Prompt an, baut, worum du gebeten hast, und härtet es dabei mit sicheren Standardwerten, nicht erst später. --- #### Spezielle Skills | Skill | Was er tut | | --------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | | [**/lagune-specialize**](https://lagune.ai/de-DE/docs/commands/specialize) | Bringt **Lagune** anhand von Artikeln, Exploits oder Themen eine neue Sicherheitsspezialisierung bei | **🔬 Auditieren: Blue-Team-Workflow** Der vollständige **Blue-Team-Workflow**: lesen, was ein Projekt tut, seine Risiken erfassen und schließen. Jede Phase baut auf der vorherigen auf, du musst der Liste also nur von oben nach unten folgen: | # | Skill | Was er für dich tut | | --- | --------------------------------------------- | --------------------------------------------------------------------------------------------------------- | | 1 | [**/lagune-charter**](https://lagune.ai/de-DE/docs/commands/charter) | Legt die Sicherheitsregeln deines Projekts fest, für dich vorgeschlagen oder nach deinen Vorgaben geformt | | 2 | [**/lagune-detect**](https://lagune.ai/de-DE/docs/commands/detect) | Liest deinen Code und erfasst, was dein System tut und wo die Risiken liegen | | 3 | [**/lagune-plan**](https://lagune.ai/de-DE/docs/commands/plan) | Macht aus dem, was detect gefunden hat, einen Abwehrplan mit einer Korrektur für jeden Befund | | 4 | [**/lagune-harden**](https://lagune.ai/de-DE/docs/commands/harden) | Setzt die Korrekturen des Plans in deinem Code um, sicher und eine nach der anderen | | 5 | [**/lagune-verify**](https://lagune.ai/de-DE/docs/commands/verify) | Weist nach, dass jede umgesetzte Korrektur greift, und schließt die ab, die den Nachweis bestehen | --- #### Spezielle Skills | Skill | Was er tut | | --------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | | [**/lagune-specialize**](https://lagune.ai/de-DE/docs/commands/specialize) | Bringt **Lagune** anhand von Artikeln, Exploits oder Themen eine neue Sicherheitsspezialisierung bei | | [**/lagune-prove**](https://lagune.ai/de-DE/docs/commands/prove) | Macht aus jedem erkannten Befund einen ausführbaren, ausschließlich defensiven Nachweis für die Responsible Disclosure | --- #### Interne Skills | Skill | Was er tut | | ------------------------------------------- | --------------------------------------------------- | | [**/lagune-repair**](https://lagune.ai/de-DE/docs/commands/repair) | Repariert die interne Nachverfolgung von **Lagune** | **Tipp** Sicherheit ist kein Kostenfaktor, sondern eine Investition: Was du am Anfang hineinsteckst, sparst du bei den Vorfällen, die du nie erlebst, um ein Vielfaches wieder ein 🙋🏻‍♂️ ## Häufige Fragen ### Welche Skills bringt Lagune mit? /lagune, um Arbeit schon beim Entwickeln zu härten, und den Blue-Team-Workflow für Audits in fünf Phasen: /lagune-charter, /lagune-detect, /lagune-plan, /lagune-harden, /lagune-verify. Dazu kommen /lagune-specialize und /lagune-prove. ### Was ist der Blue-Team-Workflow von Lagune? Ein Audit in fünf Phasen: charter (Regeln festlegen), detect (Risiken erfassen), plan (bewerten und Korrekturen planen), harden (Korrekturen umsetzen), verify (nachweisen, dass sie greifen, und sie abschließen). ### Was ist der Unterschied zwischen /lagune und dem Audit-Workflow? /lagune sichert neue Arbeit schon beim Schreiben ab, ohne einen Workflow, dem du folgen musst. Der Audit-Workflow wendet die fünf Phasen der Reihe nach auf ein bestehendes Projekt an. --- # Dashboard > Sieh dir die Sicherheitsprinzipien, die Befunde und den Katalog deines Projekts in einer lokalen Live-Ansicht an, die sich mit einem einzigen Befehl öffnet. Kanonische URL: https://lagune.ai/de-DE/docs/get-started/dashboard Sprache: de-DE Original: https://lagune.ai/docs/get-started/dashboard Zuletzt aktualisiert: 2026-11-03 Führe **Lagune** direkt und ohne Unterbefehl aus, um `.lagune/` in einer interaktiven Live-Ansicht zu sehen. Der Befehl startet ein Dashboard und öffnet es auf einem zufälligen Port: ```bash npx lagune ``` - [x] **Live-Reload** - [x] **Privat** und **lokal** - [x] Zeigt alles, was `.lagune/` enthält, sobald die ersten Sicherheitsprinzipien stehen - [x] **Verwalte** die Kategorien des Projekts direkt in deinem Browser - [x] Weder `node_modules` noch `package.json` nötig 📦 ![Sicherheitsprinzipien im Dashboard von Lagune](https://lagune.ai/img/dashboard/02.webp) ![Befunde im Dashboard von Lagune](https://lagune.ai/img/dashboard/03.webp) ![Side Quests im Dashboard von Lagune](https://lagune.ai/img/dashboard/04.webp) ![Detailansicht eines Befunds im Dashboard von Lagune](https://lagune.ai/img/dashboard/05.webp) ![Katalog im Dashboard von Lagune](https://lagune.ai/img/dashboard/06.webp) **Tipp** - 🚪 Nutze `--port`, um einen eigenen Port festzulegen. - ⏏️ Drücke `Ctrl+C` zum Beenden. ## Häufige Fragen ### Wie öffne ich das Dashboard von Lagune? Führe npx lagune ohne Unterbefehl im Stammverzeichnis deines Projekts aus. Der Befehl stellt eine Live-Ansicht von .lagune/ auf einem zufälligen Port bereit und öffnet sie in deinem Browser. ### Ist das Dashboard privat? Ja. Es läuft nur auf deinem eigenen Rechner, unter einer lokalen Adresse, die kein anderer Computer erreichen kann. ### Kann ich mein Projekt über das Dashboard ändern? Nur seine Kategorien, und zwar in deinem Browser. Alles andere, was das Dashboard zeigt, ist schreibgeschützt. --- # /lagune: sicherer Code, während deine KI ihn schreibt > Baut, worum du bittest, und härtet es schon beim Schreiben, geleitet von deinen Sicherheitsprinzipien und ohne dass du einem Workflow folgen musst. Kanonische URL: https://lagune.ai/de-DE/docs/commands/lagune Sprache: de-DE Original: https://lagune.ai/docs/commands/lagune Zuletzt aktualisiert: 2026-11-03 ⌨️ Lass die gewünschte Arbeit erledigen und schon beim Schreiben absichern. **`/lagune`** nimmt jeden Prompt in jedem Stadium deines Projekts an, baut, was du wolltest, und härtet es mit sicheren Standardwerten, bevor du es zurückbekommst. ## Verwendung Versieh einen beliebigen Prompt mit **`/lagune`** und beschreibe die Arbeit wie gewohnt. **📘 Anweisungen für Agenten** ```md # Meine Projektanweisungen für Agenten ## Sicherheit - Verwende den Skill `/lagune`, wann immer du Code erstellst oder änderst, damit er standardmäßig für mehr Sicherheit sorgt. ``` - Zum Beispiel: **AGENTS.md**, **CLAUDE.md**, **.github/copilot-instructions.md**, **.cursorrules** usw. **💬 Ein Feature** ```prompt /lagune ermögliche es Nutzern, ein eigenes Foto in ihr Profil hochzuladen. ``` **💬 Eine Korrektur** ```prompt /lagune wenn der Nutzer das Formular absendet, passiert nichts. Finde heraus, woran es liegen könnte, und behebe es. ``` **💬 Ein Refactoring** ```prompt /lagune entkopple und verbessere die Payload-Logik ``` **Optional, aber besser mit Sicherheitsprinzipien** **`/lagune`** funktioniert mit und ohne Sicherheitsprinzipien. Hast du welche, prägen die eigenen Regeln deines Projekts alles, was dabei entsteht. Lege sie einmalig mit [`/lagune-charter`](https://lagune.ai/de-DE/docs/commands/charter) fest. ## So funktioniert es Der Befehl begleitet die Arbeit in drei Schritten, ohne etwas in Lagune abzulegen: 1. Er lädt deine Sicherheitsprinzipien, falls es sie gibt, und lässt sie die gesamte Umsetzung bestimmen. Hast du noch keine, stützt er sich auf eine standardmäßig sichere Basis. 2. Er listet den [Katalog](https://lagune.ai/de-DE/docs/catalog) deines Projekts auf und lädt nur die Spezialisierungen, die deine Arbeit berührt, also dasselbe bei Bedarf geladene Wissen, das auch der Audit-Workflow nutzt. 3. Er setzt die Abwehr schon beim Schreiben des Codes um und liest sein eigenes Ergebnis anschließend noch einmal, um sicherzustellen, dass die Schutzmaßnahmen tatsächlich greifen, bevor du die Arbeit zurückbekommst. Das Ergebnis ist funktionierender Code in deinem Projekt, sicher ab der ersten Zeile. **Jederzeit einsetzbar** Ohne detect, ohne plan, ohne Aufräumen hinterher. **`/lagune`** passt zu einem frischen Projektgerüst genauso wie zu einer Änderung an einer ausgereiften Codebasis und härtet die Arbeit fortlaufend, nicht erst später. ## Was der Befehl nicht tut - Er schreibt nichts in den Ordner `.lagune`, kein Artefakt und keine Nachverfolgung, und erzeugt so nur den gehärteten Code, um den du gebeten hast. - Er schwächt keine Regel ab, um einem Prompt gerecht zu werden: Würde deine Anfrage gegen eines deiner Sicherheitsprinzipien verstoßen, hält er an und sagt es dir zuerst, statt das Gewünschte einfach unsicher zu bauen. ## Häufige Fragen ### Was macht /lagune? Der Befehl nimmt jeden Prompt in jedem Stadium an, baut, worum du gebeten hast, und härtet es mit sicheren Standardwerten, bevor du es zurückbekommst. Die Abwehr setzt er schon beim Schreiben des Codes um, nicht erst später. ### Muss ich Sicherheitsprinzipien festlegen, um /lagune zu nutzen? Nein. Der Befehl funktioniert mit und ohne sie. Mit Sicherheitsprinzipien prägen die eigenen Regeln deines Projekts alles, was er baut. Ohne stützt er sich auf eine standardmäßig sichere Basis. ### Was ist der Unterschied zwischen /lagune und dem Blue-Team-Workflow? /lagune sichert neue Arbeit ab, während du sie schreibst, ohne dass du einem Workflow folgen musst. Der Blue-Team-Workflow durchläuft die fünf Audit-Phasen der Reihe nach an einem bestehenden Projekt. ### Verfolgt /lagune Befunde nach oder schreibt der Befehl Artefakte? Nein. Der Befehl schreibt nichts in den Ordner .lagune, kein Artefakt und keine Nachverfolgung. Er erzeugt nur den gehärteten Code, um den du gebeten hast. ### Wie bringe ich meinen Agenten dazu, /lagune automatisch zu nutzen? Füge der Anweisungsdatei deines Agenten (AGENTS.md, CLAUDE.md, .cursorrules und Ähnliche) eine Anweisung hinzu, die ihn auffordert, den Skill /lagune immer dann zu verwenden, wenn er Code erstellt oder ändert. --- # /lagune-charter: Lege deine Sicherheitsprinzipien fest > Lege die Sicherheitsprinzipien deines Projekts fest, also die Regeln, an die sich jede spätere Phase hält, und trage die Spezialisierungskategorien ein, die die Analyse des Projekts stützt. Kanonische URL: https://lagune.ai/de-DE/docs/commands/charter Sprache: de-DE Original: https://lagune.ai/docs/commands/charter Zuletzt aktualisiert: 2026-11-03 🧬 Erzähl **Lagune**, worum es in deinem Projekt geht, und es macht daraus deine Sicherheitsregeln (ohne Beschreibung leitet es sie allein aus dem Projekt ab). Die charter ist die übergeordnete Ebene: eine Reihe von Prinzipien, bei denen Sicherheit an erster Stelle steht und die jede spätere Phase einhalten muss. Stell sie dir als Prüfung zur Kompilierzeit für das Sicherheitsniveau deines Projekts vor. ## Verwendung **Beschreiben** ```prompt /lagune-charter Mein Projekt ist ein Onlineshop, der Videospiele verkauft. Kunden legen Produkte in einen Warenkorb und bezahlen per Kreditkarte oder Überweisung. Sie können ihre Bestellungen und den Status jeder einzelnen sehen. ``` **Lagune vorschlagen lassen** ```prompt /lagune-charter ``` > _Ich sehe eine Zahlungsbibliothek, eine Anmeldefunktion und ein Bestellmodell, das mit einem Kunden verknüpft ist. Das sieht nach einem Onlineshop aus, der etwas verkauft. Kunden bezahlen und verfolgen ihre eigenen Bestellungen..._ ☁️ ## Was die charter ableitet **Lagune** nimmt deine Beschreibung oder dein **PRD** als Richtung, leitet ab, was daraus für die Sicherheit folgt, und liest dann das Projekt, um über das hinauszugehen, was du genannt hast. Zum Beispiel: - Ein Warenkorb, der Bestellungen enthält, bedeutet, dass es eine **Datenbank** gibt: - z. B. `"Wo liegen die Daten?"`, `"Wer kann darauf zugreifen?"`, `"Gibt es ein Datenleck?"`. - Dass Kunden ihre eigenen Bestellungen sehen können, bedeutet, dass es eine Art **Anmeldung oder Zugriffskontrolle** gibt: - z. B. `"Kann ein Kunde die Bestellungen eines anderen aufrufen?"`, `"Sind die Sitzungen geschützt?"`. - Zahlungen per Karte und Überweisung bedeuten, dass **Geld und sensible Daten im Spiel sind**: - z. B. `"Werden Kartendaten gespeichert?"`, `"Werden Zahlungen überprüft?"`. Deine Beschreibung und das Projekt ergänzen sich: Deine Beschreibung gibt die Absicht vor, und ein Blick in die Abhängigkeiten, die README und die Konfiguration bringt ans Licht, was du nicht erwähnt hast. Ist danach noch etwas Wichtiges unklar, stellt **Lagune** eine kurze, verständliche Frage, statt zu raten. Daraus erstellt **Lagune** maßgeschneiderte Sicherheitsregeln für das Projekt, die du jederzeit prüfen und anpassen kannst. **Das Beste herausholen** - Du kannst auch eigene Sicherheitsregeln für das Projekt festlegen. - Je mehr relevante Details du angibst, desto besser wird der abschließende Bericht: - Erkläre das Projekt, wie es funktioniert und was unter der Haube passiert. - Wer ist der Endnutzer? Was dürfen Nutzer tun und was nicht? - Details zum Verhalten sind genauso wertvoll wie technische Details. - Das Gedächtnis der charter liegt in `.lagune/memory/charter.md`. ## Die eingetragenen Kategorien Spezialisierungen, also das Sicherheitswissen, das die späteren Phasen bei Bedarf laden, landen im [Katalog](https://lagune.ai/de-DE/docs/catalog) deines Projekts, und zwar nach [Kategorie](https://lagune.ai/de-DE/docs/categories). Solange in deinem Projekt keine Kategorie eingetragen ist, trägt die charter jede ein, die ihre Analyse des Projekts stützt, etwa die Sprache deines Projekts, Aufrufe an ein LLM oder Container, und nennt sie in ihrer Zusammenfassung. Sind Kategorien eingetragen, lässt die charter sie unverändert und nennt nur noch Kategorien, die dein Projekt noch nicht nutzt. Ändern kannst du sie jederzeit selbst: ```bash npx lagune write add --categories python npx lagune write remove --categories python ``` ## Nächster Schritt Sind die Regeln festgelegt, erfasse, was dein System tatsächlich tut: [`/lagune-detect`](https://lagune.ai/de-DE/docs/commands/detect). ## Häufige Fragen ### Was ist die charter bei Lagune? Die charter ist die übergeordnete Ebene von Lagune, eine Reihe von Prinzipien, bei denen Sicherheit an erster Stelle steht und die jede spätere Phase einhalten muss. Stell sie dir als Prüfung zur Kompilierzeit für das Sicherheitsniveau deines Projekts vor. ### Wo wird die charter gespeichert? In .lagune/memory/charter.md. ### Kann ich eigene Regeln in die charter schreiben? Ja. Lagune schlägt Regeln auf Basis deiner Beschreibung und deines Codes vor, und du kannst sie umformulieren, streichen, ergänzen oder ihren Geltungsbereich eingrenzen. ### Wählt die charter meine Spezialisierungskategorien aus? Nur solange keine eingetragen ist. Dann trägt sie jede Kategorie ein, die ihre Analyse des Projekts stützt, etwa deine Programmiersprache oder Aufrufe an ein LLM. Sind Kategorien eingetragen, ändert sie sie nie. --- # /lagune-detect: Erfasse dein System und seine Risiken > Erfasse anhand deines Codes, was dein System tut und wo die Risiken liegen. Kanonische URL: https://lagune.ai/de-DE/docs/commands/detect Sprache: de-DE Original: https://lagune.ai/docs/commands/detect Zuletzt aktualisiert: 2026-11-03 🔬 Finde heraus, was dein System wirklich tut und wo die Risiken liegen. Detect liest den Code und hält nur fest, was sich dort tatsächlich findet, zusammen mit den Belegen, die die späteren Phasen brauchen. Ihr oberster Grundsatz lautet: erkennen, nicht erfinden. ## Verwendung **Vollständiger Durchlauf** ```prompt /lagune-detect ``` **Pfade angeben** ```prompt /lagune-detect src/routes/ src/auth.ts ``` **Anliegen beschreiben** ```prompt /lagune-detect stelle sicher, dass Kundendaten nie offengelegt werden ``` ## Was detect erfasst **Lagune** liest den Code und erfasst, was es findet. Jeder Befund nennt, worum es sich handelt, warum es wichtig ist und den Beleg dafür. Zum Beispiel: - **Datei-Uploads**, das System nimmt Dateien von Nutzern entgegen: - _Warum es wichtig ist:_ Eine als Bild getarnte Datei kann Schadcode verbergen. - _Beleg:_ Der Handler für `POST /upload` vertraut dem MIME-Typ, den der Client sendet, ohne den tatsächlichen Typ der Datei zu prüfen. - **Anmeldung und Sitzungen**, Nutzer melden sich an, um auf ihr Konto zuzugreifen: - _Warum es wichtig ist:_ Eine schwache Sitzungsverwaltung ermöglicht es, dass jemand ein fremdes Konto übernimmt. - _Beleg:_ die Logik zur Ausgabe von Sitzungen, die Sitzungen ohne Ablaufzeit ausstellt. Dabei fällt detect für jede Spezialisierung im [Katalog](https://lagune.ai/de-DE/docs/catalog) deines Projekts ein Urteil anhand des Codes, wendet die an, deren Kontext vorhanden ist, und trägt sie unter **Applied specializations** ein, der Liste, die harden und verify wiederverwenden. Danach hast du eine klare Bestandsaufnahme dessen, was dein System tut und wo die Risiken liegen, als Grundlage für die nächsten Schritte. **Tipp** - Ein erneuter Lauf aktualisiert die Bestandsaufnahme: Gelöste Befunde fallen weg, neue kommen hinzu. - Die Bestandsaufnahme von detect liegt in `.lagune/memory/detect.md`. ## Nächster Schritt Mach aus der Bestandsaufnahme einen Plan: [`/lagune-plan`](https://lagune.ai/de-DE/docs/commands/plan). ## Häufige Fragen ### Was macht /lagune-detect? Die Phase liest deinen Code und erfasst, was dein System tut und wo die Risiken liegen, wobei sie nur festhält, was sie tatsächlich findet. Ihr Grundsatz lautet: erkennen, nicht erfinden. ### Was ist ein Befund bei Lagune? Ein Befund ist ein einzelnes erkanntes Risiko und nennt, worum es sich handelt, warum es wichtig ist und den Beleg im Code. Er ist die nachverfolgte Einheit, die plan, harden und verify weitertragen. ### Wo wird die Bestandsaufnahme von detect gespeichert? In .lagune/memory/detect.md. ### Welche Spezialisierungen nutzt detect? Jede im Katalog deines Projekts erhält ein Urteil anhand des Codes. Detect wendet die an, deren Kontext vorhanden ist, und trägt sie unter Applied specializations ein. --- # /lagune-plan: Bewerte Befunde und plane Korrekturen > Mach aus dem, was detect gefunden hat, einen Abwehrplan, der jeden Befund mit einer Kategorie und einem CVSS-v4.0-Score bewertet und ihm eine Korrektur zuordnet. Kanonische URL: https://lagune.ai/de-DE/docs/commands/plan Sprache: de-DE Original: https://lagune.ai/docs/commands/plan Zuletzt aktualisiert: 2026-11-03 🛡️ Mach aus dem, was detect gefunden hat, einen Abwehrplan: Bewerte jeden Befund mit einer Kategorie und einem CVSS-v4.0-Score und ordne ihm dann die Korrektur zu, die umgesetzt werden soll. ## Verwendung **Alles planen** ```prompt /lagune-plan ``` **Pfade angeben** ```prompt /lagune-plan src/routes/upload.ts ``` **Auf eine Sorge konzentrieren** ```prompt /lagune-plan wo sensible Daten abfließen könnten ``` ## So funktioniert es Diese Phase setzt dort an, wo detect aufgehört hat. Detect hat bereits herausgefunden, was dein System tut und welches Risiko jeder Teil birgt. Deshalb wiederholt plan das Risiko nicht, sondern bewertet, wie ernst es ist, und entscheidet, was dagegen zu tun ist. Plan liest den Code nie, wodurch jede Korrektur auf etwas zeigen muss, das detect tatsächlich erkannt hat. Die Phase bewertet jeden Befund nach der Methode von CVSS v4.0: mit einer Kategorie, einem CVSS-v4.0-Vektor, der aus dem abgeleitet ist, was detect und die charter erfasst haben, und dessen Score der [Hook `cvss`](https://lagune.ai/de-DE/docs/hooks/cvss) berechnet, sowie mit der Prioritätsstufe, in die dieser Score fällt. Jede Korrektur nennt außerdem das Sicherheitsprinzip, das sie wahrt. Zum Beispiel: - **Datei-Uploads** (Priorität: **Critical**) - _Kategorie:_ uneingeschränkter Datei-Upload (CWE-434). - _CVSS:_ CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N (9.3, Critical). - _Warum diese Priorität:_ Jeder kann den Upload über das Internet erreichen, und er liegt auf dem Server, der die Dateien der Kunden speichert. - _Wahrt:_ III. Jede Eingabe gilt als nicht vertrauenswürdig, bis sie validiert ist. - _Korrektur:_ den tatsächlichen Typ und die Größe der Datei prüfen, sie beim Speichern umbenennen und Uploads dort ablegen, wo sie nicht als Code ausgeführt werden können. Danach hast du eine bewertete, priorisierte Liste von Korrekturen, jede mit einem Befund verknüpft und bereit für die Umsetzung in der nächsten Phase. Der Score wird berechnet, nie geschätzt: Der Vektor bildet die Exponiertheit des Projekts und das, was auf dem Spiel steht, als Environmental-Metriken ab, und jeder kann ihn in den Rechner von FIRST oder NVD einfügen und denselben Score erneut berechnen. **Tipp** - Die Phase baut vollständig auf detect auf. Wurde eine Datei oder eine Sorge nie erfasst, fordert sie dich auf, zuerst `/lagune-detect` dafür auszuführen. - Ein erneuter Lauf aktualisiert den Plan: Erledigte Korrekturen fallen weg, neue kommen hinzu. - Der Abwehrplan liegt in `.lagune/memory/plan.md`. **Hängt von detect ab** Plan arbeitet nur mit dem, was [`/lagune-detect`](https://lagune.ai/de-DE/docs/commands/detect) bereits erfasst hat, führe detect also zuerst aus. ## Nächster Schritt Setze den Plan um: [`/lagune-harden`](https://lagune.ai/de-DE/docs/commands/harden). ## Häufige Fragen ### Wie priorisiert Lagune Schwachstellen? /lagune-plan bewertet jeden Befund mit einer Kategorie und einem CVSS-v4.0-Score, den der Hook cvss berechnet, und ordnet ihm dann die Korrektur zu, die umgesetzt werden soll. ### Nutzt Lagune CVSS v4.0? Ja. Jeder Befund erhält einen CVSS-v4.0-Vektor und -Score, berechnet vom Hook cvss mit derselben Arithmetik wie der Rechner von FIRST, sodass jeder den Vektor dort einfügen und den Score nachrechnen kann. ### Liest die Phase plan meinen Code? Nein. Plan liest den Code nie, wodurch jede Korrektur auf etwas zeigen muss, das detect tatsächlich erkannt hat. --- # /lagune-harden: Setze Sicherheitskorrekturen in deinem Code um > Setze die Korrekturen aus dem Plan in deinem Code um, sicher und eine nach der anderen. Kanonische URL: https://lagune.ai/de-DE/docs/commands/harden Sprache: de-DE Original: https://lagune.ai/docs/commands/harden Zuletzt aktualisiert: 2026-11-03 🔧 Setze die Korrekturen aus dem Plan in deinem Code um, sicher und eine nach der anderen. ## Verwendung **Alles umsetzen** ```prompt /lagune-harden ``` **Pfade angeben** ```prompt /lagune-harden src/routes/upload.ts ``` **Nach Priorität** ```prompt /lagune-harden Priorität kritisch und hoch ``` ## So funktioniert es Der Plan hat jede Korrektur bereits festgelegt, harden setzt sie also nur noch um. Da harden die einzige Phase ist, die deinen Code anfasst, geht sie behutsam vor: Sie setzt eine Korrektur nach der anderen um, damit jede Änderung leicht zu prüfen bleibt, und schwächt nie eine Schutzmaßnahme ab, nur damit eine Korrektur passt. Zum Beispiel die Korrektur für den Upload: - **Datei-Uploads** (Status: **Applied**) - _Was sich geändert hat:_ prüft den tatsächlichen Typ und die Größe der Datei, lehnt alles Unerwartete ab, benennt sie beim Speichern um und legt sie dort ab, wo sie nicht als Code ausgeführt werden kann. - _Wo:_ die Funktion `handleUpload` sowie die Speicher-Hilfsfunktion, die sie aufruft. Lässt sich eine Korrektur nicht vollständig umsetzen, erledigt harden, was gefahrlos möglich ist, markiert den Rest als **Partial** oder **Blocked** und lässt ihn offen. **Applied heißt nicht verifiziert** Applied bedeutet noch nicht nachgewiesen. Dafür ist [verify](https://lagune.ai/de-DE/docs/commands/verify) da. **Tipp** - Die Phase baut vollständig auf dem Plan auf. Wurde eine Korrektur oder Datei nie geplant, fordert sie dich auf, zuerst `/lagune-plan` dafür auszuführen. - Ein erneuter Lauf gleicht das Protokoll ab: Rückgängig gemachte Änderungen fallen weg, neu umgesetzte Korrekturen kommen hinzu. - Das Härtungsprotokoll liegt in `.lagune/memory/harden.md`. **Hängt von plan ab und ändert deinen Code** Harden baut auf [`/lagune-plan`](https://lagune.ai/de-DE/docs/commands/plan) auf. Es ist die einzige Phase, die deinen Code ändert. ## Nächster Schritt Weise nach, dass jede Korrektur greift: [`/lagune-verify`](https://lagune.ai/de-DE/docs/commands/verify). ## Häufige Fragen ### Ändert /lagune-harden meinen Code? Ja. Harden ist die einzige Phase, die deinen Code anfasst, und setzt die Korrekturen aus dem Plan eine nach der anderen um. ### Was bedeuten Applied, Partial und Blocked? Das ist der Status, den Lagune für jede Korrektur festhält. Applied bedeutet, dass die Korrektur umgesetzt wurde, Partial, dass sie nur zum Teil umgesetzt wurde, und Blocked, dass sie sich nicht umsetzen ließ. Applied bedeutet noch nicht nachgewiesen. ### Setzt Lagune Korrekturen um, ohne zu fragen? Ob eine Änderung deine Zustimmung braucht, entscheiden dein Agent und der Berechtigungsmodus, in dem du ihn ausführst, nicht Lagune: Lagune fügt keine eigene Bestätigungsstufe hinzu. Trotzdem schwächt es nie eine Schutzmaßnahme ab, nur um einer Korrektur gerecht zu werden, und würde eine Korrektur gegen eines deiner Sicherheitsprinzipien verstoßen, hält es an und sagt es dir zuerst. --- # /lagune-verify: Weise nach, dass Schutzmaßnahmen greifen > Weise nach, dass jede umgesetzte Korrektur greift, und schließe die ab, die den Nachweis bestehen. Kanonische URL: https://lagune.ai/de-DE/docs/commands/verify Sprache: de-DE Original: https://lagune.ai/docs/commands/verify Zuletzt aktualisiert: 2026-11-03 ⚖️ Weise nach, dass jede umgesetzte Korrektur greift, indem du den Code liest und ihn dem gegenüberstellst, was harden festgehalten hat, und schließe dann die ab, die den Nachweis bestehen. ## Verwendung **Alles verifizieren** ```prompt /lagune-verify ``` **Pfade angeben** ```prompt /lagune-verify src/routes/upload.ts ``` **Nach Priorität** ```prompt /lagune-verify Priorität kritisch und hoch ``` ## So funktioniert es Verify liest den Code an jeder Stelle, die harden festgehalten hat, und bestätigt, dass er wirklich der Behauptung entspricht. Der Nachweis ist genau diese Gegenüberstellung, Code gegen Protokoll. Jede Schutzmaßnahme erhält eines von drei Urteilen: | Urteil | Bedeutung | | ---------------------------- | ------------------------------------------------------------------------ | | ✅ Risk closed | Der Code tut genau das, was das Protokoll behauptet. | | ❌ Risk not closed | Die Schutzmaßnahme ist noch offen. Verify schickt dich zurück zu harden. | | ❓ Cannot tell from the code | Der Beleg ist allein im Code nicht sichtbar. | Ein nachweislich geschlossenes Risiko trägt verify dann mit deiner Bestätigung aus der Kette aus. Zum Beispiel: - **Datei-Uploads** (Urteil: **✅ Risk closed**) - _Wie nachgewiesen:_ Verify hat den Upload-Handler gelesen und festgestellt, dass er den tatsächlichen Dateityp anhand des Inhalts erkennt, ein Größenlimit durchsetzt und alles andere ablehnt, genau wie das Protokoll behauptet. - _Beleg:_ die Funktion `handleUpload`, die den tatsächlichen Dateityp anhand des Inhalts erkennt. Ist das Risiko nicht geschlossen, sagt verify das klar und schickt dich zurück zu [`/lagune-harden`](https://lagune.ai/de-DE/docs/commands/harden), da die Korrektur noch offen ist. **Tipp** - Verify baut vollständig auf dem Härtungsprotokoll auf. - Verify liest deinen Code nur, um ihn zu beurteilen, und schwächt nie eine Schutzmaßnahme ab oder schreibt den Code um, damit ein Urteil positiv ausfällt. - Ein erneuter Lauf gleicht die Urteile ab: Veraltete fallen weg, und ein Risiko, das nicht mehr geschlossen ist, wird erneut gemeldet. - Ist ein Risiko nachweislich geschlossen, fragt verify einmal nach und entfernt diesen Befund dann aus der gesamten Kette (detect, plan, harden und die Nachverfolgung). - Verify schreibt keinen eigenen Bericht: Jedes Urteil steht im Block seiner Schutzmaßnahme in `.lagune/memory/harden.md`, wo harden es beim nächsten Lauf liest. **Hängt von harden ab** Verify baut auf [`/lagune-harden`](https://lagune.ai/de-DE/docs/commands/harden) auf. ## Der Zyklus schließt sich Ist alles im betrachteten Umfang ausgetragen, ist der Zyklus im Ruhezustand. Er öffnet sich erst wieder, wenn sich der Code ändert. Sicherheit ist abschließbar, also hat der Workflow einen Endzustand statt einer Endlosschleife. ## Häufige Fragen ### Wie verifiziert Lagune eine Korrektur? /lagune-verify liest den Code, stellt ihn dem gegenüber, was harden festgehalten hat, und gibt eines von drei Urteilen zurück: Risk closed, Risk not closed oder Cannot tell from the code. ### Was bedeutet es, einen Befund auszutragen? Weist verify nach, dass ein Risiko geschlossen ist, wird der Befund ausgetragen: Er wird mit deiner Bestätigung aus der gesamten Kette entfernt, damit er nicht immer wieder verarbeitet wird. ### Kann Sicherheitsarbeit jemals abgeschlossen sein? Ja. SDH ist abschließbar: Ein nachweislich geschlossener Befund wird ausgetragen, also hat der Workflow einen Endzustand statt einer Endlosschleife. --- # Kategorien > Die Spezialisierungskategorien, die ein Lagune-Projekt nutzen kann, von OWASP bis zur sprachspezifischen Härtung für JavaScript, Python, Go und Rust, und wie du sie änderst. Kanonische URL: https://lagune.ai/de-DE/docs/categories Sprache: de-DE Original: https://lagune.ai/docs/categories Zuletzt aktualisiert: 2026-11-03 **Lagune** gruppiert seine integrierten [**Spezialisierungen**](https://lagune.ai/de-DE/docs/catalog) in **13 Kategorien**. Die Kategorien, die ein Projekt nutzt, bestimmen, welche integrierten in seinen [**Katalog**](https://lagune.ai/de-DE/docs/catalog) aufgenommen werden, und sie teilen sich in zwei Gruppen: was das System tut und worin es geschrieben ist. Solange keine Kategorie eingetragen ist, nutzt ein Projekt nur `owasp`. [`/lagune-charter`](https://lagune.ai/de-DE/docs/commands/charter) trägt jede Kategorie ein, die die Analyse des Projekts stützt, und du kannst sie jederzeit selbst ändern. ## Was das System tut | Kategorie | Schlüssel | Was sie härtet | | ------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | | OWASP | `owasp` | Die Sicherheitsrisiken für Anwendungen, die OWASP verfolgt: Injection, mangelhafte Zugriffskontrolle und Fehler bei Authentifizierung und Kryptografie | | Infrastruktur | `infra` | Konfiguration von Containern, Workloads und Serverless: Dockerfile, Compose, Pod-Sicherheit, IAM und Trigger für FaaS | | KI / LLM | `ai` | Integrationen von KI und LLMs, gegen Prompt Injection und unsichere Anbindung von Tools, Agenten, Retrieval und MCP | | Lovable | `lovable` | Mit KI generierte Supabase-Apps (Lovable und Ähnliche): Lücken bei RLS, geleakte Schlüssel für `service_role` und unsichere Standardwerte | ## Worin es geschrieben ist | Kategorie | Schlüssel | Was sie härtet | | ---------- | ------------ | ------------------------------------------------------------------------------------------------------------------------------------ | | JavaScript | `javascript` | RCE über `eval` und `child_process`, Path Traversal und Prototype Pollution, über alle Laufzeitumgebungen hinweg | | Python | `python` | RCE durch Deserialisierung mit `pickle` und YAML, String Traversal über `str.format` und Class Pollution | | Rust | `rust` | APIs mit `unsafe`, die nicht sound sind, Missbrauch von `transmute`, Ganzzahlüberläufe und undefiniertes Verhalten an der FFI-Grenze | | C / C++ | `c-cpp` | Formatstring-Fehler, Pufferüberläufe und Out-of-Bounds-Schreibzugriffe, die Codeausführung ermöglichen | | PHP | `php` | Umgehung der Authentifizierung durch Type Juggling, Gadget-Ketten für Object Injection und unsichere Standardkonfigurationen | | Go | `go` | Typed-nil-Fehler bei Interfaces, Data Races zwischen Goroutines und unsichere Nebenläufigkeit auf sicherheitskritischen Pfaden | | Java | `java` | Gadget-Ketten bei der Deserialisierung mit `ObjectInputStream`, die in Remote Code Execution münden | | Ruby | `ruby` | Gadget-Ketten bei der Deserialisierung mit `Marshal.load` und YAML, die bis zur Remote Code Execution reichen | | .NET / C# | `dotnet` | RCE durch Deserialisierung mit `BinaryFormatter` und Umgehungen des Encoders, die zu XSS führen | **Tipp** **Lagune** ist sprachunabhängig: Der gesamte Workflow liest dein Projekt, egal in welcher Sprache es geschrieben ist, und diese Kategorien vertiefen nur die Fallstricke, die für eine bestimmte Sprache typisch sind. ## Jederzeit hinzufügen und entfernen Eine Kategorie ist ein Ausgangspunkt, keine Verpflichtung. Nutze, was jetzt zum Projekt passt, und ändere es jederzeit über den Schlüssel, mit `write add` und `write remove`. `--categories` ohne Wert öffnet in einem Terminal eine interaktive Auswahl (Leertaste zum Umschalten, Enter zum Bestätigen, leer lassen zum Überspringen). Außerhalb eines Terminals gibst du die Kategorien direkt dahinter an. **Hinzufügen** ```bash npx lagune write add --categories # interactive npx lagune write add --categories owasp npx lagune write add --categories owasp rust ``` **Entfernen** ```bash npx lagune write remove --categories # interactive npx lagune write remove --categories owasp npx lagune write remove --categories owasp rust ``` Das erste `write add` oder `write remove` geht von `owasp` aus, sodass das Entfernen aller Kategorien eine leere Liste hinterlässt, nie den Standardwert. Jede Änderung landet in `.lagune/configs.json`, sodass das ganze Team mit derselben Auswahl arbeitet. ## Prüfen, was ein Projekt nutzt `read list --categories` zeigt jede Kategorie und ob das Projekt sie nutzt: ```bash npx lagune read list --categories # Categories # • owasp [used] Harden against the application security risks OWASP tracks # • javascript [available] Harden JavaScript and its runtimes # • php [available] Harden PHP against type-juggling auth bypass # • go [available] Harden Go against typed-nil interface bugs # ... # # No category is recorded yet, so this project uses the default: owasp. ``` Im [**Katalog**](https://lagune.ai/de-DE/docs/catalog) siehst du, welche Spezialisierungen jede Kategorie enthält. Deine eigenen Spezialisierungen, geschrieben mit [`/lagune-specialize`](https://lagune.ai/de-DE/docs/commands/specialize), kommen unabhängig von den Kategorien in den Katalog. ## Häufige Fragen ### Wie füge ich eine Kategorie hinzu? Übergib den Schlüssel der Kategorie an --categories, zum Beispiel npx lagune write add --categories javascript. Solange keine eingetragen ist, trägt auch die charter die Kategorien ein, die ihre Analyse des Projekts stützt. ### Kann ich mehr als eine Kategorie nutzen? Ja. Liste sie in derselben Zeile auf, eine nach der anderen. ### Welche Kategorie sollte ein Projekt nutzen? Beginne mit owasp, dem Standard, und füge dann die für deine Sprache oder deinen Stack hinzu. Spezialisierungen werden nur bei Bedarf geladen, eine Kategorie kostet also nichts, bis eine Phase eine ihrer Spezialisierungen braucht. --- # Katalog: Sicherheitsspezialisierungen bei Bedarf > Wie die Spezialisierungen im Katalog deines Projekts geladen werden: von einer Phase bei Bedarf und von dir direkt. Kanonische URL: https://lagune.ai/de-DE/docs/catalog Sprache: de-DE Original: https://lagune.ai/docs/catalog Zuletzt aktualisiert: 2026-11-03 🧠 Die Spezialisierungen von **Lagune** sind fokussierte, sprachunabhängige Module mit Sicherheitswissen, die nur bei Bedarf geladen werden, nie standardmäßig. Sie sind keine Befehle. Der Katalog deines Projekts ist die Auswahl, die es nutzt: die integrierten Spezialisierungen seiner [Kategorien](https://lagune.ai/de-DE/docs/categories) plus seine eigenen. Die Phasen detect und verify ziehen sie während ihres Laufs heran, und du kannst jederzeit direkt eine laden. **Überblick** *Die interaktive Übersicht des Katalogs findest du auf der Webseite. Alle integrierten Spezialisierungen stehen in der Tabelle unten.* **So funktioniert es** ## Selbst nutzen Um eine Spezialisierung direkt zu nutzen, bitte deinen Agenten, sie mit `read catalog ` zu laden, und schreibe die Aufgabe in denselben Prompt. Das Wissen wirkt dann auf das, worum du gebeten hast. Das funktioniert in jedem Prompt, auch in einem, der nichts mit dem Workflow von **Lagune** zu tun hat. Zum Beispiel ein direkter, frei formulierter Prompt, der eine sichere Sammlung von **RegExp** in **Python** erzeugt: ```prompt Lade die Spezialisierung regex mit `npx lagune read catalog regex` und erstelle dann in @src/utils/regex.py eine Sammlung regulärer Ausdrücke, um E-Mail-Adressen und Benutzernamen zu validieren. ``` Das nutzt einen deterministischen Hook, um jede **RegExp** auf **ReDoS** zu testen, behält die sicheren und erzeugt etwa Folgendes: ```python import re EMAIL = re.compile(r"^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$") USERNAME = re.compile(r"^[a-zA-Z0-9_]{3,20}$") def is_email(value: str) -> bool: return EMAIL.match(value) is not None def is_username(value: str) -> bool: return USERNAME.match(value) is not None ``` **ReDoS-Checker ausprobieren** Teste selbst ein Muster unter [**devina.io/redos-checker**](https://devina.io/redos-checker). ## Die integrierten Spezialisierungen Die integrierten Spezialisierungen sind in [**Kategorien**](https://lagune.ai/de-DE/docs/categories) gruppiert. Das ist die Auswahl, die mit **Lagune** ausgeliefert wird: | Spezialisierung | Kategorie | Schwerpunkt | | --------------------- | --------------------------- | ---------------------------------------------------------------------------------------------------------- | | `regex` | `owasp` | **ReDoS:** Muster, deren Laufzeit bei manipulierten Eingaben explodiert. | | `network` | `owasp` | **SSRF & Weiterleitungen:** vom Nutzer vorgegebene Abruf- oder Weiterleitungsziele. | | `interpreter` | `owasp`, `lovable` | **Code-Injection:** `eval`, dynamisches Einbinden, Dispatch über Namen. | | `sql` | `owasp` | **Relationale Datenbanken:** Injection, rohe ORM-Aufrufe, Berechtigungen, Reichweite der Datenbank-Engine. | | `path` | `owasp` | **Dateisystempfade:** Traversal, Null-Byte, NTFS-Streams, Planting. | | `upload` | `owasp` | **Datei-Uploads:** Typ/Signatur, schädliche Inhalte, Speicherung, Limits. | | `access-control` | `owasp`, `lovable` | **Authentifizierung, Autorisierung, Sitzung:** IDOR, Mass Assignment, Mandanten, Sitzungen. | | `credential-endpoint` | `owasp`, `lovable` | **Erraten von Zugangsdaten & Bots:** Brute Force, Password Spraying, Credential Stuffing, Drosselung. | | `federation` | `owasp` | **Vertrauen in Tokens:** OAuth/OIDC, SAML, JWT-Validierung, Anmeldung per QR-Code. | | `http-request` | `owasp` | **Herkunft von Anfragen:** CSRF, CORS-Fehlkonfiguration, gefälschte Client-IP. | | `transport` | `owasp` | **Kanalsicherheit:** TLS-Konfiguration, HTTPS/Klartext, HSTS, Pinning. | | `crypto` | `owasp`, `lovable` | **Kryptografie für ruhende Daten:** schwache oder selbst gebaute Algorithmen, CSPRNG, Schlüsselverwaltung. | | `secrets` | `owasp`, `lovable` | **Fest im Code hinterlegte Zugangsdaten:** Schlüssel, Tokens, Passwörter als Literale im Quellcode. | | `api-endpoint` | `owasp` | **Schnittstellen jenseits von REST:** GraphQL, gRPC, WebSocket-Autorisierung, DoS, Schema. | | `payment` | `owasp`, `lovable` | **Checkout-Ablauf:** Gateway serverseitig prüfen, signierte Callbacks, Idempotenz. | | `xml` | `owasp` | **XML-Parsing:** XXE, externe Entitäten, Billion-Laughs-Expansion. | | `csv` | `owasp` | **Formel-Injection:** Tabellenzellen, die mit `=`/`+`/`-`/`@` beginnen. | | `container` | `owasp`, `infra` | **Container-Konfiguration:** Root, Capabilities, Socket-Mount, Härtung des Images. | | `infra` | `infra` | **Infrastructure as Code:** Terraform, Dockerfile, GitHub Actions. | | `serverless` | `owasp`, `infra`, `lovable` | **FaaS-Funktionen:** IAM nach dem Prinzip der minimalen Rechte, Event-Eingaben, Kontext, Secrets. | | `llm` | `ai`, `lovable` | **KI- und LLM-Risiken:** Prompt Injection, Agency, RAG, MCP, Ausgabe. | | `supabase` | `lovable` | **Backend mit Supabase:** RLS standardmäßig aus, von KI fehlerhaft generierte Policies, Schlüsselmodell. | | `browser` | `javascript`, `lovable` | **Clientseitige Risiken:** XSS, CSP, Framing, Speicherung usw. | | `javascript` | `javascript` | **Risiken auf Sprachebene:** RCE, Prototype Pollution usw. | | `python` | `python` | **Risiken auf Sprachebene:** RCE über `pickle`, Class Pollution, `-O` usw. | | `rust` | `rust` | **Soundness von `unsafe`:** UB, ausgelöst von sicherem Code, `transmute`, Überläufe. | | `java` | `java` | **Deserialisierung & Mobile Code:** Ketten über `readObject`, Übernahme von Objekten. | | `ruby` | `ruby` | **Deserialisierung & `open`:** Wiederherstellung von Objekten über `Marshal`/YAML, Pipe-Eigenheit. | | `php` | `php` | **Type Juggling & `unserialize`:** Magic Hashes, POP-Ketten. | | `go` | `go` | **Typed nil & Data Races:** `nil != nil`, Goroutines mit gemeinsamem Speicher. | | `c-cpp` | `c-cpp` | **Formatstrings:** `printf(user_input)`, Write-what-where über `%n`. | | `dotnet` | `dotnet` | **Risiken auf Plattformebene:** RCE über `BinaryFormatter`, `@Html.Raw`, Lücken bei Enums. | Das meiste integrierte Wissen ist aus OWASP verdichtet. Unter [**OWASP-Quellen**](https://lagune.ai/de-DE/docs/references/owasp-sources) findest du die vollständige Zuordnung jeder Spezialisierung zu ihren maßgeblichen Seiten zu Angriffen und Cheat Sheets von OWASP. Einige wenige stackspezifische Module stützen sich stattdessen auf die Empfehlungen des jeweiligen Anbieters: `supabase` etwa stammt aus der Dokumentation von Supabase und CVE-2025-48757. ## Deine eigenen Spezialisierungen Die integrierten wachsen um je eine Wissensdatei plus eine Indexzeile, nie um einen neuen Befehl. Deine eigenen fügst du genauso hinzu, mit [`/lagune-specialize`](https://lagune.ai/de-DE/docs/commands/specialize): Gib dem Befehl einen Artikel oder ein Thema, und er verdichtet daraus eine neue Spezialisierung in deinem Projekt, die Datei unter `.lagune/catalog/` und ihren Eintrag in `.lagune/configs.json`. Deine eigenen sind immer im Katalog, unabhängig von seinen Kategorien, und eine eigene überdeckt eine integrierte mit demselben Namen. **Intern lädt Lagune Spezialisierungen automatisch, bei Bedarf** Stößt die Phase detect oder verify auf einen Kontext, den eine Spezialisierung abdeckt, lädt sie diese Spezialisierung selbst mit `read catalog `. Das geschieht automatisch als Teil der Phase. Damit das funktioniert, musst du nichts von Hand tun. ## Herausfinden, was verfügbar ist So listest du den Katalog deines Projekts im Terminal auf, eine Spezialisierung pro Zeile mit ihren Tags: ```bash npx lagune read catalog # regex: Regular Expression [required] # network: Requests, Webhook, URL Fetch, Socket, IMDS, Redirect # interpreter: Evaluator, Sink, Shell, Dynamic Execution # ... ``` Eine Spezialisierung mit `[required]` gilt immer, unabhängig von der Arbeit. Welche integrierten die Liste enthält, hängt von den [**Kategorien**](https://lagune.ai/de-DE/docs/categories) deines Projekts ab. **Spezialisierungen werden nicht standardmäßig geladen** Das relevante Wissen wird für das herangezogen, was das Projekt tatsächlich ist, statt jede Prüfung standardmäßig auszuführen. ## Häufige Fragen ### Was ist eine Spezialisierung bei Lagune? Ein fokussiertes, sprachunabhängiges Modul mit Sicherheitswissen, das nur bei Bedarf geladen wird, nie standardmäßig. Es ist kein Befehl wie die Skills des Agenten. ### Was ist der Katalog eines Projekts? Die Spezialisierungen, die das Projekt nutzt: die integrierten seiner Kategorien plus seine eigenen. Solange keine Kategorie eingetragen ist, nutzt es nur OWASP. ### Werden Spezialisierungen standardmäßig geladen? Nein. Sie werden nur bei Bedarf geladen, passend zu dem, was das Projekt tatsächlich ist. ### Wie lade ich eine Spezialisierung direkt? Bitte deinen Agenten im selben Prompt wie die Aufgabe, npx lagune read catalog auszuführen. --- # /lagune-specialize: Trainiere eine Sicherheitsspezialisierung mit einfachem Text > Verdichte eine Quelle oder ein Thema zur Sicherheit, das du vorgibst, zu einer neuen Spezialisierung, die bei Bedarf geladen wird. Kanonische URL: https://lagune.ai/de-DE/docs/commands/specialize Sprache: de-DE Original: https://lagune.ai/docs/commands/specialize Zuletzt aktualisiert: 2026-11-03 🎓 Bring **Lagune** eine neue Spezialisierung bei, aus einer Quelle oder einem Thema, das du vorgibst. Der Befehl liest das Material und verdichtet es zu einer fokussierten, ausschließlich defensiven Spezialisierung, die genauso aufgebaut ist wie die [integrierten](https://lagune.ai/de-DE/docs/catalog), sodass die Phasen detect und verify sie danach wie jede andere laden. Er auditiert und erklärt nur: Er schreibt nie Angriffseingaben oder Exploits und rührt deinen Code nie an. **Aus einem Artikel** ```prompt # Ein Link oder eine Quellenangabe: Lagune verdichtet sie zur Abwehr /lagune-specialize https://owasp.org/www-community/attacks/SQL_Injection ``` **Aus einem Exploit** ```prompt # Ein Angriff als Quelle: Die Spezialisierung bleibt trotzdem die Abwehr /lagune-specialize "' OR 1=1 -- schleust SQL in den Abfragetext ein" ``` **Aus einem Thema** ```prompt # Oder nenne einfach, was abgedeckt werden soll /lagune-specialize SQL-Injection ``` **Ein Angriff kann die Quelle sein, nie das Ergebnis** Den Befehl auf einen Angriff anzusetzen, ist in Ordnung, wenn das Ziel ist, sich dagegen zu verteidigen: Die Beschreibung eines Exploits ist Studienmaterial, das er zur Abwehr verdichtet. Die Spezialisierung, die er erzeugt, auditiert und erklärt immer und liefert nie einen funktionierenden Exploit, eine Payload oder eine Umgehung. ## Was der Befehl schreibt Das Ergebnis sind zwei Dateien in deinem Projekt, die zusammen mit deinem Code committet werden und sich prüfen lassen: - Die Spezialisierung unter `.lagune/catalog/.md`, aufgebaut wie die [integrierten](https://lagune.ai/de-DE/docs/catalog). - Ihr Eintrag in `.lagune/configs.json`, wo dein Projekt seine eigenen Spezialisierungen indexiert, damit der Katalog sie mit den integrierten zusammenführt. Danach listet der Befehl den Katalog auf, um zu bestätigen, dass der neue Eintrag vorhanden ist. Deine eigenen Spezialisierungen sind immer im Katalog, unabhängig von seinen Kategorien. Du fügst nie einen Befehl hinzu und rührst das Paket nicht an: Ein neues Spezialgebiet besteht aus einer Wissensdatei und einem Indexeintrag, geschrieben in dein eigenes Projekt. ## Verfeinern, nie überschreiben Spezialisierst du einen Namen, den es schon gibt, ob eine integrierte Spezialisierung wie `regex` oder eine, die du früher selbst angelegt hast, wird die vorhandene Datei **abgeglichen** statt ersetzt. Der Befehl liest, was da ist, arbeitet das neue Wissen ein, behält, was weiterhin gilt, und schreibt um, was sich geändert hat. Nichts wird ungesehen verworfen. Eine eigene Spezialisierung überdeckt eine integrierte mit demselben Namen, sodass du eine integrierte für dein eigenes Projekt schärfen kannst, ohne sie zu verlieren. **Tipp** - Die neue Spezialisierung wird genau wie eine integrierte geladen: Die Phasen detect und verify ziehen sie bei Bedarf heran, oder du lädst sie selbst mit `npx lagune read catalog ` und gibst ihr eine Aufgabe. - Hat das Material eine erkennbare Herkunft (ein Artikel, ein Autor, ein Link, ein Standard), führt die Spezialisierung sie als Quelle an. Ein bloßes Thema hat keine Quelle. **Hinweis** **Der Befehl läuft nur, wenn du ihn aufrufst:** Der Agent startet ihn nie von sich aus. ## Häufige Fragen ### Wie füge ich eine eigene Sicherheitsspezialisierung hinzu? Führe /lagune-specialize mit einer Quelle oder einem Thema aus. Der Befehl verdichtet sie zu einer ausschließlich defensiven Spezialisierung, die er nach .lagune/catalog/.md schreibt, samt ihrem Eintrag in .lagune/configs.json. ### Kann Lagune aus einer Exploit-Beschreibung lernen? Ja, als Quelle, nie als Ergebnis. Ein Angriff kann die Quelle sein, nie das Produkt. Specialize schreibt nie Angriffseingaben oder Exploits. ### Überschreibt specialize die integrierten Spezialisierungen? Nein. Der Befehl verfeinert, statt zu überschreiben. --- # /lagune-prove: ausschließlich defensiver Proof of Concept > Mach aus jedem erkannten Befund einen ausführbaren, ausschließlich defensiven Proof of Concept (PoC) samt Sicherheitshinweis für Responsible Disclosure. Kanonische URL: https://lagune.ai/de-DE/docs/commands/prove Sprache: de-DE Original: https://lagune.ai/docs/commands/prove Zuletzt aktualisiert: 2026-11-03 🧪 Mach aus jedem erkannten Befund ausführbare, ausschließlich defensive Belege für Responsible Disclosure. Für jeden Befund in der Bestandsaufnahme von detect schreibt der Befehl einen in sich geschlossenen Sicherheitshinweis und einen Test, der den **sicheren Pfad** prüft. So schlägt der Test fehl, solange das Problem besteht, und läuft durch, sobald der Code korrigiert ist. **Tipp** Die Tests von **Lagune** liegen isoliert unter `.lagune/`, getrennt von deiner eigenen Testsuite. ## Verwendung **Alle Befunde** ```prompt /lagune-prove ``` **Ein Befund nach Name** Sieh dir die bereits nachverfolgten Befunde mit ihrem Namen an: ```prompt npx lagune read list --findings # Findings # ... # • SQL-Injection bei der Benutzersuche # ... ``` ```prompt # Weise dann einen davon nach /lagune-prove SQL-Injection bei der Benutzersuche ``` ## So funktioniert es Der Befehl liest den Quellcode, auf den jeder Befund zeigt, und legt unter `.lagune/proofs/` pro nachgewiesenem Befund einen Ordner mit genau zwei Dateien an: | Datei | Was sie ist | | ------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `report.test.mjs` (oder `.cjs`) | Der Test. Nutzt dein Projekt bereits Poku, läuft er damit, sonst mit dem nativen Test-Runner von Node.js, sodass nichts installiert werden muss. | | `report.md` | Ein in sich geschlossener Sicherheitshinweis: Schweregrad, Auswirkung, wie sich das Problem reproduzieren lässt und der Befehl zum Ausführen, auch ohne weiteren Kontext verständlich. | Die Nachweise sind immer in JavaScript geschrieben und bleiben so portabel, egal in welcher Sprache dein Projekt geschrieben ist. Eine `README.md` dient als Index, verlinkt jeden Nachweis und nennt einen einzigen Befehl, um alle auszuführen. **Tipp** - Prove ist **optional und eigenständig**: keine der fünf Phasen und nicht Teil der Kette der Nachverfolgung. - Prove schreibt nur in `.lagune/proofs/` und rührt weder die Artefakte der Phasen noch deinen Code an, den der Befehl nur liest. - Ein Befund, dessen Test das Problem nicht reproduziert, erhält keinen Nachweis, und der Befehl fordert dich auf, [`/lagune-detect`](https://lagune.ai/de-DE/docs/commands/detect) für diese Stelle auszuführen, um abzugleichen. - Ein erneuter Lauf gleicht die Nachweise ab: Ist ein Befund verschwunden oder lässt er sich nicht mehr reproduzieren, wird sein Ordner entfernt. **Hinweis** **Der Befehl läuft nur, wenn du ihn aufrufst:** Der Agent startet ihn nie von sich aus. **Baut auf detect auf** Prove liest die Bestandsaufnahme von [`/lagune-detect`](https://lagune.ai/de-DE/docs/commands/detect), führe detect also zuerst aus. ## Ausschließlich defensiv und autorisiert Bevor der Befehl etwas erzeugt, vergewissert er sich, dass du berechtigt bist, das Ziel zu testen, und lehnt jede Anfrage nach einem funktionierenden Exploit, einer Angriffs-Payload oder einer Umgehung der Erkennung ab. Ein Nachweis zeigt das sichere Verhalten und gibt nie eine Angriffseingabe aus. ## Vom Nachweis zur Offenlegung Die beiden Dateien eines nachgewiesenen Befunds gehören zusammen in einen **privaten GitHub Gist**, um die Schwachstelle zu melden. Sie belegen ein bestehendes, noch nicht offengelegtes Problem, deshalb hält eine `.gitignore` in `.lagune/proofs/` sie aus jedem Commit heraus: Teile sie nur über diesen Gist, bis die Maintainer das Problem behoben haben. Einen Befund in der Kette von **Lagune** abzuschließen, bleibt Aufgabe von [`/lagune-harden`](https://lagune.ai/de-DE/docs/commands/harden) und [`/lagune-verify`](https://lagune.ai/de-DE/docs/commands/verify): Prove liefert Belege, schließt aber nichts ab. ## Häufige Fragen ### Erzeugt Lagune Exploits? Nein. /lagune-prove schreibt ausschließlich defensive Belege: einen Test, der den sicheren Pfad prüft, sodass er fehlschlägt, solange das Problem besteht, und durchläuft, sobald der Code korrigiert ist, dazu einen Sicherheitshinweis für Responsible Disclosure. ### Was gibt prove aus? Zwei Dateien pro Befund: einen Test (report.test.mjs oder .cjs) und einen Sicherheitshinweis (report.md). ### Wie lege ich eine von Lagune gefundene Schwachstelle verantwortungsvoll offen? Prove schreibt einen in sich geschlossenen Sicherheitshinweis, den du nach den Regeln der Responsible Disclosure über einen privaten Kanal teilen kannst, etwa einen privaten GitHub Gist. --- # Hook agent: unbegrenzte Agentenschleifen erkennen > Durchsuche eine Codebasis nach Agenten- und LLM-Aufrufen ohne Schritt- oder Zeitlimit, oder bewerte einen einzelnen Aufruf, direkt über die Kommandozeile. Kanonische URL: https://lagune.ai/de-DE/docs/hooks/agent Sprache: de-DE Original: https://lagune.ai/docs/hooks/agent Zuletzt aktualisiert: 2026-11-03 Der Hook `agent` meldet **Agent-Runtimes, die ohne Runden-, Budget- oder Zeitlimit in einer Schleife laufen**, die Lücke einer entfesselten Autonomie, durch die eine manipulierte Eingabe unbegrenzte Kosten oder eine Eskalation per Prompt Injection auslöst. Er arbeitet **sprachspezifisch** und deckt die zwei Ökosysteme der Agent-Frameworks ab: **JavaScript** (die Runtime `query` des Agent-SDK von **Claude**) und **Python** (**LangChain**, **LangGraph**, **CrewAI**, **OpenAI Agents**). Er ist die deterministische Engine hinter der [Spezialisierung `llm`](https://lagune.ai/de-DE/docs/catalog), und du kannst ihn selbst im Modus **scan** oder **check** ausführen. ## Ausführen **Codebasis durchsuchen** ```bash npx lagune read agent # scans the whole project npx lagune read agent --dir src/ai # scans a directory npx lagune read agent --file chat.ts # scans a single file ``` **Aufruf prüfen** ```bash npx lagune read agent --lang javascript --pattern 'query({ prompt })' # => uncapped npx lagune read agent --lang javascript --pattern 'query({ prompt, options: { maxTurns: 5 } })' # => safe npx lagune read agent --lang python --pattern 'AgentExecutor(agent=a, max_iterations=None)' # => uncapped ``` Jede Zeile unter **Uncapped agent loops found** steht in einer Datei, die ein Agent-SDK importiert, und ist entweder ein Aufruf der Runtime `query` des Agent-SDK von Claude ohne Runden-, Budget- oder Zeitlimit (JavaScript, standardmäßig unbegrenzt) oder die ausdrückliche Aufhebung des Standardlimits eines Frameworks, etwa `max_iterations=None` / `max_turns=None` (Python, standardmäßig begrenzt). In beiden Fällen endet der Hook mit einem Exit-Code ungleich null. Im Vercel AI SDK arbeiten `generateText`/`streamText` standardmäßig mit einem einzigen Schritt (`stopWhen: stepCountIs(1)`), daher kann ein bloßer Aufruf dort keine Schleife bilden und wird nicht gemeldet, und ein gewöhnliches `db.query(...)` hält er nie für einen Agent-Aufruf. Findet er nichts, gibt er `no uncapped agent loops found` aus. ## So liest du das Urteil | Urteil | Bedeutung | | ---------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | | `uncapped` | Ein Aufruf der Runtime `query` ohne Limit (JS) oder die ausdrückliche Aufhebung eines Limits (`=None`, Py). | | `safe` | Ein Aufruf von `query`, der ein Limit setzt, eine Generierung mit einem einzigen Schritt oder ein Framework-Aufruf, der standardmäßig begrenzt ist. | | `invalid` | Der Codeausschnitt enthält keinen erkennbaren Agent-Aufruf, den er beurteilen könnte. | ### CLI-Optionen | Option | Wert | Beschreibung | | ----------- | ------------------ | -------------------------------------------------------------------------------------------- | | `--pattern` | ein Codeausschnitt | Prüft einen Aufruf. Wiederhole die Option, um mehrere zu prüfen, ein Urteil pro Zeile. | | `--lang` | eine Sprache | Erforderlich bei `--pattern`: `javascript` oder `python`. | | `--dir` | ein Verzeichnis | Beschränkt den Durchlauf auf ein Verzeichnis. Wiederholbar und mit `--file` kombinierbar. | | `--file` | eine Datei | Beschränkt den Durchlauf auf eine einzelne Datei. Wiederholbar und mit `--dir` kombinierbar. | Ohne Option durchsucht er das gesamte Projekt. `--pattern` erfordert `--lang` und lässt sich nicht mit `--dir` oder `--file` kombinieren. **Bestmöglich, aber nicht lückenlos** Eine selbst gebaute Agentenschleife entzieht sich in jeder Sprache einem statischen Durchlauf. Betrachte das Ergebnis als solide Untergrenze, nicht als vollständige Bestandsaufnahme. **Tipp** Der Hook entscheidet nur über das Limit: Der Zuschnitt der Fähigkeiten, die Vermischung von Vertrauensstufen und die Autorisierung bleiben Ermessensfragen, die die [Spezialisierung `llm`](https://lagune.ai/de-DE/docs/catalog) abdeckt. ## Häufige Fragen ### Warum sollte ich die Schleife eines Agenten begrenzen? Einen unbegrenzten Agenten kann man in endlose Rekursion, unbegrenzte Kosten oder eine Eskalation per Prompt Injection treiben. Setzt du maxTurns/maxBudgetUsd/stopWhen/signal, ist er begrenzt, und der Hook agent meldet jeden Aufruf der Runtime query, der keine dieser Grenzen setzt. --- # Hook cors: CORS-Origins auditieren > Durchsuche den Quellcode nach einer umgehbaren Allowlist für CORS-Origins, oder bewerte, ob ein einzelner Origin-Wert zu freizügigen Zugriff erlaubt, direkt über die Kommandozeile. Kanonische URL: https://lagune.ai/de-DE/docs/hooks/cors Sprache: de-DE Original: https://lagune.ai/docs/hooks/cors Zuletzt aktualisiert: 2026-11-03 Der Hook `cors` ist die deterministische Engine hinter der [Spezialisierung `http-request`](https://lagune.ai/de-DE/docs/catalog), und du kannst ihn selbst ausführen. Er arbeitet mit einem einzigen Befehl in zwei Modi: Im Modus **scan** durchsucht er den Quellcode nach einer **umgehbaren Origin-Allowlist** (einer Regex zur Host-Validierung, an der ein Host eines Angreifers vorbeikommt), und im Modus **score** bewertet er den Wert eines einzelnen **CORS-Origins** als `wildcard`, `null` oder `safe`. ## Eine Codebasis durchsuchen Ohne Option durchsucht er das gesamte Projekt. **Gesamtes Projekt** ```bash npx lagune read cors ``` **Ein Verzeichnis** ```bash npx lagune read cors --dir src/server ``` **Eine einzelne Datei** ```bash npx lagune read cors --file internal/auth/origin.go ``` Er listet jede umgehbare Allowlist unter einer gemeinsamen Überschrift auf, nach Datei gruppiert. Ein Host-Validator, dessen `.+`/`.*` im Authority-Teil der URL vor dem Suffix des vertrauenswürdigen Hosts steht (`^https?://.+\.trusted\.com`), lässt einen Angreifer-Host wie `your-site.com.attacker.com` durch. ```text Origin-allowlist patterns with a greedy wildcard (bypassable, review): internal/auth/origin.go ^https?://.+\.trusted\.com ``` Das ist ein Prüfhinweis, kein abgeschlossener Befund: Ob die Regex eine echte Vertrauensentscheidung absichert, lässt sich aus dem Text nicht entscheiden, deshalb ändert ein Durchlauf nie den Exit-Code. Lies jede Fundstelle und vergewissere dich, dass die Allowlist auf vollständige Gleichheit prüft. Findet er nichts, gibt er eine einzige Zeile aus. ```bash npx lagune read cors --dir src/clean # => no bypassable origin allowlist found ``` ## Einen Origin bewerten Übergib jeden Origin mit `--origin`. Der Hook gibt pro Origin ein Wort aus und endet bei jedem `wildcard` oder `null` mit einem Exit-Code ungleich null. **Ein Origin** ```bash npx lagune read cors --origin '*' # => wildcard npx lagune read cors --origin 'null' # => null npx lagune read cors --origin 'https://app.example.com' # => safe ``` **Mehrere Origins** Wiederhole `--origin`, um eine ganze Allowlist mit einem Aufruf zu bewerten, ein Urteil pro Zeile, in derselben Reihenfolge. ```bash npx lagune read cors \ --origin 'https://app.example.com' \ --origin '*' \ --origin 'null' # => safe # => wildcard # => null ``` | Urteil | Bedeutung | | ---------- | ------------------------------------------------------------------------------------------------------------------- | | `safe` | Weder `*` noch `null` noch ein Glob mit `*`. Ein korrekt aufgebauter Origin ist damit nicht garantiert. | | `wildcard` | `*` oder ein Glob für Subdomain, Host oder Port: Jede Website (oder eine große Menge davon) darf die Antwort lesen. | | `null` | Der Origin `null`, den Iframes in einer Sandbox und Weiterleitungen fälschen können. | Nur `safe` bedeutet Zulassen, und `--origin` ist ein Orakel für Werte: Es beurteilt den Wert, nicht den Handler, also prüfe den Handler mit der Spezialisierung `http-request`. ### CLI-Optionen | Option | Wert | Beschreibung | | ---------- | --------------- | -------------------------------------------------------------------------------------------- | | `--origin` | ein Origin | Bewertet einen Origin-Wert. Wiederhole die Option, um mehrere zu bewerten, einen pro Zeile. | | `--dir` | ein Verzeichnis | Beschränkt den Durchlauf auf ein Verzeichnis. Wiederholbar und mit `--file` kombinierbar. | | `--file` | eine Datei | Beschränkt den Durchlauf auf eine einzelne Datei. Wiederholbar und mit `--dir` kombinierbar. | Ohne Option durchsucht er das gesamte Projekt. `--origin` steht für den Modus score und lässt sich nicht mit `--dir` oder `--file` kombinieren. **Was er nicht abdeckt** Der Durchlauf erkennt die Form der **umgehbaren Regex**, und `--origin` bewertet **Werte** von Origins. Zwei Muster im Quellcode bleiben außer Reichweite: das Spiegeln des `Origin` der Anfrage (der Server sendet den eingehenden `Origin` unverändert zurück oder kombiniert ihn mit Zugangsdaten) und eine freizügige Allowlist auf Basis von `endsWith` oder Teilstrings. Erkenne sie im Code und behandle sie so, wie es die [Spezialisierung `http-request`](https://lagune.ai/de-DE/docs/catalog) beschreibt. ## Häufige Fragen ### Warum ist der CORS-Origin null gefährlich? Iframes in einer Sandbox und manche Weiterleitungen senden Origin: null, deshalb gewährt eine Allowlist, die null vertraut, diesen Kontexten Lesezugriff. Der Hook cors meldet das zusammen mit der Wildcard. ### Wie finde ich eine umgehbare Allowlist für CORS-Origins? Führe npx lagune read cors über die Codebasis aus. Er meldet eine Regex zur Host-Validierung, deren gierige Wildcard vor dem vertrauenswürdigen Suffix steht, sodass ein Angreifer-Host wie your-site.com.attacker.com durchrutscht. --- # Hook crypto: schwache Kryptografie erkennen > Durchsuche eine Codebasis nach schwachen kryptografischen Primitiven, oder bewerte einen einzelnen Codeausschnitt, direkt über die Kommandozeile. Kanonische URL: https://lagune.ai/de-DE/docs/hooks/crypto Sprache: de-DE Original: https://lagune.ai/docs/hooks/crypto Zuletzt aktualisiert: 2026-11-03 Der Hook `crypto` meldet **schwache kryptografische Primitive** direkt an der Aufrufstelle: ein veraltetes Verschlüsselungsverfahren, einen unsicheren Modus oder einen gebrochenen Hash. Er arbeitet **sprachspezifisch** und liest jede Datei nach ihren eigenen Regeln, sodass er ein Python-Konstrukt nie in einer Rust-Datei meldet. Er ist die deterministische Engine hinter der [Spezialisierung `crypto`](https://lagune.ai/de-DE/docs/catalog), und du kannst ihn selbst im Modus **scan** oder **check** ausführen. ## Ausführen **Codebasis durchsuchen** ```bash npx lagune read crypto # scans the whole project npx lagune read crypto --dir src # scans a directory npx lagune read crypto --file hash.ts # scans a single file ``` **Codeausschnitt prüfen** ```bash npx lagune read crypto --lang javascript --pattern 'createCipher("aes-256-cbc", k)' # => weak npx lagune read crypto --lang python --pattern 'hashlib.md5(data)' # => review npx lagune read crypto --lang go --pattern 'sha256.Sum256(data)' # => safe ``` Der Durchlauf gibt bis zu zwei Abschnitte aus. **Weak cryptography found** enthält die Befunde (DES/3DES/RC4/Blowfish/RC2, ECB-Modus): Jeder ist ein gebrochenes Verschlüsselungsprimitiv, deshalb endet der Hook mit einem Exit-Code ungleich null. **Cryptography to review manually** enthält Prüfhinweise, die er allein nicht beurteilen kann: einen MD5- oder SHA-1-Hash (für Sicherheitszwecke gebrochen, als einfache Prüfsumme aber legitim, also entscheidet die Absicht), einen nicht kryptografischen Zufallszahlengenerator in einem Sicherheitskontext oder einen Vergleich, der für Timing-Angriffe anfällig ist. Findet er nichts, gibt er `no weak cryptography found` aus. ## So liest du das Urteil | Urteil | Bedeutung | | --------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `weak` | Der Codeausschnitt verwendet ein gebrochenes Verschlüsselungsprimitiv (DES/3DES, RC4, Blowfish, RC2 oder den ECB-Modus). | | `review` | Ein Primitiv, dessen Risiko von der Absicht abhängt: ein MD5- oder SHA-1-Hash oder ein nicht kryptografischer Zufallszahlengenerator in einem Sicherheitskontext. | | `safe` | Der Codeausschnitt verwendet Kryptografie, und es wurde kein schwaches Primitiv gefunden. | | `invalid` | Der Codeausschnitt enthält kein erkennbares kryptografisches Konstrukt, das sich beurteilen ließe. | ### CLI-Optionen | Option | Wert | Beschreibung | | ----------- | ------------------ | ------------------------------------------------------------------------------------------------------------- | | `--pattern` | ein Codeausschnitt | Prüft einen Codeausschnitt. Wiederhole die Option, um mehrere zu prüfen, ein Urteil pro Zeile. | | `--lang` | eine Sprache | Erforderlich bei `--pattern`: eine von javascript, python, go, java, kotlin, php, ruby, rust, csharp, c, cpp. | | `--dir` | ein Verzeichnis | Beschränkt den Durchlauf auf ein Verzeichnis. Wiederholbar und mit `--file` kombinierbar. | | `--file` | eine Datei | Beschränkt den Durchlauf auf eine einzelne Datei. Wiederholbar und mit `--dir` kombinierbar. | Ohne Option durchsucht er das gesamte Projekt. `--pattern` erfordert `--lang` und lässt sich nicht mit `--dir` oder `--file` kombinieren. ### Unterstützte Sprachen Der Durchlauf liest diese Sprachen, erkannt an der Dateiendung, und prüft jede gegen ihre eigenen kryptografischen APIs. | Sprache | Schwache Verschlüsselung (Befund), Hashes und Zufallszahlengeneratoren (Prüfung) | | --------------------------- | ------------------------------------------------------------------------------------------------------------------------- | | **JavaScript / TypeScript** | `createCipher`, `CryptoJS.DES/RC4`, `*-ecb` in Anführungszeichen; MD5/SHA-1 `createHash`/`subtle.digest`; `Math.random()` | | **Python** | pycryptodome `DES/ARC4/Blowfish.new`, `algorithms.TripleDES`, `MODE_ECB`; `hashlib.md5/sha1`; `random.*` | | **Go** | `des.NewCipher`, `rc4.NewCipher`, `blowfish.NewCipher`, `NewECBEncrypter`; `md5/sha1.Sum`; `math/rand` | | **Java / Kotlin** | `Cipher.getInstance("DES"/…/ECB")`; `MessageDigest.getInstance("MD5")`, `HmacMD5`; `java.util.Random` | | **PHP** | `openssl_encrypt("des-…"/"…-ecb")`, `mcrypt_*`; `md5()`/`sha1()`, `hash("md5", …)`; `rand()`/`mt_rand()` | | **Ruby** | `OpenSSL::Cipher.new("des-…")`, `:ECB`; `Digest::MD5/SHA1`; `rand()`/`Random` | | **Rust** | `Rc4::`, `Blowfish::`, `des::`, `ecb::`; `Md5::`, `Sha1::`, `Hmac`; `SmallRng`/`XorShiftRng` | | **C#** | `DES/TripleDES/RC2.Create`, `CipherMode.ECB`; `MD5/SHA1.Create`, `HMACMD5`; `new Random()` | | **C / C++** | OpenSSL `DES_*`/`RC4`/`EVP_des_*`, `EVP_*_ecb`; `MD5()`/`SHA1()`, `EVP_md5`; `rand()`/`random()` | **Bestmöglich, aber nicht lückenlos** Er liest den Quellcode als Text, deshalb kann ihm ein Primitiv entgehen, das erst zur Laufzeit zusammengesetzt wird, hinter einem Alias steckt oder in einer Form geschrieben ist, die er nicht erkennt. Betrachte die Tabelle als soliden Ausgangspunkt, nicht als vollständige Bestandsaufnahme. **Tipp** Der Hook garantiert das Minimum (dass diese Konstrukte vorhanden sind): Schlüsselverwaltung, die Wiederverwendung von IVs und RSA-Padding bleiben Ermessensfragen, die die [Spezialisierung `crypto`](https://lagune.ai/de-DE/docs/catalog) abdeckt. ## Häufige Fragen ### Wie durchsuche ich eine Codebasis nach schwacher Kryptografie? Führe den Hook crypto ohne Option aus. Gebrochene Verschlüsselungsverfahren und der ECB-Modus sind Befunde, die mit einem Exit-Code ungleich null enden. Ein MD5- oder SHA-1-Hash ist ein Prüfhinweis, da er für Sicherheitszwecke gebrochen, als einfache Prüfsumme aber legitim ist. ### Meldet der Hook crypto Math.random()? Nur als Prüfhinweis in einem Sicherheitskontext, nie als automatischen Befund, da Zufall für Jitter oder die Reihenfolge von Elementen in einer Oberfläche legitim ist. --- # Hook cvss: einen CVSS-v4.0-Vektor bewerten > Bewerte einen oder mehrere CVSS-v4.0-Vektoren über die Kommandozeile, mit derselben Berechnung wie der Rechner von FIRST, und lass dir jeden in einfachen Worten erklären. Kanonische URL: https://lagune.ai/de-DE/docs/hooks/cvss Sprache: de-DE Original: https://lagune.ai/docs/hooks/cvss Zuletzt aktualisiert: 2026-11-03 Der Hook `cvss` bewertet einen **CVSS-v4.0-Vektor** und gibt dessen Score und Schweregradstufe aus, also die Bewertung, die [`/lagune-plan`](https://lagune.ai/de-DE/docs/commands/plan) zu jeder Korrektur und [`/lagune-prove`](https://lagune.ai/de-DE/docs/commands/prove) zu jedem Sicherheitshinweis schreibt. Er ist die deterministische Engine hinter diesen Bewertungen, nutzt dieselbe Berechnung wie der [Rechner von FIRST](https://www.first.org/cvss/calculator/4.0), und du kannst ihn selbst ausführen. ## Ausführen Übergib jeden Vektor mit `--vector`. Der Hook gibt pro Vektor eine Zeile aus: Score und Stufe. **Ein Vektor** ```bash npx lagune read cvss --vector 'CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N' # => 9.3, Critical ``` **Mehrere Vektoren** Wiederhole `--vector`, um mehrere auf einmal zu bewerten, eine Zeile pro Vektor, in derselben Reihenfolge. ```bash npx lagune read cvss \ --vector 'CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N' \ --vector 'CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/MAV:A' # => 9.3, Critical # => 8.7, High ``` **In einfachen Worten** Füge `--explain` hinzu, um dir jede Metrik in einfachen Worten erklären zu lassen. Wenn Threat- oder Environmental-Metriken den Score verändern, steht der Base-Score allein an erster Stelle. ```bash npx lagune read cvss --explain --vector 'CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/MAV:A' # => 8.7, High # => Base metrics alone: 9.3, Critical # => Attack Vector: Network, modified to Adjacent # => Attack Complexity: Low # => ... ``` ## So liest du das Ergebnis | Stufe | Score | | ---------- | ------------ | | `None` | 0.0 | | `Low` | 0.1 bis 3.9 | | `Medium` | 4.0 bis 6.9 | | `High` | 7.0 bis 8.9 | | `Critical` | 9.0 bis 10.0 | Ein Vektor nur mit Base-Metriken bewertet die Schwachstelle selbst und geht vom schlimmsten Fall aus: Jede Sicherheitsanforderung steht auf High, und die Schwachstelle wird aktiv ausgenutzt. Environmental-Metriken (`MAV` und die übrigen modifizierten Metriken sowie `CR`, `IR` und `AR`) passen den Score an eine konkrete Einsatzumgebung an, die Threat-Metrik (`E`) an das, was über die Ausnutzung bekannt ist. Bei einem ungültigen Vektor gibt der Hook `invalid vector:` und den Fehler aus und endet mit einem Exit-Code ungleich null. ### CLI-Optionen | Option | Wert | Beschreibung | | ----------- | ------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | | `--vector` | ein Vektor im Format `CVSS:4.0` | Bewertet einen Vektor. Wiederhole die Option, um mehrere zu bewerten, eine Zeile pro Vektor, in derselben Reihenfolge. | | `--explain` | | Ergänzt unter jeder Bewertungszeile jede Metrik in einfachen Worten. | Mindestens ein `--vector` ist Pflicht. Der Vektor ist nie ein bloßes Positionsargument, deshalb kann er nicht mit einer Option verwechselt werden. **Warum als Wert einer Option** Jeder Vektor wird als Wert einer Option übergeben und nie in den Befehl interpoliert. Ein Wert mit Anführungszeichen oder Backticks bleibt wirkungslos und kann nichts in die Shell einschleusen. Setze ihn immer in einfache Anführungszeichen, damit deine Shell ihn nicht vorher expandiert. **Was er nicht abdeckt** Nur CVSS v4.0: Einen Vektor in v2.0, v3.0 oder v3.1 lehnt er ab, statt ihn zu bewerten, denn **Lagune** bewertet jeden Befund in v4.0. **Tipp** Die Validierung der Phase plan wiederholt genau diese Berechnung für jede CVSS-Zeile, sodass ein Score, der nicht mehr zu seinem Vektor passt, auffällt, bevor der Plan angenommen wird. ## Häufige Fragen ### Wie berechnet Lagune einen CVSS-Score? Der Hook cvss folgt dem Referenzrechner von FIRST für CVSS v4.0, deshalb erhält ein Vektor exakt denselben Score wie auf der Website von FIRST. ### Kann ich damit einen CVSS-v3.1-Vektor bewerten? Nein. Lagune bewertet jeden Befund in CVSS v4.0, und der Hook lehnt jede andere Version ab, statt sie zu bewerten. ### Was bewirkt die Option --explain? Sie erklärt jede Metrik in einfachen Worten und zeigt den Base-Score neben dem Gesamtscore, sodass jeder sieht, was der Vektor aussagt und wie der Projektkontext den Score verändert hat. --- # Hook infra: IaC-Fehlkonfigurationen erkennen > Durchsuche Terraform, Dockerfiles und GitHub Actions nach Fehlkonfigurationen, oder bewerte einen einzelnen Codeausschnitt, direkt über die Kommandozeile. Kanonische URL: https://lagune.ai/de-DE/docs/hooks/infra Sprache: de-DE Original: https://lagune.ai/docs/hooks/infra Zuletzt aktualisiert: 2026-11-03 Der Hook `infra` meldet **Fehlkonfigurationen in Infrastructure as Code**, die sich aus der Datei selbst entscheiden lassen: ein Netzwerk, das für die ganze Welt offen ist, eine Berechtigung mit Wildcard, ein Secret in einem Manifest, ein Container, der als root läuft, ein nicht vertrauenswürdiger Wert in einer CI-Shell. Er liest nur IaC-Dateien (`.tf`/`.tf.json`/`.hcl`, `Dockerfile*`, `.github/workflows/**`). Er ist die deterministische Engine hinter der [Spezialisierung `infra`](https://lagune.ai/de-DE/docs/catalog), im Modus **scan** oder **check**. ## Ausführen **Codebasis durchsuchen** ```bash npx lagune read infra # scans every IaC file npx lagune read infra --dir infra # scans a directory npx lagune read infra --file Dockerfile # scans a single file ``` **Codeausschnitt prüfen** Übergib den Codeausschnitt mit `--pattern` und seine Art mit `--kind` (`terraform`, `dockerfile` oder `github-actions`). ```bash npx lagune read infra --kind terraform --pattern 'actions = ["*"]' # => iam-wildcard npx lagune read infra --kind dockerfile --pattern 'FROM node:20' # => mutable-tag ``` Der Durchlauf gibt bis zu zwei Abschnitte aus. **Infrastructure risks found** führt zu einem Exit-Code ungleich null und enthält die entscheidbaren Mängel (eine Ingress-Regel für `0.0.0.0/0` auf einem sensiblen Port, eine IAM-Anweisung mit Wildcard, ein Secret im Manifest, `encrypted = false`, ein Git-Modul ohne fixierte Version, ein Image, das ausdrücklich als root läuft, ein `curl | sh`, eine Script Injection in der CI, `permissions: write-all`). **Infrastructure hardening advisories** ändert den Exit-Code nicht (ein veränderliches Basis-Tag, eine Action, die nur über ein Tag fixiert ist). Findet er nichts, gibt er `no infrastructure risks found` aus. ## So liest du das Urteil Der Modus check gibt das Tag mit dem höchsten Schweregrad aus, das er gefunden hat (zum Beispiel `public-ingress`, `iam-wildcard`, `root-user`, `curl-pipe`, `script-injection`, `write-all`), ein Hinweis-Tag (`mutable-tag`, `unpinned-action`) oder `safe`. Nur ein Tag mit dem Schweregrad eines Befunds führt zu einem Exit-Code ungleich null. ### CLI-Optionen | Option | Wert | Beschreibung | | ----------- | ----------------------------------------------- | -------------------------------------------------------------------------------------------- | | `--pattern` | ein Codeausschnitt | Prüft einen Codeausschnitt. Erfordert `--kind`. Wiederhole die Option für mehrere. | | `--kind` | `terraform` \| `dockerfile` \| `github-actions` | Die Art, als die der Codeausschnitt beurteilt wird. | | `--dir` | ein Verzeichnis | Beschränkt den Durchlauf auf ein Verzeichnis. Wiederholbar und mit `--file` kombinierbar. | | `--file` | eine Datei | Beschränkt den Durchlauf auf eine einzelne Datei. Wiederholbar und mit `--dir` kombinierbar. | Ohne Option durchsucht er jede IaC-Datei im Projekt. `--pattern` lässt sich nicht mit `--dir` oder `--file` kombinieren. **Tipp** Der Hook findet die offensichtlichen, entscheidbaren Fälle: Fehlende Verschlüsselung, die Exposition über `pull_request_target` und der passende IAM-Umfang bleiben Ermessensfragen, die die [Spezialisierung `infra`](https://lagune.ai/de-DE/docs/catalog) abdeckt. ## Häufige Fragen ### Welche Infrastrukturdateien liest der Hook infra? Terraform und HCL (.tf, .tf.json, .hcl), Dockerfiles sowie Workflow- und Action-YAML von GitHub Actions unter .github/. Er erreicht diese Dateien, obwohl die Scanner für Quellcode sie überspringen. --- # Hook interpreter: Sinks für dynamische Codeausführung melden > Durchsuche eine Codebasis sprachübergreifend nach Sinks für dynamische Codeausführung, oder bewerte einen einzelnen Codeausschnitt, direkt über die Kommandozeile. Kanonische URL: https://lagune.ai/de-DE/docs/hooks/interpreter Sprache: de-DE Original: https://lagune.ai/docs/hooks/interpreter Zuletzt aktualisiert: 2026-11-03 Der Hook `interpreter` meldet **Sinks für dynamische Codeausführung**: Konstrukte, die Daten in ausgeführten Code verwandeln oder an eine Shell übergeben, von `eval` bis zur nativen Deserialisierung. Er arbeitet sprachspezifisch und liest jede Datei nach ihren eigenen Regeln. Er ist die deterministische Engine hinter der [Spezialisierung `interpreter`](https://lagune.ai/de-DE/docs/catalog), und du kannst ihn selbst im Modus **scan** oder **check** ausführen. ## Ausführen **Codebasis durchsuchen** ```bash npx lagune read interpreter # scans the whole project npx lagune read interpreter --dir src # scans a directory npx lagune read interpreter --file app.py # scans a single file ``` **Codeausschnitt prüfen** ```bash npx lagune read interpreter --lang javascript --pattern 'eval(x)' # => careful npx lagune read interpreter --lang python --pattern 'json.loads(x)' # => safe ``` Diese Sinks sind Dual-Use: Ob eine vom Angreifer beeinflusste Eingabe einen davon erreicht, kann ein statischer Durchlauf nicht entscheiden, deshalb ist jeder Treffer eine **Warnung zur Prüfung**, nie ein bestätigter Befund. Der Durchlauf gibt einen einzigen Abschnitt **Dynamic-execution sinks to review** aus, nach Datei gruppiert. Findet er nichts, gibt er `no dynamic-execution sinks found` aus. **Lies den gemeldeten Code, führe ihn nie aus!** Analysiere jeden Sink **statisch** und verfolge, ob nicht vertrauenswürdige Eingaben ihn erreichen. Führe den gemeldeten Code nie aus und übergib ihn nie an `eval`, ebenso wenig entfernten oder erst zur Laufzeit geladenen Code, den er nachlädt, um zu "testen", was er tut. ## So liest du das Urteil | Urteil | Bedeutung | | --------- | ------------------------------------------------------------------------------------------------------------------------------ | | `careful` | Der Codeausschnitt enthält einen Sink für dynamische Ausführung in seiner Sprache. Prüfe ihn durch Lesen, nie durch Ausführen. | | `safe` | Für die angegebene Sprache wurde kein Sink für dynamische Ausführung gefunden. | ### CLI-Optionen | Option | Wert | Beschreibung | | ----------- | ------------------ | ------------------------------------------------------------------------------------------------------------- | | `--pattern` | ein Codeausschnitt | Prüft einen Codeausschnitt. Wiederhole die Option, um mehrere zu prüfen, ein Urteil pro Zeile. | | `--lang` | eine Sprache | Erforderlich bei `--pattern`: eine von javascript, python, php, ruby, java, kotlin, go, rust, c, cpp, csharp. | | `--dir` | ein Verzeichnis | Beschränkt den Durchlauf auf ein Verzeichnis. Wiederholbar und mit `--file` kombinierbar. | | `--file` | eine Datei | Beschränkt den Durchlauf auf eine einzelne Datei. Wiederholbar und mit `--dir` kombinierbar. | Ohne Option durchsucht er das gesamte Projekt. `--pattern` erfordert `--lang` und lässt sich nicht mit `--dir` oder `--file` kombinieren. ### Unterstützte Sprachen Der Durchlauf liest diese Sprachen, erkannt an der Dateiendung, und prüft jede gegen ihre eigene Menge an Sinks für dynamische Ausführung. | # | Sprache | Dateiendungen | Gemeldete Sinks | | --- | --------------------------- | ------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1 | **JavaScript / TypeScript** | `.js`, `.jsx`, `.mjs`, `.cjs`, `.ts`, `.tsx`, `.mts`, `.cts`, `.astro`, `.vue`, `.svelte`, `.marko`, `.riot` | `eval()`, Function-Konstruktor, `setTimeout`/`setInterval` mit einem String als Rumpf, Modul `vm`, exec von `child_process`, dynamisches `require()`, dynamisches `import()` | | 2 | **Python** | `.py`, `.pyi` | `eval`/`exec`, `__import__()`, `os.system`/`os.popen`, `subprocess` `shell=True`, `pickle.load`/`loads`, `yaml.load` (unsicher) | | 3 | **Ruby** | `.rb` | eval-Familie (`instance_eval`/`class_eval`/`module_eval`/`eval`), `system`/`exec`, Backticks oder `%x`, `Kernel#open` / `IO.popen`/`read`/`binread` / `Open3`, `Process.spawn`, `Marshal.load` | | 4 | **Go** | `.go` | `exec.Command`/`exec.CommandContext`, `plugin.Open` | | 5 | **PHP** | `.php` | `eval()`, `assert()` auf einem String, `create_function()`, Shell-Ausführung (`system`/`exec`/`shell_exec`/`passthru`/`popen`/`proc_open`), `call_user_func`/`call_user_func_array`, `include`/`require` mit einem zur Laufzeit gebildeten Pfad | | 6 | **Rust** | `.rs` | `Command::new`, `process::Command` | | 7 | **Java** | `.java` | `Runtime.exec`, `ProcessBuilder`, `ScriptEngine`, `ObjectInputStream.readObject` | | 8 | **Kotlin** | `.kt`, `.kts` | Die JVM-Sinks: `Runtime.exec`, `ProcessBuilder`, `ScriptEngine`, `ObjectInputStream.readObject` | | 9 | **C#** | `.cs` | `Process.Start` / `new Process`, `BinaryFormatter`, `Assembly.Load` | | 10 | **C** | `.c`, `.h` | `system()`, `popen()`, die Familie `exec*` (`execl`, `execve`, `execvp`, …) | | 11 | **C++** | `.cc`, `.cpp`, `.cxx`, `.hpp`, `.hh`, `.hxx` | `system()`, `popen()`, die Familie `exec*` (`execl`, `execve`, `execvp`, …) | **Bestmöglich, aber nicht lückenlos** Er liest den Quellcode als Text, deshalb kann ihm ein Sink entgehen, der erst zur Laufzeit zusammengesetzt wird, hinter einem Alias steckt oder in einer Form geschrieben ist, die er nicht erkennt. Betrachte die Tabelle als soliden Ausgangspunkt, nicht als vollständige Bestandsaufnahme. **Tipp** Der Hook garantiert das Minimum (dass diese Sinks existieren und wo): Ob ein nicht vertrauenswürdiger Wert tatsächlich einen davon erreicht, ist die Ermessensfrage, die die [Spezialisierung `interpreter`](https://lagune.ai/de-DE/docs/catalog) abdeckt. ## Häufige Fragen ### Bestätigt der Hook interpreter eine Schwachstelle? Nein. Er meldet Sinks für dynamische Ausführung als Warnung zur Prüfung, nie als bestätigten Befund, weil ein statischer Durchlauf nicht entscheiden kann, ob eine vom Angreifer beeinflusste Eingabe den Sink erreicht. ### Welche Sprachen deckt der Hook interpreter ab? Er liest die Sprachen aus der Tabelle "Unterstützte Sprachen", erkannt an der Dateiendung, und prüft jede gegen ihre eigene Menge an Sinks. Andere Sprachen ergeben keine Sinks. --- # Hook jwt: JWT-Verifizierung ohne festgelegten Algorithmus erkennen > Durchsuche eine Codebasis nach JWT-Verifizierungen ohne festgelegten Algorithmus, oder bewerte einen einzelnen Aufruf, direkt über die Kommandozeile. Kanonische URL: https://lagune.ai/de-DE/docs/hooks/jwt Sprache: de-DE Original: https://lagune.ai/docs/hooks/jwt Zuletzt aktualisiert: 2026-11-03 Der Hook `jwt` meldet **JWT-Verifizierungen ohne festgelegten Algorithmus**, also die Lücke der Algorithm Confusion, bei der ein Verifizierer dem Header `alg` des Tokens selbst vertraut, sowie **vollständig abgeschaltete Verifizierungen**. Er arbeitet **sprachspezifisch** und liest jede Datei anhand ihrer eigenen JWT-Bibliothek. Er ist die deterministische Engine hinter der [Spezialisierung `federation`](https://lagune.ai/de-DE/docs/catalog), und du kannst ihn selbst im Modus **scan** oder **check** ausführen. ## Ausführen **Codebasis durchsuchen** ```bash npx lagune read jwt # scans the whole project npx lagune read jwt --dir src # scans a directory npx lagune read jwt --file auth.ts # scans a single file ``` **Aufruf prüfen** ```bash npx lagune read jwt --lang javascript --pattern 'jwt.verify(token, secret)' # => unpinned npx lagune read jwt --lang python --pattern 'jwt.decode(t, k, options={"verify_signature": False})' # => unpinned npx lagune read jwt --lang python --pattern 'jwt.decode(t, k, algorithms=["HS256"])' # => safe ``` Jede Zeile unter **Unpinned JWT verification found** ist ein Verifizierungsaufruf, der keine Allowlist `algorithms` setzt (wo die Bibliothek eine braucht), eine unsichere akzeptiert (`none` oder einen asymmetrischen Algorithmus gemischt mit HMAC) oder die Signaturprüfung gleich ganz abschaltet und deshalb dem `alg` des Tokens selbst vertraut. Das ist eine bestätigte Gefährdung, deshalb endet der Hook mit einem Exit-Code ungleich null. Findet er nichts, gibt er `no unpinned JWT verification found` aus. ## So liest du das Urteil | Urteil | Bedeutung | | ---------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | `unpinned` | Ein Verifizierungsaufruf ohne Allowlist für Algorithmen (wo eine nötig ist), mit einer unsicheren oder mit abgeschalteter Verifizierung. | | `safe` | Ein Verifizierungsaufruf, der eine solide Allowlist für Algorithmen festlegt oder dessen Bibliothek sie implizit festlegt. | | `invalid` | Der Codeausschnitt enthält keinen erkennbaren Verifizierungsaufruf, den er beurteilen könnte. | ### CLI-Optionen | Option | Wert | Beschreibung | | ----------- | ------------------ | ----------------------------------------------------------------------------------------------------- | | `--pattern` | ein Codeausschnitt | Prüft einen Aufruf. Wiederhole die Option, um mehrere zu prüfen, ein Urteil pro Zeile. | | `--lang` | eine Sprache | Erforderlich bei `--pattern`: eine von javascript, python, go, java, kotlin, php, ruby, rust, csharp. | | `--dir` | ein Verzeichnis | Beschränkt den Durchlauf auf ein Verzeichnis. Wiederholbar und mit `--file` kombinierbar. | | `--file` | eine Datei | Beschränkt den Durchlauf auf eine einzelne Datei. Wiederholbar und mit `--dir` kombinierbar. | Ohne Option durchsucht er das gesamte Projekt. `--pattern` erfordert `--lang` und lässt sich nicht mit `--dir` oder `--file` kombinieren. ### Unterstützte Sprachen Der Durchlauf liest diese Bibliotheken, erkannt an der Dateiendung. Weil manche den Algorithmus implizit festlegen (eine fehlende explizite Liste ist dort korrekt), gilt die Regel "keine Allowlist ⇒ unpinned" nur dort, wo die Bibliothek eine explizite erwartet, sodass er einen korrekt konfigurierten Aufruf nie meldet. | Sprache | Bibliothek | Meldet eine fehlende Allowlist als unpinned? | Meldet immer | | --------------------------- | ----------------------- | -------------------------------------------------------------------------- | ------------------------------------------------- | | **JavaScript / TypeScript** | jsonwebtoken, jose | Ja | `none`, Mischung aus asymmetrisch und HMAC | | **Python** | PyJWT, python-jose | Ja (PyJWT verlangt sie, python-jose nutzt standardmäßig `algorithms=None`) | `none`, `verify_signature: False` | | **Go** | golang-jwt | Ja (ohne `WithValidMethods`) | `none`, `ParseUnverified` | | **Ruby** | ruby-jwt | Ja | `none`, `verify = false` | | **Java / Kotlin** | jjwt, nimbus | Nein (aus dem Schlüssel abgeleitet) | `none`, ein Parser ohne Signatur oder `unsecured` | | **PHP** | firebase/php-jwt | Nein (`Key` trägt den Algorithmus) | `none` | | **Rust** | jsonwebtoken | Nein (`Validation` verlangt einen) | `none`, `insecure_disable_signature_validation` | | **C#** | Microsoft.IdentityModel | Nein (mehrzeilige Parameter) | `none`, `RequireSignedTokens = false` | **Tipp** Der Hook entscheidet nur über die Festlegung des Algorithmus: Die Prüfungen von Claims, Schlüsseln und Flows bleiben Ermessensfragen, die die [Spezialisierung `federation`](https://lagune.ai/de-DE/docs/catalog) abdeckt. ## Häufige Fragen ### Was ist Algorithm Confusion bei JWT? Ein Verifizierer, der den Algorithmus aus dem Header des Tokens liest, erlaubt einem Angreifer, RS256 gegen HS256 zu tauschen und mit dem öffentlichen Schlüssel zu signieren. Eine solide Allowlist für Algorithmen, die im Code festgelegt ist, verhindert das, und der Hook jwt meldet jeden Verifizierungsaufruf, der keine oder eine unsichere festlegt. --- # Hook network: URLs auf SSRF bewerten > Bewerte das SSRF-Risiko eines oder mehrerer Anfrageziele, direkt über die Kommandozeile. Kanonische URL: https://lagune.ai/de-DE/docs/hooks/network Sprache: de-DE Original: https://lagune.ai/docs/hooks/network Zuletzt aktualisiert: 2026-11-03 Der Hook `network` entscheidet, ob das Ziel einer serverseitigen Anfrage vor **SSRF** sicher ist (einer Anfrage, die sich auf interne Dienste, Cloud-Metadaten oder private Hosts richten lässt). Er ist die deterministische Engine hinter der [Spezialisierung `network`](https://lagune.ai/de-DE/docs/catalog), und du kannst ihn selbst ausführen. ## Ausführen Übergib jedes Ziel mit `--url`. Der Hook gibt pro Ziel ein Wort aus, dessen Bedeutung die Tabelle weiter unten erklärt. **Ein Ziel** ```bash npx lagune read network --url 'http://example.com/' # => safe npx lagune read network --url 'http://0x7f000001/' # => private-target ``` **Mehrere Ziele** Wiederhole `--url`, um eine ganze Allowlist oder Denylist mit einem Aufruf zu bewerten, ein Urteil pro Zeile, in derselben Reihenfolge. ```bash npx lagune read network \ --url 'http://example.com/' \ --url 'http://[::1]/' \ --url 'http://allowed.com@evil.example/' # => safe # => private-target # => parser-divergent ``` Er löst den Host so auf, wie es das Netzwerk tut, deshalb rutschen codierte Formen einer internen Adresse nicht durch: Hexadezimale, oktale, punktlose dezimale, verkürzte, IPv6- und IPv4-gemappte Schreibweisen ergeben alle `private-target`. Und wo ein nachlässiger Validator und der Client, der die Anfrage tatsächlich ausführt, unterschiedliche Hosts lesen würden, lautet das Urteil `parser-divergent`. ## So liest du das Urteil | Urteil | Bedeutung | | ------------------ | ---------------------------------------------------------------------------------------------------------------- | | `safe` | Das Ziel führt zu einem öffentlichen Host, und ein nachlässiger Validator würde denselben Host lesen. | | `private-target` | Der Host löst zu einer privaten, Loopback-, Link-Local-, unspezifizierten oder Cloud-Metadaten-Adresse auf. | | `parser-divergent` | Ein nachlässiger Textvalidator würde einen anderen realen Host lesen als den, mit dem sich der Client verbindet. | | `invalid url` | Die Zeichenkette lässt sich nicht als URL parsen, also gibt es nichts abzurufen. | Nur `safe` bedeutet Zulassen. Behandle `private-target`, `parser-divergent` und `invalid url` alle als Sperre. ### CLI-Optionen | Option | Wert | Beschreibung | | ------- | ---------------------- | ---------------------------------------------------------------------------------- | | `--url` | eine URL oder ein Host | Prüft ein Ziel. Wiederhole die Option, um mehrere zu prüfen, ein Urteil pro Zeile. | Mindestens ein `--url` ist Pflicht. Das Ziel ist nie ein bloßes Positionsargument, deshalb kann es nicht mit einer Option verwechselt werden. **Warum als Wert einer Option** Jedes Ziel wird als Wert einer Option übergeben und nie in den Befehl interpoliert. Ein Wert mit Anführungszeichen oder Backticks bleibt wirkungslos und kann nichts in die Shell einschleusen. Setze ihn immer in einfache Anführungszeichen, damit deine Shell ihn nicht vorher expandiert. **Was er nicht abdeckt** Der Hook ist rein und löst nie DNS auf, deshalb liegen zwei Lücken, die erst zur Laufzeit entstehen, außerhalb seines Umfangs: **DNS-Rebinding** (ein Name, der bei der Prüfung öffentlich und beim Abruf intern auflöst) und **Weiterleitungsketten** (ein erster Sprung, der die Prüfung besteht und dann nach innen weiterleitet). Schließe sie, indem du einmal auflöst und dich mit der validierten Adresse verbindest, und indem du Weiterleitungen ablehnst. Die reservierten Loopback-Namen (`localhost` und die Familie `.localhost`) stuft er ohne Abfrage als intern ein, aber jeder andere DNS-Name ergibt `safe`, denn die Behauptung, er löse nach innen auf, würde eine Auflösung erfordern: Diese Namen schützt die Allowlist, und genau sie prüft dieser Checker. **Tipp** Das ist dieselbe Prüfung, die die [Spezialisierung `network`](https://lagune.ai/de-DE/docs/catalog) ausführt, um nachzuweisen, dass ein Zielfilter greift. ## Häufige Fragen ### Wie teste ich eine URL auf SSRF? Führe den Hook network aus. Er bewertet ein Anfrageziel und gibt safe, private-target, parser-divergent oder invalid url zurück. Nur safe bedeutet Zulassen. ### Was ist eine URL vom Typ parser-divergent? Eine URL, die verschiedene Parser unterschiedlich lesen, was ein klassischer Weg ist, einen SSRF-Schutz zu umgehen. Der Hook network meldet sie, statt sie zuzulassen. --- # Hook regex: ReDoS-Muster erkennen > Durchsuche eine Codebasis nach ReDoS-anfälligen Regex-Mustern, oder bewerte ein einzelnes Muster, direkt über die Kommandozeile. Kanonische URL: https://lagune.ai/de-DE/docs/hooks/regex Sprache: de-DE Original: https://lagune.ai/docs/hooks/regex Zuletzt aktualisiert: 2026-11-03 Der Hook `regex` ist die deterministische Engine für sichere Regex, die die [Spezialisierung `regex`](https://lagune.ai/de-DE/docs/catalog) verwendet, und du kannst ihn selbst ausführen. Er arbeitet mit einem einzigen Befehl in zwei Modi: Im Modus **scan** durchsucht er eine Codebasis nach Mustern, die für **ReDoS** anfällig sind oder erst zur Laufzeit gebaut werden, und im Modus **check** bewertet er ein einzelnes Muster, das du ihm übergibst. ## Eine Codebasis durchsuchen Ohne Option durchsucht er das gesamte Projekt. `--dir` beschränkt den Durchlauf auf ein Verzeichnis, `--file` auf eine einzelne Datei. Beide lassen sich wiederholen und zu einem Bericht kombinieren, in dem jede Datei nur einmal erscheint, auch wenn mehr als ein Ziel sie abdeckt. **Gesamtes Projekt** ```bash npx lagune read regex ``` **Ein Verzeichnis** ```bash npx lagune read regex --dir src/services ``` **Eine einzelne Datei** ```bash npx lagune read regex --file bin/import.pl ``` **Mehrere Ziele** ```bash npx lagune read regex --dir core --dir workers --file Sources/App/Router.swift ``` **Mit Limit** `--limit` legt den ReDoS-Schwellenwert für den Durchlauf fest (Standard 25), dasselbe Limit, das auch der Modus check annimmt. Ein niedrigeres Limit ist strenger. ```bash npx lagune read regex --dir src/services --limit 15 ``` Die Ausgabe ist reiner Text, dessen Überschriften sagen, wie jeder Abschnitt zu lesen ist. Ein Abschnitt erscheint nur, wenn er Befunde enthält. ```text Vulnerable regular expressions found: cmd/server/main.go ([a-z]+)+$ (exponential, search) Dynamically built regular expressions (review manually by simulating a constructed regex): app/payments.php crates/parser/lexer.rs lib/validate.py Static regex wrapped in a constructor (use a literal instead): config/token.rb ``` Findet er nichts, gibt er eine einzige Zeile aus. ```bash npx lagune read regex --dir src/clean # => no unsafe patterns found ``` ### So liest du die Abschnitte | Abschnitt | Bedeutung | | ------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Vulnerable regular expressions found` | ReDoS-anfällige Muster, nach Datei gruppiert, jedes Muster eingerückt darunter, gefolgt in Klammern vom Grund, warum es unsicher ist, und, falls vorhanden, von seinem Geltungsbereich und seinen Flags. Jede Zeile ist unsicher, deshalb wird das Urteil nicht wiederholt. | | `Regular expressions the analysis could not settle (review manually)` | Muster, die die Analyse innerhalb ihres Arbeitslimits nicht klären konnte, genauso aufgelistet. | | `Dynamically built regular expressions (review manually by simulating a constructed regex)` | Dateien, die eine Regex aus einer Variablen, einer Verkettung oder einer Interpolation bauen. | | `Static regex wrapped in a constructor (use a literal instead)` | Dateien, die einem Regex-Konstruktor ein einfaches String-Literal übergeben, wo ein Regex-Literal einfacher wäre und die Kompilierung zur Laufzeit spart. | Der erste Abschnitt ist ein Sicherheitsbefund. Der zweite und dritte sind für sich genommen keine Befunde: Sie zeigen auf Code, den eine statische Prüfung nicht klären kann, und verlangen deshalb, dass ein Mensch ihn liest. Der vierte ist ein Hinweis zur Lesbarkeit, kein Sicherheitsbefund. ### CLI-Optionen | Option | Wert | Beschreibung | | ----------- | ---------------------------- | --------------------------------------------------------------------------------------------------------------- | | `--pattern` | der Quelltext einer Regex | Prüft ein Muster. Wiederhole die Option, um mehrere zu prüfen, ein Urteil pro Muster, in derselben Reihenfolge. | | `--flags` | Regex-Flags | Prüft jedes `--pattern` mit diesen Flags, etwa `im`. Gilt nur für den Modus check. | | `--dir` | ein Verzeichnis | Beschränkt den Durchlauf auf ein Verzeichnis. Wiederholbar und mit `--file` kombinierbar. | | `--file` | eine Datei | Beschränkt den Durchlauf auf eine einzelne Datei. Wiederholbar und mit `--dir` kombinierbar. | | `--limit` | eine nicht negative Ganzzahl | Legt das ReDoS-Wiederholungslimit fest (Standard 25). Gilt für beide Modi. Ein niedrigeres Limit ist strenger. | Ohne Option durchsucht er das gesamte Projekt. `--pattern` steht für den Modus check und lässt sich nicht mit `--dir` oder `--file` kombinieren. ### Unterstützte Sprachen Der Durchlauf liest diese Sprachen, erkannt an der Dateiendung, jede nach ihren eigenen Regeln, sodass er ein Muster aus einer Sprache nie nach den Regeln einer anderen testet. Alles andere überspringt er, statt es mit den falschen Regeln zu durchsuchen. | # | Sprache | Dateiendungen | | --- | --------------------------- | ------------------------------------------------------------------------------------------------------------ | | 1 | **JavaScript / TypeScript** | `.js`, `.jsx`, `.mjs`, `.cjs`, `.ts`, `.tsx`, `.mts`, `.cts`, `.astro`, `.vue`, `.svelte`, `.marko`, `.riot` | | 2 | **Python** | `.py`, `.pyi` | | 3 | **Ruby** | `.rb` | | 4 | **Go** | `.go` | | 5 | **PHP** | `.php` | | 6 | **Rust** | `.rs` | | 7 | **Java** | `.java` | | 8 | **C#** | `.cs` | | 9 | **C** | `.c`, `.h` | | 10 | **C++** | `.cc`, `.cpp`, `.cxx`, `.hpp`, `.hh`, `.hxx` | | 11 | **Kotlin** | `.kt`, `.kts` | | 12 | **Swift** | `.swift` | | 13 | **Scala** | `.scala`, `.sc` | | 14 | **Dart** | `.dart` | | 15 | **PowerShell** | `.ps1`, `.psm1`, `.psd1` | | 16 | **Elixir** | `.ex`, `.exs` | | 17 | **Objective-C** | `.m`, `.mm` | | 18 | **R** | `.r` | | 19 | **Julia** | `.jl` | | 20 | **Clojure** | `.clj`, `.cljs`, `.cljc`, `.edn` | | 21 | **Crystal** | `.cr` | | 22 | **Nim** | `.nim`, `.nims` | | 23 | **V** | `.v` | | 24 | **D** | `.d` | | 25 | **Perl** | `.pl`, `.pm` | **Bestmöglich, aber nicht lückenlos** Er liest den Quellcode als Text, deshalb kann er kein Muster beurteilen, das erst zur Laufzeit zusammengesetzt wird, und ein Muster, das sich über mehrere Zeilen erstreckt, hinter einem Alias steckt oder in einer Form geschrieben ist, die er nicht erkennt, kann ihm entgehen. Betrachte die Abschnitte als soliden Ausgangspunkt, nicht als vollständige Bestandsaufnahme, und lies den Code weiterhin selbst, um zu erfassen, was sie nicht erreichen. ## Ein einzelnes Muster prüfen Übergib `--pattern` mit dem Quelltext des Musters, um es zu bewerten. Der Hook gibt ein Wort aus: `safe`, `unsafe`, `undetermined`, wenn die Analyse ihr Arbeitslimit erreicht, bevor sie das Muster klären kann, oder `invalid regex`. Wiederhole `--pattern`, um mehrere auf einmal zu bewerten, ein Urteil pro Muster, in derselben Reihenfolge. **Ein Muster** ```bash npx lagune read regex --pattern '(a+)+$' # => unsafe npx lagune read regex --pattern '^[a-z0-9_]{3,20}$' # => safe ``` **Mehrere Muster** ```bash npx lagune read regex --pattern '(a+)+$' --pattern '^[a-z]+$' # => unsafe # => safe ``` **Mit Flags** `--flags` prüft jedes `--pattern` des Aufrufs mit den Flags, mit denen es ausgeführt wird, denn ein Flag ändert, welche Zeichen ein Muster trifft. ```bash npx lagune read regex --pattern '^(?:a|A)+$' # => safe npx lagune read regex --pattern '^(?:a|A)+$' --flags 'i' # => unsafe ``` **Mit Limit** `--limit` legt das Wiederholungslimit fest (Standard 25) und gilt für jedes `--pattern` des Aufrufs. Ein niedrigeres Limit ist strenger. ```bash npx lagune read regex --pattern 'a?a?a?' --limit 2 # => unsafe ``` **Warum ein Argument in Anführungszeichen** Jedes Muster wird als Wert einer Option übergeben und nie in den Befehl interpoliert. Ein Wert mit Anführungszeichen oder Backticks bleibt wirkungslos und kann nichts in die Shell einschleusen. Setze das Muster immer in einfache Anführungszeichen, damit deine Shell es nicht vorher expandiert. **Tipp** Das ist dieselbe Engine, die die [Spezialisierung `regex`](https://lagune.ai/de-DE/docs/catalog) ausführt: Der Modus scan eröffnet die ReDoS-Prüfung, der Modus check bestätigt ein Muster, das sie zutage fördert. ## Häufige Fragen ### Wie prüfe ich eine Regex über die CLI auf ReDoS? Führe npx lagune read regex --pattern '' aus. Der Befehl gibt safe, unsafe, undetermined oder invalid regex zurück. ### Wie durchsuche ich ein ganzes Projekt nach unsicheren Regex? Führe den Hook regex im Modus scan über die Codebasis aus. Er meldet ReDoS-anfällige Muster in 25 unterstützten Sprachen. --- # Hook secrets: fest im Code hinterlegte Secrets erkennen > Durchsuche eine Codebasis nach fest im Code hinterlegten Zugangsdaten, direkt über die Kommandozeile. Kanonische URL: https://lagune.ai/de-DE/docs/hooks/secrets Sprache: de-DE Original: https://lagune.ai/docs/hooks/secrets Zuletzt aktualisiert: 2026-11-03 Der Hook `secrets` meldet **Zugangsdaten, die fest im Quellcode stehen**, statt aus der Umgebung gelesen zu werden. Er achtet auf die **Herkunft** (ein Literal oder ein Zugriff auf die Umgebung), nicht auf den Inhalt des Werts, deshalb braucht er keinen vollständigen Katalog von Anbieter-Präfixen und erzeugt kaum False Positives. Er ist die deterministische Engine hinter der [Spezialisierung `secrets`](https://lagune.ai/de-DE/docs/catalog). Signaturen im Format eines Anbieters, Zugangsdaten in Connection-Strings und ein Literal, das einem Bezeichner mit Secret-typischem Namen zugewiesen ist, sind **sprachunabhängig**: Derselbe String liest sich in jeder Datei gleich. Die zwei Heuristiken, die von der Syntax abhängen (ein Zugriff auf die Umgebung mit einem fest im Code hinterlegten Standardwert und ein Secret, das in einen Log-Sink fließt), arbeiten **sprachspezifisch**, sodass er ein `console.log` aus JavaScript nie in einer Rust-Datei sucht und das `os.getenv("X", "default")` von Python für sich erkennt. ## Ausführen ```bash npx lagune read secrets # scans the whole project npx lagune read secrets --dir src # scans a directory npx lagune read secrets --file config.ts # scans a single file ``` Der Durchlauf gibt bis zu zwei Abschnitte aus. **Hardcoded secrets found** enthält die Befunde (ein fest im Code hinterlegter Standardwert für eine Umgebungsvariable mit Secret-typischem Namen, in einen Connection-String eingebettete Zugangsdaten oder ein Wert, der zu einem kuratierten Anbieterformat passt), deshalb endet der Hook mit einem Exit-Code ungleich null. **Secret handling to review manually** enthält Prüfhinweise: ein einfaches Literal, das einem Bezeichner mit Secret-typischem Namen zugewiesen ist (seine Herkunft lässt sich entscheiden, ob der Wert ein echtes Secret ist, dagegen nicht), und ein Wert mit Secret-typischem Namen, der in einen Log- oder Antwort-Sink fließt. Findet er nichts, gibt er `no hardcoded secrets found` aus. ### CLI-Optionen | Option | Wert | Beschreibung | | -------- | --------------- | -------------------------------------------------------------------------------------------- | | `--dir` | ein Verzeichnis | Beschränkt den Durchlauf auf ein Verzeichnis. Wiederholbar und mit `--file` kombinierbar. | | `--file` | eine Datei | Beschränkt den Durchlauf auf eine einzelne Datei. Wiederholbar und mit `--dir` kombinierbar. | Ohne Option durchsucht er das gesamte Projekt. ### Abgedeckte Sprachen Der Befund zum Standardwert einer Umgebungsvariablen und der Prüfhinweis zum Log-Sink lesen je Sprache eigene Schreibweisen, deshalb decken sie die folgenden Sprachen ab und bleiben anderswo still. Die anderen drei Signale prüfen **jede** Datei. | Signal | Sprachen | | ------------------------- | ------------------------------------------------------------------------------- | | Standardwert der Umgebung | JavaScript/TypeScript, Python, Ruby, PHP, Kotlin, Java, Go (`cmp.Or`), Rust, C# | | Log- oder Antwort-Sink | JavaScript/TypeScript, Python, Ruby, PHP, Java, Kotlin, Go, Rust, C, C++, C# | **Verstößt das gegen eine Richtlinie?** Nein. Das Format eines Secrets zu erkennen, um zu warnen, dass es committet wurde, ist gängige Praxis defensiver Werkzeuge, dieselbe Operation, die gitleaks, trufflehog und die Push Protection von GitHub ausführen. Der Hook liefert Erkennungssignaturen (öffentliche **Formate** von Tokens), nie ein echtes Secret, und er auditiert und erklärt, statt Daten zu exfiltrieren. ## Häufige Fragen ### Wie vermeidet der Hook secrets False Positives? Er achtet auf die Herkunft, nicht auf den Inhalt des Werts. Formate mit hoher Treffsicherheit (Tokens von Anbietern, Standardwerte aus der Umgebung, Connection-Strings) sind Befunde, die mit einem Exit-Code ungleich null enden. Ein einfaches Literal, das einem Bezeichner mit Secret-typischem Namen zugewiesen ist, ist ein Prüfhinweis, den du bestätigen musst, und derselbe Bezeichner, aus process.env gelesen, wird gar nicht gemeldet. --- # Prompt-Beispiele für Lagune: den Blue-Team-Workflow automatisieren > Prompts für Lagune zum Kopieren: ein Durchlauf nur mit Lesezugriff, der vollständige Blue-Team-Workflow und ein Zero-Trust-Audit, dazu eine Erkennung, die auf einen Commit, den Diff eines Branches oder PR oder einen echten Vorfall eingegrenzt ist. Kanonische URL: https://lagune.ai/de-DE/docs/examples/prompts Sprache: de-DE Original: https://lagune.ai/docs/examples/prompts Zuletzt aktualisiert: 2026-11-03 Prompts für Lagune zum Kopieren, die du direkt in deinen KI-Agenten einfügen kannst. ## 💧 Schneller Durchlauf Ein Durchlauf nur mit Lesezugriff, der den Code eigenständig liest und jede Schwachstelle mit einer Korrektur meldet, ohne den Blue-Team-Workflow auszuführen oder in die Nachverfolgung von Lagune zu schreiben. **Tipp** Funktioniert besser im Planungsmodus und mit festgelegten Sicherheitsprinzipien (`/lagune-charter`). **🪼 Standard** | Aspekt | Abwägung | Stufe | | ------------------- | ----------------------------------------------------------------------------- | ------------------- | | **Aufwand** | Ein Agent durchsucht den Code und berichtet, ohne Subagenten. | 1/5 | | **Zeit** | Schnell. Ein einziger Durchlauf nur mit Lesezugriff, der nichts umsetzt. | 2/5 | | **Token-Verbrauch** | Mäßig, geteilt. Der gesamte Durchlauf findet in einem einzigen Kontext statt. | 2/5 | ```md /lagune Du bist ein Cybersecurity-Forscher mit fundierter Erfahrung in defensiver Sicherheit und nutzt Lagune, um dein Wissen und deine Präzision zu verbessern. Durchsuche den Workspace eigenständig und ordne jeder Schwachstelle, die du findest, eine konkrete Korrektur zu. Dies ist ein separater Durchlauf, nicht der Blue-Team-Workflow: Führe weder detect, plan, harden noch verify aus und schreibe nichts in die Nachverfolgung von Lagune. Liste am Ende jede gefundene Schwachstelle auf, jeweils mit ihrem Schweregrad und einer konkreten Korrektur. ``` **🐬 Multi-Agent** | Aspekt | Abwägung | Stufe | | ------------------- | ------------------------------------------------------------------------------------------- | ------------------- | | **Aufwand** | Ein Subagent pro Datei, abgestimmt auf die Größe deiner Codebasis. | 2/5 | | **Zeit** | Parallel pro Datei, danach zu einem Bericht zusammengeführt. Weiterhin nur mit Lesezugriff. | 3/5 | | **Token-Verbrauch** | Höher, aber isoliert. Jeder Subagent führt seinen Durchlauf in einem eigenen Kontext aus. | 3/5 | ````md /lagune Du bist ein Cybersecurity-Orchestrator und nutzt Lagune, um die Pfade aufzulisten, pro Pfad einen Subagenten zu starten und ihre Berichte zusammenzuführen (alle Inhalte lesen die Subagenten). Du musst die Aufgabe abhängig von der Größe des aktuellen Projekts an Subagenten delegieren: Je größer die Codebasis, desto mehr Subagenten sollen gestartet werden, alle parallel, und jeder erhält den folgenden Prompt: ```prompt /lagune Du bist ein Cybersecurity-Forscher mit fundierter Erfahrung in defensiver Sicherheit und nutzt Lagune, um dein Wissen und deine Präzision zu verbessern. Durchsuche eigenständig und ordne jeder Schwachstelle, die du findest, eine konkrete Korrektur zu. Dies ist ein separater Durchlauf, nicht der Blue-Team-Workflow: Führe weder detect, plan, harden noch verify aus und schreibe nichts in die Nachverfolgung von Lagune. Liste am Ende jede Schwachstelle in auf, jeweils mit ihrem Schweregrad und einer konkreten Korrektur. ``` Führe am Ende alle Berichte der Subagenten zu einer priorisierten Liste von Schwachstellen und Korrekturen zusammen. ```` **Warnung** Ein schneller Durchlauf ist ein einziger breiter Prompt ohne Eingrenzung, daher lehnen manche Agenten ihn eher ab oder beenden ihn vorzeitig. Sträubt sich dein Agent, führe stattdessen den vollständigen **Blue-Team-Workflow** weiter unten aus: Seine eingegrenzten, schrittweisen Phasen werden weit seltener blockiert. --- ## 🌊 Automatischer Blue-Team-Audit-Workflow Führt den [vollständigen Befehlsablauf](https://lagune.ai/de-DE/docs/get-started/commands) von Anfang bis Ende aus, ohne für Eingaben anzuhalten. **🪼 Standard** | Aspekt | Abwägung | Stufe | | ------------------- | ------------------------------------------------------------------------------------------------------ | ------------------- | | **Aufwand** | Ein Agent, keine Subagenten, unabhängig von der Größe der Codebasis. | 3/5 | | **Zeit** | Mittel, aber weniger gründlich in großen Codebasen. Jeder Befehl läuft einmal, einer nach dem anderen. | 4/5 | | **Token-Verbrauch** | Geringer, aber weniger isoliert. Alle Befehle teilen sich denselben Kontext. | 4/5 | ```md Führe die folgenden Befehle nacheinander aus: `/lagune-charter`, `/lagune-detect`, `/lagune-plan`, `/lagune-harden` und `/lagune-verify`. ## Schleife Wenn `/lagune-verify` eine oder mehrere Korrekturen zurückweist, wiederhole `/lagune-harden` und danach `/lagune-verify`, bis alle Befunde ordnungsgemäß behoben sind. ## Wichtig - Halte nicht an, frag nicht nach: Im Zweifel erledige alles im Modus "full". ``` **🐋 Multi-Agent (gründlicher Durchlauf)** | Aspekt | Abwägung | Stufe | | ------------------- | --------------------------------------------------------------------------------------------------------- | ------------------- | | **Aufwand** | Die Zahl der Subagenten richtet sich nach der Größe deiner Codebasis. | 5/5 | | **Zeit** | Länger, aber gründlicher. Startet mehrere Subagenten, die Befunde parallel erkennen, planen und härten. | 5/5 | | **Token-Verbrauch** | Höher, aber sicherer. Jeder Subagent hat seinen eigenen, isolierten Kontext, frei von Voreingenommenheit. | 5/5 | ````md Übergib jeden der folgenden Befehle an einen eigenen Subagenten, einen nach dem anderen (ohne Backticks, nur den Befehl): Prompt für Subagent 1: `/lagune-charter` Prompt für Subagent 2: `/lagune-detect` Prompt für Subagent 3: `/lagune-plan` Prompt für Subagent 4: `/lagune-harden` Prompt für Subagent 5: `/lagune-verify` Bei den Befehlen `/lagune-detect`, `/lagune-plan`, `/lagune-harden` und `/lagune-verify` musst du die Aufgabe abhängig von der Größe des aktuellen Projekts an Subagenten delegieren: Je größer die Codebasis, desto mehr Subagenten sollen gestartet werden. Zum Beispiel: ```prompt /lagune-detect ``` ```prompt /lagune-plan ``` ```prompt /lagune-harden ``` ```prompt /lagune-verify ``` - Starte mehrere Agenten für denselben Befehl parallel. - Wenn alle Subagenten von `/lagune-detect` fertig sind, führe Folgendes aus: ```prompt /lagune-detect führe gleichwertige Befunde zusammen. Suche nicht nach neuen Befunden und durchsuche die Codebasis nicht erneut. ``` ## Schleife Wenn `/lagune-verify` eine oder mehrere Korrekturen zurückweist, wiederhole `/lagune-harden` und danach `/lagune-verify`, bis alle Befunde ordnungsgemäß behoben sind. ## Wichtig - Halte nicht an, frag nicht nach: Im Zweifel erledige alles im Modus "full". ```` --- ## 🪄 Eingegrenzte Erkennung Richte [`/lagune-detect`](https://lagune.ai/de-DE/docs/commands/detect) auf einen Ausschnitt deines Projekts statt auf das Ganze. Beschreibe den Umfang in einfachen Worten (einen Commit, einen Pull Request oder eine reale Situation), und der Befehl erfasst nur die sicherheitsrelevanten Befunde darin. **Tipp** Alles, was der Befehl hier erkennt, ist ein normaler Befund, sodass du es direkt an `/lagune-plan`, `/lagune-harden` und `/lagune-verify` weitergeben kannst, eingegrenzt auf genau diese Einträge. **📌 Seit einem Commit** Unterziehe eine neue Reihe von Commits einer eigenen Sicherheitsprüfung, eingegrenzt auf das, was sie geändert haben, zum Beispiel: ```prompt /lagune-detect Beschränke die Erkennung auf alles, was sich seit dem Commit `a1b2c3d` geändert hat. ``` **🔀 Diff eines Branches oder PR** Prüfe die Sicherheit eines Pull Requests vor dem Merge, eingegrenzt auf seinen Diff, zum Beispiel: ```prompt /lagune-detect Beschränke die Erkennung auf die Änderungen, die dieser Branch gegenüber `main` einführt. ``` **⛑️ Nach einem Vorfall** Beschreibe mit deinen eigenen Worten, was passiert ist. Lagune liest die Situation statt eines Flags und macht daraus eine gezielte Suche, zum Beispiel: ```prompt /lagune-detect Unsere Website hatte vor ein paar Wochen ein Datenleck. Ich weiß nicht genau, wie es passiert ist, und ich mache mir Sorgen, dass noch etwas offen ist, über das erneut Daten abfließen könnten. Geh den Code sorgfältig durch, konzentriere dich auf alle Stellen, an denen sensible Daten gelesen, gespeichert oder offengelegt werden, und erfasse alles, was noch ein Weg nach draußen sein könnte. Behandle das als echten Vorfall, nicht als Übung. ``` --- ## 🚨 Zero-Trust-Audit Behandelt den gesamten Workspace und jede Abhängigkeit als feindlich: Es sucht nach Interpretern, Netzwerkaufrufen, codierten Payloads und Code, der an unwahrscheinlichen Stellen versteckt ist, um an Scannern vorbeizukommen, und endet mit einem Go/No-Go-Urteil darüber, ob das Projekt sicher genutzt werden kann. Die Prompts laden die Spezialisierungen, auf die sich dieses Audit stützt, unabhängig von den Kategorien deines Projekts direkt. Für die übrigen Spezialisierungen des Katalogs, die `/lagune` passend auswählt, stelle sicher, dass das Projekt **OWASP**, **KI / LLM** und die Kategorie seines Stacks nutzt (z. B. **JavaScript**, **Python** usw.): ```bash npx lagune write add --categories owasp ai javascript ``` **Gefahr** Sei vorsichtig, wenn du Projekte aus nicht vertrauenswürdigen Quellen in deiner lokalen Umgebung ausführst. Nutze eine isolierte Umgebung wie eine **Sandbox** (empfohlen), eine **VM** oder Ähnliches, damit bösartiger Code dein System nicht beeinträchtigt. **🪼 Standard** | Aspekt | Abwägung | Stufe | | ------------------- | -------------------------------------------------------------------------------------------------------------- | ------------------- | | **Aufwand** | Ein Agent durchsucht den gesamten Workspace, ohne Subagenten. | 2/5 | | **Zeit** | Mittel. Ein Agent arbeitet den Code und seine Abhängigkeiten nacheinander durch. | 3/5 | | **Token-Verbrauch** | Mäßig, aber geteilt. Spezialisierungen, Code und Abhängigkeiten werden alle in einen einzigen Kontext geladen. | 3/5 | ```md /lagune Du bist ein Cybersecurity-Forscher mit fundierter Erfahrung in defensiver Zero-Trust-Sicherheit und nutzt Lagune, um dein Wissen und deine Präzision zu verbessern. Betrachte den gesamten Workspace als nicht vertrauenswürdige Quelle und als potenziell bösartigen Bereich. Jeder Interpreter, jeder fetch, jedes base64 und Ähnliches muss als potenzielle Bedrohung behandelt werden. Weite deine Analyse auf die Abhängigkeiten und Unterabhängigkeiten aus: Ein Projekt kann versuchen, bösartigen Code an einer unwahrscheinlichen Stelle zu verstecken, um an Scannern vorbeizukommen. Verpflichtende Spezialisierungen (lade sie einzeln mit `npx lagune read catalog `): - interpreter - secrets - llm - path Um es klar zu sagen: Jede erfasste Schwachstelle muss ausnahmslos als potenzielle Bedrohung behandelt werden. Gib am Ende ein Urteil darüber ab, ob das Projekt sicher und vertrauenswürdig genug ist, damit ich es nutzen kann, oder nicht. ``` **🐋 Multi-Agent (gründlicher Durchlauf)** | Aspekt | Abwägung | Stufe | | ------------------- | ----------------------------------------------------------------------------------------------------------------- | ------------------- | | **Aufwand** | Ein Subagent pro Datei, abgestimmt auf die Größe deiner Codebasis. | 5/5 | | **Zeit** | Länger, aber gründlicher. Die Dateien werden parallel durchsucht und danach zu einem Urteil zusammengeführt. | 4/5 | | **Token-Verbrauch** | Am höchsten, aber am sichersten. Jeder Subagent liest die Spezialisierungen in seinem eigenen isolierten Kontext. | 5/5 | ````md /lagune Du bist ein Cybersecurity-Orchestrator und nutzt Lagune, um die Dateien aufzulisten, pro Datei einen Subagenten zu starten und Berichte zu erstellen (alle Inhalte lesen die Subagenten). Starte einen Subagenten pro Datei, alle parallel, und gib jedem den folgenden Prompt, eingegrenzt auf seine Datei: ```prompt /lagune Du bist ein Cybersecurity-Forscher mit fundierter Erfahrung in defensiver Zero-Trust-Sicherheit und nutzt Lagune, um dein Wissen und deine Präzision zu verbessern. Behandle als nicht vertrauenswürdige Quelle und als potenziell bösartigen Bereich. Jeder Interpreter, jeder fetch, jedes base64 und Ähnliches muss als potenzielle Bedrohung behandelt werden. Weite die Analyse auf alles aus, was importiert, einschließlich Abhängigkeiten und Unterabhängigkeiten, in denen sich bösartiger Code verstecken kann, um an Scannern vorbeizukommen. Verpflichtende Spezialisierungen für jeden Subagenten (lade sie einzeln mit `npx lagune read catalog `): - interpreter - secrets - llm - path Um es klar zu sagen: Jede erfasste Schwachstelle muss ausnahmslos als potenzielle Bedrohung behandelt werden. Gib am Ende ein Urteil darüber ab, ob das Projekt sicher und vertrauenswürdig genug ist, damit ich es nutzen kann, oder nicht. ``` Führe am Ende alle Berichte der Subagenten zu einem abschließenden Urteil zusammen. ```` --- # Security-Driven Hardening: eine Konvention für das Zeitalter der KI-gestützten Entwicklung > Die Methodik Security-Driven Hardening (SDH): eine kontextbezogene Blue-Team-Konvention für das Auditieren und Härten von Software, die mit KI-Unterstützung oder per Vibe Coding entsteht. Kanonische URL: https://lagune.ai/de-DE/docs/references/paper Sprache: de-DE Original: https://lagune.ai/docs/references/paper Zuletzt aktualisiert: 2026-11-03 - **Weslley Araújo** - **Methodenpapier, 2026.** --- ## Zusammenfassung Security-Driven Hardening (SDH) ist eine strukturierte, KI-gesteuerte und ausschließlich defensive Sicherheitsmethodik für eine Zeit, in der Software zunehmend von KI-Agenten und von Menschen geschrieben wird, die keine Sicherheitsfachleute sind. Statt eine generische Checkliste abzuarbeiten, erkennt SDH zuerst, was ein System tatsächlich tut (Anmeldung, Datei-Uploads, Zahlungen, Offenlegung von Daten und so weiter), und steuert dann die Sicherheitsarbeit, die genau zu diesem Kontext passt. Standardmäßig sichere Prinzipien geben den Rahmen vor, die Methodik ist vollständig auf Verteidigung ausgerichtet und in verständlicher Sprache formuliert, damit jeder Nutzer danach handeln kann. Dieses Dokument vertritt die These, dass SDH eine fehlende Konvention ist, kein einzelnes Werkzeug. Das Sicherheitswissen steckt in der Methodik und ihren bei Bedarf geladenen Spezialisierungen, einer Grundlage, auf der jeder Nutzer aufbauen kann, und so dient derselbe Workflow einem Einsteiger wie einem Experten. Zwei Eigenschaften unterscheiden SDH von früheren Spec-first-Ansätzen `[1]`. SDH ist **zustandsunabhängig**: Es passt sich an ein leeres Verzeichnis, ein laufendes Projekt, einen einzelnen Pull Request oder eine große Legacy-Codebasis an, in jedem Stack. Und SDH ist **abschließbar**: Ein als geschlossen verifiziertes Risiko wird aus dem gesamten Workflow ausgetragen, sodass dieser Befund in den Ruhezustand übergeht und erst wieder geöffnet wird, wenn sich der Code ändert. SDH ersetzt weder Sicherheitsfachleute noch spezialisierte Blue-Team-Werkzeuge. Es erweitert das Wissen der Entwickler selbst, und je mehr ein Entwickler von Sicherheit versteht, desto mehr kann er es steuern. **Lagune** ist die Referenzimplementierung und belegt, dass sich die Methodik umsetzen und übertragen lässt. SDH versteht sich als Konvention, die andere übernehmen können. > **Schlagwörter** > > KI-gestützte Entwicklung, Softwaresicherheit, defensive Sicherheit, spec-driven development, Security Hardening, agentengesteuerte Workflows, Abschließbarkeit, kontextbezogene Sicherheit, Wissen bei Bedarf, agentenunabhängige Werkzeuge. --- ## I. Einleitung: die Sicherheitslücke, die KI-gestützte Entwicklung geöffnet hat Immer mehr Software stammt von Menschen, und von KI-Agenten, die ein unsicheres Muster nicht zuverlässig erkennen: ein geleaktes Secret, eine fehlende Autorisierungsprüfung, eine für Injection anfällige Abfrage. Das sind keine exotischen Risiken. Sie gehören zu den Risikoklassen, die reale Vorfälle dominieren und seit Jahren in öffentlichen Referenzen dokumentiert sind `[6]`, `[7]`, und aktuelle Studien zeigen, dass ein nennenswerter Anteil des KI-generierten Codes genau mit solchen Mängeln ausgeliefert wird `[8]`. KI-Programmierassistenten haben das verschärft, weil sie auch Nicht-Entwicklern ermöglichen, echte Software auszuliefern, doch die Lücke reicht über jede einzelne Zielgruppe hinaus. Die meisten Projekte bekommen nie eine Sicherheitsprüfung, die auf das zugeschnitten ist, was sie tatsächlich tun. Mit jeder vorschnellen Entscheidung nach dem Motto "läuft, raus damit" wird das Ökosystem fragiler. Generische Sicherheitsratschläge schließen diese Lücke nicht. Eine statische Checkliste ist nicht auf das zugeschnitten, was ein System tut, deshalb überschwemmt sie ein kleines Projekt mit irrelevanten Punkten und übersieht trotzdem das Risiko, auf das es bei genau diesem Projekt ankommt. Das Problem ist nicht, dass es auf der Welt zu wenig Sicherheitswissen gäbe. Das Problem ist, das passende Wissen dem System zuzuordnen, das tatsächlich vor dem Nutzer liegt, und das für jemanden, der vielleicht nicht weiß, wonach er fragen soll. SDH antwortet darauf mit einer einzigen Umkehrung: **Das Sicherheitswissen steckt in der Spezifikation und ihren bei Bedarf geladenen Spezialisierungen, einer Grundlage, auf der jeder Nutzer aufbauen kann**. Die Methodik erkennt den Kontext, priorisiert die Risiken, die dieser Kontext mit sich bringt, und leitet die Korrekturen an, sodass Entwickler und Nicht-Entwickler denselben Workflow nutzen. Befunde und Empfehlungen bleiben in verständlicher Sprache, damit man unabhängig vom technischen Vorwissen danach handeln kann. Den Experten schränkt das nicht ein, sondern verstärkt ihn, eine Dualität, die wir in `§VI` ausführen. > **Kernaussage** > > **Die zentrale Umkehrung:** Das Sicherheitswissen steckt in der Spezifikation und ihren bei Bedarf geladenen Spezialisierungen, einer Grundlage, auf der jeder Nutzer aufbauen kann. Die Methodik lernt, was das System tut, stimmt die Sicherheitsarbeit darauf ab und erweitert, was der Nutzer bereits weiß. Angenommen, ein Entwickler sagt zu einem KI-Assistenten: "Meine App lässt Nutzer ein Profilbild hochladen." Ohne Sicherheitsprüfung liefert der Assistent funktionierenden Code, der stillschweigend allem vertraut, was der Client schickt: dem angegebenen Dateityp, dem Dateinamen, der Größe. Der Upload geht live, und eine als Bild getarnte Datei kann Code enthalten, ein manipulierter Name kann aus dem Speicherpfad ausbrechen, eine übergroße Datei kann den Server lahmlegen. Nichts davon ist in einer Demo zu sehen, also wird es ausgeliefert. Derselbe Code verhält sich mit SDH anders. SDH erkennt, dass das System Dateien von außen annimmt (Erkennung), leitet daraus die Risiken ab, die ein Upload mit sich bringt (Triage), schlägt vor, den echten Dateityp und die Größe zu prüfen, die Datei beim Speichern umzubenennen und sie dort abzulegen, wo kein Code ausgeführt werden kann (Behebung), liest dann das Ergebnis und bestätigt, dass jede Schutzmaßnahme tatsächlich greift (Verifizierung). Der Entwickler musste den Begriff "uneingeschränkter Datei-Upload" nie kennen. Die Methodik hat ihn an seiner Stelle eingebracht. Dieses Dokument leistet folgende Beiträge: - Eine präzise Definition von SDH als Methodik, unabhängig von einer bestimmten Implementierung, samt ihren Gestaltungsprinzipien (`§III`). - Ein defensiver Lebenszyklus in fünf Phasen, in dem die Aufgabentrennung selbst der Beitrag ist: Die Erkennung erfindet nie etwas, die Planung liest nie Code, nur eine Phase ändert Code, und die Verifizierung schwächt ihr Urteil nie ab (`§IV`). - **Abschließbarkeit** als methodische Haltung: Ein einzelner Befund hat einen Endzustand statt einer Endlosschleife (`§V`). - Die Dualität als **Erweiterung des Entwicklerwissens**: ein Workflow, der den Einsteiger schützt und den Experten verstärkt (`§VI`). - **Nicht aufrufbare Spezialisierungen und Prompt bei Bedarf**: fokussiertes Sicherheitswissen, das der Agent lädt, wenn der Kontext des Projekts es verlangt, nie standardmäßig (`§VII`). - **Zustandsunabhängigkeit** und **nicht vorschreibende Anpassungsfähigkeit**: SDH passt in jeden Entwicklungsstand und richtet sich nach dem Szenario, statt einen festen Umfang vorzugeben (`§VIII`). - Ein **präventiver Modus**: dieselbe Verteidigung, während die alltägliche Arbeit entsteht, sodass der Code von Anfang an standardmäßig sicher ist und die Phasen weniger korrigieren müssen (`§IX`). - Ein eigener Vergleich mit Spec-Driven Development, der Linie, aus der SDH hervorgegangen ist und von der es sich dann gelöst hat (`§X`). - Die technischen Disziplinen, mit denen die Methodik Refactorings übersteht und von jedem Agenten unabhängig bleibt: Nachverfolgung mit Identität über den Namen (`§XI`) und ein agentenunabhängiger Träger (`§XII`). --- ## II. Hintergrund und verwandte Arbeiten SDH baut auf früheren Arbeiten auf. Es übernimmt eine bewährte Struktur aus der agentengesteuerten Spec-first-Entwicklung `[1]`, `[2]`, `[3]`: Vorlagen, Slash-Befehle, die ein Agent verarbeitet, ein übergeordnetes Dokument und einen Agenten, der die Phasen ausführt. Diese Struktur setzt es mit defensivem Zweck neu um. Die Herkunft ist gewollt, und eines der Arbeitsprinzipien von SDH benennt sie direkt: den Workflow auf einer bewährten Struktur aufbauen und ihn dann auf Sicherheit ausrichten. SDH ist keine statische Checkliste generischer Empfehlungen. Eine Checkliste weiß viel über Sicherheit im Allgemeinen und nichts über das Projekt vor ihr. SDH kehrt diese Gewichtung um. Es steckt seinen ersten Aufwand in die Erkennung, also darin, zu lernen, was das System tut, und greift erst dann zu dem Wissen, das durch die Erkennung relevant wird. SDH ersetzt auch keine Sicherheitsfachleute und keine spezialisierten Blue-Team-Werkzeuge. Es erweitert das Wissen der Entwickler (`§VI`). Ein Team mit eigener Sicherheitsabteilung sollte sie behalten. SDH gibt diesem Team einen strukturierten Träger, und einem Team ohne eine solche Abteilung eine belastbare Grundlage. SDH steht außerdem neben deterministischen Sicherheitsscannern (statische Analyse, Linter) `[4]`, `[5]`. Diese Werkzeuge sind gerade deshalb wertvoll, weil sie deterministisch und wiederholbar sind. SDH beruht überwiegend auf dem Schlussfolgern des Agenten und tauscht strengen Determinismus gegen Kontextbezug. Die Methodik gibt auch nicht vor, es wäre anders. Wo Determinismus zählt, bettet sie eine deterministische Engine in das Schlussfolgern ein (`§VII`): Der Agent entscheidet, ob es sich lohnt, eine Eingabe zu prüfen, und ein deterministisches Programm entscheidet, ob diese Eingabe gefährlich ist. Der direkteste Vorläufer ist Spec-Driven Development (SDD), die Familie der Spec-first-Methodiken, die eine Entwicklung von einer ausführbaren Spezifikation aus vorantreibt. Wir behandeln SDD als Klasse. Seine klarste Darstellung als Praxismethodik ist der Bericht von Piskala `[1]`, sein sichtbarstes agentengesteuertes Toolkit ist Spec Kit von GitHub `[2]`, und OpenSpec `[3]` ist ein zweites Werkzeug aus derselben Familie. Damit sind die maßgeblichen Referenzen für den Vergleich in `§X` benannt. --- ## III. SDH: Definition und Gestaltungsprinzipien **Security-Driven Hardening** ist eine strukturierte, KI-gesteuerte Sicherheitsmethodik, die eine Codebasis sicherer macht, indem sie die Arbeit von einer Spezifikation aus steuert, die der Agent ausführt, statt von spontanen Korrekturen. Der Name ist von den **Blue Teams** inspiriert, den Verteidigern im Sicherheitsbereich. Bei SDH geht es um Verteidigung, Härtung und Verifizierung, nie um Angriff. > **Definition** > > **Security-Driven Hardening (SDH):** Eine strukturierte, KI-gesteuerte, ausschließlich defensive Sicherheitsmethodik, die zuerst erkennt, was ein System tatsächlich tut, und dann die kontextspezifische Sicherheitsarbeit steuert, bestimmt von standardmäßig sicheren Prinzipien und in verständlicher Sprache formuliert. SDH wird durch eine Reihe verbindlicher Prinzipien definiert. Jedes ist eine Regel, und jedes gibt dem Nutzer eine bestimmte Garantie. | Prinzip | Die Regel | Was es dem Nutzer garantiert | | ----------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Standardmäßig sicher, in verständlicher Sprache, für alle gleichermaßen | Jeder Standardwert, jede Meldung und jede Korrektur ist von Haus aus sicher und für jeden Leser verständlich, ob Entwickler oder nicht. Keine Nutzergruppe wird bevorzugt. | Ein Einsteiger erhält eine sichere Grundlage, ohne danach zu fragen, und versteht das Ergebnis in seinen eigenen Worten. | | Kontextbezogen statt generisch | Jede Phase geht vom Kontext aus, den detect erkannt hat, und arbeitet mit dem, was das System tatsächlich tut. | Die Empfehlungen passen zum Projekt, nicht zu einer Checkliste. Das Sicherheitswissen steckt in der Spezifikation und ihren bei Bedarf geladenen Spezialisierungen und erweitert, was der Nutzer mitbringt. | | Flexibel statt starr | Prinzipien, Anforderungen und Empfehlungen sind Ausgangspunkte. Der Nutzer kann alles umformulieren, streichen, ergänzen oder eingrenzen. | Die Methodik passt sich dem Projekt und dem Nutzer an und ist nie strenger, als der Nutzer es will. Flexibilität schwächt nie die standardmäßig sichere Grundlage. | | Abgleichen statt nur anhängen | Artefakte sind lebendige Dokumente, keine Logs. Jeder Lauf prüft jeden Eintrag neu: behalten, was noch gilt, umschreiben, was sich geändert hat, entfernen, was nicht mehr zutrifft. | Die Aufzeichnungen spiegeln immer die Gegenwart wider und verkommen so nie zu einem veralteten Backlog. | | Ausschließlich defensiv | SDH auditiert, härtet und verifiziert. Es erzeugt nie offensive Werkzeuge, Exploits für böswillige Zwecke oder Techniken zur Umgehung von Erkennung, um Schaden anzurichten. | Die Methodik lässt sich nicht als Waffe einsetzen. Dual-Use-Inhalte erscheinen nur in einem klar defensiven Rahmen. | | Spec-first, agentengesteuert, auf Sicherheit ausgerichtet | Der Workflow besteht aus Vorlagen, Befehlen, übergeordneten Sicherheitsprinzipien und einem Agenten, der die Phasen ausführt. | Eine bewährte Entwicklungsstruktur, so umgewidmet, dass der Agent die eigentliche Sicherheitsarbeit leistet. | **Tabelle 1.** Die Gestaltungsprinzipien von SDH und die Garantie, die jedes dem Nutzer gibt. Diese Prinzipien sind keine Zierde. Sie sind die Vorgaben, die jede der folgenden Phasen einhalten muss, und die Diskussion in `§XV` greift sie wieder auf, um die Grenzen der Methodik abzustecken. Der Rest des Dokuments entwickelt neun benannte Säulen. Sie sind die Teile, die ein Leser im Kopf behalten können sollte, und die Teile, die ein anderes Team neu umsetzen würde, um zu behaupten, es betreibe SDH. | Säule | Was sie leistet | Abschnitt | | ------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- | | Die kontextbezogene Umkehrung | Das Sicherheitswissen steckt in der Spezifikation und ihren bei Bedarf geladenen Spezialisierungen, sodass Einsteiger und Experte einen Workflow teilen. | `§I`, `§VI` | | Der defensive Lebenszyklus in fünf Phasen | Aufgabentrennung: Richtlinie, Erkennung, Triage, Behebung, Verifizierung, jede mit genau einer Aufgabe. | `§IV` | | Abschließbarkeit | Ein Befund hat einen Endzustand statt einer Endlosschleife. Abgeschlossene Arbeit wird ausgetragen. | `§V` | | Die Dualität als Erweiterung des Entwicklerwissens | Ein Workflow, der den Einsteiger schützt und den Experten verstärkt, ohne einen von beiden zu ersetzen. | `§VI` | | Prompt bei Bedarf, nicht aufrufbares Wissen | Relevantes Sicherheitswissen wird für das geladen, was das Projekt ist, nie standardmäßig. | `§VII` | | Zustandsunabhängigkeit und nicht vorschreibende Anpassungsfähigkeit | Passt in jeden Entwicklungsstand und jeden Stack und richtet sich nach dem Szenario, statt einen Umfang vorzugeben. | `§VIII` | | Der präventive Modus | Dieselbe Verteidigung läuft mit, während neue Arbeit entsteht, sodass der Code von Anfang an standardmäßig sicher ist. | `§IX` | | Nachverfolgung mit Identität über den Namen | Ein Befund bleibt über alle Phasen hinweg ein Eintrag, und eine Umbenennung unterbricht die Verknüpfung nur an einer Stelle. | `§XI` | | Der agentenunabhängige Träger | Der Sicherheitskern wird einmal geschrieben und hängt von keinem Agenten und keinem Stack ab. | `§XII` | **Tabelle 2.** Die neun benannten Säulen von SDH und wo jede ausgeführt wird. --- ## IV. Der Blue-Team-Workflow in 5 Phasen SDH gliedert die Arbeit in einen defensiven Lebenszyklus aus fünf Phasen (Abbildung 1). Jede Phase ist auf Verteidigung ausgerichtet, jede baut auf der vorherigen auf, und die Phasen folgen der echten Arbeit eines Blue Teams: Richtlinie festlegen, erkennen, triagieren, beheben, verifizieren. ```mermaid flowchart TB charter["1 · charter (Richtlinie)
liest: das Projekt und, falls vorhanden, die Beschreibung des Nutzers
schreibt: die Sicherheitsprinzipien
jedes Prinzip nennt in verständlicher Sprache das Risiko, das es verhindert"] detect["2 · detect (Erkennung)
liest: den Code des Nutzers
schreibt: die Bestandsaufnahme
Erkennen, nicht erfinden: nur festhalten, was der Code belegt"] plan["3 · plan (Triage)
liest: die Bestandsaufnahme, nie den Code
schreibt: den Abwehrplan
jede Korrektur verweist auf etwas, das detect tatsächlich erfasst hat"] harden["4 · harden (Behebung)
liest: den Abwehrplan und den Code, den er betrifft
schreibt: den Code und das Härtungsprotokoll
die einzige Phase, die Code ändert, eine Korrektur nach der anderen, die kleinste Änderung, die greift"] verify["5 · verify (Verifizierung)
liest: den Code und das Härtungsprotokoll
schreibt: jedes offene Urteil ins Härtungsprotokoll
die Gegenüberstellung von Code und Protokoll, statisch, nie abgeschwächt"] charter --> detect --> plan --> harden --> verify verify -.->|"nicht bestanden: wieder offene Arbeit für harden,
erneut umgesetzt anhand der festgehaltenen Begründung"| harden verify -.->|"Abschluss: was als geschlossen nachgewiesen ist,
wird aus der gesamten Kette ausgetragen,
eine Zeile in der Historie"| detect ``` **Abbildung 1.** Der Workflow in fünf Phasen: was jede Phase liest, was sie schreibt und ihre tragende Invariante. Verify steuert beide Rückwege: Eine nicht bestandene Schutzmaßnahme öffnet harden erneut, und ein als geschlossen nachgewiesener Befund wird aus der Kette ausgetragen, mit einer Zeile in der Historie. Die Aufgabentrennung ist der Beitrag. Weil jede Phase genau eine Aufgabe hat, bleibt ein Fehler auf eine Stelle beschränkt, und der Leser kann sich auf das verlassen, was jedes Artefakt aussagt. > **Kernaussage** > > **Applied heißt nicht verifiziert:** Harden hält fest, dass eine Korrektur umgesetzt wurde. Verify prüft das nach und stellt dafür den Code diesem Protokoll gegenüber, und das Urteil wird nie abgeschwächt, damit es zum Protokoll passt. Eine Schutzmaßnahme kann im Code vorhanden sein und das Risiko trotzdem erreichbar lassen, und dann lautet das ehrliche Urteil "Risk not closed". ### charter (Richtlinie) Die Phase charter legt die Sicherheitsprinzipien des Projekts fest, die Regeln, die jede spätere Phase einhalten muss. Sie ist die übergeordnete Ebene, eine Art Prüfung zur Kompilierzeit für das Sicherheitsniveau des Projekts. Jedes Prinzip hat einen klaren Namen, eine unverhandelbare Regel, die sich am Code überprüfen lässt, und eine Zeile `Why:`, die das Risiko nennt, das es verhindert, nicht nur die Korrektur. Die Phase liest immer das Projekt selbst (seine Manifeste, seine Struktur und seine Abhängigkeiten), und eine Beschreibung des Nutzers gibt, falls vorhanden, eine Richtung vor, die das Lesen dann über das Genannte hinaus erweitert. Ohne Beschreibung ist das Projekt die einzige Quelle. Beides ergänzt sich, statt zu konkurrieren, und die Sicherheitsprinzipien halten die Richtlinie fest, an die sich das Projekt halten soll, nicht den Zustand seines Codes. Auch wer nicht entwickelt, sollte sie lesen und sowohl die Regel als auch das Risiko verstehen können. ### detect (Erkennung) Detect liest den Code und erfasst, was das System tatsächlich tut und was dabei sicherheitsrelevant ist. Die leitende Anweisung lautet "Erkennen, nicht erfinden": nur festhalten, was der Code belegt, mit den Belegen, die spätere Phasen brauchen. Detect ist neutral. Die Phase zwingt ihre Befunde nicht in die Sicherheitsprinzipien, denn Risiken an deren Regeln zu messen, ist Aufgabe der Phase plan. Jeder Befund besteht aus drei Teilen: was er ist (eine Beschreibung in verständlicher Sprache), warum er wichtig ist (das Risiko, nicht nur die Tatsache) und der Beleg (die Funktion oder Route, in der er steckt). Der Beleg enthält keinen Dateipfad. Der Pfad steht nur in der Tracking-Map (`§XI`), sodass der Text nie einen Pfad enthält, der veralten kann. ### plan (Triage) Plan macht aus jedem Befund eine Korrektur, benannt nach ihrer Risikoklasse (mit Verweis auf die etablierten Referenzen CWE und OWASP, wo diese sie begründen) und an das Sicherheitsprinzip gebunden, das die Korrektur wahrt. Die Priorität (kritisch, hoch, mittel, niedrig) ist keine freie Wahl: plan bewertet jeden Befund nach CVSS v4.0 mit Base- und Environmental-Metriken, sodass die Stufe den Score in einfachen Worten ausdrückt, begründet mit einer verständlichen Zeile zu Exposition und Tragweite, und zwei Läufe ergeben dieselbe Reihenfolge. Der Vektor ist der präzise Anker für Experten, die Stufe mit ihrer Begründung dieselbe Bewertung in einer Form, der jeder folgen kann. Plan arbeitet nur mit der Bestandsaufnahme von detect und liest nie den Code. Das ist eine bewusste Vorgabe, keine Schwäche: Sie zwingt jede Korrektur, auf etwas zu verweisen, das detect tatsächlich erkannt hat. Wurde ein Bereich nie erfasst, hält plan an und schickt den Nutzer zurück zu detect, statt zu raten. ### harden (Behebung) Harden ist die einzige Phase, die Code ändert, deshalb geht sie mit Vorsicht vor. Ob eine Änderung die Zustimmung des Nutzers braucht, entscheiden der Agent und der Berechtigungsmodus, in dem er läuft, daher fügt harden keinen eigenen Bestätigungsschritt hinzu. Die Phase setzt eine Korrektur nach der anderen um, zuerst die Abhängigkeiten, dann die höchste Priorität, damit jede Änderung klein, überprüfbar und leicht rückgängig zu machen bleibt. Sie schwächt nie eine bestehende Schutzmaßnahme ab, damit eine neue Korrektur passt, und sie verletzt nie eines der Sicherheitsprinzipien. Würde eine Korrektur einem Prinzip widersprechen, hält harden an und zeigt den Konflikt auf, statt die Korrektur umzusetzen. Jeder Block wird als Applied, Partial oder Blocked festgehalten. "Applied heißt noch nicht verifiziert", und darum kümmert sich die nächste Phase. ### verify (Verifizierung) Verify liest den Code und stellt ihn dem gegenüber, was harden festgehalten hat, um jede umgesetzte Schutzmaßnahme zu prüfen. Die Verifizierung ist genau diese Gegenüberstellung, Code gegen Protokoll, und sie ist statisch: Sie bestätigt, dass eine Schutzmaßnahme im Code vorhanden und korrekt ist, nicht dass sie auf einem laufenden System einem Angriff standhält. Diese Prüfung zur Laufzeit, also die Art, die echte oder simulierte Angriffe gegen das laufende System ausführt, liegt bewusst außerhalb des Umfangs. Verify liefert eines von drei Urteilen: Risk closed, Risk not closed oder Cannot tell from the code. Die Phase erzeugt kein eigenes Artefakt: harden und verify teilen sich das Härtungsprotokoll, wobei harden verantwortet, was getan wurde, und verify das Urteil samt Begründung, und keine der beiden schreibt je in die Felder der anderen. Eine nicht bestandene Schutzmaßnahme ist wieder offene Arbeit für harden, deren nächster Lauf das Urteil über die eigene Lesart des Codes stellt und die Korrektur genau an der Lücke, die die Begründung benennt, erneut umsetzt. Verify traut dem Code mehr als dem Protokoll, denn ein Protokoll kann mehr behaupten, als der Code leistet. Auf den Code des Nutzers greift die Phase nur lesend zu, und sie schwächt ein Urteil nie ab, damit es zum Protokoll passt. Eine Schutzmaßnahme kann vorhanden sein und das Risiko auf anderem Weg trotzdem erreichbar lassen, und dann lautet das ehrliche Urteil "Risk not closed". Bemerkt verify beim Lesen ein Sicherheitsproblem, das die Bestandsaufnahme von detect nie abgedeckt hat, erfindet sie dafür kein Urteil, denn das Erkennen ist Aufgabe von detect: Sie meldet das Problem und schickt den Nutzer zurück zu detect, damit der Befund über denselben Workflow hereinkommt, statt ihn zu umgehen. > **Durchgehendes Beispiel: Datei-Uploads.** Ein einzelner Befund zeigt das Rückgrat des Workflows von Anfang bis Ende. > > - **detect** findet ihn: Das System nimmt Dateien von Nutzern an, und der Upload-Handler vertraut dem MIME-Typ, den der Client schickt, ohne den echten Typ der Datei zu prüfen. _Warum das wichtig ist:_ Eine als Bild getarnte Datei kann Schadcode verbergen. > - **plan** legt die Korrektur fest, Priorität **kritisch**, zur Wahrung des Prinzips "Jede Eingabe gilt als nicht vertrauenswürdig, bis sie validiert ist": den echten Typ und die Größe der Datei prüfen, sie beim Speichern umbenennen und Uploads dort ablegen, wo sie nicht als Code ausgeführt werden können. > - **harden** setzt sie um, Status **Applied**: Der Handler erkennt den echten Typ jetzt am Inhalt, erzwingt ein Größenlimit, lehnt alles Unerwartete ab, benennt beim Speichern um und legt die Dateien dort ab, wo kein Code ausgeführt werden kann. > - **verify** liest den Handler, stellt ihn dem Protokoll gegenüber und liefert **Risk closed**: Der Code tut genau das, was das Protokoll behauptet. > > Derselbe Befundname zieht sich durch die Bestandsaufnahme von detect, den Abwehrplan und das Härtungsprotokoll, und verify arbeitet unter demselben Namen mit diesem Protokoll: Ein offenes Urteil wird in den Block des Befunds geschrieben, und ein als geschlossen nachgewiesener Befund wird ausgetragen (`§V`). Dieser gemeinsame Name ist seine Identität (`§XI`). --- ## V. Abschließbarkeit: Ein Befund hat einen Endzustand Die meisten Sicherheitswerkzeuge hinterlassen beim Nutzer einen Backlog, der nur wächst. SDH vertritt eine andere Position: **Ein Befund ist abschließbar, er hat also einen Endzustand, statt in einem endlosen Backlog zu leben** (Abbildung 2). Das folgt direkt aus dem Prinzip des Abgleichs. > **Definition** > > **Abschließbarkeit:** Ein als geschlossen verifiziertes Risiko wird aus dem gesamten Workflow ausgetragen, sodass dieser Befund in den Ruhezustand übergeht und erst wieder geöffnet wird, wenn sich der Code ändert. Ein Befund hat einen Endzustand, auch wenn das Sicherheitsprogramm selbst fortlaufend bleibt. Die Artefakte von SDH sind lebendige Dokumente, keine Logs. Bei jedem erneuten Lauf gleicht eine Phase jeden vorhandenen Eintrag mit dem aktuellen Stand ab und tut eines von drei Dingen: Sie behält, was noch gilt, schreibt um, was sich geändert hat, oder entfernt, was nicht mehr zutrifft. Ein Befund, den der Code inzwischen als behoben ausweist, wird einfach entfernt. Der Arbeitsstand spiegelt die Gegenwart wider, nicht die Vergangenheit. Der Abschluss ist derselbe Abgleich, an seinem Ende angekommen. Bestätigt verify, dass ein Risiko geschlossen ist, trägt sie den Befund aus dem gesamten Workflow aus: aus der Bestandsaufnahme von detect, dem Abwehrplan, dem Härtungsprotokoll und der Tracking-Map. Deshalb ist verify die eine Phase, die in die Artefakte der anderen Phasen schreibt: Sie ist die Phase, die den Kreis schließt. Wenn der Befund die Kette verlässt, verdichtet ihn das Austragen zu einem kurzen Eintrag in einer Historie, die außerhalb der Arbeitskette liegt und nie erneut verarbeitet wird. Das ist die Grenze zwischen Verschwinden und Abschließen: Ein Befund, den der Abgleich entfernt hat, weil er nicht mehr zutraf, hinterlässt nichts, während sich ein als geschlossen nachgewiesener Befund seine Zeile in der Historie verdient. Ein ausgetragener Befund fehlt danach in jedem Arbeitsartefakt, und dieses Fehlen ist erwartet, keine unterbrochene Kette. ```mermaid stateDiagram-v2 direction TB [*] --> OPEN: detect erkennt OPEN --> Plan: plan Plan --> Harden: harden Harden --> Verify: verify Verify --> StoodDown: Risk closed StoodDown --> SETTLED SETTLED --> OPEN: Codeänderungen öffnen einen Befund erneut Plan: plan Harden: harden Verify: verify StoodDown: STOOD DOWN · eine Zeile in der Historie ``` **Abbildung 2.** Der Zustandsautomat der Abschließbarkeit. Ein Befund durchläuft OPEN → STOOD DOWN → SETTLED und wird erst wieder geöffnet, wenn sich der Code ändert. Ist alles im Umfang ausgetragen, ist der Zyklus im Ruhezustand, und dieser Ruhezustand hat eine konkrete Form: Ein Artefakt, dessen letzter Befund abgeschlossen wurde, wird ganz entfernt, sodass eine vollständig abgeschlossene Kette nur die Sicherheitsprinzipien und die Historie übrig lässt, die Richtlinie und den Nachweis. Der Zyklus wird erst wieder geöffnet, wenn sich der Code ändert. Die Methodik gibt jedem Befund ein klares Ende, und genau das kann ein endloser Backlog nicht. --- ## VI. Die Dualität als Erweiterung des Entwicklerwissens SDH ersetzt keine Menschen und keine spezialisierten Blue-Team-Werkzeuge. Es **erweitert das Wissen der Entwickler selbst**. Je mehr ein Entwickler von Sicherheit versteht, desto präziser kann er den Workflow steuern und desto mehr Autonomie hat er. Ein Entwickler, der wenig davon versteht, erhält trotzdem ein sicheres Ergebnis, weil der automatische Modus ihn absichert. Die Umkehrung aus `§I`, nach der das Sicherheitswissen in der Spezifikation steckt, wirkt in beide Richtungen. Für den Einsteiger ist sie Schutz: Er muss nicht wissen, wonach er fragen soll, weil die Spezifikation Vorschläge macht. Für den Experten ist sie Verstärkung: Dieselbe Spezifikation erlaubt ihm, den Workflow präzise auszurichten, statt gegen eine starre Checkliste anzuarbeiten. Jede Phase trägt diese Dualität in ihrer eigenen Arbeitsweise (Abbildung 3). Ohne Eingabe gestartet, arbeitet sie im Namen des Nutzers im gesamten Umfang. Mit einer Vorgabe beschränkt sich dieselbe Phase genau auf das, worauf der Nutzer sie richtet. ```mermaid flowchart TB inversion["eine Umkehrung, zwei Richtungen:
das Sicherheitswissen steckt in der Spezifikation"] inversion --> auto["automatischer Modus (ohne Eingabe)
die Phase schlägt vor und handelt
im gesamten Umfang"] inversion --> directed["gezielter Modus (mit Eingabe)
die Phase beschränkt sich genau
auf das, worauf der Nutzer sie richtet"] auto --> novice["der Einsteiger, geschützt:
ein sicheres Ergebnis, ohne
zu wissen, wonach er fragen soll"] directed --> expert["der Experte, verstärkt:
der Workflow präzise ausgerichtet,
keine starre Checkliste"] novice -.-> phases["dieselben fünf Phasen dienen beiden:
charter · detect · plan · harden · verify"] expert -.-> phases ``` **Abbildung 3.** Die Dualität als Erweiterung des Entwicklerwissens. Eine Umkehrung dient zwei Zielgruppen: Der automatische Modus schützt den Einsteiger, und der gezielte Modus verstärkt den Experten, mit denselben fünf Phasen. Die bei Bedarf geladenen Spezialisierungen (`§VII`) machen die Dualität in ihrem eigenen Text ausdrücklich. Jede sagt dem Agenten, dass ihr Wissen "dein Urteilsvermögen erweitert" und dass er über das hinaus weiterdenken soll, was die Spezialisierung liefert. Das Wissen ist eine Untergrenze, keine Obergrenze. Genau das dient beiden Zielgruppen in der Balance, die das Dokument anstrebt: Die Entwickler-Community erhält ein substanzielles Werkzeug, und wer im Blue Team arbeitet, erhält einen strukturierten Träger, der nicht vorgibt, ihm die Arbeit abzunehmen. --- ## VII. Nicht aufrufbare Spezialisierungen und Prompt bei Bedarf Dies ist das neuartigste Muster der Methodik. SDH bringt fokussiertes Sicherheitswissen als Spezialisierungen mit, die **nur bei Bedarf** laden, und der Agent selbst entscheidet, welche er lädt, indem er sie mit dem Kontext des Projekts abgleicht. Wir nennen das **Prompt bei Bedarf**: eine Möglichkeit für den Agenten, anhand des Umfangs des Projekts, in dem er sich befindet, zu wählen, welches Wissen er aktiviert, statt jede Prüfung standardmäßig auszuführen. Die Spezialisierungen entwickeln sich weiter, und jede von ihnen kann sich jederzeit ändern oder ersetzt werden. Der Beitrag ist das Muster, nicht die Spezialisierungen selbst. > **Definition** > > **Prompt bei Bedarf:** Der Agent wählt aus, welches Sicherheitswissen er aktiviert, indem er es mit dem Umfang des Projekts vor ihm abgleicht, sodass das relevante Wissen für das herangezogen wird, was das Projekt tatsächlich ist, statt jede Prüfung standardmäßig auszuführen. > **Definition** > > **Nicht aufrufbare Spezialisierung:** Eine fokussierte, sprachunabhängige Einheit von Sicherheitswissen für einen Kontext, etwa Datei-Uploads oder Code, der im Browser läuft. Sie auditiert und erklärt, schreibt nie Code um und erzeugt nie eine Angriffseingabe. Sie ist kein Befehl: Sie lädt, wenn der Kontext, den sie abdeckt, im Umfang liegt, oder wenn ein Prompt sie beim Namen anfordert. Jede Spezialisierung benennt die sichereren Formen für die Risiken, die sie abdeckt, und sagt dem Agenten, wie er in jeder Phase, die sie nutzt, mit einem Befund umgeht: wie er ihn bei der Erkennung beurteilt, wie er die Korrektur bei der Behebung sicher umsetzt und wie er sie bei der Verifizierung nachweist. Das prägende Merkmal ist, dass eine Spezialisierung **nicht eigenständig aufrufbar** ist: Sie ist kein Befehl, und innerhalb des Workflows lädt sie nur ein Treffer. Die Erkennungsphase listet den Katalog einmal auf, gleicht den Kontext des Projekts mit dem ab, was jeder Eintrag abdeckt, und lädt nur die Spezialisierungen, deren Kontext im Umfang vorhanden ist. Die späteren Phasen verwenden diese Trefferliste wieder, statt erneut aufzulisten, sodass ein einziger Abgleich der gesamten Kette dient, und der präventive Modus (`§IX`) führt denselben Abgleich mit der Arbeit durch, die gleich entstehen soll. Eine Spezialisierung, deren Kontext fehlt, wird übersprungen, und das Überspringen wird genauso begründet wie das Laden: Jeder Eintrag im Katalog erhält ein ausdrückliches Urteil, angewendet oder übersprungen, mit der aus dem Code abgelesenen Begründung, sodass ein vages Gefühl von Irrelevanz nie an die Stelle tatsächlichen Fehlens tritt. Keine passende zu finden, ist ein gültiges Ergebnis. Der Katalog besteht aus Daten, und Wachstum bedeutet eine Wissensdatei plus eine Katalogzeile, nie einen neuen Befehl. Die integrierten Spezialisierungen sind in Kategorien gruppiert, etwa OWASP, eine Programmiersprache oder KI-Integrationen, und der Katalog, den ein Projekt nutzt, enthält die integrierten Spezialisierungen der Kategorien, die es gewählt hat, plus seine eigenen Spezialisierungen. Das Projekt hält diese Wahl zusammen mit dem Rest seines Zustands fest, sodass ein ganzes Team mit demselben Katalog abgleicht. Das ist dasselbe kontextbezogene Prinzip wie bei den Phasen, angewandt auf Wissen: Das relevante Wissen wird für das herangezogen, was das Projekt tatsächlich ist, statt jede Prüfung standardmäßig auszuführen. Dieselbe Eigenschaft erlaubt es dem Nutzer, nicht nur dem Maintainer, den Katalog zu erweitern: Eine Sicherheitsquelle oder ein Thema, das der Nutzer einbringt, wird zu einer neuen Spezialisierung verdichtet, die dem Projekt gehört, unabhängig von den Kategorien in seinen Katalog aufgenommen wird und genau wie eine integrierte lädt, wobei sie die integrierte mit demselben Namen ersetzt. Auch das Verfassen einer Spezialisierung ist ausschließlich defensiv und folgt derselben Grenze, die die Spezialisierungen durchsetzen: Die Beschreibung eines Angriffs darf die Quelle sein, doch die daraus entstehende Spezialisierung auditiert und erklärt, sie liefert nie einen funktionsfähigen Exploit. So reicht die Umkehrung aus `§I`, die Intelligenz in der Spezifikation, bis in den Katalog selbst, den der Nutzer für seinen eigenen Kontext vertiefen kann, ohne Code zu schreiben. Ein kurzes Beispiel veranschaulicht Prompt bei Bedarf. Detect liest einen Ordner mit Code, der im Browser läuft. Die Phase findet diesen Kontext im Katalog, lädt die Spezialisierung, die ihn abdeckt, und meldet über die üblichen Schritte von detect einen clientseitigen Befund. Die Spezialisierungen, deren Kontext in diesem Umfang fehlt, passen nicht, laden also nie, und jede wird als übersprungen festgehalten. Das Projekt hat entschieden, welches Wissen relevant war, nicht eine feste Konfiguration. Determinismus taucht genau dort auf, wo er zählt. Eine Spezialisierung kann ein deterministisches Prüfprogramm mitbringen, nicht nur Text: Wo eine Risikoklasse ein klares Entscheidungsverfahren hat, liefert ein kleines Programm für eine gegebene Eingabe ein festes Urteil, zum Beispiel aus einer kurzen Menge von Wörtern wie `safe`, `unsafe` oder `invalid input`. Manche Risikoklassen lassen sich genau so deterministisch entscheiden, und hinter dem Entscheidungsverfahren steht eine Reihe früherer Arbeiten `[9]`, `[10]`, `[11]`. Das Prüfprogramm bewertet entweder Kandidaten, die der Agent liefert, oder durchsucht den Umfang selbst nach ihnen, und in beiden Fällen liefert das Prüfprogramm das Urteil, nicht der Agent. Eine Spezialisierung, die universell genug ist, kann im Katalog als verpflichtend markiert werden und wird dann immer angewendet, wobei ihr Prüfprogramm über den gesamten Umfang läuft. Das ist der einzige Fall, in dem Wissen ohne Kontexttreffer lädt, und er ist in den Daten des Katalogs festgelegt, nie vom Agenten im Moment entschieden. Hier verankert SDH das Schlussfolgern des Agenten in etwas Wiederholbarem, ohne vorzugeben, der gesamte Workflow sei deterministisch. Schließlich sind die Spezialisierungen **ablösbar**. Weil das Wissen für sich allein steht, kann ein Nutzer eine davon direkt in einem Prompt ausführen, der nichts mit dem vollständigen Workflow von SDH zu tun hat, und so die Sicherheit bei der alltäglichen Entwicklung mitlaufen lassen. Eine Spezialisierung mit deterministischem Prüfprogramm kann zum Beispiel jeden Kandidaten prüfen, der während der alltäglichen Programmierarbeit entsteht, und nur die sicheren behalten. Diese Ablösbarkeit ist ein Grund dafür, dass sich SDH an so viele Situationen anpasst, worum es in `§VIII` geht, und ihren vollen Ausdruck findet sie im präventiven Modus (`§IX`), in dem dasselbe Wissen die alltägliche Entwicklung von Anfang bis Ende absichert. --- ## VIII. Zustandsunabhängigkeit und nicht vorschreibende Anpassungsfähigkeit Zwei Eigenschaften unterscheiden SDH von starren Spezifikationsmethodiken. ### Zustandsunabhängigkeit > **Definition** > > **Zustandsunabhängigkeit:** Die Methodik hängt nicht vom Entwicklungsstand ab. Sie passt zu einem leeren Verzeichnis, einem laufenden Projekt, einem einzelnen Pull Request oder einer großen Legacy-Codebasis, in jedem Stack, weil sie den Ausgangspunkt erfasst, indem sie ihn liest. Jede Phase arbeitet gleich, ob das Projekt brandneu ist oder bereits existiert. Die Phase charter leitet Prinzipien aus dem Code ab, der gerade vorhanden ist. Detect erfasst den Code, der da ist, auch wenn es sehr wenig ist. Es gibt keinen vorausgesetzten Ausgangspunkt. ### Nicht vorschreibende Anpassungsfähigkeit > **Definition** > > **Nicht vorschreibende Anpassungsfähigkeit:** Die Methodik passt sich dem Szenario an, statt einen festen Umfang vorzugeben, dem der Nutzer folgen muss. Weiß der Nutzer nicht, was er sagen soll, liest sie die Umgebung, in der sie aufgerufen wurde, erzeugt Kontext und stellt die Fragen, die bestimmen, was sie als Nächstes tut. Der Vorschlagsmodus der Phase charter ist das deutlichste Beispiel: SDH leitet durch eine Analyse des Projekts standardmäßig sichere Prinzipien ab, fragt den Nutzer nur, wenn eine Lücke das Ergebnis tatsächlich verändert, schreibt sie dann und stellt jedes Prinzip in verständlicher Sprache mit dem Risiko vor, das es verhindert. Die Sicherheitsprinzipien sind ein lebendiges Dokument, das der Nutzer durch erneutes Ausführen überarbeitet, kein Vertrag hinter einer Freigabeabfrage, und so muss der Nutzer nie wissen, wonach er fragen soll. Diese Anpassungsfähigkeit zeigt sich als Gespür für die Form der Eingabe: Dieselbe Phase liest, was sie bekommen hat, und wählt einen Modus (Abbildung 4). Eine Datei im Prompt, ein Befund aus der Liste, eine Sorge, ein gezielter Auftrag gegen einen bekannten Schwachpunkt oder der Wunsch nach einem vollständigen Brute-Force-Durchlauf: Jedes davon passt zu dem, was der Nutzer braucht, weil der Workflow von Grund auf nicht vorschreibend ist. Nichts davon schwächt die standardmäßig sichere Grundlage. Flexibilität bestimmt, wie die Grundlage angewendet wird, sie senkt sie nie. ```mermaid flowchart TB shape["die Phase liest die Form
dessen, was sie bekommen hat"] shape --> none["keine Eingabe"] shape --> paths["ein oder mehrere Pfade"] shape --> concern["ein beschriebenes Anliegen"] shape --> finding["ein benannter Befund"] shape --> band["eine Prioritätsstufe"] none --> auto["der automatische Modus:
vorschlagen oder den gesamten
Umfang durchsuchen"] paths --> focus["nur auf diese Dateien
oder Verzeichnisse konzentrieren"] concern --> scoped["auf dieses eine
Anliegen beschränken"] finding --> item["nur diesen einen
nachverfolgten Eintrag bearbeiten"] band --> priority["nur eine Stufe bearbeiten:
kritisch, hoch, mittel oder niedrig"] ``` **Abbildung 4.** Nicht vorschreibende Anpassungsfähigkeit. Dieselbe Phase liest die Form ihrer Eingabe und wählt einen Modus, sodass der Umfang immer beim Nutzer liegt und nie vorgegeben wird. --- ## IX. Der universelle präventive Modus: dieselbe Verteidigung, während die Arbeit entsteht SDH bringt einen ergänzenden Modus mit: alltägliche Entwicklung, bei der dieselbe Verteidigung aktiv ist, während der Code geschrieben wird. Der Nutzer bittet um die Arbeit selbst, eine Anmeldeseite, einen Upload, einen Endpoint, und die Methodik sichert die Entwicklung ab, während sie geschieht, sodass das Ergebnis in dem Moment standardmäßig sicher ist, in dem es fertig ist, statt erst nach einer späteren Härtung. > **Definition** > > **Der präventive Modus:** alltägliche Entwicklung unter der übergeordneten Ebene und dem Wissen von SDH. Die Sicherheitsprinzipien binden die Entwicklung, die Spezialisierungen, die für das gerade Entstehende relevant sind, laden bei Bedarf, und das Ergebnis wird genau der Verteidigung gegenübergestellt, die eingesetzt wurde, bevor die Arbeit als fertig gilt. Der Modus verwendet jedes Teil wieder, das die Phasen bereits mitbringen, nur gerichtet auf Code, den es noch nicht gibt. Die Kontexterkennung wendet sich vom Code zur Absicht: Der Agent denkt durch, was er gleich bauen wird und welche Grenzen diese Arbeit überschreitet (eine Anmeldung bedeutet Zugangsdaten, eine Sitzung und Eingaben von außen), und genau diese Überlegung wird mit dem Wissenskatalog abgeglichen. Prompt bei Bedarf (`§VII`) wird hier verallgemeinert: Kontext lässt sich im Plan für Code erkennen, nicht nur in bestehendem Code. Die Sicherheitsprinzipien gelten wie immer, und eine Anfrage, die ein Prinzip verletzen würde, wird als Konflikt gemeldet und nie gebaut. Die Verteidigung wird direkt angewendet, in dem Moment, in dem jedes Teil geschrieben wird, mit Validierung an der Grenze und dem sicheren Konstrukt gleich beim ersten Mal, sodass nie eine funktionierende, aber unsichere Version entsteht, die korrigiert werden müsste. Der Modus endet so, wie verify beginnt. Bevor die Arbeit als fertig gilt, stellt derjenige, der sie gebaut hat, das eigene Ergebnis der eingesetzten Verteidigung gegenüber: Die Schutzmaßnahme muss auf dem Weg des Risikos liegen, nicht daneben, sie muss vollständig sein, und wo eine Spezialisierung ein deterministisches Prüfprogramm mitbringt, hat dessen Urteil Vorrang vor der eigenen Lesart des Agenten. Eine Lücke, die hier auffällt, wird als Teil derselben Arbeit geschlossen, denn die Arbeit fertigzustellen heißt, sie sicher fertigzustellen. Was der Modus ablehnt, ist ebenso bewusst gewählt wie das, was er tut. Er baut nur, was verlangt wurde, und auditiert nichts drumherum: Das Auditieren des Bestehenden ist Sache der Phasen. Er schreibt kein Artefakt und verfolgt keinen Befund nach, denn ein Befund ist ein in Bestehendem erkanntes Risiko, und der Zweck dieses Modus ist, dass die unsichere Version gar nicht erst entsteht. Die beiden Richtungen ergänzen sich: Die Phasen schließen ab, was schon da ist (`§V`), und der präventive Modus verhindert, dass neue Arbeit es wieder öffnet. Eine Kette im Ruhezustand bleibt im Ruhezustand, nicht weil die Entwicklung stillsteht, sondern weil alles, was in dieser Zeit entsteht, von vornherein abgesichert entsteht. --- ## X. Security-Driven Hardening im Vergleich zu Spec-Driven Development Security-Driven Hardening (SDH) ist aus der Basis von Spec-Driven Development (SDD) hervorgegangen und hat sich dann deutlich davon entfernt. Das strukturelle Erbe ist real und anerkannt: Spec-first, agentengesteuert, ein übergeordnetes Dokument und eine Reihe von Befehlen in Phasen, die der Agent ausführt. SDH übernimmt diese Struktur bewusst. Anders sind der Zweck, das Autoritätsmodell, der vorausgesetzte Zustand und die Endbedingung. Wir behandeln SDD als Klasse und nehmen den Bericht von Piskala `[1]` als maßgebliche Darstellung der Methodik, Spec Kit von GitHub `[2]` als maßgebliches Toolkit für Agenten und OpenSpec `[3]` als zweites Werkzeug aus derselben Familie. SDD stellt die herkömmliche Entwicklung auf den Kopf, indem es Spezifikationen ausführbar macht: Die Spezifikation erzeugt direkt eine funktionierende Implementierung, statt sie nur anzuleiten `[1]`. Seine Phasen treiben eine Entwicklung voran `[2]` (übergeordnete Prinzipien festlegen, spezifizieren, was gebaut wird, den Tech-Stack planen, den Plan in Aufgaben zerlegen, dann implementieren). Sein übergeordnetes Dokument, eine Verfassung aus Prinzipien, ist das Fundament, an das sich der Agent durchgehend halten muss. Das ist der Kern des Unterschieds. Bei SDD fließt die Autorität von der Spezifikation in die Entwicklung, und von der Implementierung wird erwartet, dass sie ihr folgt. SDH kehrt fast jede Achse dieses Vertrags um (Tabelle 3). > **Kernaussage** > > **Der zentrale Unterschied:** Bei SDD fließt die Autorität von der Spezifikation in die Entwicklung, und von der Implementierung wird erwartet, dass sie ihr folgt. SDH ist nicht vorschreibend und fließt in die andere Richtung, vom erkannten Kontext des Systems nach innen, und härtet, was bereits da ist. | Achse | SDD | SDH | | ----------------------- | -------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | | Ziel | Funktionen liefern. Die Spezifikation wird zu einer funktionierenden Implementierung. | Härten, was existiert oder gerade entsteht. Jede Phase ist auf Verteidigung ausgerichtet. | | Autoritätsmodell | Vorschreibend. Spezifikation und Verfassung beschränken die Entwicklung auf einen Umfang, dem sie folgen muss. | Nicht vorschreibend. SDH passt sich dem Szenario an, und der Nutzer kann umformulieren, streichen oder eingrenzen. | | Zustandsannahme | Eine Vorwärtsentwicklung aus einer Spezifikation. | Zustandsunabhängig: leeres Verzeichnis, laufendes Projekt, ein einzelner PR oder Legacy. | | Endbedingung | Endet, wenn die Funktion gebaut ist. | Abschließbar. Ein Befund erreicht den Ruhezustand und wird erst wieder geöffnet, wenn sich der Code ändert. | | Übergeordnetes Dokument | Eine Verfassung aus Prinzipien, an die sich der Agent halten muss. | Sicherheitsprinzipien, die vom Risiko her formuliert sind (jedes mit einer Zeile `Why:`), ausdrücklich kein fester Vertrag. | | Wie Wissen wächst | Einen Befehl hinzufügen (oder die Phasen erweitern). | Eine nicht aufrufbare Spezialisierung hinzufügen, die der Agent bei Bedarf lädt: eine Datei plus eine Katalogzeile, kein neuer Befehl. | | Wem es dient | Jemandem, der eine Funktion vorantreibt. | Jedem Nutzer, ob Entwickler oder nicht, im selben Workflow. | | Was Code ändert | Die Implementierungsphase erzeugt das Ergebnis. | Nur die Phase harden ändert Code, eine Korrektur nach der anderen. | **Tabelle 3.** SDD und SDH im Vergleich über acht Achsen. Geliehene Struktur, umgekehrter Vertrag. Um der Herkunft gerecht zu werden: SDD ist bewährter Stand der Technik, und SDH verdankt ihm die Struktur, auf der es läuft. Die Abweichung ist keine Kritik an SDD, das ein anderes Problem (die Vorwärtsentwicklung) gut löst. SDH nimmt dieselbe bewährte Maschinerie und richtet sie auf Verteidigung, Anpassungsfähigkeit und Abschluss aus. OpenSpec `[3]`, aufgebaut um Änderungsvorschläge, Aufgabenlisten und Spezifikationen pro Änderung, bestätigt das Muster: Die Familie treibt eine Entwicklung von einer Spezifikation aus voran, während SDH ein System ausgehend von seinem erkannten Kontext nach innen härtet. Selbst der präventive Modus von SDH (`§IX`), die einzige Stelle, an der es eine Vorwärtsentwicklung begleitet, behält den umgekehrten Vertrag bei: Er bestimmt, wie die Arbeit gebaut wird, und entscheidet nie, was gebaut wird. --- ## XI. Technische Sorgfalt: die Disziplin der Nachverfolgung Die Disziplin, abzugleichen statt nur anzuhängen (`§V`), braucht eine Grundlage, die Refactorings übersteht. Ein Befund muss über jede Phase hinweg, die ihn berührt, ein Eintrag bleiben, und eine umbenannte oder verschobene Datei darf die Kette nicht unterbrechen. SDH löst das mit **Identität über den Namen** und **Pfaden nur in der Nachverfolgung**. > **Definition** > > **Identität über den Namen:** Die Identität eines Befunds ist sein Name, in jedem Artefakt identisch geschrieben. Der Text trägt den Namen, nie einen Pfad. Dateipfade stehen nur in der Tracking-Map, sodass eine Umbenennung oder eine verschobene Datei die Verknüpfung an genau einer Stelle unterbricht. Jeder Befund von detect ist ein nachverfolgter Eintrag. Seine Identität ist sein **Name**, der Abschnittstitel, identisch geschrieben in der Bestandsaufnahme von detect, im Abwehrplan und im Härtungsprotokoll. Die späteren Phasen übernehmen diesen Namen wörtlich, wenn sie an demselben Eintrag arbeiten, und verify schreibt ihr Urteil unter genau diesem Namen ins Härtungsprotokoll. Die Tracking-Map enthält Nachverfolgung und sonst nichts, einen Eintrag pro Befund: ```json { "name": "File uploads", "paths": ["src/routes/upload.ts"] } ``` Die Tracking-Map hält keinen Text fest, keine Anmerkungen, keine separate Kennung und keine Phase. Die Textartefakte tragen den Wortlaut, und die Map trägt nur Identität und Pfade. Dateipfade sind das einzig Veränderliche, und sie stehen nur hier. Eine Umbenennung oder eine verschobene Datei kann die Verknüpfung an genau einer Stelle unterbrechen, nie in zwei auseinanderlaufenden Kopien. ```mermaid flowchart TB detect["die Bestandsaufnahme von detect"] --> name plan["der Abwehrplan"] --> name harden["das Härtungsprotokoll
verify schreibt hier ihr Urteil"] --> name name["name = "File uploads"
der Text trägt den Namen, nie einen Pfad"] name -.-> tracking tracking["die Tracking-Map
{ name: "File uploads",
paths: ["src/routes/upload.ts"] }
der Pfad steht nur hier, also korrigiert eine Umbenennung nur diesen Eintrag"] ``` **Abbildung 5.** Das Förderband der Identität. Ein Befundname fließt durch jedes Artefakt, während sein Pfad nur in der Tracking-Map steht, sodass eine Umbenennung an einer Stelle korrigiert wird. Zwei Vorgänge pflegen die Map im normalen Workflow, und ein dritter steht als Wartung für sich. **Track** ist eine additive Registrierung: Eine Phase meldet die Befunde, die sie geschrieben hat, und die Engine erfasst die neuen und folgt bei den übrigen einem umbenannten Pfad, wobei sie jeden als neu, verschoben oder unverändert einordnet. Track entfernt nie etwas, das die Phase nicht gemeldet hat. **Untrack** trägt die Befunde aus, die verify abgeschlossen hat: In einem deterministischen Durchgang verdichtet er jeden zu seinem Eintrag in der Historie, entfernt seinen gesamten Abschnitt aus den Artefakten, löscht ein Artefakt, dessen letzter Befund weg ist, und streicht seinen Tracking-Eintrag, sodass der Agent nichts davon von Hand erledigt. Wo der deterministische Durchgang nicht sicher weiterkommt, etwa bei einem ausgetragenen Namen, der noch im Text eines anderen Befunds zitiert wird, meldet er die Stelle dem Agenten, statt eine Änderung zu raten. Diese beiden rufen die Phasen während ihrer Arbeit auf. **Repair** ist der Wartungsvorgang: Eine Phase übergibt automatisch an ihn, wenn ihr eigener Abgleich die Nachverfolgung als inkonsistent erkennt (ein festgehaltener Pfad, den es nicht mehr gibt), und ansonsten wird er bei Bedarf ausgeführt. Er richtet die gesamte Map auf einmal neu aus, liest jedes Artefakt und den aktuellen Code, korrigiert die Pfade jedes Eintrags und legt offen, was er nicht allein entscheiden kann: einen verwaisten Eintrag (einen nachverfolgten Eintrag, den kein Artefakt mehr nennt) oder einen Umbenennungskandidaten (einen Eintrag, dessen Pfade zu einem anderen gemeldeten Namen passen). Repair ist Wartung, keine sechste Phase. Er berührt weder den Code des Nutzers noch die Textartefakte, nur die Nachverfolgung. Den Quellcode des Nutzers liest er aus genau einem Grund, um den neuen Pfad einer umbenannten Datei zu erfahren, und er verfasst nie Sicherheitsinhalte. Der Mensch hat das letzte Wort bei der einen Entscheidung, die die Engine nicht raten will: ob ein verschwundener Eintrag behoben oder nur umbenannt wurde. Lieber fragen als raten, denn ein fälschlich gestrichener Eintrag unterbricht die Kette. Die Methodik wendet ihre eigene Verteidigungsdisziplin auf sich selbst an. Die deterministischen Engines werden als Kommandozeilenprogramme aufgerufen, und jede Eingabe wird als eigenes Prozessargument übergeben, was sie unschädlich hält, sodass ein Wert mit Anführungszeichen oder Backticks nie in den Befehl eingeschleust werden kann. Eine unbekannte Prüfung schlägt fehl, statt zu antworten, sodass eine falsch geschriebene nie als sauberes Ergebnis durchgeht. SDH nimmt seine eigene Infrastruktur nicht vom Prinzip der standardmäßigen Sicherheit aus. --- ## XII. Der Träger: agentenunabhängige Architektur als Nachweis der Portabilität Damit SDH eine Konvention sein kann, die andere übernehmen, darf es nicht an einen Agenten oder einen Stack gebunden sein, deshalb hält sein Träger drei Zuständigkeiten auseinander (Abbildung 6). Lagune belegt, dass das machbar ist. **Der Sicherheitskern** wird einmal geschrieben und weiß nichts davon, welcher Agent ihn ausführt: die Phasenanweisungen und die Vorlagen, die sie ausfüllen, der Wissenskatalog und die deterministischen Engines. **Die Auslieferung** ist schlank: Ihre einzige Aufgabe ist, diesen Kern zu einem bestimmten Agenten zu bringen, in der Form und an den Ort, die der Agent erwartet, und sie enthält keine eigene Sicherheitslogik. **Der Zustand des Projekts** gehört dem Projekt: die Sicherheitsprinzipien, die Phasen-Artefakte, die Tracking-Map, die gewählten Kategorien und die eigenen Spezialisierungen, committet und überprüfbar wie jeder andere Teil seines Codes. ```mermaid flowchart TB value["der Sicherheitskern, einmal geschrieben
Phasenanweisungen · Vorlagen · Wissenskatalog · deterministische Engines
weiß nicht, welcher Agent ihn ausführt"] delivery["die Auslieferung
bringt diesen Kern zu jedem Agenten in der Form, die er erwartet
enthält keine Sicherheitslogik"] agent["der Agent
führt die Phasen aus"] project["der Zustand des Projekts
zusammen mit seinem Code committet
Sicherheitsprinzipien · Phasen-Artefakte · Nachverfolgung · Kategorien · eigene Spezialisierungen"] value --> delivery --> agent agent -->|"liest und schreibt"| project ``` **Abbildung 6.** Der agentenunabhängige Träger. Der Sicherheitskern wird einmal geschrieben, eine schlanke Auslieferung bringt ihn zu jedem Agenten, und der Zustand bleibt beim Projekt. Weil die Auslieferung keine Sicherheitslogik enthält, ändert die Art, wie sie gebaut ist, nichts an SDH. Ein Träger kann die Auslieferung selbst bauen oder einem Ökosystem überlassen, das bereits Skills für Agenten verteilt, wie es die Referenzimplementierung tut, und die Phasen, ihre Artefakte und ihre Garantien bleiben dieselben. Nichts davon ist zudem an eine Sprache oder eine Laufzeitumgebung gebunden. Die Referenzimplementierung ist zufällig in einem bestimmten Stack geschrieben, doch die Methodik ist die Grenze zwischen diesen Zuständigkeiten, nicht die Toolchain, die sie baut. Dasselbe Design ließe sich in einer ganz anderen Sprache neu umsetzen, ohne zu ändern, was SDH ist. --- ## XIII. Fallbeispiel: SDH von Anfang bis Ende > **Fallbeispiel** > > **Defensive Härtung einer Upload- und Admin-Oberfläche.** > **Kontext:** eine kleine App, die Datei-Uploads von Nutzern annimmt und sie auf einer Admin-Seite auflistet. > **Muster:** charter → detect (mit Wissen, das der Kontext bei Bedarf aktiviert) → plan → harden → verify, mit einem Abschluss und einem echten Fehlschlag. > **Ergebnis (Fähigkeit):** ein Risiko, das als geschlossen verifiziert und aus der Kette ausgetragen wird, und eine Schutzmaßnahme, die als _nicht_ geschlossen verifiziert und an harden zurückgegeben wird. Das Urteil spiegelt den Code wider, nicht das Protokoll. _Dies ist ein veranschaulichendes Beispiel für die Mechanik der Methodik, keine im Feld gemessene Studie, und es nennt keine Kennzahlen zur Wirksamkeit._ Ein durchgehender Ablauf zeigt die Methodik in Aktion, nicht nur ihre Teile. Wir erweitern das Datei-Upload-Beispiel aus `§IV` um eine Aktivierung von Wissen bei Bedarf und einen Abschluss, und wir nehmen einen echten Fehlschlag auf. 1. **charter** schlägt das Prinzip "Jede Eingabe gilt als nicht vertrauenswürdig, bis sie validiert ist" vor, mit seinem Risiko in verständlicher Sprache: Ungeprüfte Eingaben sind der häufigste Weg, ein System zu kompromittieren. 2. **detect** durchsucht die Upload-Route und die kleine Admin-Seite, die hochgeladene Dateien auflistet. Die Phase erkennt den Upload-Befund (der Handler vertraut dem MIME-Typ des Clients). Die Admin-Seite läuft im Browser, ein Kontext, den Prompt bei Bedarf (`§VII`) erkennt, also lädt detect die Spezialisierung für diesen Kontext und meldet einen zweiten Befund: eine Stelle, an der ein Dateiname als Markup statt als Text in die Seite geschrieben wird, sodass ein manipulierter Name im Browser des Besuchers als Skript ausgeführt werden kann. Spezialisierungen, deren Kontext in diesem Umfang fehlt, laden nie, und jedes Überspringen wird festgehalten, wobei das Fehlen am Code abgelesen wird. 3. **plan** gibt der Upload-Korrektur die Priorität kritisch, gebunden an das Prinzip: den echten Typ und die Größe der Datei prüfen, beim Speichern umbenennen, dort ablegen, wo kein Code ausgeführt werden kann. Der zweiten Korrektur gibt die Phase die Priorität hoch: den Dateinamen als Text darstellen, nicht als Markup. 4. **harden** setzt zuerst die Upload-Korrektur um (höchste Priorität) und hält sie als Applied fest, danach die zweite, ebenfalls Applied. 5. **verify** liest jede Stelle und stellt Code und Protokoll gegenüber. Die Upload-Schutzmaßnahme greift: Der Handler erkennt den echten Typ am Inhalt, erzwingt ein Größenlimit und lehnt den Rest ab. Urteil: Risk closed. Verify trägt den Upload-Befund aus der gesamten Kette aus, und seine verdichtete Zusammenfassung landet in der Historie. Es folgt der echte Fehlschlag. Angenommen, die zweite Korrektur von harden hat eine sichere Hilfsfunktion zur Textdarstellung hinzugefügt, aber den alten Aufruf, der Markup schreibt, auf einem anderen Codepfad weiterhin erreichbar gelassen. Verify liest die Seite, sieht die sichere Hilfsfunktion und sieht auch, dass der unsichere Pfad noch aktiv ist. Die Schutzmaßnahme ist vorhanden, aber das Risiko ist nicht geschlossen. Verify weigert sich, das Urteil abzuschwächen, damit es zum Protokoll passt. Die Phase liefert "Risk not closed", hält die Lücke fest und verweist zurück an harden. Eine Schutzmaßnahme, die das Risiko nicht vollständig behebt, gilt nicht als bestanden. Das ist der Charakter der Methodik in einem Beispiel: kontextbezogene Erkennung, priorisierte Korrekturen, die an Prinzipien gebunden sind, sorgfältige Umsetzung und eine Verifizierung, die den tatsächlichen Zustand des Codes meldet, unabhängig vom Protokoll. --- ## XIV. Wann sich SDH eignet und wo seine Grenzen liegen SDH ist selten so unverhältnismäßig, wie es ein schwerfälliger Prozess sein kann, weil es zustandsunabhängig und abschließbar ist: Es lässt sich auf eine einzelne Datei und ein einzelnes Anliegen herunterskalieren und erreicht einen Ruhezustand, statt eine dauerhafte Last zu hinterlassen. Seine Grenze ist nicht die Projektgröße, sondern die **Tiefe der Absicherung**. ```mermaid flowchart TB q1{"Macht der Code etwas Sicherheitsrelevantes?
(Eingaben, Authentifizierung, Daten, Secrets, externe Aufrufe)"} q1 -->|nein| little["Hier bringt SDH wenig."] q1 -->|ja| q2{"Führe SDH aus. Gibt es Compliance-Vorgaben
oder eine eigene Sicherheitsabteilung?"} q2 -->|nein| baseline["SDH ist eine belastbare Grundlage."] q2 -->|ja| carrier["SDH ist der strukturierte Träger:
es unterstützt Prüfung und Audit durch Experten,
es ersetzt sie nicht."] ``` **Abbildung 7.** Wann sich SDH eignet. Die Verzweigung fragt zuerst nach der Sicherheitsrelevanz, dann nach der Tiefe der Absicherung, nie nach der Projektgröße. Wo SDH an seine Grenze stößt: Verhalten, das nur auftritt, wenn das System läuft (verify liest Code, sie führt das System nicht aus), Risiken, die von einer Konfiguration oder einer Umgebung abhängen, die der Agent nicht lesen kann, und Kontexte, in denen so viel auf dem Spiel steht, dass eine Prüfung durch Experten ohnehin vorgeschrieben ist. In jedem dieser Fälle bringt SDH als strukturierter erster Durchgang weiterhin Nutzen, aber es ist eine Untergrenze, keine Obergrenze. > **Kernaussage** > > **Die Grenze:** Die Grenze von SDH ist die Tiefe der Absicherung, nicht die Projektgröße. Es kann fast überall als belastbare Grundlage dienen und unterstützt eine Prüfung durch Experten, wo viel auf dem Spiel steht, doch es ersetzt weder Tests am laufenden System noch das Urteil von Sicherheitsfachleuten. --- ## XV. Diskussion: Einordnung, Grenzen und was SDH nicht behauptet SDH ist präzise, was seine Grenzen angeht. ### Es erweitert, es ersetzt nicht SDH ersetzt weder Sicherheitsfachleute noch spezialisierte Blue-Team-Werkzeuge. Es erweitert das Wissen der Entwickler (`§VI`). Eine maßvolle Aussage ist die richtige: Gut angewendet **kann** SDH reale Risiken wirksam schließen, besonders bei Projekten, die sonst überhaupt keine Sicherheitsprüfung bekämen. Es ist keine Garantie und kein Ersatz für eine Prüfung durch Experten, wo viel auf dem Spiel steht. ### Ausschließlich defensiv, vom Aufbau her SDH auditiert, härtet und verifiziert. Es erzeugt nie offensive Werkzeuge, Exploits oder Techniken zur Umgehung von Erkennung, um Schaden anzurichten. Dual-Use-Sicherheitsinhalte sind nur in einem klar defensiven, autorisierten Rahmen zulässig. Das ist eine harte Grenze, keine Vorliebe. ### Die Verifizierung ist substanziell, nicht theatralisch Verify prüft, indem sie den Code liest und dem Protokoll gegenüberstellt, nicht indem sie das System ausführt. Das ist statische Verifizierung: Sie bestätigt, dass eine Schutzmaßnahme im Code vorhanden und korrekt ist, und weist nicht nach, dass die Maßnahme zur Laufzeit einem Angriff standhält. Deshalb ist "Cannot tell from the code" ein legitimes Urteil, kein Fehlschlag, der sich hinter einem bestandenen Ergebnis versteckt. Wenn der Beleg nicht im Code steckt (weil er von der Konfiguration abhängt oder von einem Pfad, den der Agent nicht lesen kann), sagt SDH das, statt zu raten. ### Determinismus ist begrenzt und benannt Der Großteil von SDH beruht auf dem Schlussfolgern des Agenten, und genau das ermöglicht seinen Kontextbezug. Determinismus ist den deterministischen Engines vorbehalten: den Prüfprogrammen, die eine Spezialisierung mitbringen kann (`§VII`), und der Tracking-Engine (`§XI`). Das Dokument verwischt diese Grenze nicht. Wo ein Ergebnis deterministisch ist, ist es das Ergebnis eines Programms. Wo es erschlossen ist, ist es die Lesart des Codes durch den Agenten, und der Nutzer hat das letzte Wort. ### Kosten und Skalierung Ein vollständiger Durchlauf verbraucht viele Tokens. Die manuellen Modi (`§VI`, `§VIII`) gibt es unter anderem, damit die Kosten im Verhältnis zum Anliegen stehen. ### Der Nutzer hat das letzte Wort SDH lässt den Menschen entscheiden, ob etwas umbenannt oder behoben wurde, und die Freigabe seiner Codeänderungen bleibt dort, wo der Nutzer seinen Agenten ohnehin steuert: im Berechtigungsmodus, in dem er ihn ausführt. Die Methodik schlägt vor und verifiziert. Sie setzt sich nicht über den Menschen hinweg. ### Einwände und Antworten Ein fairer Skeptiker wird mehrere Einwände erheben. Die gewichtigen verdienen es, in ihren eigenen Worten gestellt zu werden. **"Ist das nicht einfach ein statisches Analysetool mit angeflanschtem LLM?"** Nein. Ein statisches Analysetool führt standardmäßig jede Regel aus, die es hat. SDH erkennt zuerst, was das System ist, greift dann zum relevanten Wissen (`§II`, `§VII`) und _bettet_ ein deterministisches Prüfprogramm nur dort ein, wo eine Risikoklasse ein klares Entscheidungsverfahren hat. Das Schlussfolgern geht vom Kontext aus, der Determinismus ist gezielt. **"Ist das nicht einfach eine Sicherheitscheckliste?"** Nein. SDH kehrt die Checkliste um: Die Erkennung kommt zuerst, und Wissen wird für das herangezogen, was das Projekt tatsächlich tut (`§II`, `§VII`). **"Ist das nicht einfach SDD, neu verpackt für Sicherheit?"** Nein. SDH übernimmt die Struktur von SDD und kehrt seinen Vertrag um: Autorität, Zustandsannahme, Endbedingung und Zielgruppe unterscheiden sich allesamt (`§X`). Dieselbe Maschinerie, entgegengesetzte Richtung. **"Halluziniert eine Methode, die auf KI-Schlussfolgerungen beruht, nicht einfach Befunde?"** Das Design schränkt das Erfinden ein, statt darauf zu vertrauen, dass sich das Modell benimmt. Detect hält nur fest, was der Code belegt ("Erkennen, nicht erfinden", `§IV`), verify stellt Code und Protokoll gegenüber und darf mit "Cannot tell from the code" antworten (`§XV`), deterministische Prüfprogramme stützen die entscheidbaren Fälle (`§VII`), und der Nutzer hat das letzte Wort. Das macht den Agenten nicht unfehlbar, aber es macht seine Aussagen überprüfbar. Eine Anmerkung zur Einordnung. SDH wird hier unabhängig von seiner Referenzimplementierung definiert. Die fünf Phasen, die vom Risiko her formulierten Sicherheitsprinzipien, das Abgleichen statt nur Anhängen und seine Abschließbarkeit, das Wissen per Prompt bei Bedarf, der präventive Modus, die Nachverfolgung mit Identität über den Namen und die ausschließlich defensive Grenze sind die Methodik. Ein anderes Team könnte sie in einem anderen Stack und einem anderen Agenten-Ökosystem umsetzen, und das Ergebnis wäre trotzdem SDH. Lagune ist sein Nachweis, nicht seine Definition. --- ## XVI. Fallstricke und wie SDH sie strukturell vermeidet Methodiken dieser Familie teilen eine bekannte Reihe von Fehlermustern. Die Antwort von SDH auf die meisten davon ist strukturell, in den Workflow eingebaut, statt der Disziplin überlassen. | Fallstrick | Das Problem | Die strukturelle Antwort von SDH | | --------------------------------------------- | ---------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | | Verrottende Spezifikation, veralteter Backlog | Artefakte sammeln tote Einträge an, denen niemand traut | Abgleichen statt nur anhängen (`§V`): Jeder Lauf prüft jeden Eintrag neu und entfernt, was behoben ist | | Falsche Sicherheit, scheinbar bestanden | Man nimmt an, eine vorhandene Schutzmaßnahme schließe das Risiko | Verify stellt Code und Protokoll gegenüber, sodass "Risk not closed" und "Cannot tell" vollwertige Urteile sind (`§IV`, `§XV`) | | Checklistenflut | Generische Punkte verdecken das eine Risiko, auf das es ankommt | Kontextbezogen statt generisch, mit Prompt bei Bedarf, der nur lädt, was der Umfang verlangt (`§VII`) | | Werkzeug-Lock-in | Die Methode ist fest an einen Anbieter oder Agenten geschweißt | Agentenunabhängiger Träger: Der Sicherheitskern wird einmal geschrieben, und seine Auslieferung an jeden Agenten enthält keine Sicherheitslogik (`§XII`) | | Die Endlosschleife | Der Backlog schließt sich nie, die Arbeit ruht nie | Abschließbarkeit und der Ruhezustand (`§V`) | **Tabelle 4.** Bekannte Fallstricke in dieser Methodikfamilie und die strukturelle Antwort von SDH auf jeden davon. Darum geht es: den Fallstrick zu benennen und auf den Mechanismus zu zeigen. Das sind keine Mahnungen zur Vorsicht, sondern Eigenschaften des Workflows. --- ## XVII. Künftige Arbeiten Die Methodik und ihre Referenzimplementierung haben klare nächste Schritte. - **Den Wissenskatalog erweitern:** Jede Ergänzung behält die Form aus `§VII`: eine Wissensdatei und eine Katalogzeile, kein neuer Befehl. Den Weg für Nutzer gibt es dort bereits: Der Nutzer verdichtet seine eigenen Spezialisierungen bei Bedarf. Weitere integrierte Sprachen, Laufzeitumgebungen und Risikoklassen, jeweils in einer Kategorie, sind die Richtung auf Seiten des Maintainers, und die Spezialisierungen werden sich voraussichtlich weiterentwickeln. - **Mehr deterministische Prüfprogramme:** Wo eine Risikoklasse ein klares Entscheidungsverfahren hat, kann eine Spezialisierung ein deterministisches Prüfprogramm mitbringen, das das Schlussfolgern des Agenten in einem wiederholbaren Urteil verankert. Das auf weitere Risikoklassen auszudehnen, ist eine naheliegende Richtung. - **Empirische Evaluation:** Die wichtigste offene Frage ist die gemessene Wirksamkeit: die Qualität der Abschlüsse und die Rate falscher Urteile in realen Codebasen. Eine Studie der Sicherheitsergebnisse von SDH steht noch aus, und die Aussagen hier sind entsprechend eingegrenzt. --- ## XVIII. Fazit KI-gestützte Entwicklung hat eine Sicherheitslücke geöffnet, die generische Checklisten nicht füllen können, weil das Risiko, auf das es ankommt, davon abhängt, was ein System tatsächlich tut, und weil die Person, die es ausliefert, vielleicht nicht weiß, wonach sie fragen soll. SDH schließt diese Lücke mit einem kontextbezogenen, ausschließlich defensiven und abschließbaren Workflow, in dem das Sicherheitswissen in der Methodik und ihren bei Bedarf geladenen Spezialisierungen steckt, einer Grundlage, auf der jeder Nutzer aufbauen kann. Es erkennt den tatsächlichen Kontext des Systems, priorisiert die Risiken, die dieser Kontext mit sich bringt, setzt Korrekturen sorgfältig um und verifiziert jede einzelne, dann trägt es aus, was es abgeschlossen hat, sodass jeder Befund einen Endzustand erreicht. Dieselbe Verteidigung läuft außerdem präventiv mit, während neue Arbeit entsteht, sodass geschlossen bleibt, was der Workflow schließt. Es passt sich jedem Entwicklungsstand in jedem Stack an und erweitert das Wissen der Entwickler, statt die Menschen und Werkzeuge zu ersetzen, die diese Arbeit bereits leisten. Lagune ist der Nachweis, doch der Beitrag ist die Konvention. SDH versteht sich als der grundlegende Sicherheits-Workflow für das Zeitalter der Entwicklung mit KI, den andere übernehmen, verfeinern und in ihren eigenen Stacks umsetzen können. --- ## Literatur **[1]** D. B. Piskala, "Spec-Driven Development: From Code to Contract in the Age of AI Coding Assistants," arXiv preprint arXiv:2602.00180v1 [cs.SE], Jan. 2026. (Submitted to AIWare 2026.) [Online]. Available: https://arxiv.org/abs/2602.00180 **[2]** GitHub, "Spec Kit: Toolkit for Spec-Driven Development." [Online]. Available: https://github.com/github/spec-kit. Accessed: 2026. **[3]** Fission AI, "OpenSpec: Spec-Driven Development for AI Coding Assistants." [Online]. Available: https://github.com/Fission-AI/OpenSpec. Accessed: 2026. **[4]** B. Chess and G. McGraw, "Static Analysis for Security," IEEE Security & Privacy, vol. 2, no. 6, pp. 76-79, 2004, doi: 10.1109/MSP.2004.111. **[5]** OWASP Foundation, "Source Code Analysis Tools." [Online]. Available: https://owasp.org/www-community/Source_Code_Analysis_Tools. Accessed: 2026. **[6]** OWASP Foundation, "OWASP Top 10:2021." [Online]. Available: https://owasp.org/Top10/. Accessed: 2026. **[7]** MITRE, "Common Weakness Enumeration (CWE)." [Online]. Available: https://cwe.mitre.org/. Accessed: 2026. **[8]** N. Perry, M. Srivastava, D. Kumar, and D. Boneh, "Do Users Write More Insecure Code with AI Assistants?," in Proc. ACM SIGSAC Conf. on Computer and Communications Security (CCS '23), 2023, pp. 2785-2799, doi: 10.1145/3576915.3623157. [Online]. Available: https://arxiv.org/abs/2211.03622 **[9]** J. Davis and contributors, "safe-regex: Detect Possibly Catastrophic, Exponential-Time Regular Expressions." [Online]. Available: https://github.com/davisjam/safe-regex. Accessed: 2026. **[10]** D. Soshnikov, "regexp-tree: Regular Expressions Processor in JavaScript." [Online]. Available: https://github.com/DmitrySoshnikov/regexp-tree. Accessed: 2026. **[11]** T. Jenkinson, "redos-detector: A CLI and Library to Score How Vulnerable a Regex Pattern Is to ReDoS Attacks." [Online]. Available: https://github.com/tjenkinson/redos-detector. Accessed: 2026. --- ## Anhang A: die Prinzipien im Wortlaut 1. **Standardmäßig sicher, in verständlicher Sprache, für alle gleichermaßen:** Jeder Standardwert, jede Meldung und jede Korrektur muss von Haus aus sicher und für jeden Nutzer verständlich sein, ob Entwickler oder nicht. Keine Nutzergruppe wird gegenüber einer anderen bevorzugt. 2. **Kontextbezogen statt generisch:** Jede Phase muss vom Kontext ausgehen, den detect erkannt hat, und mit dem arbeiten, was das System tatsächlich tut. Bevorzuge Empfehlungen, die auf diesen Kontext zugeschnitten sind, gegenüber generischen Checklisten. Das Sicherheitswissen steckt in der Spezifikation und ihren bei Bedarf geladenen Spezialisierungen und erweitert, was der Nutzer mitbringt. 3. **Flexibel statt starr:** SDH passt sich dem Projekt und dem Nutzer an. Prinzipien, Anforderungen und Empfehlungen sind Ausgangspunkte, kein fester Vertrag. Lass den Nutzer alles umformulieren, streichen, ergänzen oder eingrenzen. Flexibilität schwächt nie die standardmäßig sichere Grundlage, sie lässt den Nutzer nur bestimmen, wie sie angewendet wird. 4. **Abgleichen statt nur anhängen:** Artefakte sind lebendige Dokumente, keine Logs. Wenn eine Phase erneut läuft, gleiche jeden vorhandenen Eintrag mit dem aktuellen Stand ab: Behalte, was noch gilt, schreibe um, was sich geändert hat, und entferne, was nicht mehr zutrifft. Der Abschluss ist derselbe Abgleich, an seinem Ende angekommen. 5. **Ausschließlich defensiv:** SDH auditiert, härtet und verifiziert. Es erzeugt nie offensive Werkzeuge, Exploits für böswillige Zwecke oder Techniken zur Umgehung von Erkennung, um Schaden anzurichten. Dual-Use-Sicherheitsinhalte sind nur in einem klar defensiven, autorisierten Rahmen zulässig. 6. **Spec-first, agentengesteuert, auf Sicherheit ausgerichtet:** Baue den Workflow auf einer bewährten Struktur auf: Vorlagen, Befehle, übergeordnete Sicherheitsprinzipien und ein Agent, der die Phasen ausführt. Setze diese Struktur mit defensivem Zweck neu um. --- # Glossar zu Lagune: SDH, charter, Befunde und Schutzmaßnahmen > Alle Begriffe von Lagune und Security-Driven Hardening in einfacher Sprache erklärt: SDH, charter, detect, Befund, Schutzmaßnahme, harden, verify, austragen, Abschließbarkeit, Spezialisierungen, Kategorien und der Katalog. Kanonische URL: https://lagune.ai/de-DE/docs/references/glossary Sprache: de-DE Original: https://lagune.ai/docs/references/glossary Zuletzt aktualisiert: 2026-11-03 Jeder zentrale Begriff von Lagune und der Methodik Security-Driven Hardening, einmal definiert und in einfacher Sprache. ### Security-Driven Hardening (SDH) Die Methodik, die Lagune umsetzt: eine kontextbezogene Blue-Team-Konvention, die den Kontext eines Systems erkennt, die Risiken dieses Kontexts priorisiert und die Korrekturen anleitet. Das Sicherheitswissen steckt in der Spezifikation und ihren Spezialisierungen, die bei Bedarf geladen werden, sodass Entwickler und Nicht-Entwickler denselben Workflow nutzen. ### Lagune Die Referenzimplementierung von SDH: neun Agentenbefehle, jeweils mit der Vorlage, die sie ausfüllen, mit denen ein KI-Agent eine Codebasis härtet. Jeder Agent installiert sie über seinen eigenen Plugin-Installer oder über [**skills.sh**](https://www.skills.sh/wellwelwel/lagune), wie die [Installationsseite](https://lagune.ai/de-DE/docs) zeigt, und sie führen für jeden deterministischen Schritt die Engine von Lagune aus. ### Charter Die übergeordnete Ebene von Lagune: Prinzipien, die Sicherheit an erste Stelle setzen und die jede spätere Phase einhalten muss. Stell sie dir als Prüfung zur Kompilierzeit für das Sicherheitsniveau eines Projekts vor. Gespeichert sind sie unter `.lagune/memory/charter.md`. ### Entwicklungs-Workflow Der universelle Befehl `/lagune`, der die Arbeit härtet, während sie entsteht. Er nimmt jeden Prompt zu jedem Zeitpunkt an, baut, was du verlangt hast, und härtet es mit sicheren Standardwerten, bevor er es zurückgibt, geleitet von den Sicherheitsprinzipien, sofern es welche gibt. Er schreibt nichts in die Nachverfolgung von Lagune, sein einziges Ergebnis ist also der gehärtete Code. Zusammen mit der Phase charter (davor) und dem Blue-Team-Workflow (danach) ist er der Weg, auf dem Lagune während der Entwicklung schützt. ### Blue-Team-Workflow Das Audit in fünf Phasen im Kern von Lagune: charter, detect, plan, harden, verify. Jede Phase baut auf der vorherigen auf. "Blue Team" ist die Tradition der Verteidiger in der Sicherheit, im Gegensatz zum offensiven Red Team. ### Befund Ein erkanntes Risiko. Jeder Befund hält fest, worum es sich handelt, warum es wichtig ist und welche Belege es dafür im Code gibt. Ein Befund ist die einzelne nachverfolgte Einheit, die plan, harden und verify weitertragen und die in jedem Artefakt über ihren Namen identifiziert wird. ### Schutzmaßnahme Eine Sicherheitsmaßnahme, die umgesetzt wird, um ein Risiko zu schließen. Die Phase harden setzt Schutzmaßnahmen um, verify weist nach, dass sie greifen. Lagune schwächt nie eine Schutzmaßnahme ab, nur um einem Prompt zu entsprechen. ### Detect Die Phase, die den Code liest und erfasst, was das System tut und wo die Risiken liegen. Ihre oberste Regel lautet erkennen, nicht erfinden: Sie hält nur fest, was der Code belegt. ### Harden Die einzige Phase, die deinen Code anfasst. Sie setzt die Korrekturen der Phase plan nacheinander um und hält jede als Applied, Partial oder Blocked fest. Applied heißt noch nicht nachgewiesen. ### Verify Die Phase, die nachweist, dass jede umgesetzte Korrektur greift, indem sie den Code liest und ihm gegenüberstellt, was harden festgehalten hat. Sie liefert eines von drei Urteilen: Risk closed, Risk not closed oder Cannot tell from the code. ### Austragen Wenn verify nachweist, dass ein Risiko geschlossen ist, wird der Befund ausgetragen: Er wird mit deiner Bestätigung aus der gesamten Kette entfernt und danach nicht mehr erneut verarbeitet. ### Abschließbarkeit Die Eigenschaft, dass Sicherheitsarbeit einen Endzustand hat. Weil ein nachweislich geschlossener Befund ausgetragen wird, kann der Workflow in den Ruhezustand übergehen und wird erst wieder geöffnet, wenn sich der Code ändert. SDH ist abschließbar und keine Endlosschleife. ### Engine Das Paket `lagune` auf **npm**, das die Befehle für jeden deterministischen Schritt über `npx` ausführen: die Hooks, den Katalog und die Kategorien. ### Spezialisierung Ein fokussiertes, sprachunabhängiges Modul mit Sicherheitswissen, das nur bei Bedarf geladen wird, nie standardmäßig. Eine Spezialisierung ist kein Befehl. Lade eine mit `read catalog ` der Engine in einen beliebigen Prompt, zum Beispiel `npx lagune read catalog regex`. ### Kategorie Eine benannte Gruppe integrierter Spezialisierungen, von `owasp` bis zu sprachspezifischen wie `javascript`, `python`, `go` und `rust`. Die Kategorien, die ein Projekt nutzt und in `.lagune/configs.json` festhält, bestimmen, welche integrierten Spezialisierungen in seinen Katalog aufgenommen werden. Solange keine festgehalten ist, nutzt das Projekt nur `owasp`. ### Katalog Die Menge der Spezialisierungen, die ein Projekt nutzt: die integrierten seiner Kategorien plus die eigenen, mit `/lagune-specialize` geschrieben. Die Engine listet ihn mit `read catalog` auf, und die Phasen vergleichen ihn mit dem Code. ### Prompt bei Bedarf Das Prinzip, dass das relevante Sicherheitswissen passend zu dem geladen wird, was das Projekt tatsächlich ist, statt standardmäßig jede Prüfung auszuführen. ### Identität über den Namen Das Nachverfolgungsmodell von Lagune: Der Name jedes Befunds, in jedem Artefakt identisch als Abschnittstitel geschrieben, ist seine Identität in der gesamten Kette. Die Tracking-Map (`.lagune/tracking.json`) enthält nur Daten zur Nachverfolgung, nie Fließtext. ## Häufige Fragen ### Was ist Security-Driven Hardening (SDH)? SDH ist eine kontextbezogene Blue-Team-Methodik für die Sicherheit. Sie erkennt den Kontext eines Systems, priorisiert die Risiken dieses Kontexts und leitet die Korrekturen an, wobei jeder Befund in einfacher Sprache bleibt. Lagune ist ihre Referenzimplementierung. ### Was sind die Sicherheitsprinzipien (charter) in Lagune? Die Sicherheitsprinzipien sind die übergeordnete Ebene von Lagune: Prinzipien, die Sicherheit an erste Stelle setzen und die jede spätere Phase einhalten muss. Sie liegen unter .lagune/memory/charter.md. ### Was bedeutet es, einen Befund auszutragen? Wenn verify nachweist, dass ein Risiko geschlossen ist, wird der Befund ausgetragen: Er wird mit deiner Bestätigung aus der gesamten Kette entfernt und danach nicht mehr erneut verarbeitet. --- # Konfigurationsschema > Das JSON Schema für die Konfiguration eines Projekts mit Lagune, für Autovervollständigung und Validierung in deinem Editor, passend zur aktuellen Version von Lagune oder fest an eine Version gebunden. Kanonische URL: https://lagune.ai/de-DE/docs/references/configs-schema Sprache: de-DE Original: https://lagune.ai/docs/references/configs-schema Zuletzt aktualisiert: 2026-11-03 Die Datei `.lagune/configs.json` hält die [**Kategorien**](https://lagune.ai/de-DE/docs/categories) fest, die ein Projekt nutzt, und indexiert seine eigenen [**Spezialisierungen**](https://lagune.ai/de-DE/docs/catalog). Mit ihrem JSON Schema vervollständigt dein Editor jedes Feld automatisch und meldet einen Tippfehler oder eine unbekannte Kategorie, während du die Datei bearbeitest. ## Das aktuelle Schema Immer wenn **Lagune** die Datei schreibt und darin kein `$schema` findet, trägt es das aktuelle Schema ein: ```json { "$schema": "https://lagune.ai/schemas/configs.json", "categories": ["owasp", "javascript"] } ``` Diese Adresse folgt immer der aktuellen Version von **Lagune**. Eine Datei, die vor **Lagune** 0.16.0 geschrieben wurde, erhält sie bei ihrer nächsten Änderung, und bis dahin weist jede Phase darauf hin. ## Eine Version festlegen Jedes Release von **Lagune** ab 0.16.0 enthält das Schema so, wie es in dieser Version war, veröffentlicht auf **npm** und ausgeliefert über **jsDelivr**. Um eine Version festzulegen, trage die Version hinter `lagune@` in die Adresse von `$schema` ein: ```json { "$schema": "https://cdn.jsdelivr.net/npm/lagune@0.16.0/schemas/configs.json" } ``` Als Version ist jeder semver-Bereich möglich: | Version | Schema | | -------------------- | --------------------------------- | | `0.16.0` | Das aus 0.16.0 | | `0.16.x` oder `0.16` | Das aus dem neuesten Release 0.16 | | `0.x` oder `0` | Das aus dem neuesten Release 0.x | | `latest` | Das aus dem neuesten Release | ## Häufige Fragen ### Braucht Lagune das Schema? Nein. Das Schema hilft nur deinem Editor, und Lagune liest die Datei mit oder ohne $schema genauso. ### Überschreibt Lagune ein festgelegtes Schema? Nein. Lagune schreibt $schema nur, wenn die Datei keins enthält, und behält jede Adresse bei, die du gesetzt hast. ### Wann sollte ich eine Version festlegen? Wenn das Projekt eine bestimmte Version von Lagune nutzt, damit dein Editor die Datei gegen das prüft, was diese Version akzeptiert. --- # Lagune vs. Deepsec: zwei KI-gestützte Sicherheitsansätze im direkten Vergleich > Eine Referenz, die Lagune und Deepsec von Vercel vergleicht: Funktionsweise, Lebenszyklus, Erkennung, Kosten, Befunde und Abschluss. Kanonische URL: https://lagune.ai/de-DE/docs/references/deepsec Sprache: de-DE Original: https://lagune.ai/docs/references/deepsec Zuletzt aktualisiert: 2026-11-03 [Lagune](https://github.com/wellwelwel/lagune) und [Deepsec](https://github.com/vercel-labs/deepsec) (`v2.2.1`) sind zwei defensive Antworten auf dasselbe Problem: Sicherheit im Zeitalter KI-gestützter Entwicklung. Ihre Grundannahme, ihr Anfang, ihre Mitte und ihr Ende sowie die Art, wie sich jedes Projekt seinen Nutzern präsentiert, gehen bewusst auseinander, auch dort, wo sich ihre Mechanik überschneidet. **Tipp** Ist Lagune von Deepsec inspiriert? Nein, Lagune ist von Grund auf neu geschrieben und von Spec-Driven Development und Security Hardening inspiriert. Die beiden Projekte sind unabhängig voneinander entstanden, und dieser Vergleich soll Nutzern helfen, ihre Unterschiede zu verstehen. ## Auf einen Blick | Aspekt | Lagune | Deepsec | | ------------------ | ----------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------- | | Art | Eine Methodik (SDH) mit einer Referenzimplementierung | Ein Produkt: ein agentengestützter Schwachstellenscanner | | Schwerpunkt | Sicherheitsprinzipien und bei Bedarf geladenes Wissen steuern den Agenten, gestützt auf deterministische Hooks | Ein weites Regex-Netz speist eine verpflichtende KI-Untersuchung | | Ergebnis | Gehärteter Code, Nachweise und eine nachverfolgte Kette von Befunden | Ein triagierter Bericht mit Befunden, nach Schweregrad geordnet | | Ändert deinen Code | Ja: `harden` bearbeitet deinen Code | Nein: nur statische Analyse, liefert Befunde und Empfehlungstexte | | Ausführung | Läuft mit dem Agenten und dem Modell, die du bereits nutzt, in jeder Modellklasse | Betreibt eine eigene Modell-Pipeline, standardmäßig mit einem Frontier-Modell | | Erste Schritte | Ein Plugin installieren oder `npx skills add`, dann in einfacher Sprache steuern, ohne ein neues Tool aufzusetzen | Einen Workspace `.deepsec/` aufsetzen, Abhängigkeiten installieren und einen Modellschlüssel hinterlegen | ## So funktioniert es Bei Lagune steht der Agent an erster Stelle: Er steuert, lädt bei Bedarf das Wissen, das zum Code passt, und überlässt den deterministischen Hooks den Teil, den sie entscheiden können. Bei Deepsec steht das Deterministische an erster Stelle: Ein breiter Durchlauf meldet Kandidaten, die einem verpflichtenden Modell zeigen, was es untersuchen und beurteilen soll. | Aspekt | Lagune | Deepsec | | ---------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------ | | Reihenfolge | Sicherheitsprinzipien und passendes Wissen lenken den Agenten, der an Hooks delegiert und den Rest selbst beurteilt | Matcher melden Kandidaten, das Modell untersucht und beurteilt jeden einzelnen | | Deterministische Rolle | Hooks für mehrere Programmiersprachen, die ein Urteil liefern oder den Agenten ausrichten, kombiniert mit dem Wissen der Kategorien | Matcher, die Kandidaten melden, damit das verpflichtende Modell sie beurteilt | | Entwicklungs-Workflow | `/lagune` entwickelt sicher mit, direkt während du programmierst | Es prüft Code, schreibt ihn aber nicht | | Audit-Workflow | `charter` → `detect` → `plan` → `harden` → `verify` | `scan` → `process` → `triage` → `revalidate` → `report` | | Aufgabe der KI | Aus dem Wissen schlussfolgern, die Korrektur umsetzen und nachweisen, dass sie greift | Jeden Kandidaten untersuchen und die Befunde berichten | ## Lebenszyklus Lagune wirkt vor, während und nach dem Schreiben des Codes. Deepsec prüft ein Repository, sobald der Code existiert. | Zeitpunkt | Lagune | Deepsec | | ----------------------- | ----------------------------------------------------------------------------------- | ---------------------------------------------------------------------------- | | Bevor Code existiert | `charter` leitet aus der erklärten Absicht eine Sicherheitsrichtlinie ab | Setzt bei bestehendem Code an: `init` braucht ein Verzeichnis | | Während der Entwicklung | `/lagune` entwickelt direkt standardmäßig sicher, ohne ein Artefakt zu hinterlassen | Prüft nach der Entwicklung, nicht währenddessen | | Bei bestehendem Code | `detect` → `plan` → `harden` → `verify` | `scan` → `process`, der zentrale Workflow | | Fortlaufende Prüfung | Phasen je Umfang erneut ausführen, kein fertiges CI-Gate | Inkrementeller erneuter Durchlauf, `process --diff` als Exit-Gate für die CI | ## Erkennungsebene Die beiden deterministischen Ebenen sind grundverschieden: Die eine entscheidet, die andere meldet. | Aspekt | Lagune | Deepsec | | --------------- | ------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------- | | Gruppierung | Hooks und Spezialisierungen, in Kategorien gruppiert | Matcher je Muster oder Framework | | Ausgabe | Wörtliches Urteil (finding / review / advisory) plus ein Klassifizierungslabel | Kandidat ohne Urteil (Slug, Zeilen, Codeausschnitt, gefundenes Muster) | | Abstimmung | Präzision: erkennt Kommentare, Schutzregeln für Platzhalter und Suchfenster | Recall: weite Netze, die KI sortiert False Positives danach aus | | Tiefe | Tiefer bei den gemeinsam abgedeckten Klassen | Breiter, aber weniger tief bei den gemeinsam abgedeckten Klassen | | False Positives | Schon an der Quelle gering gehalten, dann im Kontext beurteilt | Absichtlich im Überfluss erzeugt, dann durch einen Durchlauf von `revalidate` reduziert | ## Wissen und Urteil Beide bringen Sicherheitswissen mit, das Regex allein nicht abbilden kann. Sie unterscheiden sich darin, wo es liegt und wer es gestalten kann. | Aspekt | Lagune | Deepsec | | ------------------- | --------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- | | Form | Bearbeitbare Markdown-Module, mehrere davon durch einen deterministischen Hook gestützt | Ein kurzer Prompt und Hinweise je Technologie, gestützt auf das eigene Wissen des Modells | | Auswahl | Auf den Code abgestimmt, nur geladen, wenn sein Kontext vorhanden ist | In jeden KI-Batch eingefügt, dazu Hinweise für die erkannte Technologie | | Wer es verfasst | Der Nutzer bearbeitet Module und fügt mit `specialize` neue hinzu | Der Maintainer verantwortet den Prompt, der Nutzer füllt eine `INFO.md` aus | | Wo das Urteil fällt | Die Hooks entscheiden die Basis, der Agent beurteilt den Rest anhand des Wissens | Zentral: Ein einziger KI-Prozessor beurteilt jeden Kandidaten | | Wiederverwendung | Ein Modul leitet sowohl `detect` als auch `verify` | Ein Prompt steuert die einzige Stufe `process` | ## Befunde und Abschluss Am stärksten unterscheiden sie sich darin, was aus einem Befund wird, sobald er gelöst ist. | Aspekt | Lagune | Deepsec | | ----------------------- | ----------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- | | Schweregrad | Eine Bewertung nach CVSS v4.0, angepasst an Exposition und Tragweite | Ein Schweregrad von der KI, dazu eine Triage P0 / P1 / P2 nach Ausnutzbarkeit und Auswirkung | | Urteile | Risk closed, Risk not closed oder Cannot tell from the code | true-positive, false-positive, fixed, uncertain, accepted-risk, duplicate | | Persistenz | Die Arbeitskette wird abgeglichen, abgeschlossene Befunde werden zu einer Historie verdichtet | Einträge je Datei, die nur ergänzt werden, nichts wird entfernt | | Endzustand | Abschließbar: Ein nachgewiesener Befund wird ausgetragen, die Kette kann in den Ruhezustand übergehen | Jeder Befund bleibt dauerhaft erhalten und wird nach der Lösung in den Ansichten ausgeblendet | | Detailgrad der Historie | Eine kompakte Zusammenfassung dessen, was das Risiko war | Die vollständige Spur der Urteile, einschließlich dessen, wie es behoben wurde | ## Kosten | Aspekt | Lagune | Deepsec | | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Deterministische Basis | Kostenlos: Hooks laufen ohne KI und ohne Schlüssel und liefern bereits Urteile | Kostenlos: `scan` läuft ohne KI, liefert allein aber keine Urteile | | Typische Kosten | In einem Agenten enthalten, den du bereits nutzt: ab 0 US-Dollar mit einem lokalen Modell, zum Preis des Abos, das du schon hast, oder pro Iteration bei Nutzung über eine API | [Etwa 25 bis 1200 US-Dollar pro Durchlauf für 100 bis 2000 Dateien, bei größerem Umfang mehr](https://github.com/vercel-labs/deepsec/blob/f75a16803ec5250938bacfe41571d929e8564f45/docs/getting-started.md#run-the-ai-investigation) | | Günstigster Weg | Jedes Modell, auch ein kostenloses lokales, schließt den Zyklus ab | Es gibt günstigere kostenpflichtige Modellklassen, aber Befunde erfordern die kostenpflichtige KI-Stufe | ## Erweiterbarkeit und Governance Jedes öffnet die Ebene, die das andere geschlossen hält. | Aspekt | Lagune | Deepsec | | ---------------------- | -------------------------------------------------------------------- | ------------------------------------------------------------------- | | Was du erweiterst | Module bearbeiten oder über `specialize` neue hinzufügen | Matcher, Agenten, Benachrichtigungen und Zuständigkeiten hinzufügen | | Richtlinienebene | Die Sicherheitsprinzipien gelten für jede Phase und sind versioniert | Die Konfiguration ist betrieblich (Matcher, Modelle, Pfade) | | Überschreiben per Name | Ein verfeinertes Modul überdeckt das integrierte | Bei einer Kollision von Matcher-Slugs gewinnt dein Matcher | ## Schnittstellen Deepsec liefert Ergebnisse für eine Sicherheitsorganisation. Lagune zeigt eine Live-Ansicht für die Person, die es ausführt. | Aspekt | Lagune | Deepsec | | ------------------------- | ------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- | | Oberfläche für Menschen | Ein lokales Live-Dashboard der gesamten Kette, in einfacher Sprache | Dateien für Bericht, Export, Metriken und PR-Kommentare, dazu eine Dokumentationsseite | | Verantwortlichkeit | Zeigt Dateien und die angewendeten Spezialisierungen | Schlägt eine zuständige Person vor: Rufbereitschaft, Manager oder Committer | | Reproduzierbarer Nachweis | `prove` schreibt ausführbare Tests und einen Sicherheitshinweis zur Offenlegung | Bleibt bewusst statisch und führt das Ziel nie aus | | Selbstschutz des Tools | Härtet eine lokale Schreib-API im Dashboard | Härtet die eigene KI-Ausführung gegen nicht vertrauenswürdigen Zielcode | ## Skalierung und Bereitstellung | Aspekt | Lagune | Deepsec | | ------------------- | ------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------- | | Installation | Neun Befehle aus dem Plugin deines Agenten oder über die CLI von **skills**, ohne etwas im Projekt anzulegen | Ein Workspace `.deepsec/` mit eigenem Paket und eigenen Abhängigkeiten | | Skalierungsrichtung | Beschränkt sich auf jeden beliebigen Ausschnitt, einen Kontext, von einer Datei bis zum ganzen Projekt | Durchsucht ganze Repositories, bis hin zu großen Monorepos | | Verteilung | Nur lokal, der einzige Server lauscht auf Loopback | Optional auf Worker-VMs von Vercel Sandbox verteilt | ## Nutzererfahrung Wie beide der Person begegnen, die sie ausführt: was der erste Durchlauf erfordert und wie man sie ausrichtet. ### Einstieg Lagune läuft über den Agenten, der bereits geöffnet ist. Deepsec richtet zuerst einen eigenen Workspace und den Zugang zum Modell ein. | Aspekt | Lagune | Deepsec | | -------------------------- | ------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ | | Erster Befehl | Die Installation des Plugins oder `npx skills add wellwelwel/lagune`, dann `/lagune-*` im Agenten | `npx deepsec init`, dann `cd .deepsec`, `pnpm install`, `scan`, `process` | | Zugangsdaten zum Ausführen | Kein separater Schlüssel, es nutzt deinen aktuellen Agenten | Ein Modellschlüssel (z. B. AI Gateway, ein 12 Stunden gültiges OIDC-Token von Vercel oder ein Token von Anthropic) | ### Steuerung Beide lassen sich steuern. Lagune liest in jeder Phase die Form der Eingabe. Deepsec grenzt die Dateimenge ein, über die dieselbe Untersuchung läuft. | Aspekt | Lagune | Deepsec | | -------------------- | ----------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------- | | Ganzes Projekt | Eine Phase ohne Eingabe durchsucht den gesamten Umfang | `scan` und `process` durchsuchen das Repository | | Ein Ausschnitt | Jede Phase lässt sich auf angegebene Dateien oder Verzeichnisse beschränken | `--files`, `--files-from` oder `--diff` grenzen den Durchlauf ein | | Ein Anliegen | Eine Phase lässt sich auf eine beschriebene Sorge beschränken | Der Prompt der Untersuchung ist fest vorgegeben | | Eine Prioritätsstufe | `harden` und `verify` lassen sich auf den Schweregrad kritisch, hoch, mittel oder niedrig beschränken | Befunde werden nach dem Durchlauf eingestuft | | Ein einzelner Wert | Ein Hook bewertet direkt einen Codeausschnitt, ein Muster oder eine URL (`--pattern`, `--url`) | Die Arbeitseinheit ist eine Datei | ## Häufige Fragen ### Was unterscheidet Lagune von Deepsec? Bei Lagune steht der Agent an erster Stelle, und es wirkt vor, während und nach dem Schreiben des Codes: Es legt Richtlinien fest, bevor Code entsteht, härtet direkt während der Entwicklung und auditiert, härtet und verifiziert bereits geschriebenen Code. Bei Deepsec steht das Deterministische an erster Stelle: Ein breiter Regex-Durchlauf speist eine verpflichtende Untersuchung durch ein Frontier-Modell, die bestehenden Code prüft und Befunde meldet, ohne ihn zu ändern. ### Kann ich eines der beiden kostenlos nutzen? Der gesamte Workflow von Lagune kann mit einem kostenlosen lokalen Modell für 0 US-Dollar laufen, und die deterministischen Hooks liefern ganz ohne KI Urteile. Der Scan von Deepsec ist kostenlos, liefert aber keine Urteile, sodass jeder Befund die kostenpflichtige KI-Stufe erfordert. ### Verändert eines der beiden meinen Code? Lagune schon: harden setzt Korrekturen in deinem Code um. Deepsec nicht: Es führt nur eine statische Analyse durch und liefert Befunde und Empfehlungstexte, die eine Person oder ein Agent separat umsetzt. --- # OWASP-Quellen > Woher das Wissen der integrierten OWASP-Spezialisierungen stammt, zugeordnet zu den kanonischen OWASP-Seiten der Angriffe und Cheat Sheets. Kanonische URL: https://lagune.ai/de-DE/docs/references/owasp-sources Sprache: de-DE Original: https://lagune.ai/docs/references/owasp-sources Zuletzt aktualisiert: 2026-11-03 Dieses Dokument ordnet jeden **Angriff** (`www-community`) und jedes **Cheat Sheet** (`CheatSheetSeries`) von OWASP einer Sicherheitskategorie zu, jeweils mit einem Link auf die kanonische öffentliche Seite. Innerhalb einer Kategorie teilen sich gleichwertige Einträge eine einzige Zeile der Checkliste: Angriffe und Cheat Sheets, die dasselbe Risiko behandeln, stehen kommagetrennt zusammen. Einträge ohne direktes Gegenstück stehen in einer eigenen Zeile. - Die Urheberschaft liegt bei OWASP. Die Angriffe stehen unter `https://owasp.org/www-community/attacks/`, die Cheat Sheets unter `https://cheatsheetseries.owasp.org/cheatsheets/.html`. --- ## 1. Injection (allgemein) - [x] [Code Injection](https://owasp.org/www-community/attacks/Code_Injection), [Injection Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet.html), [Injection Prevention in Java](https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_in_Java_Cheat_Sheet.html) (interpreter) - [x] [Direct Dynamic Code Evaluation (Eval Injection)](https://owasp.org/www-community/attacks/Direct_Dynamic_Code_Evaluation_Eval_Injection) (interpreter) - [x] [Function Injection](https://owasp.org/www-community/attacks/Function_Injection) (interpreter) - [x] [Resource Injection](https://owasp.org/www-community/attacks/Resource_Injection) (network) - [x] [Special Element Injection](https://owasp.org/www-community/attacks/Special_Element_Injection) (interpreter) - [x] [Custom Special Character Injection](https://owasp.org/www-community/attacks/Custom_Special_Character_Injection) (interpreter) - [x] [Comment Injection Attack](https://owasp.org/www-community/attacks/Comment_Injection_Attack) (interpreter) - [x] [Parameter Delimiter](https://owasp.org/www-community/attacks/Parameter_Delimiter) (interpreter) - [x] [Server-Side Includes (SSI) Injection](https://owasp.org/www-community/attacks/Server-Side_Includes_%28SSI%29_Injection) (interpreter) - [x] [Input Validation](https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html), [Bean Validation](https://cheatsheetseries.owasp.org/cheatsheets/Bean_Validation_Cheat_Sheet.html) (interpreter) --- ## 2. SQL- und Datenbank-Injection - [x] [SQL Injection](https://owasp.org/www-community/attacks/SQL_Injection), [SQL Injection Prevention](https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html), [Query Parameterization](https://cheatsheetseries.owasp.org/cheatsheets/Query_Parameterization_Cheat_Sheet.html) (sql) - [x] [Blind SQL Injection](https://owasp.org/www-community/attacks/Blind_SQL_Injection) (sql) - [x] [SQL Injection Bypassing WAF](https://owasp.org/www-community/attacks/SQL_Injection_Bypassing_WAF) (sql) - [x] [RSQL Injection](https://owasp.org/www-community/attacks/RSQL_Injection) (interpreter) - [x] [Database Security](https://cheatsheetseries.owasp.org/cheatsheets/Database_Security_Cheat_Sheet.html) (sql) - [x] [NoSQL Security](https://cheatsheetseries.owasp.org/cheatsheets/NoSQL_Security_Cheat_Sheet.html) (interpreter) --- ## 3. OS-Command-Injection - [x] [Command Injection](https://owasp.org/www-community/attacks/Command_Injection), [OS Command Injection Defense](https://cheatsheetseries.owasp.org/cheatsheets/OS_Command_Injection_Defense_Cheat_Sheet.html) (interpreter) --- ## 4. LDAP-, XPath- und XML-Injection - [x] [LDAP Injection](https://owasp.org/www-community/attacks/LDAP_Injection), [LDAP Injection Prevention](https://cheatsheetseries.owasp.org/cheatsheets/LDAP_Injection_Prevention_Cheat_Sheet.html) (interpreter) - [x] [XPATH Injection](https://owasp.org/www-community/attacks/XPATH_Injection) (interpreter) - [x] [Blind XPath Injection](https://owasp.org/www-community/attacks/Blind_XPath_Injection) (interpreter) - [x] [XML External Entity (XXE) Prevention](https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html), [XML Security](https://cheatsheetseries.owasp.org/cheatsheets/XML_Security_Cheat_Sheet.html) (xml) --- ## 5. Cross-Site Scripting (XSS) - [x] [Cross Site Scripting (XSS)](https://owasp.org/www-community/attacks/Cross-site-Scripting-%28XSS%29), [Cross Site Scripting Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html), [XSS Filter Evasion](https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet.html) (browser) - [x] [DOM Based XSS](https://owasp.org/www-community/attacks/DOM_Based_XSS), [DOM based XSS Prevention](https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.html), [DOM Clobbering Prevention](https://cheatsheetseries.owasp.org/cheatsheets/DOM_Clobbering_Prevention_Cheat_Sheet.html) (browser) - [x] [Reflected DOM Injection](https://owasp.org/www-community/attacks/Reflected_DOM_Injection) (browser) - [x] [XSS in Converting File Content to Text](https://owasp.org/www-community/attacks/XSS_in_Converting_File_Content_to_Text) (browser) - [x] [XSS in subtitle](https://owasp.org/www-community/attacks/Xss_in_subtitle) (browser) - [x] [Cross Frame Scripting](https://owasp.org/www-community/attacks/Cross_Frame_Scripting) (browser) - [x] [Cross Site Tracing](https://owasp.org/www-community/attacks/Cross_Site_Tracing) (browser) - [x] [Content Security Policy](https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html) (browser) --- ## 6. Cross-Site Request Forgery (CSRF) und Clickjacking - [x] [Cross Site Request Forgery (CSRF)](https://owasp.org/www-community/attacks/cross-site-request-forgery), [XSRF](https://owasp.org/www-community/attacks/XSRF), [Cross-Site Request Forgery Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html) (http-request) - [x] [Clickjacking](https://owasp.org/www-community/attacks/Clickjacking), [Clickjacking Defense](https://cheatsheetseries.owasp.org/cheatsheets/Clickjacking_Defense_Cheat_Sheet.html) (browser) - [x] [Cross Site History Manipulation (XSHM)](https://owasp.org/www-community/attacks/Cross_Site_History_Manipulation_%28XSHM%29) (browser) - [x] [Form action hijacking](https://owasp.org/www-community/attacks/Form_action_hijacking) (network) - [x] [Reverse Tabnabbing](https://owasp.org/www-community/attacks/Reverse_Tabnabbing) (browser) --- ## 7. Um- und Weiterleitungen - [x] [Open Redirect](https://owasp.org/www-community/attacks/open_redirect), [Unvalidated Redirects and Forwards](https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html) (network) - [x] [Execution After Redirect (EAR)](https://owasp.org/www-community/attacks/Execution_After_Redirect_%28EAR%29) (browser) --- ## 8. Zugriffskontrolle und Autorisierung - [x] [Insecure Direct Object Reference (IDOR)](https://owasp.org/www-community/attacks/insecure_direct_object_reference), [Insecure Direct Object Reference Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet.html) (access-control) - [x] [Forced browsing](https://owasp.org/www-community/attacks/Forced_browsing) (access-control) - [x] [Web Parameter Tampering](https://owasp.org/www-community/attacks/Web_Parameter_Tampering) (access-control) - [x] [Setting Manipulation](https://owasp.org/www-community/attacks/Setting_Manipulation) (access-control) - [x] [Authorization](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) (access-control) - [x] [Transaction Authorization](https://cheatsheetseries.owasp.org/cheatsheets/Transaction_Authorization_Cheat_Sheet.html) (access-control) - [x] [Mass Assignment](https://cheatsheetseries.owasp.org/cheatsheets/Mass_Assignment_Cheat_Sheet.html) (access-control) - [x] [Multi-Tenant Application Security](https://cheatsheetseries.owasp.org/cheatsheets/Multi_Tenant_Security_Cheat_Sheet.html) (access-control) --- ## 9. Authentifizierung und Zugangsdaten - [x] [Brute Force Attack](https://owasp.org/www-community/attacks/Brute_force_attack), [Password Spraying Attack](https://owasp.org/www-community/attacks/Password_Spraying_Attack), [Bot Management and Anti-Automation](https://cheatsheetseries.owasp.org/cheatsheets/Bot_Management_and_Anti-Automation_Cheat_Sheet.html) (credential-endpoint) - [x] [Credential stuffing](https://owasp.org/www-community/attacks/Credential_stuffing), [Credential Stuffing Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Credential_Stuffing_Prevention_Cheat_Sheet.html) (credential-endpoint) - [x] [Qrljacking](https://owasp.org/www-community/attacks/Qrljacking) (federation) - [x] [Authentication](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html), [Multifactor Authentication](https://cheatsheetseries.owasp.org/cheatsheets/Multifactor_Authentication_Cheat_Sheet.html) (access-control) - [x] [Password Storage](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html) (access-control) - [x] [Forgot Password](https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html), [Choosing and Using Security Questions](https://cheatsheetseries.owasp.org/cheatsheets/Choosing_and_Using_Security_Questions_Cheat_Sheet.html) (access-control) - [x] [Email Validation and Verification in Identity Systems](https://cheatsheetseries.owasp.org/cheatsheets/Email_Validation_and_Verification_Cheat_Sheet.html) (access-control) --- ## 10. Session-Management - [x] [Session fixation](https://owasp.org/www-community/attacks/Session_fixation), [Session hijacking attack](https://owasp.org/www-community/attacks/Session_hijacking_attack), [Session Prediction](https://owasp.org/www-community/attacks/Session_Prediction), [Session Management](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html) (access-control) - [x] [Cookie Theft Mitigation](https://cheatsheetseries.owasp.org/cheatsheets/Cookie_Theft_Mitigation_Cheat_Sheet.html) (access-control) --- ## 11. Identitätsföderation (OAuth, SAML und JWT) - [x] [OAuth 2.0 Protocol](https://cheatsheetseries.owasp.org/cheatsheets/OAuth2_Cheat_Sheet.html) (federation) - [x] [SAML Security](https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html) (federation) - [x] [JSON Web Token for Java](https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_for_Java_Cheat_Sheet.html) (federation) --- ## 12. Kryptografie und Transportsicherheit - [x] [Cryptanalysis](https://owasp.org/www-community/attacks/Cryptanalysis), [Cryptographic Storage](https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html), [Key Management](https://cheatsheetseries.owasp.org/cheatsheets/Key_Management_Cheat_Sheet.html) (crypto) - [x] [Manipulator-in-the-Middle (MITM)](https://owasp.org/www-community/attacks/Man-in-the-middle_attack), [Transport Layer Security](https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Security_Cheat_Sheet.html) (transport) - [x] [HTTP Strict Transport Security](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html) (transport) - [x] [Pinning](https://cheatsheetseries.owasp.org/cheatsheets/Pinning_Cheat_Sheet.html) (transport) --- ## 13. Server-Side Request Forgery (SSRF) - [x] [Server Side Request Forgery](https://owasp.org/www-community/attacks/Server_Side_Request_Forgery), [Server-Side Request Forgery Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html) (network) --- ## 14. Path Traversal und Dateiverarbeitung - [x] [Path Traversal](https://owasp.org/www-community/attacks/Path_Traversal) (path) - [x] [Binary Planting](https://owasp.org/www-community/attacks/Binary_planting) (path) - [x] [Windows ::DATA Alternate Data Stream](https://owasp.org/www-community/attacks/Windows_DATA_alternate_data_stream) (path) - [x] [Embedding Null Code](https://owasp.org/www-community/attacks/Embedding_Null_Code) (path) - [x] [File Upload](https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html) (upload) --- ## 15. Missbrauch des HTTP-Protokolls (Header, Caching, Splitting) - [x] [HTTP Response Splitting](https://owasp.org/www-community/attacks/HTTP_Response_Splitting), [Cross-User Defacement](https://owasp.org/www-community/attacks/Cross-User_Defacement) (interpreter) - [x] [HTTP Security Response Headers](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html) (aufgeteilt auf browser, transport, http-request und access-control) - [x] [Cache Poisoning](https://owasp.org/www-community/attacks/Cache_Poisoning) (interpreter) - [x] [IP Spoofing via HTTP Headers](https://owasp.org/www-community/attacks/ip_spoofing_via_http_headers) (http-request) --- ## 16. Kodierung und Content-Spoofing - [x] [Unicode Encoding](https://owasp.org/www-community/attacks/Unicode_Encoding) (interpreter) - [x] [Double Encoding](https://owasp.org/www-community/Double_Encoding) (interpreter) - [x] [Content Spoofing](https://owasp.org/www-community/attacks/Content_Spoofing) (browser) --- ## 17. CSV- und Tabellenkalkulations-Injection - [x] [CSV Injection](https://owasp.org/www-community/attacks/CSV_Injection) (csv) --- ## 18. CORS (Cross-Origin Resource Sharing) - [x] [CORS OriginHeaderScrutiny](https://owasp.org/www-community/attacks/CORS_OriginHeaderScrutiny) (http-request) - [x] [CORS RequestPreflightScrutiny](https://owasp.org/www-community/attacks/CORS_RequestPreflightScrutiny) (http-request) --- ## 19. Denial of Service - [x] [Regular expression Denial of Service (ReDoS)](https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS) (regex) --- ## 20. Speichersicherheit und nativer Code - [x] [Buffer Overflow Attack](https://owasp.org/www-community/attacks/Buffer_overflow_attack), [Buffer Overflow via Environment Variables](https://owasp.org/www-community/attacks/Buffer_Overflow_via_Environment_Variables) (c-cpp) - [x] [Format string attack](https://owasp.org/www-community/attacks/Format_string_attack) (c-cpp) --- ## 21. Mobile Code und Ausführung nicht vertrauenswürdigen Codes - [x] [Mobile code invoking untrusted mobile code](https://owasp.org/www-community/attacks/Mobile_code_invoking_untrusted_mobile_code) (interpreter) - [x] [Mobile code non-final public field](https://owasp.org/www-community/attacks/Mobile_code_non-final_public_field) (java) - [x] [Mobile code object hijack](https://owasp.org/www-community/attacks/Mobile_code_object_hijack) (java) --- ## 22. Deserialisierung - [x] [Deserialization](https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html) (aufgeteilt auf python, ruby, php, java und dotnet) --- ## 23. Malware und clientseitige Bedrohungen - [x] [Man-in-the-browser attack](https://owasp.org/www-community/attacks/Man-in-the-browser_attack), [Browser Extension Security Vulnerabilities](https://cheatsheetseries.owasp.org/cheatsheets/Browser_Extension_Vulnerabilities_Cheat_Sheet.html) (browser) - [x] [Third Party JavaScript Management](https://cheatsheetseries.owasp.org/cheatsheets/Third_Party_Javascript_Management_Cheat_Sheet.html) (browser) --- ## 24. Logging, Abstreitbarkeit und Fehlerbehandlung - [x] [Log Injection](https://owasp.org/www-community/attacks/Log_Injection), [Logging](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html), [Application Logging Vocabulary](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Vocabulary_Cheat_Sheet.html) (interpreter) - [x] [Repudiation Attack](https://owasp.org/www-community/attacks/Repudiation_Attack) (interpreter) --- ## 25. Geschäftslogik und Missbrauch von Funktionen Geschäftslogik und Missbrauch von Funktionen haben keine einzelne Angriffsfläche im Code, die eine Spezialisierung pro Angriffsfläche verteidigen könnte: Die Abwehr liegt im anwendungsspezifischen Design, nach derselben Überlegung, die auch die Bedrohungsmodellierung des Projekts leitet. Verschoben nach "Außerhalb des Geltungsbereichs". --- ## 26. KI-, LLM- und Agentensicherheit - [x] [Prompt Injection](https://owasp.org/www-community/attacks/prompt-injection), [LLM Prompt Injection Prevention](https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html) (llm) - [x] [MCP Tool Poisoning](https://owasp.org/www-community/attacks/MCP_Tool_Poisoning), [MCP (Model Context Protocol) Security](https://cheatsheetseries.owasp.org/cheatsheets/MCP_Security_Cheat_Sheet.html) (llm) - [x] [HITL Dialog Forging (Lies-in-the-Loop)](https://owasp.org/www-community/attacks/lies-in-the-loop) (llm) - [x] [AI Agent Security](https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html), [Secure Coding with AI](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Coding_with_AI_Cheat_Sheet.html) (llm) - [x] [Retrieval-Augmented Generation (RAG) Security](https://cheatsheetseries.owasp.org/cheatsheets/RAG_Security_Cheat_Sheet.html) (llm) - [x] [Secure AI/ML Model Ops](https://cheatsheetseries.owasp.org/cheatsheets/Secure_AI_Model_Ops_Cheat_Sheet.html) (llm) - [x] [AML and Sanctions Compliance for AI Agent Payments](https://cheatsheetseries.owasp.org/cheatsheets/AML_Sanctions_AI_Agent_Payments_Cheat_Sheet.html) (llm) --- ## 27. Prototype Pollution und Cross-Site Leaks - [x] [Prototype Pollution Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Prototype_Pollution_Prevention_Cheat_Sheet.html) (javascript) - [x] [Cross-site leaks (XS-Leaks)](https://cheatsheetseries.owasp.org/cheatsheets/XS_Leaks_Cheat_Sheet.html) (browser) --- ## 28. Frameworks und Sprachplattformen - [x] [Django Security](https://cheatsheetseries.owasp.org/cheatsheets/Django_Security_Cheat_Sheet.html), [Django REST Framework](https://cheatsheetseries.owasp.org/cheatsheets/Django_REST_Framework_Cheat_Sheet.html) (python) - [x] [Ruby on Rails](https://cheatsheetseries.owasp.org/cheatsheets/Ruby_on_Rails_Cheat_Sheet.html) (ruby) - [x] [Laravel](https://cheatsheetseries.owasp.org/cheatsheets/Laravel_Cheat_Sheet.html) (php) - [x] [Symfony](https://cheatsheetseries.owasp.org/cheatsheets/Symfony_Cheat_Sheet.html) (php) - [x] [Java Security](https://cheatsheetseries.owasp.org/cheatsheets/Java_Security_Cheat_Sheet.html) (java) - [x] [DotNet Security](https://cheatsheetseries.owasp.org/cheatsheets/DotNet_Security_Cheat_Sheet.html) (dotnet) - [x] [NodeJS Security](https://cheatsheetseries.owasp.org/cheatsheets/Nodejs_Security_Cheat_Sheet.html) (javascript) - [x] [PHP Configuration](https://cheatsheetseries.owasp.org/cheatsheets/PHP_Configuration_Cheat_Sheet.html) (php) --- ## 29. Web-Frontend und Browser - [x] [HTML5 Security](https://cheatsheetseries.owasp.org/cheatsheets/HTML5_Security_Cheat_Sheet.html) (browser) - [x] [AJAX Security](https://cheatsheetseries.owasp.org/cheatsheets/AJAX_Security_Cheat_Sheet.html) (browser) - [x] [Securing Cascading Style Sheets](https://cheatsheetseries.owasp.org/cheatsheets/Securing_Cascading_Style_Sheets_Cheat_Sheet.html) (aufgeteilt auf access-control und browser) --- ## 30. APIs und Dienste - [x] [GraphQL](https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html) (api-endpoint) - [x] [gRPC Security](https://cheatsheetseries.owasp.org/cheatsheets/gRPC_Security_Cheat_Sheet.html) (api-endpoint) - [x] [WebSocket Security](https://cheatsheetseries.owasp.org/cheatsheets/WebSocket_Security_Cheat_Sheet.html) (api-endpoint) --- ## 31. Cloud, Container und Infrastruktur Die Konfiguration von Containern und Workloads ist Configuration as Code, die Entwickler mit der App ausliefern (`Dockerfile`, Compose, `securityContext` des Pods), eine echte Angriffsfläche, die `harden` behebt und `verify` nachweist, und gehört deshalb zum Geltungsbereich. Die Cluster-Administration (RBAC, etcd, API-Server, Admission, Netzwerksegmentierung) ist Sache der Betreiber und bleibt außerhalb des Geltungsbereichs. - [x] [Docker Security](https://cheatsheetseries.owasp.org/cheatsheets/Docker_Security_Cheat_Sheet.html), [Node.js Docker](https://cheatsheetseries.owasp.org/cheatsheets/NodeJS_Docker_Cheat_Sheet.html) (container) - [x] [Kubernetes Security](https://cheatsheetseries.owasp.org/cheatsheets/Kubernetes_Security_Cheat_Sheet.html) (container: der Teil zu Workloads und Pods. Die Cluster-Administration bleibt außerhalb des Geltungsbereichs) - [x] [Serverless / FaaS Security](https://cheatsheetseries.owasp.org/cheatsheets/Serverless_FaaS_Security_Cheat_Sheet.html) (serverless) --- ## 32. Lieferkette und CI/CD - [x] [NPM Security](https://cheatsheetseries.owasp.org/cheatsheets/NPM_Security_Cheat_Sheet.html) (interpreter) - [x] [Dependency Graph & SBOM Best Practices](https://cheatsheetseries.owasp.org/cheatsheets/Dependency_Graph_SBOM_Cheat_Sheet.html), [Vulnerable Dependency Management](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerable_Dependency_Management_Cheat_Sheet.html) (interpreter) --- ## 33. Secrets und Konfiguration Die Verwaltung von Secrets ist Betriebsaufgabe: Vaults, CI/CD, Cloud-Konfiguration, Rotation. Der einzige Aspekt auf Code-Ebene (ein fest im Quellcode hinterlegtes Secret) ist Sache eines deterministischen Durchlaufs, keiner Risiko-Spezialisierung. Verschoben nach "Außerhalb des Geltungsbereichs". --- ## 34. Prozesse, Design und Governance Der Schutz der Privatsphäre von Nutzern ist eine Frage von Richtlinien und Design (Datenminimierung, Transparenz, Aufbewahrung), keine Angriffsfläche im Code, die eine Spezialisierung verteidigt. Verschoben nach "Außerhalb des Geltungsbereichs". --- ## 35. Zahlungen und Compliance - [x] [Secure Integration of Third-Party Payment Gateways](https://cheatsheetseries.owasp.org/cheatsheets/Third_Party_Payment_Gateway_Integration_Cheat_Sheet.html) (payment) --- ## 36. Embedded-Systeme, IoT und Spezialgebiete Die Sicherheit von Fahrzeugen und Drohnen gehört zum Gebiet der Embedded-Systeme (CAN-Bus, OTA-Firmware, Integrität von Sensoren und Funk, physischer Zugang), nicht zum Quellcode von Web- und API-Anwendungen, den Lagune auditiert. Verschoben nach "Außerhalb des Geltungsbereichs". --- ## Außerhalb des Geltungsbereichs (keine Angriffsfläche im Code) Diese Einträge sind kein Einsatzgebiet für Spezialisierungen und haben kein Kontrollkästchen: Es geht um Governance, Prozesse, betriebliche Härtung oder die Nutzung von Frameworks, ohne eine einzelne Angriffsfläche im Code, die eine Spezialisierung pro Angriffsfläche verteidigen könnte. Ihr Sicherheitswert ist real, liegt aber in Prozessen und Architektur (oder, bei einem Framework, im eigenen Skill der jeweiligen Sprache), nicht in einer Abwehr, die dieser Katalog mitliefert. Sie stehen hier als Referenz, nicht als offene Aufgaben. - [Authorization Regression Testing](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Regression_Testing_Cheat_Sheet.html), [Authorization Testing Automation](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Testing_Automation_Cheat_Sheet.html) - [JAAS](https://cheatsheetseries.owasp.org/cheatsheets/JAAS_Cheat_Sheet.html) - [Denial of Service](https://owasp.org/www-community/attacks/Denial_of_Service), [Denial of Service](https://cheatsheetseries.owasp.org/cheatsheets/Denial_of_Service_Cheat_Sheet.html) - [HTTP/2 Reset Attack](https://owasp.org/www-community/attacks/HTTP2_Reset_Attack) - [Traffic flood](https://owasp.org/www-community/attacks/Traffic_flood) - [Web Service Amplification Attack](https://owasp.org/www-community/attacks/web_service_amplificaiton) (Amplification über SOAP/WS-Addressing, eine betriebliche DoS-Variante ohne Angriffsfläche im Code) - [Cash Overflow](https://owasp.org/www-community/attacks/Cash_Overflow) - [Spyware](https://owasp.org/www-community/attacks/Spyware), [Trojan Horse](https://owasp.org/www-community/attacks/Trojan_Horse) (Malware auf den Geräten der Endnutzer, keine Angriffsfläche im Code des auditierten Projekts. Der Aspekt der Auslieferung im Browser liegt in `browser`) - [REST Security](https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html), [REST Assessment](https://cheatsheetseries.owasp.org/cheatsheets/REST_Assessment_Cheat_Sheet.html) - [Web Service Security](https://cheatsheetseries.owasp.org/cheatsheets/Web_Service_Security_Cheat_Sheet.html) - [Cloud Architecture Security](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Cloud_Architecture_Cheat_Sheet.html) (Design und Abwägungen: IAM gegenüber signierten URLs, öffentliche und private VPCs, Vertrauensgrenzen, geteilte Verantwortung. Anders als `container` bietet es keine konkrete Konfiguration, die eine Spezialisierung prüft) - [Infrastructure as Code Security](https://cheatsheetseries.owasp.org/cheatsheets/Infrastructure_as_Code_Security_Cheat_Sheet.html) (trotz des Namens geht es um SDLC-Prozesse und Werkzeuge zum _Verwalten_ von IaC: IDE-Plugins, statische Analyse, Image-Scans, CI/CD, Signierung. Es zeigt in keiner Terraform- oder CloudFormation-Datei den Weg von einem unsicheren Muster zur sicheren Form) - [Kubernetes Security](https://cheatsheetseries.owasp.org/cheatsheets/Kubernetes_Security_Cheat_Sheet.html) (_nur der Teil zur Cluster-Administration_: RBAC, etcd, API-Server, Admission. Der Teil zu Workloads und Pods gehört unter `container` zum Geltungsbereich) - [Network Segmentation](https://cheatsheetseries.owasp.org/cheatsheets/Network_Segmentation_Cheat_Sheet.html) (Netzwerkarchitektur und Firewall-Richtlinien) - [Subdomain Takeover Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Subdomain_Takeover_Prevention_Cheat_Sheet.html) (Lebenszyklus und Überwachung von DNS, kein Code) - [Secrets Management](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html) (Vaults, CI/CD, Rotation. Der Aspekt fest im Code hinterlegter Secrets ist Sache eines deterministischen Durchlaufs, keiner Risiko-Spezialisierung) - [C-Based Toolchain Hardening](https://cheatsheetseries.owasp.org/cheatsheets/C-Based_Toolchain_Hardening_Cheat_Sheet.html) (Compiler-, Linker- und Build-Flags, ohne Sink im Quellcode) - [Microservices Security](https://cheatsheetseries.owasp.org/cheatsheets/Microservices_Security_Cheat_Sheet.html), [Microservices based Security Arch Doc](https://cheatsheetseries.owasp.org/cheatsheets/Microservices_based_Security_Arch_Doc_Cheat_Sheet.html) - [Zero Trust Architecture](https://cheatsheetseries.owasp.org/cheatsheets/Zero_Trust_Architecture_Cheat_Sheet.html) - [CI/CD Security](https://cheatsheetseries.owasp.org/cheatsheets/CI_CD_Security_Cheat_Sheet.html), [GitHub Actions Security](https://cheatsheetseries.owasp.org/cheatsheets/GitHub_Actions_Security_Cheat_Sheet.html) - [Software Supply Chain Security](https://cheatsheetseries.owasp.org/cheatsheets/Software_Supply_Chain_Security_Cheat_Sheet.html) - [Error Handling](https://cheatsheetseries.owasp.org/cheatsheets/Error_Handling_Cheat_Sheet.html), [Full Path Disclosure](https://owasp.org/www-community/attacks/Full_Path_Disclosure) (globale Konfiguration der Fehlerbehandlung je Stack. Das Leck ist dieselbe Offenlegung, die die Fehlerbehandlung bereits regelt) - [Abuse of Functionality](https://owasp.org/www-community/attacks/Abuse_of_Functionality), [Business Logic Security](https://cheatsheetseries.owasp.org/cheatsheets/Business_Logic_Security_Cheat_Sheet.html), [Abuse Case _(historisch)_](https://cheatsheetseries.owasp.org/cheatsheets/Abuse_Case_Cheat_Sheet.html) (anwendungsspezifisches Design, kein einzelner Sink im Code) - [User Privacy Protection](https://cheatsheetseries.owasp.org/cheatsheets/User_Privacy_Protection_Cheat_Sheet.html) (Datenminimierung, Transparenz, Aufbewahrungsrichtlinien) - [Top 10 Automotive Security Vulnerabilities](https://cheatsheetseries.owasp.org/cheatsheets/Automotive_Security_Cheat_Sheet.html), [Drone Security](https://cheatsheetseries.owasp.org/cheatsheets/Drone_Security_Cheat_Sheet.html) (Gebiete der Embedded-Systeme: CAN-Bus, OTA-Firmware, Integrität von Sensoren und Funk, kein Web- oder API-Quellcode) - [Mobile Application Security](https://cheatsheetseries.owasp.org/cheatsheets/Mobile_Application_Security_Cheat_Sheet.html) (Härtung der Plattformen Android und iOS: Speicher, Biometrie, Pinning, personenbezogene Daten. Es hat keine einzelne Angriffsfläche im Code, und der Aspekt des Ladens nicht vertrauenswürdigen Codes ging an `interpreter`) - [Threat Modeling](https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html), [Threat Modeling _(Community-Seite)_](https://owasp.org/www-community/Threat_Modeling) - [Attack Surface Analysis](https://cheatsheetseries.owasp.org/cheatsheets/Attack_Surface_Analysis_Cheat_Sheet.html) - [Secure Product Design](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Product_Design_Cheat_Sheet.html) - [Secure Code Review](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Code_Review_Cheat_Sheet.html) - [Virtual Patching](https://cheatsheetseries.owasp.org/cheatsheets/Virtual_Patching_Cheat_Sheet.html) - [Vulnerability Disclosure](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html) - [Legacy Application Management](https://cheatsheetseries.owasp.org/cheatsheets/Legacy_Application_Management_Cheat_Sheet.html) - [Security Terminology](https://cheatsheetseries.owasp.org/cheatsheets/Security_Terminology_Cheat_Sheet.html) --- # /lagune-repair: Repariere die defekte Nachverfolgung von Befunden > Repariere die Kette, wenn eine Umbenennung oder eine verschobene Datei die Nachverfolgung von Lagune durcheinanderbringt. Kanonische URL: https://lagune.ai/de-DE/docs/commands/repair Sprache: de-DE Original: https://lagune.ai/docs/commands/repair Zuletzt aktualisiert: 2026-11-03 🧰 Repariere die Kette, wenn eine Umbenennung oder eine verschobene Datei sie durcheinanderbringt. **Interne Wartung, keine Sicherheitsphase** Repair ist keine sechste Phase im linearen Workflow. Der Befehl hat die Aufgabe, die Nachverfolgung stimmig zu halten. ```prompt # Der Befehl nimmt keine Eingabe: Er repariert immer die gesamte Kette /lagune-repair ``` ## So funktioniert es Jeder Befund aus detect ist ein nachverfolgter Eintrag, den plan, harden und verify weitertragen. Jede dieser Phasen bearbeitet ihn und führt ihn erneut unter seinem Namen auf. Dieser Name, der in jedem Artefakt identisch als Abschnittstitel steht, ist durchgehend seine Identität. Das einzig Veränderliche, das die Nachverfolgung speichert, sind die Dateipfade, auf die der Eintrag zeigt. Diese Pfade stehen nirgendwo sonst, daher kann eine Umbenennung oder eine verschobene Datei die Verknüpfung nur dort unterbrechen, nie in zwei auseinanderlaufenden Kopien. Passiert das, korrigiert repair die Tracking-Map (`.lagune/tracking.json`), damit die Identität die Umbenennung übersteht. Der Befehl liest die Artefakte und die Tracking-Map, liest deinen Quellcode nur, um den neuen Pfad einer umbenannten Datei zu erfahren, und verfasst nie Sicherheitsinhalte. Im selben Durchlauf prüft repair jedes Artefakt im Gedächtnis anhand seiner Vorlage und meldet, was davon abweicht, jeweils mit Verweis auf die Phase, die es behebt. **Tipp** - Repair rührt weder deinen Code noch die Textartefakte an, nur die Nachverfolgung. - Von Hand führst du den Befehl selten aus. Bemerkt eine Phase, dass die Kette inkonsistent ist, führt sie repair für dich aus und macht weiter. - Die Nachverfolgung, die der Befehl pflegt, liegt in `.lagune/tracking.json`, einem internen Zustand, den du nie von Hand bearbeitest. --- # Migrate: Stelle ein manifestbasiertes Lagune-Projekt auf die Skills und Plugins um > Stelle ein manifestbasiertes Lagune-Projekt auf die auf Skills basierende Version von Lagune um und behalte deine charter, deine Artefakte, die Nachverfolgung und deine eigenen Spezialisierungen. Kanonische URL: https://lagune.ai/de-DE/docs/commands/migrate Sprache: de-DE Original: https://lagune.ai/docs/commands/migrate Zuletzt aktualisiert: 2026-11-03 🔀 Stelle ein manifestbasiertes Projekt von **Lagune** auf die auf Skills basierende Version von **Lagune** um und behalte alles, was du geschrieben hast. **Hinweis zur Abkündigung** Ein Projekt mit Manifest funktioniert bis `v1.x` unverändert weiter: `npx lagune` übergibt `init`, `pull`, `update`, `add`, `remove`, `list` und das Dashboard an `lagune@0.15.0`, die letzte manifestbasierte Version. ## So stellst du um 1. Stelle sicher, dass deine aktuelle Arbeit committet ist, und führe migrate dann im Stammverzeichnis des Projekts aus: ```bash npx lagune migrate ``` 2. Committe die Änderungen von migrate in einem eigenen Commit, damit die Umstellung eine einzige, prüfbare Änderung bleibt. 3. Installiere die Befehle für deinen Agenten, wie es die [Installationsseite](https://lagune.ai/de-DE/docs) zeigt. 4. Hat das Projekt bereits ein Artefakt von detect, plan oder harden, bitte [`/lagune-repair`](https://lagune.ai/de-DE/docs/commands/repair), die alten Verweise darin und in deinen eigenen Spezialisierungen abzugleichen: ```prompt /lagune-repair Gleiche die angewendeten Spezialisierungen (früher Sub-Skills) in den Artefakten unter `.lagune/memory/` (`detect.md`, `plan.md` und `harden.md`) mit den Namen ab, die der neue Katalog auflistet, und schreibe jeden Aufruf, den meine eigenen Spezialisierungen in `.lagune/catalog/` an die alten Hooks in `.lagune/hooks/` richten, in einen Aufruf des Tools `lagune_read` oder `lagune_write` um. ``` ## Was sich ändert | Vorher | Nachher | | ----------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- | | `.lagune/templates/`, `.lagune/hooks/` und `.lagune/specializations.md` | Entfernt: Jeder Skill bringt seine Vorlage mit, und die Engine führt die Hooks aus | | Die Kopien der integrierten Spezialisierungen in `.lagune/skills/` | Entfernt: Die Engine liefert die integrierten aus | | Deine eigenen Spezialisierungen in `.lagune/skills/` | Verschoben nach `.lagune/catalog/` | | `.lagune/skills.json`, der Index deiner eigenen Spezialisierungen | Zusammengeführt in `.lagune/configs.json` | | Die Kategorien des Manifests | Eingetragen in `.lagune/configs.json` | | Die alten Agentenbefehle, etwa `/lagune.detect` | Entfernt: Mit der [Installation von **Lagune**](https://lagune.ai/de-DE/docs) kommen die neuen, etwa `/lagune-detect` | | Der Block von **Lagune** in `.gitignore` | Entfernt, zusammen mit der Datei, wenn sie sonst nichts enthielt | | `.lagune/proofs/`, von diesem Block ignoriert | Durch eine eigene `.gitignore` aus Commits herausgehalten | | `.lagune/manifest.json` | Gelöscht, als Letztes | Deine Sicherheitsarbeit bleibt, wie sie ist: die charter, das Artefakt, das jede Phase erzeugt hat, und die Tracking-Map mit den Pfaden, auf die jeder Befund zeigt. ## Häufige Fragen ### Muss ich migrieren? Ja. Manifestbasierte Projekte sind abgekündigt und funktionieren nur bis v1.x weiter, führe also npx lagune migrate aus, um deins umzustellen. ### Was behält migrate bei? Deine charter, jedes Artefakt der Phasen, die Tracking-Map, deine Kategorien und deine eigenen Spezialisierungen. Die Spezialisierungen ziehen nach .lagune/catalog/ um, und ihr Index landet zusammen mit deinen Kategorien in .lagune/configs.json. ### Wann installiere ich die neuen Befehle? Nach migrate, wie es die Installationsseite für deinen Agenten zeigt. Vorher zu installieren funktioniert auch, da migrate den neuen Befehl /lagune behält. ### Ein Teammitglied hat schon migriert. Was führe ich aus? Hol dir die Umstellung per Pull und führe dann einmal npx lagune migrate aus. Der Befehl entfernt, was die manifestbasierte Version von Lagune in deinem Klon hinterlassen hat und was die Versionsverwaltung nie mitgeführt hat, und hält deine Nachweise aus Commits heraus.