# Lagune > Security-Driven Hardening til enhver kodebase Lagune er et open source og udelukkende defensivt workflow til Security-Driven Hardening (SDH). Det hjælper din AI-agent med at hærde enhver kodebase i ethvert sprog, på ethvert tidspunkt: fasen charter fastlægger sikkerhedsreglerne, før du bygger, den universelle kommando /lagune hærder arbejdet, mens det bliver skrevet, og Blue Team-workflowet i fem faser finder ud af, hvad dit system rent faktisk gør, og driver de rettelser, der betyder noget i den kontekst. Kommandoerne installeres i din agent med CLI'en fra skills, og der kræves ingen API-nøgle. --- # Installation: sikkerhedshærdning til enhver AI-agent > Installér Lagune i ethvert projekt, som et plugin, hvor din agent understøtter det, og ellers med CLI'en fra skills, og vælg derefter de sikkerhedsspecialiseringer, der passer til det. Kanonisk URL: https://lagune.ai/da-DK/docs Sprog: da-DK Original: https://lagune.ai/docs Sidst opdateret: 2026-11-09 **Lagune** hjælper din AI-agent med at gøre et projekt mere sikkert. Du peger det mod din kode, og agenten finder ud af, hvad dit system rent faktisk gør, og guider dig derefter gennem det sikkerhedsarbejde, der betyder noget for det. **Lagune** er det første projekt i metoden [Security-Driven Hardening (SDH)](https://lagune.ai/da-DK/docs/references/paper). **Støt open source** Kan du lide **Lagune**? [Giv os en ⭐ på **GitHub**](https://github.com/wellwelwel/lagune) ## Vælg din agent - [Claude Code](https://lagune.ai/da-DK/docs/install/claude-code): Anthropics agentiske kodeværktøj - [Codex](https://lagune.ai/da-DK/docs/install/codex): OpenAIs kodeagent - [Cursor](https://lagune.ai/da-DK/docs/install/cursor): AI-kodeeditoren - [GitHub Copilot](https://lagune.ai/da-DK/docs/install/github-copilot-cli): GitHubs AI-makker til parprogrammering - [Gemini CLI](https://lagune.ai/da-DK/docs/install/gemini-cli): Googles open source-terminalagent - [Antigravity](https://lagune.ai/da-DK/docs/install/antigravity-cli): Googles agentiske udviklingsplatform - [OpenCode](https://lagune.ai/da-DK/docs/install/opencode): Kodeagenten med åben kildekode - [Devin for Terminal](https://lagune.ai/da-DK/docs/install/devin-cli): Cognitions terminalagent - [Factory Droid](https://lagune.ai/da-DK/docs/install/factory-droid): Factorys agent til softwareudvikling - [Grok Build](https://lagune.ai/da-DK/docs/install/grok-build): xAIs kodeagent - [Qwen Code](https://lagune.ai/da-DK/docs/install/qwen-code): Qwens kodeagent til terminalen - [Kimi Code](https://lagune.ai/da-DK/docs/install/kimi-code): Moonshot AIs kodeagent - [Muse Code](https://lagune.ai/da-DK/docs/install/muse-code): Metas kodeagent - [Pi](https://lagune.ai/da-DK/docs/install/pi): En minimal kodeagent til terminalen - [Hermes Agent](https://lagune.ai/da-DK/docs/install/hermes-agent): Nous Researchs open source-agent - [Universel](https://lagune.ai/da-DK/docs/install/universal): Cline, Kiro CLI, Windsurf, Zed og 66 mere **Info** - **Lagune** kører på **Node.js** bag kulisserne, men du bruger det sprog, du vil. - Hvis du vil køre helt offline, så installér **Lagune** i dit projekt med `npm i -D lagune@0.18.1`. ## Kategorier Sikkerhedsviden i **Lagune** kommer som [**specialiseringer**](https://lagune.ai/da-DK/docs/catalog), grupperet i [**kategorier**](https://lagune.ai/da-DK/docs/categories). - **OWASP** (`owasp`): Hærd mod de risici for applikationssikkerhed, som OWASP følger: injection, mangelfuld adgangskontrol, autentificering og kryptografiske fejl - **Infrastruktur** (`infra`): Hærd konfigurationen af containere, workloads og serverless: Dockerfile, Compose, Pod-sikkerhed, IAM og triggere til FaaS - **AI / LLM** (`ai`): Hærd AI- og LLM-integrationer mod prompt injection og usikker opkobling af værktøjer, agenter, retrieval og MCP - **Lovable** (`lovable`): Hærd AI-genererede Supabase-apps (Lovable og lignende): huller i RLS, lækkede nøgler til service_role og usikre standardindstillinger - **JavaScript** (`javascript`): Hærd JavaScript og dets runtimes mod RCE via eval og child_process, path traversal og prototype pollution - **Python** (`python`): Hærd Python mod RCE via deserialisering med pickle og YAML, traversal i str.format-strenge og class pollution - **Rust** (`rust`): Hærd Rust mod usunde unsafe-API'er, misbrug af transmute, heltalsoverløb og udefineret adfærd ved FFI-grænsen - **Java** (`java`): Hærd Java mod gadget chains ved deserialisering med ObjectInputStream, der ender i fjernafvikling af kode - **Ruby** (`ruby`): Hærd Ruby mod gadget chains ved deserialisering med Marshal.load og YAML, der fører til fjernafvikling af kode - **PHP** (`php`): Hærd PHP mod omgåelse af autentificering via type juggling, gadget chains ved object injection og usikre standardindstillinger i konfigurationen - **Go** (`go`): Hærd Go mod fejl med typede nil-interfaces, data races i goroutines og usikker samtidighed på sikkerhedskritiske stier - **C / C++** (`c-cpp`): Hærd C og C++ mod format string-fejl, bufferoverløb og skrivninger uden for grænserne, der giver mulighed for kodeafvikling - **.NET** (`dotnet`): Hærd .NET og C# mod RCE via deserialisering med BinaryFormatter og de omgåelser af encodere, der fører til XSS Kør `npx lagune write add --categories` med nøglerne for de kategorier, du vælger. **Tip** Et projekt starter med `owasp`, og [`/lagune-charter`](https://lagune.ai/da-DK/docs/commands/charter) tilføjer de kategorier, som dets læsning af projektet understøtter. ## Krav Du skal have [**Node.js (LTS)**](https://nodejs.org/en/download/package-manager) installeret på dit system. ## Brug et badge ✨ Bruger du **Lagune**? Tilføj et til din **README**: **To farver** ![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) ``` **Ensfarvet** ![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æste trin Se, hvad hver af [**Skills**](https://lagune.ai/da-DK/docs/get-started/commands) i **Lagune** gør. ## Ofte stillede spørgsmål ### Hvad er Lagune? Lagune er et open source og udelukkende defensivt sikkerhedsworkflow, der hjælper din AI-agent med at hærde enhver kodebase. Du peger det mod din kode, det finder ud af, hvad dit system rent faktisk gør, og guider derefter de sikkerhedsrettelser, der betyder noget i netop den kontekst. ### Hvordan installerer jeg Lagune? Vælg din agent: Claude Code, GitHub Copilot CLI, Muse Code, Antigravity CLI, Cursor, Kimi Code, OpenCode, Codex CLI, Factory Droid, Grok Build, Devin CLI og Hermes Agent installerer Lagune som et plugin, Gemini CLI og Qwen Code som en udvidelse, Pi som en pakke og alle andre agenter med npx skills add wellwelwel/lagune. Det virker i nye såvel som eksisterende projekter. ### Kræver Lagune en API-nøgle? Nej. Det kører gennem din egen AI-agent, så der kræves ingen API-nøgler. ### Hvad er kravene? Du skal have Node.js (LTS) installeret på dit system. ### Hvilke programmeringssprog understøtter Lagune? Alle. Lagune kører på Node.js bag kulisserne, men det gennemgår og hærder projekter skrevet i ethvert programmeringssprog. ### Hvad tilføjer Lagune til mit projekt? En mappe .lagune/ med dit projekts sikkerhedstilstand, oprettet af den første kommando, der skriver. CLI'en fra skills installerer også slash-kommandoerne i projektet, hvor din agent læser dem, mens et plugin holder dem inde i agenten. ### Hvordan opdaterer jeg Lagune? På samme måde, som du installerede det. Installationssiden for hver agent viser, hvordan du opdaterer Lagune dér, og CLI'en fra skills opdaterer det med npx skills update. Dine sikkerhedsprincipper, faseartefakter og egne specialiseringer forbliver uberørte. ### Hvilke specialiseringer bruger et projekt? De indbyggede i dets kategorier plus dets egne. Charter registrerer de kategorier, som dets læsning af projektet understøtter, og npx lagune write add --categories ændrer dem. ### Skal jeg være færdig med at bygge, før jeg sikrer mit projekt? Nej. Kommandoen /lagune hærder arbejdet, mens det bliver skrevet: den tager imod enhver prompt, bygger det, du bad om, og hærder det med sikre standardindstillinger, styret af sikkerhedsprincipperne. Blue Team-workflowet i fem faser gennemgår det, der allerede findes. ### Kan Lagune gennemgå et eksisterende projekt? Ja. Blue Team-workflowet i fem faser gennemgår det, der allerede findes: charter fastlægger dine sikkerhedsregler, detect kortlægger, hvad systemet gør, og hvor risiciene er, plan vurderer hvert fund og parrer det med en rettelse, harden gennemfører rettelserne, og verify påviser, at de holder, og afslutter dem. ### Hvad er forskellen på at bruge Lagune og blot bede agenten om at kortlægge sårbarheder og sikkerhedsfejl? En agent, der læser på egen hånd, finder det, der ligner en sårbarhed, og springer det over, der ligner en kontrol. En liste over blokerede adresser ser ud, som om nogen allerede har håndteret risikoen, så ingen tjekker, at den overser de fleste af dem, og koden bliver udgivet. Lagune vender den standard om: en beskyttelse, der allerede står i koden, anses for ubevist, indtil den er tjekket, hver specialisering i kataloget får en udtrykkelig afgørelse, og verify spørger, om risikoen er væk, ikke om der er en kontrol. Hvert fund forbliver desuden ét sporet punkt på tværs af kørsler, så det kan påvises lukket og tages ud, hvor en almindelig forespørgsel giver dig en ny rapport hver gang uden noget at sammenligne med. ### Hvad er forskellen på at udvikle med Lagune og blot bede agenten om at skrive sikker kode? At bede om sikker kode overlader definitionen af sikker til agenten, og det forudsætter, at du ved, hvad du skal bede om. Kravet ligger som regel allerede i din forespørgsel, uden at nogen af jer ser det: at bede om en side, der viser de kurser, en bruger har adgang til, udtrykker en autorisationsregel, og et tjek, der aldrig bliver skrevet, efterlader intet i koden at lægge mærke til. Kommandoen /lagune indlæser dine sikkerhedsprincipper og de specialiseringer, der passer til det, der skal bygges, før den første linje bliver skrevet, og læser derefter resultatet igen op mod det forsvar, den brugte. Den sikre form koster sjældent mere end den usikre, så det, der afgør resultatet, er at vide, hvilken man skal gribe efter, og det er netop det, der er på plads fra starten. ### Kører Lagune DAST (Dynamic Application Security Testing) eller tester min kørende applikation? Nej. Lagune læser kode og kører aldrig dit system eller sender det manipulerede forespørgsler. Verify bekræfter, at en kontrol findes og er korrekt i kildekoden, hvilket er et andet spørgsmål end, om den overlever et angreb mod et kørende mål, så "cannot tell from the code" er en legitim afgørelse i stedet for en stille godkendelse. DAST besvarer spørgsmålet om kørsel, og Lagune besvarer spørgsmålet om kildekoden, så ingen af dem erstatter den anden. Selv den valgfrie kommando prove holder den linje: dens tests bekræfter den sikre adfærd, aldrig en angrebspayload. ### Erstatter Lagune en pentest (penetrationstest)? Nej, bestemt ikke! En pentest er en autoriseret opgave, hvor en professionel bruger sin dømmekraft mod dit kørende system, kæder fund sammen og afprøver den forretningslogik, som ingen regel pr. overflade beskriver. Fund fra en pentest kan komme ind i Blue Team-workflowet i Lagune som bekymringer, du giver til detect, så det, en professionel rapporterer, bliver planlagt, hærdet og verificeret. ## Sikkerhedspolitik Læs venligst [SECURITY.md](https://github.com/wellwelwel/lagune/blob/main/SECURITY.md). ## Licens **Lagune** er udgivet under [Apache License 2.0](https://github.com/wellwelwel/lagune/blob/main/LICENSE). Copyright © 2026-nu [Weslley Araújo](https://github.com/wellwelwel) og [bidragydere](https://github.com/wellwelwel/lagune/graphs/contributors). --- # Installér Lagune i Antigravity CLI som et plugin > Installér Lagune i Antigravity CLI som et plugin, hold det opdateret, og giv dets motor tilladelse på forhånd. Kanonisk URL: https://lagune.ai/da-DK/docs/install/antigravity-cli Sprog: da-DK Original: https://lagune.ai/docs/install/antigravity-cli Sidst opdateret: 2026-11-09 Installér pluginnet fra din terminal: ```bash agy plugin install https://github.com/wellwelwel/lagune/tree/plugin-antigravity ``` ## Opdatering Installér **Lagune** igen for at opdatere det: ```bash agy plugin install https://github.com/wellwelwel/lagune/tree/plugin-antigravity ``` ## Kommandoer Skriv kommandoerne under pluginnets navn, såsom `/lagune:lagune-charter` for `/lagune-charter`. --- **Tilladelser** Motoren kører gennem to værktøjer: `lagune_read` læser kun dit projekt, og `lagune_write` skriver kun til `.lagune/`. En kommando, der sendes som en sessions første besked, kører, før de er indlæst, så den bruger **npx** i stedet. Hvis du vil give værktøjerne og **npx** tilladelse på forhånd, så tilføj disse regler til `~/.gemini/antigravity-cli/settings.json`: ```json { "permissions": { "allow": [ "mcp(lagune_lagune/lagune_read)", "mcp(lagune_lagune/lagune_write)", "command(regex:npx --yes lagune@[0-9.]+)" ] } } ``` ## Ofte stillede spørgsmål ### Hvordan installerer jeg Lagune i Antigravity CLI? Kør agy plugin install https://github.com/wellwelwel/lagune/tree/plugin-antigravity. ### Hvordan opdaterer jeg Lagune i Antigravity CLI? Kør agy plugin install https://github.com/wellwelwel/lagune/tree/plugin-antigravity igen. ### Hvordan kører jeg kommandoerne i Lagune i Antigravity CLI? Skriv dem under pluginnets navn, såsom /lagune:lagune-charter. ### Kan Antigravity CLI køre Lagune uden at bede om tilladelse? Ja. Tillad mcp(lagune_lagune/lagune_read), mcp(lagune_lagune/lagune_write) og command(regex:npx --yes lagune@[0-9.]+) i indstillingerne for Antigravity CLI. Reglen for npx dækker en kommando, der sendes som en sessions første besked. --- # Installér Lagune i Claude Code som et plugin > Installér Lagune i Claude Code som et plugin, i terminalen, udvidelsen eller desktopappen, hold det opdateret, og giv dets motor tilladelse på forhånd. Kanonisk URL: https://lagune.ai/da-DK/docs/install/claude-code Sprog: da-DK Original: https://lagune.ai/docs/install/claude-code Sidst opdateret: 2026-11-09 **Terminal** Installér pluginnet fra din terminal: ```bash claude plugin install lagune --marketplace wellwelwel/lagune ``` Eller fra en session i **Claude Code**: ```text /plugin marketplace add wellwelwel/lagune /plugin install lagune@lagune ``` **Udvidelse** - Skriv `/plugin`, og vælg **Manage plugins**. - Tilføj `wellwelwel/lagune` under fanen **Marketplaces**. - Installér `lagune` under fanen **Plugins**. **Desktop** - Installér **Lagune** fra terminalen eller udvidelsen, og vælg **Install for you** i udvidelsen. - Start en ny session i desktopappen, som indlæser de plugins, du installerer til dig selv. ## Opdatering **Terminal** Kør følgende for at opdatere **Lagune**: ```bash claude plugin marketplace update lagune claude plugin update lagune@lagune ``` Hvis du vil holde det opdateret, så vælg **Enable auto-update** for markedspladsen `lagune` under `/plugin`. **Udvidelse** - Skriv `/plugin`, og vælg **Manage plugins**. - Åbn fanen **Marketplaces**. - Vælg opdateringsikonet ved `lagune`. **Desktop** - Opdatér **Lagune** fra terminalen eller udvidelsen. - Start en ny session i desktopappen. ## Kommandoer Skriv kommandoerne ved deres navn, såsom `/lagune-charter`, eller under pluginnets navn, såsom `/lagune:lagune-charter`. --- **Tilladelser** Motoren kører gennem to værktøjer: `lagune_read` læser kun dit projekt, og `lagune_write` skriver kun til `.lagune/`. Hvis du vil give dem tilladelse på forhånd, så tilføj disse regler til `.claude/settings.json` for ét projekt eller til `~/.claude/settings.json` for dem alle: ```json { "permissions": { "allow": [ "mcp__plugin_lagune_lagune__lagune_read", "mcp__plugin_lagune_lagune__lagune_write" ] } } ``` Når motoren kører gennem **npx**, som med **skills.sh**, så tillad `Bash(npx --yes lagune@*)`. Med sandboxen slået til skal du også tilføje `registry.npmjs.org` til `sandbox.network.allowedDomains`. ## Ofte stillede spørgsmål ### Hvordan installerer jeg Lagune i Claude Code? Kør claude plugin install lagune --marketplace wellwelwel/lagune. I en session eller i udvidelsen tilføjer du markedspladsen wellwelwel/lagune fra pluginhåndteringen og installerer lagune. Desktopappen indlæser det, når du har installeret det til dig selv i terminalen eller udvidelsen. ### Hvordan opdaterer jeg Lagune i Claude Code? Kør claude plugin marketplace update lagune og derefter claude plugin update lagune@lagune, eller vælg Enable auto-update for markedspladsen lagune under /plugin. I udvidelsen åbner du Manage plugins fra /plugin og vælger opdateringsikonet ved markedspladsen lagune. Desktopappen indlæser opdateringen i sin næste session. ### Hvordan kører jeg kommandoerne i Lagune i Claude Code? Skriv dem ved deres navn, såsom /lagune-charter, eller under pluginnets navn, såsom /lagune:lagune-charter. ### Kan Claude Code køre Lagune uden at bede om tilladelse? Ja. Tillad mcp__plugin_lagune_lagune__lagune_read og mcp__plugin_lagune_lagune__lagune_write i dine indstillinger for Claude Code, plus Bash(npx --yes lagune@*), når motoren kører gennem npx. --- # Installér Lagune i Codex CLI som et plugin > Installér Lagune i Codex CLI som et plugin, hold det opdateret, og kør dets motor inde i sandboxen. Kanonisk URL: https://lagune.ai/da-DK/docs/install/codex Sprog: da-DK Original: https://lagune.ai/docs/install/codex Sidst opdateret: 2026-11-09 Installér pluginnet fra din terminal: ```bash codex plugin marketplace add wellwelwel/lagune codex plugin add lagune@lagune ``` ## Opdatering Kør følgende for at opdatere **Lagune**: ```bash codex plugin marketplace upgrade lagune ``` ## Kommandoer Skriv `$` og kommandoen under pluginnets navn efterfulgt af dit input, såsom `$lagune:lagune-charter` for `/lagune-charter`. Når du skriver `$`, vises kommandoerne, og når du vælger en, indsættes dens fulde navn. --- **Sandbox** Sandboxen i **Codex** har ingen netværksadgang. Installér motoren i dit projekt fra din egen terminal, én gang og efter hver opdatering: ```bash npm i -D lagune@0.18.1 ``` ## Ofte stillede spørgsmål ### Hvordan installerer jeg Lagune i Codex CLI? Kør codex plugin marketplace add wellwelwel/lagune og derefter codex plugin add lagune@lagune. ### Hvordan opdaterer jeg Lagune i Codex CLI? Kør codex plugin marketplace upgrade lagune. ### Hvordan kører jeg kommandoerne i Lagune i Codex CLI? Skriv $ og kommandoen under pluginnets navn efterfulgt af dit input, såsom $lagune:lagune-charter. ### Virker Lagune inde i sandboxen i Codex? Ja, når du har installeret motoren i dit projekt med npm i -D lagune@0.18.1 fra din egen terminal, én gang og efter hver opdatering. --- # Installér Lagune i Cursor som et plugin > Installér Lagune i Cursor og Cursor CLI som et plugin, hold det opdateret, og giv dets motor tilladelse på forhånd. Kanonisk URL: https://lagune.ai/da-DK/docs/install/cursor Sprog: da-DK Original: https://lagune.ai/docs/install/cursor Sidst opdateret: 2026-11-09 **Cursor** - Åbn **Customize**. - Vælg **From GitHub Repository**, og angiv `https://github.com/wellwelwel/lagune`. - Vælg **Install** ved **Lagune**, og vælg et omfang for projektet eller brugeren. **Cursor CLI** - Tilføj markedspladsen fra din terminal: ```bash agent plugin marketplace add https://github.com/wellwelwel/lagune --git-ref plugin-cursor ``` - Skriv `/plugins` i en session med `agent`. - Installér **Lagune**. Hvis **Lagune** allerede er installeret i **Claude Code**, indlæser **Cursor CLI** det derfra. ## Opdatering **Cursor** - Åbn **Customize**. - Vælg **Refresh** ved markedspladsen `lagune`. **Cursor CLI** - Udskift markedspladsen fra din terminal: ```bash agent plugin marketplace remove lagune agent plugin marketplace add https://github.com/wellwelwel/lagune --git-ref plugin-cursor ``` - Skriv `/plugins` i en session med `agent`. - Installér **Lagune** igen. ## Kommandoer Skriv kommandoerne ved deres navn, såsom `/lagune-charter`. --- **Tilladelser** I **Cursor** kører kommandoerne motoren gennem **npx**, som standardtilstanden Auto-review tillader uden at spørge. I **Cursor CLI** kører motoren gennem to værktøjer: `lagune_read` læser kun dit projekt, og `lagune_write` skriver kun til `.lagune/`. Hvis du vil give dem tilladelse på forhånd, så tilføj disse regler til `.cursor/cli.json` for ét projekt eller til `~/.cursor/cli-config.json` for dem alle: ```json { "permissions": { "allow": [ "Mcp(plugin-lagune-lagune:lagune_read)", "Mcp(plugin-lagune-lagune:lagune_write)" ] } } ``` Når motoren kører gennem **npx**, som med **skills.sh**, så tillad `Shell(npx:--yes lagune@*)`. ## Ofte stillede spørgsmål ### Hvordan installerer jeg Lagune i Cursor? I Cursor åbner du Customize, vælger From GitHub Repository, angiver https://github.com/wellwelwel/lagune og installerer Lagune. I Cursor CLI kører du agent plugin marketplace add https://github.com/wellwelwel/lagune --git-ref plugin-cursor og installerer derefter Lagune fra /plugins. ### Hvordan opdaterer jeg Lagune i Cursor? I Cursor vælger du Refresh ved markedspladsen lagune under Customize. I Cursor CLI fjerner du markedspladsen lagune, tilføjer den igen og installerer derefter Lagune igen fra /plugins. ### Hvordan kører jeg kommandoerne i Lagune i Cursor? Skriv dem ved deres navn, såsom /lagune-charter. ### Kan Cursor køre Lagune uden at bede om tilladelse? Ja. Standardtilstanden Auto-review i Cursor tillader det allerede. I Cursor CLI tillader du Mcp(plugin-lagune-lagune:lagune_read) og Mcp(plugin-lagune-lagune:lagune_write), plus Shell(npx:--yes lagune@*), når motoren kører gennem npx. --- # Installér Lagune i Devin CLI som et plugin > Installér Lagune i Devin CLI som et plugin, og hold det opdateret. Kanonisk URL: https://lagune.ai/da-DK/docs/install/devin-cli Sprog: da-DK Original: https://lagune.ai/docs/install/devin-cli Sidst opdateret: 2026-11-09 Log ind på **Devin**, og installér derefter pluginnet fra din terminal: ```bash devin auth login devin plugins install wellwelwel/lagune ``` ## Opdatering Kør følgende for at opdatere **Lagune**: ```bash devin plugins update lagune ``` ## Kommandoer Skriv kommandoerne under pluginnets navn, såsom `/lagune:lagune-charter` for `/lagune-charter`. Menuen `/` viser dem også. ## Ofte stillede spørgsmål ### Hvordan installerer jeg Lagune i Devin CLI? Log ind med devin auth login, og kør derefter devin plugins install wellwelwel/lagune. ### Hvordan opdaterer jeg Lagune i Devin CLI? Kør devin plugins update lagune. ### Hvordan kører jeg kommandoerne i Lagune i Devin CLI? Skriv dem under pluginnets navn, såsom /lagune:lagune-charter. Menuen / viser dem også. --- # Installér Lagune i Factory Droid som et plugin > Installér Lagune i Factory Droid som et plugin, hold det opdateret, og giv dets motors værktøjer tilladelse. Kanonisk URL: https://lagune.ai/da-DK/docs/install/factory-droid Sprog: da-DK Original: https://lagune.ai/docs/install/factory-droid Sidst opdateret: 2026-11-09 Installér pluginnet fra din terminal: ```bash droid plugin marketplace add wellwelwel/lagune droid plugin install lagune@lagune ``` ## Opdatering Kør følgende for at opdatere **Lagune**: ```bash droid plugin marketplace update lagune droid plugin update lagune@lagune ``` ## Kommandoer Skriv kommandoerne ved deres navn, såsom `/lagune-charter`. ## Ofte stillede spørgsmål ### Hvordan installerer jeg Lagune i Factory Droid? Kør droid plugin marketplace add wellwelwel/lagune og derefter droid plugin install lagune@lagune. ### Hvordan opdaterer jeg Lagune i Factory Droid? Kør droid plugin marketplace update lagune og derefter droid plugin update lagune@lagune. ### Hvordan kører jeg kommandoerne i Lagune i Factory Droid? Skriv dem ved deres navn, såsom /lagune-charter. ### Kan Factory Droid køre Lagune uden at bede om tilladelse? Ja. Vælg altid at tillade lagune_read og lagune_write, når Factory Droid spørger. Den spørger igen, efter at den har synkroniseret et nyt commit fra markedspladsen lagune. --- # Installér Lagune i Gemini CLI som en udvidelse > Installér Lagune i Gemini CLI som en udvidelse, hold det opdateret, og giv dets motor tilladelse på forhånd. Kanonisk URL: https://lagune.ai/da-DK/docs/install/gemini-cli Sprog: da-DK Original: https://lagune.ai/docs/install/gemini-cli Sidst opdateret: 2026-11-09 Installér udvidelsen fra din terminal: ```bash gemini extensions install https://github.com/wellwelwel/lagune ``` ## Opdatering Kør følgende for at opdatere **Lagune**: ```bash gemini extensions update lagune ``` Hvis du vil holde det opdateret, så installér det med `--auto-update`. ## Kommandoer Skriv kommandoerne under udvidelsens navn, såsom `/lagune:lagune-charter` for `/lagune-charter`. --- **Tilladelser** Motoren kører gennem to værktøjer: `lagune_read` læser kun dit projekt, og `lagune_write` skriver kun til `.lagune/`. **Gemini CLI** starter dem kun i en betroet mappe. Hvis du vil give dem tilladelse på forhånd, så gem denne regel som `~/.gemini/policies/lagune.toml`: ```toml [[rule]] mcpName = "lagune" toolName = ["lagune_read", "lagune_write"] decision = "allow" priority = 100 ``` Når motoren kører gennem **npx**, som med **skills.sh**, så tilføj denne regel til samme fil: ```toml [[rule]] toolName = "run_shell_command" commandRegex = 'npx --yes lagune@\d+\.\d+\.\d+\s' decision = "allow" priority = 100 ``` ## Ofte stillede spørgsmål ### Hvordan installerer jeg Lagune i Gemini CLI? Kør gemini extensions install https://github.com/wellwelwel/lagune. ### Hvordan opdaterer jeg Lagune i Gemini CLI? Kør gemini extensions update lagune, eller installér udvidelsen med --auto-update. ### Hvordan kører jeg kommandoerne i Lagune i Gemini CLI? Skriv dem under udvidelsens navn, såsom /lagune:lagune-charter. ### Kan Gemini CLI køre Lagune uden at bede om tilladelse? Ja. Tilføj en policy-regel, der tillader værktøjerne lagune_read og lagune_write fra serveren lagune, plus en til run_shell_command med npx --yes lagune@ og en version, når motoren kører gennem npx. --- # Installér Lagune i GitHub Copilot CLI som et plugin > Installér Lagune i GitHub Copilot CLI som et plugin, og hold det opdateret. Kanonisk URL: https://lagune.ai/da-DK/docs/install/github-copilot-cli Sprog: da-DK Original: https://lagune.ai/docs/install/github-copilot-cli Sidst opdateret: 2026-11-09 Installér pluginnet fra din terminal: ```bash copilot plugin marketplace add wellwelwel/lagune copilot plugin install lagune@lagune ``` I en editor installerer du **Lagune** til **GitHub Copilot** med [**skills.sh**](https://lagune.ai/da-DK/docs/install/universal). ## Opdatering Kør følgende for at opdatere **Lagune**: ```bash copilot plugin marketplace update lagune copilot plugin update lagune@lagune ``` ## Kommandoer Skriv kommandoerne ved deres navn, såsom `/lagune-charter`. ## Ofte stillede spørgsmål ### Hvordan installerer jeg Lagune i GitHub Copilot CLI? Kør copilot plugin marketplace add wellwelwel/lagune og derefter copilot plugin install lagune@lagune. ### Hvordan opdaterer jeg Lagune i GitHub Copilot CLI? Kør copilot plugin marketplace update lagune og derefter copilot plugin update lagune@lagune. ### Hvordan kører jeg kommandoerne i Lagune i GitHub Copilot CLI? Skriv dem ved deres navn, såsom /lagune-charter. ### Kan jeg bruge Lagune med GitHub Copilot i VS Code? Ja. I VS Code eller en anden editor installerer du Lagune med skills.sh i stedet for pluginnet. --- # Installér Lagune i Grok Build som et plugin > Installér Lagune i Grok Build som et plugin, hold det opdateret, og giv dets motor tilladelse på forhånd. Kanonisk URL: https://lagune.ai/da-DK/docs/install/grok-build Sprog: da-DK Original: https://lagune.ai/docs/install/grok-build Sidst opdateret: 2026-11-09 Installér pluginnet fra din terminal: ```bash grok plugin install wellwelwel/lagune@plugin-grok --trust ``` ## Opdatering Kør følgende for at opdatere **Lagune**: ```bash grok plugin update lagune ``` ## Kommandoer Skriv kommandoerne ved deres navn, såsom `/lagune-charter`, eller under pluginnets navn, såsom `/lagune:lagune-charter`. --- **Tilladelser** Motoren kører gennem to værktøjer: `lagune_read` læser kun dit projekt, og `lagune_write` skriver kun til `.lagune/`. Hvis du vil give dem tilladelse på forhånd, så tilføj disse regler til `~/.grok/config.toml`: ```toml [permission] allow = ["MCPTool(lagune__lagune_read)", "MCPTool(lagune__lagune_write)"] ``` Når motoren kører gennem **npx**, som med **skills.sh**, så tillad `Bash(npx --yes lagune@*)`. ## Ofte stillede spørgsmål ### Hvordan installerer jeg Lagune i Grok Build? Kør grok plugin install wellwelwel/lagune@plugin-grok --trust. ### Hvordan opdaterer jeg Lagune i Grok Build? Kør grok plugin update lagune. ### Hvordan kører jeg kommandoerne i Lagune i Grok Build? Skriv dem ved deres navn, såsom /lagune-charter, eller under pluginnets navn, såsom /lagune:lagune-charter. ### Kan Grok Build køre Lagune uden at bede om tilladelse? Ja. Tillad MCPTool(lagune__lagune_read) og MCPTool(lagune__lagune_write) i konfigurationen for Grok Build, plus Bash(npx --yes lagune@*), når motoren kører gennem npx. --- # Installér Lagune i Hermes Agent som et plugin > Installér Lagune i Hermes Agent som et plugin, og hold det opdateret. Kanonisk URL: https://lagune.ai/da-DK/docs/install/hermes-agent Sprog: da-DK Original: https://lagune.ai/docs/install/hermes-agent Sidst opdateret: 2026-11-09 Installér pluginnet fra din terminal: ```bash hermes plugins install wellwelwel/lagune --enable ``` - Når **Hermes Agent** beder dig bekræfte et plugin uden for sit katalog, så **bekræft det**. - Når den tilbyder at installere repositoriets afhængigheder til **Node.js**, så **afvis**. ## Opdatering Kør følgende for at opdatere **Lagune**: ```bash hermes plugins update lagune ``` ## Kommandoer Skriv kommandoerne under pluginnets navn, såsom `/lagune:lagune-charter` for `/lagune-charter` og `/lagune:lagune` for `/lagune`. ## Ofte stillede spørgsmål ### Hvordan installerer jeg Lagune i Hermes Agent? Kør hermes plugins install wellwelwel/lagune --enable. Bekræft pluginnet, når du bliver spurgt, og afvis at installere repositoriets afhængigheder til Node.js. ### Hvordan opdaterer jeg Lagune i Hermes Agent? Kør hermes plugins update lagune. ### Hvordan kører jeg kommandoerne i Lagune i Hermes Agent? Skriv dem under pluginnets navn, såsom /lagune:lagune-charter og /lagune:lagune. --- # Installér Lagune i Kimi Code som et plugin > Installér Lagune i Kimi Code som et plugin, og hold det opdateret. Kanonisk URL: https://lagune.ai/da-DK/docs/install/kimi-code Sprog: da-DK Original: https://lagune.ai/docs/install/kimi-code Sidst opdateret: 2026-11-09 Installér pluginnet fra en session i **Kimi Code**, vælg **Trust and install**, og start derefter en ny session for at indlæse det: ```text /plugins install https://github.com/wellwelwel/lagune /new ``` ## Opdatering Installér **Lagune** igen for at opdatere det: ```text /plugins install https://github.com/wellwelwel/lagune /new ``` ## Kommandoer Skriv kommandoerne under pluginnets navn, såsom `/lagune:lagune-charter` for `/lagune-charter`. Menuen `/` viser dem som `/skill:lagune:lagune-charter`, hvilket også virker. ## Ofte stillede spørgsmål ### Hvordan installerer jeg Lagune i Kimi Code? I en session i Kimi Code kører du /plugins install https://github.com/wellwelwel/lagune, vælger Trust and install og kører derefter /new. ### Hvordan opdaterer jeg Lagune i Kimi Code? Kør /plugins install https://github.com/wellwelwel/lagune igen og derefter /new. ### Hvordan kører jeg kommandoerne i Lagune i Kimi Code? Skriv dem under pluginnets navn, såsom /lagune:lagune-charter, eller som menuen / viser dem, såsom /skill:lagune:lagune-charter. --- # Installér Lagune i Muse Code som et plugin > Installér Lagune i Muse Code som et plugin, hold det opdateret, og kør dets motor inde i sandboxen. Kanonisk URL: https://lagune.ai/da-DK/docs/install/muse-code Sprog: da-DK Original: https://lagune.ai/docs/install/muse-code Sidst opdateret: 2026-11-09 Installér pluginnet fra din terminal: ```bash muse plugins marketplace add lagune wellwelwel/lagune muse plugins install lagune@lagune ``` ## Opdatering Opdatér markedspladsen, og geninstallér pluginnet for at opdatere **Lagune**: ```bash muse plugins marketplace update lagune muse plugins remove lagune muse plugins install lagune@lagune ``` ## Kommandoer Skriv kommandoerne ved deres navn, såsom `/lagune-charter`, eller under pluginnets navn, såsom `/lagune:lagune-charter`. --- **Sandbox** Sandboxen i **Muse Code** kan ikke downloade motoren. Installér den i dit projekt fra din egen terminal, én gang og efter hver opdatering: ```bash npm i -D lagune@0.18.1 ``` ## Ofte stillede spørgsmål ### Hvordan installerer jeg Lagune i Muse Code? Kør muse plugins marketplace add lagune wellwelwel/lagune og derefter muse plugins install lagune@lagune. ### Hvordan opdaterer jeg Lagune i Muse Code? Kør muse plugins marketplace update lagune, og geninstallér derefter med muse plugins remove lagune og muse plugins install lagune@lagune. ### Hvordan kører jeg kommandoerne i Lagune i Muse Code? Skriv dem ved deres navn, såsom /lagune-charter, eller under pluginnets navn, såsom /lagune:lagune-charter. ### Virker Lagune inde i sandboxen i Muse Code? Ja, når du har installeret motoren i dit projekt med npm i -D lagune@0.18.1 fra din egen terminal, én gang og efter hver opdatering. --- # Installér Lagune i OpenCode som et plugin > Installér Lagune i OpenCode 1.x og 2.x som et plugin, og hold det opdateret. Kanonisk URL: https://lagune.ai/da-DK/docs/install/opencode Sprog: da-DK Original: https://lagune.ai/docs/install/opencode Sidst opdateret: 2026-11-09 **OpenCode 2.x** Installér pluginnet fra din terminal: ```bash opencode plugin add lagune ``` Eller tilføj det til listen `plugins` i `opencode.json`: ```json { "plugins": ["lagune"] } ``` **OpenCode 1.x** Installér pluginnet i dit projekt fra din terminal, eller tilføj `-g` for at installere det til alle dine projekter: ```bash opencode plugin lagune ``` Eller tilføj det til listen `plugin` i `opencode.json`: ```json { "plugin": ["lagune"] } ``` ## Opdatering **OpenCode 2.x** Kør følgende for at opdatere **Lagune**: ```bash opencode plugin update lagune opencode reload ``` **OpenCode 1.x** Installér den nye udgivelse oven på den gamle for at opdatere **Lagune**, og tilføj `-g`, hvis du installerede det til alle dine projekter: ```bash opencode plugin lagune@0.18.1 --force ``` ## Kommandoer **OpenCode 2.x** Skriv `@`, og vælg kommandoen, såsom `@lagune-charter`, og skriv derefter dit input i samme besked. **OpenCode 1.x** Skriv kommandoerne ved deres navn, såsom `/lagune-charter`. De står under `/skills`, ikke i menuen `/`. ## Ofte stillede spørgsmål ### Hvordan installerer jeg Lagune i OpenCode? I OpenCode 2.x kører du opencode plugin add lagune. I OpenCode 1.x kører du opencode plugin lagune og tilføjer -g for at installere det til alle dine projekter. ### Hvordan opdaterer jeg Lagune i OpenCode? I OpenCode 2.x kører du opencode plugin update lagune og derefter opencode reload. I OpenCode 1.x kører du opencode plugin lagune@0.18.1 --force. ### Hvordan kører jeg kommandoerne i Lagune i OpenCode? I OpenCode 2.x skriver du @ og vælger kommandoen, såsom @lagune-charter, og skriver derefter dit input i samme besked. I OpenCode 1.x skriver du dem ved deres navn, såsom /lagune-charter, eller finder dem under /skills. ### Beder OpenCode om tilladelse, før Lagune kører? Nej. OpenCode kører motorens to værktøjer, lagune_read og lagune_write, uden at spørge. --- # Installér Lagune i Pi som en pakke > Installér Lagune i Pi som en pakke, fra npm eller fra GitHub, og hold det opdateret. Kanonisk URL: https://lagune.ai/da-DK/docs/install/pi Sprog: da-DK Original: https://lagune.ai/docs/install/pi Sidst opdateret: 2026-11-09 **npm** Installér pakken fra din terminal: ```bash pi install npm:lagune ``` **GitHub** Installér det seneste commit fra **GitHub**, som kører motoren gennem **npx**: ```bash pi install git:github.com/wellwelwel/lagune ``` ## Opdatering **npm** Kør følgende for at opdatere **Lagune**: ```bash pi update npm:lagune ``` **GitHub** Kør følgende for at opdatere **Lagune**: ```bash pi update git:github.com/wellwelwel/lagune ``` `pi update --extensions` opdaterer alle de pakker, du har installeret, mens `pi update` alene kun opdaterer **Pi**. ## Kommandoer Skriv kommandoerne med præfikset `skill:`, såsom `/skill:lagune-charter` for `/lagune-charter`. ## Ofte stillede spørgsmål ### Hvordan installerer jeg Lagune i Pi? Kør pi install npm:lagune, eller pi install git:github.com/wellwelwel/lagune for at få det seneste commit fra GitHub. ### Hvordan opdaterer jeg Lagune i Pi? Kør pi update npm:lagune, eller pi update git:github.com/wellwelwel/lagune for en installation fra GitHub. pi update --extensions opdaterer alle de pakker, du har installeret. ### Hvordan kører jeg kommandoerne i Lagune i Pi? Skriv dem med præfikset skill:, såsom /skill:lagune-charter. --- # Installér Lagune i Qwen Code som en udvidelse > Installér Lagune i Qwen Code som en udvidelse, hold det opdateret, og giv dets motor tilladelse på forhånd. Kanonisk URL: https://lagune.ai/da-DK/docs/install/qwen-code Sprog: da-DK Original: https://lagune.ai/docs/install/qwen-code Sidst opdateret: 2026-11-09 Installér udvidelsen fra din terminal: ```bash qwen extensions install lagune ``` ## Opdatering Kør følgende for at opdatere **Lagune**: ```bash qwen extensions update lagune ``` Hvis du vil holde det opdateret, så installér det med `--auto-update`. ## Kommandoer Skriv kommandoerne under udvidelsens navn, såsom `/lagune:lagune-charter` for `/lagune-charter`. --- **Tilladelser** Motoren kører gennem to værktøjer: `lagune_read` læser kun dit projekt, og `lagune_write` skriver kun til `.lagune/`. Hvis du vil give dem tilladelse på forhånd, så tilføj disse regler til `.qwen/settings.json` for ét projekt eller til `~/.qwen/settings.json` for dem alle: ```json { "permissions": { "allow": ["mcp__lagune__lagune_read", "mcp__lagune__lagune_write"] } } ``` Når motoren kører gennem **npx**, som med **skills.sh**, så tillad `Shell(npx --yes lagune@*)`. ## Ofte stillede spørgsmål ### Hvordan installerer jeg Lagune i Qwen Code? Kør qwen extensions install lagune. ### Hvordan opdaterer jeg Lagune i Qwen Code? Kør qwen extensions update lagune, eller installér udvidelsen med --auto-update. ### Hvordan kører jeg kommandoerne i Lagune i Qwen Code? Skriv dem under udvidelsens navn, såsom /lagune:lagune-charter. ### Kan Qwen Code køre Lagune uden at bede om tilladelse? Ja. Tillad mcp__lagune__lagune_read og mcp__lagune__lagune_write i indstillingerne for Qwen Code, plus Shell(npx --yes lagune@*), når motoren kører gennem npx. --- # Installér Lagune i enhver agent med skills.sh eller GitHub CLI > Installér Lagune i enhver AI-agent med CLI'en fra skills eller GitHub CLI, og hold det opdateret. Kanonisk URL: https://lagune.ai/da-DK/docs/install/universal Sprog: da-DK Original: https://lagune.ai/docs/install/universal Sidst opdateret: 2026-11-09 **skills.sh** Installér kommandoerne i **Lagune** i dit projekt fra din terminal med [**skills.sh**](https://www.skills.sh/wellwelwel/lagune), og behold **Project** som installationsomfang: ```bash npx skills add wellwelwel/lagune --skill '*' ``` Eller indsæt denne prompt i din agent: ```md Kør `npx --yes skills add wellwelwel/lagune`, og følg de genererede instruktioner til skillen nu. Læs hele outputtet, og omdirigér det først til en midlertidig fil, hvis det er nødvendigt. Opløs relative stier ud fra den mappe med supportfiler, som outputtet angiver. ``` **GitHub CLI** Installér kommandoerne i **Lagune** i dit projekt fra din terminal med [**GitHub CLI**](https://cli.github.com/) 2.90.0 eller nyere: ```bash gh skill install wellwelwel/lagune --all --scope project ``` Eller indsæt denne prompt i din agent: ```md Kør `gh skill install wellwelwel/lagune --all --scope project`, og læs hele outputtet. Omdirigér det først til en midlertidig fil, hvis det er nødvendigt. ``` ## Opdatering **skills.sh** Kør følgende for at opdatere **Lagune**: ```bash npx skills update ``` Eller indsæt denne prompt i din agent: ```md Kør `npx --yes skills update -y`, og læs hele outputtet. Omdirigér det først til en midlertidig fil, hvis det er nødvendigt. ``` **GitHub CLI** Kør følgende for at opdatere **Lagune**: ```bash gh skill update --all ``` Eller indsæt denne prompt i din agent: ```md Kør `gh skill update --all`, og læs hele outputtet. Omdirigér det først til en midlertidig fil, hvis det er nødvendigt. ``` --- **Sandbox** I en sandbox uden netværksadgang kan kommandoerne ikke downloade motoren. Installér den i dit projekt fra din egen terminal, én gang og efter hver opdatering: ```bash npm i -D lagune@0.18.1 ``` ## Ofte stillede spørgsmål ### Hvordan installerer jeg Lagune i en hvilken som helst AI-agent? Kør npx skills add wellwelwel/lagune --skill '*' eller gh skill install wellwelwel/lagune --all --scope project i dit projekt, eller indsæt installationsprompten i din agent. ### Hvordan opdaterer jeg Lagune i en hvilken som helst AI-agent? Kør npx skills update, hvis du installerede det med skills.sh, eller gh skill update --all, hvis du installerede det med GitHub CLI. Du kan også indsætte opdateringsprompten i din agent. ### Kan jeg installere Lagune på mere end én måde? Nej. Med to viser agenten hver kommando to gange eller bruger én kopi og skjuler den anden. --- # Sikkerhedsskills til AI-agenter > De skills, din AI-agent får med Lagune: gennemgå et eksisterende projekt, eller sikr nyt arbejde, mens du bygger, altid styret af sikkerhedsprincipperne. Kanonisk URL: https://lagune.ai/da-DK/docs/get-started/commands Sprog: da-DK Original: https://lagune.ai/docs/get-started/commands Sidst opdateret: 2026-11-09 Når **Lagune** er [installeret](https://lagune.ai/da-DK/docs), får din **AI**-agent en række skills. Der er to måder at bruge dem på, og begge styres af **charter**: sikr nyt arbejde, mens du bygger det, eller kør hele gennemgangen af et projekt. **⌨️ Byg / udvikling** Du behøver ikke at gøre dit arbejde færdigt, før du sikrer det. Brug [**`/lagune`**](https://lagune.ai/da-DK/docs/commands/lagune) til det arbejde, du skriver **lige nu**: | Skill | Hvad den gør for dig | | --------------------------------------------- | ---------------------------------------------------------------------------------- | | [**/lagune-charter**](https://lagune.ai/da-DK/docs/commands/charter) | Fastlægger dit projekts sikkerhedsregler, det fundament `/lagune` bygger ud fra | | [**/lagune**](https://lagune.ai/da-DK/docs/commands/lagune) | Bygger det, du beder om, og hærder det, mens det bliver skrevet, styret af charter | **Brug den når som helst** [**`/lagune`**](https://lagune.ai/da-DK/docs/commands/lagune) overholder dine regler fra charter, hver gang den kører. Den tager imod enhver prompt, bygger det, du bad om, og hærder det med sikre standardindstillinger undervejs, ikke senere. --- #### Særlige skills | Skill | Hvad den gør | | --------------------------------------------------- | ------------------------------------------------------------------------------------- | | [**/lagune-specialize**](https://lagune.ai/da-DK/docs/commands/specialize) | Lærer **Lagune** en ny sikkerhedsspecialisering ud fra artikler, exploits eller emner | **🔬 Gennemgang: Blue Team-workflow** Hele **Blue Team-workflowet**: læs, hvad et projekt gør, kortlæg dets risici, og luk dem. Hvert trin bygger på det forrige, så du skal blot følge listen oppefra og ned: | # | Skill | Hvad den gør for dig | | --- | --------------------------------------------- | -------------------------------------------------------------------------------------------- | | 1 | [**/lagune-charter**](https://lagune.ai/da-DK/docs/commands/charter) | Fastlægger dit projekts sikkerhedsregler, foreslået for dig eller formet efter det, du siger | | 2 | [**/lagune-detect**](https://lagune.ai/da-DK/docs/commands/detect) | Læser din kode og kortlægger, hvad dit system gør, og hvor risiciene er | | 3 | [**/lagune-plan**](https://lagune.ai/da-DK/docs/commands/plan) | Gør det, detect fandt, til en forsvarsplan med en rettelse til hvert fund | | 4 | [**/lagune-harden**](https://lagune.ai/da-DK/docs/commands/harden) | Gennemfører planens rettelser i din kode, sikkert og én ad gangen | | 5 | [**/lagune-verify**](https://lagune.ai/da-DK/docs/commands/verify) | Påviser, at hver gennemført rettelse holder, og afslutter dem, der gør | --- #### Særlige skills | Skill | Hvad den gør | | --------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | | [**/lagune-specialize**](https://lagune.ai/da-DK/docs/commands/specialize) | Lærer **Lagune** en ny sikkerhedsspecialisering ud fra artikler, exploits eller emner | | [**/lagune-prove**](https://lagune.ai/da-DK/docs/commands/prove) | Gør hvert fund fra detect til et kørbart, udelukkende defensivt bevis til ansvarlig offentliggørelse | --- #### Interne skills | Skill | Hvad den gør | | ------------------------------------------- | ------------------------------------------ | | [**/lagune-repair**](https://lagune.ai/da-DK/docs/commands/repair) | Reparerer den interne sporing i **Lagune** | **Tip** Sikkerhed er ikke en udgift, men en investering: det, du lægger i fra starten, sparer du mange gange igen i de hændelser, du aldrig får 🙋🏻‍♂️ ## Ofte stillede spørgsmål ### Hvilke skills tilføjer Lagune? /lagune til at hærde arbejdet, mens du bygger det, og Blue Team-gennemgangen i fem faser: /lagune-charter, /lagune-detect, /lagune-plan, /lagune-harden, /lagune-verify. Derudover /lagune-specialize og /lagune-prove. ### Hvad er Blue Team-workflowet i Lagune? En gennemgang i fem faser: charter (fastlæg regler), detect (kortlæg risici), plan (vurdér og planlæg rettelser), harden (gennemfør rettelser), verify (påvis, at de holder, og afslut dem). ### Hvad er forskellen på /lagune og gennemgangen? /lagune sikrer nyt arbejde, mens du skriver det, uden et workflow at følge. Gennemgangen kører de fem faser i rækkefølge over et eksisterende projekt. --- # Dashboard > Se dit projekts sikkerhedsprincipper, fund og katalog i en lokal livevisning, der åbner med én kommando. Kanonisk URL: https://lagune.ai/da-DK/docs/get-started/dashboard Sprog: da-DK Original: https://lagune.ai/docs/get-started/dashboard Sidst opdateret: 2026-11-09 Kør **Lagune** direkte uden underkommando for at få en interaktiv livevisning af `.lagune/`. Den starter et dashboard og åbner det på en tilfældig port: ```bash npx lagune ``` - [x] **Live reload** - [x] **Privat** og **lokalt** - [x] Viser alt, hvad `.lagune/` indeholder, fra de første sikkerhedsprincipper og frem - [x] **Administrér** projektets kategorier, og hvad dets hooks scanner, direkte fra din browser - [x] Hverken `node_modules` eller `package.json` er nødvendig 📦 ![Sikkerhedsprincipper i dashboardet for Lagune](https://lagune.ai/img/dashboard/02.webp) ![Fund i dashboardet for Lagune](https://lagune.ai/img/dashboard/03.webp) ![Side quests i dashboardet for Lagune](https://lagune.ai/img/dashboard/04.webp) ![Detaljevisning af et fund i dashboardet for Lagune](https://lagune.ai/img/dashboard/05.webp) ![Katalog i dashboardet for Lagune](https://lagune.ai/img/dashboard/06.webp) **Tip** - 🚪 Brug `--port` til at angive en bestemt port. - ⏏️ Tryk på `Ctrl+C` for at stoppe. ## Ofte stillede spørgsmål ### Hvordan åbner jeg dashboardet i Lagune? Kør npx lagune uden underkommando i roden af dit projekt. Den viser en livevisning af .lagune/ på en tilfældig port og åbner den i din browser. ### Er dashboardet privat? Ja. Det kører kun på din egen maskine, på en lokal adresse, som ingen anden computer kan nå. ### Kan jeg ændre mit projekt fra dashboardet? Kun dets kategorier, og hvad dets hooks udelader, fra din browser. Alt andet, dashboardet viser, kan kun læses. --- # /lagune: Sikr koden, mens din AI skriver den > Byg det, du beder om, og hærd det, mens det bliver skrevet, styret af sikkerhedsprincipperne og uden et workflow at følge. Kanonisk URL: https://lagune.ai/da-DK/docs/commands/lagune Sprog: da-DK Original: https://lagune.ai/docs/commands/lagune Sidst opdateret: 2026-11-09 ⌨️ Få udført det arbejde, du bad om, sikret mens det bliver skrevet. **`/lagune`** tager imod enhver prompt i enhver fase, bygger det, du ønskede, og hærder det med sikre standardindstillinger, før den afleverer det. ## Brug Tilføj **`/lagune`** til en hvilken som helst prompt, og beskriv arbejdet, som du plejer. **📘 Instruktioner til agenten** ```md # Mine projektinstruktioner til agenter ## Sikkerhed - Brug skillen `/lagune`, hver gang du bygger eller ændrer kode, så den forbedrer sikkerheden som standard. ``` - For eksempel: **AGENTS.md**, **CLAUDE.md**, **.github/copilot-instructions.md**, **.cursorrules** osv. **💬 En funktion** ```prompt /lagune lad brugerne uploade et eget billede på deres profil. ``` **💬 En rettelse** ```prompt /lagune der sker ingenting, når brugeren sender formularen. Undersøg, hvad det kan være, og ret det. ``` **💬 En refaktorering** ```prompt /lagune afkobl og forbedr payload-logikken ``` **Charter er valgfrit, men bedre med** **`/lagune`** kører med eller uden sikkerhedsprincipper. Med dem former dit projekts egne regler hvert build. Fastlæg dem én gang med [`/lagune-charter`](https://lagune.ai/da-DK/docs/commands/charter). ## Sådan virker det Den indrammer arbejdet i tre trin uden at skrive noget til Lagune: 1. Den indlæser dine sikkerhedsprincipper, hvis de findes, og de styrer hele buildet, og når du endnu ikke har nogen, falder den tilbage på et grundlag, der er sikkert som standard. 2. Den oplister dit projekts [katalog](https://lagune.ai/da-DK/docs/catalog) og indlæser kun de specialiseringer, dit arbejde berører, den samme viden efter behov, som gennemgangen bruger. 3. Den anvender forsvaret, mens koden bliver skrevet, og læser derefter sit eget resultat igen for at bekræfte, at kontrollerne faktisk holder, før den afleverer arbejdet. Resultatet er fungerende kode i dit projekt, sikker fra første linje. **Brug den når som helst** Ingen detect, ingen plan, ingen oprydning bagefter. **`/lagune`** passer lige så godt til et nyt skelet som til en ændring i en moden kodebase, og den hærder arbejdet undervejs, ikke senere. ## Hvad den ikke gør - Den skriver intet til mappen `.lagune`, hverken artefakter eller sporing, så det eneste, den producerer, er den hærdede kode, du bad om. - Den svækker ikke en regel for at imødekomme en prompt, så hvis det, du bad om, ville bryde et princip i charter, stopper den og fortæller dig det først i stedet for direkte at bygge det usikkert. ## Ofte stillede spørgsmål ### Hvad gør /lagune? Den tager imod enhver prompt i enhver fase, bygger det, du bad om, og hærder det med sikre standardindstillinger, før den afleverer det. Forsvaret anvendes, mens koden bliver skrevet, ikke senere. ### Skal jeg have sikkerhedsprincipper for at bruge /lagune? Nej. Den kører med eller uden. Med sikkerhedsprincipper former dit projekts egne regler hvert build. Uden dem falder den tilbage på et grundlag, der er sikkert som standard. ### Hvad er forskellen på /lagune og Blue Team-workflowet? /lagune sikrer nyt arbejde, mens du skriver det, uden et workflow at følge. Blue Team-workflowet kører de fem faser af gennemgangen i rækkefølge over et eksisterende projekt. ### Sporer /lagune fund eller skriver artefakter? Nej. Den skriver intet til mappen .lagune, hverken artefakter eller sporing. Det eneste, den producerer, er den hærdede kode, du bad om. ### Hvordan får jeg min agent til at bruge /lagune automatisk? Tilføj en instruktion til din agents instruktionsfil (AGENTS.md, CLAUDE.md, .cursorrules og lignende), der beder den bruge skillen /lagune, hver gang den bygger eller ændrer kode. --- # /lagune-charter: Fastlæg dine sikkerhedsprincipper > Fastlæg dit projekts sikkerhedsprincipper, de regler hver senere fase respekterer, og registrér de kategorier af specialiseringer, som læsningen af projektet understøtter. Kanonisk URL: https://lagune.ai/da-DK/docs/commands/charter Sprog: da-DK Original: https://lagune.ai/docs/commands/charter Sidst opdateret: 2026-11-09 🧬 Fortæl **Lagune**, hvad dit projekt er, så gør det det til dine sikkerhedsregler (eller, uden en beskrivelse, udleder dem af projektet alene). Charter er det overordnede lag: et sæt principper med sikkerheden i første række, som hver senere fase skal respektere. Tænk på det som kompileringstjekket for dit projekts sikkerhedsniveau. ## Brug **Beskriv det** ```prompt /lagune-charter Mit projekt er en webshop, der sælger videospil. Kunderne lægger produkter i en kurv og betaler med kreditkort eller bankoverførsel. De kan se deres ordrer og status for hver enkelt. ``` **Lad Lagune foreslå** ```prompt /lagune-charter ``` > _Jeg ser et betalingsbibliotek, en loginopsætning og en ordremodel knyttet til en kunde. Det ligner en webshop, der sælger noget. Kunderne betaler og følger deres egne ordrer..._ ☁️ ## Hvad det udleder **Lagune** tager din beskrivelse eller din **PRD** som retning og udleder, hvad den betyder for sikkerheden, og læser derefter projektet for at gå videre, end du nævnte. For eksempel: - En kurv, der indeholder ordrer, betyder, at der er en **database**: - f.eks. `"Hvor ligger dataene?"`, `"Hvem kan nå dem?"`, `"Lækker de?"`. - Kunder, der kan se deres egne ordrer, betyder, at der er en form for **login eller adgangskontrol**: - f.eks. `"Kan én kunde nå en anden kundes ordrer?"`, `"Er sessionerne beskyttet?"`. - Betaling med kort og bankoverførsel betyder, at **penge og følsomme data er involveret**: - f.eks. `"Bliver kortdata gemt?"`, `"Bliver betalingerne verificeret?"`. Din beskrivelse og projektet supplerer hinanden: din beskrivelse sætter hensigten, og læsningen af afhængighederne, README og konfigurationen bringer det frem, du ikke nævnte. Hvis noget vigtigt stadig er uklart, stiller **Lagune** et kort, enkelt spørgsmål i stedet for at gætte. Ud fra det bygger **Lagune** et skræddersyet sæt sikkerhedsregler til projektet, som du kan gennemse og justere, når du har brug for det. **Få mest muligt ud af det** - Du kan også definere dine egne sikkerhedsregler for projektet. - Jo flere relevante detaljer du giver, desto bedre bliver den endelige rapport: - Forklar projektet, hvordan det virker, og hvad der sker bag kulisserne. - Hvem er slutbrugeren? Hvad kan brugerne gøre, og hvad kan de ikke? - Detaljer om adfærd er lige så værdifulde som tekniske detaljer. - Hukommelsen for charter ligger i `.lagune/memory/charter.md`. ## De kategorier, det registrerer Specialiseringer, den sikkerhedsviden de senere faser indlæser efter behov, kommer ind i dit projekts [katalog](https://lagune.ai/da-DK/docs/catalog) efter [kategori](https://lagune.ai/da-DK/docs/categories). Så længe dit projekt ikke har nogen kategori registreret, registrerer charter hver kategori, som læsningen understøtter, såsom dit projekts sprog, kald til en LLM eller containere, og nævner dem i sit resumé. Når der er registreret kategorier, lader charter dem være og nævner kun en kategori, dit projekt endnu ikke bruger. Du kan selv ændre dem når som helst: ```bash npx lagune write add --categories python npx lagune write remove --categories python ``` ## De mapper, det tilbyder at udelade Når læsningen i charter finder committede mapper, der ikke er dit projekts kode at forsvare, såsom testfixtures skrevet til at se sårbare ud, oplister den dem med numre sidst i sit resumé. Den udelader aldrig en mappe på egen hånd, da et fjendtligt repository kan få sin kode til at ligne fixtures, så kun de numre, du svarer med, bliver registreret. [Konfigurér hooks](https://lagune.ai/da-DK/docs/hooks/configure) beskriver, hvordan du selv ændrer dem. ## Næste trin Med reglerne på plads kan du kortlægge, hvad dit system rent faktisk gør: [`/lagune-detect`](https://lagune.ai/da-DK/docs/commands/detect). ## Ofte stillede spørgsmål ### Hvad er charter i Lagune? Charter er det overordnede lag i Lagune, et sæt principper med sikkerheden i første række, som hver senere fase skal respektere. Tænk på det som kompileringstjekket for dit projekts sikkerhedsniveau. ### Hvor bliver charter gemt? I .lagune/memory/charter.md. ### Kan jeg skrive mine egne regler i charter? Ja. Lagune foreslår regler ud fra din beskrivelse og din kode, og du kan omformulere, fjerne, tilføje eller afgrænse dem. ### Vælger charter mine kategorier af specialiseringer? Kun så længe der ikke er registreret nogen. Den registrerer så hver kategori, som læsningen understøtter, såsom dit sprog eller kald til en LLM. Når der er registreret kategorier, ændrer den dem aldrig. --- # /lagune-detect: Kortlæg dit system og dets risici > Læs din kode, og kortlæg, hvad dit system gør, og hvor risiciene er. Kanonisk URL: https://lagune.ai/da-DK/docs/commands/detect Sprog: da-DK Original: https://lagune.ai/docs/commands/detect Sidst opdateret: 2026-11-09 🔬 Find ud af, hvad dit system virkelig gør, og hvor risiciene er. Detect læser koden og registrerer kun det, den faktisk finder, med det belæg, de senere faser har brug for. Dens styrende instruks er at opdage, ikke at opfinde. ## Brug **Fuld scanning** ```prompt /lagune-detect ``` **Angiv stier** ```prompt /lagune-detect src/routes/ src/auth.ts ``` **Beskriv en bekymring** ```prompt /lagune-detect sørg for, at kundedata aldrig bliver eksponeret ``` ## Hvad den kortlægger **Lagune** læser koden og kortlægger det, den finder. Hvert fund indeholder, hvad det er, hvorfor det betyder noget, og belægget. For eksempel: - **Filupload**, systemet tager imod filer fra brugerne: - _Hvorfor det betyder noget:_ en fil forklædt som et billede kan skjule ondsindet kode. - _Belæg:_ handleren til `POST /upload` stoler på den MIME-type, klienten sender, uden at tjekke filens reelle type. - **Login og sessioner**, brugerne logger ind for at nå deres konto: - _Hvorfor det betyder noget:_ svag håndtering af sessioner gør det muligt for én konto at blive overtaget af en anden. - _Belæg:_ logikken, der udsteder sessioner, hvor sessionerne udstedes uden udløbstid. Undervejs giver detect hver specialisering i dit projekts [katalog](https://lagune.ai/da-DK/docs/catalog) en afgørelse op mod koden, anvender dem, hvis kontekst er til stede, og registrerer dem under **Applied specializations**, den liste, harden og verify genbruger. Derfra har du et klart kort over, hvad dit system gør, og hvor risiciene ligger, klar til at de næste trin kan handle på det. **Tip** - Når du kører den igen, bliver kortlægningen opdateret: løste fund forsvinder, og nye kommer til. - Kortlægningen ligger i `.lagune/memory/detect.md`. ## Næste trin Gør kortlægningen til en plan: [`/lagune-plan`](https://lagune.ai/da-DK/docs/commands/plan). ## Ofte stillede spørgsmål ### Hvad gør /lagune-detect? Den læser din kode og kortlægger, hvad dit system gør, og hvor risiciene er, og registrerer kun det, den faktisk finder. Dens regel er at opdage, ikke at opfinde. ### Hvad er et fund i Lagune? Et fund er én opdaget risiko med det, den er, hvorfor den betyder noget, og belægget i koden. Det er den sporede enhed, som plan, harden og verify fører videre. ### Hvor bliver kortlægningen gemt? I .lagune/memory/detect.md. ### Hvilke specialiseringer bruger detect? Hver specialisering i dit projekts katalog får en afgørelse op mod koden. Detect anvender dem, hvis kontekst er til stede, og registrerer dem under Applied specializations. --- # /lagune-plan: Vurdér fund og planlæg rettelser > Gør det, detect fandt, til en forsvarsplan, der vurderer hvert fund med en kategori og en CVSS v4.0-score og parrer det med en rettelse. Kanonisk URL: https://lagune.ai/da-DK/docs/commands/plan Sprog: da-DK Original: https://lagune.ai/docs/commands/plan Sidst opdateret: 2026-11-09 🛡️ Gør det, detect fandt, til en forsvarsplan: vurdér hvert fund med en kategori og en CVSS v4.0-score, og par det derefter med den rettelse, der skal gennemføres. ## Brug **Planlæg alt** ```prompt /lagune-plan ``` **Angiv stier** ```prompt /lagune-plan src/routes/upload.ts ``` **Fokusér på en bekymring** ```prompt /lagune-plan hvor følsomme data kan lække ``` ## Sådan virker det Denne fase fortsætter, hvor detect slap. Detect har allerede fundet, hvad dit system gør, og hvilken risiko hver ting indebærer, så planen gentager ikke risikoen, men vurderer, hvor alvorlig den er, og beslutter, hvad der skal gøres ved den. Plan læser aldrig koden, hvilket tvinger hver rettelse til at pege på noget, detect faktisk opdagede. Den vurderer hvert fund med metoden CVSS v4.0: en kategori, en CVSS v4.0-vektor, udledt af det, detect og charter har registreret, og scoret af [hooken `cvss`](https://lagune.ai/da-DK/docs/hooks/cvss), og det prioritetsniveau, scoren lander i. Hver rettelse angiver også det princip i charter, den opretholder. For eksempel: - **Filupload** (prioritet: **Critical**) - _Kategori:_ ubegrænset filupload (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). - _Hvorfor denne prioritet:_ alle kan nå uploaden over internettet, og den ligger på den server, der gemmer kundernes filer. - _Opretholder:_ III. Alt input er ikke-betroet, indtil det er valideret. - _Rettelse:_ tjek filens reelle type og størrelse, omdøb den ved lagring, og gem uploads et sted, hvor de ikke kan køres som kode. Derfra har du en vurderet og prioriteret liste over rettelser, hver knyttet til et fund og klar til, at den næste fase gennemfører den. Scoren bliver beregnet, aldrig anslået: vektoren indeholder projektets eksponering og indsats som Environmental-metrikker, og alle kan indsætte den i lommeregneren fra FIRST eller NVD og udlede den samme score igen. **Tip** - Den bygger udelukkende på detect. Hvis en fil eller en bekymring aldrig er blevet kortlagt, beder den dig om først at køre `/lagune-detect` på den. - Når du kører den igen, bliver planen opdateret: færdige rettelser forsvinder, og nye kommer til. - Forsvarsplanen ligger i `.lagune/memory/plan.md`. **Afhænger af detect** Plan arbejder kun ud fra det, [`/lagune-detect`](https://lagune.ai/da-DK/docs/commands/detect) allerede har kortlagt, så kør detect først. ## Næste trin Gennemfør planen: [`/lagune-harden`](https://lagune.ai/da-DK/docs/commands/harden). ## Ofte stillede spørgsmål ### Hvordan prioriterer Lagune sårbarheder? /lagune-plan vurderer hvert fund med en kategori og en CVSS v4.0-score, beregnet af hooken cvss, og parrer det derefter med den rettelse, der skal gennemføres. ### Bruger Lagune CVSS v4.0? Ja. Hvert fund får en CVSS v4.0-vektor og -score, beregnet af hooken cvss med samme aritmetik som lommeregneren fra FIRST, så alle kan indsætte vektoren dér og udlede scoren igen. ### Læser planen min kode? Nej. Plan læser aldrig koden, hvilket tvinger hver rettelse til at pege på noget, detect faktisk opdagede. --- # /lagune-harden: Gennemfør sikkerhedsrettelser i din kode > Gennemfør planens rettelser i din kode, sikkert og én ad gangen. Kanonisk URL: https://lagune.ai/da-DK/docs/commands/harden Sprog: da-DK Original: https://lagune.ai/docs/commands/harden Sidst opdateret: 2026-11-09 🔧 Gennemfør planens rettelser i din kode, sikkert og én ad gangen. ## Brug **Gennemfør alt** ```prompt /lagune-harden ``` **Angiv stier** ```prompt /lagune-harden src/routes/upload.ts ``` **Efter prioritet** ```prompt /lagune-harden Critical og High ``` ## Sådan virker det Planen har allerede besluttet hver rettelse, så harden gennemfører den blot. Da det er den eneste fase, der rører din kode, går den forsigtigt frem: den gennemfører én rettelse ad gangen, så hver ændring forbliver nem at gennemse, og den svækker aldrig en kontrol for at få en rettelse til at passe. For eksempel rettelsen af uploaden: - **Filupload** (status: **Applied**) - _Hvad der ændrede sig:_ tjekker filens reelle type og størrelse, afviser alt uventet, omdøber den ved lagring og gemmer den et sted, hvor den ikke kan køres som kode. - _Hvor:_ funktionen `handleUpload` samt den lagringshjælper, den kalder. Hvis en rettelse ikke kan gennemføres fuldt ud, gør harden det, den sikkert kan, og markerer resten som **Partial** eller **Blocked**, så den forbliver åben. **Applied er ikke verificeret** Applied betyder ikke, at den er påvist endnu. Det er, hvad [verify](https://lagune.ai/da-DK/docs/commands/verify) er til. **Tip** - Den bygger udelukkende på planen. Hvis en rettelse eller en fil aldrig er blevet planlagt, beder den dig om først at køre `/lagune-plan` på den. - Når du kører den igen, bliver hærdningsloggen afstemt: tilbagerullede ændringer forsvinder, og nyligt gennemførte rettelser kommer til. - Hærdningsloggen ligger i `.lagune/memory/harden.md`. **Afhænger af plan og ændrer din kode** Harden bygger på [`/lagune-plan`](https://lagune.ai/da-DK/docs/commands/plan). Det er den eneste fase, der ændrer din kode. ## Næste trin Påvis, at hver rettelse holder: [`/lagune-verify`](https://lagune.ai/da-DK/docs/commands/verify). ## Ofte stillede spørgsmål ### Ændrer /lagune-harden min kode? Ja. Det er den eneste fase, der rører din kode, og den gennemfører planens rettelser én ad gangen. ### Hvad betyder Applied, Partial og Blocked? Det er den status, Lagune registrerer for hver rettelse. Applied betyder, at rettelsen er gennemført, Partial, at kun en del af den er, og Blocked, at den ikke kunne gennemføres. Applied betyder ikke, at den er påvist endnu. ### Gennemfører Lagune rettelser uden at spørge? Om en ændring kræver din godkendelse, afgøres af din agent og den tilladelsestilstand, du kører den i, ikke af Lagune, som ikke tilføjer nogen bekræftelse af sin egen. Den svækker dog aldrig en kontrol for at opfylde en rettelse, og hvis en rettelse ville komme i konflikt med en regel i charter, stopper den og fortæller dig det først. --- # /lagune-verify: Påvis, at sikkerhedskontrollerne holder > Påvis, at hver gennemført rettelse holder, og afslut derefter dem, der gør. Kanonisk URL: https://lagune.ai/da-DK/docs/commands/verify Sprog: da-DK Original: https://lagune.ai/docs/commands/verify Sidst opdateret: 2026-11-09 ⚖️ Påvis, at hver gennemført rettelse holder, ved at læse koden og holde den op mod det, harden registrerede, og afslut derefter dem, der gør. ## Brug **Verificér alt** ```prompt /lagune-verify ``` **Angiv stier** ```prompt /lagune-verify src/routes/upload.ts ``` **Efter prioritet** ```prompt /lagune-verify Critical og High ``` ## Sådan virker det Den læser koden på hvert sted, harden registrerede, og bekræfter, at den virkelig svarer til påstanden. Beviset er netop den konfrontation, koden op mod loggen. Hver kontrol får én af tre afgørelser: | Afgørelse | Betydning | | ---------------------------- | ---------------------------------------------------------------- | | ✅ Risk closed | Koden gør præcis det, loggen påstår. | | ❌ Risk not closed | Kontrollen er stadig åben. Verify sender dig tilbage til harden. | | ❓ Cannot tell from the code | Belægget kan ikke ses i koden alene. | En risiko, der er påvist lukket, bliver derefter taget ud af kæden, med din bekræftelse. For eksempel: - **Filupload** (afgørelse: **✅ Risk closed**) - _Sådan blev det påvist:_ læste upload-handleren og så, at den bestemmer filens reelle type ud fra indholdet, håndhæver en størrelsesgrænse og afviser alt andet, præcis som loggen påstår. - _Belæg:_ funktionen `handleUpload`, som bestemmer den reelle filtype ud fra indholdet. Hvis risikoen ikke er lukket, siger verify det ligeud og sender dig tilbage til [`/lagune-harden`](https://lagune.ai/da-DK/docs/commands/harden), da rettelsen stadig er åben. **Tip** - Den bygger udelukkende på hærdningsloggen. - Den læser kun din kode for at vurdere den og svækker aldrig en kontrol eller omskriver koden for at få en afgørelse igennem. - Når du kører den igen, bliver afgørelserne afstemt: forældede afgørelser forsvinder, og en risiko, der ikke længere er lukket, bliver markeret igen. - Når en risiko er påvist lukket, spørger den én gang og fjerner derefter fundet fra hele kæden (detect, plan, harden og sporingen). - Den skriver ingen rapport af sin egen: hver afgørelse står i blokken for sin kontrol i `.lagune/memory/harden.md`, hvor harden læser den ved næste kørsel. **Afhænger af harden** Verify bygger på [`/lagune-harden`](https://lagune.ai/da-DK/docs/commands/harden). ## Cyklussen afsluttes Når alt inden for omfanget er taget ud, er cyklussen i hvile. Den åbner kun igen, når koden ændrer sig. Sikkerhed kan afsluttes, så workflowet har en sluttilstand, ikke en endeløs løkke. ## Ofte stillede spørgsmål ### Hvordan verificerer Lagune en rettelse? /lagune-verify læser koden og holder den op mod det, harden registrerede, og giver én af tre afgørelser: Risk closed, Risk not closed eller Cannot tell from the code. ### Hvad vil det sige at tage et fund ud? Når verify påviser, at en risiko er lukket, bliver fundet taget ud: fjernet fra hele kæden, med din bekræftelse, så det ikke længere bliver behandlet igen. ### Kan sikkerhedsarbejde nogensinde blive færdigt? Ja. SDH kan afsluttes: et fund, der er påvist lukket, bliver taget ud, så workflowet har en sluttilstand, ikke en endeløs løkke. --- # Kategorier > De kategorier af specialiseringer, et Lagune-projekt kan bruge, fra OWASP til hærdning pr. sprog for JavaScript, Python, Go og Rust, og hvordan du ændrer dem. Kanonisk URL: https://lagune.ai/da-DK/docs/categories Sprog: da-DK Original: https://lagune.ai/docs/categories Sidst opdateret: 2026-11-09 **Lagune** grupperer sine indbyggede [**specialiseringer**](https://lagune.ai/da-DK/docs/catalog) i **13 kategorier**. De kategorier, et projekt bruger, afgør, hvilke indbyggede der kommer med i dets [**katalog**](https://lagune.ai/da-DK/docs/catalog), og de falder i to grupper: hvad systemet gør, og hvad det er skrevet i. Så længe der ikke er registreret nogen kategori, bruger et projekt kun `owasp`. [`/lagune-charter`](https://lagune.ai/da-DK/docs/commands/charter) registrerer hver kategori, som læsningen af projektet understøtter, og du kan selv ændre dem når som helst. ## Hvad systemet gør | Kategori | Nøgle | Hvad den hærder | | ------------- | --------- | ----------------------------------------------------------------------------------------------------------------------------------- | | OWASP | `owasp` | De risici for applikationssikkerhed, som OWASP følger: injection, mangelfuld adgangskontrol, autentificering og kryptografiske fejl | | Infrastruktur | `infra` | Konfigurationen af containere, workloads og serverless: Dockerfile, Compose, Pod-sikkerhed, IAM og triggere til FaaS | | AI / LLM | `ai` | AI- og LLM-integrationer, mod prompt injection og usikker opkobling af værktøjer, agenter, retrieval og MCP | | Lovable | `lovable` | AI-genererede Supabase-apps (Lovable og lignende): huller i RLS, lækkede nøgler til `service_role` og usikre standardindstillinger | ## Hvad det er skrevet i | Kategori | Nøgle | Hvad den hærder | | ---------- | ------------ | ----------------------------------------------------------------------------------------------------------------------------------- | | JavaScript | `javascript` | RCE via `eval` og `child_process`, path traversal og prototype pollution på tværs af dets runtimes | | Python | `python` | RCE via deserialisering med `pickle` og YAML, traversal i strenge med `str.format` og class pollution | | Rust | `rust` | Usunde `unsafe`-API'er, misbrug af `transmute`, heltalsoverløb og udefineret adfærd ved FFI-grænsen | | C / C++ | `c-cpp` | Format string-fejl, bufferoverløb og skrivninger uden for grænserne, der giver mulighed for kodeafvikling | | PHP | `php` | Omgåelse af autentificering via type juggling, gadget chains ved object injection og usikre standardindstillinger i konfigurationen | | Go | `go` | Fejl med typede nil-interfaces, data races i goroutines og usikker samtidighed på sikkerhedskritiske stier | | Java | `java` | Gadget chains ved deserialisering med `ObjectInputStream`, der ender i fjernafvikling af kode | | Ruby | `ruby` | Gadget chains ved deserialisering med `Marshal.load` og YAML, der fører til fjernafvikling af kode | | .NET / C# | `dotnet` | RCE via deserialisering med `BinaryFormatter` og de omgåelser af encodere, der fører til XSS | **Tip** **Lagune** er sprogneutralt: hele workflowet læser det, dit projekt er skrevet i, og disse kategorier tilføjer kun dybde om de faldgruber, der er specifikke for ét sprog. ## Tilføj og fjern når som helst En kategori er et udgangspunkt, ikke en forpligtelse. Brug det, der passer til projektet nu, og ændr det når som helst ud fra nøglen med `write add` og `write remove`. `--categories` uden værdi åbner en interaktiv vælger i en terminal (mellemrum for at slå til og fra, enter for at bekræfte, tomt for at springe over). Uden for en terminal angiver du kategorierne efter den. **Tilføj** ```bash npx lagune write add --categories # interactive npx lagune write add --categories owasp npx lagune write add --categories owasp rust ``` **Fjern** ```bash npx lagune write remove --categories # interactive npx lagune write remove --categories owasp npx lagune write remove --categories owasp rust ``` Den første `write add` eller `write remove` starter fra `owasp`, så hvis du fjerner alle kategorier, står du tilbage med en tom liste, aldrig standarden. Hver ændring havner i `.lagune/configs.json`, så hele teamet arbejder med det samme sæt. ## Se, hvad et projekt bruger `read list --categories` viser hver kategori, og om projektet bruger den: ```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. ``` Se [**Katalog**](https://lagune.ai/da-DK/docs/catalog) for, hvilke specialiseringer hver kategori indeholder. Dine egne specialiseringer, skrevet med [`/lagune-specialize`](https://lagune.ai/da-DK/docs/commands/specialize), kommer med i kataloget uanset kategorierne. ## Ofte stillede spørgsmål ### Hvordan tilføjer jeg en kategori? Angiv kategoriens nøgle til --categories, for eksempel npx lagune write add --categories javascript. Charter registrerer også de kategorier, som læsningen af projektet understøtter, så længe der ikke er registreret nogen. ### Kan jeg bruge mere end én kategori? Ja. Skriv dem på samme linje, den ene efter den anden. ### Hvilken kategori skal et projekt bruge? Start med owasp, standarden, og tilføj derefter den til dit sprog eller din stak. Specialiseringer indlæses kun efter behov, så en kategori koster intet, før en fase har brug for en af dens specialiseringer. --- # Katalog: sikkerhedsspecialiseringer efter behov > Sådan indlæses specialiseringerne i dit projekts katalog, af en fase efter behov og af dig direkte. Kanonisk URL: https://lagune.ai/da-DK/docs/catalog Sprog: da-DK Original: https://lagune.ai/docs/catalog Sidst opdateret: 2026-11-09 🧠 Specialiseringerne i **Lagune** er fokuserede, sprogneutrale moduler med sikkerhedsviden, der kun indlæses efter behov, aldrig som standard. De er ikke kommandoer. Dit projekts katalog er det sæt, det bruger: de indbyggede specialiseringer i dets [kategorier](https://lagune.ai/da-DK/docs/categories) plus dets egne. Faserne detect og verify griber efter dem, mens de kører, og du kan selv indlæse en direkte når som helst. **Overblik** *Det interaktive overblik over kataloget findes på websiden. Alle indbyggede specialiseringer står i tabellen nedenfor.* **Sådan virker det** ## Brug den selv Hvis du vil bruge en specialisering direkte, så bed din agent om at indlæse den med `read catalog `, og skriv opgaven i samme prompt. Viden virker så på det, du bad om. Det virker i enhver prompt, også en, der ikke har noget med workflowet i **Lagune** at gøre. For eksempel en direkte, fri prompt, der genererer en sikker samling af **RegExp** med **Python**: ```prompt Indlæs specialiseringen regex med `npx lagune read catalog regex`, og lav derefter en samling regulære udtryk i @src/utils/regex.py, der validerer e-mailadresser og brugernavne. ``` Den bruger en deterministisk hook til at teste hvert **RegExp** mod **ReDoS**, beholder de sikre og producerer noget i stil med: ```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 ``` **Prøv ReDoS-tjekket** Test selv et mønster på [**devina.io/redos-checker**](https://devina.io/redos-checker). ## De indbyggede specialiseringer De indbyggede specialiseringer er grupperet i [**kategorier**](https://lagune.ai/da-DK/docs/categories). Dette er det sæt, der følger med **Lagune**: | Specialisering | Kategori | Fokus | | --------------------- | --------------------------- | ----------------------------------------------------------------------------------------------- | | `regex` | `owasp` | **ReDoS:** mønstre, der eksploderer ved manipuleret input. | | `network` | `owasp` | **SSRF og omdirigeringer:** hente- eller omdirigeringsmål, som brugeren angiver. | | `interpreter` | `owasp`, `lovable` | **Code injection:** `eval`, dynamisk include, dispatch efter navn. | | `sql` | `owasp` | **Relationelle databaser:** injection, rå ORM-kald, rettigheder, databasemotorens rækkevidde. | | `path` | `owasp` | **Filsystemstier:** traversal, null-byte, NTFS-streams, planting. | | `upload` | `owasp` | **Filupload:** type/signatur, ondsindet indhold, lagring, grænser. | | `access-control` | `owasp`, `lovable` | **Autentificering, autorisation, session:** IDOR, mass assignment, tenants, sessioner. | | `credential-endpoint` | `owasp`, `lovable` | **Gæt og bots:** brute force, password spraying, credential stuffing, throttling. | | `federation` | `owasp` | **Tillid til tokens:** OAuth/OIDC, SAML, validering af JWT, login med QR-kode. | | `http-request` | `owasp` | **Forespørgslers oprindelse:** CSRF, fejlkonfigureret CORS, forfalsket klient-IP. | | `transport` | `owasp` | **Kanalsikkerhed:** TLS-konfiguration, HTTPS/klartekst, HSTS, pinning. | | `crypto` | `owasp`, `lovable` | **Kryptografi for lagrede data:** svage eller hjemmelavede algoritmer, CSPRNG, nøglehåndtering. | | `secrets` | `owasp`, `lovable` | **Hardcodede loginoplysninger:** nøgler, tokens, adgangskoder som literaler i kildekoden. | | `api-endpoint` | `owasp` | **Flader ud over REST:** GraphQL, gRPC, autorisation af WebSocket, DoS, skema. | | `payment` | `owasp`, `lovable` | **Checkout-flow:** verificér gatewayen på serveren, signerede callbacks, idempotens. | | `xml` | `owasp` | **XML-parsing:** XXE, eksterne entiteter, billion laughs-ekspansion. | | `csv` | `owasp` | **Formula injection:** regnearksceller, der starter med `=`/`+`/`-`/`@`. | | `container` | `owasp`, `infra` | **Containerkonfiguration:** root, capabilities, socket-mount, hærdning af imaget. | | `infra` | `infra` | **Infrastructure as code:** Terraform, Dockerfile, GitHub Actions. | | `serverless` | `owasp`, `infra`, `lovable` | **FaaS-funktioner:** IAM med mindste privilegium, hændelsesinput, kontekst, secrets. | | `llm` | `ai`, `lovable` | **AI- og LLM-risici:** prompt injection, agency, RAG, MCP, output. | | `supabase` | `lovable` | **Supabase-backend:** RLS slået fra som standard, policies fejlgenereret af AI, nøglemodel. | | `browser` | `javascript`, `lovable` | **Risici på klientsiden:** XSS, CSP, framing, lagring osv. | | `javascript` | `javascript` | **Risici på sprogniveau:** RCE, prototype pollution osv. | | `python` | `python` | **Risici på sprogniveau:** RCE via `pickle`, class pollution, `-O` osv. | | `rust` | `rust` | **Soundness i `unsafe`:** UB fra sikre kaldere, `transmute`, overløb. | | `java` | `java` | **Deserialisering og mobil kode:** kæder via `readObject`, kapring af objekter. | | `ruby` | `ruby` | **Deserialisering og `open`:** genoplivning via `Marshal`/YAML, særheden med pipes. | | `php` | `php` | **Type juggling og `unserialize`:** magic hashes, POP-kæder. | | `go` | `go` | **Typed nil og data races:** `nil != nil`, goroutines med delt hukommelse. | | `c-cpp` | `c-cpp` | **Format strings:** `printf(user_input)`, write-what-where via `%n`. | | `dotnet` | `dotnet` | **Risici på platformsniveau:** RCE via `BinaryFormatter`, `@Html.Raw`, huller i enums. | Det meste af den indbyggede viden er destilleret fra OWASP. Se [**OWASP-kilder**](https://lagune.ai/da-DK/docs/references/owasp-sources) for den fulde kobling mellem hver specialisering og dens kanoniske sider om angreb og Cheat Sheets hos OWASP. Nogle få stakspecifikke moduler bygger i stedet på leverandørens egen vejledning: `supabase` kommer for eksempel fra dokumentationen til Supabase og CVE-2025-48757. ## Dine egne specialiseringer De indbyggede vokser ved at tilføje én vidensfil plus én indeksrække, aldrig en ny kommando. Du tilføjer dine egne på samme måde med [`/lagune-specialize`](https://lagune.ai/da-DK/docs/commands/specialize): peg den mod en artikel eller et emne, så destillerer den en ny specialisering ind i dit projekt, filen under `.lagune/catalog/` og dens post i `.lagune/configs.json`. Dine egne er altid i kataloget, uanset dets kategorier, og en af dine overskygger en indbygget med samme navn. **Internt indlæser Lagune specialiseringer automatisk, efter behov** Når fasen detect eller verify rammer en kontekst, som en specialisering dækker, indlæser den selv specialiseringen med `read catalog `. Det sker automatisk som en del af fasen. Du skal ikke gøre det manuelt, for at det virker. ## Find ud af, hvad der er tilgængeligt Sådan oplister du dit projekts katalog fra terminalen, én specialisering pr. linje med dens tags: ```bash npx lagune read catalog # regex: Regular Expression [required] # network: Requests, Webhook, URL Fetch, Socket, IMDS, Redirect # interpreter: Evaluator, Sink, Shell, Dynamic Execution # ... ``` En specialisering med `[required]` gælder altid, uanset arbejdet. Hvilke indbyggede listen indeholder, afhænger af dit projekts [**kategorier**](https://lagune.ai/da-DK/docs/categories). **Specialiseringer indlæses ikke som standard** Den relevante viden hentes ind til det, projektet rent faktisk er, i stedet for at alle tjek kører som standard. ## Ofte stillede spørgsmål ### Hvad er en specialisering i Lagune? Et fokuseret, sprogneutralt modul med sikkerhedsviden, der kun indlæses efter behov, aldrig som standard. Det er ikke en kommando som agentens skills. ### Hvad er et projekts katalog? De specialiseringer, projektet bruger: de indbyggede i dets kategorier plus dets egne. Så længe der ikke er registreret nogen kategori, bruger det kun OWASP. ### Indlæses specialiseringer som standard? Nej. De indlæses kun efter behov, til det, projektet rent faktisk er. ### Hvordan indlæser jeg en specialisering direkte? Bed din agent om at køre npx lagune read catalog i samme prompt som opgaven. --- # /lagune-specialize: Træn en sikkerhedsspecialisering med almindelig tekst > Destillér en sikkerhedskilde eller et emne, du giver den, til en ny specialisering, der indlæses efter behov. Kanonisk URL: https://lagune.ai/da-DK/docs/commands/specialize Sprog: da-DK Original: https://lagune.ai/docs/commands/specialize Sidst opdateret: 2026-11-09 🎓 Lær **Lagune** en ny specialisering ud fra en kilde eller et emne, du giver den. Den læser materialet og destillerer det til en fokuseret, udelukkende defensiv specialisering, formet præcis som de [indbyggede](https://lagune.ai/da-DK/docs/catalog), så faserne detect og verify efterfølgende indlæser den som enhver anden. Den gennemgår og forklarer kun: den skriver aldrig angrebsinput eller exploits, og den rører aldrig din kode. **Fra en artikel** ```prompt # Et link eller en reference: Lagune destillerer det til forsvaret /lagune-specialize https://owasp.org/www-community/attacks/SQL_Injection ``` **Fra et exploit** ```prompt # Et angreb som kilde: specialiseringen er stadig forsvaret /lagune-specialize "' OR 1=1 -- splejser SQL ind i forespørgselsteksten" ``` **Fra et emne** ```prompt # Eller nævn blot, hvad den skal dække /lagune-specialize SQL injection ``` **Et angreb kan være kilden, aldrig resultatet** Det er fint at pege den mod et angreb, når målet er at forsvare sig mod det: en beskrivelse af et exploit er studiemateriale, som den destillerer til forsvaret. Den specialisering, den producerer, gennemgår og forklarer altid og producerer aldrig et fungerende exploit, en payload eller en omgåelse. ## Hvad den skriver Resultatet er to filer i dit projekt, committet og til at gennemse sammen med din kode: - Specialiseringen i `.lagune/catalog/.md`, formet som de [indbyggede](https://lagune.ai/da-DK/docs/catalog). - Dens post i `.lagune/configs.json`, hvor dit projekt indekserer sine egne specialiseringer, så kataloget kan flette dem med de indbyggede. Derefter oplister den kataloget for at bekræfte, at den nye post er der. Dine egne specialiseringer er altid i kataloget, uanset dets kategorier. Du tilføjer aldrig en kommando eller rører pakken: en ny specialisering er én vidensfil plus én indekspost, skrevet ind i dit eget projekt. ## Forfin, overskriv aldrig Når du specialiserer et navn, der allerede findes, hvad enten det er en indbygget som `regex` eller en, du tidligere har specialiseret, bliver den nuværende fil **afstemt** i stedet for erstattet. Den læser det, der står, folder den nye viden ind, beholder det, der stadig holder, og omskriver det, der har ændret sig. Intet bliver kasseret usét. En af dine egne specialiseringer overskygger en indbygget med samme navn, så du kan skærpe en indbygget til dit eget projekt uden at miste den. **Tip** - Den nye specialisering indlæses præcis som en indbygget: faserne detect og verify henter den efter behov, eller du kan selv indlæse den med `npx lagune read catalog ` og give den en opgave. - Når materialet har en identificerbar oprindelse (en artikel, en forfatter, et link, en standard), krediterer specialiseringen den. Et rent emne har ingen kilde. **Bemærk** **Den kører kun, når du kalder den:** agenten starter den aldrig af sig selv. ## Ofte stillede spørgsmål ### Hvordan tilføjer jeg en egen sikkerhedsspecialisering? Kør /lagune-specialize med en kilde eller et emne. Den destillerer det til en udelukkende defensiv specialisering, skrevet til .lagune/catalog/.md, samt dens post i .lagune/configs.json. ### Kan Lagune lære af en beskrivelse af et exploit? Ja, som kilde, aldrig som resultat. Et angreb kan være kilden, aldrig produktet. Specialize skriver aldrig angrebsinput eller exploits. ### Overskriver specialize de indbyggede specialiseringer? Nej. Den forfiner, den overskriver aldrig. --- # /lagune-prove: Udelukkende defensivt proof of concept > Gør hvert opdaget fund til et kørbart, udelukkende defensivt proof of concept (PoC) og en sikkerhedsmeddelelse til ansvarlig offentliggørelse. Kanonisk URL: https://lagune.ai/da-DK/docs/commands/prove Sprog: da-DK Original: https://lagune.ai/docs/commands/prove Sidst opdateret: 2026-11-09 🧪 Gør hvert opdaget fund til et kørbart, udelukkende defensivt belæg til ansvarlig offentliggørelse. For hvert fund i kortlægningen skriver den en selvstændig sikkerhedsmeddelelse og en test, der bekræfter den **sikre vej**, så testen fejler, mens problemet findes, og består, når koden er rettet. **Tip** Tests fra **Lagune** ligger isoleret under `.lagune/`, adskilt fra din egen testsuite. ## Brug **Hvert fund** ```prompt /lagune-prove ``` **Et navngivet fund** Se de fund, der allerede spores, med deres navne: ```prompt npx lagune read list --findings # Findings # ... # • SQL injection i brugeropslag # ... ``` ```prompt # Påvis derefter et af dem /lagune-prove SQL injection i brugeropslag ``` ## Sådan virker det Den læser den kildekode, hvert fund peger på, og skriver én mappe pr. påvist fund under `.lagune/proofs/` med præcis to filer: | Fil | Hvad det er | | -------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | | `report.test.mjs` (eller `.cjs`) | Testen. Den kører på Poku, når dit projekt allerede bruger det, og ellers på den indbyggede test runner i Node.js, så intet skal installeres. | | `report.md` | En selvstændig sikkerhedsmeddelelse: alvorlighed, konsekvens, hvordan problemet reproduceres, og kommandoen til at køre testen, læsbar alene. | Beviserne er altid JavaScript, så de forbliver flytbare, uanset hvilket sprog dit projekt er skrevet i. Et indeks i `README.md` linker til hvert bevis og giver én kommando til at køre dem alle. **Tip** - Den er **valgfri og selvstændig**: ikke en af de fem faser og ikke en del af sporingskæden. - Den skriver kun i `.lagune/proofs/` og rører aldrig faseartefakterne eller din kode, som den kun læser. - Et fund, hvis test ikke reproducerer problemet, får intet bevis, og den beder dig om at køre [`/lagune-detect`](https://lagune.ai/da-DK/docs/commands/detect) på det sted for at afstemme. - Når du kører den igen, bliver beviserne afstemt: et fund, der er væk eller ikke længere kan reproduceres, får sin mappe fjernet. **Bemærk** **Den kører kun, når du kalder den:** agenten starter den aldrig af sig selv. **Bygger på detect** Prove læser kortlægningen fra [`/lagune-detect`](https://lagune.ai/da-DK/docs/commands/detect), så kør detect først. ## Udelukkende defensiv og autoriseret Før den genererer noget, bekræfter den, at du har tilladelse til at teste målet, og den afviser enhver forespørgsel om et fungerende exploit, en angrebspayload eller omgåelse af detektion. Et bevis demonstrerer den sikre adfærd og udsender aldrig et angrebsinput. ## Fra bevis til offentliggørelse De to filer for hvert påvist fund hører sammen i en **privat GitHub Gist**, når du rapporterer sårbarheden. De er belæg for et aktivt, ikke-offentliggjort problem, så en `.gitignore` inde i `.lagune/proofs/` holder dem ude af hvert commit: del dem kun gennem den Gist, indtil vedligeholderne har løst problemet. At lukke et fund i kæden i **Lagune** er stadig opgaven for [`/lagune-harden`](https://lagune.ai/da-DK/docs/commands/harden) og [`/lagune-verify`](https://lagune.ai/da-DK/docs/commands/verify): prove producerer belæg, den lukker ikke noget. ## Ofte stillede spørgsmål ### Genererer Lagune exploits? Nej. /lagune-prove skriver udelukkende defensivt belæg: en test, der bekræfter den sikre vej, så den fejler, mens problemet findes, og består, når koden er rettet, samt en sikkerhedsmeddelelse til ansvarlig offentliggørelse. ### Hvad producerer prove? To filer pr. fund: en test (report.test.mjs eller .cjs) og en sikkerhedsmeddelelse (report.md). ### Hvordan offentliggør jeg ansvarligt en fejl, Lagune har fundet? Prove skriver en selvstændig sikkerhedsmeddelelse, som du kan dele gennem en privat kanal, såsom en privat GitHub Gist, efter principperne for ansvarlig offentliggørelse. --- # Konfigurér hooks: vælg, hvad de scanner > Vælg, hvad de hooks, der scanner filer, udelader, for dem alle eller for én. Kanonisk URL: https://lagune.ai/da-DK/docs/hooks/configure Sprog: da-DK Original: https://lagune.ai/docs/hooks/configure Sidst opdateret: 2026-11-09 Blokken `checkers` i `.lagune/configs.json` bestemmer, hvad de hooks, der scanner filer, udelader, for dem alle eller for én. ## Konfigurér det Tilføj eller fjern stier og mønstre fra kommandolinjen, og sæt et mønster i anførselstegn, så shellen lader det stå, som det er skrevet: ```bash npx lagune write add --ignore test/fixtures npx lagune write add --ignore 'packages/*/dist' --checker secrets npx lagune write remove --ignore test/fixtures ``` Eller vælg dem under Settings i [dashboardet](https://lagune.ai/da-DK/docs/get-started/dashboard), eller angiv dem i filen: ```json { "checkers": { "ignore": ["test/fixtures"], "secrets": { "gitignore": false, "ignore": ["test/fixtures", "temp"] } } } ``` ### Indstillinger | Nøgle | Værdi | Standard | Beskrivelse | | ----------- | -------------------------------------- | -------- | ---------------------------------------------------------------------------------------------------- | | `gitignore` | `true` eller `false` | `true` | Udelad det, **Git** ignorerer. En fil, som **Git** sporer, bliver scannet under alle omstændigheder. | | `ignore` | stier eller mønstre fra projektets rod | `[]` | Udelad det, hver enkelt matcher, og alt derunder, selv en fil, som **Git** sporer. | Øverst i `checkers` gælder en nøgle for alle tjek. Under et tjeks navn gælder den kun for det tjek og erstatter den fælles, så i eksemplet scanner `secrets` det, **Git** ignorerer, og udelader `test/fixtures` og `temp`. Når `write add --ignore` giver et tjek dets første egen liste, starter den liste som en kopi af den fælles. ### Mønstre Et mønster starter i projektets rod, så `*.generated.ts` kun rammer filerne dér, og `**/*.generated.ts` rammer dem i enhver dybde. Navne matcher præcist, inklusive store og små bogstaver. | Mønster | Udelader | | ------------------- | -------------------------------------------- | | `dist` | `dist` i projektets rod | | `packages/*/dist` | `dist` i hver mappe under `packages` | | `**/dist` | hver `dist`, i enhver dybde | | `**/*.generated.ts` | hver fil, hvis navn ender på `.generated.ts` | | `fixture-?` | `fixture-a`, `fixture-1` og lignende | | `[ab]-cache` | `a-cache` og `b-cache` | | `[*]x` | `*x`, med en bogstavelig `*` | ## Sådan læser du resultatet Rapporten slutter med, hvor mange stier scanningen udelod, efter hvad der ignorerer dem: ```text Skipped 25 paths that Git ignores and 3 paths that .lagune/configs.json ignores. Name one with --dir or --file to scan it. ``` En sti, der angives med `--dir` eller `--file`, bliver scannet, uanset hvad indstillingerne siger. En indstilling, motoren ikke kan læse, stopper tjekket med en fejl, der navngiver den, for eksempel et mønster, der starter med `!` eller et mellemrum, kravler ud af projektet, efterlader en klamme åben eller tager for lang tid at matche. ## Ofte stillede spørgsmål ### Indstiller Lagune dem for mig? Nej. Charter oplister de committede mapper, som læsningen viser ikke er din kode at forsvare, såsom testfixtures skrevet til at se sårbare ud, og registrerer kun dem, du vælger med numre. ### Hvornår skal et tjek scanne det, Git ignorerer? Når repositoriet ikke er dit at stole på, da dets egne .gitignore-filer kan skjule kode, eller når en build-mappe kan indeholde en nøgle, der er indsat ved build. Sæt gitignore til false for alle tjek eller for ét. --- # Hook agent: find agentløkker uden loft > Gennemsøg en kodebase for agent- og LLM-kald uden loft over trin eller tid, eller vurdér et enkelt kald, fra kommandolinjen. Kanonisk URL: https://lagune.ai/da-DK/docs/hooks/agent Sprog: da-DK Original: https://lagune.ai/docs/hooks/agent Sidst opdateret: 2026-11-09 Hooken `agent` markerer **agent-runtimes, der kører i løkke uden loft over ture, budget eller tid**, det hul i form af løbsk autonomi, der gør et manipuleret input til ubegrænsede omkostninger eller eskalering via prompt injection. Den er **sprogbevidst** og dækker de to økosystemer af agent-frameworks: **JavaScript** (runtimen `query` i agent-SDK'et fra **Claude**) og **Python** (**LangChain**, **LangGraph**, **CrewAI**, **OpenAI Agents**). Den er den deterministiske motor bag [specialiseringen `llm`](https://lagune.ai/da-DK/docs/catalog), som du selv kan køre i tilstanden **scan** eller **check**. ## Kørsel **Scan kodebasen** ```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 ``` **Tjek et kald** ```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 ``` Hver linje under **Uncapped agent loops found** er, i en fil, der importerer et agent-SDK, enten runtimen `query` fra agent-SDK'et til Claude kaldt uden loft over ture, budget eller tid (JavaScript, ubegrænset som standard), eller en udtrykkelig fjernelse af et frameworks standardloft såsom `max_iterations=None` / `max_turns=None` (Python, med loft som standard). Begge afslutter med en kode forskellig fra nul. `generateText`/`streamText` i Vercel AI SDK bruger som standard et enkelt trin (`stopWhen: stepCountIs(1)`), så et bart kald dér kan ikke køre i løkke og bliver ikke markeret, og et almindeligt `db.query(...)` forveksles aldrig med et agentkald. En ren kørsel udskriver `no uncapped agent loops found`. ## Sådan læser du afgørelsen | Afgørelse | Betydning | | ---------- | ---------------------------------------------------------------------------------------------------------------------- | | `uncapped` | Et kald til runtimen `query` uden loft (JS), eller en udtrykkelig fjernelse af loftet (`=None`, Py). | | `safe` | Et kald til `query`, der sætter et loft, en generering i ét trin eller et kald til et framework med loft som standard. | | `invalid` | Kodeuddraget indeholder intet genkendeligt agentkald at vurdere. | ### CLI-indstillinger | Indstilling | Værdi | Beskrivelse | | ----------- | ------------- | ------------------------------------------------------------------------------ | | `--pattern` | et kodeuddrag | Tjek ét kald. Gentag for at tjekke flere, én afgørelse pr. linje. | | `--lang` | et sprog | Påkrævet med `--pattern`: `javascript` eller `python`. | | `--dir` | en mappe | Afgræns en scanning til en mappe. Kan gentages og kombineres med `--file`. | | `--file` | en fil | Afgræns en scanning til en enkelt fil. Kan gentages og kombineres med `--dir`. | Uden indstillinger scanner den hele projektet. `--pattern` kræver `--lang` og kan ikke kombineres med `--dir` eller `--file`. ### Vælg, hvad den scanner Den udelader det, **Git** ignorerer. For at udelade mere, eller for at scanne det, **Git** ignorerer, så giv `agent` sine egne indstillinger: ```bash npx lagune write add --ignore test/fixtures --checker agent ``` ```json { "checkers": { "agent": { "gitignore": false, "ignore": ["test/fixtures"] } } } ``` [Konfigurér hooks](https://lagune.ai/da-DK/docs/hooks/configure) beskriver alle indstillinger. **Efter bedste evne, ikke udtømmende** En håndskrevet agentløkke, i et hvilket som helst sprog, ligger uden for en statisk scanning. Betragt dette som et solidt minimum, ikke en komplet oversigt. **Tip** Hooken afgør kun loftet: afgrænsning af kapabiliteter, sammenblanding af tillid og autorisation er vurderinger, som [specialiseringen `llm`](https://lagune.ai/da-DK/docs/catalog) stadig dækker. ## Ofte stillede spørgsmål ### Hvorfor sætte et loft over en agentløkke? En agent uden loft kan drives ud i ubegrænset rekursion, ubegrænsede omkostninger eller eskalering via prompt injection. Ved at sætte maxTurns/maxBudgetUsd/stopWhen/signal begrænses den, og hooken agent markerer et kald til runtimen query, der ikke sætter nogen af dem. --- # Hook cors: gennemgå CORS-origins > Scan kildekoden for en tilladelsesliste over CORS-origins, der kan omgås, eller vurdér, om en enkelt origin-værdi giver for bred adgang, fra kommandolinjen. Kanonisk URL: https://lagune.ai/da-DK/docs/hooks/cors Sprog: da-DK Original: https://lagune.ai/docs/hooks/cors Sidst opdateret: 2026-11-09 Hooken `cors` er den deterministiske motor bag [specialiseringen `http-request`](https://lagune.ai/da-DK/docs/catalog), og du kan selv køre den. Den virker i to tilstande fra én kommando: en **scanning**, der gennemsøger kildekoden for en **tilladelsesliste over origins, der kan omgås** (et regex til validering af værter, som en angribers vært slipper forbi), og en **vurdering**, der klassificerer en enkelt **CORS-origin** som `wildcard`, `null` eller `safe`. ## Scan en kodebase Uden flag scanner den hele projektet. **Hele projektet** ```bash npx lagune read cors ``` **En mappe** ```bash npx lagune read cors --dir src/server ``` **En enkelt fil** ```bash npx lagune read cors --file internal/auth/origin.go ``` Den oplister hver tilladelsesliste, der kan omgås, under én overskrift, grupperet efter fil. En værtsvalidator, hvis `.+` eller `.*` står i authority-delen før suffikset for den betroede vært (`^https?://.+\.trusted\.com`), lader en angribers vært som `your-site.com.attacker.com` slippe forbi. ```text Origin-allowlist patterns with a greedy wildcard (bypassable, review): internal/auth/origin.go ^https?://.+\.trusted\.com ``` Det er et spor at gennemgå, ikke et lukket fund: om regexet styrer en reel tillidsbeslutning, kan ikke afgøres ud fra teksten, så en scanning ændrer aldrig exitkoden. Læs hver enkelt, og bekræft, at tilladelseslisten sammenligner med fuld lighed. Når intet bliver fundet, udskriver den en enkelt linje. ```bash npx lagune read cors --dir src/clean # => no bypassable origin allowlist found ``` ## Vurdér en origin Angiv hver origin med `--origin`. Hooken udskriver ét ord pr. origin og afslutter med en kode forskellig fra nul ved enhver `wildcard` eller `null`. **Én 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 ``` **Flere origins** Gentag `--origin` for at vurdere en hel tilladelsesliste i ét kald, én afgørelse pr. linje, i rækkefølge. ```bash npx lagune read cors \ --origin 'https://app.example.com' \ --origin '*' \ --origin 'null' # => safe # => wildcard # => null ``` | Afgørelse | Betydning | | ---------- | ---------------------------------------------------------------------------------------------------------- | | `safe` | Hverken `*`, `null` eller et glob med `*`. Det garanterer ikke en velformet origin. | | `wildcard` | `*` eller et glob for underdomæne, vært eller port: ethvert websted (eller en bred mængde) må læse svaret. | | `null` | Origin `null`, som iframes i sandbox og omdirigeringer kan forfalske. | Kun `safe` er en tilladelse, og `--origin` er et orakel for værdier: det vurderer værdien, ikke handleren, så bekræft handleren med specialiseringen `http-request`. ### CLI-indstillinger | Indstilling | Værdi | Beskrivelse | | ----------- | --------- | ------------------------------------------------------------------------------ | | `--origin` | en origin | Vurdér én origin-værdi. Gentag for at vurdere flere, én pr. linje. | | `--dir` | en mappe | Afgræns en scanning til en mappe. Kan gentages og kombineres med `--file`. | | `--file` | en fil | Afgræns en scanning til en enkelt fil. Kan gentages og kombineres med `--dir`. | Uden indstillinger scanner den hele projektet. `--origin` er vurderingstilstanden og kan ikke kombineres med `--dir` eller `--file`. ### Vælg, hvad den scanner Den udelader det, **Git** ignorerer. For at udelade mere, eller for at scanne det, **Git** ignorerer, så giv `cors` sine egne indstillinger: ```bash npx lagune write add --ignore test/fixtures --checker cors ``` ```json { "checkers": { "cors": { "gitignore": false, "ignore": ["test/fixtures"] } } } ``` [Konfigurér hooks](https://lagune.ai/da-DK/docs/hooks/configure) beskriver alle indstillinger. **Hvad den ikke dækker** Scanningen læser formen med **regex, der kan omgås**, og `--origin` vurderer **værdier** af origins. To mønstre i kildekoden forbliver uden for rækkevidde: spejling af forespørgslens `Origin` (serveren sender den indkommende `Origin` uændret tilbage eller kombinerer den med loginoplysninger) og en eftergivende tilladelsesliste baseret på `endsWith` eller delstrenge. Genkend dem i koden, og behandl dem, som [specialiseringen `http-request`](https://lagune.ai/da-DK/docs/catalog) beskriver. ## Ofte stillede spørgsmål ### Hvorfor er en CORS-origin null farlig? Iframes i sandbox og visse omdirigeringer sender Origin: null, så en tilladelsesliste, der stoler på null, giver de kontekster læseadgang. Hooken cors markerer den sammen med wildcard. ### Hvordan fanger jeg en tilladelsesliste over CORS-origins, der kan omgås? Kør npx lagune read cors over kodebasen. Den markerer et regex til validering af værter, hvis grådige wildcard står før det betroede suffiks, så en angribers vært som your-site.com.attacker.com slipper forbi. --- # Hook crypto: find svag kryptografi > Gennemsøg en kodebase for svage kryptografiske primitiver, eller vurdér et enkelt kodeuddrag, fra kommandolinjen. Kanonisk URL: https://lagune.ai/da-DK/docs/hooks/crypto Sprog: da-DK Original: https://lagune.ai/docs/hooks/crypto Sidst opdateret: 2026-11-09 Hooken `crypto` markerer **svage kryptografiske primitiver** på kaldstedet: en udfaset cipher, en usikker tilstand eller en brudt digest. Den er **sprogbevidst** og læser hver fil efter dens egne regler, så en Python-konstruktion aldrig bliver markeret i en Rust-fil, og den er den deterministiske motor bag [specialiseringen `crypto`](https://lagune.ai/da-DK/docs/catalog), som du selv kan køre i tilstanden **scan** eller **check**. ## Kørsel **Scan kodebasen** ```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 ``` **Tjek et kodeuddrag** ```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 ``` Scanningen udskriver op til to afsnit. **Weak cryptography found** er sættet af fund (DES/3DES/RC4/Blowfish/RC2, tilstanden ECB): hver er en brudt cipher-primitiv, så hooken afslutter med en kode forskellig fra nul. **Cryptography to review manually** er et sæt spor, den ikke kan vurdere alene: en MD5/SHA-1-digest (brudt til sikkerhedsbrug, men legitim som almindelig checksum, så hensigten afgør det), en ikke-kryptografisk RNG i en sikkerhedskontekst eller en sammenligning, der ikke er sikker mod timingangreb. En ren kørsel udskriver `no weak cryptography found`. ## Sådan læser du afgørelsen | Afgørelse | Betydning | | --------- | -------------------------------------------------------------------------------------------------------------------- | | `weak` | Kodeuddraget bruger en brudt cipher-primitiv (DES/3DES, RC4, Blowfish, RC2 eller tilstanden ECB). | | `review` | En primitiv, der afhænger af hensigten: en MD5/SHA-1-digest eller en ikke-kryptografisk RNG i en sikkerhedskontekst. | | `safe` | Kodeuddraget bruger kryptografi, og der blev ikke fundet nogen svag primitiv. | | `invalid` | Kodeuddraget indeholder ingen genkendelig kryptografisk konstruktion at vurdere. | ### CLI-indstillinger | Indstilling | Værdi | Beskrivelse | | ----------- | ------------- | ------------------------------------------------------------------------------------------------------ | | `--pattern` | et kodeuddrag | Tjek ét kodeuddrag. Gentag for at tjekke flere, én afgørelse pr. linje. | | `--lang` | et sprog | Påkrævet med `--pattern`: et af javascript, python, go, java, kotlin, php, ruby, rust, csharp, c, cpp. | | `--dir` | en mappe | Afgræns en scanning til en mappe. Kan gentages og kombineres med `--file`. | | `--file` | en fil | Afgræns en scanning til en enkelt fil. Kan gentages og kombineres med `--dir`. | Uden indstillinger scanner den hele projektet. `--pattern` kræver `--lang` og kan ikke kombineres med `--dir` eller `--file`. ### Vælg, hvad den scanner Den udelader det, **Git** ignorerer. For at udelade mere, eller for at scanne det, **Git** ignorerer, så giv `crypto` sine egne indstillinger: ```bash npx lagune write add --ignore test/fixtures --checker crypto ``` ```json { "checkers": { "crypto": { "gitignore": false, "ignore": ["test/fixtures"] } } } ``` [Konfigurér hooks](https://lagune.ai/da-DK/docs/hooks/configure) beskriver alle indstillinger. ### Understøttede sprog Scanningen læser disse sprog, bestemt ud fra filendelsen, og hvert sprog tjekkes mod sine egne kryptografiske API'er. | Sprog | Svage ciphers (fund) og digests eller RNG (gennemgang) | | --------------------------- | -------------------------------------------------------------------------------------------------------------------- | | **JavaScript / TypeScript** | `createCipher`, `CryptoJS.DES/RC4`, `*-ecb` i anførselstegn; 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()` | **Efter bedste evne, ikke udtømmende** Den læser kildekoden som tekst, så en primitiv, der sættes sammen under kørslen, skjules bag et alias eller skrives i en form, den ikke genkender, kan slippe forbi. Betragt tabellen som et solidt udgangspunkt, ikke en komplet oversigt. **Tip** Hooken garanterer minimummet (at disse konstruktioner findes): nøglehåndtering, genbrug af IV og RSA-padding er vurderinger, som [specialiseringen `crypto`](https://lagune.ai/da-DK/docs/catalog) stadig dækker. ## Ofte stillede spørgsmål ### Hvordan scanner jeg en kodebase for svag kryptografi? Kør hooken crypto uden flag. Brudte ciphers og tilstanden ECB er fund, der afslutter med en kode forskellig fra nul. En MD5/SHA-1-digest er et spor til gennemgang, da den er brudt til sikkerhedsbrug, men legitim som almindelig checksum. ### Markerer hooken crypto Math.random()? Kun som et spor til gennemgang i en sikkerhedskontekst, aldrig som et automatisk fund, da tilfældighed er legitim til jitter eller rækkefølge i brugerfladen. --- # Hook cvss: beregn scoren for en CVSS v4.0-vektor > Beregn scoren for en eller flere CVSS v4.0-vektorer fra kommandolinjen med samme aritmetik som lommeregneren fra FIRST, og få hver af dem forklaret i almindelige ord. Kanonisk URL: https://lagune.ai/da-DK/docs/hooks/cvss Sprog: da-DK Original: https://lagune.ai/docs/hooks/cvss Sidst opdateret: 2026-11-09 Hooken `cvss` beregner scoren for en **CVSS v4.0-vektor** og udskriver dens score og alvorlighedsniveau, den vurdering, som [`/lagune-plan`](https://lagune.ai/da-DK/docs/commands/plan) skriver på hver rettelse og [`/lagune-prove`](https://lagune.ai/da-DK/docs/commands/prove) på hver sikkerhedsmeddelelse. Den er den deterministiske motor bag de vurderinger, med samme aritmetik som [lommeregneren fra FIRST](https://www.first.org/cvss/calculator/4.0), og du kan selv køre den. ## Kørsel Angiv hver vektor med `--vector`. Hooken udskriver én linje pr. vektor: dens score og niveau. **Én 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 ``` **Flere vektorer** Gentag `--vector` for at beregne flere på én gang, én linje hver, i rækkefølge. ```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 ``` **I almindelige ord** Tilføj `--explain` for at få hver metrik forklaret i almindelige ord. Når Threat- eller Environmental-metrikker flytter scoren, kommer Base-scoren alene først. ```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 # => ... ``` ## Sådan læser du resultatet | Niveau | Score | | ---------- | ------------ | | `None` | 0.0 | | `Low` | 0.1 til 3.9 | | `Medium` | 4.0 til 6.9 | | `High` | 7.0 til 8.9 | | `Critical` | 9.0 til 10.0 | En vektor med kun Base-metrikker vurderer selve fejlen og antager det værste: alle sikkerhedskrav sat til High, og fejlen angrebet i praksis. Environmental-metrikker (`MAV` og de andre modificerede metrikker samt `CR`, `IR` og `AR`) afgør den for én bestemt udrulning, og Threat-metrikken (`E`) ud fra, hvad der vides om udnyttelse. En ugyldig vektor udskriver `invalid vector:` og hvad der er galt, og hooken afslutter med en kode forskellig fra nul. ### CLI-indstillinger | Indstilling | Værdi | Beskrivelse | | ----------- | -------------------- | -------------------------------------------------------------------------------------------- | | `--vector` | en `CVSS:4.0`-vektor | Beregn scoren for én vektor. Gentag for at beregne flere, én linje pr. vektor, i rækkefølge. | | `--explain` | | Tilføj hver metrik i almindelige ord under hver linje med en vurdering. | Mindst én `--vector` er påkrævet. Vektoren er aldrig et bart positionelt argument, så den kan ikke forveksles med et flag. **Hvorfor en værdi til et flag** Hver vektor angives som værdi til et flag og indsættes aldrig i selve kommandoen. En værdi med anførselstegn eller backticks forbliver uskadelig og kan ikke injicere noget i shellen. Sæt den altid i enkelte anførselstegn, så din shell ikke ekspanderer den først. **Hvad den ikke dækker** Kun CVSS v4.0: en vektor i v2.0, v3.0 eller v3.1 bliver afvist i stedet for at blive vurderet, da **Lagune** vurderer hvert fund i v4.0. **Tip** Valideringen i fasen plan kører den samme aritmetik igen på hver CVSS-linje, så en score, der er gledet væk fra sin vektor, bliver fanget, før planen godkendes. ## Ofte stillede spørgsmål ### Hvordan beregner Lagune en CVSS-score? Hooken cvss følger referencelommeregneren fra FIRST til CVSS v4.0, så en vektor får præcis samme score som på webstedet for FIRST. ### Kan jeg beregne scoren for en CVSS v3.1-vektor med den? Nej. Lagune vurderer hvert fund i CVSS v4.0, og hooken afviser enhver anden version i stedet for at vurdere den. ### Hvad gør flaget --explain? Det forklarer hver metrik i almindelige ord og viser Base-scoren ved siden af den samlede, så alle kan se, hvad vektoren siger, og hvordan projektets kontekst flyttede den. --- # Hook infra: find fejlkonfiguration i IaC > Gennemsøg Terraform, Dockerfiles og GitHub Actions for fejlkonfiguration, eller vurdér et enkelt kodeuddrag, fra kommandolinjen. Kanonisk URL: https://lagune.ai/da-DK/docs/hooks/infra Sprog: da-DK Original: https://lagune.ai/docs/hooks/infra Sidst opdateret: 2026-11-09 Hooken `infra` markerer **fejlkonfiguration i infrastructure as code**, der kan afgøres ud fra filen: et netværk, der er åbent for hele verden, en tilladelse med wildcard, en secret i et manifest, en container, der kører som root, en ikke-betroet værdi i en CI-shell. Den læser kun IaC-filer (`.tf`/`.tf.json`/`.hcl`, `Dockerfile*`, `.github/workflows/**`). Den er den deterministiske motor bag [specialiseringen `infra`](https://lagune.ai/da-DK/docs/catalog), i tilstanden **scan** eller **check**. ## Kørsel **Scan kodebasen** ```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 ``` **Tjek et kodeuddrag** Angiv kodeuddraget med `--pattern` og dets type med `--kind` (`terraform`, `dockerfile` eller `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 ``` Scanningen udskriver op til to afsnit. **Infrastructure risks found** afslutter med en kode forskellig fra nul og indeholder de fejl, der kan afgøres (en ingress fra `0.0.0.0/0` på en følsom port, en IAM-erklæring med wildcard, en secret i et manifest, `encrypted = false`, et git-modul uden fastlåst version, et image, der udtrykkeligt kører som root, en `curl | sh`, en script injection i CI, `permissions: write-all`). **Infrastructure hardening advisories** ændrer ikke exitkoden (et foranderligt basis-tag, en action, der kun er fastlåst med et tag). En ren kørsel udskriver `no infrastructure risks found`. ## Sådan læser du afgørelsen Tilstanden check udskriver det mest alvorlige tag, den matchede (for eksempel `public-ingress`, `iam-wildcard`, `root-user`, `curl-pipe`, `script-injection`, `write-all`), et tag til en anbefaling (`mutable-tag`, `unpinned-action`) eller `safe`. Kun et tag med alvorligheden fund afslutter med en kode forskellig fra nul. ### CLI-indstillinger | Indstilling | Værdi | Beskrivelse | | ----------- | ----------------------------------------------- | ------------------------------------------------------------------------------ | | `--pattern` | et kodeuddrag | Tjek ét kodeuddrag. Kræver `--kind`. Gentag for flere. | | `--kind` | `terraform` \| `dockerfile` \| `github-actions` | Den type, kodeuddraget vurderes som. | | `--dir` | en mappe | Afgræns en scanning til en mappe. Kan gentages og kombineres med `--file`. | | `--file` | en fil | Afgræns en scanning til en enkelt fil. Kan gentages og kombineres med `--dir`. | Uden indstillinger scanner den hver IaC-fil i projektet. `--pattern` kan ikke kombineres med `--dir` eller `--file`. ### Vælg, hvad den scanner Den udelader det, **Git** ignorerer. For at udelade mere, eller for at scanne det, **Git** ignorerer, så giv `infra` sine egne indstillinger: ```bash npx lagune write add --ignore examples --checker infra ``` ```json { "checkers": { "infra": { "gitignore": false, "ignore": ["examples"] } } } ``` [Konfigurér hooks](https://lagune.ai/da-DK/docs/hooks/configure) beskriver alle indstillinger. **Tip** Hooken fanger de åbenlyse tilfælde, der kan afgøres: manglende kryptering, eksponering via `pull_request_target` og det rette IAM-omfang er vurderinger, som [specialiseringen `infra`](https://lagune.ai/da-DK/docs/catalog) stadig dækker. ## Ofte stillede spørgsmål ### Hvilke infrastrukturfiler læser hooken infra? Terraform/HCL (.tf, .tf.json, .hcl), Dockerfiles samt YAML til workflows og actions i GitHub Actions under .github/. Den når de filer, selvom scannerne af kildekode springer dem over. --- # Hook interpreter: markér sinks til dynamisk kodeafvikling > Gennemsøg en kodebase for sinks til dynamisk kodeafvikling på tværs af sprog, eller vurdér et enkelt kodeuddrag, fra kommandolinjen. Kanonisk URL: https://lagune.ai/da-DK/docs/hooks/interpreter Sprog: da-DK Original: https://lagune.ai/docs/hooks/interpreter Sidst opdateret: 2026-11-09 Hooken `interpreter` markerer **sinks til dynamisk kodeafvikling**: konstruktioner, der gør data til kørende kode eller giver dem videre til en shell, fra `eval` til indbygget deserialisering. Den er sprogbevidst og læser hver fil efter dens egne regler, og den er den deterministiske motor bag [specialiseringen `interpreter`](https://lagune.ai/da-DK/docs/catalog), som du selv kan køre i tilstanden **scan** eller **check**. ## Kørsel **Scan kodebasen** ```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 ``` **Tjek et kodeuddrag** ```bash npx lagune read interpreter --lang javascript --pattern 'eval(x)' # => careful npx lagune read interpreter --lang python --pattern 'json.loads(x)' # => safe ``` Disse sinks har dobbelt anvendelse: om input, som en angriber kan påvirke, når frem til en af dem, kan ikke afgøres af en statisk scanning, så hvert match er en **advarsel at gennemgå**, aldrig et bekræftet fund. Scanningen udskriver et enkelt afsnit, **Dynamic-execution sinks to review**, grupperet efter fil. En ren kørsel udskriver `no dynamic-execution sinks found`. **Læs den markerede kode, kør den aldrig!** Ræsonnér om hver sink **statisk**, og følg, om ikke-betroet input når frem til den. Kør aldrig den markerede kode, og brug aldrig `eval` på den eller på kode, den henter eksternt eller under kørslen, for at "teste", hvad den gør. ## Sådan læser du afgørelsen | Afgørelse | Betydning | | --------- | --------------------------------------------------------------------------------------------------------------------------- | | `careful` | Kodeuddraget indeholder en sink til dynamisk afvikling for sit sprog. Gennemgå den ved at læse den, aldrig ved at køre den. | | `safe` | Der blev ikke fundet nogen sink til dynamisk afvikling for det angivne sprog. | ### CLI-indstillinger | Indstilling | Værdi | Beskrivelse | | ----------- | ------------- | ------------------------------------------------------------------------------------------------------ | | `--pattern` | et kodeuddrag | Tjek ét kodeuddrag. Gentag for at tjekke flere, én afgørelse pr. linje. | | `--lang` | et sprog | Påkrævet med `--pattern`: et af javascript, python, php, ruby, java, kotlin, go, rust, c, cpp, csharp. | | `--dir` | en mappe | Afgræns en scanning til en mappe. Kan gentages og kombineres med `--file`. | | `--file` | en fil | Afgræns en scanning til en enkelt fil. Kan gentages og kombineres med `--dir`. | Uden indstillinger scanner den hele projektet. `--pattern` kræver `--lang` og kan ikke kombineres med `--dir` eller `--file`. ### Vælg, hvad den scanner Den udelader det, **Git** ignorerer. For at udelade mere, eller for at scanne det, **Git** ignorerer, så giv `interpreter` sine egne indstillinger: ```bash npx lagune write add --ignore test/fixtures --checker interpreter ``` ```json { "checkers": { "interpreter": { "gitignore": false, "ignore": ["test/fixtures"] } } } ``` [Konfigurér hooks](https://lagune.ai/da-DK/docs/hooks/configure) beskriver alle indstillinger. ### Understøttede sprog Scanningen læser disse sprog, bestemt ud fra filendelsen, og hvert sprog tjekkes mod sit eget sæt af sinks til dynamisk afvikling. | # | Sprog | Filendelser | Sinks, den markerer | | --- | --------------------------- | ------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1 | **JavaScript / TypeScript** | `.js`, `.jsx`, `.mjs`, `.cjs`, `.ts`, `.tsx`, `.mts`, `.cts`, `.astro`, `.vue`, `.svelte`, `.marko`, `.riot` | `eval()`, Function-konstruktøren, `setTimeout`/`setInterval` med en streng som krop, modulet `vm`, exec fra `child_process`, dynamisk `require()`, dynamisk `import()` | | 2 | **Python** | `.py`, `.pyi` | `eval`/`exec`, `__import__()`, `os.system`/`os.popen`, `subprocess` `shell=True`, `pickle.load`/`loads`, `yaml.load` (usikker) | | 3 | **Ruby** | `.rb` | eval-familien (`instance_eval`/`class_eval`/`module_eval`/`eval`), `system`/`exec`, backticks eller `%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()` på en streng, `create_function()`, shell-exec (`system`/`exec`/`shell_exec`/`passthru`/`popen`/`proc_open`), `call_user_func`/`call_user_func_array`, `include`/`require` med en sti fra kørslen | | 6 | **Rust** | `.rs` | `Command::new`, `process::Command` | | 7 | **Java** | `.java` | `Runtime.exec`, `ProcessBuilder`, `ScriptEngine`, `ObjectInputStream.readObject` | | 8 | **Kotlin** | `.kt`, `.kts` | JVM-sinks: `Runtime.exec`, `ProcessBuilder`, `ScriptEngine`, `ObjectInputStream.readObject` | | 9 | **C#** | `.cs` | `Process.Start` / `new Process`, `BinaryFormatter`, `Assembly.Load` | | 10 | **C** | `.c`, `.h` | `system()`, `popen()`, familien `exec*` (`execl`, `execve`, `execvp`, …) | | 11 | **C++** | `.cc`, `.cpp`, `.cxx`, `.hpp`, `.hh`, `.hxx` | `system()`, `popen()`, familien `exec*` (`execl`, `execve`, `execvp`, …) | **Efter bedste evne, ikke udtømmende** Den læser kildekoden som tekst, så en sink, der sættes sammen under kørslen, skjules bag et alias eller skrives i en form, den ikke genkender, kan slippe forbi. Betragt tabellen som et solidt udgangspunkt, ikke en komplet oversigt. **Tip** Hooken garanterer minimummet (at disse sinks findes, og hvor): om en ikke-betroet værdi faktisk når frem til en af dem, er den vurdering, som [specialiseringen `interpreter`](https://lagune.ai/da-DK/docs/catalog) dækker. ## Ofte stillede spørgsmål ### Bekræfter hooken interpreter en sårbarhed? Nej. Den markerer sinks til dynamisk afvikling som en advarsel at gennemgå, aldrig et bekræftet fund, fordi en statisk scanning ikke kan afgøre, om input, som en angriber kan påvirke, når frem til sinken. ### Hvilke sprog dækker hooken interpreter? Den læser sprogene i tabellen Understøttede sprog, bestemt ud fra filendelsen, og hvert sprog tjekkes mod sit eget sæt af sinks. Andre sprog giver ingen sinks. --- # Hook jwt: find JWT-verifikation uden fastlåst algoritme > Gennemsøg en kodebase for JWT-verifikation uden fastlåst algoritme, eller vurdér et enkelt kald, fra kommandolinjen. Kanonisk URL: https://lagune.ai/da-DK/docs/hooks/jwt Sprog: da-DK Original: https://lagune.ai/docs/hooks/jwt Sidst opdateret: 2026-11-09 Hooken `jwt` markerer **JWT-verifikation uden fastlåst algoritme**, hullet med algoritmeforvirring, hvor en verifikator stoler på tokenets egen header `alg`, og **verifikation, der er slået helt fra**. Den er **sprogbevidst** og læser hver fil efter dens eget JWT-bibliotek, og den er den deterministiske motor bag [specialiseringen `federation`](https://lagune.ai/da-DK/docs/catalog), som du selv kan køre i tilstanden **scan** eller **check**. ## Kørsel **Scan kodebasen** ```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 ``` **Tjek et kald** ```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 ``` Hver linje under **Unpinned JWT verification found** er et verifikationskald, der ikke sætter nogen tilladelsesliste i `algorithms` (hvor biblioteket kræver en), accepterer en usikker (`none` eller en asymmetrisk algoritme blandet med HMAC) eller helt slår signaturtjekket fra, så det stoler på tokenets egen `alg`. Det er en bekræftet eksponering, så hooken afslutter med en kode forskellig fra nul. En ren kørsel udskriver `no unpinned JWT verification found`. ## Sådan læser du afgørelsen | Afgørelse | Betydning | | ---------- | ----------------------------------------------------------------------------------------------------------------------------------- | | `unpinned` | Et verifikationskald uden tilladelsesliste over algoritmer (hvor der kræves en), med en usikker eller med verifikationen slået fra. | | `safe` | Et verifikationskald, der fastlåser en sund tilladelsesliste over algoritmer, eller hvis bibliotek fastlåser den implicit. | | `invalid` | Kodeuddraget indeholder intet genkendeligt verifikationskald at vurdere. | ### CLI-indstillinger | Indstilling | Værdi | Beskrivelse | | ----------- | ------------- | ---------------------------------------------------------------------------------------------- | | `--pattern` | et kodeuddrag | Tjek ét kald. Gentag for at tjekke flere, én afgørelse pr. linje. | | `--lang` | et sprog | Påkrævet med `--pattern`: et af javascript, python, go, java, kotlin, php, ruby, rust, csharp. | | `--dir` | en mappe | Afgræns en scanning til en mappe. Kan gentages og kombineres med `--file`. | | `--file` | en fil | Afgræns en scanning til en enkelt fil. Kan gentages og kombineres med `--dir`. | Uden indstillinger scanner den hele projektet. `--pattern` kræver `--lang` og kan ikke kombineres med `--dir` eller `--file`. ### Vælg, hvad den scanner Den udelader det, **Git** ignorerer. For at udelade mere, eller for at scanne det, **Git** ignorerer, så giv `jwt` sine egne indstillinger: ```bash npx lagune write add --ignore test/fixtures --checker jwt ``` ```json { "checkers": { "jwt": { "gitignore": false, "ignore": ["test/fixtures"] } } } ``` [Konfigurér hooks](https://lagune.ai/da-DK/docs/hooks/configure) beskriver alle indstillinger. ### Understøttede sprog Scanningen læser disse biblioteker, bestemt ud fra filendelsen. Fordi nogle fastlåser algoritmen implicit (en manglende udtrykkelig liste er sund), gælder reglen "ingen tilladelsesliste ⇒ unpinned" kun dér, hvor biblioteket forventer en udtrykkelig liste, så et korrekt konfigureret kald bliver aldrig markeret. | Sprog | Bibliotek | Markerer manglende tilladelsesliste som unpinned? | Markerer altid | | --------------------------- | ----------------------- | ------------------------------------------------------------------------ | ----------------------------------------------- | | **JavaScript / TypeScript** | jsonwebtoken, jose | Ja | `none`, blanding af asymmetrisk og HMAC | | **Python** | PyJWT, python-jose | Ja (PyJWT kræver den, python-jose bruger som standard `algorithms=None`) | `none`, `verify_signature: False` | | **Go** | golang-jwt | Ja (uden `WithValidMethods`) | `none`, `ParseUnverified` | | **Ruby** | ruby-jwt | Ja | `none`, `verify = false` | | **Java / Kotlin** | jjwt, nimbus | Nej (udledt af nøglen) | `none`, en usigneret eller `unsecured` parser | | **PHP** | firebase/php-jwt | Nej (`Key` bærer algoritmen) | `none` | | **Rust** | jsonwebtoken | Nej (`Validation` kræver en) | `none`, `insecure_disable_signature_validation` | | **C#** | Microsoft.IdentityModel | Nej (parametre over flere linjer) | `none`, `RequireSignedTokens = false` | **Tip** Hooken afgør kun fastlåsningen af algoritmen: tjek af claims, nøgler og flow er vurderinger, som [specialiseringen `federation`](https://lagune.ai/da-DK/docs/catalog) stadig dækker. ## Ofte stillede spørgsmål ### Hvad er algoritmeforvirring i JWT? En verifikator, der læser algoritmen fra tokenets header, lader en angriber bytte RS256 ud med HS256 og signere med den offentlige nøgle. At fastlåse en sund tilladelsesliste over algoritmer i koden forhindrer det, og hooken jwt markerer et verifikationskald, der ikke sætter nogen eller sætter en usikker. --- # Hook network: vurdér URL'er for SSRF > Vurdér et eller flere hentemål for SSRF direkte fra kommandolinjen. Kanonisk URL: https://lagune.ai/da-DK/docs/hooks/network Sprog: da-DK Original: https://lagune.ai/docs/hooks/network Sidst opdateret: 2026-11-09 Hooken `network` afgør, om et hentemål på serversiden er sikret mod **SSRF** (en forespørgsel, der kan rettes mod interne tjenester, cloud-metadata eller private værter). Den er den deterministiske motor bag [specialiseringen `network`](https://lagune.ai/da-DK/docs/catalog), og du kan selv køre den. ## Kørsel Angiv hvert mål med `--url`. Hooken udskriver ét ord pr. mål, som du kan slå op i tabellen nedenfor. **Ét mål** ```bash npx lagune read network --url 'http://example.com/' # => safe npx lagune read network --url 'http://0x7f000001/' # => private-target ``` **Flere mål** Gentag `--url` for at vurdere en hel tilladelsesliste eller blokeringsliste i ét kald, én afgørelse pr. linje, i rækkefølge. ```bash npx lagune read network \ --url 'http://example.com/' \ --url 'http://[::1]/' \ --url 'http://allowed.com@evil.example/' # => safe # => private-target # => parser-divergent ``` Den opløser værten, som netværket gør, så kodede former af en intern adresse ikke slipper forbi: hex, oktal, decimal uden punktummer, forkortet form, IPv6 og IPv4-mapped giver alle `private-target`. Og hvor en sjusket validator og den egentlige henter ville læse forskellige værter, er afgørelsen `parser-divergent`. ## Sådan læser du afgørelsen | Afgørelse | Betydning | | ------------------ | ------------------------------------------------------------------------------------------------------- | | `safe` | Målet forbinder til en offentlig vært, og en sjusket validator ville læse den samme vært. | | `private-target` | Værten opløses til en privat adresse, loopback, link-local, uspecificeret adresse eller cloud-metadata. | | `parser-divergent` | En sjusket tekstvalidator ville læse en anden reel vært end den, henteren forbinder til. | | `invalid url` | Strengen kan ikke parses som en URL, så der er intet at hente. | Kun `safe` er en tilladelse. Behandl `private-target`, `parser-divergent` og `invalid url` alle som en blokering. ### CLI-indstillinger | Indstilling | Værdi | Beskrivelse | | ----------- | ----------------- | ---------------------------------------------------------------- | | `--url` | en URL eller vært | Tjek ét mål. Gentag for at tjekke flere, én afgørelse pr. linje. | Mindst én `--url` er påkrævet. Målet er aldrig et bart positionelt argument, så det kan ikke forveksles med et flag. **Hvorfor en værdi til et flag** Hvert mål angives som værdi til et flag og indsættes aldrig i selve kommandoen. En værdi med anførselstegn eller backticks forbliver uskadelig og kan ikke injicere noget i shellen. Sæt den altid i enkelte anførselstegn, så din shell ikke ekspanderer den først. **Hvad den ikke dækker** Hooken er ren og opløser aldrig DNS, så to huller under kørslen ligger uden for omfanget: **DNS rebinding** (et navn, der opløses offentligt, når det tjekkes, og internt, når det hentes) og **kæder af omdirigeringer** (et første hop, der godkendes, og derefter omdirigerer indad). Luk dem ved at opløse én gang og forbinde til den validerede adresse og ved at afvise omdirigeringer. Den låser de reserverede loopback-navne (`localhost` og familien `.localhost`) fast som interne uden opslag, men ethvert andet DNS-navn giver `safe`, fordi det ville kræve opløsning at påstå, at det peger indad: tilladelseslisten beskytter dem, og det er den, dette tjek validerer. **Tip** Det er det samme tjek, som [specialiseringen `network`](https://lagune.ai/da-DK/docs/catalog) kører for at påvise, at et filter for mål holder. ## Ofte stillede spørgsmål ### Hvordan tester jeg en URL for SSRF? Kør hooken network. Den vurderer et hentemål og returnerer safe, private-target, parser-divergent eller invalid url. Kun safe er en tilladelse. ### Hvad er en parser-divergent URL? En URL, som forskellige parsere læser forskelligt, hvilket er en klassisk måde at omgå SSRF-beskyttelse på. Hooken network markerer den i stedet for at tillade den. --- # Hook regex: find ReDoS-mønstre > Gennemsøg en kodebase for regex, der er sårbare over for ReDoS, eller vurdér et enkelt mønster, fra kommandolinjen. Kanonisk URL: https://lagune.ai/da-DK/docs/hooks/regex Sprog: da-DK Original: https://lagune.ai/docs/hooks/regex Sidst opdateret: 2026-11-09 Hooken `regex` er den deterministiske motor til regex-sikkerhed, som [specialiseringen `regex`](https://lagune.ai/da-DK/docs/catalog) kører, og du kan selv køre den. Den virker i to tilstande fra én kommando: en **scanning**, der gennemsøger en kodebase for mønstre, der er sårbare over for **ReDoS** eller bygges under kørslen, og et **tjek**, der vurderer et enkelt mønster, du giver den. ## Scan en kodebase Uden flag scanner den hele projektet. `--dir` afgrænser scanningen til en mappe, `--file` til en enkelt fil. Begge kan gentages og kombineres i én rapport, hvor hver fil kun står én gang, selv når mere end ét mål dækker den. **Hele projektet** ```bash npx lagune read regex ``` **En mappe** ```bash npx lagune read regex --dir src/services ``` **En enkelt fil** ```bash npx lagune read regex --file bin/import.pl ``` **Flere mål** ```bash npx lagune read regex --dir core --dir workers --file Sources/App/Router.swift ``` **Med en grænse** `--limit` sætter tærsklen for ReDoS i gennemsøgningen (standard 25), den samme grænse, som tilstanden check tager. En lavere grænse er strengere. ```bash npx lagune read regex --dir src/services --limit 15 ``` Outputtet er rå tekst, hvis overskrifter fortæller, hvordan hvert afsnit skal læses. Et afsnit vises kun, når det har fund. ```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 ``` Når intet bliver fundet, udskriver den en enkelt linje. ```bash npx lagune read regex --dir src/clean # => no unsafe patterns found ``` ### Sådan læser du afsnittene | Afsnit | Betydning | | ------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Vulnerable regular expressions found` | Mønstre, der er sårbare over for ReDoS, grupperet efter fil med hvert mønster indrykket nedenunder, efterfulgt i parentes af, hvorfor det er usikkert, og, når de findes, dets omfang og dets flag. Hver linje er usikker, så afgørelsen gentages ikke. | | `Regular expressions the analysis could not settle (review manually)` | Mønstre, som analysen ikke kunne afgøre inden for sin arbejdsgrænse, oplistet på samme måde. | | `Dynamically built regular expressions (review manually by simulating a constructed regex)` | Filer, der bygger et regex ud fra en variabel, en sammenkædning eller en interpolation. | | `Static regex wrapped in a constructor (use a literal instead)` | Filer, der giver en almindelig strengliteral til en regex-konstruktør, hvor en regex-literal er enklere og sparer en kompilering under kørslen. | Det første afsnit er et sikkerhedsfund. Det andet og tredje er ikke fund i sig selv: de peger på kode, som et statisk tjek ikke kan afgøre, så de kræver, at et menneske læser den. Det fjerde er et hint om klarhed, ikke et sikkerhedsfund. ### CLI-indstillinger | Indstilling | Værdi | Beskrivelse | | ----------- | ----------------------- | --------------------------------------------------------------------------------------------------------- | | `--pattern` | en regex-kilde | Tjek ét mønster. Gentag for at tjekke flere, én afgørelse pr. mønster, i rækkefølge. | | `--flags` | regex-flag | Tjek hvert `--pattern` med disse flag, såsom `im`. Gælder kun tilstanden check. | | `--dir` | en mappe | Afgræns en scanning til en mappe. Kan gentages og kombineres med `--file`. | | `--file` | en fil | Afgræns en scanning til en enkelt fil. Kan gentages og kombineres med `--dir`. | | `--limit` | et ikke-negativt heltal | Sæt grænsen for gentagelser i ReDoS (standard 25). Gælder begge tilstande. En lavere grænse er strengere. | Uden indstillinger scanner den hele projektet. `--pattern` er tilstanden check og kan ikke kombineres med `--dir` eller `--file`. ### Vælg, hvad den scanner Den udelader det, **Git** ignorerer. For at udelade mere, eller for at scanne det, **Git** ignorerer, så giv `regex` sine egne indstillinger: ```bash npx lagune write add --ignore test/fixtures --checker regex ``` ```json { "checkers": { "regex": { "gitignore": false, "ignore": ["test/fixtures"] } } } ``` [Konfigurér hooks](https://lagune.ai/da-DK/docs/hooks/configure) beskriver alle indstillinger. ### Understøttede sprog Scanningen læser disse sprog, bestemt ud fra filendelsen, hvert efter dets egne regler, så et mønster fra ét sprog aldrig testes mod et andet. Alt andet springes over i stedet for at blive scannet med de forkerte regler. | # | Sprog | Filendelser | | --- | --------------------------- | ------------------------------------------------------------------------------------------------------------ | | 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` | **Efter bedste evne, ikke udtømmende** Den læser kildekoden som tekst, så den kan ikke vurdere et mønster, der sættes sammen under kørslen, og et mønster, der er spredt over flere linjer, skjult bag et alias eller skrevet i en form, den ikke genkender, kan slippe forbi. Betragt afsnittene som et solidt udgangspunkt, ikke en komplet oversigt, og bliv ved med at læse koden for det, de ikke kan nå. ## Tjek et enkelt mønster Angiv `--pattern` med mønsterets kilde for at vurdere det. Hooken udskriver ét ord: `safe`, `unsafe`, `undetermined`, når analysen når sin arbejdsgrænse, før mønsteret er afgjort, eller `invalid regex`. Gentag `--pattern` for at vurdere flere på én gang, én afgørelse pr. mønster, i rækkefølge. **Ét mønster** ```bash npx lagune read regex --pattern '(a+)+$' # => unsafe npx lagune read regex --pattern '^[a-z0-9_]{3,20}$' # => safe ``` **Flere mønstre** ```bash npx lagune read regex --pattern '(a+)+$' --pattern '^[a-z]+$' # => unsafe # => safe ``` **Med flag** `--flags` tjekker hvert `--pattern` i kaldet med de flag, det kører med, da et flag ændrer, hvilke tegn et mønster matcher. ```bash npx lagune read regex --pattern '^(?:a|A)+$' # => safe npx lagune read regex --pattern '^(?:a|A)+$' --flags 'i' # => unsafe ``` **Med en grænse** `--limit` sætter grænsen for gentagelser (standard 25) og gælder for hvert `--pattern` i kaldet. En lavere grænse er strengere. ```bash npx lagune read regex --pattern 'a?a?a?' --limit 2 # => unsafe ``` **Hvorfor et argument i anførselstegn** Hvert mønster angives som værdi til et flag og indsættes aldrig i selve kommandoen. En værdi med anførselstegn eller backticks forbliver uskadelig og kan ikke injicere noget i shellen. Sæt altid mønsteret i enkelte anførselstegn, så din shell ikke ekspanderer det først. **Tip** Det er den samme motor, som [specialiseringen `regex`](https://lagune.ai/da-DK/docs/catalog) kører: scanningen indleder en gennemgang for ReDoS, og tjekket bekræfter et mønster, den bringer frem. ## Ofte stillede spørgsmål ### Hvordan tjekker jeg et regex for ReDoS fra CLI'en? Kør npx lagune read regex --pattern ''. Den returnerer safe, unsafe, undetermined eller invalid regex. ### Hvordan scanner jeg et helt projekt for usikre regex? Kør hooken regex i tilstanden scan over kodebasen. Den rapporterer mønstre, der er sårbare over for ReDoS, på tværs af 25 understøttede sprog. --- # Hook secrets: find hardcodede secrets > Gennemsøg en kodebase for hardcodede loginoplysninger fra kommandolinjen. Kanonisk URL: https://lagune.ai/da-DK/docs/hooks/secrets Sprog: da-DK Original: https://lagune.ai/docs/hooks/secrets Sidst opdateret: 2026-11-09 Hooken `secrets` markerer **loginoplysninger, der er kompileret ind i kildekoden** i stedet for at blive læst fra miljøet. Den tager udgangspunkt i **oprindelsen** (en literal frem for et opslag i miljøet), ikke i værdiens indhold, så den behøver intet udtømmende katalog over udbyderpræfikser og giver næsten ingen falske positiver. Den er den deterministiske motor bag [specialiseringen `secrets`](https://lagune.ai/da-DK/docs/catalog). Signaturer i udbydernes formater, loginoplysninger i forbindelsesstrenge og en literal, der er bundet til en identifikator med et secret-navn, er **sprogneutrale**: den samme streng læses ens i enhver fil. De to heuristikker, der afhænger af syntaksen, et opslag i miljøet med en hardcodet standardværdi og en secret, der flyder ind i en log-sink, er **sprogbevidste**, så et JavaScript-`console.log` aldrig læses i en Rust-fil, og Pythons `os.getenv("X", "default")` ses for sig selv. ## Kørsel ```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 ``` Scanningen udskriver op til to afsnit. **Hardcoded secrets found** er sættet af fund (en hardcodet standardværdi for en miljøvariabel med et secret-navn, en loginoplysning indlejret i en forbindelsesstreng eller en værdi, der matcher et udvalgt udbyderformat), så hooken afslutter med en kode forskellig fra nul. **Secret handling to review manually** er et sæt spor: en almindelig literal bundet til en identifikator med et secret-navn (dens oprindelse kan afgøres, men ikke om værdien er en rigtig secret) og en værdi med et secret-navn, der flyder ind i en log- eller svar-sink. En ren kørsel udskriver `no hardcoded secrets found`. ### CLI-indstillinger | Indstilling | Værdi | Beskrivelse | | ----------- | -------- | ------------------------------------------------------------------------------ | | `--dir` | en mappe | Afgræns en scanning til en mappe. Kan gentages og kombineres med `--file`. | | `--file` | en fil | Afgræns en scanning til en enkelt fil. Kan gentages og kombineres med `--dir`. | Uden indstillinger scanner den hele projektet. ### Vælg, hvad den scanner Den udelader det, **Git** ignorerer. For at udelade mere, eller for at scanne det, **Git** ignorerer, så giv `secrets` sine egne indstillinger: ```bash npx lagune write add --ignore test/fixtures --checker secrets ``` ```json { "checkers": { "secrets": { "gitignore": false, "ignore": ["test/fixtures"] } } } ``` [Konfigurér hooks](https://lagune.ai/da-DK/docs/hooks/configure) beskriver alle indstillinger. ### Sprogdækning Fundet med en standardværdi i miljøet og sporet med en log-sink læser et sæt former pr. sprog, så de dækker sprogene nedenfor og er tavse andre steder. De tre andre signaler kører på **hver** fil. | Signal | Sprog | | ----------------------- | ------------------------------------------------------------------------------- | | Standardværdi i miljøet | JavaScript/TypeScript, Python, Ruby, PHP, Kotlin, Java, Go (`cmp.Or`), Rust, C# | | Log- eller svar-sink | JavaScript/TypeScript, Python, Ruby, PHP, Java, Kotlin, Go, Rust, C, C++, C# | **Er det et problem i forhold til politikker?** Nej. At genkende en secrets format for at advare om, at den er blevet committet, er almindeligt defensivt værktøj, den samme operation som gitleaks, trufflehog og push protection i GitHub udfører. Hooken leverer signaturer til detektion (offentlige **formater** for tokens), aldrig en aktiv secret, og den gennemgår og forklarer i stedet for at eksfiltrere. ## Ofte stillede spørgsmål ### Hvordan undgår hooken secrets falske positiver? Den tager udgangspunkt i oprindelsen, ikke i værdiens indhold. Formater med høj sikkerhed (udbydertokens, standardværdier i miljøet, forbindelsesstrenge) er fund, der afslutter med en kode forskellig fra nul. En almindelig literal bundet til en identifikator med et secret-navn er et spor, der skal bekræftes, og den samme identifikator læst fra process.env bliver slet ikke markeret. --- # Eksempler på prompts til Lagune: automatisér Blue Team-workflowet > Prompts til Lagune, klar til at kopiere: en scanning med kun læseadgang, hele Blue Team-workflowet og en Zero Trust-gennemgang samt detektion afgrænset til et commit, diffen for en branch eller PR eller en reel hændelse. Kanonisk URL: https://lagune.ai/da-DK/docs/examples/prompts Sprog: da-DK Original: https://lagune.ai/docs/examples/prompts Sidst opdateret: 2026-11-09 Prompts til Lagune, klar til at kopiere, som du kan indsætte direkte i din AI-agent. ## 💧 Overfladisk scanning En gennemsøgning med kun læseadgang, der læser koden på egen hånd og rapporterer hver fejl med en rettelse, uden at køre Blue Team-workflowet eller skrive til sporingen i Lagune. **Tip** Virker bedre i planlægningstilstand og med sikkerhedsprincipper (`/lagune-charter`) defineret. **🪼 Standard** | Aspekt | Afvejning | Niveau | | ---------------- | --------------------------------------------------------------- | ------------------- | | **Indsats** | Én agent scanner og rapporterer, uden subagenter. | 1/5 | | **Tid** | Hurtig. Et enkelt gennemløb med kun læseadgang, intet anvendes. | 2/5 | | **Tokenforbrug** | Moderat, delt. Hele scanningen kører i én kontekst. | 2/5 | ```md /lagune Du er en cybersikkerhedsforsker med dyb ekspertise i defensiv sikkerhed, og du bruger Lagune til at forbedre din viden og præcision. Scan arbejdsområdet på egen hånd, og par hver fejl, du finder, med en konkret rettelse. Dette er en selvstændig gennemsøgning, ikke Blue Team-workflowet: kør ikke detect, plan, harden eller verify, og skriv intet til sporingen i Lagune. Til sidst skal du liste hver fejl, du har fundet, hver med sin alvorlighed og en konkret rettelse. ``` **🐬 Flere agenter** | Aspekt | Afvejning | Niveau | | ---------------- | ------------------------------------------------------------------------------ | ------------------- | | **Indsats** | Én subagent pr. fil, skaleret efter størrelsen på din kodebase. | 2/5 | | **Tid** | Parallelt pr. fil, derefter flettet til én rapport. Stadig kun med læseadgang. | 3/5 | | **Tokenforbrug** | Højere, men isoleret. Hver subagent scanner i sin egen kontekst. | 3/5 | ````md /lagune Du er en cybersikkerhedsorkestrator, der bruger Lagune til at opregne, sende en subagent af sted pr. sti og flette deres rapporter (alt indhold læses af subagenterne). Du skal uddelegere opgaven til subagenter ud fra det aktuelle projekts størrelse: jo større kodebasen er, desto flere subagenter skal sendes af sted, alle parallelt, og hver skal have prompten nedenfor: ```prompt /lagune Du er en cybersikkerhedsforsker med dyb ekspertise i defensiv sikkerhed, og du bruger Lagune til at forbedre din viden og præcision. Scan på egen hånd, og par hver fejl, du finder, med en konkret rettelse. Dette er en selvstændig gennemsøgning, ikke Blue Team-workflowet: kør ikke detect, plan, harden eller verify, og skriv intet til sporingen i Lagune. Til sidst skal du liste hver fejl i , hver med sin alvorlighed og en konkret rettelse. ``` Til sidst skal du flette alle subagenternes rapporter til én prioriteret liste over fejl og rettelser. ```` **Advarsel** En hurtig scanning er én bred, uafgrænset prompt, så nogle agenter er mere tilbøjelige til at afvise den eller afbryde den før tid. Hvis din agent stritter imod, så kør i stedet hele **Blue Team-workflowet** nedenfor: dets afgrænsede faser, trin for trin, bliver langt sjældnere blokeret. --- ## 🌊 Automatisk Blue Team-gennemgang Kører [hele kommandoforløbet](https://lagune.ai/da-DK/docs/get-started/commands) fra start til slut. **🪼 Standard** | Aspekt | Afvejning | Niveau | | ---------------- | --------------------------------------------------------------------------------------------------- | ------------------- | | **Indsats** | Én agent, ingen subagenter, uanset kodebasens størrelse. | 3/5 | | **Tid** | Middel, men mindre grundig i store kodebaser. Hver kommando kører én gang, den ene efter den anden. | 4/5 | | **Tokenforbrug** | Lavere, men mindre isoleret. Alle kommandoer deler den samme kontekst. | 4/5 | ```md Udfør følgende kommandoer, én ad gangen: `/lagune-charter`, `/lagune-detect`, `/lagune-plan`, `/lagune-harden` og `/lagune-verify`. ## Løkke Når `/lagune-verify` afviser en eller flere rettelser, så gentag `/lagune-harden` og derefter `/lagune-verify`, indtil alle fund er løst korrekt. ``` **🐋 Flere agenter (dyb scanning)** | Aspekt | Afvejning | Niveau | | ---------------- | ------------------------------------------------------------------------------------------------------------- | ------------------- | | **Indsats** | Antallet af subagenter skaleres efter størrelsen på din kodebase. | 5/5 | | **Tid** | Længere, men mere grundig. Sender flere subagenter af sted, der opdager, planlægger og hærder fund parallelt. | 5/5 | | **Tokenforbrug** | Højere, men sikrere. Hver subagent har sin egen isolerede kontekst uden forudindtagethed. | 5/5 | ````md Udfør hver af følgende kommandoer med sin egen subagent, én ad gangen (uden backticks, kun kommandoen): Prompt til subagent 1: `/lagune-charter` Prompt til subagent 2: `/lagune-detect` Prompt til subagent 3: `/lagune-plan` Prompt til subagent 4: `/lagune-harden` Prompt til subagent 5: `/lagune-verify` I kommandoerne `/lagune-detect`, `/lagune-plan`, `/lagune-harden` og `/lagune-verify` skal du uddelegere opgaven til subagenter ud fra det aktuelle projekts størrelse: jo større kodebasen er, desto flere subagenter skal sendes af sted. For eksempel: ```prompt /lagune-detect ``` ```prompt /lagune-plan ``` ```prompt /lagune-harden ``` ```prompt /lagune-verify ``` - Flere agenter på samme kommando skal sendes af sted parallelt. - Når alle subagenter til `/lagune-detect` er færdige, så udfør: ```prompt /lagune-detect flet ensbetydende fund. Opdag ikke nye fund, og scan ikke kodebasen igen. ``` ## Løkke Når `/lagune-verify` afviser en eller flere rettelser, så gentag `/lagune-harden` og derefter `/lagune-verify`, indtil alle fund er løst korrekt. ```` --- ## 🪄 Afgrænset detektion Ret [`/lagune-detect`](https://lagune.ai/da-DK/docs/commands/detect) mod en del af dit projekt i stedet for det hele. Beskriv omfanget med almindelige ord (et commit, en pull request eller en reel situation), så kortlægger den kun de sikkerhedsrelevante fund dér. **Tip** Alt, hvad den opdager her, er almindelige fund, så du kan føre dem direkte videre til `/lagune-plan`, `/lagune-harden` og `/lagune-verify`, afgrænset til netop de punkter. **📌 Siden et commit** Giv en ny omgang commits sin egen sikkerhedsgennemgang, afgrænset til netop det, de ændrede, for eksempel: ```prompt /lagune-detect Afgræns detektionen til alt, der er ændret siden commit `a1b2c3d`. ``` **🔀 Diff for branch eller PR** Gennemgå sikkerheden i en pull request, før den bliver merget, afgrænset til netop dens diff, for eksempel: ```prompt /lagune-detect Afgræns detektionen til de ændringer, denne branch introducerer i forhold til `main`. ``` **⛑️ Efter en hændelse** Beskriv med dine egne ord, hvad der skete. Lagune læser situationen, ikke et flag, og gør den til en fokuseret jagt, for eksempel: ```prompt /lagune-detect Vores websted havde et datalæk for et par uger siden. Jeg ved ikke præcis, hvordan det skete, og jeg er bekymret for, at der stadig er noget åbent, der kan lække data igen. Gå koden grundigt igennem, fokusér på alle steder, hvor følsomme data læses, gemmes eller eksponeres, og kortlæg alt, der stadig kan være en vej ud. Behandl det som en reel hændelse, ikke en øvelse. ``` --- ## 🚨 Zero Trust-gennemgang Behandler hele arbejdsområdet og hver afhængighed som fjendtlig: den jager interpretere, netværkskald, kodede payloads og kode, der er gemt på usandsynlige steder for at slippe forbi scannere, og slutter med en afgørelse om, hvorvidt projektet er sikkert at bruge eller ej. Prompterne indlæser de specialiseringer, denne gennemgang bygger på, direkte, uanset dit projekts kategorier. For resten af det katalog, som `/lagune` matcher, skal du sørge for, at projektet bruger **OWASP**, **AI/LLM** og kategorien for dets stak (f.eks. **JavaScript**, **Python** osv.): ```bash npx lagune write add --categories owasp ai javascript ``` Repositoriets egne `.gitignore`-filer og konfigurationer kan skjule filer for tjekkene, så indstil blokken `checkers` i `.lagune/configs.json` til at [scanne alt](https://lagune.ai/da-DK/docs/hooks/configure), og erstat enhver blok, som repositoriet leverer: ```json { "checkers": { "gitignore": false } } ``` **Fare** Vær forsigtig, når du kører projekter fra kilder, du ikke stoler på, i dit lokale miljø. Brug et isoleret miljø, såsom en **sandbox** (anbefales), en **VM** eller lignende, så ondsindet kode ikke kan påvirke dit system. **🪼 Standard** | Aspekt | Afvejning | Niveau | | ---------------- | -------------------------------------------------------------------------------------------- | ------------------- | | **Indsats** | Én agent gennemsøger hele arbejdsområdet, uden subagenter. | 2/5 | | **Tid** | Middel. Én agent arbejder sig gennem koden og dens afhængigheder i rækkefølge. | 3/5 | | **Tokenforbrug** | Moderat, men delt. Specialiseringerne, koden og afhængighederne indlæses alle i én kontekst. | 3/5 | ```md /lagune Du er en cybersikkerhedsforsker med dyb ekspertise i defensiv Zero Trust-sikkerhed, og du bruger Lagune til at forbedre din viden og præcision. Kortlæg hele arbejdsområdet som en kilde, der ikke er til at stole på, og et potentielt ondsindet område. Hver interpreter, fetch, base64 og lignende skal behandles som en potentiel trussel. Udvid din analyse til afhængighederne og deres afhængigheder: et projekt kan forsøge at skjule ondsindet kode et usandsynligt sted for at slippe forbi scannere. Obligatoriske specialiseringer (indlæs dem én ad gangen med `npx lagune read catalog `): - interpreter - secrets - llm - path For at være helt klar: hver kortlagt sårbarhed skal behandles som en potentiel trussel, uden undtagelse. Til sidst skal du give en afgørelse om, hvorvidt projektet er sikkert og troværdigt for mig at bruge eller ej. ``` **🐋 Flere agenter (dyb scanning)** | Aspekt | Afvejning | Niveau | | ---------------- | ---------------------------------------------------------------------------------------------- | ------------------- | | **Indsats** | Én subagent pr. fil, skaleret efter størrelsen på din kodebase. | 5/5 | | **Tid** | Længere, men mere grundig. Filerne gennemsøges parallelt og flettes derefter til én afgørelse. | 4/5 | | **Tokenforbrug** | Højest, men sikrest. Hver subagent læser specialiseringerne i sin egen isolerede kontekst. | 5/5 | ````md /lagune Du er en cybersikkerhedsorkestrator, der bruger Lagune til at opregne, sende en subagent af sted pr. fil og generere rapporter (alt indhold læses af subagenterne). Send én subagent af sted pr. fil, alle parallelt, og giv hver prompten nedenfor, afgrænset til dens fil: ```prompt /lagune Du er en cybersikkerhedsforsker med dyb ekspertise i defensiv Zero Trust-sikkerhed, og du bruger Lagune til at forbedre din viden og præcision. Behandl som en kilde, der ikke er til at stole på, og et potentielt ondsindet område. Hver interpreter, fetch, base64 og lignende skal behandles som en potentiel trussel. Udvid analysen til alt, hvad importerer, inklusive afhængigheder og deres afhængigheder, hvor ondsindet kode kan gemme sig for at slippe forbi scannere. Obligatoriske specialiseringer for hver subagent (indlæs dem én ad gangen med `npx lagune read catalog `): - interpreter - secrets - llm - path For at være helt klar: hver kortlagt sårbarhed skal behandles som en potentiel trussel, uden undtagelse. Til sidst skal du give en afgørelse om, hvorvidt projektet er sikkert og troværdigt for mig at bruge eller ej. ``` Til sidst skal du flette alle subagenternes rapporter til én endelig afgørelse. ```` --- # Security-Driven Hardening: en konvention for tiden med AI-assisteret udvikling > Metoden Security-Driven Hardening (SDH): en kontekstbevidst Blue Team-konvention til gennemgang og hærdning af software, der er udviklet med AI-assistance eller vibe coding. Kanonisk URL: https://lagune.ai/da-DK/docs/references/paper Sprog: da-DK Original: https://lagune.ai/docs/references/paper Sidst opdateret: 2026-11-09 - **Weslley Araújo** - **Metodeartikel, 2026.** --- ## Resumé Security-Driven Hardening (SDH) er en struktureret, AI-drevet og udelukkende defensiv sikkerhedsmetode til en tid, hvor software i stigende grad skrives af AI-agenter og af folk, der ikke er sikkerhedsspecialister. I stedet for at køre en generisk tjekliste finder SDH først ud af, hvad et system rent faktisk gør (login, filupload, betalinger, eksponering af data og så videre), og driver derefter det sikkerhedsarbejde, der er specifikt for den kontekst. Den styres af principper, der er sikre som standard, er udelukkende rettet mod forsvar og formuleres i almindelige ord, så enhver bruger kan handle på den. Denne artikel argumenterer for, at SDH er en manglende konvention, ikke et enkelt værktøj. Sikkerhedsviden ligger i metoden og dens specialiseringer efter behov, et grundlag, som enhver bruger kan bygge videre på, og det gør det muligt at betjene en nybegynder og en ekspert gennem det samme workflow. To egenskaber adskiller den fra tidligere spec-first-tilgange `[1]`. SDH er **uafhængig af tilstand**: den tilpasser sig en tom mappe, et projekt under udvikling, en enkelt pull request eller en stor legacy-kodebase, i enhver stak. Og SDH **kan afsluttes**: en risiko, der er verificeret lukket, bliver taget ud af hele workflowet, så fundet når en afklaret tilstand og først åbnes igen, når koden ændrer sig. SDH erstatter ikke sikkerhedsprofessionelle eller specialiserede Blue Team-værktøjer. Den udvider udviklerens egen viden, og jo mere en udvikler forstår af sikkerhed, desto mere kan vedkommende styre den. **Lagune** er referenceimplementeringen, og den beviser, at metoden kan bygges og flyttes. SDH tilbydes som en konvention, som andre kan tage i brug. > **Nøgleord** > > AI-assisteret udvikling, softwaresikkerhed, defensiv sikkerhed, spec-driven development, sikkerhedshærdning, agentdrevne workflows, afslutning, kontekstbevidst sikkerhed, viden efter behov, agentuafhængige værktøjer. --- ## I. Introduktion: det sikkerhedshul, som AI-assisteret udvikling åbnede Software bliver i stigende grad udgivet af mennesker, og af AI-agenter, der ikke pålideligt kan genkende et usikkert mønster: en lækket secret, et manglende autorisationstjek, en forespørgsel, der kan injiceres. Det er ikke eksotiske risici. De hører til de risikoklasser, der dominerer reelle hændelser, og som i årevis er dokumenteret i offentlige referencer `[6]`, `[7]`, og nyere undersøgelser viser, at en betydelig andel af AI-genereret kode bliver udgivet med netop sådanne fejl `[8]`. AI-kodeassistenter gjorde det akut ved at lade ikke-udviklere udgive rigtig software, men hullet er bredere end en enkelt målgruppe. De fleste projekter får aldrig en sikkerhedsgennemgang, der er specifik for det, de rent faktisk gør. Økosystemet bliver mere skrøbeligt for hver forhastet beslutning om, at "det virker, så udgiv det". Generiske sikkerhedsråd lukker ikke dette hul. En statisk tjekliste er ikke specifik for det, et system gør, så den oversvømmer et lille projekt med irrelevante punkter og overser stadig den risiko, der betyder noget for netop det projekt. Problemet er ikke mangel på sikkerhedsviden i verden. Problemet er at matche den rette viden med det system, brugeren faktisk står med, og at gøre det for en, der måske ikke ved, hvad vedkommende skal spørge om. SDH besvarer dette med en enkelt omvending: **sikkerhedsviden ligger i specen og dens specialiseringer efter behov, et grundlag, som enhver bruger kan bygge videre på**. Metoden finder konteksten, prioriterer de risici, den kontekst indebærer, og guider rettelserne, så en udvikler og en ikke-udvikler betjenes gennem det samme workflow. Fundene og anbefalingerne forbliver i almindelige ord, så de kan bruges uanset læserens tekniske niveau. Eksperten bliver ikke begrænset af det, men forstærket, en dualitet, vi udfolder i `§VI`. > **Kerneindsigt** > > **Den centrale omvending:** Sikkerhedsviden ligger i specen og dens specialiseringer efter behov, et grundlag, som enhver bruger kan bygge videre på. Metoden lærer, hvad systemet gør, matcher sikkerhedsarbejdet til det og udvider det, brugeren allerede ved. Forestil dig en udvikler, der fortæller en AI-assistent: "min app lader brugerne uploade et profilbillede." Uden en sikkerhedsgennemgang producerer assistenten fungerende kode, der i det stille stoler på alt, hvad klienten sender: den angivne filtype, filnavnet, størrelsen. Uploaden bliver udgivet, og en fil forklædt som et billede kan indeholde kode, et manipuleret navn kan bryde ud af lagringsstien, og en for stor fil kan opbruge serverens ressourcer. Intet af dette er synligt i en demo, så det bliver udgivet. Den samme kode, kørt gennem SDH, opfører sig anderledes. Den opdager, at systemet tager imod filer udefra (detektion), prioriterer det til de risici, en upload indebærer (triage), foreslår at tjekke den reelle filtype og størrelse, omdøbe ved lagring og gemme et sted, hvor kode ikke kan køre (afhjælpning), og læser derefter resultatet og bekræfter, at hver kontrol faktisk holder (verifikation). Udvikleren behøvede aldrig at kende udtrykket "unrestricted file upload". Metoden leverede det på vedkommendes vegne. Denne artikel bidrager med følgende: - En præcis definition af SDH som metode, uafhængig af en bestemt implementering, med dens designprincipper (`§III`). - En defensiv livscyklus i fem faser, hvor adskillelsen af ansvar i sig selv er bidraget: detektion opfinder aldrig, planlægning læser aldrig kode, kun én fase ændrer kode, og verifikation blødgør aldrig sin vurdering (`§IV`). - **Afslutning** som metodisk holdning: et enkelt fund har en sluttilstand, ikke en endeløs løkke (`§V`). - Dualiteten **udvidelse af udviklerens viden**: ét workflow, der beskytter nybegynderen og forstærker eksperten (`§VI`). - **Ikke-kaldbare specialiseringer og prompt efter behov**: fokuseret sikkerhedsviden, som agenten indlæser, når projektets kontekst kræver det, aldrig som standard (`§VII`). - **Uafhængighed af tilstand** og **ikke-autoritativ tilpasningsevne**: SDH passer til enhver udviklingstilstand og tilpasser sig scenariet i stedet for at påtvinge et fast omfang (`§VIII`). - En **forebyggende tilstand**: det samme forsvar, kørt mens almindeligt arbejde bygges, så koden lander sikker som standard, og faserne har mindre at rette (`§IX`). - En særskilt sammenligning med Spec-Driven Development, den slægt, SDH voksede ud af og derefter skilte sig fra (`§X`). - De tekniske discipliner, der lader metoden overleve refaktoreringer og forblive uafhængig af en bestemt agent: sporing med identitet ved navn (`§XI`) og en agentuafhængig bærer (`§XII`). --- ## II. Baggrund og relateret arbejde SDH bygger på tidligere arbejde. Den arver en gennemprøvet struktur fra spec-first, agentdrevet udvikling `[1]`, `[2]`, `[3]`: skabeloner, slash-kommandoer, som en agent bruger, et styrende dokument og en agent, der kører faserne. Den genimplementerer den struktur med et defensivt formål. Slægtskabet er bevidst, og et af SDH's arbejdsprincipper nævner det direkte: byg workflowet ud fra en gennemprøvet struktur, og indram det derefter til sikkerhed. SDH er ikke en statisk tjekliste med generiske anbefalinger. En tjekliste ved meget om sikkerhed generelt og intet om det projekt, den står over for. SDH vender den vægtning om. Den bruger sin første indsats på detektion, på at lære, hvad systemet gør, og griber først derefter efter den viden, som detektionen gør relevant. SDH er heller ikke en erstatning for sikkerhedsfolk eller for specialiserede Blue Team-værktøjer. Den udvider udviklerens viden (`§VI`). Et team med en dedikeret sikkerhedsfunktion bør beholde den. SDH giver det team en struktureret bærer, og den giver et team uden en sådan funktion et forsvarligt grundlag. SDH står også ved siden af deterministiske sikkerhedsscannere (statisk analyse, linters) `[4]`, `[5]`. De værktøjer er værdifulde, netop fordi de er deterministiske og gentagelige. SDH er for det meste ræsonneret af agenten, hvilket bytter streng determinisme for kontekstbevidsthed. Metoden lader ikke som om andet. Hvor determinisme betyder noget, indlejrer den en deterministisk motor i ræsonnementet (`§VII`): agenten afgør, om et input er værd at tjekke, og et deterministisk program afgør, om inputtet er farligt. Det mest direkte tidligere arbejde er Spec-Driven Development (SDD), familien af spec-first-metoder, der driver et byggeri frem ud fra en eksekverbar specifikation. Vi behandler SDD som en klasse. Den klareste beskrivelse af den som praktisk metode er Piskalas rapport `[1]`, og dens mest synlige agentdrevne værktøjskasse er Spec Kit fra GitHub `[2]`, med OpenSpec `[3]` som endnu et værktøj fra samme familie. De udgør de kanoniske referencer for sammenligningen i `§X`. --- ## III. SDH: definition og designprincipper **Security-Driven Hardening** er en struktureret, AI-drevet sikkerhedsmetode, der gør en kodebase mere sikker ved at drive arbejdet ud fra en spec, som agenten kører, i stedet for ud fra ad hoc-rettelser. Navnet er inspireret af **Blue Teams**, forsvarerne inden for sikkerhed. SDH handler om forsvar, hærdning og verifikation, aldrig angreb. > **Definition** > > **Security-Driven Hardening (SDH):** En struktureret, AI-drevet og udelukkende defensiv sikkerhedsmetode, der først finder ud af, hvad et system rent faktisk gør, og derefter driver det kontekstspecifikke sikkerhedsarbejde, styret af principper, der er sikre som standard, og formuleret i almindelige ord. SDH er defineret af et sæt bindende principper. Hvert af dem er en regel, og hvert af dem giver brugeren en bestemt garanti. | Princip | Reglen | Hvad det garanterer brugeren | | ----------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Sikker som standard, i almindelige ord, for alle lige | Hver standard, besked og rettelse er sikker fra starten og forståelig for enhver læser, udvikler eller ej. Ingen gruppe af brugere er privilegeret. | En nybegynder får et sikkert grundlag uden at bede om det og læser resultatet i sine egne termer. | | Kontekstbevidst frem for generisk | Hver fase starter fra den kontekst, der blev fundet i detect, og handler på det, systemet rent faktisk gør. | Anbefalingerne passer til projektet, ikke til en tjekliste. Sikkerhedsviden ligger i specen og dens specialiseringer efter behov og udvider det, brugeren selv bringer med. | | Fleksibel frem for stiv | Principper, krav og anbefalinger er udgangspunkter. Brugeren kan omformulere, fjerne, tilføje eller afgrænse hvad som helst. | Metoden bøjer sig efter projektet og brugeren og aldrig hårdere, end brugeren ønsker. Fleksibilitet svækker aldrig grundlaget, der er sikkert som standard. | | Afstem, aldrig kun tilføj | Artefakter er levende dokumenter, ikke logs. Hver kørsel tjekker hver post igen: behold det, der holder, omskriv det, der har ændret sig, og fjern det, der ikke længere gælder. | Registreringen afspejler altid nutiden, så den aldrig forfalder til en forældet backlog. | | Udelukkende forsvar | SDH gennemgår, hærder og verificerer. Den producerer aldrig offensive værktøjer, exploits til ondsindet brug eller omgåelse af detektion til skade. | Metoden kan ikke gøres til et våben. Indhold med dobbelt anvendelse optræder kun i en tydeligt defensiv indramning. | | Spec-first, agentdrevet, indrammet til sikkerhed | Workflowet bygges af skabeloner, kommandoer, styrende sikkerhedsprincipper og en agent, der kører faserne. | En gennemprøvet udviklingsstruktur, genbrugt, så agenten udfører det substantielle sikkerhedsarbejde. | **Tabel 1.** Designprincipperne i SDH og den garanti, hvert af dem giver brugeren. Disse principper er ikke pynt. De er de begrænsninger, hver fase nedenfor skal respektere, og diskussionen i `§XV` vender tilbage til dem for at markere metodens grænser. Resten af artiklen udfolder ni navngivne søjler. Det er de dele, en læser bør kunne holde i hovedet, og de dele, et andet team skal genimplementere for at kunne sige, at det laver SDH. | Søjle | Hvad den giver | Afsnit | | ------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------- | ----------- | | Den kontekstbevidste omvending | Sikkerhedsviden ligger i specen og dens specialiseringer efter behov, så en nybegynder og en ekspert deler ét workflow. | `§I`, `§VI` | | Den defensive livscyklus i fem faser | Adskillelse af ansvar: politik, detektion, triage, afhjælpning, verifikation, hver med én opgave. | `§IV` | | Afslutning | Et fund har en sluttilstand, ikke en endeløs løkke. Afsluttet arbejde bliver taget ud. | `§V` | | Dualiteten udvidelse af udviklerens viden | Ét workflow, der beskytter nybegynderen og forstærker eksperten uden at erstatte nogen af dem. | `§VI` | | Prompt efter behov, ikke-kaldbar viden | Relevant sikkerhedsviden indlæses til det, projektet er, aldrig som standard. | `§VII` | | Uafhængighed af tilstand og ikke-autoritativ tilpasningsevne | Passer til enhver udviklingstilstand i enhver stak og tilpasser sig scenariet i stedet for at påtvinge et omfang. | `§VIII` | | Den forebyggende tilstand | Det samme forsvar kører, mens nyt arbejde bygges, så koden lander sikker som standard. | `§IX` | | Sporing med identitet ved navn | Et fund forbliver ét punkt på tværs af faser, og en omdøbning bryder forbindelsen ét sted. | `§XI` | | Den agentuafhængige bærer | Sikkerhedsværdien skrives én gang og afhænger hverken af agent eller stak. | `§XII` | **Tabel 2.** De ni navngivne søjler i SDH, og hvor hver af dem udfoldes. --- ## IV. Blue Team-workflowet i 5 faser SDH strukturerer arbejdet som en defensiv livscyklus i fem faser (figur 1). Hver fase er rettet mod forsvar, hver bygger på den forrige, og faserne følger reel Blue Team-aktivitet: fastlæg en politik, opdag, prioritér, afhjælp, verificér. ```mermaid flowchart TB charter["1 · charter (politik)
læser: projektet og brugerens beskrivelse, hvis den findes
skriver: sikkerhedsprincipperne
hvert princip nævner den risiko, det forhindrer, i almindelige ord"] detect["2 · detect (detektion)
læser: brugerens kode
skriver: kortlægningen
at opdage, ikke at opfinde: registrér kun det, koden understøtter"] plan["3 · plan (triage)
læser: kortlægningen, aldrig koden
skriver: forsvarsplanen
hver rettelse peger på noget, detect faktisk kortlagde"] harden["4 · harden (afhjælpning)
læser: forsvarsplanen og den kode, den berører
skriver: koden og hærdningsloggen
den eneste fase, der ændrer kode, én rettelse ad gangen, den mindste ændring, der holder"] verify["5 · verify (verifikation)
læser: koden og hærdningsloggen
skriver: hver åben afgørelse i hærdningsloggen
koden holdt op mod loggen, statisk, aldrig blødgjort"] charter --> detect --> plan --> harden --> verify verify -.->|"afvist: genåbnet arbejde for harden,
anvendt igen ud fra den registrerede begrundelse"| harden verify -.->|"afslutning: tager det, den påviste lukket,
ud af hele kæden,
én linje i historikken"| detect ``` **Figur 1.** Workflowet i fem faser: hvad hver fase læser, hvad den skriver, og dens bærende invariant. Verify styrer begge veje tilbage: en afvist kontrol genåbner harden, og et fund, der er påvist lukket, bliver taget ud af kæden, med én linje i historikken. Adskillelsen af ansvar er bidraget. Fordi hver fase har én opgave, er en fejl begrænset til ét sted, og læseren kan stole på det, hvert artefakt påstår. > **Kerneindsigt** > > **Applied er ikke verificeret:** Harden registrerer, at en rettelse er gennemført. Verify verificerer det ved at holde koden op mod den registrering, og afgørelsen blødgøres aldrig for at passe til registreringen. En kontrol kan være til stede i koden og stadig lade risikoen være til at nå, og så er den ærlige afgørelse "risk not closed". ### charter (politik) Charter fastlægger projektets sikkerhedsprincipper, de regler, hver senere fase skal respektere. Det er det overordnede lag, en slags kompileringstjek for projektets sikkerhedsniveau. Hvert princip har et klart navn, en ufravigelig regel, der kan tjekkes op mod koden, og en linje `Why:`, der angiver den risiko, det forhindrer, ikke kun rettelsen. Charter læser altid selve projektet (dets manifester, struktur og afhængigheder), og en brugers beskrivelse er, når den gives, en retning, som læsningen derefter udvider ud over det, brugeren nævnte. Uden beskrivelse er projektet den eneste kilde. De to supplerer hinanden i stedet for at konkurrere, og charter registrerer den politik, projektet bør overholde, ikke tilstanden af dets kode. En ikke-udvikler bør kunne læse det og forstå både reglen og risikoen. ### detect (detektion) Detect læser koden og kortlægger det, systemet rent faktisk gør, som har sikkerhedsmæssig vægt. Den styrende instruks er "at opdage, ikke at opfinde": registrér kun det, koden understøtter, med det belæg, de senere faser har brug for. Detect er neutral. Den tvinger ikke sine fund til at passe til charter, fordi det at matche risici med reglerne i charter er opgaven for fasen plan. Hvert fund har tre dele: hvad det er (en beskrivelse i almindelige ord), hvorfor det betyder noget (risikoen, ikke kun faktum) og belægget (den funktion eller rute, hvor det findes). Belægget indeholder ingen filsti. Stien findes kun i sporingskortet (`§XI`), så teksten aldrig indeholder en sti, der kan blive forældet. ### plan (triage) Plan gør hvert fund til en rettelse, navngivet efter dens risikoklasse (med henvisning til de etablerede referencer, CWE og OWASP, hvor de giver grundlag for det) og knyttet til det princip i charter, som rettelsen opretholder. Prioriteten (Critical, High, Medium, Low) er ikke et frit valg: plan vurderer hvert fund med metoden CVSS v4.0 Base og Environmental, så niveauet er scoren i almindelige ord, begrundet med én linje i almindelige ord om eksponering og indsats, og to kørsler lander i samme rækkefølge. Vektoren er det præcise ankerpunkt for en ekspert, niveauet og dets begrundelse den samme vurdering, som alle kan følge. Plan arbejder kun ud fra kortlægningen og læser aldrig koden. Det er en bevidst begrænsning, ikke en mangel: den tvinger hver rettelse til at pege på noget, detect faktisk opdagede. Hvis et omfang aldrig er blevet kortlagt, stopper plan og sender brugeren tilbage til detect i stedet for at gætte. ### harden (afhjælpning) Harden er den eneste fase, der ændrer kode, så den går forsigtigt frem. Om en ændring kræver brugerens godkendelse, afgøres af agenten og den tilladelsestilstand, den kører i, så harden tilføjer ingen bekræftelse af sin egen. Den gennemfører én rettelse ad gangen, afhængigheder først og derefter den højeste prioritet, så hver ændring forbliver lille, til at gennemse og nem at fortryde. Den svækker aldrig en eksisterende kontrol for at få en ny rettelse til at passe, og den bryder aldrig et princip i charter. Hvis en rettelse ville komme i konflikt med et princip, stopper harden og bringer konflikten frem i stedet for at gennemføre den. Hver blok registreres som Applied, Partial eller Blocked. "Applied betyder ikke, at den er verificeret endnu", og det er netop det, den næste fase tager sig af. ### verify (verifikation) Verify verificerer hver gennemført kontrol ved at læse koden og holde den op mod det, harden registrerede. Verifikationen er netop den konfrontation, koden op mod loggen, og den er statisk: den bekræfter, at en kontrol findes og er korrekt i koden, ikke at kontrollen holder under et angreb mod et kørende system. Det tjek under kørsel, den slags, der udfører reelle eller simulerede angreb mod det kørende system, ligger bevidst uden for omfanget. Verify giver én af tre afgørelser: risk closed, risk not closed eller cannot tell from the code. Den producerer intet artefakt af sin egen: harden og verify deler hærdningsloggen, hvor harden ejer det, der blev gjort, og verify ejer afgørelsen og dens begrundelse, og ingen af dem skriver nogensinde i den andens felter. En afvist kontrol er genåbnet arbejde for harden, hvis næste kørsel lader afgørelsen gå forud for sin egen læsning af koden og gennemfører rettelsen igen mod netop det hul, begrundelsen nævner. Verify stoler mere på koden end på loggen, fordi en log kan påstå mere, end koden leverer. Den har kun læseadgang til brugerens kode, og den blødgør aldrig en afgørelse for at passe til loggen. En kontrol kan være til stede og stadig lade risikoen være til at nå ad en anden vej, og i så fald er den ærlige afgørelse "risk not closed". Hvis verify under læsningen bemærker et sikkerhedsproblem, som kortlægningen aldrig dækkede, opfinder den ikke en afgørelse for det, da detektion er opgaven for detect: den bringer problemet frem og sender brugeren tilbage til detect, så fundet kommer ind gennem det samme workflow i stedet for at gå udenom. > **Gennemgående eksempel: filupload.** Et enkelt fund viser rygraden fra start til slut. > > - **detect** finder det: systemet tager imod filer fra brugerne, og upload-handleren stoler på den MIME-type, klienten sender, uden at tjekke filens reelle type. _Hvorfor det betyder noget:_ en fil forklædt som et billede kan skjule ondsindet kode. > - **plan** beslutter rettelsen, prioritet **Critical**, og opretholder princippet "Alt input er ikke-betroet, indtil det er valideret": tjek filens reelle type og størrelse, omdøb den ved lagring, og gem uploads et sted, hvor de ikke kan køres som kode. > - **harden** gennemfører den, status **Applied**: handleren bestemmer nu den reelle type ud fra indholdet, håndhæver en størrelsesgrænse, afviser alt uventet, omdøber ved lagring og gemmer et sted, hvor kode ikke kan køre. > - **verify** læser handleren, holder den op mod loggen og giver afgørelsen **risk closed**: koden gør præcis det, loggen påstår. > > Det samme fundnavn går igen i kortlægningen, planen og hærdningsloggen, og verify handler på den log under det samme navn: en åben afgørelse skrives i fundets blok, og et fund, der er påvist lukket, bliver taget ud (`§V`). Det fælles navn er dets identitet (`§XI`). --- ## V. Afslutning: et fund har en sluttilstand De fleste sikkerhedsværktøjer efterlader brugeren med en backlog, der kun vokser. SDH indtager en anden holdning: **et fund kan afsluttes, så det har en sluttilstand i stedet for at leve i en endeløs backlog** (figur 2). Det følger direkte af princippet om afstemning. > **Definition** > > **Afslutning:** En risiko, der er verificeret lukket, bliver taget ud af hele workflowet, så fundet når en afklaret tilstand og først åbnes igen, når koden ændrer sig. Et fund har en sluttilstand, selvom selve sikkerhedsprogrammet forbliver løbende. Artefakter i SDH er levende dokumenter, ikke logs. Hver gang en fase kører igen, tjekker den hver eksisterende post op mod den aktuelle sandhed og gør én af tre ting: beholder det, der stadig holder, omskriver det, der har ændret sig, eller fjerner det, der ikke længere gælder. Et fund, som koden viser nu er løst, bliver simpelthen fjernet. Den aktive registrering afspejler nutiden, ikke fortiden. Afslutning er den samme afstemning, der når sin konklusion. Når verify verificerer, at en risiko er lukket, tager den fundet ud af hele workflowet, kortlægningen, planen, hærdningsloggen og sporingskortet. Det er derfor, verify er den ene fase, der skriver til de andre fasers artefakter: det er den fase, der lukker løkken. Når fundet forlader kæden, destilleres det til en kort post i en historik, der ligger uden for den aktive kæde og aldrig behandles igen. Det er grænsen mellem at forsvinde og at blive afsluttet: et fund, som afstemningen fjernede, fordi det holdt op med at være sandt, efterlader intet, mens et fund, der er påvist lukket, gør sig fortjent til sin linje i historikken. Et fund, der er taget ud, er derefter fraværende i alle aktive artefakter, og det fravær er forventet, ikke en brudt kæde. ```mermaid stateDiagram-v2 direction TB [*] --> OPEN: detect opdager OPEN --> Plan: plan Plan --> Harden: harden Harden --> Verify: verify Verify --> StoodDown: risk closed StoodDown --> SETTLED SETTLED --> OPEN: ændringer i koden genåbner et fund Plan: plan Harden: harden Verify: verify StoodDown: STOOD DOWN · én linje i historikken ``` **Figur 2.** Tilstandsmaskinen for afslutning. Et fund går fra OPEN → STOOD DOWN → SETTLED og genåbnes kun, når koden ændrer sig. Når alt inden for omfanget er taget ud, er cyklussen i hvile, og den tilstand har en konkret form: et artefakt, hvis sidste fund er lukket, fjernes helt, så en fuldt afsluttet kæde kun efterlader sikkerhedsprincipperne og historikken, politikken og beviset. Cyklussen åbnes først igen, når koden ændrer sig. Metoden giver hvert fund en bestemt afslutning, hvilket netop er det, en endeløs backlog ikke kan. --- ## VI. Dualiteten udvidelse af udviklerens viden SDH erstatter ikke mennesker, og den erstatter ikke specialiserede Blue Team-værktøjer. Den **udvider udviklerens egen viden**. Jo mere en udvikler forstår af sikkerhed, desto mere præcist kan vedkommende styre workflowet, og desto mere selvstændighed har vedkommende. En udvikler, der forstår lidt, får stadig et sikkert resultat, fordi den automatiske tilstand beskytter vedkommende. Omvendingen fra `§I`, at sikkerhedsviden ligger i specen, virker i begge retninger. For nybegynderen er den beskyttelse: vedkommende behøver ikke at vide, hvad der skal spørges om, fordi specen foreslår det. For eksperten er den forstærkning: den samme spec lader vedkommende rette workflowet præcist i stedet for at arbejde op mod en fast tjekliste. Hver fase bærer denne dualitet i sin egen funktion (figur 3). Kørt uden input handler den på hele omfanget på brugerens vegne. Med en retning indsnævrer den samme fase sig til netop det, brugeren rettede den mod. ```mermaid flowchart TB inversion["én omvending, to retninger:
sikkerhedsviden ligger i specen"] inversion --> auto["automatisk tilstand (intet input)
fasen foreslår og handler
på hele omfanget"] inversion --> directed["styret tilstand (input givet)
fasen indsnævrer sig til netop
det, brugeren rettede den mod"] auto --> novice["nybegynderen, beskyttet:
et sikkert resultat uden
at vide, hvad man skal spørge om"] directed --> expert["eksperten, forstærket:
workflowet rettet præcist,
ikke en fast tjekliste"] novice -.-> phases["de samme fem faser tjener begge:
charter · detect · plan · harden · verify"] expert -.-> phases ``` **Figur 3.** Dualiteten udvidelse af udviklerens viden. Én omvending tjener to målgrupper: den automatiske tilstand beskytter nybegynderen, og den styrede tilstand forstærker eksperten, gennem de samme fem faser. Specialiseringerne efter behov (`§VII`) gør dualiteten udtrykkelig i deres egen tekst. Hver af dem fortæller agenten, at dens viden "udvider din dømmekraft", og at den skal fortsætte med at ræsonnere ud over det, specialiseringen giver. Viden er et gulv, ikke et loft. Det er det, der tjener begge målgrupper i den balance, artiklen tilstræber: udviklerfællesskabet får et substantielt instrument, og Blue Team-udøveren får en struktureret bærer, der ikke lader som om, den gør vedkommendes arbejde. --- ## VII. Ikke-kaldbare specialiseringer og prompt efter behov Dette er metodens mest nyskabende mønster. SDH bærer fokuseret sikkerhedsviden som specialiseringer, der **kun indlæses efter behov**, og agenten afgør selv, hvilke der skal indlæses, ved at matche projektets kontekst. Vi kalder det **prompt efter behov**: en måde, hvorpå agenten vælger, hvilken viden der skal aktiveres, ud fra omfanget af det projekt, den befinder sig i, i stedet for at køre alle tjek som standard. Specialiseringerne udvikler sig, og enhver af dem kan til enhver tid ændres eller erstattes. Bidraget er mønsteret, ikke specialiseringerne selv. > **Definition** > > **Prompt efter behov:** Agenten vælger, hvilken sikkerhedsviden der skal aktiveres, ved at matche den med omfanget af det projekt, den står over for, så den relevante viden hentes ind til det, projektet rent faktisk er, i stedet for at alle tjek kører som standard. > **Definition** > > **Ikke-kaldbar specialisering:** En fokuseret, sprogneutral enhed af sikkerhedsviden til én kontekst, såsom filupload eller kode, der kører i browseren. Den gennemgår og forklarer, omskriver aldrig kode og producerer aldrig et angrebsinput. Den er ikke en kommando: den indlæses, når den kontekst, den dækker, er inden for omfanget, eller når en prompt beder om den ved navn. Hver specialisering nævner de sikrere former for de risici, den dækker, og fortæller agenten, hvordan den skal handle på et fund i hver fase, der bruger den: hvordan det vurderes ved detektion, hvordan rettelsen gennemføres sikkert ved afhjælpning, og hvordan den påvises ved verifikation. Det afgørende træk er, at en specialisering **ikke kan kaldes alene**: den er ikke en kommando, og inde i workflowet er det et match, der indlæser den. Detektionsfasen oplister kataloget én gang, matcher projektets kontekst med det, hver post dækker, og indlæser kun de specialiseringer, hvis kontekst er til stede inden for omfanget. De senere faser genbruger den matchede liste i stedet for at oplise igen, så ét match tjener hele kæden, og den forebyggende tilstand (`§IX`) kører det samme match mod det arbejde, der er ved at blive bygget. En specialisering, hvis kontekst mangler, springes over, og overspringet er lige så ansvarligt som indlæsningen: hver post i kataloget får en udtrykkelig afgørelse, anvendt eller sprunget over med begrundelsen aflæst i koden, så en vag fornemmelse af irrelevans aldrig træder i stedet for fravær. At ingen er relevante, er et gyldigt resultat. Kataloget er data, og vækst er én vidensfil plus én række i kataloget, aldrig en ny kommando. De indbyggede specialiseringer er grupperet i kategorier, såsom OWASP, et sprog eller AI-integrationer, og det katalog, et projekt bruger, indeholder de indbyggede i de kategorier, det har valgt, plus dets egne specialiseringer. Projektet registrerer det valg sammen med resten af sin tilstand, så et helt team matcher mod det samme katalog. Det er det samme kontekstbevidste princip som i faserne, anvendt på viden: den relevante viden hentes ind til det, projektet rent faktisk er, i stedet for at alle tjek kører som standard. Den samme egenskab lader brugeren, ikke kun vedligeholderen, udvide kataloget: en sikkerhedskilde eller et emne, som brugeren leverer, destilleres til en ny specialisering, der tilhører projektet, kommer med i dets katalog uanset kategorierne og indlæses præcis som en indbygget, og den erstatter den indbyggede med samme navn. At skrive en specialisering er i sig selv udelukkende defensivt og følger den samme grænse, som specialiseringerne håndhæver: en beskrivelse af et angreb kan være kilden, men den specialisering, den giver, gennemgår og forklarer og udsender aldrig et fungerende exploit. Så omvendingen fra `§I`, at intelligensen ligger i specen, gælder også selve kataloget, som brugeren kan uddybe til sin egen kontekst uden at skrive kode. Et kort eksempel illustrerer prompt efter behov. Detect læser en mappe med kode, der kører i browseren. Den matcher den kontekst i kataloget, indlæser den specialisering, der dækker den, og bringer et fund på klientsiden frem gennem de normale trin i detect. De specialiseringer, hvis kontekst mangler i dette omfang, matcher ikke, så de indlæses aldrig, og hver af dem registreres som sprunget over. Det var projektet, der afgjorde, hvilken viden der var relevant, ikke en fast konfiguration. Determinisme optræder netop dér, hvor den betyder noget. En specialisering kan have et deterministisk tjek med, ikke kun tekst: hvor en risikoklasse har en skarp beslutningsprocedure, returnerer et lille program en fast afgørelse for et givet input, for eksempel et kort sæt ord som `safe`, `unsafe` eller `invalid input`. Nogle risikoklasser kan afgøres deterministisk på netop den måde, med et stykke tidligere arbejde bag beslutningsproceduren `[9]`, `[10]`, `[11]`. Tjekket vurderer enten kandidater, som agenten leverer, eller scanner omfanget for selv at finde dem, og i begge tilfælde er det tjekket, ikke agenten, der returnerer afgørelsen. En specialisering, der er universel nok, kan markeres som påkrævet i kataloget og anvendes så altid, med sit tjek kørt over hele omfanget. Det er det ene tilfælde, hvor viden indlæses uden et kontekstmatch, og det er angivet i katalogets data, aldrig afgjort af agenten i øjeblikket. Det er her, SDH forankrer agentens ræsonnement i noget gentageligt, uden at lade som om hele workflowet er deterministisk. Endelig kan specialiseringerne **bruges selvstændigt**. Fordi viden står på egne ben, kan en bruger køre en specialisering direkte i en prompt, der intet har med hele SDH-workflowet at gøre, og dermed holde sikkerheden med i almindelig udvikling. En specialisering med et deterministisk tjek kan for eksempel sortere hver kandidat, der bliver produceret under almindelig kodning, og kun beholde de sikre. Denne selvstændighed er en del af grunden til, at SDH tilpasser sig så mange situationer, som er emnet for `§VIII`, og dens fulde udtryk er den forebyggende tilstand (`§IX`), hvor den samme viden beskytter almindelig udvikling fra start til slut. --- ## VIII. Uafhængighed af tilstand og ikke-autoritativ tilpasningsevne To egenskaber adskiller SDH fra stive spec-metoder. ### Uafhængighed af tilstand > **Definition** > > **Uafhængighed af tilstand:** Metoden afhænger ikke af udviklingstilstanden. Den passer til en tom mappe, et projekt under udvikling, en enkelt pull request eller en stor legacy-kodebase, i enhver stak, fordi den lærer udgangspunktet at kende ved at læse det. Hver fase virker på samme måde, uanset om projektet er helt nyt eller allerede findes. Charter udleder principper af den kode, der er til stede. Detect kortlægger den kode, der er, selv hvis der er meget lidt. Der er intet forudsat udgangspunkt. ### Ikke-autoritativ tilpasningsevne > **Definition** > > **Ikke-autoritativ tilpasningsevne:** Metoden tilpasser sig scenariet i stedet for at påtvinge et fast omfang, som brugeren skal følge. Når brugeren ikke ved, hvad vedkommende skal sige, læser den det miljø, den blev kaldt i, skaber kontekst og stiller de spørgsmål, der former, hvad den gør derefter. Tilstanden, hvor charter foreslår, er det tydeligste eksempel: SDH udleder sikkerhedsprincipper, der er sikre som standard, ved at analysere projektet og spørger kun brugeren, når et hul faktisk ændrer resultatet, og skriver dem derefter og præsenterer hvert princip i almindelige ord med den risiko, det forhindrer. Sikkerhedsprincipperne er et levende dokument, som brugeren omarbejder ved at køre igen, ikke en kontrakt låst bag en godkendelsesprompt, så det kræver aldrig, at brugeren ved, hvad der skal spørges om. Denne tilpasningsevne viser sig som en følsomhed over for inputtets form: den samme fase læser det, den fik, og vælger en tilstand (figur 4). En fil i prompten, et fund fra listen, en bekymring, en fokuseret mission mod et kendt svagt punkt eller en anmodning om en fuld brute force-scanning: hver passer til brugerens behov, fordi workflowet er ikke-autoritativt af design. Intet af dette svækker grundlaget, der er sikkert som standard. Fleksibilitet former, hvordan grundlaget anvendes, men sænker det aldrig. ```mermaid flowchart TB shape["fasen læser formen
på det, den fik"] shape --> none["intet input"] shape --> paths["en eller flere stier"] shape --> concern["en beskrevet bekymring"] shape --> finding["et navngivet fund"] shape --> band["et prioritetsniveau"] none --> auto["den automatiske tilstand:
foreslå eller scan
hele omfanget"] paths --> focus["fokusér kun på de
filer eller mapper"] concern --> scoped["afgræns til den
ene bekymring"] finding --> item["handl på det ene
sporede punkt"] band --> priority["handl kun på Critical,
High, Medium eller Low"] ``` **Figur 4.** Ikke-autoritativ tilpasningsevne. Den samme fase læser formen på sit input og vælger en tilstand, så omfanget altid er brugerens, aldrig påtvunget. --- ## IX. Den universelle forebyggende tilstand: det samme forsvar, mens arbejdet bygges SDH har en supplerende tilstand: almindelig udvikling, udført med det samme forsvar aktivt, mens koden skrives. Brugeren beder om selve arbejdet, en loginside, en upload, et endpoint, og metoden beskytter opbygningen, mens den sker, så resultatet er sikkert som standard i det øjeblik, det lander, i stedet for efter en senere hærdning. > **Definition** > > **Den forebyggende tilstand:** almindelig udvikling, der kører under det overordnede lag og den viden, SDH har. Sikkerhedsprincipperne binder opbygningen, de specialiseringer, der er relevante for det, der er ved at blive skabt, indlæses efter behov, og resultatet holdes op mod netop det forsvar, der blev brugt, før arbejdet kaldes færdigt. Tilstanden genbruger hver del, faserne allerede har, rettet mod kode, der endnu ikke findes. Kontekstdetektionen vender sig fra koden til hensigten: agenten ræsonnerer sig gennem det, den er ved at bygge, og de grænser, arbejdet krydser (et login indebærer loginoplysninger, en session og input udefra), og det ræsonnement er det, vidensbiblioteket matches mod. Prompt efter behov (`§VII`) generaliseres her: kontekst kan opdages i planen for kode, ikke kun i kode, der findes. Sikkerhedsprincipperne styrer, som de altid gør, og en anmodning, der ville bryde et princip, bringes frem som en konflikt og bygges aldrig. Forsvaret anvendes undervejs, i det øjeblik hver del skrives, ved at validere ved grænsen og gribe efter den sikre konstruktion første gang, så en version, der virker, men er usikker, aldrig findes og skal rettes. Tilstanden slutter, som verify begynder. Før arbejdet kaldes færdigt, holder den, der bygger, sit eget resultat op mod det forsvar, den brugte: kontrollen skal ligge på risikoens vej, ikke ved siden af den, den skal være komplet, og hvor en specialisering har et deterministisk tjek, går tjekkets afgørelse forud for agentens egen læsning. Et hul, der findes her, lukkes som en del af det samme stykke arbejde, fordi at gøre arbejdet færdigt betyder at gøre det færdigt på en sikker måde. Det, tilstanden afviser, er lige så bevidst som det, den gør. Den bygger kun det, der blev bedt om, og gennemgår intet omkring det: at gennemgå det, der findes, hører til faserne. Den skriver intet artefakt og sporer intet fund, fordi et fund er en risiko, der er opdaget i det, der findes, og formålet med denne tilstand er, at den usikre version aldrig lander. De to retninger supplerer hinanden: faserne lukker det, der allerede er der (`§V`), og den forebyggende tilstand forhindrer nyt arbejde i at åbne det igen. En kæde i hvile forbliver i hvile, ikke fordi udviklingen er stoppet, men fordi det, der bygges, mens den hviler, bliver bygget forsvaret. --- ## X. Security-Driven Hardening over for Spec-Driven Development Security-Driven Hardening (SDH) voksede ud af grundlaget fra Spec-Driven Development (SDD) og skilte sig derefter markant fra det. Den strukturelle arv er reel og anerkendt: spec-first, agentdrevet, et styrende dokument og et sæt kommandoer i faser, som agenten kører. SDH genbruger bevidst den struktur. Det, der adskiller dem, er formålet, autoritetsmodellen, den forudsatte tilstand og slutbetingelsen. Vi behandler SDD som en klasse og bruger Piskalas rapport `[1]` som den kanoniske beskrivelse af metoden, Spec Kit fra GitHub `[2]` som den kanoniske værktøjskasse til agenter og OpenSpec `[3]` som endnu et værktøj fra samme familie. SDD vender traditionel udvikling på hovedet ved at gøre specifikationer eksekverbare: specen genererer direkte en fungerende implementering i stedet for blot at guide den `[1]`. Dens sæt af faser driver et byggeri fremad `[2]` (fastlæg styrende principper, specificér, hvad der skal bygges, planlæg den tekniske stak, del planen op i opgaver, og implementér derefter). Dens styrende dokument, en forfatning af principper, er det fundament, agenten hele vejen igennem skal overholde. Det er kernen i forskellen. I SDD flyder autoriteten fra specen ind i byggeriet, og implementeringen forventes at følge den. SDH vender næsten hver akse i den kontrakt om (tabel 3). > **Kerneindsigt** > > **Den centrale forskel:** I SDD flyder autoriteten fra specen ind i byggeriet, og implementeringen forventes at følge den. SDH er ikke-autoritativ og flyder den anden vej, indad fra systemets opdagede kontekst, og hærder det, der allerede er der. | Akse | SDD | SDH | | -------------------- | -------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- | | Mål | Levere funktioner. Specen bliver til en fungerende implementering. | Hærde det, der findes eller er ved at blive bygget. Hver fase er rettet mod forsvar. | | Autoritetsmodel | Autoritativ. Specen og forfatningen begrænser byggeriet til et omfang, det skal følge. | Ikke-autoritativ. SDH tilpasser sig scenariet, og brugeren kan omformulere, fjerne eller afgrænse. | | Forudsat tilstand | Et byggeri fremad ud fra en specifikation. | Uafhængig af tilstand: tom mappe, projekt under udvikling, en enkelt PR eller legacy. | | Slutbetingelse | Slutter, når funktionen er bygget. | Kan afsluttes. Et fund når en afklaret tilstand og genåbnes kun, når koden ændrer sig. | | Styrende dokument | En forfatning af principper, som agenten skal overholde. | Sikkerhedsprincipper formuleret ud fra risici (hvert med en linje `Why:`), udtrykkeligt ikke en fast kontrakt. | | Hvordan viden vokser | Tilføj en kommando (eller udvid sættet af faser). | Tilføj en ikke-kaldbar specialisering, som agenten indlæser efter behov: én fil plus én række i kataloget, ingen ny kommando. | | Hvem den tjener | En, der bygger og driver en funktion fremad. | Enhver bruger, udvikler eller ej, betjent gennem det samme workflow. | | Hvad ændrer koden | Implementeringsfasen genererer byggeriet. | Kun fasen harden ændrer kode, én rettelse ad gangen. | **Tabel 3.** SDD over for SDH på otte akser. Lånt struktur, omvendt kontrakt. For at yde slægtskabet retfærdighed: SDD er gennemprøvet tidligere arbejde, og SDH skylder det den struktur, den kører på. Afvigelsen er ikke en kritik af SDD, som løser et andet problem (at bygge fremad) godt. SDH tager det samme gennemprøvede maskineri og retter det mod forsvar, tilpasningsevne og afslutning. OpenSpec `[3]`, der er organiseret omkring ændringsforslag, opgavelister og specs pr. ændring, bekræfter mønsteret: familien driver et byggeri fremad ud fra en spec, mens SDH hærder et system indad fra dets opdagede kontekst. Selv den forebyggende tilstand i SDH (`§IX`), det ene sted, hvor den ledsager et byggeri fremad, bevarer den omvendte kontrakt: den styrer, hvordan arbejdet bygges, og afgør aldrig, hvad der skal bygges. --- ## XI. Teknisk stringens: disciplinen for sporing Disciplinen om at afstemme og aldrig kun tilføje (`§V`) kræver et fundament, der overlever refaktoreringer. Et fund skal forblive ét punkt på tværs af hver fase, der rører det, og en omdøbt eller flyttet fil må ikke bryde kæden. SDH løser det med **identitet ved navn** og **stier, der kun findes i sporingen**. > **Definition** > > **Identitet ved navn:** Et funds identitet er dets navn, skrevet ens i hvert artefakt. Teksten bærer navnet, aldrig en sti. Filstier findes kun i sporingskortet, så en omdøbning eller en flyttet fil bryder forbindelsen præcis ét sted. Hvert fund fra detect er ét sporet punkt. Dets identitet er dets **navn**, afsnitstitlen, skrevet ens i kortlægningen, planen og hærdningsloggen. De senere faser genbruger navnet ordret, når de handler på det samme punkt, og verify skriver sin afgørelse i hærdningsloggen under det samme navn. Sporingskortet indeholder sporing og intet andet, én post pr. punkt: ```json { "name": "File uploads", "paths": ["src/routes/upload.ts"] } ``` Kortet registrerer ingen tekst, ingen kommentarer, ingen separat identifikator og ingen fase. Tekstartefakterne bærer formuleringen, og kortet bærer kun identitet og stier. Filstier er det eneste foranderlige, og de findes kun her. En omdøbning eller en flyttet fil kan bryde forbindelsen præcis ét sted, aldrig i to kopier, der glider fra hinanden. ```mermaid flowchart TB detect["kortlægningen"] --> name plan["forsvarsplanen"] --> name harden["hærdningsloggen
verify skriver sin afgørelse her"] --> name name["navn = "File uploads"
teksten bærer navnet, aldrig en sti"] name -.-> tracking tracking["sporingskortet
{ name: "File uploads",
paths: ["src/routes/upload.ts"] }
stien findes kun her, så en omdøbning kun retter denne post"] ``` **Figur 5.** Identitetens transportbånd. Ét fundnavn flyder gennem hvert artefakt, mens dets sti kun findes i sporingskortet, så en omdøbning rettes ét sted. To handlinger vedligeholder kortet i det normale workflow, og en tredje står for sig selv som vedligeholdelse. **Track** er en tilføjende registrering: en fase rapporterer de fund, den har skrevet, og motoren registrerer de nye og følger en omdøbt sti for resten og klassificerer hvert som nyt, flyttet eller uændret. Den fjerner aldrig noget, fasen ikke har rapporteret. **Untrack** tager de fund ud, som verify har lukket: i ét deterministisk gennemløb destillerer den hvert til sin post i historikken, fjerner hele dets afsnit fra artefakterne, sletter et artefakt, hvis sidste fund er væk, og fjerner dets post i sporingen, så agenten ikke udfører noget af det manuelt. Hvor det deterministiske gennemløb ikke sikkert kan gå, et navn, der er taget ud, men stadig citeres i et andet funds tekst, markerer den stedet for agenten i stedet for at gætte en ændring. Disse to er det, faserne kalder, mens de kører. **Repair** er vedligeholdelseshandlingen: en fase uddelegerer automatisk til den, når dens egen afstemning finder sporingen inkonsistent (en registreret sti, der ikke længere findes), og ellers køres den efter behov. Den genopretter hele kortet på én gang, læser hvert artefakt og den aktuelle kode, retter hvert punkts stier og bringer det frem, den ikke kan afgøre alene, et forældreløst punkt (et sporet punkt, som intet artefakt længere nævner) eller en kandidat til omdøbning (et punkt, hvis stier matcher et andet rapporteret navn). Repair er vedligeholdelse, ikke en sjette fase. Den rører hverken brugerens kode eller tekstartefakterne, kun sporingen. Den læser kun brugerens kildekode af én grund, for at finde en omdøbt fils nye sti, og den skriver aldrig sikkerhedsindhold. Mennesket har det sidste ord i det ene spørgsmål, motoren nægter at gætte på: om et forsvundet punkt blev løst eller blot omdøbt. Spørg hellere end at gætte, for et punkt, der fejlagtigt fjernes, bryder kæden. Metoden anvender sin egen forsvarsdisciplin på sig selv. De deterministiske motorer kaldes som kommandolinjeprogrammer, og hvert input gives som sit eget procesargument, hvilket holder det uskadeligt, så en værdi med anførselstegn eller backticks aldrig kan injicere noget i kommandoen. Et ukendt tjek fejler i stedet for at svare, så et stavefejlsramt tjek aldrig læses som et rent resultat. SDH fritager ikke sit eget maskinrum fra princippet om at være sikker som standard. --- ## XII. Bæreren: agentuafhængig arkitektur som bevis på flytbarhed For at SDH kan blive en konvention, som andre tager i brug, må den ikke være bundet til én agent eller én stak, så dens bærer holder tre ansvarsområder adskilt (figur 6). Lagune beviser, at det kan lade sig gøre. **Sikkerhedsværdien** skrives én gang og ved intet om, hvilken agent der kører den: fasernes instruktioner og de skabeloner, de udfylder, vidensbiblioteket og de deterministiske motorer. **Leveringen** er tynd: dens eneste opgave er at bringe den værdi til en given agent i den form og på det sted, agenten forventer, og den har ingen sikkerhedslogik af sin egen. **Projektets tilstand** tilhører projektet: sikkerhedsprincipperne, faseartefakterne, sporingskortet, de kategorier, det har valgt, og dets egne specialiseringer, committet og til at gennemse som enhver anden del af dets kode. ```mermaid flowchart TB value["sikkerhedsværdien, skrevet én gang
fasernes instruktioner · skabeloner · vidensbibliotek · deterministiske motorer
ved intet om, hvilken agent der kører den"] delivery["levering
bringer værdien til hver agent i den form, den forventer
har ingen sikkerhedslogik"] agent["agenten
kører faserne"] project["projektets tilstand
committet sammen med dets kode
sikkerhedsprincipper · faseartefakter · sporing · kategorier · egne specialiseringer"] value --> delivery --> agent agent -->|"læser og skriver"| project ``` **Figur 6.** Den agentuafhængige bærer. Sikkerhedsværdien skrives én gang, en tynd levering bringer den til hver agent, og tilstanden forbliver projektets. Fordi leveringen ikke har nogen sikkerhedslogik, ændrer det intet i SDH, hvordan den er bygget. En bærer kan selv bygge leveringen eller overlade den til et økosystem, der allerede distribuerer skills til agenter, som referenceimplementeringen gør, og faserne, deres artefakter og deres garantier forbliver de samme. Intet af dette er heller specifikt for et sprog eller et runtime. Referenceimplementeringen er tilfældigvis skrevet i én stak, men metoden er grænsen mellem disse ansvarsområder, ikke den værktøjskæde, der bygger dem. Det samme design kunne genimplementeres i et helt andet sprog uden at ændre, hvad SDH er. --- ## XIII. Gennemgået eksempel: SDH fra start til slut > **Gennemgået eksempel** > > **Defensiv hærdning af en upload- og administrationsflade.** > **Kontekst:** en lille app, der tager imod filer uploadet af brugerne og oplister dem på en administrationsside. > **Mønster:** charter → detect (med viden efter behov aktiveret af konteksten) → plan → harden → verify, med én afslutning og én reel fejl. > **Resultat (kapabilitet):** én risiko verificeret lukket og taget ud af hele kæden, og én kontrol verificeret _ikke_ lukket og sendt tilbage til harden. Afgørelsen afspejler koden, ikke loggen. _Dette er et illustrativt eksempel på metodens mekanik, ikke en undersøgelse målt i praksis, og det rapporterer ingen målinger af effektivitet._ Én sammenhængende gennemgang viser metoden i drift, ikke kun dens dele. Vi udvider tråden om filupload fra `§IV` med en aktivering af viden efter behov og en afslutning, og vi medtager én reel fejl. 1. **charter** foreslår princippet "Alt input er ikke-betroet, indtil det er valideret" med sin risiko i almindelige ord: input, der ikke tjekkes, er den mest almindelige måde, et system bliver brudt på. 2. **detect** scanner upload-ruten og den lille administrationsside, der oplister uploadede filer. Den opdager fundet ved uploaden (handleren stoler på klientens MIME-type). Administrationssiden kører i browseren, en kontekst, som prompt efter behov (`§VII`) genkender, så detect indlæser specialiseringen til den kontekst og bringer et andet fund frem, et sted, hvor et filnavn skrives ind på siden som markup i stedet for tekst, så et manipuleret navn kan køre som script i den besøgendes browser. Specialiseringer, hvis kontekst mangler i dette omfang, indlæses aldrig, og hvert overspring registreres med fraværet aflæst i koden. 3. **plan** giver rettelsen af uploaden prioriteten Critical, knyttet til princippet: tjek filens reelle type og størrelse, omdøb ved lagring, og gem et sted, hvor kode ikke kan køre. Den giver den anden rettelse prioriteten High: vis filnavnet som tekst, ikke som markup. 4. **harden** gennemfører rettelsen af uploaden først (højeste prioritet) og registrerer den som Applied, og derefter den anden, Applied. 5. **verify** læser hvert sted og holder koden op mod loggen. Kontrollen ved uploaden holder: handleren bestemmer den reelle type ud fra indholdet, håndhæver en størrelsesgrænse og afviser resten. Afgørelse: risk closed. Verify tager fundet ved uploaden ud af hele kæden, og dets destillerede resumé havner i historikken. Den reelle fejl følger. Antag, at den anden rettelse fra harden tilføjede en sikker hjælper til visning af tekst, men lod det gamle kald, der skriver markup, være til at nå ad en anden kodevej. Verify læser siden, ser den sikre hjælper og ser også, at den usikre vej stadig er aktiv. Kontrollen er til stede, men risikoen er ikke lukket. Verify nægter at blødgøre afgørelsen for at passe til loggen. Den giver afgørelsen "risk not closed", registrerer hullet og peger tilbage til harden. En kontrol, der ikke fuldt ud håndterer risikoen, er ikke godkendt. Det er metodens karakter i ét eksempel: kontekstbevidst detektion, prioriterede rettelser knyttet til principper, omhyggelig gennemførelse og en verifikation, der rapporterer kodens faktiske tilstand uanset loggen. --- ## XIV. Hvornår SDH skal bruges, og dens grænser SDH er sjældent uforholdsmæssig, sådan som en tung proces kan være, fordi den er uafhængig af tilstand og kan afsluttes: den skalerer ned til en enkelt fil og en enkelt bekymring, og den når en afklaret tilstand i stedet for at efterlade en vedvarende byrde. Dens grænse er ikke projektets størrelse, men **sikkerhedsgarantiens dybde**. ```mermaid flowchart TB q1{"Gør koden noget sikkerhedsrelevant?
(input, autentificering, data, secrets, eksterne kald)"} q1 -->|nej| little["SDH tilføjer kun lidt her."] q1 -->|ja| q2{"Kør SDH. Er der et compliance-krav
eller en dedikeret sikkerhedsfunktion?"} q2 -->|nej| baseline["SDH er et forsvarligt grundlag."] q2 -->|ja| carrier["SDH er den strukturerede bærer:
den understøtter ekspertgennemgang og revision,
den erstatter dem ikke."] ``` **Figur 7.** Hvornår SDH skal bruges. Forgreningen spørger først om sikkerhedsrelevans, derefter om sikkerhedsgarantiens dybde, aldrig om projektets størrelse. Hvor SDH når sin grænse: adfærd, der kun viser sig, når systemet kører (verify læser kode, den kører ikke systemet), risiko, der afhænger af konfiguration eller et miljø, som agenten ikke kan læse, og kontekster med meget på spil, hvor ekspertgennemgang under alle omstændigheder er påkrævet. I hvert af disse tilfælde tilfører SDH stadig værdi som et struktureret første gennemløb, men den er et gulv, ikke et loft. > **Kerneindsigt** > > **Grænsen:** Grænsen for SDH er sikkerhedsgarantiens dybde, ikke projektets størrelse. Den kan tjene som et forsvarligt grundlag næsten overalt, og den understøtter ekspertgennemgang, hvor der er meget på spil, men den erstatter hverken test af det kørende system eller en sikkerhedsprofessionels dømmekraft. --- ## XV. Diskussion: placering, grænser og hvad SDH ikke påstår SDH er præcis om sine grænser. ### Den udvider, den erstatter ikke SDH erstatter ikke sikkerhedsprofessionelle eller specialiserede Blue Team-værktøjer. Den udvider udviklerens viden (`§VI`). En afmålt påstand er den rigtige: anvendt godt **kan** SDH effektivt lukke reelle risici, især for projekter, der ellers slet ikke ville få en sikkerhedsgennemgang. Den er ikke en garanti, og den er ikke en erstatning for ekspertgennemgang, hvor der er meget på spil. ### Udelukkende forsvar, af konstruktion SDH gennemgår, hærder og verificerer. Den producerer aldrig offensive værktøjer, exploits eller omgåelse af detektion til skade. Sikkerhedsindhold med dobbelt anvendelse er kun acceptabelt i en tydeligt defensiv og autoriseret indramning. Det er en fast grænse, ikke en præference. ### Verifikationen er substantiel, ikke teatralsk Verify verificerer ved at læse koden og holde den op mod loggen, ikke ved at køre systemet. Det er statisk verifikation: den bekræfter, at en kontrol findes og er korrekt i koden, og den beviser ikke, at kontrollen holder under et angreb under kørsel. Derfor er "cannot tell from the code" en legitim afgørelse, ikke en fejl skjult bag et godkendt resultat. Når belægget ikke findes i koden (det afhænger af konfiguration eller af en sti, agenten ikke kan læse), siger SDH det i stedet for at gætte. ### Determinisme er afgrænset og navngivet Det meste af SDH er ræsonneret af agenten, og det er det, der giver dens kontekstbevidsthed. Determinisme er forbeholdt de deterministiske motorer: de tjek, en specialisering kan have med (`§VII`), og sporingsmotoren (`§XI`). Artiklen udvisker ikke denne grænse. Hvor et resultat er deterministisk, er det et programs resultat. Hvor det er ræsonneret, er det agentens læsning af koden, med brugeren som den, der har det sidste ord. ### Omkostninger og skala En fuld scanning bruger mange tokens. De manuelle tilstande (`§VI`, `§VIII`) findes blandt andet for at holde omkostningerne i forhold til bekymringen. ### Brugeren har det sidste ord SDH beder mennesket afgøre, om noget er omdøbt eller løst, og godkendelsen af kodeændringerne forbliver dér, hvor brugeren allerede styrer sin agent, i den tilladelsestilstand, vedkommende kører den i. Metoden foreslår og verificerer. Den tilsidesætter ikke personen. ### Indvendinger og svar En fair skeptiker vil rejse flere indvendinger. De væsentlige er værd at stille med deres egne ord. **"Er det ikke bare en statisk analysator med en LLM skruet på?"** Nej. En statisk analysator kører som standard alle de regler, den har. SDH finder først ud af, hvad systemet er, og griber derefter efter den relevante viden (`§II`, `§VII`), og den _indlejrer_ kun et deterministisk tjek, hvor en risikoklasse har en skarp beslutningsprocedure. Ræsonnementet tager udgangspunkt i konteksten, og determinismen er målrettet. **"Er det ikke bare en sikkerhedstjekliste?"** Nej. SDH vender tjeklisten om: detektion kommer først, og viden hentes ind til det, projektet rent faktisk gør (`§II`, `§VII`). **"Er det ikke bare SDD med nyt navn til sikkerhed?"** Nej. SDH låner strukturen fra SDD og vender dens kontrakt om: autoritet, forudsat tilstand, slutbetingelse og hvem den tjener er alle forskellige (`§X`). Samme maskineri, modsat retning. **"Hallucinerer en metode, der ræsonneres af AI, ikke bare fund?"** Designet begrænser opfindelse i stedet for at stole på, at modellen opfører sig ordentligt. Detect registrerer kun det, koden understøtter ("at opdage, ikke at opfinde", `§IV`), verify holder koden op mod loggen og kan svare "cannot tell from the code" (`§XV`), deterministiske tjek forankrer de tilfælde, der kan afgøres (`§VII`), og brugeren har det sidste ord. Det gør ikke agenten ufejlbarlig, men det gør dens påstande til at kontrollere. En bemærkning om placering. SDH defineres her uafhængigt af sin referenceimplementering. De fem faser, sikkerhedsprincipperne formuleret ud fra risici, afstemning frem for tilføjelse og dermed afslutning, viden efter behov, den forebyggende tilstand, sporing med identitet ved navn og grænsen om udelukkende forsvar udgør metoden. Et andet team kunne implementere dem i en anden stak og et andet økosystem af agenter, og resultatet ville stadig være SDH. Lagune er dens bevis, ikke dens definition. --- ## XVI. Faldgruber, og hvordan SDH strukturelt undgår dem Metoder i denne familie deler et kendt sæt fejltyper. SDH's svar på de fleste af dem er strukturelt, indbygget i workflowet i stedet for overladt til disciplin. | Faldgrube | Fejlen | SDH's strukturelle svar | | --------------------------------- | ----------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | | Forfaldne specs, forældet backlog | Artefakter samler døde poster, som ingen stoler på | Afstem, aldrig kun tilføj (`§V`): hver kørsel tjekker hver post igen og fjerner det, der er løst | | Falsk tryghed, godkendt resultat | Man antager, at en kontrol, der findes, lukker risikoen | Verify holder koden op mod loggen, så "risk not closed" og "cannot tell" er førsteklasses afgørelser (`§IV`, `§XV`) | | Oversvømmelse af tjeklister | Generiske punkter skjuler den ene risiko, der betyder noget | Kontekstbevidst frem for generisk, med prompt efter behov, der kun indlæser det, omfanget kræver (`§VII`) | | Fastlåsning til værktøjer | Metoden er svejset fast til én leverandør eller agent | Agentuafhængig bærer: sikkerhedsværdien skrives én gang, og dens levering til hver agent har ingen sikkerhedslogik (`§XII`) | | Den endeløse løkke | Backloggen lukker aldrig, arbejdet hviler aldrig | Afslutning og den afklarede tilstand (`§V`) | **Tabel 4.** Kendte faldgruber i denne familie af metoder og SDH's strukturelle svar på hver af dem. Pointen er at navngive faldgruben og pege på mekanismen: det er ikke advarsler om at være forsigtig, men egenskaber ved workflowet. --- ## XVII. Fremtidigt arbejde Metoden og dens referenceimplementering har klare næste skridt. - **Udvid vidensbiblioteket:** Hver tilføjelse bevarer formen fra `§VII`: en vidensfil og en række i kataloget, ingen ny kommando. Vejen for brugeren findes allerede dér: brugeren destillerer sine egne specialiseringer efter behov. Flere indbyggede sprog, runtimes og risikoklasser, der hver kommer med i en kategori, er retningen for vedligeholderen, og specialiseringerne forventes at udvikle sig. - **Flere deterministiske tjek:** Hvor en risikoklasse har en skarp beslutningsprocedure, kan en specialisering have et deterministisk tjek med, der forankrer agentens ræsonnement i en gentagelig afgørelse. At udvide dette til flere risikoklasser er en naturlig retning. - **Empirisk evaluering:** Det stærkeste åbne spørgsmål er den målte effekt: kvaliteten af afslutninger og andelen af forkerte afgørelser på tværs af rigtige kodebaser. En undersøgelse af sikkerhedsresultaterne af SDH er fremtidigt arbejde, og påstandene her er afgrænset derefter. --- ## XVIII. Konklusion AI-assisteret udvikling åbnede et sikkerhedshul, som generiske tjeklister ikke kan udfylde, fordi den risiko, der betyder noget, er specifik for det, et system rent faktisk gør, og den person, der udgiver det, ved måske ikke, hvad der skal spørges om. SDH lukker det hul med et kontekstbevidst, udelukkende defensivt workflow, der kan afsluttes, hvor sikkerhedsviden ligger i metoden og dens specialiseringer efter behov, et grundlag, som enhver bruger kan bygge videre på. Den finder systemets reelle kontekst, prioriterer de risici, den kontekst indebærer, gennemfører rettelser omhyggeligt og verificerer hver af dem, og tager derefter det ud, den har lukket, så hvert fund når en sluttilstand. Det samme forsvar kører også forebyggende, mens nyt arbejde bygges, så det, workflowet lukker, forbliver lukket. Den tilpasser sig enhver udviklingstilstand i enhver stak, og den udvider udviklerens viden i stedet for at erstatte de mennesker og værktøjer, der allerede gør det arbejde. Lagune er beviset, men bidraget er konventionen. SDH tilbydes som det essentielle sikkerhedsworkflow i tiden med udvikling med AI, så andre kan tage det i brug, forfine det og implementere det i deres egne stakke. --- ## Referencer **[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. --- ## Bilag A: principperne ordret 1. **Sikker som standard, i almindelige ord, for alle lige:** Hver standard, besked og rettelse skal være sikker fra starten og forståelig for enhver bruger, udvikler eller ej. Ingen gruppe af brugere er privilegeret frem for en anden. 2. **Kontekstbevidst frem for generisk:** Hver fase skal starte fra den kontekst, der blev fundet i detect, og handle på det, systemet rent faktisk gør. Foretræk anbefalinger, der er specifikke for den kontekst, frem for generiske tjeklister. Sikkerhedsviden ligger i specen og dens specialiseringer efter behov og udvider det, brugeren selv bringer med. 3. **Fleksibel frem for stiv:** SDH bøjer sig efter projektet og brugeren. Principper, krav og anbefalinger er udgangspunkter, ikke en fast kontrakt. Lad brugeren omformulere, fjerne, tilføje eller afgrænse hvad som helst. Fleksibilitet svækker aldrig grundlaget, der er sikkert som standard, den lader kun brugeren forme, hvordan det anvendes. 4. **Afstem, aldrig kun tilføj:** Artefakter er levende dokumenter, ikke logs. Når en fase kører igen, så afstem hver eksisterende post med den aktuelle sandhed: behold det, der stadig holder, omskriv det, der har ændret sig, og fjern det, der ikke længere gælder. Afslutning er den samme afstemning, der når sin konklusion. 5. **Udelukkende forsvar:** SDH gennemgår, hærder og verificerer. Den producerer aldrig offensive værktøjer, exploits til ondsindet brug eller omgåelse af detektion til skade. Sikkerhedsindhold med dobbelt anvendelse er kun acceptabelt i en tydeligt defensiv og autoriseret indramning. 6. **Spec-first, agentdrevet, indrammet til sikkerhed:** Byg workflowet ud fra en gennemprøvet struktur: skabeloner, kommandoer, styrende sikkerhedsprincipper og en agent, der kører faserne. Genimplementér den struktur med et defensivt formål. --- # Ordliste for Lagune: SDH, charter, fund og kontroller > Definitioner i almindelige ord af hvert begreb i Lagune og Security-Driven Hardening: SDH, charter, detect, fund, kontrol, harden, verify, at tage ud, at sikkerhed kan afsluttes, specialiseringer, kategorier og kataloget. Kanonisk URL: https://lagune.ai/da-DK/docs/references/glossary Sprog: da-DK Original: https://lagune.ai/docs/references/glossary Sidst opdateret: 2026-11-09 Hvert bærende begreb i Lagune og metoden Security-Driven Hardening, defineret én gang, i almindelige ord. ### Security-Driven Hardening (SDH) Den metode, Lagune implementerer: en kontekstbevidst Blue Team-konvention, der finder et systems kontekst, prioriterer de risici, den kontekst indebærer, og guider rettelserne. Sikkerhedsviden ligger i specen og dens specialiseringer efter behov, så en udvikler og en ikke-udvikler betjenes gennem det samme workflow. ### Lagune Referenceimplementeringen af SDH: ni agentkommandoer, hver med den skabelon, den udfylder, som en AI-agent kører for at hærde en kodebase. Hver agent installerer dem gennem sin egen plugininstallation eller [**skills.sh**](https://www.skills.sh/wellwelwel/lagune), som [installationssiden](https://lagune.ai/da-DK/docs) viser, og de kører motoren i Lagune til hvert deterministisk trin. ### Charter Det overordnede lag i Lagune: et sæt principper med sikkerheden i første række, som hver senere fase skal respektere. Tænk på det som kompileringstjekket for et projekts sikkerhedsniveau. Det gemmes i `.lagune/memory/charter.md`. ### Udviklingsworkflow Den universelle kommando `/lagune`, der hærder arbejdet, mens det bliver skrevet. Den tager imod enhver prompt i enhver fase, bygger det, du bad om, og hærder det med sikre standardindstillinger, før den afleverer det, styret af sikkerhedsprincipperne, når de findes. Den skriver intet til sporingen i Lagune, så dens eneste produkt er den hærdede kode. Sammen med charter (før) og Blue Team-workflowet (efter) er det sådan, Lagune beskytter under opbygningen. ### Blue Team-workflow Gennemgangen i fem faser i kernen af Lagune: charter, detect, plan, harden, verify. Hver fase bygger på den forrige. "Blue Team" er sikkerhedstraditionen for forsvarere, i modsætning til det offensive Red Team. ### Fund Én opdaget risiko. Hvert fund indeholder, hvad det er, hvorfor det betyder noget, og belægget i koden. Et fund er den ene sporede enhed, som plan, harden og verify fører videre, identificeret ved navn på tværs af alle artefakter. ### Sikkerhedskontrol En sikkerhedsforanstaltning, der anvendes for at lukke en risiko. Harden anvender kontroller, verify påviser, at de holder. Lagune svækker aldrig en kontrol for at imødekomme en prompt. ### Detect Den fase, der læser koden og kortlægger, hvad systemet gør, og hvor risiciene er. Dens styrende regel er at opdage, ikke at opfinde: den registrerer kun det, koden understøtter. ### Harden Den eneste fase, der rører din kode. Den gennemfører planens rettelser én ad gangen og registrerer hver som Applied, Partial eller Blocked. Applied betyder ikke, at den er påvist endnu. ### Verify Den fase, der påviser, at hver gennemført rettelse holder, ved at læse koden og holde den op mod det, harden registrerede. Den giver én af tre afgørelser: Risk closed, Risk not closed eller Cannot tell from the code. ### Tage ud Når verify påviser, at en risiko er lukket, bliver fundet taget ud: fjernet fra hele kæden, med din bekræftelse, så det ikke længere bliver behandlet igen. ### Kan afsluttes Egenskaben, at sikkerhedsarbejde har en sluttilstand. Fordi et fund, der er påvist lukket, bliver taget ud, kan workflowet komme til hvile og åbnes kun igen, når koden ændrer sig. SDH kan afsluttes og er ikke en endeløs løkke. ### Motor Pakken `lagune` på **npm**, som kommandoerne kører gennem `npx` til hvert deterministisk trin: hooks, kataloget og kategorierne. ### Specialisering Et fokuseret, sprogneutralt modul med sikkerhedsviden, der kun indlæses efter behov, aldrig som standard. En specialisering er ikke en kommando. Indlæs en i en hvilken som helst prompt med motorens `read catalog `, for eksempel `npx lagune read catalog regex`. ### Kategori En navngivet gruppe af indbyggede specialiseringer, fra `owasp` til dem pr. sprog som `javascript`, `python`, `go` og `rust`. De kategorier, et projekt bruger, registreret i `.lagune/configs.json`, afgør, hvilke indbyggede der kommer med i dets katalog. Så længe der ikke er registreret nogen, bruger projektet kun `owasp`. ### Katalog Det sæt specialiseringer, et projekt bruger: de indbyggede i dets kategorier plus dets egne, skrevet med `/lagune-specialize`. Motorens `read catalog` oplister det, og faserne matcher det op mod koden. ### Prompt efter behov Princippet om, at den relevante sikkerhedsviden hentes ind til det, projektet rent faktisk er, i stedet for at alle tjek kører som standard. ### Identitet ved navn Sporingsmodellen i Lagune: hvert funds navn, skrevet ens som afsnitstitel i hvert artefakt, er dets identitet gennem hele kæden. Sporingskortet (`.lagune/tracking.json`) indeholder kun sporing, aldrig tekst. ## Ofte stillede spørgsmål ### Hvad er Security-Driven Hardening (SDH)? SDH er en kontekstbevidst Blue Team-metode til sikkerhed. Den finder et systems kontekst, prioriterer de risici, den kontekst indebærer, og guider rettelserne, med hvert fund formuleret i almindelige ord. Lagune er dens referenceimplementering. ### Hvad er charter i Lagune? Charter er det overordnede lag i Lagune, et sæt principper med sikkerheden i første række, som hver senere fase skal respektere. Det gemmes i .lagune/memory/charter.md. ### Hvad vil det sige at tage et fund ud? Når verify påviser, at en risiko er lukket, bliver fundet taget ud: fjernet fra hele kæden med din bekræftelse, så det ikke længere bliver behandlet igen. --- # Skema for configs > JSON Schema for konfigurationen af et Lagune-projekt, til autofuldførelse og validering i din editor, der følger den aktuelle version af Lagune eller er fastlåst til en bestemt version. Kanonisk URL: https://lagune.ai/da-DK/docs/references/configs-schema Sprog: da-DK Original: https://lagune.ai/docs/references/configs-schema Sidst opdateret: 2026-11-09 `.lagune/configs.json` registrerer de [**kategorier**](https://lagune.ai/da-DK/docs/categories), et projekt bruger, indekserer dets egne [**specialiseringer**](https://lagune.ai/da-DK/docs/catalog) og bestemmer, hvad [**tjekkene**](https://lagune.ai/da-DK/docs/hooks/configure) udelader. Dets JSON Schema lader din editor autofuldføre hvert felt og markere en tastefejl eller en ukendt kategori, mens du redigerer filen. ## Det aktuelle skema Hver gang **Lagune** skriver filen og ikke finder nogen `$schema` i den, peger det filen mod det aktuelle skema: ```json { "$schema": "https://lagune.ai/schemas/configs.json", "categories": ["owasp", "javascript"] } ``` Denne adresse følger altid den aktuelle version af **Lagune**. En fil, der er skrevet før **Lagune** 0.16.0, får den ved sin næste ændring, og hver fase gør opmærksom på det indtil da. ## Fastlås en version Hver udgivelse af **Lagune** fra 0.16.0 og frem indeholder skemaet, som det var i den version, udgivet på **npm** og leveret af **jsDelivr**. Hvis du vil fastlåse en, så sæt versionen efter `lagune@` i adressen i `$schema`: ```json { "$schema": "https://cdn.jsdelivr.net/npm/lagune@0.16.0/schemas/configs.json" } ``` Versionen accepterer ethvert semver-interval: | Version | Skema | | --------------------- | ------------------------------------- | | `0.16.0` | Det fra 0.16.0 | | `0.16.x` eller `0.16` | Det fra den seneste udgivelse af 0.16 | | `0.x` eller `0` | Det fra den seneste udgivelse af 0.x | | `latest` | Det fra den seneste udgivelse | ## Ofte stillede spørgsmål ### Har Lagune brug for skemaet? Nej. Skemaet hjælper kun din editor, og Lagune læser filen på samme måde med eller uden $schema. ### Overskriver Lagune et fastlåst skema? Nej. Lagune skriver kun $schema, når filen ikke har noget, og beholder enhver adresse, du angiver. ### Hvornår skal jeg fastlåse en version? Når projektet kører en bestemt version af Lagune, så din editor validerer filen mod det, den version accepterer. --- # Lagune vs. Deepsec: to AI-drevne tilgange til sikkerhed side om side > En reference, der sammenligner Lagune og Deepsec fra Vercel ud fra, hvordan de virker, livscyklus, detektion, omkostninger, fund og afslutning. Kanonisk URL: https://lagune.ai/da-DK/docs/references/deepsec Sprog: da-DK Original: https://lagune.ai/docs/references/deepsec Sidst opdateret: 2026-11-09 [Lagune](https://github.com/wellwelwel/lagune) og [Deepsec](https://github.com/vercel-labs/deepsec) (`v2.2.1`) er to defensive svar på det samme problem: sikkerhed i en tid med AI-assisteret udvikling. Deres præmis, deres begyndelse, midte og slutning, og hvordan hver af dem præsenterer sig for en bruger, er bevidst forskellige, selv hvor deres mekanik overlapper. **Tip** Er Lagune inspireret af Deepsec? Nej, Lagune er skrevet fra bunden og er inspireret af Spec-Driven Development og Security Hardening. De to projekter er udviklet uafhængigt af hinanden, og sammenligningen her skal hjælpe brugerne med at forstå forskellene. ## Overblik | Aspekt | Lagune | Deepsec | | ------------------- | --------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- | | Type | En metode (SDH) med en referenceimplementering | Et produkt: en sårbarhedsscanner drevet af agenter | | Tyngdepunkt | Sikkerhedsprincipper og viden efter behov styrer agenten, forankret i deterministiske hooks | Et bredt regex-net fodrer en obligatorisk AI-undersøgelse | | Hvad den producerer | Hærdet kode, beviser og en sporet kæde af fund | En triageret rapport over fund, rangeret efter alvorlighed | | Rører din kode | Ja: `harden` redigerer din kode | Nej: kun statisk analyse, udsender fund og anbefalingstekst | | Kørsel | Kører på den agent og model, du allerede bruger, på ethvert niveau | Kører sin egen modelpipeline, som standard på et frontier-niveau | | Kom i gang | Én plugininstallation eller `npx skills add`, og styr den derefter med almindelige ord, intet nyt værktøj at sætte op | Sæt et arbejdsområde `.deepsec/` op, installér afhængigheder, og tilføj en modelnøgle | ## Sådan virker det Lagune er agent-først: agenten styrer, henter viden efter behov ud fra, hvad koden er, og uddelegerer en del, der kan afgøres, til de deterministiske hooks. Deepsec er deterministisk-først: en bred scanning markerer kandidater, der peger en obligatorisk model mod, hvad den skal undersøge og vurdere. | Aspekt | Lagune | Deepsec | | -------------------- | ------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------- | | Rækkefølge | Sikkerhedsprincipperne og den matchede viden styrer agenten, som uddelegerer til hooks og vurderer resten | Matchers markerer kandidater, og modellen undersøger og vurderer hver enkelt | | Deterministisk rolle | Hooks til flere sprog, der returnerer en afgørelse eller retter agenten, kombineret med viden fra kategorier | Matchers, der markerer kandidater, som den obligatoriske model skal vurdere | | Udviklingsworkflow | `/lagune` bygger sikkert undervejs, mens du koder | Den gennemgår kode, den skriver den ikke | | Gennemgang | `charter` → `detect` → `plan` → `harden` → `verify` | `scan` → `process` → `triage` → `revalidate` → `report` | | AI'ens opgave | Ræsonnere ud fra viden, anvende rettelsen og påvise, at den holder | Undersøge hver kandidat og rapportere fundene | ## Livscyklus Lagune virker før, under og efter, at koden bliver skrevet. Deepsec gennemgår et repository, når koden findes. | Tidspunkt | Lagune | Deepsec | | -------------------- | ----------------------------------------------------------------------------- | ------------------------------------------------------------ | | Før koden findes | `charter` skaber en sikkerhedspolitik ud fra den erklærede hensigt | Starter fra eksisterende kode: `init` kræver en mappe | | Mens der bygges | `/lagune` bygger sikkert som standard undervejs, uden at efterlade artefakter | Gennemgår efter opbygningen, ikke under den | | På eksisterende kode | `detect` → `plan` → `harden` → `verify` | `scan` → `process`, kerneforløbet | | Løbende gennemgang | Kør faserne igen pr. omfang, ingen færdigpakket CI-gate | Inkrementel genscanning, `process --diff` som exit-gate i CI | ## Detektionslag De to deterministiske lag er modsatte af natur: det ene afgør, det andet markerer. | Aspekt | Lagune | Deepsec | | ---------------- | ------------------------------------------------------------------------------------ | ---------------------------------------------------------------------- | | Gruppering | Hooks og specialiseringer, grupperet i kategorier | Matchers pr. mønster eller framework | | Output | Bogstavelig afgørelse (fund / gennemgang / anbefaling) plus en klassifikationsetiket | Kandidat uden afgørelse (slug, linjer, kodeuddrag, matchet mønster) | | Tuning | Præcision: kender kommentarer, værn mod pladsholdere og vinduer | Recall: brede net, AI'en beskærer falske positiver bagefter | | Dybde | Dybere på fælles klasser | Bredere, mindre dyb på fælles klasser | | Falske positiver | Holdes lave ved kilden og vurderes derefter i kontekst | Overgenereres med vilje og skæres ned af et gennemløb med `revalidate` | ## Viden og vurdering Begge bærer sikkerhedsviden, som regex ikke kan. De adskiller sig i, hvor den ligger, og hvem der kan forme den. | Aspekt | Lagune | Deepsec | | ----------------------- | --------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- | | Form | Redigerbare markdown-moduler, flere af dem understøttet af en deterministisk hook | En kort prompt og fremhævninger pr. teknologi, der trækker på modellens egen viden | | Udvælgelse | Matchet til koden, kun indlæst når dens kontekst er til stede | Indsat i hver AI-batch plus fremhævninger for den opdagede teknologi | | Hvem skriver den | Brugeren redigerer moduler og tilføjer nye med `specialize` | Vedligeholderen ejer prompten, brugeren udfylder en `INFO.md` | | Hvor vurderingen ligger | Hooks afgør deres minimum, agenten vurderer resten ud fra viden | Centraliseret: én AI-processor vurderer hver kandidat | | Genbrug | Ét modul guider både `detect` og `verify` | Én prompt driver det ene trin `process` | ## Fund og afslutning De adskiller sig mest i, hvad et fund bliver til, når det er løst. | Aspekt | Lagune | Deepsec | | --------------------- | ------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- | | Alvorlighed | En CVSS v4.0-score, justeret for eksponering og indsats | En alvorlighed fra AI'en plus en triage efter P0 / P1 / P2 af udnyttelighed og konsekvens | | Afgørelser | Risk closed, not closed eller cannot tell from the code | true-positive, false-positive, fixed, uncertain, accepted-risk, duplicate | | Persistens | Den aktive kæde afstemmes, lukkede fund destilleres til en historik | Poster pr. fil, der kun tilføjes til, intet fjernes | | Sluttilstand | Kan afsluttes: et påvist fund bliver taget ud, og kæden kan hvile | Hvert fund beholdes for altid og skjules fra visninger, når det er løst | | Historikkens detaljer | Et kompakt resumé af, hvad risikoen var | Hele sporet af afgørelser, inklusive hvordan det blev rettet | ## Omkostninger | Aspekt | Lagune | Deepsec | | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Deterministisk minimum | Gratis: hooks kører uden AI og uden nøgle og udsender allerede afgørelser | Gratis: `scan` kører uden AI, men udsender ingen afgørelser af sig selv | | Typisk regning | Indeholdt i en agent, du allerede bruger, ned til $0 med en lokal model, den abonnementspris, du allerede betaler, eller pr. iteration ved brug via API | [Cirka $25 til $1.200 pr. kørsel for 100 til 2.000 filer, mere i stor skala](https://github.com/vercel-labs/deepsec/blob/f75a16803ec5250938bacfe41571d929e8564f45/docs/getting-started.md#run-the-ai-investigation) | | Billigste vej | Enhver model, også en gratis lokal model, afslutter cyklussen | Der findes billigere betalte niveauer, men fund kræver det betalte AI-trin | ## Udvidelse og styring Hver af dem åbner det lag, den anden holder lukket. | Aspekt | Lagune | Deepsec | | ---------------------- | ---------------------------------------------------------- | ---------------------------------------------------------- | | Hvad du udvider | Redigér moduler, eller tilføj nye via `specialize` | Tilføj matchers, agenter, notifikatorer og ejerskab | | Politiklag | Sikkerhedsprincipperne styrer hver fase og er versionerede | Konfigurationen er operationel (matchers, modeller, stier) | | Overskrivning ved navn | Et forfinet modul overskygger det indbyggede | Ved en kollision mellem matcher-slugs vinder din matcher | ## Brugerflader Deepsec udsender leverancer til en sikkerhedsorganisation. Lagune viser en livevisning for den, der kører det. | Aspekt | Lagune | Deepsec | | ----------------------- | ----------------------------------------------------------------------------- | ---------------------------------------------------------------------------- | | Menneskelig brugerflade | Et lokalt livedashboard over hele kæden, i almindelige ord | Filer til rapport, eksport, metrikker og PR-kommentarer plus et docs-websted | | Ansvarlighed | Viser filer og de specialiseringer, der blev anvendt | Foreslår en ansvarlig: vagthavende, leder eller den, der committede | | Reproducerbart bevis | `prove` skriver kørbare tests og en sikkerhedsmeddelelse til offentliggørelse | Forbliver statisk af design og kører aldrig målet | | Værktøjets selvforsvar | Hærder et lokalt skrive-API i dashboardet | Hærder sin egen AI-kørsel mod ikke-betroet målkode | ## Skala og udrulning | Aspekt | Lagune | Deepsec | | ----------------- | ------------------------------------------------------------------------------- | --------------------------------------------------------------------- | | Installation | Ni kommandoer fra din agents plugin eller CLI'en fra skills, intet stilladseret | Et arbejdsområde `.deepsec/` med sin egen pakke og egne afhængigheder | | Skaleringsretning | Afgrænses til enhver del, en kontekst, fra én fil til hele projektet | Gennemsøger hele repositories, op til store monorepos | | Distribution | Kun lokalt, den ene server binder til loopback | Valgfri fordeling på tværs af worker-VM'er i Vercel Sandbox | ## Brugeroplevelse Hvordan hver af dem møder den person, der kører den: hvad den første kørsel kræver, og hvordan operatøren styrer den. ### Kom i gang Lagune kører gennem den agent, der allerede er åben. Deepsec opretter først sit eget arbejdsområde og sin egen modeladgang. | Aspekt | Lagune | Deepsec | | --------------------------- | ----------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ | | Første kommando | Plugininstallationen eller `npx skills add wellwelwel/lagune` og derefter `/lagune-*` i agenten | `npx deepsec init`, derefter `cd .deepsec`, `pnpm install`, `scan`, `process` | | Loginoplysninger til kørsel | Ingen separat nøgle, den bruger din nuværende agent | En modelnøgle (f.eks. AI Gateway, et Vercel OIDC-token, der gælder i 12 timer, eller et token fra Anthropic) | ### Styring Begge tager imod retning. Lagune læser inputtets form pr. fase. Deepsec indsnævrer det sæt filer, den samme undersøgelse kører over. | Aspekt | Lagune | Deepsec | | ------------------- | ----------------------------------------------------------------------------------- | ----------------------------------------------------------- | | Hele projektet | En fase uden input scanner hele omfanget | `scan` og `process` gennemsøger repositoriet | | En del | Enhver fase kan afgrænses til angivne filer eller mapper | `--files`, `--files-from` eller `--diff` indsnævrer kørslen | | En bekymring | En fase kan afgrænses til en beskrevet bekymring | Undersøgelsens prompt er fast | | Et prioritetsniveau | `harden` og `verify` kan afgrænses til Critical, High, Medium eller Low | Fundene får etiketter efter kørslen | | En enkelt værdi | En hook vurderer ét kodeuddrag, mønster eller én URL direkte (`--pattern`, `--url`) | Arbejdsenheden er en fil | ## Ofte stillede spørgsmål ### Hvordan adskiller Lagune sig fra Deepsec? Lagune er agent-først og virker før, under og efter, at koden bliver skrevet: det fastlægger en politik før koden, hærder undervejs, mens der bygges, og gennemgår, hærder og verificerer kode, der allerede er skrevet. Deepsec er deterministisk-først: en bred regex-scanning fodrer en obligatorisk undersøgelse med en frontier-model, der gennemgår eksisterende kode og rapporterer fund uden at ændre den. ### Kan jeg køre en af dem gratis? Hele workflowet i Lagune kan køre for $0 med en gratis lokal model, og dets deterministiske hooks udsender afgørelser helt uden AI. Scanningen i Deepsec er gratis, men udsender ingen afgørelser, så ethvert fund kræver dets betalte AI-trin. ### Ændrer nogen af dem min kode? Lagune gør: harden gennemfører rettelser i din kode. Deepsec gør ikke: det er kun statisk analyse, der udsender fund og anbefalingstekst, som en person eller agent anvender separat. --- # OWASP-kilder > Hvor viden i de indbyggede OWASP-specialiseringer kommer fra, koblet til de kanoniske sider om angreb og Cheat Sheets hos OWASP. Kanonisk URL: https://lagune.ai/da-DK/docs/references/owasp-sources Sprog: da-DK Original: https://lagune.ai/docs/references/owasp-sources Sidst opdateret: 2026-11-09 Dette dokument kobler hvert **angreb** (`www-community`) og hvert **Cheat Sheet** (`CheatSheetSeries`) fra OWASP til en sikkerhedskategori, hver med et link til sin kanoniske offentlige side. Inden for en kategori deler ensbetydende punkter én linje i tjeklisten: de angreb og Cheat Sheets, der handler om samme risiko, står sammen, adskilt af kommaer. Punkter uden en direkte modpart står på deres egen linje. - Æren tilfalder OWASP. Angrebene ligger på `https://owasp.org/www-community/attacks/` og Cheat Sheets på `https://cheatsheetseries.owasp.org/cheatsheets/.html`. --- ## 1. Injection (generelt) - [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- og database-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- og 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- og 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) og 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. Omdirigeringer og videresendelser - [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. Adgangskontrol og autorisation - [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. Autentificering og loginoplysninger - [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. Sessionshåndtering - [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. Identitetsføderation (OAuth, SAML og 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. Kryptografi og transportsikkerhed - [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 og filhåndtering - [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. Misbrug af HTTP-protokollen (headers, 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) (fordelt på browser, transport, http-request og 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. Kodning og 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- og regnearks-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. Hukommelsessikkerhed og native kode - [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. Mobil kode og kørsel af ikke-betroet kode - [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. Deserialisering - [x] [Deserialization](https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html) (fordelt på python, ruby, php, java og dotnet) --- ## 23. Malware og trusler på klientsiden - [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. Logning, benægtelse og fejlhåndtering - [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. Forretningslogik og misbrug af funktionalitet Forretningslogik og misbrug af funktionalitet har ingen enkelt flade i koden, som en specialisering pr. flade kan forsvare: forsvaret er applikationsspecifikt design, efter samme ræsonnement som projektets trusselsmodellering. Flyttet til "Uden for omfanget". --- ## 26. Sikkerhed for AI, LLM og agenter - [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 og 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 og sprogplatforme - [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 og 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) (fordelt på access-control og browser) --- ## 30. API'er og tjenester - [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, containere og infrastruktur Konfigurationen af containere og workloads er configuration as code, som udvikleren leverer sammen med appen (`Dockerfile`, Compose, Pod-`securityContext`), en reel flade, som `harden` retter og `verify` påviser, så den er inden for omfanget. Administration af clusteret (RBAC, etcd, API-server, admission, netværkssegmentering) er driftens domæne og forbliver uden for omfanget. - [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: delen om workloads og pods. Administration af clusteret forbliver uden for omfanget) - [x] [Serverless / FaaS Security](https://cheatsheetseries.owasp.org/cheatsheets/Serverless_FaaS_Security_Cheat_Sheet.html) (serverless) --- ## 32. Forsyningskæde og 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 og konfiguration Håndtering af secrets er en driftsopgave: vaults, CI/CD, cloud-konfiguration, rotation. Det ene aspekt på kodeniveau (en secret, der er hardcodet i kildekoden) er en deterministisk scanning, ikke en risikospecialisering. Flyttet til "Uden for omfanget". --- ## 34. Proces, design og governance Beskyttelse af brugernes privatliv er politik og design (dataminimering, gennemsigtighed, opbevaring), ikke en flade i koden, som en specialisering forsvarer. Flyttet til "Uden for omfanget". --- ## 35. Betalinger og compliance - [x] [Secure Integration of Third-Party Payment Gateways](https://cheatsheetseries.owasp.org/cheatsheets/Third_Party_Payment_Gateway_Integration_Cheat_Sheet.html) (payment) --- ## 36. Indlejrede systemer, IoT og specialiserede domæner Sikkerhed i biler og droner hører til domænet for indlejrede systemer (CAN-bus, OTA-firmware, integritet af sensorer og radio, fysisk adgang), ikke til den kildekode i web- og API-applikationer, som Lagune gennemgår. Flyttet til "Uden for omfanget". --- ## Uden for omfanget (ingen flade i koden) Disse er ikke områder for specialiseringer og har ingen afkrydsningsboks: de handler om governance, processer, driftsmæssig hærdning eller brug af frameworks uden en enkelt flade i koden, som en specialisering pr. flade forsvarer. Deres sikkerhedsværdi er reel, men den ligger i processer og arkitektur (eller, for et framework, i det pågældende sprogs egen skill), ikke i et forsvar, som dette katalog leverer. De står her som reference, ikke som opgaver. - [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 via SOAP/WS-Addressing, en driftsmæssig DoS-variant uden flade i koden) - [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 hos slutbrugeren, ikke en flade i koden i det gennemgåede projekt. Aspektet med levering i browseren ligger i `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 og afvejninger: IAM over for signerede URL'er, offentlige og private VPC'er, tillidsgrænser, delt ansvar. I modsætning til `container` har det ingen konkret konfiguration, som en specialisering tjekker) - [Infrastructure as Code Security](https://cheatsheetseries.owasp.org/cheatsheets/Infrastructure_as_Code_Security_Cheat_Sheet.html) (trods navnet handler det om SDLC-processer og værktøjer til at _administrere_ IaC: IDE-plugins, statisk analyse, scanning af images, CI/CD, signering. Det viser ingen vej fra et usikkert mønster til en sikker form i en Terraform- eller CloudFormation-fil) - [Kubernetes Security](https://cheatsheetseries.owasp.org/cheatsheets/Kubernetes_Security_Cheat_Sheet.html) (_kun delen om administration af clusteret_: RBAC, etcd, API-server, admission. Delen om workloads og pods er inden for omfanget under `container`) - [Network Segmentation](https://cheatsheetseries.owasp.org/cheatsheets/Network_Segmentation_Cheat_Sheet.html) (netværksarkitektur og firewallpolitik) - [Subdomain Takeover Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Subdomain_Takeover_Prevention_Cheat_Sheet.html) (DNS-livscyklus og overvågning, ikke kode) - [Secrets Management](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html) (vaults, CI/CD, rotation. Aspektet med hardcodede secrets er en deterministisk scanning, ikke en risikospecialisering) - [C-Based Toolchain Hardening](https://cheatsheetseries.owasp.org/cheatsheets/C-Based_Toolchain_Hardening_Cheat_Sheet.html) (flag til compiler, linker og build, uden sink i kildekoden) - [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) (global konfiguration af fejlhåndtering pr. stak. Lækket er den samme afsløring, som fejlhåndteringen allerede styrer) - [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 _(historisk)_](https://cheatsheetseries.owasp.org/cheatsheets/Abuse_Case_Cheat_Sheet.html) (applikationsspecifikt design, ingen enkelt sink i koden) - [User Privacy Protection](https://cheatsheetseries.owasp.org/cheatsheets/User_Privacy_Protection_Cheat_Sheet.html) (dataminimering, gennemsigtighed, politik for opbevaring) - [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) (domæner for indlejrede systemer: CAN-bus, OTA-firmware, integritet af sensorer og radio, ikke kildekode til web eller API) - [Mobile Application Security](https://cheatsheetseries.owasp.org/cheatsheets/Mobile_Application_Security_Cheat_Sheet.html) (hærdning af platformene Android og iOS: lagring, biometri, pinning, personoplysninger. Det har ingen enkelt flade i koden, og aspektet med indlæsning af ikke-betroet kode gik til `interpreter`) - [Threat Modeling](https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html), [Threat Modeling _(community-side)_](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: Ret ødelagt sporing af fund > Reparér kæden, når en omdøbning eller en flyttet fil forvirrer sporingen i Lagune. Kanonisk URL: https://lagune.ai/da-DK/docs/commands/repair Sprog: da-DK Original: https://lagune.ai/docs/commands/repair Sidst opdateret: 2026-11-09 🧰 Reparér kæden, når en omdøbning eller en flyttet fil forvirrer den. **Intern vedligeholdelse, ikke en sikkerhedsfase** Repair er ikke en sjette fase i det lineære workflow. Dens opgave er at holde sporingen sammenhængende. ```prompt # Den tager intet input: den reparerer altid hele kæden /lagune-repair ``` ## Sådan virker det Hvert fund fra detect er ét sporet punkt, som plan, harden og verify fører videre, og hver af dem handler på det og rapporterer det igen ved navn. Det navn, skrevet ens som afsnitstitel i hvert artefakt, er dets identitet hele vejen igennem. Det eneste foranderlige, sporingen gemmer, er de filstier, punktet peger på. De stier findes ingen andre steder, så en omdøbning eller en flyttet fil kan kun bryde forbindelsen dér, aldrig i to kopier, der glider fra hinanden. Når det sker, retter repair kortet (`.lagune/tracking.json`), så identiteten overlever omdøbningen. Den læser artefakterne og sporingskortet, læser kun din kildekode for at finde en omdøbt fils nye sti og skriver aldrig sikkerhedsindhold. I samme gennemløb tjekker den hvert hukommelsesartefakt op mod dets skabelon og rapporterer, hvad der har flyttet sig, og peger hvert punkt mod den fase, der retter det. **Tip** - Den rører hverken din kode eller tekstartefakterne, kun sporingen. - Du kører den sjældent manuelt. Når en fase opdager, at kæden er inkonsistent, kører den repair for dig og fortsætter. - Den sporing, den vedligeholder, ligger i `.lagune/tracking.json`, en intern tilstand, du aldrig redigerer manuelt. --- # Migrate: Flyt et manifestbaseret Lagune-projekt til skills og plugins > Flyt et manifestbaseret Lagune-projekt til det skillsbaserede Lagune, og behold dine sikkerhedsprincipper, artefakter, sporing og egne specialiseringer. Kanonisk URL: https://lagune.ai/da-DK/docs/commands/migrate Sprog: da-DK Original: https://lagune.ai/docs/commands/migrate Sidst opdateret: 2026-11-09 🔀 Flyt et manifestbaseret projekt med **Lagune** til det skillsbaserede **Lagune**, og behold alt, hvad du har skrevet. **Meddelelse om udfasning** Et projekt med et manifest fortsætter med at virke, som det er, indtil `v1.x`: `npx lagune` sender `init`, `pull`, `update`, `add`, `remove`, `list` og dashboardet videre til `lagune@0.15.0`, den sidste manifestbaserede version. ## Flyt det 1. Sørg for, at dit nuværende arbejde er committet, og kør derefter migrate fra projektets rod: ```bash npx lagune migrate ``` 2. Commit kun det, den ændrede, så flytningen forbliver én ændring, der kan gennemses. 3. Installér kommandoerne til din agent, som [installationssiden](https://lagune.ai/da-DK/docs) viser. 4. Hvis projektet allerede har et artefakt fra detect, plan eller harden, så bed [`/lagune-repair`](https://lagune.ai/da-DK/docs/commands/repair) om at afstemme de gamle referencer i dem og i dine egne specialiseringer: ```prompt /lagune-repair Afstem de anvendte specialiseringer (tidligere sub-skills) i artefakterne under `.lagune/memory/` (`detect.md`, `plan.md` og `harden.md`) med de navne, det nye katalog oplister, og omskriv hvert kald, som mine egne specialiseringer i `.lagune/catalog/` laver til de gamle hooks i `.lagune/hooks/`, til et kald til værktøjet `lagune_read` eller `lagune_write`. ``` ## Hvad der ændrer sig | Før | Efter | | ---------------------------------------------------------------------- | ----------------------------------------------------------------------------------- | | `.lagune/templates/`, `.lagune/hooks/` og `.lagune/specializations.md` | Fjernet: hver skill har sin skabelon med, og motoren kører hooks | | Kopierne af de indbyggede specialiseringer i `.lagune/skills/` | Fjernet: motoren leverer de indbyggede | | Dine egne specialiseringer i `.lagune/skills/` | Flyttet til `.lagune/catalog/` | | `.lagune/skills.json`, indekset over dine egne specialiseringer | Flettet ind i `.lagune/configs.json` | | Manifestets kategorier | Registreret i `.lagune/configs.json` | | De gamle agentkommandoer, såsom `/lagune.detect` | Fjernet: [installationen af **Lagune**](https://lagune.ai/da-DK/docs) giver de nye, såsom `/lagune-detect` | | Blokken for **Lagune** i `.gitignore` | Fjernet, sammen med filen, når den ikke indeholdt andet | | `.lagune/proofs/`, ignoreret af den blok | Holdt ude af commits af sin egen `.gitignore` | | `.lagune/manifest.json` | Slettet, til sidst | Dit sikkerhedsarbejde forbliver, som det er: sikkerhedsprincipperne, det artefakt, hver fase har produceret, og sporingskortet med de stier, hvert fund peger på. ## Ofte stillede spørgsmål ### Skal jeg migrere? Ja. Manifestbaserede projekter er udfaset og virker kun indtil v1.x, så kør npx lagune migrate for at flytte dit. ### Hvad beholder migrate? Dine sikkerhedsprincipper, hvert faseartefakt, sporingskortet, dine kategorier og dine egne specialiseringer. Specialiseringerne flyttes til .lagune/catalog/, og deres indeks kommer ind sammen med dine kategorier i .lagune/configs.json. ### Hvornår installerer jeg de nye kommandoer? Efter migrate, som installationssiden viser for din agent. Det virker også at installere først, da migrate beholder den nye /lagune. ### En kollega har allerede migreret. Hvad skal jeg køre? Hent flytningen med pull, og kør derefter npx lagune migrate én gang. Den fjerner det, det manifestbaserede Lagune efterlod på din klon, som versionsstyringen aldrig har haft med, og holder dine beviser ude af commits.