# Lagune > Security-Driven Hardening for enhver kodebase Lagune er en kun defensiv arbeidsflyt med åpen kildekode for Security-Driven Hardening (SDH). Den hjelper KI-agenten din med å herde enhver kodebase, i alle språk, til enhver tid: fasen charter fastsetter sikkerhetsreglene før du bygger, den universelle kommandoen /lagune herder arbeidet mens det skrives, og Blue Team-flyten i fem faser oppdager hva systemet ditt faktisk gjør og driver frem utbedringene som betyr noe i den konteksten. Du installerer kommandoene i agenten din med CLI-en til skills, og det trengs ingen API-nøkkel. --- # Installasjon: sikkerhetsherding for alle KI-agenter > Installer Lagune i ethvert prosjekt, som plugin der agenten din støtter det og ellers med CLI-en til skills, og velg deretter sikkerhetsspesialiseringene som passer prosjektet. Kanonisk URL: https://lagune.ai/no-NO/docs Språk: no-NO Original: https://lagune.ai/docs Sist oppdatert: 2026-11-09 **Lagune** hjelper KI-agenten din med å gjøre et prosjekt sikrere. Du peker det mot koden din, og agenten finner ut hva systemet ditt faktisk gjør, og leder deg deretter gjennom sikkerhetsarbeidet som betyr noe for det. **Lagune** er det første prosjektet i metodikken [Security-Driven Hardening (SDH)](https://lagune.ai/no-NO/docs/references/paper). **Støtt åpen kildekode** Liker du **Lagune**? [Gi oss en ⭐ på **GitHub**](https://github.com/wellwelwel/lagune) ## Velg agenten din - [Claude Code](https://lagune.ai/no-NO/docs/install/claude-code): Det agentbaserte kodeverktøyet fra Anthropic - [Codex](https://lagune.ai/no-NO/docs/install/codex): Kodeagenten fra OpenAI - [Cursor](https://lagune.ai/no-NO/docs/install/cursor): Kodeeditoren med KI - [GitHub Copilot](https://lagune.ai/no-NO/docs/install/github-copilot-cli): KI-parprogrammereren fra GitHub - [Gemini CLI](https://lagune.ai/no-NO/docs/install/gemini-cli): Terminalagenten med åpen kildekode fra Google - [Antigravity](https://lagune.ai/no-NO/docs/install/antigravity-cli): Den agentbaserte utviklingsplattformen fra Google - [OpenCode](https://lagune.ai/no-NO/docs/install/opencode): Kodeagenten med åpen kildekode - [Devin for Terminal](https://lagune.ai/no-NO/docs/install/devin-cli): Terminalagenten fra Cognition - [Factory Droid](https://lagune.ai/no-NO/docs/install/factory-droid): Agenten for programvareutvikling fra Factory - [Grok Build](https://lagune.ai/no-NO/docs/install/grok-build): Kodeagenten fra xAI - [Qwen Code](https://lagune.ai/no-NO/docs/install/qwen-code): Kodeagenten for terminalen fra Qwen - [Kimi Code](https://lagune.ai/no-NO/docs/install/kimi-code): Kodeagenten fra Moonshot AI - [Muse Code](https://lagune.ai/no-NO/docs/install/muse-code): Kodeagenten fra Meta - [Pi](https://lagune.ai/no-NO/docs/install/pi): En minimalistisk kodeagent for terminalen - [Hermes Agent](https://lagune.ai/no-NO/docs/install/hermes-agent): Agenten med åpen kildekode fra Nous Research - [Universell](https://lagune.ai/no-NO/docs/install/universal): Cline, Kiro CLI, Windsurf, Zed og 66 til **Info** - **Lagune** kjører på **Node.js** i bakgrunnen, men du bruker det språket du vil. - Vil du kjøre helt offline, installerer du **Lagune** i prosjektet ditt med `npm i -D lagune@0.18.1`. ## Kategorier Sikkerhetskunnskapen i **Lagune** kommer som [**spesialiseringer**](https://lagune.ai/no-NO/docs/catalog), gruppert i [**kategorier**](https://lagune.ai/no-NO/docs/categories). - **OWASP** (`owasp`): Herd mot sikkerhetsrisikoene i applikasjoner som OWASP følger med på: injection, brutt tilgangskontroll og feil i autentisering og kryptografi - **Infrastruktur** (`infra`): Herd konfigurasjonen av containere, arbeidslaster og serverless: Dockerfile, Compose, Pod-sikkerhet, IAM og triggere for FaaS - **KI / LLM** (`ai`): Herd KI- og LLM-integrasjoner mot prompt injection og usikker kobling til verktøy, agenter, datahenting og MCP - **Lovable** (`lovable`): Herd KI-genererte Supabase-apper (Lovable og lignende): hull i RLS, lekkede nøkler for service_role og usikre standardinnstillinger - **JavaScript** (`javascript`): Herd JavaScript og kjøremiljøene mot RCE via eval og child_process, path traversal og prototype pollution - **Python** (`python`): Herd Python mot RCE via deserialisering med pickle og YAML, traversal via formatstrenger i str.format og class pollution - **Rust** (`rust`): Herd Rust mot usunne unsafe-API-er, feil bruk av transmute, heltallsoverflyt og udefinert oppførsel ved FFI-grensen - **Java** (`java`): Herd Java mot gadget chains ved deserialisering med ObjectInputStream som ender i fjernkjøring av kode - **Ruby** (`ruby`): Herd Ruby mot gadget chains ved deserialisering med Marshal.load og YAML som fører til fjernkjøring av kode - **PHP** (`php`): Herd PHP mot omgåelse av autentisering via type juggling, gadget chains via object injection og usikre standardinnstillinger i konfigurasjonen - **Go** (`go`): Herd Go mot typed nil-feil i interfaces, data races mellom goroutiner og usikker samtidighet i sikkerhetskritiske kodestier - **C / C++** (`c-cpp`): Herd C og C++ mot formatstrengfeil, bufferoverflyt og skriving utenfor minnegrensene som åpner for kodekjøring - **.NET** (`dotnet`): Herd .NET og C# mot RCE via deserialisering med BinaryFormatter og omgåelse av enkodere som fører til XSS Kjør `npx lagune write add --categories` med nøklene til kategoriene du velger. **Tips** Et prosjekt starter med `owasp`, og [`/lagune-charter`](https://lagune.ai/no-NO/docs/commands/charter) legger til kategoriene som vurderingen av prosjektet gir grunnlag for. ## Krav Du trenger [**Node.js (LTS)**](https://nodejs.org/en/download/package-manager) installert på systemet ditt. ## Bruk et merke ✨ Bruker du **Lagune**? Legg til et merke i **README**: **To farger** ![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) ``` **Ensfarget** ![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) ``` ## Neste steg Se hva hver av [**skillene**](https://lagune.ai/no-NO/docs/get-started/commands) i **Lagune** gjør. ## Vanlige spørsmål ### Hva er Lagune? Lagune er en arbeidsflyt med åpen kildekode for kun defensiv sikkerhet, som hjelper KI-agenten din med å herde enhver kodebase. Du peker det mot koden din, det oppdager hva systemet ditt faktisk gjør, og deretter leder det deg gjennom sikkerhetsutbedringene som betyr noe i den konteksten. ### Hvordan installerer jeg Lagune? Velg agenten din: 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 plugin, Gemini CLI og Qwen Code som utvidelse, Pi som pakke, og alle andre agenter med npx skills add wellwelwel/lagune. Det fungerer i nye og eksisterende prosjekter. ### Trenger Lagune en API-nøkkel? Nei. Det kjører gjennom din egen KI-agent, så du trenger ingen API-nøkler. ### Hvilke krav er det? Du trenger Node.js (LTS) installert på systemet ditt. ### Hvilke programmeringsspråk støtter Lagune? Alle. Lagune kjører på Node.js i bakgrunnen, men reviderer og herder prosjekter skrevet i alle programmeringsspråk. ### Hva legger Lagune til i prosjektet mitt? En mappe .lagune/ med sikkerhetstilstanden til prosjektet ditt, som den første kommandoen som skriver noe, oppretter. CLI-en til skills installerer også skråstrekkommandoene i prosjektet, der agenten din leser dem, mens en plugin holder dem inne i agenten. ### Hvordan oppdaterer jeg Lagune? På samme måte som du installerte det. Installasjonssiden for hver agent viser hvordan du oppdaterer Lagune der, og CLI-en til skills oppdaterer det med npx skills update. Sikkerhetsprinsippene dine, artefaktene fra fasene og dine egne spesialiseringer forblir urørt. ### Hvilke spesialiseringer bruker et prosjekt? De innebygde i kategoriene prosjektet har, pluss sine egne. Fasen charter registrerer kategoriene som vurderingen av prosjektet gir grunnlag for, og npx lagune write add --categories endrer dem. ### Må jeg bli ferdig med å bygge før jeg sikrer prosjektet mitt? Nei. Kommandoen /lagune herder arbeidet mens det skrives: Den tar imot en hvilken som helst prompt, bygger det du ba om, og herder det med sikre standardinnstillinger, veiledet av sikkerhetsprinsippene. Blue Team-flyten i fem faser reviderer det som allerede finnes. ### Kan Lagune revidere et eksisterende prosjekt? Ja. Blue Team-flyten i fem faser reviderer det som allerede finnes: charter fastsetter sikkerhetsreglene dine, detect kartlegger hva systemet gjør og hvor risikoene ligger, plan vurderer hvert funn og kobler det til en utbedring, harden tar i bruk utbedringene, og verify beviser at de holder, og lukker dem. ### Hva er forskjellen på å bruke Lagune og å bare be agenten kartlegge sårbarheter og sikkerhetshull? En agent som leser på egen hånd, finner det som ser ut som en sårbarhet, og hopper over det som ser ut som et sikringstiltak. En liste over blokkerte adresser ser ut som om noen allerede har håndtert risikoen, så ingen sjekker at den mangler de fleste av dem, og koden går i produksjon. Lagune snur denne standarden: Et vern som allerede finnes i koden, regnes som ubevist til det er sjekket, hver spesialisering i katalogen får en eksplisitt konklusjon, og verify spør om risikoen er borte, ikke om et sikringstiltak er der. Hvert funn forblir dessuten ett sporet element på tvers av kjøringer, slik at det kan bevises lukket og tas ut, mens en vanlig forespørsel gir deg en ny rapport hver gang, uten noe å sammenligne med. ### Hva er forskjellen på å utvikle med Lagune og å bare be agenten skrive sikker kode? Ber du om sikker kode, overlater du til agenten å avgjøre hva sikker betyr, og det forutsetter at du vet hva du skal be om. Kravet ligger som regel allerede i forespørselen din uten at noen av dere ser det: Ber du om en side som viser kursene en bruker har tilgang til, uttrykker du en autorisasjonsregel, og en sjekk som aldri blir skrevet, etterlater ingenting i koden som kan legges merke til. Kommandoen /lagune laster inn sikkerhetsprinsippene dine og spesialiseringene som passer til det som skal bygges, før den første linjen er skrevet, og leser deretter resultatet på nytt opp mot forsvaret den brukte. Den sikre løsningen koster sjelden mer enn den usikre, så det som avgjør utfallet, er å vite hvilken du skal velge, og nettopp det får du på forhånd. ### Kjører Lagune DAST (Dynamic Application Security Testing) eller tester det applikasjonen min mens den kjører? Nei. Lagune leser kode og kjører aldri systemet ditt eller sender det manipulerte forespørsler. Fasen verify bekrefter at et sikringstiltak finnes og er riktig i kildekoden, og det er et annet spørsmål enn om det tåler et angrep mot et live mål, så "cannot tell from the code" er en legitim konklusjon i stedet for en stille godkjenning. DAST besvarer spørsmålet om kjøretiden og Lagune spørsmålet om kildekoden, så ingen av dem erstatter den andre. Selv den valgfrie kommandoen prove holder seg innenfor denne grensen: Testene dens bekrefter den sikre oppførselen, aldri en angreps-payload. ### Erstatter Lagune en pentest (penetrasjonstest)? Nei, absolutt ikke! En pentest er et autorisert oppdrag der en fagperson bruker eget skjønn mot det kjørende systemet ditt, kobler sammen funn og undersøker forretningslogikken som ingen regel per angrepsflate beskriver. Funn fra en pentest kan gå inn i Blue Team-flyten i Lagune som problemstillinger du gir til detect, slik at det en fagperson rapporterer, blir planlagt, herdet og verifisert. ## Sikkerhetspolicy Se [SECURITY.md](https://github.com/wellwelwel/lagune/blob/main/SECURITY.md). ## Lisens **Lagune** er lisensiert under [Apache License 2.0](https://github.com/wellwelwel/lagune/blob/main/LICENSE). Copyright © 2026-i dag [Weslley Araújo](https://github.com/wellwelwel) og [bidragsytere](https://github.com/wellwelwel/lagune/graphs/contributors). --- # Installer Lagune som plugin i Antigravity CLI > Installer Lagune som plugin i Antigravity CLI, hold den oppdatert og tillat motoren på forhånd. Kanonisk URL: https://lagune.ai/no-NO/docs/install/antigravity-cli Språk: no-NO Original: https://lagune.ai/docs/install/antigravity-cli Sist oppdatert: 2026-11-09 Installer pluginen fra terminalen: ```bash agy plugin install https://github.com/wellwelwel/lagune/tree/plugin-antigravity ``` ## Oppdatering Oppdater **Lagune** ved å installere den på nytt: ```bash agy plugin install https://github.com/wellwelwel/lagune/tree/plugin-antigravity ``` ## Kommandoer Skriv kommandoene med navnet på pluginen foran, for eksempel `/lagune:lagune-charter` for `/lagune-charter`. --- **Tillatelser** Motoren kjører via to verktøy: `lagune_read` leser bare prosjektet ditt, og `lagune_write` skriver bare til `.lagune/`. En kommando som sendes som første melding i en økt, kjører før verktøyene er lastet inn, og bruker derfor **npx** i stedet. Du tillater verktøyene og **npx** på forhånd ved å legge til disse reglene i `~/.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.]+)" ] } } ``` ## Vanlige spørsmål ### Hvordan installerer jeg Lagune i Antigravity CLI? Kjør agy plugin install https://github.com/wellwelwel/lagune/tree/plugin-antigravity. ### Hvordan oppdaterer jeg Lagune i Antigravity CLI? Kjør agy plugin install https://github.com/wellwelwel/lagune/tree/plugin-antigravity på nytt. ### Hvordan kjører jeg kommandoene til Lagune i Antigravity CLI? Skriv dem med navnet på pluginen foran, for eksempel /lagune:lagune-charter. ### Kan Antigravity CLI kjøre Lagune uten å be om tillatelse? Ja. Tillat mcp(lagune_lagune/lagune_read), mcp(lagune_lagune/lagune_write) og command(regex:npx --yes lagune@[0-9.]+) i innstillingene for Antigravity CLI. Regelen for npx dekker en kommando som sendes som første melding i en økt. --- # Installer Lagune som plugin i Claude Code > Installer Lagune som plugin i Claude Code, i terminalen, utvidelsen eller skrivebordsappen, hold den oppdatert og tillat motoren på forhånd. Kanonisk URL: https://lagune.ai/no-NO/docs/install/claude-code Språk: no-NO Original: https://lagune.ai/docs/install/claude-code Sist oppdatert: 2026-11-09 **Terminal** Installer pluginen fra terminalen: ```bash claude plugin install lagune --marketplace wellwelwel/lagune ``` Eller fra en økt i **Claude Code**: ```text /plugin marketplace add wellwelwel/lagune /plugin install lagune@lagune ``` **Utvidelse** - Skriv `/plugin` og velg **Manage plugins**. - Legg til `wellwelwel/lagune` i fanen **Marketplaces**. - Installer `lagune` i fanen **Plugins**. **Skrivebord** - Installer **Lagune** fra terminalen eller utvidelsen, og velg **Install for you** i utvidelsen. - Start en ny økt i skrivebordsappen, som laster inn pluginene du installerer for deg selv. ## Oppdatering **Terminal** Oppdater **Lagune** ved å kjøre: ```bash claude plugin marketplace update lagune claude plugin update lagune@lagune ``` For automatisk oppdatering velger du **Enable auto-update** for markedsplassen `lagune` under `/plugin`. **Utvidelse** - Skriv `/plugin` og velg **Manage plugins**. - Åpne fanen **Marketplaces**. - Velg oppdateringsikonet på `lagune`. **Skrivebord** - Oppdater **Lagune** fra terminalen eller utvidelsen. - Start en ny økt i skrivebordsappen. ## Kommandoer Skriv kommandoene med navnet deres, for eksempel `/lagune-charter`, eller med navnet på pluginen foran, for eksempel `/lagune:lagune-charter`. --- **Tillatelser** Motoren kjører via to verktøy: `lagune_read` leser bare prosjektet ditt, og `lagune_write` skriver bare til `.lagune/`. Du tillater dem på forhånd ved å legge til disse reglene i `.claude/settings.json` for ett prosjekt, eller i `~/.claude/settings.json` for alle prosjektene: ```json { "permissions": { "allow": [ "mcp__plugin_lagune_lagune__lagune_read", "mcp__plugin_lagune_lagune__lagune_write" ] } } ``` Når motoren kjører via **npx**, som med **skills.sh**, tillater du `Bash(npx --yes lagune@*)`. Er sandkassen slått på, legger du også til `registry.npmjs.org` i `sandbox.network.allowedDomains`. ## Vanlige spørsmål ### Hvordan installerer jeg Lagune i Claude Code? Kjør claude plugin install lagune --marketplace wellwelwel/lagune. I en økt eller i utvidelsen legger du til markedsplassen wellwelwel/lagune fra pluginbehandleren og installerer lagune. Skrivebordsappen laster den inn så snart du har installert den for deg selv i terminalen eller utvidelsen. ### Hvordan oppdaterer jeg Lagune i Claude Code? Kjør claude plugin marketplace update lagune og deretter claude plugin update lagune@lagune, eller velg Enable auto-update for markedsplassen lagune under /plugin. I utvidelsen åpner du Manage plugins fra /plugin og velger oppdateringsikonet på markedsplassen lagune. Skrivebordsappen laster inn oppdateringen i neste økt. ### Hvordan kjører jeg kommandoene til Lagune i Claude Code? Skriv dem med navnet deres, for eksempel /lagune-charter, eller med navnet på pluginen foran, for eksempel /lagune:lagune-charter. ### Kan Claude Code kjøre Lagune uten å be om tillatelse? Ja. Tillat mcp__plugin_lagune_lagune__lagune_read og mcp__plugin_lagune_lagune__lagune_write i innstillingene for Claude Code, og i tillegg Bash(npx --yes lagune@*) når motoren kjører via npx. --- # Installer Lagune som plugin i Codex CLI > Installer Lagune som plugin i Codex CLI, hold den oppdatert og kjør motoren i sandkassen. Kanonisk URL: https://lagune.ai/no-NO/docs/install/codex Språk: no-NO Original: https://lagune.ai/docs/install/codex Sist oppdatert: 2026-11-09 Installer pluginen fra terminalen: ```bash codex plugin marketplace add wellwelwel/lagune codex plugin add lagune@lagune ``` ## Oppdatering Oppdater **Lagune** ved å kjøre: ```bash codex plugin marketplace upgrade lagune ``` ## Kommandoer Skriv `$` og kommandoen med navnet på pluginen foran, etterfulgt av teksten din, for eksempel `$lagune:lagune-charter` for `/lagune-charter`. Når du skriver `$`, vises en liste over kommandoene, og velger du én, settes hele navnet inn. --- **Sandkasse** Sandkassen i **Codex** har ingen nettverkstilgang. Installer motoren i prosjektet ditt fra din egen terminal, én gang og etter hver oppdatering: ```bash npm i -D lagune@0.18.1 ``` ## Vanlige spørsmål ### Hvordan installerer jeg Lagune i Codex CLI? Kjør codex plugin marketplace add wellwelwel/lagune og deretter codex plugin add lagune@lagune. ### Hvordan oppdaterer jeg Lagune i Codex CLI? Kjør codex plugin marketplace upgrade lagune. ### Hvordan kjører jeg kommandoene til Lagune i Codex CLI? Skriv $ og kommandoen med navnet på pluginen foran, etterfulgt av teksten din, for eksempel $lagune:lagune-charter. ### Fungerer Lagune i sandkassen til Codex? Ja, når du har installert motoren i prosjektet ditt med npm i -D lagune@0.18.1 fra din egen terminal, én gang og etter hver oppdatering. --- # Installer Lagune som plugin i Cursor > Installer Lagune som plugin i Cursor og Cursor CLI, hold den oppdatert og tillat motoren på forhånd. Kanonisk URL: https://lagune.ai/no-NO/docs/install/cursor Språk: no-NO Original: https://lagune.ai/docs/install/cursor Sist oppdatert: 2026-11-09 **Cursor** - Åpne **Customize**. - Velg **From GitHub Repository** og skriv inn `https://github.com/wellwelwel/lagune`. - Velg **Install** på **Lagune**, og velg prosjekt- eller brukeromfang. **Cursor CLI** - Legg til markedsplassen fra terminalen: ```bash agent plugin marketplace add https://github.com/wellwelwel/lagune --git-ref plugin-cursor ``` - Skriv `/plugins` i en økt med `agent`. - Installer **Lagune**. Er **Lagune** allerede installert i **Claude Code**, laster **Cursor CLI** den inn derfra. ## Oppdatering **Cursor** - Åpne **Customize**. - Velg **Refresh** på markedsplassen `lagune`. **Cursor CLI** - Bytt ut markedsplassen fra terminalen: ```bash agent plugin marketplace remove lagune agent plugin marketplace add https://github.com/wellwelwel/lagune --git-ref plugin-cursor ``` - Skriv `/plugins` i en økt med `agent`. - Installer **Lagune** på nytt. ## Kommandoer Skriv kommandoene med navnet deres, for eksempel `/lagune-charter`. --- **Tillatelser** I **Cursor** kjører kommandoene motoren via **npx**, noe standardmodusen Auto-review tillater uten å spørre. I **Cursor CLI** kjører motoren via to verktøy: `lagune_read` leser bare prosjektet ditt, og `lagune_write` skriver bare til `.lagune/`. Du tillater dem på forhånd ved å legge til disse reglene i `.cursor/cli.json` for ett prosjekt, eller i `~/.cursor/cli-config.json` for alle prosjektene: ```json { "permissions": { "allow": [ "Mcp(plugin-lagune-lagune:lagune_read)", "Mcp(plugin-lagune-lagune:lagune_write)" ] } } ``` Når motoren kjører via **npx**, som med **skills.sh**, tillater du `Shell(npx:--yes lagune@*)`. ## Vanlige spørsmål ### Hvordan installerer jeg Lagune i Cursor? Åpne Customize i Cursor, velg From GitHub Repository, skriv inn https://github.com/wellwelwel/lagune og installer Lagune. I Cursor CLI kjører du agent plugin marketplace add https://github.com/wellwelwel/lagune --git-ref plugin-cursor og installerer deretter Lagune fra /plugins. ### Hvordan oppdaterer jeg Lagune i Cursor? Velg Refresh på markedsplassen lagune under Customize i Cursor. I Cursor CLI fjerner du markedsplassen lagune, legger den til på nytt og installerer deretter Lagune på nytt fra /plugins. ### Hvordan kjører jeg kommandoene til Lagune i Cursor? Skriv dem med navnet deres, for eksempel /lagune-charter. ### Kan Cursor kjøre Lagune uten å be om tillatelse? Ja. Standardmodusen Auto-review i Cursor tillater det allerede. I Cursor CLI tillater du Mcp(plugin-lagune-lagune:lagune_read) og Mcp(plugin-lagune-lagune:lagune_write), og i tillegg Shell(npx:--yes lagune@*) når motoren kjører via npx. --- # Installer Lagune som plugin i Devin CLI > Installer Lagune som plugin i Devin CLI og hold den oppdatert. Kanonisk URL: https://lagune.ai/no-NO/docs/install/devin-cli Språk: no-NO Original: https://lagune.ai/docs/install/devin-cli Sist oppdatert: 2026-11-09 Logg inn på **Devin**, og installer deretter pluginen fra terminalen: ```bash devin auth login devin plugins install wellwelwel/lagune ``` ## Oppdatering Oppdater **Lagune** ved å kjøre: ```bash devin plugins update lagune ``` ## Kommandoer Skriv kommandoene med navnet på pluginen foran, for eksempel `/lagune:lagune-charter` for `/lagune-charter`. Menyen `/` viser dem også. ## Vanlige spørsmål ### Hvordan installerer jeg Lagune i Devin CLI? Logg inn med devin auth login, og kjør deretter devin plugins install wellwelwel/lagune. ### Hvordan oppdaterer jeg Lagune i Devin CLI? Kjør devin plugins update lagune. ### Hvordan kjører jeg kommandoene til Lagune i Devin CLI? Skriv dem med navnet på pluginen foran, for eksempel /lagune:lagune-charter. Menyen / viser dem også. --- # Installer Lagune som plugin i Factory Droid > Installer Lagune som plugin i Factory Droid, hold den oppdatert og tillat verktøyene til motoren. Kanonisk URL: https://lagune.ai/no-NO/docs/install/factory-droid Språk: no-NO Original: https://lagune.ai/docs/install/factory-droid Sist oppdatert: 2026-11-09 Installer pluginen fra terminalen: ```bash droid plugin marketplace add wellwelwel/lagune droid plugin install lagune@lagune ``` ## Oppdatering Oppdater **Lagune** ved å kjøre: ```bash droid plugin marketplace update lagune droid plugin update lagune@lagune ``` ## Kommandoer Skriv kommandoene med navnet deres, for eksempel `/lagune-charter`. ## Vanlige spørsmål ### Hvordan installerer jeg Lagune i Factory Droid? Kjør droid plugin marketplace add wellwelwel/lagune og deretter droid plugin install lagune@lagune. ### Hvordan oppdaterer jeg Lagune i Factory Droid? Kjør droid plugin marketplace update lagune og deretter droid plugin update lagune@lagune. ### Hvordan kjører jeg kommandoene til Lagune i Factory Droid? Skriv dem med navnet deres, for eksempel /lagune-charter. ### Kan Factory Droid kjøre Lagune uten å be om tillatelse? Ja. Velg å alltid tillate lagune_read og lagune_write når Factory Droid spør. Den spør på nytt etter at en ny commit av markedsplassen lagune er synkronisert. --- # Installer Lagune som utvidelse i Gemini CLI > Installer Lagune som utvidelse i Gemini CLI, hold den oppdatert og tillat motoren på forhånd. Kanonisk URL: https://lagune.ai/no-NO/docs/install/gemini-cli Språk: no-NO Original: https://lagune.ai/docs/install/gemini-cli Sist oppdatert: 2026-11-09 Installer utvidelsen fra terminalen: ```bash gemini extensions install https://github.com/wellwelwel/lagune ``` ## Oppdatering Oppdater **Lagune** ved å kjøre: ```bash gemini extensions update lagune ``` For automatisk oppdatering installerer du den med `--auto-update`. ## Kommandoer Skriv kommandoene med navnet på utvidelsen foran, for eksempel `/lagune:lagune-charter` for `/lagune-charter`. --- **Tillatelser** Motoren kjører via to verktøy: `lagune_read` leser bare prosjektet ditt, og `lagune_write` skriver bare til `.lagune/`. **Gemini CLI** starter dem bare i en klarert mappe. Du tillater dem på forhånd ved å lagre denne regelen som `~/.gemini/policies/lagune.toml`: ```toml [[rule]] mcpName = "lagune" toolName = ["lagune_read", "lagune_write"] decision = "allow" priority = 100 ``` Når motoren kjører via **npx**, som med **skills.sh**, legger du til denne regelen i samme fil: ```toml [[rule]] toolName = "run_shell_command" commandRegex = 'npx --yes lagune@\d+\.\d+\.\d+\s' decision = "allow" priority = 100 ``` ## Vanlige spørsmål ### Hvordan installerer jeg Lagune i Gemini CLI? Kjør gemini extensions install https://github.com/wellwelwel/lagune. ### Hvordan oppdaterer jeg Lagune i Gemini CLI? Kjør gemini extensions update lagune, eller installer utvidelsen med --auto-update. ### Hvordan kjører jeg kommandoene til Lagune i Gemini CLI? Skriv dem med navnet på utvidelsen foran, for eksempel /lagune:lagune-charter. ### Kan Gemini CLI kjøre Lagune uten å be om tillatelse? Ja. Legg til en policyregel som tillater verktøyene til serveren lagune, lagune_read og lagune_write, og i tillegg en regel for run_shell_command med npx --yes lagune@ og en versjon når motoren kjører via npx. --- # Installer Lagune som plugin i GitHub Copilot CLI > Installer Lagune som plugin i GitHub Copilot CLI og hold det oppdatert. Kanonisk URL: https://lagune.ai/no-NO/docs/install/github-copilot-cli Språk: no-NO Original: https://lagune.ai/docs/install/github-copilot-cli Sist oppdatert: 2026-11-09 Installer pluginen fra terminalen: ```bash copilot plugin marketplace add wellwelwel/lagune copilot plugin install lagune@lagune ``` I en editor installerer du **Lagune** for **GitHub Copilot** med [**skills.sh**](https://lagune.ai/no-NO/docs/install/universal). ## Oppdatering Kjør følgende for å oppdatere **Lagune**: ```bash copilot plugin marketplace update lagune copilot plugin update lagune@lagune ``` ## Kommandoer Skriv inn kommandoene med navn, for eksempel `/lagune-charter`. ## Vanlige spørsmål ### Hvordan installerer jeg Lagune i GitHub Copilot CLI? Kjør copilot plugin marketplace add wellwelwel/lagune, deretter copilot plugin install lagune@lagune. ### Hvordan oppdaterer jeg Lagune i GitHub Copilot CLI? Kjør copilot plugin marketplace update lagune, deretter copilot plugin update lagune@lagune. ### Hvordan kjører jeg kommandoene til Lagune i GitHub Copilot CLI? Skriv dem inn med navn, for eksempel /lagune-charter. ### Kan jeg bruke Lagune med GitHub Copilot i VS Code? Ja. I VS Code eller en annen editor installerer du Lagune med skills.sh i stedet for pluginen. --- # Installer Lagune som plugin i Grok Build > Installer Lagune som plugin i Grok Build, hold det oppdatert og gi motoren tillatelse på forhånd. Kanonisk URL: https://lagune.ai/no-NO/docs/install/grok-build Språk: no-NO Original: https://lagune.ai/docs/install/grok-build Sist oppdatert: 2026-11-09 Installer pluginen fra terminalen: ```bash grok plugin install wellwelwel/lagune@plugin-grok --trust ``` ## Oppdatering Kjør følgende for å oppdatere **Lagune**: ```bash grok plugin update lagune ``` ## Kommandoer Skriv inn kommandoene med navn, for eksempel `/lagune-charter`, eller med navnet på pluginen foran, for eksempel `/lagune:lagune-charter`. --- **Tillatelser** Motoren kjører gjennom to verktøy: `lagune_read` leser bare prosjektet ditt, og `lagune_write` skriver bare til `.lagune/`. For å tillate dem på forhånd legger du til disse reglene i `~/.grok/config.toml`: ```toml [permission] allow = ["MCPTool(lagune__lagune_read)", "MCPTool(lagune__lagune_write)"] ``` Når motoren kjører via **npx**, som med **skills.sh**, tillater du også `Bash(npx --yes lagune@*)`. ## Vanlige spørsmål ### Hvordan installerer jeg Lagune i Grok Build? Kjør grok plugin install wellwelwel/lagune@plugin-grok --trust. ### Hvordan oppdaterer jeg Lagune i Grok Build? Kjør grok plugin update lagune. ### Hvordan kjører jeg kommandoene til Lagune i Grok Build? Skriv dem inn med navn, for eksempel /lagune-charter, eller med navnet på pluginen foran, for eksempel /lagune:lagune-charter. ### Kan Grok Build kjøre Lagune uten å be om tillatelse? Ja. Tillat MCPTool(lagune__lagune_read) og MCPTool(lagune__lagune_write) i konfigurasjonen til Grok Build, og i tillegg Bash(npx --yes lagune@*) når motoren kjører via npx. --- # Installer Lagune som plugin i Hermes Agent > Installer Lagune som plugin i Hermes Agent og hold det oppdatert. Kanonisk URL: https://lagune.ai/no-NO/docs/install/hermes-agent Språk: no-NO Original: https://lagune.ai/docs/install/hermes-agent Sist oppdatert: 2026-11-09 Installer pluginen fra terminalen: ```bash hermes plugins install wellwelwel/lagune --enable ``` - Når **Hermes Agent** ber deg bekrefte en plugin utenfor katalogen sin, **bekreft den**. - Når den tilbyr å installere avhengighetene for **Node.js** i repositoryet, **avslå**. ## Oppdatering Kjør følgende for å oppdatere **Lagune**: ```bash hermes plugins update lagune ``` ## Kommandoer Skriv inn kommandoene med navnet på pluginen foran, for eksempel `/lagune:lagune-charter` for `/lagune-charter` og `/lagune:lagune` for `/lagune`. ## Vanlige spørsmål ### Hvordan installerer jeg Lagune i Hermes Agent? Kjør hermes plugins install wellwelwel/lagune --enable. Bekreft pluginen når du blir spurt, og avslå å installere avhengighetene for Node.js i repositoryet. ### Hvordan oppdaterer jeg Lagune i Hermes Agent? Kjør hermes plugins update lagune. ### Hvordan kjører jeg kommandoene til Lagune i Hermes Agent? Skriv dem inn med navnet på pluginen foran, for eksempel /lagune:lagune-charter og /lagune:lagune. --- # Installer Lagune som plugin i Kimi Code > Installer Lagune som plugin i Kimi Code og hold det oppdatert. Kanonisk URL: https://lagune.ai/no-NO/docs/install/kimi-code Språk: no-NO Original: https://lagune.ai/docs/install/kimi-code Sist oppdatert: 2026-11-09 Installer pluginen fra en økt i **Kimi Code**, velg **Trust and install**, og start deretter en ny økt for å laste den inn: ```text /plugins install https://github.com/wellwelwel/lagune /new ``` ## Oppdatering Installer **Lagune** på nytt for å oppdatere det: ```text /plugins install https://github.com/wellwelwel/lagune /new ``` ## Kommandoer Skriv inn kommandoene med navnet på pluginen foran, for eksempel `/lagune:lagune-charter` for `/lagune-charter`. Menyen `/` viser dem som `/skill:lagune:lagune-charter`, og det fungerer også. ## Vanlige spørsmål ### Hvordan installerer jeg Lagune i Kimi Code? Kjør /plugins install https://github.com/wellwelwel/lagune i en økt i Kimi Code, velg Trust and install, og kjør deretter /new. ### Hvordan oppdaterer jeg Lagune i Kimi Code? Kjør /plugins install https://github.com/wellwelwel/lagune på nytt, deretter /new. ### Hvordan kjører jeg kommandoene til Lagune i Kimi Code? Skriv dem inn med navnet på pluginen foran, for eksempel /lagune:lagune-charter, eller slik menyen / viser dem, for eksempel /skill:lagune:lagune-charter. --- # Installer Lagune som plugin i Muse Code > Installer Lagune som plugin i Muse Code, hold det oppdatert og kjør motoren i sandkassen. Kanonisk URL: https://lagune.ai/no-NO/docs/install/muse-code Språk: no-NO Original: https://lagune.ai/docs/install/muse-code Sist oppdatert: 2026-11-09 Installer pluginen fra terminalen: ```bash muse plugins marketplace add lagune wellwelwel/lagune muse plugins install lagune@lagune ``` ## Oppdatering Frisk opp markedsplassen og installer pluginen på nytt for å oppdatere **Lagune**: ```bash muse plugins marketplace update lagune muse plugins remove lagune muse plugins install lagune@lagune ``` ## Kommandoer Skriv inn kommandoene med navn, for eksempel `/lagune-charter`, eller med navnet på pluginen foran, for eksempel `/lagune:lagune-charter`. --- **Sandkasse** Sandkassen i **Muse Code** kan ikke laste ned motoren. Installer den i prosjektet ditt fra din egen terminal, først én gang og deretter etter hver oppdatering: ```bash npm i -D lagune@0.18.1 ``` ## Vanlige spørsmål ### Hvordan installerer jeg Lagune i Muse Code? Kjør muse plugins marketplace add lagune wellwelwel/lagune, deretter muse plugins install lagune@lagune. ### Hvordan oppdaterer jeg Lagune i Muse Code? Kjør muse plugins marketplace update lagune, og installer deretter på nytt med muse plugins remove lagune og muse plugins install lagune@lagune. ### Hvordan kjører jeg kommandoene til Lagune i Muse Code? Skriv dem inn med navn, for eksempel /lagune-charter, eller med navnet på pluginen foran, for eksempel /lagune:lagune-charter. ### Fungerer Lagune i sandkassen til Muse Code? Ja, når du installerer motoren i prosjektet ditt med npm i -D lagune@0.18.1 fra din egen terminal, først én gang og deretter etter hver oppdatering. --- # Installer Lagune som plugin i OpenCode > Installer Lagune som plugin i OpenCode 1.x og 2.x og hold det oppdatert. Kanonisk URL: https://lagune.ai/no-NO/docs/install/opencode Språk: no-NO Original: https://lagune.ai/docs/install/opencode Sist oppdatert: 2026-11-09 **OpenCode 2.x** Installer pluginen fra terminalen: ```bash opencode plugin add lagune ``` Eller legg den til i listen `plugins` i `opencode.json`: ```json { "plugins": ["lagune"] } ``` **OpenCode 1.x** Installer pluginen i prosjektet ditt fra terminalen, eller legg til `-g` for å installere den for alle prosjektene dine: ```bash opencode plugin lagune ``` Eller legg den til i listen `plugin` i `opencode.json`: ```json { "plugin": ["lagune"] } ``` ## Oppdatering **OpenCode 2.x** Kjør følgende for å oppdatere **Lagune**: ```bash opencode plugin update lagune opencode reload ``` **OpenCode 1.x** Installer den nye versjonen over den gamle for å oppdatere **Lagune**, og legg til `-g` hvis du installerte den for alle prosjektene dine: ```bash opencode plugin lagune@0.18.1 --force ``` ## Kommandoer **OpenCode 2.x** Skriv `@` og velg kommandoen, for eksempel `@lagune-charter`, og skriv deretter teksten din i samme melding. **OpenCode 1.x** Skriv inn kommandoene med navn, for eksempel `/lagune-charter`. De står oppført under `/skills`, ikke i menyen `/`. ## Vanlige spørsmål ### Hvordan installerer jeg Lagune i OpenCode? I OpenCode 2.x kjører du opencode plugin add lagune. I OpenCode 1.x kjører du opencode plugin lagune, og legger til -g for å installere den for alle prosjektene dine. ### Hvordan oppdaterer jeg Lagune i OpenCode? I OpenCode 2.x kjører du opencode plugin update lagune, deretter opencode reload. I OpenCode 1.x kjører du opencode plugin lagune@0.18.1 --force. ### Hvordan kjører jeg kommandoene til Lagune i OpenCode? I OpenCode 2.x skriver du @ og velger kommandoen, for eksempel @lagune-charter, og skriver deretter teksten din i samme melding. I OpenCode 1.x skriver du dem inn med navn, for eksempel /lagune-charter, eller finner dem under /skills. ### Ber OpenCode om tillatelse før Lagune kjører? Nei. OpenCode kjører de to verktøyene til motoren, lagune_read og lagune_write, uten å spørre. --- # Installer Lagune som pakke i Pi > Installer Lagune som pakke i Pi, fra npm eller GitHub, og hold det oppdatert. Kanonisk URL: https://lagune.ai/no-NO/docs/install/pi Språk: no-NO Original: https://lagune.ai/docs/install/pi Sist oppdatert: 2026-11-09 **npm** Installer pakken fra terminalen: ```bash pi install npm:lagune ``` **GitHub** Installer den nyeste commiten fra **GitHub**, som kjører motoren via **npx**: ```bash pi install git:github.com/wellwelwel/lagune ``` ## Oppdatering **npm** Kjør følgende for å oppdatere **Lagune**: ```bash pi update npm:lagune ``` **GitHub** Kjør følgende for å oppdatere **Lagune**: ```bash pi update git:github.com/wellwelwel/lagune ``` `pi update --extensions` oppdaterer alle pakkene du har installert, mens `pi update` alene bare oppdaterer **Pi**. ## Kommandoer Skriv inn kommandoene med prefikset `skill:`, for eksempel `/skill:lagune-charter` for `/lagune-charter`. ## Vanlige spørsmål ### Hvordan installerer jeg Lagune i Pi? Kjør pi install npm:lagune, eller pi install git:github.com/wellwelwel/lagune for den nyeste commiten fra GitHub. ### Hvordan oppdaterer jeg Lagune i Pi? Kjør pi update npm:lagune, eller pi update git:github.com/wellwelwel/lagune for en installasjon fra GitHub. pi update --extensions oppdaterer alle pakkene du har installert. ### Hvordan kjører jeg kommandoene til Lagune i Pi? Skriv dem inn med prefikset skill:, for eksempel /skill:lagune-charter. --- # Installer Lagune som utvidelse i Qwen Code > Installer Lagune som utvidelse i Qwen Code, hold det oppdatert og gi motoren tillatelse på forhånd. Kanonisk URL: https://lagune.ai/no-NO/docs/install/qwen-code Språk: no-NO Original: https://lagune.ai/docs/install/qwen-code Sist oppdatert: 2026-11-09 Installer utvidelsen fra terminalen: ```bash qwen extensions install lagune ``` ## Oppdatering Kjør følgende for å oppdatere **Lagune**: ```bash qwen extensions update lagune ``` Installer utvidelsen med `--auto-update` for å holde den oppdatert. ## Kommandoer Skriv inn kommandoene med navnet på utvidelsen foran, for eksempel `/lagune:lagune-charter` for `/lagune-charter`. --- **Tillatelser** Motoren kjører gjennom to verktøy: `lagune_read` leser bare prosjektet ditt, og `lagune_write` skriver bare til `.lagune/`. For å tillate dem på forhånd legger du til disse reglene i `.qwen/settings.json` for ett prosjekt, eller i `~/.qwen/settings.json` for alle prosjektene dine: ```json { "permissions": { "allow": ["mcp__lagune__lagune_read", "mcp__lagune__lagune_write"] } } ``` Når motoren kjører via **npx**, som med **skills.sh**, tillater du også `Shell(npx --yes lagune@*)`. ## Vanlige spørsmål ### Hvordan installerer jeg Lagune i Qwen Code? Kjør qwen extensions install lagune. ### Hvordan oppdaterer jeg Lagune i Qwen Code? Kjør qwen extensions update lagune, eller installer utvidelsen med --auto-update. ### Hvordan kjører jeg kommandoene til Lagune i Qwen Code? Skriv dem inn med navnet på utvidelsen foran, for eksempel /lagune:lagune-charter. ### Kan Qwen Code kjøre Lagune uten å be om tillatelse? Ja. Tillat mcp__lagune__lagune_read og mcp__lagune__lagune_write i innstillingene til Qwen Code, og i tillegg Shell(npx --yes lagune@*) når motoren kjører via npx. --- # Installer Lagune i enhver agent med skills.sh eller GitHub CLI > Installer Lagune i enhver KI-agent med CLI-en til skills eller med GitHub CLI, og hold det oppdatert. Kanonisk URL: https://lagune.ai/no-NO/docs/install/universal Språk: no-NO Original: https://lagune.ai/docs/install/universal Sist oppdatert: 2026-11-09 **skills.sh** Installer kommandoene til **Lagune** i prosjektet ditt fra terminalen med [**skills.sh**](https://www.skills.sh/wellwelwel/lagune), og behold **Project** som installasjonsomfang: ```bash npx skills add wellwelwel/lagune --skill '*' ``` Eller lim inn denne prompten i agenten din: ```md Kjør `npx --yes skills add wellwelwel/lagune` og følg de genererte skill-instruksjonene nå. Les alle utdataene, om nødvendig etter å ha omdirigert dem til en midlertidig fil først. Løs opp relative stier ut fra mappen for støttefiler som utdataene oppgir. ``` **GitHub CLI** Installer kommandoene til **Lagune** i prosjektet ditt fra terminalen med [**GitHub CLI**](https://cli.github.com/) 2.90.0 eller nyere: ```bash gh skill install wellwelwel/lagune --all --scope project ``` Eller lim inn denne prompten i agenten din: ```md Kjør `gh skill install wellwelwel/lagune --all --scope project` og les alle utdataene, om nødvendig etter å ha omdirigert dem til en midlertidig fil først. ``` ## Oppdatering **skills.sh** Kjør følgende for å oppdatere **Lagune**: ```bash npx skills update ``` Eller lim inn denne prompten i agenten din: ```md Kjør `npx --yes skills update -y` og les alle utdataene, om nødvendig etter å ha omdirigert dem til en midlertidig fil først. ``` **GitHub CLI** Kjør følgende for å oppdatere **Lagune**: ```bash gh skill update --all ``` Eller lim inn denne prompten i agenten din: ```md Kjør `gh skill update --all` og les alle utdataene, om nødvendig etter å ha omdirigert dem til en midlertidig fil først. ``` --- **Sandkasse** I en sandkasse uten nettverkstilgang kan ikke kommandoene laste ned motoren. Installer den i prosjektet ditt fra din egen terminal, først én gang og deretter etter hver oppdatering: ```bash npm i -D lagune@0.18.1 ``` ## Vanlige spørsmål ### Hvordan installerer jeg Lagune i en hvilken som helst KI-agent? Kjør npx skills add wellwelwel/lagune --skill '*' eller gh skill install wellwelwel/lagune --all --scope project i prosjektet ditt, eller lim inn installasjonsprompten i agenten din. ### Hvordan oppdaterer jeg Lagune i en hvilken som helst KI-agent? Kjør npx skills update hvis du installerte det med skills.sh, eller gh skill update --all hvis du installerte det med GitHub CLI. Du kan også lime inn oppdateringsprompten i agenten din. ### Kan jeg installere Lagune på mer enn én måte? Nei. Med to måter viser agenten hver kommando to ganger, eller den bruker én kopi og skjuler den andre. --- # Skills for sikkerhet med KI-agenter > Skillene KI-agenten din låser opp med Lagune: å revidere et eksisterende prosjekt eller sikre nytt arbeid mens du bygger, alltid styrt av sikkerhetsprinsippene. Kanonisk URL: https://lagune.ai/no-NO/docs/get-started/commands Språk: no-NO Original: https://lagune.ai/docs/get-started/commands Sist oppdatert: 2026-11-09 Når **Lagune** er [installert](https://lagune.ai/no-NO/docs), låser **KI**-agenten din opp et sett med skills. Du kan bruke dem på to måter, og begge styres av **sikkerhetsprinsippene**: å sikre nytt arbeid mens du bygger det, eller å kjøre hele revisjonen over et prosjekt. **⌨️ Bygging / utvikling** Du trenger ikke å bli ferdig med arbeidet før du sikrer det. Bruk [**`/lagune`**](https://lagune.ai/no-NO/docs/commands/lagune) for arbeidet du skriver **akkurat nå**: | Skill | Hva den gjør for deg | | --------------------------------------------- | -------------------------------------------------------------------------------------- | | [**/lagune-charter**](https://lagune.ai/no-NO/docs/commands/charter) | Fastsetter sikkerhetsreglene for prosjektet ditt, grunnlaget `/lagune` bygger på | | [**/lagune**](https://lagune.ai/no-NO/docs/commands/lagune) | Bygger det du ber om og herder det mens det skrives, veiledet av sikkerhetsprinsippene | **Bruk den når som helst** [**`/lagune`**](https://lagune.ai/no-NO/docs/commands/lagune) følger reglene i sikkerhetsprinsippene dine hver gang den kjører. Den tar imot en hvilken som helst prompt, bygger det du ba om, og herder det med sikre standardinnstillinger underveis, ikke senere. --- #### Spesielle skills | Skill | Hva den gjør | | --------------------------------------------------- | ----------------------------------------------------------------------------------- | | [**/lagune-specialize**](https://lagune.ai/no-NO/docs/commands/specialize) | Lærer **Lagune** en ny sikkerhetsspesialisering fra artikler, exploits eller temaer | **🔬 Revisjon: Blue Team-flyt** Hele **Blue Team-flyten**: å lese hva et prosjekt gjør, kartlegge risikoene og lukke dem. Hver fase bygger på den forrige, så alt du trenger å gjøre, er å følge listen ovenfra og ned: | # | Skill | Hva den gjør for deg | | --- | --------------------------------------------- | ----------------------------------------------------------------------------------------------- | | 1 | [**/lagune-charter**](https://lagune.ai/no-NO/docs/commands/charter) | Fastsetter sikkerhetsreglene for prosjektet ditt, foreslått for deg eller formet av det du sier | | 2 | [**/lagune-detect**](https://lagune.ai/no-NO/docs/commands/detect) | Leser koden din og kartlegger hva systemet ditt gjør og hvor risikoene ligger | | 3 | [**/lagune-plan**](https://lagune.ai/no-NO/docs/commands/plan) | Gjør det detect fant, om til en forsvarsplan, med en utbedring for hvert funn | | 4 | [**/lagune-harden**](https://lagune.ai/no-NO/docs/commands/harden) | Tar i bruk utbedringene fra planen i koden din, trygt og én om gangen | | 5 | [**/lagune-verify**](https://lagune.ai/no-NO/docs/commands/verify) | Beviser at hver utbedring holder, og lukker dem som gjør det | --- #### Spesielle skills | Skill | Hva den gjør | | --------------------------------------------------- | ---------------------------------------------------------------------------------------- | | [**/lagune-specialize**](https://lagune.ai/no-NO/docs/commands/specialize) | Lærer **Lagune** en ny sikkerhetsspesialisering fra artikler, exploits eller temaer | | [**/lagune-prove**](https://lagune.ai/no-NO/docs/commands/prove) | Gjør hvert oppdaget funn om til et kjørbart bevis, kun defensivt, for ansvarlig varsling | --- #### Interne skills | Skill | Hva den gjør | | ------------------------------------------- | -------------------------------------------- | | [**/lagune-repair**](https://lagune.ai/no-NO/docs/commands/repair) | Reparerer den interne sporingen i **Lagune** | **Tips** Sikkerhet er ikke en kostnad, men en investering: Det du legger inn i starten, sparer du inn mange ganger igjen i hendelsene du aldri får 🙋🏻‍♂️ ## Vanlige spørsmål ### Hvilke skills legger Lagune til? /lagune for å herde arbeidet mens du bygger det, og Blue Team-flyten for revisjon i fem faser: /lagune-charter, /lagune-detect, /lagune-plan, /lagune-harden, /lagune-verify. I tillegg kommer /lagune-specialize og /lagune-prove. ### Hva er Blue Team-flyten i Lagune? En revisjon i fem faser: charter (fastsett regler), detect (kartlegg risikoer), plan (vurder og planlegg utbedringer), harden (ta i bruk utbedringer), verify (bevis at de holder, og lukk dem). ### Hva er forskjellen på /lagune og revisjonsflyten? /lagune sikrer nytt arbeid mens du skriver det, uten noen flyt å følge. Revisjonsflyten kjører de fem fasene i rekkefølge over et eksisterende prosjekt. --- # Dashbord > Se sikkerhetsprinsippene, funnene og katalogen til prosjektet ditt i en lokal live-visning som åpnes med én kommando. Kanonisk URL: https://lagune.ai/no-NO/docs/get-started/dashboard Språk: no-NO Original: https://lagune.ai/docs/get-started/dashboard Sist oppdatert: 2026-11-09 Kjør **Lagune** direkte uten underkommando for å få en interaktiv live-visning av `.lagune/`. Kommandoen starter et dashbord og åpner det på en tilfeldig port: ```bash npx lagune ``` - [x] **Live reload** - [x] **Privat** og **lokalt** - [x] Viser alt `.lagune/` inneholder, fra de første sikkerhetsprinsippene og utover - [x] **Administrer** kategoriene til prosjektet og hva hookene skanner, rett fra nettleseren din - [x] Verken `node_modules` eller `package.json` er nødvendig 📦 ![Sikkerhetsprinsipper i dashbordet til Lagune](https://lagune.ai/img/dashboard/02.webp) ![Funn i dashbordet til Lagune](https://lagune.ai/img/dashboard/03.webp) ![Sideoppdrag i dashbordet til Lagune](https://lagune.ai/img/dashboard/04.webp) ![Detaljvisning av et funn i dashbordet til Lagune](https://lagune.ai/img/dashboard/05.webp) ![Katalogen i dashbordet til Lagune](https://lagune.ai/img/dashboard/06.webp) **Tips** - 🚪 Bruk `--port` for å angi en egen port. - ⏏️ Trykk `Ctrl+C` for å stoppe. ## Vanlige spørsmål ### Hvordan åpner jeg dashbordet til Lagune? Kjør npx lagune uten underkommando i rotmappen til prosjektet ditt. Kommandoen viser .lagune/ live på en tilfeldig port og åpner visningen i nettleseren din. ### Er dashbordet privat? Ja. Det kjører bare på din egen maskin, på en lokal adresse som ingen andre datamaskiner kan nå. ### Kan jeg endre prosjektet mitt fra dashbordet? Bare kategoriene og hva hookene utelater, fra nettleseren din. Alt annet dashbordet viser, er skrivebeskyttet. --- # /lagune: sikker kode mens KI-en din skriver den > Bygg det du ber om, og herd det mens det skrives, styrt av sikkerhetsprinsippene dine og uten noen flyt å følge. Kanonisk URL: https://lagune.ai/no-NO/docs/commands/lagune Språk: no-NO Original: https://lagune.ai/docs/commands/lagune Sist oppdatert: 2026-11-09 ⌨️ Få gjort arbeidet du ba om, sikret mens det skrives. **`/lagune`** tar imot hvilken som helst prompt på hvilket som helst stadium, bygger det du ville ha, og herder det med sikre standardinnstillinger før du får det tilbake. ## Bruk Merk en hvilken som helst prompt med **`/lagune`**, og beskriv arbeidet slik du alltid ville gjort. **📘 Instruksjoner for agenter** ```md # Prosjektinstruksjonene mine for agenter ## Sikkerhet - Bruk skillen `/lagune` hver gang du bygger eller endrer kode, slik at den gjør koden sikrere som standard. ``` - For eksempel: **AGENTS.md**, **CLAUDE.md**, **.github/copilot-instructions.md**, **.cursorrules** osv. **💬 En funksjon** ```prompt /lagune la brukerne laste opp et eget bilde på profilen sin. ``` **💬 En feilretting** ```prompt /lagune ingenting skjer når brukeren sender inn skjemaet. Finn ut hva det kan være, og rett det. ``` **💬 En refaktorering** ```prompt /lagune frikoble og forbedre payload-logikken ``` **Sikkerhetsprinsipper er valgfrie, men bedre å ha** **`/lagune`** fungerer med eller uten sikkerhetsprinsipper. Har du dem, former prosjektets egne regler alt som bygges. Fastsett dem én gang med [`/lagune-charter`](https://lagune.ai/no-NO/docs/commands/charter). ## Slik fungerer det Kommandoen pakker inn arbeidet i tre steg, uten å skrive noe til Lagune: 1. Den laster inn sikkerhetsprinsippene dine, hvis de finnes, og lar dem styre hele byggingen. Har du ingen ennå, faller den tilbake på et grunnlag som er sikkert som standard. 2. Den lister opp [katalogen](https://lagune.ai/no-NO/docs/catalog) for prosjektet ditt og laster bare inn spesialiseringene arbeidet ditt berører, den samme kunnskapen ved behov som revisjonsflyten bruker. 3. Den tar i bruk forsvaret mens koden skrives, og leser deretter sitt eget resultat på nytt for å bekrefte at sikringstiltakene faktisk holder, før du får arbeidet tilbake. Resultatet er fungerende kode i prosjektet ditt, sikker fra første linje. **Bruk den når som helst** Ingen detect, ingen plan, ingen opprydding etterpå. **`/lagune`** passer like godt til et helt nytt prosjektskjelett som til en endring i en moden kodebase, og den herder arbeidet underveis, ikke senere. ## Hva den ikke gjør - Den skriver ingenting til mappen `.lagune`, verken artefakter eller sporing, så det eneste den produserer, er den herdede koden du ba om. - Den svekker ikke en regel for å etterkomme en prompt, så hvis det du ba om, ville bryte et av sikkerhetsprinsippene dine, stopper den og sier fra til deg først i stedet for å bygge det usikkert. ## Vanlige spørsmål ### Hva gjør /lagune? Den tar imot hvilken som helst prompt på hvilket som helst stadium, bygger det du ba om, og herder det med sikre standardinnstillinger før du får det tilbake. Forsvaret blir tatt i bruk mens koden skrives, ikke senere. ### Trenger jeg sikkerhetsprinsipper for å bruke /lagune? Nei. Den fungerer med eller uten. Med sikkerhetsprinsipper former prosjektets egne regler alt som bygges. Uten faller den tilbake på et grunnlag som er sikkert som standard. ### Hva er forskjellen på /lagune og Blue Team-flyten? /lagune sikrer nytt arbeid mens du skriver det, uten noen flyt å følge. Blue Team-flyten kjører de fem revisjonsfasene i rekkefølge over et eksisterende prosjekt. ### Sporer /lagune funn eller skriver artefakter? Nei. Den skriver ingenting til mappen .lagune, verken artefakter eller sporing. Det eneste den produserer, er den herdede koden du ba om. ### Hvordan får jeg agenten min til å bruke /lagune automatisk? Legg til en instruksjon i instruksjonsfilen til agenten din (AGENTS.md, CLAUDE.md, .cursorrules og lignende) som ber den bruke skillen /lagune hver gang den bygger eller endrer kode. --- # /lagune-charter: Fastsett sikkerhetsprinsippene dine > Fastsett sikkerhetsprinsippene for prosjektet ditt, reglene hver senere fase følger, og registrer spesialiseringskategoriene som gjennomgangen av prosjektet støtter. Kanonisk URL: https://lagune.ai/no-NO/docs/commands/charter Språk: no-NO Original: https://lagune.ai/docs/commands/charter Sist oppdatert: 2026-11-09 🧬 Fortell **Lagune** hva prosjektet ditt er, så gjør det dette om til sikkerhetsreglene dine (eller, uten en beskrivelse, utleder dem fra prosjektet alene). Charter er det overordnede laget: et sett sikkerhetsprinsipper der sikkerheten kommer først, og som hver senere fase må respektere. Tenk på det som en kompileringskontroll av sikkerhetsnivået i prosjektet ditt. ## Bruk **Beskriv det** ```prompt /lagune-charter Prosjektet mitt er en nettbutikk som selger videospill. Kundene legger produkter i en handlekurv og betaler med kredittkort eller faktura. De kan se bestillingene sine og statusen for hver enkelt. ``` **La Lagune foreslå** ```prompt /lagune-charter ``` > _Jeg ser et betalingsbibliotek, et innloggingsoppsett og en bestillingsmodell knyttet til en kunde. Dette ser ut som en nettbutikk som selger noe. Kundene betaler og følger med på sine egne bestillinger..._ ☁️ ## Hva fasen utleder **Lagune** bruker beskrivelsen din eller et **PRD** som retning og utleder hva den betyr for sikkerheten, og leser deretter prosjektet for å gå lenger enn det du nevnte. For eksempel: - En handlekurv som holder bestillinger, betyr at det finnes en **database**: - f.eks. `"Hvor ligger dataene?"`, `"Hvem kan nå dem?"`, `"Lekker de?"`. - At kundene kan se sine egne bestillinger, betyr at det finnes en form for **innlogging eller tilgangskontroll**: - f.eks. `"Kan én kunde nå en annen kundes bestillinger?"`, `"Er øktene beskyttet?"`. - At prosjektet tar imot betaling med kort og faktura, betyr at **penger og sensitive data er involvert**: - f.eks. `"Lagres kortdata?"`, `"Blir betalingene verifisert?"`. Beskrivelsen din og prosjektet utfyller hverandre: Beskrivelsen din angir hensikten, og en gjennomgang av avhengighetene, README-filen og konfigurasjonen avdekker det du ikke nevnte. Er noe viktig fortsatt uklart, stiller **Lagune** et kort, enkelt spørsmål i stedet for å gjette. Ut fra dette bygger **Lagune** et skreddersydd sett sikkerhetsregler for prosjektet, som du kan gå gjennom og justere når du trenger det. **Få mest mulig ut av det** - Du kan også definere dine egne sikkerhetsregler for prosjektet. - Jo flere relevante detaljer du gir, desto bedre blir den endelige rapporten: - Forklar prosjektet, hvordan det fungerer og hva som skjer under panseret. - Hvem er sluttbrukeren? Hva kan brukerne gjøre, og hva kan de ikke gjøre? - Detaljer om oppførsel er like verdifulle som tekniske detaljer. - Minnet for charter ligger i `.lagune/memory/charter.md`. ## Kategoriene den registrerer Spesialiseringer, sikkerhetskunnskapen de senere fasene laster inn ved behov, kommer inn i [katalogen](https://lagune.ai/no-NO/docs/catalog) for prosjektet ditt etter [kategori](https://lagune.ai/no-NO/docs/categories). Så lenge prosjektet ditt ikke har registrert noen kategori, registrerer charter hver kategori som gjennomgangen støtter, for eksempel språket i prosjektet, kall til en LLM eller containere, og nevner dem i oppsummeringen. Når kategorier er registrert, lar charter dem være som de er og nevner bare en kategori prosjektet ditt ikke bruker ennå. Du kan endre dem selv når som helst: ```bash npx lagune write add --categories python npx lagune write remove --categories python ``` ## Mappene den tilbyr å utelate Finner charter under gjennomgangen mapper i repositoryet som ikke er kode prosjektet ditt skal forsvare, for eksempel testfixtures skrevet for å se sårbare ut, lister den dem opp med nummer på slutten av oppsummeringen. Den utelater aldri en mappe på egen hånd, siden et fiendtlig repository kan få koden sin til å se ut som fixtures, så bare numrene du svarer med, blir registrert. [Konfigurer hookene](https://lagune.ai/no-NO/docs/hooks/configure) viser hvordan du endrer dem selv. ## Neste steg Når reglene er fastsatt, kartlegg hva systemet ditt faktisk gjør: [`/lagune-detect`](https://lagune.ai/no-NO/docs/commands/detect). ## Vanlige spørsmål ### Hva er en charter i Lagune? Charter er det overordnede laget i Lagune, et sett sikkerhetsprinsipper der sikkerheten kommer først, og som hver senere fase må respektere. Tenk på det som en kompileringskontroll av sikkerhetsnivået i prosjektet ditt. ### Hvor lagres charter? I .lagune/memory/charter.md. ### Kan jeg skrive mine egne regler i charter? Ja. Lagune foreslår regler ut fra beskrivelsen og koden din, og du kan omformulere, fjerne, legge til eller avgrense dem. ### Velger charter spesialiseringskategoriene mine? Bare så lenge ingen er registrert. Da registrerer den hver kategori som gjennomgangen støtter, for eksempel språket ditt eller kall til en LLM. Når kategorier er registrert, endrer den dem aldri. --- # /lagune-detect: Kartlegg systemet ditt og risikoene > Les koden din og kartlegg hva systemet gjør og hvor risikoene ligger. Kanonisk URL: https://lagune.ai/no-NO/docs/commands/detect Språk: no-NO Original: https://lagune.ai/docs/commands/detect Sist oppdatert: 2026-11-09 🔬 Finn ut hva systemet ditt egentlig gjør og hvor risikoene ligger. Detect leser koden og registrerer bare det den faktisk finner, med belegget de senere fasene trenger. Det overordnede prinsippet er å oppdage, ikke å finne på. ## Bruk **Full gjennomgang** ```prompt /lagune-detect ``` **Oppgi stier** ```prompt /lagune-detect src/routes/ src/auth.ts ``` **Beskriv en problemstilling** ```prompt /lagune-detect sørg for at kundedata aldri blir eksponert ``` ## Hva fasen kartlegger **Lagune** leser koden og kartlegger det den finner. Hvert funn sier hva det er, hvorfor det er viktig og hva belegget er. For eksempel: - **Filopplasting**, systemet tar imot filer fra brukerne: - _Hvorfor det er viktig:_ En fil forkledd som et bilde kan skjule skadelig kode. - _Belegg:_ Handleren for `POST /upload` stoler på MIME-typen klienten sender, uten å sjekke den faktiske filtypen. - **Innlogging og økter**, brukerne logger inn for å nå kontoen sin: - _Hvorfor det er viktig:_ Svak økthåndtering gjør det mulig for én konto å bli overtatt av en annen. - _Belegg:_ logikken som utsteder økter, der øktene utstedes uten noen utløpstid. Underveis gir detect hver spesialisering i [katalogen](https://lagune.ai/no-NO/docs/catalog) for prosjektet ditt en konklusjon ut fra koden, tar i bruk dem der konteksten finnes, og registrerer dem under **Applied specializations**, listen som harden og verify bruker på nytt. Deretter har du et klart kart over hva systemet ditt gjør og hvor risikoene ligger, klart for at de neste stegene kan handle ut fra det. **Tips** - Kjører du den på nytt, blir kartet oppdatert: Løste funn faller bort, og nye kommer til. - Kartleggingen fra detect ligger i `.lagune/memory/detect.md`. ## Neste steg Gjør kartleggingen om til en plan: [`/lagune-plan`](https://lagune.ai/no-NO/docs/commands/plan). ## Vanlige spørsmål ### Hva gjør /lagune-detect? Den leser koden din og kartlegger hva systemet gjør og hvor risikoene ligger, og registrerer bare det den faktisk finner. Regelen er å oppdage, ikke å finne på. ### Hva er et funn i Lagune? Et funn er én oppdaget risiko, med hva den er, hvorfor den er viktig og belegget i koden. Det er den sporede enheten som plan, harden og verify tar videre. ### Hvor lagres kartleggingen fra detect? I .lagune/memory/detect.md. ### Hvilke spesialiseringer bruker detect? Hver spesialisering i katalogen for prosjektet ditt får en konklusjon ut fra koden. Detect tar i bruk dem der konteksten finnes, og registrerer dem under Applied specializations. --- # /lagune-plan: Vurder funn og planlegg utbedringer > Gjør det detect fant, om til en forsvarsplan som vurderer hvert funn med en kategori og en CVSS v4.0-score, og knytter en utbedring til det. Kanonisk URL: https://lagune.ai/no-NO/docs/commands/plan Språk: no-NO Original: https://lagune.ai/docs/commands/plan Sist oppdatert: 2026-11-09 🛡️ Gjør det detect fant, om til en forsvarsplan: Vurder hvert funn med en kategori og en CVSS v4.0-score, og knytt det deretter til utbedringen som skal tas i bruk. ## Bruk **Planlegg alt** ```prompt /lagune-plan ``` **Oppgi stier** ```prompt /lagune-plan src/routes/upload.ts ``` **Fokuser på en bekymring** ```prompt /lagune-plan hvor sensitive data kan lekke ut ``` ## Slik fungerer det Denne fasen fortsetter der detect slapp. Detect har allerede funnet ut hva systemet ditt gjør og hvilken risiko hver del innebærer, så plan gjentar ikke risikoen, men vurderer hvor alvorlig den er og bestemmer hva som skal gjøres med den. Plan leser aldri koden, og det tvinger hver utbedring til å peke på noe detect faktisk oppdaget. Fasen vurderer hvert funn etter metoden i CVSS v4.0: en kategori, en CVSS v4.0-vektor som er utledet fra det detect og charter fanget opp, og som [hooken `cvss`](https://lagune.ai/no-NO/docs/hooks/cvss) beregner scoren for, samt prioritetsnivået scoren havner i. Hver utbedring angir også sikkerhetsprinsippet den ivaretar. For eksempel: - **Filopplasting** (Prioritet: **Critical**) - _Kategori:_ Ubegrenset filopplasting (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 prioriteten:_ Alle kan nå opplastingen over internett, og den ligger på serveren som lagrer kundenes filer. - _Ivaretar:_ III. All inndata er ikke-klarert til den er validert. - _Utbedring:_ sjekk filens faktiske type og størrelse, gi den nytt navn ved lagring, og lagre opplastinger der de ikke kan kjøres som kode. Deretter har du en vurdert og prioritert liste over utbedringer, hver knyttet til et funn og klar til å tas i bruk i neste fase. Scoren blir beregnet, aldri anslått: Vektoren uttrykker hvor eksponert prosjektet er og hva som står på spill, som Environmental-metrikker, og hvem som helst kan lime den inn i kalkulatoren til FIRST eller NVD og komme frem til samme score. **Tips** - Fasen bygger helt på detect. Er en fil eller en bekymring aldri blitt kartlagt, ber den deg kjøre `/lagune-detect` på den først. - Kjører du den på nytt, blir planen oppdatert: Ferdige utbedringer faller bort, og nye kommer til. - Forsvarsplanen ligger i `.lagune/memory/plan.md`. **Avhenger av detect** Plan arbeider bare ut fra det [`/lagune-detect`](https://lagune.ai/no-NO/docs/commands/detect) allerede har kartlagt, så kjør detect først. ## Neste steg Ta i bruk planen: [`/lagune-harden`](https://lagune.ai/no-NO/docs/commands/harden). ## Vanlige spørsmål ### Hvordan prioriterer Lagune sårbarheter? /lagune-plan vurderer hvert funn med en kategori og en CVSS v4.0-score som hooken cvss beregner, og knytter det deretter til utbedringen som skal tas i bruk. ### Bruker Lagune CVSS v4.0? Ja. Hvert funn får en CVSS v4.0-vektor og -score, beregnet av hooken cvss med samme aritmetikk som kalkulatoren til FIRST, så hvem som helst kan lime inn vektoren der og komme frem til samme score. ### Leser plan koden min? Nei. Plan leser aldri koden, og det tvinger hver utbedring til å peke på noe detect faktisk oppdaget. --- # /lagune-harden: Ta i bruk sikkerhetsutbedringer i koden din > Ta i bruk utbedringene fra planen i koden din, trygt og én om gangen. Kanonisk URL: https://lagune.ai/no-NO/docs/commands/harden Språk: no-NO Original: https://lagune.ai/docs/commands/harden Sist oppdatert: 2026-11-09 🔧 Ta i bruk utbedringene fra planen i koden din, trygt og én om gangen. ## Bruk **Ta i bruk alt** ```prompt /lagune-harden ``` **Oppgi stier** ```prompt /lagune-harden src/routes/upload.ts ``` **Etter prioritet** ```prompt /lagune-harden kritisk og høy prioritet ``` ## Slik fungerer det Planen har allerede bestemt hver utbedring, så harden tar dem bare i bruk. Siden dette er den eneste fasen som rører koden din, går den forsiktig frem: Den tar i bruk én utbedring om gangen, slik at hver endring er lett å gå gjennom, og den svekker aldri et sikringstiltak for å få en utbedring til å passe. For eksempel utbedringen for opplastingen: - **Filopplasting** (Status: **Applied**) - _Hva som ble endret:_ sjekker filens faktiske type og størrelse, avviser alt uventet, gir den nytt navn ved lagring og lagrer den der den ikke kan kjøres som kode. - _Hvor:_ funksjonen `handleUpload`, pluss lagringshjelperen den kaller. Kan en utbedring ikke tas fullt i bruk, gjør harden det som trygt lar seg gjøre, og markerer resten som **Partial** eller **Blocked**, slik at utbedringen står åpen. **Applied er ikke verifisert** Applied betyr ikke at noe er bevist ennå. Det er det [verify](https://lagune.ai/no-NO/docs/commands/verify) er til for. **Tips** - Fasen bygger helt på planen. Er en utbedring eller fil aldri blitt planlagt, ber den deg kjøre `/lagune-plan` på den først. - Kjører du den på nytt, blir loggen avstemt: Endringer som er rullet tilbake, faller bort, og utbedringer som nettopp er tatt i bruk, kommer til. - Herdingsloggen ligger i `.lagune/memory/harden.md`. **Avhenger av plan og endrer koden din** Harden bygger på [`/lagune-plan`](https://lagune.ai/no-NO/docs/commands/plan). Det er den eneste fasen som endrer koden din. ## Neste steg Bevis at hver utbedring holder: [`/lagune-verify`](https://lagune.ai/no-NO/docs/commands/verify). ## Vanlige spørsmål ### Endrer /lagune-harden koden min? Ja. Det er den eneste fasen som rører koden din, og den tar i bruk utbedringene fra planen én om gangen. ### Hva betyr Applied, Partial og Blocked? Det er statusen Lagune registrerer for hver utbedring. Applied betyr at utbedringen ble gjort, Partial at bare en del av den ble gjort, og Blocked at den ikke kunne tas i bruk. Applied betyr ikke at noe er bevist ennå. ### Tar Lagune i bruk utbedringer uten å spørre? Om en endring trenger godkjenningen din, avgjør agenten din og tillatelsesmodusen du kjører den i, ikke Lagune, som ikke legger til noe eget bekreftelsestrinn. Den svekker likevel aldri et sikringstiltak for å oppfylle en utbedring, og hvis en utbedring ville komme i konflikt med en regel i charter, stopper den og sier fra til deg først. --- # /lagune-verify: Bevis at sikringstiltakene holder > Bevis at hver utbedring som er tatt i bruk, holder, og lukk deretter de som gjør det. Kanonisk URL: https://lagune.ai/no-NO/docs/commands/verify Språk: no-NO Original: https://lagune.ai/docs/commands/verify Sist oppdatert: 2026-11-09 ⚖️ Bevis at hver utbedring som er tatt i bruk, holder, ved å lese koden og holde den opp mot det harden registrerte, og lukk deretter de som gjør det. ## Bruk **Verifiser alt** ```prompt /lagune-verify ``` **Oppgi stier** ```prompt /lagune-verify src/routes/upload.ts ``` **Etter prioritet** ```prompt /lagune-verify kritisk og høy prioritet ``` ## Slik fungerer det Fasen leser koden på hvert sted harden registrerte, og bekrefter at den virkelig stemmer med påstanden. Beviset ligger i nettopp dette: koden holdt opp mot loggen. Hvert sikringstiltak får én av tre konklusjoner: | Konklusjon | Betydning | | ---------------------------- | ------------------------------------------------------------------------- | | ✅ Risk closed | Koden gjør nøyaktig det loggen påstår. | | ❌ Risk not closed | Sikringstiltaket er fortsatt åpent. Verify sender deg tilbake til harden. | | ❓ Cannot tell from the code | Belegget er ikke synlig i koden alene. | En risiko som er bevist lukket, blir deretter tatt ut av kjeden, med din bekreftelse. For eksempel: - **Filopplasting** (Konklusjon: **✅ Risk closed**) - _Hvordan det ble bevist:_ Verify leste opplastingshandleren og så at den finner filens faktiske type ut fra innholdet, håndhever en størrelsesgrense og avviser alt annet, nøyaktig slik loggen påstår. - _Belegg:_ funksjonen `handleUpload`, som finner den faktiske filtypen ut fra innholdet. Er risikoen ikke lukket, sier verify det rett ut og sender deg tilbake til [`/lagune-harden`](https://lagune.ai/no-NO/docs/commands/harden), siden utbedringen fortsatt er åpen. **Tips** - Fasen bygger helt på herdingsloggen. - Den leser bare koden din for å vurdere den, og svekker aldri et sikringstiltak eller skriver om koden for å få en konklusjon til å gå gjennom. - Kjører du den på nytt, blir konklusjonene avstemt: Utdaterte faller bort, og en risiko som ikke lenger er lukket, blir flagget igjen. - Når en risiko er bevist lukket, spør den én gang og fjerner deretter funnet fra hele kjeden (detect, plan, harden og sporingen). - Den skriver ingen egen rapport: Hver konklusjon ligger i blokken for sikringstiltaket i `.lagune/memory/harden.md`, der harden leser den ved neste kjøring. **Avhenger av harden** Verify bygger på [`/lagune-harden`](https://lagune.ai/no-NO/docs/commands/harden). ## Syklusen lukkes Når alt innenfor omfanget er tatt ut, er syklusen i ro. Den åpnes igjen bare når koden endres. Sikkerhet er lukkbar, så flyten har en sluttilstand, ikke en endeløs løkke. ## Vanlige spørsmål ### Hvordan verifiserer Lagune en utbedring? /lagune-verify leser koden og holder den opp mot det harden registrerte, og gir én av tre konklusjoner: Risk closed, Risk not closed eller Cannot tell from the code. ### Hva vil det si å ta ut et funn? Når verify beviser at en risiko er lukket, blir funnet tatt ut: fjernet fra hele kjeden, med din bekreftelse, slik at det ikke blir behandlet på nytt. ### Kan sikkerhetsarbeid noen gang bli ferdig? Ja. SDH er lukkbar: Et funn som er bevist lukket, blir tatt ut, så flyten har en sluttilstand, ikke en endeløs løkke. --- # Kategorier > Spesialiseringskategoriene et Lagune-prosjekt kan bruke, fra OWASP til språkspesifikk herding for JavaScript, Python, Go og Rust, og hvordan du endrer dem. Kanonisk URL: https://lagune.ai/no-NO/docs/categories Språk: no-NO Original: https://lagune.ai/docs/categories Sist oppdatert: 2026-11-09 **Lagune** grupperer de innebygde [**spesialiseringene**](https://lagune.ai/no-NO/docs/catalog) sine i **13 kategorier**. Kategoriene et prosjekt bruker, avgjør hvilke innebygde som kommer med i [**katalogen**](https://lagune.ai/no-NO/docs/catalog) til prosjektet, og de deler seg i to: hva systemet gjør, og hva det er skrevet i. Så lenge ingen kategori er registrert, bruker et prosjekt bare `owasp`. [`/lagune-charter`](https://lagune.ai/no-NO/docs/commands/charter) registrerer hver kategori som analysen av prosjektet støtter, og du kan når som helst endre dem selv. ## Hva systemet gjør | Kategori | Nøkkel | Hva den herder | | ------------- | --------- | -------------------------------------------------------------------------------------------------------------------------------- | | OWASP | `owasp` | Applikasjonssikkerhetsrisikoene OWASP følger med på: injeksjon, brutt tilgangskontroll og svikt i autentisering og kryptografi | | Infrastruktur | `infra` | Konfigurasjon av containere, arbeidslaster og serverless: Dockerfile, Compose, Pod-sikkerhet, IAM og triggere for FaaS | | KI / LLM | `ai` | Integrasjoner med KI og LLM, mot prompt injection og usikker kobling av verktøy, agenter, gjenfinning og MCP | | Lovable | `lovable` | KI-genererte Supabase-apper (Lovable og lignende): hull i RLS, lekkede nøkler for `service_role` og usikre standardinnstillinger | ## Hva det er skrevet i | Kategori | Nøkkel | Hva den herder | | ---------- | ------------ | ---------------------------------------------------------------------------------------------------------------- | | JavaScript | `javascript` | RCE via `eval` og `child_process`, path traversal og prototype pollution, på tvers av kjøremiljøene | | Python | `python` | RCE ved deserialisering med `pickle` og YAML, string traversal via `str.format` og class pollution | | Rust | `rust` | Usunne API-er med `unsafe`, feilbruk av `transmute`, heltallsoverflyt og udefinert oppførsel ved FFI-grensen | | C / C++ | `c-cpp` | Formatstrengfeil, bufferoverflyt og skriving utenfor grensene som muliggjør kodekjøring | | PHP | `php` | Omgåelse av autentisering via type juggling, gadget-kjeder for objektinjeksjon og usikre standardkonfigurasjoner | | Go | `go` | Typed nil-feil i interfaces, data races mellom goroutiner og usikker samtidighet på sikkerhetskritiske stier | | Java | `java` | Gadget-kjeder ved deserialisering med `ObjectInputStream` som ender i fjernkjøring av kode | | Ruby | `ruby` | Gadget-kjeder ved deserialisering med `Marshal.load` og YAML som når fram til fjernkjøring av kode | | .NET / C# | `dotnet` | RCE ved deserialisering med `BinaryFormatter` og omgåelser av encoderen som fører til XSS | **Tips** **Lagune** er språkuavhengig: Hele flyten leser prosjektet ditt, uansett hva det er skrevet i, og disse kategoriene går bare dypere inn i fallgruvene som er særegne for ett språk. ## Legg til og fjern når som helst En kategori er et utgangspunkt, ikke en forpliktelse. Bruk det som passer prosjektet nå, og endre det når som helst via nøkkelen, med `write add` og `write remove`. `--categories` uten verdi åpner en interaktiv velger i en terminal (mellomrom for å slå av og på, enter for å bekrefte, tomt for å hoppe over). Utenfor en terminal oppgir du kategoriene rett etter. **Legg til** ```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` tar utgangspunkt i `owasp`, så fjerner du alle kategorier, står du igjen med en tom liste, aldri standardverdien. Hver endring havner i `.lagune/configs.json`, så hele teamet jobber med det samme utvalget. ## Se hva et prosjekt bruker `read list --categories` viser hver kategori og om prosjektet bruker 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. ``` I [**Katalog**](https://lagune.ai/no-NO/docs/catalog) ser du hvilke spesialiseringer hver kategori inneholder. Dine egne spesialiseringer, skrevet med [`/lagune-specialize`](https://lagune.ai/no-NO/docs/commands/specialize), kommer med i katalogen uansett kategorier. ## Vanlige spørsmål ### Hvordan legger jeg til en kategori? Gi nøkkelen til kategorien til --categories, for eksempel npx lagune write add --categories javascript. Så lenge ingen er registrert, registrerer også charter kategoriene som analysen av prosjektet støtter. ### Kan jeg bruke mer enn én kategori? Ja. Skriv dem på samme linje, den ene etter den andre. ### Hvilken kategori bør et prosjekt bruke? Start med owasp, som er standard, og legg deretter til den for språket eller stakken din. Spesialiseringer lastes bare ved behov, så en kategori koster ingenting før en fase trenger en av spesialiseringene i den. --- # Katalog: sikkerhetsspesialiseringer ved behov > Slik lastes spesialiseringene i katalogen til prosjektet ditt: av en fase ved behov, og av deg direkte. Kanonisk URL: https://lagune.ai/no-NO/docs/catalog Språk: no-NO Original: https://lagune.ai/docs/catalog Sist oppdatert: 2026-11-09 🧠 Spesialiseringene i **Lagune** er fokuserte, språkuavhengige kunnskapsmoduler for sikkerhet som bare lastes ved behov, aldri som standard. De er ikke kommandoer. Katalogen til prosjektet ditt er utvalget det bruker: de innebygde spesialiseringene fra [kategoriene](https://lagune.ai/no-NO/docs/categories) til prosjektet, pluss prosjektets egne. Fasene detect og verify henter dem inn mens de kjører, og du kan når som helst laste en direkte. **Oversikt** *Den interaktive katalogoversikten finner du på nettsiden. Alle innebygde spesialiseringer står i tabellen nedenfor.* **Slik fungerer det** ## Bruk den selv Vil du bruke en spesialisering direkte, ber du agenten laste den med `read catalog ` og skriver oppgaven i samme prompt. Kunnskapen virker da på det du ba om. Dette fungerer i alle prompter, også i en som ikke har noe med flyten i **Lagune** å gjøre. Her er for eksempel en direkte, fritt formulert prompt som lager en sikker samling **RegExp** i **Python**: ```prompt Last inn spesialiseringen regex med `npx lagune read catalog regex`, og lag deretter en samling regulære uttrykk i @src/utils/regex.py som validerer e-postadresser og brukernavn. ``` Dette bruker en deterministisk hook til å teste hver **RegExp** mot **ReDoS**, beholder de trygge og gir omtrent dette: ```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-kontrollen** Test et mønster selv på [**devina.io/redos-checker**](https://devina.io/redos-checker). ## De innebygde spesialiseringene De innebygde spesialiseringene er gruppert i [**kategorier**](https://lagune.ai/no-NO/docs/categories). Dette er utvalget som følger med **Lagune**: | Spesialisering | Kategori | Fokus | | --------------------- | --------------------------- | ------------------------------------------------------------------------------------------------------ | | `regex` | `owasp` | **ReDoS:** mønstre som eksploderer ved manipulert inndata. | | `network` | `owasp` | **SSRF og omdirigeringer:** brukeroppgitte mål for henting eller omdirigering. | | `interpreter` | `owasp`, `lovable` | **Kodeinjeksjon:** `eval`, dynamisk inkludering, dispatch via navn. | | `sql` | `owasp` | **Relasjonsdatabaser:** injeksjon, rå ORM-kall, privilegier, rekkevidden til databasemotoren. | | `path` | `owasp` | **Filsystemstier:** traversal, null-byte, NTFS-strømmer, planting. | | `upload` | `owasp` | **Filopplasting:** type/signatur, ondsinnet innhold, lagring, grenser. | | `access-control` | `owasp`, `lovable` | **Autentisering, autorisasjon og økter:** IDOR, mass assignment, leietakere, økter. | | `credential-endpoint` | `owasp`, `lovable` | **Gjetting og boter:** brute force, password spraying, credential stuffing, hastighetsbegrensning. | | `federation` | `owasp` | **Tillit til tokens:** OAuth/OIDC, SAML, JWT-validering, QR-innlogging. | | `http-request` | `owasp` | **Opprinnelsen til forespørsler:** CSRF, feilkonfigurert CORS, forfalsket klient-IP. | | `transport` | `owasp` | **Kanalsikkerhet:** TLS-konfigurasjon, HTTPS/klartekst, HSTS, pinning. | | `crypto` | `owasp`, `lovable` | **Kryptografi for lagrede data:** svake eller hjemmelagde algoritmer, CSPRNG, nøkkelhåndtering. | | `secrets` | `owasp`, `lovable` | **Hardkodede påloggingsdetaljer:** nøkler, tokens og passord skrevet rett inn i kildekoden. | | `api-endpoint` | `owasp` | **Grensesnitt utenom REST:** GraphQL, gRPC, autorisasjon for WebSocket, DoS, skjema. | | `payment` | `owasp`, `lovable` | **Betalingsflyt:** verifisering mot betalingsløsningen på serversiden, signerte callbacks, idempotens. | | `xml` | `owasp` | **XML-parsing:** XXE, eksterne entiteter, billion laughs-ekspansjon. | | `csv` | `owasp` | **Formelinjeksjon:** regnearkceller som starter med `=`/`+`/`-`/`@`. | | `container` | `owasp`, `infra` | **Containerkonfigurasjon:** root, capabilities, socket-montering, herding av imaget. | | `infra` | `infra` | **Infrastruktur som kode:** Terraform, Dockerfile, GitHub Actions. | | `serverless` | `owasp`, `infra`, `lovable` | **FaaS-funksjoner:** IAM med minste privilegium, hendelsesinndata, kontekst, hemmeligheter. | | `llm` | `ai`, `lovable` | **KI- og LLM-risikoer:** prompt injection, agency, RAG, MCP, utdata. | | `supabase` | `lovable` | **Backend med Supabase:** RLS av som standard, policyer som KI genererer feil, nøkkelmodell. | | `browser` | `javascript`, `lovable` | **Risikoer på klientsiden:** XSS, CSP, framing, lagring osv. | | `javascript` | `javascript` | **Risikoer på språknivå:** RCE, prototype pollution osv. | | `python` | `python` | **Risikoer på språknivå:** RCE via `pickle`, class pollution, `-O` osv. | | `rust` | `rust` | **Soundness i `unsafe`:** UB utløst fra trygg kode, `transmute`, overflyt. | | `java` | `java` | **Deserialisering og mobil kode:** kjeder via `readObject`, kapring av objekter. | | `ruby` | `ruby` | **Deserialisering og `open`:** gjenoppliving av objekter via `Marshal`/YAML, pipe-særhet. | | `php` | `php` | **Type juggling og `unserialize`:** magiske hasher, POP-kjeder. | | `go` | `go` | **Typed nil og data races:** `nil != nil`, goroutiner med delt minne. | | `c-cpp` | `c-cpp` | **Formatstrenger:** `printf(user_input)`, write-what-where via `%n`. | | `dotnet` | `dotnet` | **Risikoer på plattformnivå:** RCE via `BinaryFormatter`, `@Html.Raw`, hull i enums. | Mesteparten av den innebygde kunnskapen er destillert fra OWASP. Under [**OWASP-kilder**](https://lagune.ai/no-NO/docs/references/owasp-sources) finner du hele koblingen mellom hver spesialisering og de kanoniske OWASP-sidene om angrep og Cheat Sheets. Noen få stakkspesifikke moduler bygger i stedet på leverandørens egne anbefalinger: `supabase` kommer for eksempel fra dokumentasjonen til Supabase og CVE-2025-48757. ## Dine egne spesialiseringer De innebygde vokser med én kunnskapsfil og én indeksrad om gangen, aldri med en ny kommando. Du legger til dine egne på samme måte, med [`/lagune-specialize`](https://lagune.ai/no-NO/docs/commands/specialize): Gi kommandoen en artikkel eller et tema, så destillerer den en ny spesialisering inn i prosjektet ditt, filen under `.lagune/catalog/` og oppføringen i `.lagune/configs.json`. Dine egne er alltid med i katalogen, uansett kategorier, og en av dine overstyrer en innebygd med samme navn. **Internt laster Lagune spesialiseringer automatisk, ved behov** Når fasen detect eller verify støter på en kontekst som en spesialisering dekker, laster den selv inn spesialiseringen med `read catalog `. Dette skjer automatisk, som en del av fasen. Du trenger ikke gjøre noe for hånd for at det skal fungere. ## Se hva som er tilgjengelig Slik lister du opp katalogen til prosjektet ditt i terminalen, én spesialisering per linje med taggene sine: ```bash npx lagune read catalog # regex: Regular Expression [required] # network: Requests, Webhook, URL Fetch, Socket, IMDS, Redirect # interpreter: Evaluator, Sink, Shell, Dynamic Execution # ... ``` En spesialisering merket `[required]` gjelder alltid, uansett hva arbeidet er. Hvilke innebygde listen inneholder, avhenger av [**kategoriene**](https://lagune.ai/no-NO/docs/categories) til prosjektet ditt. **Spesialiseringer lastes ikke som standard** Den relevante kunnskapen hentes inn ut fra hva prosjektet faktisk er, i stedet for at alle kontroller kjører som standard. ## Vanlige spørsmål ### Hva er en spesialisering i Lagune? En fokusert, språkuavhengig kunnskapsmodul for sikkerhet som bare lastes ved behov, aldri som standard. Den er ikke en kommando, slik skillene til agenten er. ### Hva er katalogen til et prosjekt? Spesialiseringene prosjektet bruker: de innebygde fra kategoriene til prosjektet, pluss prosjektets egne. Så lenge ingen kategori er registrert, bruker det bare OWASP. ### Lastes spesialiseringer som standard? Nei. De lastes bare ved behov, ut fra hva prosjektet faktisk er. ### Hvordan laster jeg en spesialisering direkte? Be agenten kjøre npx lagune read catalog i samme prompt som oppgaven. --- # /lagune-specialize: Tren en sikkerhetsspesialisering med vanlig tekst > Destiller en sikkerhetskilde eller et sikkerhetstema du gir den, til en ny spesialisering som lastes inn ved behov. Kanonisk URL: https://lagune.ai/no-NO/docs/commands/specialize Språk: no-NO Original: https://lagune.ai/docs/commands/specialize Sist oppdatert: 2026-11-09 🎓 Lær **Lagune** en ny spesialisering, ut fra en kilde eller et tema du gir den. Kommandoen leser materialet og destillerer det til en fokusert, kun defensiv spesialisering, bygd opp nøyaktig som de [innebygde](https://lagune.ai/no-NO/docs/catalog), slik at fasene detect og verify laster den inn etterpå som alle andre. Den reviderer og forklarer bare: Den skriver aldri angrepsinndata eller exploits, og den rører aldri koden din. **Fra en artikkel** ```prompt # En lenke eller referanse: Lagune destillerer den til forsvaret /lagune-specialize https://owasp.org/www-community/attacks/SQL_Injection ``` **Fra en exploit** ```prompt # Et angrep som kilde: Spesialiseringen er fortsatt forsvaret /lagune-specialize "' OR 1=1 -- skjøter SQL inn i spørringsteksten" ``` **Fra et tema** ```prompt # Eller bare si hva den skal dekke /lagune-specialize SQL injection ``` **Et angrep kan være kilden, aldri resultatet** Det er greit å peke kommandoen mot et angrep når målet er å forsvare seg mot det: En beskrivelse av en exploit er studiemateriale den destillerer til forsvaret. Spesialiseringen den produserer, reviderer og forklarer alltid, og den produserer aldri en fungerende exploit, payload eller omgåelse. ## Hva den skriver Resultatet er to filer i prosjektet ditt, committet og mulige å gå gjennom sammen med koden din: - Spesialiseringen i `.lagune/catalog/.md`, bygd opp som de [innebygde](https://lagune.ai/no-NO/docs/catalog). - Oppføringen for den i `.lagune/configs.json`, der prosjektet ditt indekserer sine egne spesialiseringer, slik at katalogen kan slå dem sammen med de innebygde. Deretter lister den opp katalogen for å bekrefte at den nye oppføringen er der. Dine egne spesialiseringer er alltid i katalogen, uansett hvilke kategorier den har. Du legger aldri til en kommando eller rører pakken: Et nytt spesialfelt er én kunnskapsfil pluss én indeksoppføring, skrevet inn i ditt eget prosjekt. ## Forbedre, aldri overskrive Spesialiserer du et navn som allerede finnes, enten en innebygd som `regex` eller en du har spesialisert før, blir den gjeldende filen **avstemt** i stedet for erstattet. Den leser det som finnes, arbeider inn den nye kunnskapen, beholder det som fortsatt gjelder, og skriver om det som har endret seg. Ingenting blir forkastet uten at det er sett. En spesialisering du har laget, overstyrer en innebygd med samme navn, så du kan skjerpe en innebygd for ditt eget prosjekt uten å miste den. **Tips** - Den nye spesialiseringen lastes inn nøyaktig som en innebygd: Fasene detect og verify henter den ved behov, eller du laster den inn selv med `npx lagune read catalog ` og gir den en oppgave. - Når materialet har et identifiserbart opphav (en artikkel, en forfatter, en lenke, en standard), krediterer spesialiseringen det. Et rent tema har ingen kilde. **Merk** **Den kjører bare når du kaller den:** Agenten starter den aldri på egen hånd. ## Vanlige spørsmål ### Hvordan legger jeg til en egen sikkerhetsspesialisering? Kjør /lagune-specialize med en kilde eller et tema. Den destillerer det til en kun defensiv spesialisering, skrevet til .lagune/catalog/.md, pluss oppføringen for den i .lagune/configs.json. ### Kan Lagune lære av en beskrivelse av en exploit? Ja, som kilde, aldri som resultat. Et angrep kan være kilden, aldri produktet. Specialize skriver aldri angrepsinndata eller exploits. ### Overskriver specialize de innebygde spesialiseringene? Nei. Den forbedrer og overskriver aldri. --- # /lagune-prove: kun defensiv proof of concept > Gjør hvert oppdaget funn om til en kjørbar, kun defensiv proof of concept (PoC) og et sikkerhetsvarsel for ansvarlig varsling. Kanonisk URL: https://lagune.ai/no-NO/docs/commands/prove Språk: no-NO Original: https://lagune.ai/docs/commands/prove Sist oppdatert: 2026-11-09 🧪 Gjør hvert oppdaget funn om til kjørbart, kun defensivt belegg for ansvarlig varsling. For hvert funn i kartleggingen fra detect skriver kommandoen et selvstendig sikkerhetsvarsel og en test som bekrefter den **sikre veien**, slik at testen feiler så lenge problemet finnes, og går gjennom når koden er utbedret. **Tips** Testene fra **Lagune** ligger isolert under `.lagune/`, atskilt fra din egen testsuite. ## Bruk **Hvert funn** ```prompt /lagune-prove ``` **Et navngitt funn** Se funnene som allerede er sporet, med navn: ```prompt npx lagune read list --findings # Findings # ... # • SQL injection i brukeroppslag # ... ``` ```prompt # Bevis deretter ett av dem /lagune-prove SQL injection i brukeroppslag ``` ## Slik fungerer det Kommandoen leser kildekoden hvert funn peker på, og skriver én mappe per bevist funn under `.lagune/proofs/`, med nøyaktig to filer: | Fil | Hva den er | | -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | | `report.test.mjs` (eller `.cjs`) | Testen. Den kjører med Poku når prosjektet ditt allerede bruker Poku, ellers med den innebygde testkjøreren i Node.js, så ingenting må installeres. | | `report.md` | Et selvstendig sikkerhetsvarsel: alvorlighetsgrad, konsekvens, hvordan problemet reproduseres og kommandoen for å kjøre testen, lesbart på egen hånd. | Bevisene er alltid i JavaScript, så de er portable uansett hvilket språk prosjektet ditt er skrevet i. En indeks i `README.md` lenker til hvert bevis og gir én enkelt kommando for å kjøre alle. **Tips** - Den er **valgfri og selvstendig**: ikke en av de fem fasene, og ikke en del av sporingskjeden. - Den skriver bare i `.lagune/proofs/` og rører aldri fasenes artefakter eller koden din, som den bare leser. - Et funn der testen ikke reproduserer problemet, får ikke noe bevis, og kommandoen ber deg kjøre [`/lagune-detect`](https://lagune.ai/no-NO/docs/commands/detect) på det stedet for å avstemme. - Kjører du den på nytt, blir bevisene avstemt: Et funn som er borte eller ikke lenger lar seg reprodusere, får mappen sin fjernet. **Merk** **Den kjører bare når du kaller den:** Agenten starter den aldri på egen hånd. **Bygger på detect** Prove leser kartleggingen fra [`/lagune-detect`](https://lagune.ai/no-NO/docs/commands/detect), så kjør detect først. ## Kun defensiv og autorisert Før kommandoen genererer noe, bekrefter den at du har tillatelse til å teste målet, og den avviser enhver forespørsel om en fungerende exploit, en payload for angrep eller omgåelse av deteksjon. Et bevis demonstrerer den sikre oppførselen, det sender aldri ut angrepsinndata. ## Fra bevis til varsling De to filene for hvert bevist funn hører sammen i en **privat GitHub Gist** når du skal rapportere sårbarheten. De er belegg for et aktivt problem som ikke er offentliggjort, så en `.gitignore` i `.lagune/proofs/` holder dem utenfor hver commit: Del dem bare gjennom den Gisten til vedlikeholderne har løst problemet. Å lukke et funn i kjeden i **Lagune** er fortsatt jobben til [`/lagune-harden`](https://lagune.ai/no-NO/docs/commands/harden) og [`/lagune-verify`](https://lagune.ai/no-NO/docs/commands/verify): Prove produserer belegg, den lukker ingenting. ## Vanlige spørsmål ### Lager Lagune exploits? Nei. /lagune-prove skriver kun defensivt belegg: en test som bekrefter den sikre veien, slik at den feiler så lenge problemet finnes, og går gjennom når koden er utbedret, pluss et sikkerhetsvarsel for ansvarlig varsling. ### Hva lager prove? To filer per funn: en test (report.test.mjs eller .cjs) og et sikkerhetsvarsel (report.md). ### Hvordan varsler jeg ansvarlig om en sårbarhet Lagune har funnet? Prove skriver et selvstendig sikkerhetsvarsel du kan dele gjennom en privat kanal, for eksempel en privat GitHub Gist, i tråd med ansvarlig varsling. --- # Konfigurer hookene: Velg hva de skanner > Velg hva hookene som skanner filer, utelater, for alle eller for én av dem. Kanonisk URL: https://lagune.ai/no-NO/docs/hooks/configure Språk: no-NO Original: https://lagune.ai/docs/hooks/configure Sist oppdatert: 2026-11-09 Blokken `checkers` i `.lagune/configs.json` bestemmer hva hookene som skanner filer, utelater, for alle eller for én av dem. ## Konfigurer Legg til eller fjern stier og mønstre fra kommandolinjen, og sett et mønster i anførselstegn, så skallet lar det stå slik 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 velg dem under Settings i [dashbordet](https://lagune.ai/no-NO/docs/get-started/dashboard), eller angi dem i filen: ```json { "checkers": { "ignore": ["test/fixtures"], "secrets": { "gitignore": false, "ignore": ["test/fixtures", "temp"] } } } ``` ### Innstillinger | Nøkkel | Verdi | Standard | Beskrivelse | | ----------- | ------------------------------------- | -------- | -------------------------------------------------------------------------------------- | | `gitignore` | `true` eller `false` | `true` | Utelater det **Git** ignorerer. En fil som **Git** sporer, skannes uansett. | | `ignore` | stier eller mønstre fra prosjektroten | `[]` | Utelater det hver oppføring treffer, og alt under den, også en fil som **Git** sporer. | Øverst i `checkers` gjelder en nøkkel for alle kontroller. Under navnet på en kontroll gjelder den bare for den kontrollen og erstatter den felles nøkkelen, så i eksempelet skanner `secrets` det **Git** ignorerer, og utelater `test/fixtures` og `temp`. Når `write add --ignore` gir en kontroll dens første egne liste, starter listen som en kopi av den felles listen. ### Mønstre Et mønster starter i prosjektroten, så `*.generated.ts` når bare filene der, mens `**/*.generated.ts` når dem på alle nivåer. Navn må stemme nøyaktig, også når det gjelder store og små bokstaver. | Mønster | Utelater | | ------------------- | ---------------------------------------------- | | `dist` | `dist` i prosjektroten | | `packages/*/dist` | `dist` i hver mappe under `packages` | | `**/dist` | hver `dist`, på alle nivåer | | `**/*.generated.ts` | hver fil der navnet slutter på `.generated.ts` | | `fixture-?` | `fixture-a`, `fixture-1` og lignende | | `[ab]-cache` | `a-cache` og `b-cache` | | `[*]x` | `*x`, med en bokstavelig `*` | ## Slik leser du resultatet Rapporten avsluttes med hvor mange stier gjennomgangen utelot, fordelt på hva som 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 du angir med `--dir` eller `--file`, skannes uansett hva innstillingene sier. En innstilling motoren ikke kan lese, stopper kontrollen med en feil som navngir den, for eksempel et mønster som starter med `!` eller et mellomrom, går ut av prosjektet, lar en hakeparentes stå åpen eller tar for lang tid å matche. ## Vanlige spørsmål ### Setter Lagune disse innstillingene for meg? Nei. Fasen charter lister opp mappene som er committet, og som etter dens vurdering ikke er kode du skal forsvare, for eksempel testfixtures som er skrevet for å se sårbare ut, og registrerer bare dem du velger med nummer. ### Når bør en kontroll skanne det Git ignorerer? Når du ikke har grunn til å stole på repositoryet, siden dets egne .gitignore-filer kan skjule kode, eller når en build-mappe kan inneholde en nøkkel som ble bygd inn ved bygging. Sett gitignore til false for alle kontroller eller for én av dem. --- # Hook agent: Oppdag agentløkker uten grense > Skann en kodebase for agent- og LLM-kall uten grense for steg eller tid, eller vurder ett enkelt kall, rett fra kommandolinjen. Kanonisk URL: https://lagune.ai/no-NO/docs/hooks/agent Språk: no-NO Original: https://lagune.ai/docs/hooks/agent Sist oppdatert: 2026-11-09 Hooken `agent` flagger **agentkjøretider som går i løkke uten grense for runder, budsjett eller tid**, hullet for løpsk autonomi som gjør en manipulert inndata om til ubegrensede kostnader eller eskalering via prompt injection. Den er **språkbevisst** og dekker de to økosystemene for agentrammeverk: **JavaScript** (kjøretiden `query` i agent-SDK-en til **Claude**) og **Python** (**LangChain**, **LangGraph**, **CrewAI**, **OpenAI Agents**). Den er den deterministiske motoren bak [spesialiseringen `llm`](https://lagune.ai/no-NO/docs/catalog), som du kan kjøre selv i modusen **scan** eller **check**. ## Kjør **Skann 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 ``` **Sjekk et kall** ```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 som importerer en agent-SDK, enten et kall til kjøretiden `query` i agent-SDK-en til Claude uten grense for runder, budsjett eller tid (JavaScript, ubegrenset som standard), eller en eksplisitt fjerning av standardgrensen i et rammeverk, for eksempel `max_iterations=None` / `max_turns=None` (Python, begrenset som standard). Begge avslutter med en kode som ikke er null. I Vercel AI SDK bruker `generateText`/`streamText` ett enkelt steg som standard (`stopWhen: stepCountIs(1)`), så et kall uten innstillinger der kan ikke gå i løkke og flagges ikke, og et vanlig `db.query(...)` forveksles aldri med et agentkall. En gjennomgang uten funn skriver ut `no uncapped agent loops found`. ## Slik leser du konklusjonen | Konklusjon | Betydning | | ---------- | ----------------------------------------------------------------------------------------------------------------------------------- | | `uncapped` | Et kall til kjøretiden `query` uten grense (JS), eller en eksplisitt fjerning av grensen (`=None`, Py). | | `safe` | Et kall til `query` som setter en grense, en generering med ett enkelt steg, eller et rammeverkskall som er begrenset som standard. | | `invalid` | Kodeutdraget inneholder ikke noe gjenkjennelig agentkall å vurdere. | ### CLI-alternativer | Alternativ | Verdi | Beskrivelse | | ----------- | ------------- | -------------------------------------------------------------------------------- | | `--pattern` | et kodeutdrag | Sjekk ett kall. Gjenta for å sjekke flere, én konklusjon per linje. | | `--lang` | et språk | Påkrevd med `--pattern`: `javascript` eller `python`. | | `--dir` | en mappe | Avgrens en gjennomgang til en mappe. Kan gjentas og kombineres med `--file`. | | `--file` | en fil | Avgrens en gjennomgang til én enkelt fil. Kan gjentas og kombineres med `--dir`. | Uten alternativ skanner den hele prosjektet. `--pattern` krever `--lang` og kan ikke kombineres med `--dir` eller `--file`. ### Velg hva den skanner Den utelater det **Git** ignorerer. For å utelate mer, eller for å skanne det **Git** ignorerer, gi `agent` egne innstillinger: ```bash npx lagune write add --ignore test/fixtures --checker agent ``` ```json { "checkers": { "agent": { "gitignore": false, "ignore": ["test/fixtures"] } } } ``` [Konfigurer hookene](https://lagune.ai/no-NO/docs/hooks/configure) beskriver hver innstilling. **Etter beste evne, ikke uttømmende** En egenutviklet agentløkke, i et hvilket som helst språk, er utenfor rekkevidden til en statisk gjennomgang. Se på dette som et solid minimum, ikke en fullstendig oversikt. **Tips** Hooken avgjør bare grensen: avgrensning av hva agenten kan gjøre, blanding av tillitsnivåer og autorisasjon er skjønnsvurderinger som [spesialiseringen `llm`](https://lagune.ai/no-NO/docs/catalog) fortsatt dekker. ## Vanlige spørsmål ### Hvorfor bør en agentløkke ha en grense? En agent uten grense kan drives inn i ubegrenset rekursjon, ubegrensede kostnader eller eskalering via prompt injection. Å sette maxTurns/maxBudgetUsd/stopWhen/signal begrenser den, og hooken agent flagger et kall til kjøretiden query som ikke setter noen av dem. --- # Hook cors: Revider CORS-origins > Skann kildekoden for en tillatelsesliste for CORS-origins som kan omgås, eller vurder om én enkelt origin-verdi gir for vid tilgang, rett fra kommandolinjen. Kanonisk URL: https://lagune.ai/no-NO/docs/hooks/cors Språk: no-NO Original: https://lagune.ai/docs/hooks/cors Sist oppdatert: 2026-11-09 Hooken `cors` er den deterministiske motoren bak [spesialiseringen `http-request`](https://lagune.ai/no-NO/docs/catalog), og du kan kjøre den selv. Den har to moduser i én kommando: modusen **scan** skanner kildekoden for en **tillatelsesliste for origins som kan omgås** (en regex for vertsvalidering som en angripers vert slipper forbi), og modusen **score** vurderer én enkelt **CORS-origin**-verdi som `wildcard`, `null` eller `safe`. ## Skann en kodebase Uten flagg skanner den hele prosjektet. **Hele prosjektet** ```bash npx lagune read cors ``` **En mappe** ```bash npx lagune read cors --dir src/server ``` **Én enkelt fil** ```bash npx lagune read cors --file internal/auth/origin.go ``` Den lister hver tillatelsesliste som kan omgås under én overskrift, gruppert etter fil. En vertsvalidator der `.+`/`.*` står i authority-delen av URL-en foran suffikset til den klarerte verten (`^https?://.+\.trusted\.com`), slipper gjennom en angripervert som `your-site.com.attacker.com`. ```text Origin-allowlist patterns with a greedy wildcard (bypassable, review): internal/auth/origin.go ^https?://.+\.trusted\.com ``` Dette er et spor å undersøke, ikke et avsluttet funn: om regexen styrer en reell tillitsbeslutning, kan ikke avgjøres ut fra teksten, så en gjennomgang endrer aldri avslutningskoden. Les hvert treff og bekreft at tillatelseslisten sammenligner på full likhet. Når den ikke finner noe, skriver den ut én enkelt linje. ```bash npx lagune read cors --dir src/clean # => no bypassable origin allowlist found ``` ## Vurder en origin Send hver origin med `--origin`. Hooken skriver ut ett ord per origin og avslutter med en kode som ikke er null ved hver `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** Gjenta `--origin` for å vurdere en hel tillatelsesliste i ett kall, én konklusjon per linje, i samme rekkefølge. ```bash npx lagune read cors \ --origin 'https://app.example.com' \ --origin '*' \ --origin 'null' # => safe # => wildcard # => null ``` | Konklusjon | Betydning | | ---------- | -------------------------------------------------------------------------------------------------- | | `safe` | Verken `*`, `null` eller en glob med `*`. Det garanterer ikke en korrekt utformet origin. | | `wildcard` | `*` eller en glob for underdomene, vert eller port: alle nettsteder (eller mange) kan lese svaret. | | `null` | Originen `null`, som iframes i sandkasse og videresendinger kan forfalske. | Bare `safe` betyr tillatelse, og `--origin` er et orakel for verdier: det vurderer verdien, ikke handleren, så bekreft handleren med spesialiseringen `http-request`. ### CLI-alternativer | Alternativ | Verdi | Beskrivelse | | ---------- | --------- | -------------------------------------------------------------------------------- | | `--origin` | en origin | Vurder én origin-verdi. Gjenta for å vurdere flere, én per linje. | | `--dir` | en mappe | Avgrens en gjennomgang til en mappe. Kan gjentas og kombineres med `--file`. | | `--file` | en fil | Avgrens en gjennomgang til én enkelt fil. Kan gjentas og kombineres med `--dir`. | Uten alternativ skanner den hele prosjektet. `--origin` er modusen score og kan ikke kombineres med `--dir` eller `--file`. ### Velg hva den skanner Den utelater det **Git** ignorerer. For å utelate mer, eller for å skanne det **Git** ignorerer, gi `cors` egne innstillinger: ```bash npx lagune write add --ignore test/fixtures --checker cors ``` ```json { "checkers": { "cors": { "gitignore": false, "ignore": ["test/fixtures"] } } } ``` [Konfigurer hookene](https://lagune.ai/no-NO/docs/hooks/configure) beskriver hver innstilling. **Hva den ikke dekker** Gjennomgangen gjenkjenner formen til en **regex som kan omgås**, og `--origin` vurderer **verdier** for origins. To mønstre i kildekoden er utenfor rekkevidde: speiling av `Origin` fra forespørselen (serveren sender den innkommende `Origin` tilbake uendret, eller kombinerer den med påloggingsdetaljer), og en for romslig tillatelsesliste basert på `endsWith` eller delstrenger. Gjenkjenn dem i koden og håndter dem slik [spesialiseringen `http-request`](https://lagune.ai/no-NO/docs/catalog) beskriver. ## Vanlige spørsmål ### Hvorfor er CORS-originen null farlig? Iframes i sandkasse og enkelte videresendinger sender Origin: null, så en tillatelsesliste som stoler på null, gir disse kontekstene lesetilgang. Hooken cors flagger det sammen med wildcard. ### Hvordan finner jeg en tillatelsesliste for CORS-origins som kan omgås? Kjør npx lagune read cors over kodebasen. Den flagger en regex for vertsvalidering der et grådig wildcard står foran det klarerte suffikset, slik at en angripervert som your-site.com.attacker.com slipper forbi. --- # Hook crypto: Oppdag svak kryptografi > Skann en kodebase for svake kryptografiske primitiver, eller vurder ett enkelt kodeutdrag, rett fra kommandolinjen. Kanonisk URL: https://lagune.ai/no-NO/docs/hooks/crypto Språk: no-NO Original: https://lagune.ai/docs/hooks/crypto Sist oppdatert: 2026-11-09 Hooken `crypto` flagger **svake kryptografiske primitiver** der de kalles: et utfaset chiffer, en usikker modus eller en knekt hashfunksjon. Den er **språkbevisst** og leser hver fil etter sine egne regler, så en Python-konstruksjon aldri flagges i en Rust-fil, og den er den deterministiske motoren bak [spesialiseringen `crypto`](https://lagune.ai/no-NO/docs/catalog), som du kan kjøre selv i modusen **scan** eller **check**. ## Kjør **Skann 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 ``` **Sjekk et kodeutdrag** ```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 ``` Gjennomgangen skriver ut opptil to seksjoner. **Weak cryptography found** inneholder funnene (DES/3DES/RC4/Blowfish/RC2, ECB-modus): hvert er et knekt chifferprimitiv, så hooken avslutter med en kode som ikke er null. **Cryptography to review manually** inneholder spor den ikke kan vurdere alene: en MD5- eller SHA-1-hash (knekt for sikkerhetsbruk, men legitim som en enkel kontrollsum, så det er hensikten som avgjør), en ikke-kryptografisk tilfeldighetsgenerator i en sikkerhetskontekst, eller en sammenligning som er sårbar for tidsangrep. En gjennomgang uten funn skriver ut `no weak cryptography found`. ## Slik leser du konklusjonen | Konklusjon | Betydning | | ---------- | --------------------------------------------------------------------------------------------------------------------------------------- | | `weak` | Kodeutdraget bruker et knekt chifferprimitiv (DES/3DES, RC4, Blowfish, RC2 eller ECB-modus). | | `review` | Et primitiv der hensikten avgjør: en MD5- eller SHA-1-hash, eller en ikke-kryptografisk tilfeldighetsgenerator i en sikkerhetskontekst. | | `safe` | Kodeutdraget bruker kryptografi, og ingen svake primitiver ble funnet. | | `invalid` | Kodeutdraget inneholder ingen gjenkjennelig kryptografisk konstruksjon å vurdere. | ### CLI-alternativer | Alternativ | Verdi | Beskrivelse | | ----------- | ------------- | ------------------------------------------------------------------------------------------------------ | | `--pattern` | et kodeutdrag | Sjekk ett kodeutdrag. Gjenta for å sjekke flere, én konklusjon per linje. | | `--lang` | et språk | Påkrevd med `--pattern`: ett av javascript, python, go, java, kotlin, php, ruby, rust, csharp, c, cpp. | | `--dir` | en mappe | Avgrens en gjennomgang til en mappe. Kan gjentas og kombineres med `--file`. | | `--file` | en fil | Avgrens en gjennomgang til én enkelt fil. Kan gjentas og kombineres med `--dir`. | Uten alternativ skanner den hele prosjektet. `--pattern` krever `--lang` og kan ikke kombineres med `--dir` eller `--file`. ### Velg hva den skanner Den utelater det **Git** ignorerer. For å utelate mer, eller for å skanne det **Git** ignorerer, gi `crypto` egne innstillinger: ```bash npx lagune write add --ignore test/fixtures --checker crypto ``` ```json { "checkers": { "crypto": { "gitignore": false, "ignore": ["test/fixtures"] } } } ``` [Konfigurer hookene](https://lagune.ai/no-NO/docs/hooks/configure) beskriver hver innstilling. ### Støttede språk Gjennomgangen leser disse språkene, gjenkjent på filendelsen, og sjekker hvert mot sine egne kryptografiske API-er. | Språk | Svake chiffer (funn), hashfunksjoner og tilfeldighetsgeneratorer (gjennomgang) | | --------------------------- | -------------------------------------------------------------------------------------------------------------------- | | **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()` | **Etter beste evne, ikke uttømmende** Den leser kildekoden som tekst, så et primitiv som settes sammen under kjøring, er skjult bak et alias eller er skrevet i en form den ikke gjenkjenner, kan slippe gjennom. Se på tabellen som et solid utgangspunkt, ikke en fullstendig oversikt. **Tips** Hooken garanterer minimumet (at disse konstruksjonene finnes): nøkkelhåndtering, gjenbruk av IV-er og RSA-padding er skjønnsvurderinger som [spesialiseringen `crypto`](https://lagune.ai/no-NO/docs/catalog) fortsatt dekker. ## Vanlige spørsmål ### Hvordan skanner jeg en kodebase for svak kryptografi? Kjør hooken crypto uten flagg. Knekte chiffer og ECB-modus er funn som avslutter med en kode som ikke er null. En MD5- eller SHA-1-hash er et spor å gjennomgå, siden den er knekt for sikkerhetsbruk, men legitim som en enkel kontrollsum. ### Flagger hooken crypto Math.random()? Bare som et spor å gjennomgå i en sikkerhetskontekst, aldri som et automatisk funn, siden tilfeldighet er legitimt for jitter eller rekkefølge i brukergrensesnittet. --- # Hook cvss: Vurder en CVSS v4.0-vektor > Vurder én eller flere CVSS v4.0-vektorer fra kommandolinjen, med samme beregning som kalkulatoren til FIRST, og få hver av dem forklart med enkle ord. Kanonisk URL: https://lagune.ai/no-NO/docs/hooks/cvss Språk: no-NO Original: https://lagune.ai/docs/hooks/cvss Sist oppdatert: 2026-11-09 Hooken `cvss` vurderer en **CVSS v4.0-vektor** og skriver ut scoren og alvorlighetsgraden, den vurderingen [`/lagune-plan`](https://lagune.ai/no-NO/docs/commands/plan) skriver på hver utbedring og [`/lagune-prove`](https://lagune.ai/no-NO/docs/commands/prove) på hvert sikkerhetsvarsel. Den er den deterministiske motoren bak disse vurderingene, med samme beregning som [kalkulatoren til FIRST](https://www.first.org/cvss/calculator/4.0), og du kan kjøre den selv. ## Kjør Send hver vektor med `--vector`. Hooken skriver ut én linje per vektor: scoren og alvorlighetsgraden. **É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** Gjenta `--vector` for å vurdere flere samtidig, én linje hver, i samme rekkefø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 ``` **Med enkle ord** Legg til `--explain` for å få hver metrikk forklart med enkle ord. Når Threat- eller Environmental-metrikker endrer 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 # => ... ``` ## Slik leser du resultatet | Alvorlighetsgrad | 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 bare Base-metrikker vurderer selve sårbarheten og antar det verste: at hvert sikkerhetskrav er High, og at sårbarheten angripes i praksis. Environmental-metrikker (`MAV` og de andre modifiserte metrikkene, pluss `CR`, `IR` og `AR`) tilpasser den til én konkret utrulling, og Threat-metrikken (`E`) til det som er kjent om utnyttelse. En ugyldig vektor skriver ut `invalid vector:` og hva som er galt, og hooken avslutter med en kode som ikke er null. ### CLI-alternativer | Alternativ | Verdi | Beskrivelse | | ----------- | -------------------- | -------------------------------------------------------------------------------------- | | `--vector` | en `CVSS:4.0`-vektor | Vurder én vektor. Gjenta for å vurdere flere, én linje per vektor, i samme rekkefølge. | | `--explain` | | Legg til hver metrikk med enkle ord under hver vurderingslinje. | Minst én `--vector` er påkrevd. Vektoren er aldri et frittstående posisjonsargument, så den kan ikke forveksles med et flagg. **Hvorfor en flaggverdi** Hver vektor sendes som verdien til et flagg og interpoleres aldri inn i kommandoen. En verdi med anførselstegn eller backticks forblir uvirksom og kan ikke injisere noe i skallet. Sett den alltid i enkle anførselstegn, så skallet ditt ikke ekspanderer den først. **Hva den ikke dekker** Bare CVSS v4.0: en vektor i v2.0, v3.0 eller v3.1 avvises i stedet for å vurderes, siden **Lagune** vurderer hvert funn i v4.0. **Tips** Valideringen i fasen plan kjører den samme beregningen på nytt for hver CVSS-linje, så en score som har drevet bort fra vektoren sin, fanges opp før planen godtas. ## Vanlige spørsmål ### Hvordan beregner Lagune en CVSS-score? Hooken cvss følger referansekalkulatoren til FIRST for CVSS v4.0, så en vektor får nøyaktig samme score som på nettstedet til FIRST. ### Kan jeg vurdere en CVSS v3.1-vektor med den? Nei. Lagune vurderer hvert funn i CVSS v4.0, og hooken avviser alle andre versjoner i stedet for å vurdere dem. ### Hva gjør flagget --explain? Det forklarer hver metrikk med enkle ord og viser Base-scoren ved siden av totalscoren, så alle kan se hva vektoren sier og hvordan prosjektets kontekst har endret den. --- # Hook infra: Oppdag feilkonfigurasjon i IaC > Skann Terraform, Dockerfiles og GitHub Actions etter feilkonfigurasjon, eller vurder ett enkelt kodeutdrag, rett fra kommandolinjen. Kanonisk URL: https://lagune.ai/no-NO/docs/hooks/infra Språk: no-NO Original: https://lagune.ai/docs/hooks/infra Sist oppdatert: 2026-11-09 Hooken `infra` flagger **feilkonfigurasjon i infrastruktur som kode** som kan avgjøres ut fra selve filen: et nettverk som er åpent for hele verden, en tillatelse med jokertegn, en hemmelighet i et manifest, en container som kjører som root, en ikke-klarert verdi i et CI-skall. Den leser bare IaC-filer (`.tf`/`.tf.json`/`.hcl`, `Dockerfile*`, `.github/workflows/**`). Den er den deterministiske motoren bak [spesialiseringen `infra`](https://lagune.ai/no-NO/docs/catalog), i modusen **scan** eller **check**. ## Kjør **Skann 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 ``` **Sjekk et kodeutdrag** Oppgi kodeutdraget med `--pattern` og typen 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 ``` Gjennomgangen skriver ut opptil to seksjoner. **Infrastructure risks found** avslutter med en exit-kode som ikke er null, og inneholder feilene som kan avgjøres (en ingress fra `0.0.0.0/0` på en sensitiv port, en IAM-setning med jokertegn, en hemmelighet i et manifest, `encrypted = false`, en git-modul som ikke er låst til en versjon, et image som eksplisitt kjører som root, en `curl | sh`, en skriptinjeksjon i CI, `permissions: write-all`). **Infrastructure hardening advisories** endrer ikke exit-koden (en foranderlig basistagg, en action som bare er låst til en tagg). Finner den ingenting, skriver den ut `no infrastructure risks found`. ## Slik leser du konklusjonen Modusen check skriver ut taggen med høyest alvorlighetsgrad som den traff (for eksempel `public-ingress`, `iam-wildcard`, `root-user`, `curl-pipe`, `script-injection`, `write-all`), en anbefalingstagg (`mutable-tag`, `unpinned-action`) eller `safe`. Bare en tagg med alvorlighetsgraden til et funn avslutter med en exit-kode som ikke er null. ### CLI-alternativer | Alternativ | Verdi | Beskrivelse | | ----------- | ----------------------------------------------- | --------------------------------------------------------------------------- | | `--pattern` | et kodeutdrag | Sjekk ett kodeutdrag. Krever `--kind`. Gjenta for flere. | | `--kind` | `terraform` \| `dockerfile` \| `github-actions` | Typen kodeutdraget vurderes som. | | `--dir` | en mappe | Avgrens gjennomgangen til en mappe. Kan gjentas og kombineres med `--file`. | | `--file` | en fil | Avgrens gjennomgangen til én fil. Kan gjentas og kombineres med `--dir`. | Uten alternativer skanner den alle IaC-filer i prosjektet. `--pattern` kan ikke kombineres med `--dir` eller `--file`. ### Velg hva den skanner Den utelater det **Git** ignorerer. For å utelate mer, eller for å skanne det **Git** ignorerer, gi `infra` egne innstillinger: ```bash npx lagune write add --ignore examples --checker infra ``` ```json { "checkers": { "infra": { "gitignore": false, "ignore": ["examples"] } } } ``` [Konfigurer hookene](https://lagune.ai/no-NO/docs/hooks/configure) dekker alle innstillingene. **Tips** Hooken fanger de opplagte tilfellene som kan avgjøres: Manglende kryptering, eksponering via `pull_request_target` og riktig IAM-omfang er vurderinger som [spesialiseringen `infra`](https://lagune.ai/no-NO/docs/catalog) fortsatt dekker. ## Vanlige spørsmål ### Hvilke infrastrukturfiler leser hooken infra? Terraform og HCL (.tf, .tf.json, .hcl), Dockerfiles og workflow- og action-YAML for GitHub Actions under .github/. Den når disse filene selv om skannerne for kildekode hopper over dem. --- # Hook interpreter: Flagg sinks for dynamisk kodekjøring > Skann en kodebase etter sinks for dynamisk kodekjøring på tvers av språk, eller vurder ett enkelt kodeutdrag, rett fra kommandolinjen. Kanonisk URL: https://lagune.ai/no-NO/docs/hooks/interpreter Språk: no-NO Original: https://lagune.ai/docs/hooks/interpreter Sist oppdatert: 2026-11-09 Hooken `interpreter` flagger **sinks for dynamisk kodekjøring**: konstruksjoner som gjør data om til kode som kjører, eller sender dem videre til et skall, fra `eval` til native deserialisering. Den er språkbevisst og leser hver fil etter dens egne regler. Den er den deterministiske motoren bak [spesialiseringen `interpreter`](https://lagune.ai/no-NO/docs/catalog), og du kan kjøre hooken selv i modusen **scan** eller **check**. ## Kjør **Skann 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 ``` **Sjekk et kodeutdrag** ```bash npx lagune read interpreter --lang javascript --pattern 'eval(x)' # => careful npx lagune read interpreter --lang python --pattern 'json.loads(x)' # => safe ``` Disse sinkene har dobbel bruk: Om input som en angriper kan påvirke, når en av dem, kan ikke en statisk gjennomgang avgjøre, så hvert treff er en **advarsel til gjennomsyn**, aldri et bekreftet funn. Gjennomgangen skriver ut én enkelt seksjon, **Dynamic-execution sinks to review**, gruppert etter fil. Finner den ingenting, skriver den ut `no dynamic-execution sinks found`. **Les den flaggede koden, kjør den aldri!** Vurder hver sink **statisk** ved å spore om ikke-klarert input når den. Kjør aldri den flaggede koden og send den aldri til `eval`, heller ikke kode den henter inn eksternt eller under kjøring, for å "teste" hva den gjør. ## Slik leser du konklusjonen | Konklusjon | Betydning | | ---------- | ------------------------------------------------------------------------------------------------------------------------ | | `careful` | Kodeutdraget inneholder en sink for dynamisk kjøring i sitt språk. Gå gjennom den ved å lese den, aldri ved å kjøre den. | | `safe` | Ingen sink for dynamisk kjøring ble funnet for det angitte språket. | ### CLI-alternativer | Alternativ | Verdi | Beskrivelse | | ----------- | ------------- | ------------------------------------------------------------------------------------------------------ | | `--pattern` | et kodeutdrag | Sjekk ett kodeutdrag. Gjenta for å sjekke flere, én konklusjon per linje. | | `--lang` | et språk | Påkrevd med `--pattern`: ett av javascript, python, php, ruby, java, kotlin, go, rust, c, cpp, csharp. | | `--dir` | en mappe | Avgrens gjennomgangen til en mappe. Kan gjentas og kombineres med `--file`. | | `--file` | en fil | Avgrens gjennomgangen til én fil. Kan gjentas og kombineres med `--dir`. | Uten alternativer skanner den hele prosjektet. `--pattern` krever `--lang` og kan ikke kombineres med `--dir` eller `--file`. ### Velg hva den skanner Den utelater det **Git** ignorerer. For å utelate mer, eller for å skanne det **Git** ignorerer, gi `interpreter` egne innstillinger: ```bash npx lagune write add --ignore test/fixtures --checker interpreter ``` ```json { "checkers": { "interpreter": { "gitignore": false, "ignore": ["test/fixtures"] } } } ``` [Konfigurer hookene](https://lagune.ai/no-NO/docs/hooks/configure) dekker alle innstillingene. ### Støttede språk Gjennomgangen leser disse språkene, gjenkjent etter filendelse, og sjekker hvert av dem mot sitt eget sett med sinks for dynamisk kjøring. | # | Språk | Filendelser | Sinks den flagger | | --- | --------------------------- | ------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 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 kropp, modulen `vm`, exec i `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()`, skallkjøring (`system`/`exec`/`shell_exec`/`passthru`/`popen`/`proc_open`), `call_user_func`/`call_user_func_array`, `include`/`require` med en sti satt sammen under kjøring | | 6 | **Rust** | `.rs` | `Command::new`, `process::Command` | | 7 | **Java** | `.java` | `Runtime.exec`, `ProcessBuilder`, `ScriptEngine`, `ObjectInputStream.readObject` | | 8 | **Kotlin** | `.kt`, `.kts` | JVM-sinkene: `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`, …) | **Etter beste evne, ikke uttømmende** Den leser kildekoden som tekst, så en sink som settes sammen under kjøring, skjules bak et alias eller skrives i en form den ikke kjenner igjen, kan slippe gjennom. Se på tabellen som et solid utgangspunkt, ikke som en fullstendig oversikt. **Tips** Hooken garanterer minimumet (at disse sinkene finnes, og hvor): Om en ikke-klarert verdi faktisk når en av dem, er vurderingen som [spesialiseringen `interpreter`](https://lagune.ai/no-NO/docs/catalog) dekker. ## Vanlige spørsmål ### Bekrefter hooken interpreter en sårbarhet? Nei. Den flagger sinks for dynamisk kjøring som en advarsel til gjennomsyn, aldri som et bekreftet funn, fordi en statisk gjennomgang ikke kan avgjøre om input som en angriper kan påvirke, når sinken. ### Hvilke språk dekker hooken interpreter? Den leser språkene i tabellen "Støttede språk", gjenkjent etter filendelse, og sjekker hvert av dem mot sitt eget sett med sinks. Andre språk gir ingen sinks. --- # Hook jwt: Oppdag JWT-verifisering uten låst algoritme > Skann en kodebase etter JWT-verifisering uten låst algoritme, eller vurder ett enkelt kall, rett fra kommandolinjen. Kanonisk URL: https://lagune.ai/no-NO/docs/hooks/jwt Språk: no-NO Original: https://lagune.ai/docs/hooks/jwt Sist oppdatert: 2026-11-09 Hooken `jwt` flagger **JWT-verifisering uten låst algoritme**, hullet for algorithm confusion der en verifikator stoler på tokenets egen header `alg`, og **verifisering som er slått helt av**. Den er **språkbevisst** og leser hver fil ut fra JWT-biblioteket den bruker. Den er den deterministiske motoren bak [spesialiseringen `federation`](https://lagune.ai/no-NO/docs/catalog), og du kan kjøre hooken selv i modusen **scan** eller **check**. ## Kjør **Skann 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 ``` **Sjekk et kall** ```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 verifiseringskall som ikke angir noen tillatelsesliste `algorithms` (der biblioteket trenger en), som godtar en usikker liste (`none`, eller en asymmetrisk algoritme blandet med HMAC), eller som slår av signatursjekken helt og dermed stoler på tokenets egen `alg`. Det er en bekreftet eksponering, så hooken avslutter med en exit-kode som ikke er null. Finner den ingenting, skriver den ut `no unpinned JWT verification found`. ## Slik leser du konklusjonen | Konklusjon | Betydning | | ---------- | -------------------------------------------------------------------------------------------------------------------------------- | | `unpinned` | Et verifiseringskall uten tillatelsesliste for algoritmer (der en trengs), med en usikker liste eller med verifisering slått av. | | `safe` | Et verifiseringskall som låser en trygg tillatelsesliste for algoritmer, eller der biblioteket låser den implisitt. | | `invalid` | Kodeutdraget inneholder ikke noe gjenkjennelig verifiseringskall å vurdere. | ### CLI-alternativer | Alternativ | Verdi | Beskrivelse | | ----------- | ------------- | ---------------------------------------------------------------------------------------------- | | `--pattern` | et kodeutdrag | Sjekk ett kall. Gjenta for å sjekke flere, én konklusjon per linje. | | `--lang` | et språk | Påkrevd med `--pattern`: ett av javascript, python, go, java, kotlin, php, ruby, rust, csharp. | | `--dir` | en mappe | Avgrens gjennomgangen til en mappe. Kan gjentas og kombineres med `--file`. | | `--file` | en fil | Avgrens gjennomgangen til én fil. Kan gjentas og kombineres med `--dir`. | Uten alternativer skanner den hele prosjektet. `--pattern` krever `--lang` og kan ikke kombineres med `--dir` eller `--file`. ### Velg hva den skanner Den utelater det **Git** ignorerer. For å utelate mer, eller for å skanne det **Git** ignorerer, gi `jwt` egne innstillinger: ```bash npx lagune write add --ignore test/fixtures --checker jwt ``` ```json { "checkers": { "jwt": { "gitignore": false, "ignore": ["test/fixtures"] } } } ``` [Konfigurer hookene](https://lagune.ai/no-NO/docs/hooks/configure) dekker alle innstillingene. ### Støttede språk Gjennomgangen leser disse bibliotekene, gjenkjent etter filendelse. Fordi noen av dem låser algoritmen implisitt (der holder det uten en eksplisitt liste), gjelder regelen "ingen tillatelsesliste ⇒ unpinned" bare der biblioteket forventer en eksplisitt liste, så et riktig konfigurert kall blir aldri flagget. | Språk | Bibliotek | Flagger manglende tillatelsesliste som unpinned? | Flagger alltid | | --------------------------- | ----------------------- | --------------------------------------------------------------------- | ------------------------------------------------- | | **JavaScript / TypeScript** | jsonwebtoken, jose | Ja | `none`, blanding av asymmetrisk og HMAC | | **Python** | PyJWT, python-jose | Ja (PyJWT krever den, python-jose har `algorithms=None` som standard) | `none`, `verify_signature: False` | | **Go** | golang-jwt | Ja (uten `WithValidMethods`) | `none`, `ParseUnverified` | | **Ruby** | ruby-jwt | Ja | `none`, `verify = false` | | **Java / Kotlin** | jjwt, nimbus | Nei (utledet fra nøkkelen) | `none`, en parser uten signatur eller `unsecured` | | **PHP** | firebase/php-jwt | Nei (`Key` bærer algoritmen) | `none` | | **Rust** | jsonwebtoken | Nei (`Validation` krever en) | `none`, `insecure_disable_signature_validation` | | **C#** | Microsoft.IdentityModel | Nei (parametere over flere linjer) | `none`, `RequireSignedTokens = false` | **Tips** Hooken avgjør bare om algoritmen er låst: Sjekkene av claims, nøkler og flyt er vurderinger som [spesialiseringen `federation`](https://lagune.ai/no-NO/docs/catalog) fortsatt dekker. ## Vanlige spørsmål ### Hva er algorithm confusion i JWT? En verifikator som leser algoritmen fra headeren i tokenet, lar en angriper bytte RS256 med HS256 og signere med den offentlige nøkkelen. En trygg tillatelsesliste for algoritmer, låst i koden, hindrer det, og hooken jwt flagger et verifiseringskall som ikke angir noen liste, eller som angir en usikker liste. --- # Hook network: Vurder URL-er for SSRF > Vurder SSRF-risikoen for én eller flere destinasjoner for forespørsler, rett fra kommandolinjen. Kanonisk URL: https://lagune.ai/no-NO/docs/hooks/network Språk: no-NO Original: https://lagune.ai/docs/hooks/network Sist oppdatert: 2026-11-09 Hooken `network` avgjør om destinasjonen for en forespørsel fra serversiden er trygg mot **SSRF** (en forespørsel som kan rettes mot interne tjenester, metadata i skyen eller private verter). Den er den deterministiske motoren bak [spesialiseringen `network`](https://lagune.ai/no-NO/docs/catalog), og du kan kjøre den selv. ## Kjør Oppgi hver destinasjon med `--url`. Hooken skriver ut ett ord per destinasjon, forklart i tabellen nedenfor. **Én destinasjon** ```bash npx lagune read network --url 'http://example.com/' # => safe npx lagune read network --url 'http://0x7f000001/' # => private-target ``` **Flere destinasjoner** Gjenta `--url` for å vurdere en hel tillatelsesliste eller blokkeringsliste i ett kall, én konklusjon per linje, i samme rekkefø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 tolker verten slik nettverket gjør, så kodede former av en intern adresse slipper ikke gjennom: Heksadesimal, oktal, desimal uten punktum, forkortet, IPv6 og IPv4-mappet form gir alle `private-target`. Og der en slurvete validator og klienten som faktisk henter, ville lest ulike verter, er konklusjonen `parser-divergent`. ## Slik leser du konklusjonen | Konklusjon | Betydning | | ------------------ | ----------------------------------------------------------------------------------------------------------------------------------------- | | `safe` | Destinasjonen kobler til en offentlig vert, og en slurvete validator ville lest den samme verten. | | `private-target` | Verten peker til en privat adresse, en loopback-adresse, en link-local-adresse, en uspesifisert adresse eller en metadataadresse i skyen. | | `parser-divergent` | En slurvete tekstvalidator ville lest en annen reell vert enn den klienten kobler til. | | `invalid url` | Strengen kan ikke tolkes som en URL, så det finnes ingenting å hente. | Bare `safe` betyr tillat. Behandle `private-target`, `parser-divergent` og `invalid url` alle som blokkering. ### CLI-alternativer | Alternativ | Verdi | Beskrivelse | | ---------- | ----------------- | ------------------------------------------------------------------------- | | `--url` | en URL eller vert | Sjekk én destinasjon. Gjenta for å sjekke flere, én konklusjon per linje. | Minst én `--url` er påkrevd. Destinasjonen er aldri et frittstående posisjonsargument, så den kan ikke forveksles med et flagg. **Hvorfor som verdi til et flagg** Hver destinasjon sendes som verdien til et flagg og blir aldri interpolert inn i kommandoen. En verdi med anførselstegn eller backticks forblir uvirksom og kan ikke injisere noe i skallet. Sett den alltid i enkle anførselstegn, så skallet ditt ikke ekspanderer den først. **Hva den ikke dekker** Hooken er ren og slår aldri opp i DNS, så to hull som oppstår under kjøring, er utenfor omfanget: **DNS rebinding** (et navn som peker til en offentlig adresse når det sjekkes, og til en intern når det hentes) og **omdirigeringskjeder** (et første hopp som består sjekken, og deretter omdirigerer innover). Lukk dem ved å slå opp én gang og koble til den validerte adressen, og ved å avvise omdirigeringer. Den låser de reserverte loopback-navnene (`localhost` og familien `.localhost`) til internt uten oppslag, men alle andre DNS-navn gir `safe`, fordi det å fastslå at et navn peker innover, ville krevd et oppslag: Tillatelseslisten beskytter disse navnene, og det er den denne kontrollen validerer. **Tips** Dette er den samme sjekken som [spesialiseringen `network`](https://lagune.ai/no-NO/docs/catalog) kjører for å bevise at et destinasjonsfilter holder. ## Vanlige spørsmål ### Hvordan tester jeg en URL for SSRF? Kjør hooken network. Den vurderer destinasjonen for en forespørsel og returnerer safe, private-target, parser-divergent eller invalid url. Bare safe betyr tillat. ### Hva er en URL av typen parser-divergent? En URL som ulike parsere leser forskjellig, en klassisk måte å omgå SSRF-beskyttelse på. Hooken network flagger den i stedet for å tillate den. --- # Hook regex: Oppdag ReDoS-mønstre > Skann en kodebase for regex som er utsatt for ReDoS, eller vurder ett enkelt mønster, rett fra kommandolinjen. Kanonisk URL: https://lagune.ai/no-NO/docs/hooks/regex Språk: no-NO Original: https://lagune.ai/docs/hooks/regex Sist oppdatert: 2026-11-09 Hooken `regex` er den deterministiske motoren for trygge regex som [spesialiseringen `regex`](https://lagune.ai/no-NO/docs/catalog) kjører, og du kan kjøre den selv. Den har to moduser i én kommando: modusen **scan** skanner en kodebase for mønstre som er utsatt for **ReDoS** eller bygges under kjøring, og modusen **check** vurderer ett enkelt mønster du gir den. ## Skann en kodebase Uten flagg skanner den hele prosjektet. `--dir` avgrenser gjennomgangen til en mappe, `--file` til én enkelt fil. Begge kan gjentas og slås sammen til én rapport, der hver fil står én gang, selv når flere mål dekker den. **Hele prosjektet** ```bash npx lagune read regex ``` **En mappe** ```bash npx lagune read regex --dir src/services ``` **Én 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 grense** `--limit` setter ReDoS-terskelen for gjennomgangen (standard 25), den samme grensen som modusen check tar. En lavere grense er strengere. ```bash npx lagune read regex --dir src/services --limit 15 ``` Utdataene er ren tekst, og overskriftene forteller hvordan hver seksjon skal leses. En seksjon vises bare når den har funn. ```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 den ikke finner noe, skriver den ut én enkelt linje. ```bash npx lagune read regex --dir src/clean # => no unsafe patterns found ``` ### Slik leser du seksjonene | Seksjon | Betydning | | ------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Vulnerable regular expressions found` | Mønstre som er utsatt for ReDoS, gruppert etter fil med hvert mønster innrykket under, fulgt i parentes av hvorfor det er utrygt og, når det har dem, omfanget og flaggene. Hver linje er utrygg, så konklusjonen gjentas ikke. | | `Regular expressions the analysis could not settle (review manually)` | Mønstre analysen ikke kunne avgjøre innenfor arbeidsgrensen sin, listet opp på samme måte. | | `Dynamically built regular expressions (review manually by simulating a constructed regex)` | Filer som bygger en regex fra en variabel, en sammenslåing eller en interpolering. | | `Static regex wrapped in a constructor (use a literal instead)` | Filer som sender en vanlig strengliteral til en regex-konstruktør der en regex-literal er enklere og sparer en kompilering under kjøring. | Den første seksjonen er et sikkerhetsfunn. Den andre og tredje er ikke funn i seg selv: de peker på kode en statisk kontroll ikke kan avgjøre, og ber derfor om at et menneske leser den. Den fjerde er et hint om lesbarhet, ikke et sikkerhetsfunn. ### CLI-alternativer | Alternativ | Verdi | Beskrivelse | | ----------- | ------------------------- | --------------------------------------------------------------------------------------------------------- | | `--pattern` | kildeteksten til en regex | Sjekk ett mønster. Gjenta for å sjekke flere, én konklusjon per mønster, i samme rekkefølge. | | `--flags` | regex-flagg | Sjekk hvert `--pattern` med disse flaggene, for eksempel `im`. Gjelder bare modusen check. | | `--dir` | en mappe | Avgrens en gjennomgang til en mappe. Kan gjentas og kombineres med `--file`. | | `--file` | en fil | Avgrens en gjennomgang til én enkelt fil. Kan gjentas og kombineres med `--dir`. | | `--limit` | et ikke-negativt heltall | Sett ReDoS-grensen for repetisjoner (standard 25). Gjelder begge modusene. En lavere grense er strengere. | Uten alternativ skanner den hele prosjektet. `--pattern` er modusen check og kan ikke kombineres med `--dir` eller `--file`. ### Velg hva den skanner Den utelater det **Git** ignorerer. For å utelate mer, eller for å skanne det **Git** ignorerer, gi `regex` egne innstillinger: ```bash npx lagune write add --ignore test/fixtures --checker regex ``` ```json { "checkers": { "regex": { "gitignore": false, "ignore": ["test/fixtures"] } } } ``` [Konfigurer hookene](https://lagune.ai/no-NO/docs/hooks/configure) beskriver hver innstilling. ### Støttede språk Gjennomgangen leser disse språkene, gjenkjent på filendelsen, hvert etter sine egne regler, slik at et mønster fra ett språk aldri testes etter et annet språks regler. Alt annet hoppes over i stedet for å skannes med feil regler. | # | Språk | 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` | **Etter beste evne, ikke uttømmende** Den leser kildekoden som tekst, så den kan ikke vurdere et mønster som settes sammen under kjøring, og et mønster som er spredt over flere linjer, skjult bak et alias eller skrevet i en form den ikke gjenkjenner, kan slippe gjennom. Se på seksjonene som et solid utgangspunkt, ikke en fullstendig oversikt, og fortsett å lese koden for det de ikke når. ## Sjekk ett enkelt mønster Send `--pattern` med kildeteksten til mønsteret for å vurdere det. Hooken skriver ut ett ord: `safe`, `unsafe`, `undetermined` når analysen når arbeidsgrensen sin før den har avgjort mønsteret, eller `invalid regex`. Gjenta `--pattern` for å vurdere flere samtidig, én konklusjon per mønster, i samme rekkefølge. **Ett 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 flagg** `--flags` sjekker hvert `--pattern` i kallet med flaggene det kjøres med, siden et flagg endrer hvilke tegn et mønster treffer. ```bash npx lagune read regex --pattern '^(?:a|A)+$' # => safe npx lagune read regex --pattern '^(?:a|A)+$' --flags 'i' # => unsafe ``` **Med en grense** `--limit` setter grensen for repetisjoner (standard 25) og gjelder hvert `--pattern` i kallet. En lavere grense er strengere. ```bash npx lagune read regex --pattern 'a?a?a?' --limit 2 # => unsafe ``` **Hvorfor et argument i anførselstegn** Hvert mønster sendes som verdien til et flagg og interpoleres aldri inn i kommandoen. En verdi med anførselstegn eller backticks forblir uvirksom og kan ikke injisere noe i skallet. Sett alltid mønsteret i enkle anførselstegn, så skallet ditt ikke ekspanderer det først. **Tips** Dette er den samme motoren som [spesialiseringen `regex`](https://lagune.ai/no-NO/docs/catalog) kjører: modusen scan åpner en ReDoS-gjennomgang, og modusen check bekrefter et mønster den finner. ## Vanlige spørsmål ### Hvordan sjekker jeg en regex for ReDoS fra CLI-en? Kjør npx lagune read regex --pattern ''. Den returnerer safe, unsafe, undetermined eller invalid regex. ### Hvordan skanner jeg et helt prosjekt for utrygge regex? Kjør hooken regex i modusen scan over kodebasen. Den rapporterer mønstre som er utsatt for ReDoS, i 25 støttede språk. --- # Hook secrets: Oppdag hardkodede hemmeligheter > Skann en kodebase etter hardkodede påloggingsdetaljer rett fra kommandolinjen. Kanonisk URL: https://lagune.ai/no-NO/docs/hooks/secrets Språk: no-NO Original: https://lagune.ai/docs/hooks/secrets Sist oppdatert: 2026-11-09 Hooken `secrets` flagger **påloggingsdetaljer som er skrevet rett inn i kildekoden** i stedet for å bli lest fra miljøet. Den ser på **opphav** (en literal eller et oppslag i miljøet), ikke på innholdet i verdien, så den trenger ingen uttømmende katalog over leverandørprefikser og gir nesten ingen falske positiver. Den er den deterministiske motoren bak [spesialiseringen `secrets`](https://lagune.ai/no-NO/docs/catalog). Signaturer i formatet til en leverandør, påloggingsdetaljer i tilkoblingsstrenger og en literal som er bundet til en identifikator med et navn som tyder på en hemmelighet, er **språkuavhengige**: Den samme strengen leses likt i alle filer. De to heuristikkene som avhenger av syntaks, et miljøoppslag med en hardkodet standardverdi og en hemmelighet som flyter inn i en loggsink, er **språkbevisste**, så en `console.log` fra JavaScript blir aldri lest i en Rust-fil, og `os.getenv("X", "default")` fra Python blir gjenkjent på egne premisser. ## Kjør ```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 ``` Gjennomgangen skriver ut opptil to seksjoner. **Hardcoded secrets found** er funnene (en hardkodet standardverdi for en miljøvariabel med et navn som tyder på en hemmelighet, påloggingsdetaljer bygd inn i en tilkoblingsstreng, eller en verdi som passer et kuratert leverandørformat), så hooken avslutter med en exit-kode som ikke er null. **Secret handling to review manually** er spor å følge opp: en vanlig literal bundet til en identifikator med et navn som tyder på en hemmelighet (opphavet kan avgjøres, men ikke om verdien er en ekte hemmelighet), og en verdi med et navn som tyder på en hemmelighet, som flyter inn i en sink for logg eller respons. Finner den ingenting, skriver den ut `no hardcoded secrets found`. ### CLI-alternativer | Alternativ | Verdi | Beskrivelse | | ---------- | -------- | --------------------------------------------------------------------------- | | `--dir` | en mappe | Avgrens gjennomgangen til en mappe. Kan gjentas og kombineres med `--file`. | | `--file` | en fil | Avgrens gjennomgangen til én fil. Kan gjentas og kombineres med `--dir`. | Uten alternativer skanner den hele prosjektet. ### Velg hva den skanner Den utelater det **Git** ignorerer. For å utelate mer, eller for å skanne det **Git** ignorerer, gi `secrets` egne innstillinger: ```bash npx lagune write add --ignore test/fixtures --checker secrets ``` ```json { "checkers": { "secrets": { "gitignore": false, "ignore": ["test/fixtures"] } } } ``` [Konfigurer hookene](https://lagune.ai/no-NO/docs/hooks/configure) dekker alle innstillingene. ### Språkdekning Funnet for standardverdier i miljøet og sporet for loggsinker leser et eget sett med former per språk, så de dekker språkene nedenfor og er stille ellers. De tre andre signalene kjører på **alle** filer. | Signal | Språk | | --------------------------- | ------------------------------------------------------------------------------- | | Standardverdi i miljøet | JavaScript/TypeScript, Python, Ruby, PHP, Kotlin, Java, Go (`cmp.Or`), Rust, C# | | Sink for logg eller respons | JavaScript/TypeScript, Python, Ruby, PHP, Java, Kotlin, Go, Rust, C, C++, C# | **Bryter dette med retningslinjene?** Nei. Å gjenkjenne formatet til en hemmelighet for å advare om at den er committet, er vanlig defensiv verktøybruk, den samme operasjonen som gitleaks, trufflehog og push protection i GitHub utfører. Hooken leverer gjenkjenningssignaturer (offentlige **formater** for tokens), aldri en ekte hemmelighet, og den reviderer og forklarer i stedet for å eksfiltrere data. ## Vanlige spørsmål ### Hvordan unngår hooken secrets falske positiver? Den ser på opphav, ikke på innholdet i verdien. Formater med høy treffsikkerhet (leverandørtokens, standardverdier i miljøet, tilkoblingsstrenger) er funn som avslutter med en exit-kode som ikke er null. En vanlig literal bundet til en identifikator med et navn som tyder på en hemmelighet, er et spor du må bekrefte, og den samme identifikatoren lest fra process.env blir ikke flagget i det hele tatt. --- # Prompteksempler for Lagune: Automatiser Blue Team-flyten > Prompter for Lagune, klare til å kopieres: en gjennomgang med kun lesetilgang, hele Blue Team-flyten og en Zero Trust-revisjon, pluss kartlegging avgrenset til en commit, en diff fra en branch eller PR, eller en reell hendelse. Kanonisk URL: https://lagune.ai/no-NO/docs/examples/prompts Språk: no-NO Original: https://lagune.ai/docs/examples/prompts Sist oppdatert: 2026-11-09 Prompter for Lagune som er klare til å kopieres, og som du kan lime rett inn i KI-agenten din. ## 💧 Rask gjennomgang En gjennomgang med kun lesetilgang som leser koden på egen hånd og rapporterer hver svakhet med en utbedring, uten å kjøre Blue Team-flyten eller skrive til sporingen i Lagune. **Tips** Fungerer bedre i planleggingsmodus og når sikkerhetsprinsippene (`/lagune-charter`) er fastsatt. **🪼 Standard** | Aspekt | Avveining | Nivå | | ------------- | ---------------------------------------------------------------------- | ------------------- | | **Innsats** | Én agent skanner og rapporterer, ingen underagenter. | 1/5 | | **Tid** | Rask. Én enkelt gjennomgang med kun lesetilgang, ingenting tas i bruk. | 2/5 | | **Tokenbruk** | Moderat, delt. Hele gjennomgangen kjører i én kontekst. | 2/5 | ```md /lagune Du er en cybersikkerhetsforsker med dyp ekspertise innen defensiv sikkerhet, og du bruker Lagune til å forbedre kunnskapen og presisjonen din. Skann arbeidsområdet på egen hånd, og koble hver svakhet du finner, til en konkret utbedring. Dette er en frittstående gjennomgang, ikke Blue Team-flyten: Ikke kjør detect, plan, harden eller verify, og ikke skriv noe til sporingen i Lagune. Til slutt lister du opp hver svakhet du fant, hver med alvorlighetsgrad og en konkret utbedring. ``` **🐬 Flere agenter** | Aspekt | Avveining | Nivå | | ------------- | ---------------------------------------------------------------------------------- | ------------------- | | **Innsats** | Én underagent per fil, tilpasset størrelsen på kodebasen din. | 2/5 | | **Tid** | Parallelt per fil, deretter slått sammen til én rapport. Fortsatt kun lesetilgang. | 3/5 | | **Tokenbruk** | Høyere, men isolert. Hver underagent skanner i sin egen kontekst. | 3/5 | ````md /lagune Du er en cybersikkerhetsorkestrator som bruker Lagune til å liste opp stiene, sende ut én underagent per sti og slå sammen rapportene deres (alt innhold leses av underagentene). Du må delegere oppgaven til underagenter basert på størrelsen på det gjeldende prosjektet: Jo større kodebasen er, desto flere underagenter skal sendes ut, alle parallelt, og hver av dem får prompten nedenfor: ```prompt /lagune Du er en cybersikkerhetsforsker med dyp ekspertise innen defensiv sikkerhet, og du bruker Lagune til å forbedre kunnskapen og presisjonen din. Skann på egen hånd, og koble hver svakhet du finner, til en konkret utbedring. Dette er en frittstående gjennomgang, ikke Blue Team-flyten: Ikke kjør detect, plan, harden eller verify, og ikke skriv noe til sporingen i Lagune. Til slutt lister du opp hver svakhet i , hver med alvorlighetsgrad og en konkret utbedring. ``` Til slutt slår du sammen alle rapportene fra underagentene til én prioritert liste over svakheter og utbedringer. ```` **Advarsel** En rask gjennomgang er én bred prompt uten avgrensning, så noen agenter er mer tilbøyelige til å avvise den eller avbryte den underveis. Hvis agenten din protesterer, kjører du heller hele **Blue Team-flyten** nedenfor: De avgrensede fasene, som går steg for steg, blir langt sjeldnere blokkert. --- ## 🌊 Automatisk Blue Team-revisjonsflyt Kjører [hele kommandoflyten](https://lagune.ai/no-NO/docs/get-started/commands) fra start til slutt. **🪼 Standard** | Aspekt | Avveining | Nivå | | ------------- | ----------------------------------------------------------------------------------------------------- | ------------------- | | **Innsats** | Én agent, ingen underagenter, uansett størrelse på kodebasen. | 3/5 | | **Tid** | Middels, men mindre grundig i store kodebaser. Hver kommando kjøres én gang, den ene etter den andre. | 4/5 | | **Tokenbruk** | Lavere, men mindre isolert. Alle kommandoene deler samme kontekst. | 4/5 | ```md Kjør følgende kommandoer, én etter én: `/lagune-charter`, `/lagune-detect`, `/lagune-plan`, `/lagune-harden` og `/lagune-verify`. ## Løkke Når `/lagune-verify` avviser én eller flere utbedringer, gjentar du `/lagune-harden` og deretter `/lagune-verify` til alle funn er ordentlig løst. ``` **🐋 Flere agenter (dyp gjennomgang)** | Aspekt | Avveining | Nivå | | ------------- | --------------------------------------------------------------------------------------------------------- | ------------------- | | **Innsats** | Antallet underagenter tilpasses størrelsen på kodebasen din. | 5/5 | | **Tid** | Lengre, men grundigere. Sender ut flere underagenter som kartlegger, planlegger og herder funn parallelt. | 5/5 | | **Tokenbruk** | Høyere, men tryggere. Hver underagent har sin egen isolerte kontekst, uten skjevhet. | 5/5 | ````md Kjør hver av følgende kommandoer i en egen underagent, én om gangen (uten backticks, bare kommandoen): Prompt for underagent 1: `/lagune-charter` Prompt for underagent 2: `/lagune-detect` Prompt for underagent 3: `/lagune-plan` Prompt for underagent 4: `/lagune-harden` Prompt for underagent 5: `/lagune-verify` I kommandoene `/lagune-detect`, `/lagune-plan`, `/lagune-harden` og `/lagune-verify` må du delegere oppgaven til underagenter basert på størrelsen på det gjeldende prosjektet: Jo større kodebasen er, desto flere underagenter skal sendes ut. For eksempel: ```prompt /lagune-detect ``` ```prompt /lagune-plan ``` ```prompt /lagune-harden ``` ```prompt /lagune-verify ``` - Flere agenter på samme kommando skal sendes ut parallelt. - Når alle underagentene for `/lagune-detect` er ferdige, kjører du: ```prompt /lagune-detect slå sammen likeverdige funn. Ikke se etter nye funn, og ikke skann kodebasen på nytt. ``` ## Løkke Når `/lagune-verify` avviser én eller flere utbedringer, gjentar du `/lagune-harden` og deretter `/lagune-verify` til alle funn er ordentlig løst. ```` --- ## 🪄 Avgrenset kartlegging Rett [`/lagune-detect`](https://lagune.ai/no-NO/docs/commands/detect) mot en del av prosjektet ditt i stedet for hele. Beskriv omfanget med vanlige ord (en commit, en pull request eller en reell situasjon), så kartlegger kommandoen bare de sikkerhetsrelevante funnene der. **Tips** Alt kommandoen oppdager her, er vanlige funn, så du kan ta dem rett videre til `/lagune-plan`, `/lagune-harden` og `/lagune-verify`, avgrenset til akkurat disse elementene. **📌 Siden en commit** Gi en fersk bunke commits sin egen sikkerhetsgjennomgang, avgrenset til akkurat det de endret, for eksempel: ```prompt /lagune-detect Avgrens kartleggingen til alt som er endret siden commit `a1b2c3d`. ``` **🔀 Diff fra branch eller PR** Gå gjennom sikkerheten i en pull request før den blir flettet inn, avgrenset til akkurat diffen, for eksempel: ```prompt /lagune-detect Avgrens kartleggingen til endringene denne branchen innfører sammenlignet med `main`. ``` **⛑️ Etter en hendelse** Beskriv med dine egne ord hva som skjedde. Lagune leser situasjonen, ikke et flagg, og gjør den om til et målrettet søk, for eksempel: ```prompt /lagune-detect Nettstedet vårt hadde en datalekkasje for noen uker siden. Jeg vet ikke nøyaktig hvordan det skjedde, og jeg er redd for at noe fortsatt står åpent som kan lekke data igjen. Gå nøye gjennom koden, fokuser på alle steder der sensitive data leses, lagres eller eksponeres, og kartlegg alt som fortsatt kan være en vei ut. Behandle dette som en ekte hendelse, ikke en øvelse. ``` --- ## 🚨 Zero Trust-revisjon Behandler hele arbeidsområdet og hver avhengighet som fiendtlig: Den leter etter interpretere, nettverkskall, kodede payloads og kode som er gjemt på usannsynlige steder for å slippe forbi skannere, og avslutter med en go/no-go-konklusjon om prosjektet er trygt å bruke. Promptene laster inn spesialiseringene denne revisjonen bygger på, direkte, uansett hvilke kategorier prosjektet ditt har. For resten av katalogen som `/lagune` velger ut, må du sørge for at prosjektet bruker **OWASP**, **AI/LLM** og kategorien for stacken sin (f.eks. **JavaScript**, **Python** osv.): ```bash npx lagune write add --categories owasp ai javascript ``` Filene `.gitignore` og konfigurasjonene i selve repositoryet kan skjule filer for kontrollene, så sett blokken `checkers` i `.lagune/configs.json` til å [skanne alt](https://lagune.ai/no-NO/docs/hooks/configure), og erstatt en eventuell blokk som repositoryet har med seg: ```json { "checkers": { "gitignore": false } } ``` **Fare** Vær forsiktig når du kjører prosjekter fra ikke-klarerte kilder i ditt lokale miljø. Bruk et isolert miljø, som en **sandkasse** (anbefalt), en **VM** eller lignende, for å hindre at ondsinnet kode påvirker systemet ditt. **🪼 Standard** | Aspekt | Avveining | Nivå | | ------------- | -------------------------------------------------------------------------------------------- | ------------------- | | **Innsats** | Én agent går gjennom hele arbeidsområdet, ingen underagenter. | 2/5 | | **Tid** | Middels. Én agent arbeider seg gjennom koden og avhengighetene i rekkefølge. | 3/5 | | **Tokenbruk** | Moderat, men delt. Spesialiseringene, koden og avhengighetene lastes alle inn i én kontekst. | 3/5 | ```md /lagune Du er en cybersikkerhetsforsker med dyp ekspertise innen defensiv zero trust-sikkerhet, og du bruker Lagune til å forbedre kunnskapen og presisjonen din. Kartlegg hele arbeidsområdet som en ikke-klarert kilde og et potensielt ondsinnet omfang. Hver interpreter, hver fetch, hver base64 og lignende skal behandles som en potensiell trussel. Utvid analysen til avhengighetene og underavhengighetene: Et prosjekt kan forsøke å gjemme ondsinnet kode på et usannsynlig sted for å slippe forbi skannere. Obligatoriske spesialiseringer (last dem inn én om gangen med `npx lagune read catalog `): - interpreter - secrets - llm - path For å være tydelig: Hver kartlagte sårbarhet skal behandles som en potensiell trussel, uten unntak. Til slutt gir du en konklusjon om prosjektet er trygt og pålitelig for meg å bruke eller ikke. ``` **🐋 Flere agenter (dyp gjennomgang)** | Aspekt | Avveining | Nivå | | ------------- | ---------------------------------------------------------------------------------------------- | ------------------- | | **Innsats** | Én underagent per fil, tilpasset størrelsen på kodebasen din. | 5/5 | | **Tid** | Lengre, men grundigere. Filene gjennomgås parallelt og slås deretter sammen til én konklusjon. | 4/5 | | **Tokenbruk** | Høyest, men tryggest. Hver underagent leser spesialiseringene i sin egen isolerte kontekst. | 5/5 | ````md /lagune Du er en cybersikkerhetsorkestrator som bruker Lagune til å liste opp filene, sende ut én underagent per fil og lage rapporter (alt innhold leses av underagentene). Send ut én underagent per fil, alle parallelt, og gi hver av dem prompten nedenfor, avgrenset til sin fil: ```prompt /lagune Du er en cybersikkerhetsforsker med dyp ekspertise innen defensiv zero trust-sikkerhet, og du bruker Lagune til å forbedre kunnskapen og presisjonen din. Behandle som en ikke-klarert kilde og et potensielt ondsinnet omfang. Hver interpreter, hver fetch, hver base64 og lignende skal behandles som en potensiell trussel. Utvid analysen til alt importerer, inkludert avhengigheter og underavhengigheter, der ondsinnet kode kan gjemme seg for å slippe forbi skannere. Obligatoriske spesialiseringer for hver underagent (last dem inn én om gangen med `npx lagune read catalog `): - interpreter - secrets - llm - path For å være tydelig: Hver kartlagte sårbarhet skal behandles som en potensiell trussel, uten unntak. Til slutt gir du en konklusjon om prosjektet er trygt og pålitelig for meg å bruke eller ikke. ``` Til slutt slår du sammen alle rapportene fra underagentene til én endelig konklusjon. ```` --- # Security-Driven Hardening: en konvensjon for tiden med KI-assistert utvikling > Metodikken Security-Driven Hardening (SDH): en kontekstbevisst Blue Team-konvensjon for revisjon og herding av programvare som er KI-assistert eller vibe-kodet. Kanonisk URL: https://lagune.ai/no-NO/docs/references/paper Språk: no-NO Original: https://lagune.ai/docs/references/paper Sist oppdatert: 2026-11-09 - **Weslley Araújo** - **Metodeartikkel, 2026.** --- ## Sammendrag Security-Driven Hardening (SDH) er en strukturert, KI-drevet og kun defensiv sikkerhetsmetodikk for en tid der programvare i økende grad skrives av KI-agenter og av mennesker som ikke er sikkerhetsspesialister. I stedet for å kjøre en generisk sjekkliste oppdager SDH først hva et system faktisk gjør (innlogging, filopplasting, betalinger, dataeksponering og så videre), og driver deretter sikkerhetsarbeidet som er spesifikt for den konteksten. Metodikken styres av prinsipper som er sikre som standard, er rammet inn helt rundt forsvar og uttrykt i et enkelt språk, slik at enhver bruker kan handle ut fra den. Dette dokumentet argumenterer for at SDH er en manglende konvensjon, ikke ett enkelt verktøy. Sikkerhetskunnskapen ligger i metodikken og spesialiseringene som lastes ved behov, et grunnlag enhver bruker kan bygge videre på, og det lar den tjene en nybegynner og en ekspert gjennom den samme flyten. To egenskaper skiller den fra tidligere spec-first-tilnærminger `[1]`. SDH er **tilstandsuavhengig**: Den tilpasser seg en tom mappe, et prosjekt under arbeid, én enkelt pull request eller en stor eldre kodebase, i hvilken som helst stack. Og SDH er **lukkbar**: En risiko som er verifisert lukket, tas ut av hele flyten, slik at funnet kommer til ro og åpnes igjen først når koden endres. SDH erstatter ikke sikkerhetsfolk eller spesialiserte Blue Team-verktøy. Den utvider utviklerens egen kunnskap, og jo mer en utvikler forstår av sikkerhet, desto mer kan vedkommende styre den. **Lagune** er referanseimplementasjonen, og den beviser at metodikken kan bygges og overføres. SDH tilbys som en konvensjon andre kan ta i bruk. > **Stikkord** > > KI-assistert utvikling, programvaresikkerhet, defensiv sikkerhet, spec-driven development, sikkerhetsherding, agentdrevne arbeidsflyter, lukkbarhet, kontekstbevisst sikkerhet, kunnskap ved behov, agentuavhengige verktøy. --- ## I. Innledning: sikkerhetsgapet KI-assistert utvikling åpnet Programvare blir i økende grad levert av mennesker, og av KI-agenter, som ikke pålitelig kan gjenkjenne et usikkert mønster: en lekket hemmelighet, en manglende autorisasjonssjekk, en spørring som kan injiseres. Dette er ikke eksotiske risikoer. De hører til risikoklassene som dominerer virkelige hendelser, dokumentert i årevis i offentlige referanser `[6]`, `[7]`, og nyere studier viser at en betydelig andel av KI-generert kode leveres med nettopp slike feil `[8]`. KI-kodeassistenter gjorde dette akutt ved å la ikke-utviklere levere ekte programvare, men gapet er bredere enn én enkelt målgruppe. De fleste prosjekter får aldri en sikkerhetsgjennomgang som er spesifikk for det de faktisk gjør. Økosystemet blir skjørere for hver forhastet beslutning av typen "det funker, send det ut". Generiske sikkerhetsråd lukker ikke dette gapet. En statisk sjekkliste er ikke spesifikk for det et system gjør, så den oversvømmer et lite prosjekt med irrelevante punkter og går likevel glipp av risikoen som betyr noe for akkurat det prosjektet. Problemet er ikke mangel på sikkerhetskunnskap i verden. Problemet er å matche riktig kunnskap med systemet brukeren faktisk har foran seg, og å gjøre det for noen som kanskje ikke vet hva det skal spørres om. SDH svarer på dette med én enkelt inversjon: **sikkerhetskunnskapen ligger i spesifikasjonen og spesialiseringene som lastes ved behov, et grunnlag enhver bruker kan bygge videre på**. Metodikken oppdager konteksten, prioriterer risikoene den konteksten fører med seg og veileder utbedringene, så en utvikler og en ikke-utvikler bruker den samme flyten. Funnene og anbefalingene holdes i et enkelt språk, så de kan følges opp uansett hvor teknisk leseren er. Eksperten blir ikke begrenset av dette, men forsterket, en dualitet vi utdyper i `§VI`. > **Kjerneinnsikt** > > **Kjerneinversjonen:** Sikkerhetskunnskapen ligger i spesifikasjonen og spesialiseringene som lastes ved behov, et grunnlag enhver bruker kan bygge videre på. Metodikken lærer hva systemet gjør og tilpasser sikkerhetsarbeidet til det, og den utvider det brukeren allerede kan. Tenk deg en utvikler som sier til en KI-assistent: "Appen min lar brukere laste opp et profilbilde." Uten en sikkerhetsgjennomgang lager assistenten fungerende kode som i det stille stoler på alt klienten sender: den oppgitte filtypen, filnavnet, størrelsen. Opplastingen går i produksjon, og en fil forkledd som et bilde kan inneholde kode, et manipulert navn kan bryte ut av lagringsstien, en overdimensjonert fil kan tømme serveren for ressurser. Ingenting av dette synes i en demo, så det går i produksjon. Den samme koden oppfører seg annerledes når den kjøres gjennom SDH. Metodikken oppdager at systemet tar imot filer utenfra (oppdagelse), omsetter det til risikoene en opplasting fører med seg (triage), foreslår å sjekke den faktiske filtypen og størrelsen, gi filen nytt navn ved lagring og lagre den der kode ikke kan kjøres (utbedring), og leser deretter resultatet og bekrefter at hvert sikringstiltak faktisk holder (verifisering). Utvikleren trengte aldri å kjenne uttrykket "ubegrenset filopplasting". Metodikken leverte det på utviklerens vegne. Dette dokumentet gir følgende bidrag: - En presis definisjon av SDH som metodikk, uavhengig av en bestemt implementasjon, med designprinsippene (`§III`). - En defensiv livssyklus i fem faser der selve ansvarsdelingen er bidraget: Oppdagelsen finner aldri på, planleggingen leser aldri kode, bare én fase endrer kode, og verifiseringen myker aldri opp vurderingen sin (`§IV`). - **Lukkbarhet** som metodisk standpunkt: Et enkelt funn har en sluttilstand, ikke en endeløs løkke (`§V`). - Dualiteten der metodikken **utvider utviklerens kunnskap**: én flyt som beskytter nybegynneren og forsterker eksperten (`§VI`). - **Ikke-kallbare spesialiseringer og prompt-on-demand**: fokusert sikkerhetskunnskap agenten laster når konteksten i prosjektet krever det, aldri som standard (`§VII`). - **Tilstandsuavhengighet** og **ikke-autoritativ tilpasningsevne**: SDH passer til enhver utviklingstilstand og tilpasser seg scenarioet i stedet for å påtvinge et fast omfang (`§VIII`). - En **forebyggende modus**: Det samme forsvaret kjøres mens vanlig arbeid bygges, så koden blir sikker som standard fra start og fasene har mindre å rette opp (`§IX`). - En egen sammenligning med Spec-Driven Development, slekten SDH vokste ut av og deretter skilte lag med (`§X`). - Ingeniørdisiplinene som lar metodikken overleve refaktoreringer og forbli uavhengig av enhver agent: sporing med identitet etter navn (`§XI`) og en agentuavhengig bærer (`§XII`). --- ## II. Bakgrunn og relatert arbeid SDH bygger på tidligere arbeid. Den arver en velprøvd struktur fra spec-first, agentdrevet utvikling `[1]`, `[2]`, `[3]`: maler, skråstrekkommandoer en agent bruker, et styrende dokument og en agent som kjører fasene. Den implementerer den strukturen på nytt med et defensivt formål. Slektskapet er bevisst, og et av arbeidsprinsippene i SDH sier det rett ut: Bygg arbeidsflyten på en velprøvd struktur, og ramm den deretter inn for sikkerhet. SDH er ikke en statisk sjekkliste med generiske anbefalinger. En sjekkliste vet mye om sikkerhet generelt og ingenting om prosjektet foran den. SDH snur denne vektleggingen. Den bruker den første innsatsen på oppdagelse, på å lære hva systemet gjør, og først deretter henter den kunnskapen som oppdagelsen gjør relevant. SDH erstatter heller ikke sikkerhetsfolk eller spesialiserte Blue Team-verktøy. Den utvider utviklerens kunnskap (`§VI`). Et team med en egen sikkerhetsfunksjon bør beholde den. SDH gir det teamet en strukturert bærer, og den gir et team uten en slik funksjon et forsvarbart grunnlag. SDH står også ved siden av deterministiske sikkerhetsskannere (statisk analyse, lintere) `[4]`, `[5]`. Disse verktøyene er verdifulle nettopp fordi de er deterministiske og repeterbare. SDH bygger for det meste på agentens resonnering, som bytter streng determinisme mot kontekstbevissthet. Metodikken later ikke som noe annet. Der determinisme betyr noe, bygger den inn en deterministisk motor i resonneringen (`§VII`): Agenten avgjør om en inngangsverdi er verdt å sjekke, og et deterministisk program avgjør om verdien er farlig. Den mest direkte forgjengeren er Spec-Driven Development (SDD), familien av spec-first-metodikker som driver et bygg fremover fra en kjørbar spesifikasjon. Vi behandler SDD som en klasse. Den tydeligste formuleringen av den som praktikermetodikk er rapporten til Piskala `[1]`, og det mest synlige agentdrevne verktøysettet er Spec Kit fra GitHub `[2]`, med OpenSpec `[3]` som et annet verktøy fra samme familie. Disse er de kanoniske referansene for sammenligningen i `§X`. --- ## III. SDH: definisjon og designprinsipper **Security-Driven Hardening** er en strukturert, KI-drevet sikkerhetsmetodikk som gjør en kodebase sikrere ved å drive arbeidet fra en spesifikasjon agenten kjører, i stedet for fra ad hoc-utbedringer. Navnet er inspirert av **Blue Teams**, forsvarerne innen sikkerhet. SDH handler om forsvar, herding og verifisering, aldri angrep. > **Definisjon** > > **Security-Driven Hardening (SDH):** En strukturert, KI-drevet og kun defensiv sikkerhetsmetodikk som først oppdager hva et system faktisk gjør og deretter driver det kontekstspesifikke sikkerhetsarbeidet, styrt av prinsipper som er sikre som standard og uttrykt i et enkelt språk. SDH defineres av et sett bindende prinsipper. Hvert av dem er en regel, og hvert gir brukeren en bestemt garanti. | Prinsipp | Regelen | Hva det garanterer brukeren | | ----------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Sikker som standard, i et enkelt språk, likt for alle | Hver standardinnstilling, melding og utbedring er sikker fra start og forståelig for enhver leser, utvikler eller ikke. Ingen brukergruppe er privilegert. | En nybegynner får et sikkert grunnlag uten å be om det, og leser resultatet på sine egne premisser. | | Kontekstbevisst fremfor generisk | Hver fase starter fra konteksten som ble oppdaget i detect, og handler ut fra det systemet faktisk gjør. | Anbefalingene passer prosjektet, ikke en sjekkliste. Sikkerhetskunnskapen ligger i spesifikasjonen og spesialiseringene som lastes ved behov, og utvider det brukeren tar med seg. | | Fleksibel fremfor rigid | Prinsipper, krav og anbefalinger er utgangspunkter. Brukeren kan omformulere, droppe, legge til eller snevre inn hva som helst. | Metodikken tilpasser seg prosjektet og brukeren, og blir aldri strengere enn brukeren ønsker. Fleksibilitet svekker aldri grunnlaget som er sikkert som standard. | | Avstem, aldri bare legg til | Artefakter er levende dokumenter, ikke logger. Hver kjøring sjekker hver oppføring på nytt: behold det som holder, skriv om det som er endret, fjern det som ikke lenger gjelder. | Det som er registrert, gjenspeiler alltid nåtiden, så det forfaller aldri til et utdatert etterslep. | | Kun defensiv | SDH reviderer, herder og verifiserer. Den lager aldri offensive verktøy, exploits for ondsinnet bruk eller teknikker for å unngå deteksjon for å gjøre skade. | Metodikken kan ikke gjøres om til et våpen. Innhold med dobbel bruk forekommer bare i en tydelig defensiv ramme. | | Spec-first, agentdrevet, innrettet mot sikkerhet | Arbeidsflyten bygges av maler, kommandoer, styrende sikkerhetsprinsipper og en agent som kjører fasene. | En velprøvd utviklingsstruktur, tatt i bruk på nytt slik at agenten gjør det vesentlige sikkerhetsarbeidet. | **Tabell 1.** Designprinsippene i SDH og garantien hvert av dem gir brukeren. Disse prinsippene er ikke pynt. De er begrensningene hver fase nedenfor må respektere, og diskusjonen i `§XV` vender tilbake til dem for å markere grensene for metodikken. Resten av dokumentet utvikler ni navngitte pilarer. Det er delene en leser bør kunne holde i hodet, og delene et annet team ville implementert på nytt for å kunne si at de praktiserer SDH. | Pilar | Hva den gir | Seksjon | | --------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | ----------- | | Den kontekstbevisste inversjonen | Sikkerhetskunnskapen ligger i spesifikasjonen og spesialiseringene som lastes ved behov, så en nybegynner og en ekspert deler én flyt. | `§I`, `§VI` | | Den defensive livssyklusen i fem faser | Ansvarsdeling: retningslinjer, oppdagelse, triage, utbedring, verifisering, hver med én oppgave. | `§IV` | | Lukkbarhet | Et funn har en sluttilstand, ikke en endeløs løkke. Lukket arbeid tas ut. | `§V` | | Dualiteten som utvider utviklerens kunnskap | Én flyt som beskytter nybegynneren og forsterker eksperten, uten å erstatte noen av dem. | `§VI` | | Prompt-on-demand, ikke-kallbar kunnskap | Relevant sikkerhetskunnskap lastes for det prosjektet er, aldri som standard. | `§VII` | | Tilstandsuavhengighet og ikke-autoritativ tilpasningsevne | Passer til enhver utviklingstilstand i enhver stack, og tilpasser seg scenarioet i stedet for å påtvinge et omfang. | `§VIII` | | Den forebyggende modusen | Det samme forsvaret kjører mens nytt arbeid bygges, så koden blir sikker som standard fra start. | `§IX` | | Sporing med identitet etter navn | Et funn forblir ett element på tvers av fasene, og en omdøping bryter koblingen på bare ett sted. | `§XI` | | Den agentuavhengige bæreren | Sikkerhetsverdien skrives én gang og er ikke avhengig av noen agent eller stack. | `§XII` | **Tabell 2.** De ni navngitte pilarene i SDH og hvor hver av dem utvikles. --- ## IV. Blue Team-flyten i 5 faser SDH strukturerer arbeidet som en defensiv livssyklus i fem faser (figur 1). Hver fase er rammet inn rundt forsvar, hver bygger på den forrige, og fasene følger reell Blue Team-aktivitet: fastsette retningslinjer, oppdage, triagere, utbedre, verifisere. ```mermaid flowchart TB charter["1 · charter (retningslinjer)
leser: prosjektet, og brukerens beskrivelse hvis den finnes
skriver: sikkerhetsprinsippene
prinsippene beskriver risikoen de forebygger, i et enkelt språk"] detect["2 · detect (oppdagelse)
leser: koden til brukeren
skriver: kartleggingen
oppdage, ikke finne på: registrer bare det koden underbygger"] plan["3 · plan (triage)
leser: kartleggingen, aldri koden
skriver: forsvarsplanen
hver utbedring peker på noe detect faktisk kartla"] harden["4 · harden (utbedring)
leser: forsvarsplanen, og koden den berører
skriver: koden, og herdingsloggen
den eneste fasen som endrer kode, én utbedring om gangen, den minste endringen som holder"] verify["5 · verify (verifisering)
leser: koden, og herdingsloggen
skriver: hver åpen konklusjon i herdingsloggen
koden holdt opp mot loggen, statisk, aldri myket opp"] charter --> detect --> plan --> harden --> verify verify -.->|"avvist: gjenåpnet arbeid for harden,
tatt i bruk på nytt ut fra den registrerte begrunnelsen"| harden verify -.->|"lukking: tar det den beviste lukket
ut av hele kjeden,
én linje i historikken"| detect ``` **Figur 1.** Flyten i fem faser: hva hver fase leser, hva den skriver, og den bærende invarianten. Verify styrer begge returene: Et avvist sikringstiltak gjenåpner harden, og et funn som er bevist lukket, tas ut av hele kjeden, med én linje i historikken. Ansvarsdelingen er bidraget. Fordi hver fase har én oppgave, holdes en feil til ett sted, og leseren kan stole på det hver artefakt hevder. > **Kjerneinnsikt** > > **Applied er ikke verifisert:** Harden registrerer at en utbedring er tatt i bruk. Verify verifiserer den ved å holde koden opp mot den registreringen, og konklusjonen mykes aldri opp for å passe loggen. Et sikringstiltak kan finnes i koden og likevel la risikoen være nåbar, og da er den ærlige konklusjonen "Risk not closed". ### charter (retningslinjer) Fasen charter fastsetter sikkerhetsprinsippene for prosjektet, reglene hver senere fase må respektere. Det er det overordnede laget, en slags kompileringstidskontroll for sikkerhetsnivået i prosjektet. Hvert prinsipp har et tydelig navn, en ufravikelig regel som kan kontrolleres mot koden, og en linje `Why:` som oppgir risikoen det forebygger, ikke bare utbedringen. Fasen leser alltid selve prosjektet (manifestene, strukturen og avhengighetene), og en beskrivelse fra brukeren, når den gis, er en retning som lesingen deretter utvider ut over det brukeren nevnte. Uten beskrivelse er prosjektet den eneste kilden. De to legges sammen i stedet for å konkurrere, og sikkerhetsprinsippene registrerer retningslinjene prosjektet bør følge, ikke tilstanden i koden. En ikke-utvikler skal kunne lese dem og forstå både regelen og risikoen. ### detect (oppdagelse) Detect leser koden og kartlegger det systemet faktisk gjør som har sikkerhetsmessig betydning. Den styrende instruksen er "oppdage, ikke finne på": Registrer bare det koden underbygger, med belegget de senere fasene trenger. Detect er nøytral. Den tvinger ikke funnene sine til å passe sikkerhetsprinsippene, fordi det å holde risikoer opp mot reglene i sikkerhetsprinsippene er jobben til fasen plan. Hvert funn har tre deler: hva det er (en beskrivelse i et enkelt språk), hvorfor det betyr noe (risikoen, ikke bare faktumet) og belegget (funksjonen eller ruten der det ligger). Belegget inneholder ingen filsti. Stien ligger bare i sporingskartet (`§XI`), så teksten inneholder aldri en sti som kan bli utdatert. ### plan (triage) Plan gjør hvert funn om til en utbedring, navngitt etter risikoklassen (med henvisning til de etablerte referansene, CWE og OWASP, der de underbygger den) og knyttet til sikkerhetsprinsippet utbedringen ivaretar. Prioriteten (kritisk, høy, middels, lav) er ikke et fritt valg: Plan vurderer hvert funn med CVSS v4.0 og metrikkene Base og Environmental, så nivået er scoren uttrykt med vanlige ord, begrunnet med én linje i et enkelt språk om eksponering og hva som står på spill, og to kjøringer gir samme rekkefølge. Vektoren er det presise ankeret for en ekspert, nivået og begrunnelsen den samme vurderingen i en form alle kan følge. Plan arbeider bare ut fra kartleggingen og leser aldri koden. Dette er en bevisst begrensning, ikke en svakhet: Den tvinger hver utbedring til å peke på noe detect faktisk oppdaget. Hvis et omfang aldri ble kartlagt, stopper plan og sender brukeren tilbake til detect i stedet for å gjette. ### harden (utbedring) Harden er den eneste fasen som endrer kode, så den går forsiktig frem. Om en endring trenger brukerens godkjenning, avgjøres av agenten og tillatelsesmodusen den kjører i, så harden legger ikke til noe eget bekreftelsestrinn. Den tar i bruk én utbedring om gangen, avhengighetene først og deretter høyeste prioritet, slik at hver endring forblir liten, lett å gjennomgå og lett å angre. Den svekker aldri et eksisterende sikringstiltak for å få en ny utbedring til å passe, og den bryter aldri et sikkerhetsprinsipp. Hvis en utbedring ville komme i konflikt med et prinsipp, stopper harden og viser konflikten i stedet for å ta den i bruk. Hver blokk registreres som Applied, Partial eller Blocked. "Applied betyr ikke at den er verifisert ennå", og det er dette den neste fasen håndterer. ### verify (verifisering) Verify verifiserer hvert sikringstiltak som er tatt i bruk, ved å lese koden og holde den opp mot det harden registrerte. Verifiseringen er nettopp dette, koden holdt opp mot loggen, og den er statisk: Den bekrefter at et sikringstiltak finnes og er korrekt i koden, ikke at det holder under angrep på et kjørende system. Den kontrollen under kjøring, den typen som utfører ekte eller simulerte angrep mot det kjørende systemet, er bevisst utenfor omfanget. Verify gir én av tre konklusjoner: Risk closed, Risk not closed eller Cannot tell from the code. Den lager ingen egen artefakt: Harden og verify deler herdingsloggen, der harden eier det som ble gjort og verify eier konklusjonen og begrunnelsen, og ingen av dem skriver noen gang i den andres felt. Et avvist sikringstiltak er gjenåpnet arbeid for harden, som ved neste kjøring lar konklusjonen gå foran sin egen lesning av koden og tar utbedringen i bruk på nytt mot nøyaktig det gapet begrunnelsen peker på. Verify stoler mer på koden enn på loggen, fordi en logg kan påstå mer enn koden leverer. Den har bare lesetilgang til koden til brukeren, og den myker aldri opp en konklusjon for å passe loggen. Et sikringstiltak kan finnes og likevel la risikoen være nåbar på en annen måte, og da er den ærlige konklusjonen "Risk not closed". Hvis verify under lesingen legger merke til et sikkerhetsproblem kartleggingen aldri dekket, finner den ikke på en konklusjon for det, fordi oppdagelse er jobben til detect: Den melder fra om problemet og sender brukeren tilbake til detect, slik at funnet kommer inn gjennom den samme flyten i stedet for å gå utenom den. > **Gjennomgående eksempel: filopplasting.** Ett enkelt funn viser hele ryggraden fra start til slutt. > > - **detect** finner det: Systemet tar imot filer fra brukere, og opplastingshandleren stoler på MIME-typen klienten sender, uten å sjekke den faktiske filtypen. _Hvorfor det betyr noe:_ En fil forkledd som et bilde kan skjule ondsinnet kode. > - **plan** bestemmer utbedringen, prioritet **kritisk**, i tråd med prinsippet "Alle inndata er ikke-klarerte til de er validert": Sjekk den faktiske filtypen og størrelsen, gi filen nytt navn ved lagring, og lagre opplastinger der de ikke kan kjøres som kode. > - **harden** tar den i bruk, status **Applied**: Handleren oppdager nå den faktiske typen ut fra innholdet, håndhever en størrelsesgrense, avviser alt uventet, gir nytt navn ved lagring og lagrer der kode ikke kan kjøres. > - **verify** leser handleren, holder den opp mot loggen og returnerer **Risk closed**: Koden gjør nøyaktig det loggen hevder. > > Det samme funnavnet går gjennom kartleggingen, forsvarsplanen og herdingsloggen, og verify handler på den loggen under det samme navnet: En åpen konklusjon skrives i blokken til funnet, og et funn som er bevist lukket, tas ut (`§V`). Det felles navnet er identiteten (`§XI`). --- ## V. Lukkbarhet: et funn har en sluttilstand De fleste sikkerhetsverktøy etterlater brukeren med et etterslep som bare vokser. SDH inntar et annet standpunkt: **Et funn er lukkbart, så det har en sluttilstand i stedet for å leve i et endeløst etterslep** (figur 2). Dette følger direkte av prinsippet om avstemming. > **Definisjon** > > **Lukkbarhet:** En risiko som er verifisert lukket, tas ut av hele flyten, slik at funnet kommer til ro og åpnes igjen først når koden endres. Et funn har en sluttilstand, selv om selve sikkerhetsprogrammet fortsetter kontinuerlig. Artefaktene i SDH er levende dokumenter, ikke logger. Hver gang en fase kjøres på nytt, sjekker den hver eksisterende oppføring mot den nåværende sannheten og gjør én av tre ting: Den beholder det som fortsatt holder, skriver om det som er endret, eller fjerner det som ikke lenger gjelder. Et funn som koden viser at nå er løst, fjernes ganske enkelt. Arbeidsdokumentasjonen gjenspeiler nåtiden, ikke fortiden. Lukking er den samme avstemmingen, ført helt til ende. Når verify verifiserer at en risiko er lukket, tar den funnet ut av hele flyten: kartleggingen, forsvarsplanen, herdingsloggen og sporingskartet. Det er derfor verify er den ene fasen som skriver til artefaktene til de andre fasene: Den er fasen som lukker sløyfen. Når funnet forlater kjeden, destillerer uttaket det til en kort oppføring i en historikk som ligger utenfor arbeidskjeden og aldri behandles på nytt. Dette er skillet mellom å forsvinne og å lukkes: Et funn som avstemmingen fjernet fordi det sluttet å være sant, etterlater ingenting, mens et funn som er bevist lukket, gjør seg fortjent til sin linje i historikken. Et funn som er tatt ut, mangler i hver arbeidsartefakt etterpå, og det fraværet er forventet, ikke en brutt kjede. ```mermaid stateDiagram-v2 direction TB [*] --> OPEN: detect oppdager OPEN --> Plan: plan Plan --> Harden: harden Harden --> Verify: verify Verify --> StoodDown: Risk closed StoodDown --> SETTLED SETTLED --> OPEN: kodeendringer gjenåpner et funn Plan: plan Harden: harden Verify: verify StoodDown: STOOD DOWN · én linje i historikken ``` **Figur 2.** Tilstandsmaskinen for lukkbarhet. Et funn går gjennom OPEN → STOOD DOWN → SETTLED og åpnes igjen først når koden endres. Når alt innenfor omfanget er tatt ut, er syklusen i ro, og tilstanden i ro har en konkret form: En artefakt der det siste funnet ble lukket, fjernes helt, så en helt lukket kjede etterlater bare sikkerhetsprinsippene og historikken, retningslinjene og beviset. Syklusen åpnes igjen først når koden endres. Metodikken gir hvert funn en tydelig slutt, og det er nettopp det et endeløst etterslep ikke kan. --- ## VI. Dualiteten som utvider utviklerens kunnskap SDH erstatter ikke mennesker, og den erstatter ikke spesialiserte Blue Team-verktøy. Den **utvider utviklerens egen kunnskap**. Jo mer en utvikler forstår av sikkerhet, desto mer presist kan vedkommende styre flyten, og desto mer selvstendighet får vedkommende. En utvikler som forstår lite, får likevel et sikkert resultat, fordi den automatiske modusen beskytter vedkommende. Inversjonen fra `§I`, at sikkerhetskunnskapen ligger i spesifikasjonen, virker i begge retninger. For nybegynneren er den beskyttelse: Nybegynneren trenger ikke å vite hva det skal spørres om, fordi spesifikasjonen kommer med forslag. For eksperten er den forsterkning: Den samme spesifikasjonen lar eksperten sikte flyten presist i stedet for å jobbe mot en fast sjekkliste. Hver fase bærer denne dualiteten i sin egen virkemåte (figur 3). Kjøres fasen uten inndata, handler den på hele omfanget på vegne av brukeren. Får den en retning, snevrer den samme fasen seg inn til nøyaktig det brukeren siktet den mot. ```mermaid flowchart TB inversion["én inversjon, to retninger:
sikkerhetskunnskapen ligger i spesifikasjonen"] inversion --> auto["automatisk modus (ingen inndata)
fasen foreslår og handler
på hele omfanget"] inversion --> directed["styrt modus (inndata gitt)
fasen snevrer seg inn til nøyaktig
det brukeren siktet den mot"] auto --> novice["nybegynneren, beskyttet:
et sikkert resultat uten å
vite hva det skal spørres om"] directed --> expert["eksperten, forsterket:
flyten siktet presist,
ikke en fast sjekkliste"] novice -.-> phases["de samme fem fasene tjener begge:
charter · detect · plan · harden · verify"] expert -.-> phases ``` **Figur 3.** Dualiteten som utvider utviklerens kunnskap. Én inversjon tjener to målgrupper: Den automatiske modusen beskytter nybegynneren, og den styrte modusen forsterker eksperten, gjennom de samme fem fasene. Spesialiseringene som lastes ved behov (`§VII`), gjør dualiteten eksplisitt i sin egen tekst. Hver av dem forteller agenten at kunnskapen "utvider din vurdering", og at den skal fortsette å resonnere ut over det spesialiseringen gir. Kunnskapen er et gulv, ikke et tak. Det er dette som tjener begge målgruppene i den balansen dokumentet sikter mot: Utviklermiljøet får et betydelig instrument, og Blue Team-praktikeren får en strukturert bærer som ikke later som den gjør jobben for vedkommende. --- ## VII. Ikke-kallbare spesialiseringer og prompt-on-demand Dette er det mest nyskapende mønsteret i metodikken. SDH bærer fokusert sikkerhetskunnskap som spesialiseringer som **bare lastes ved behov**, og agenten avgjør selv hvilke som skal lastes ved å matche konteksten i prosjektet. Vi kaller dette **prompt-on-demand**: en måte for agenten å velge hvilken kunnskap som skal aktiveres ut fra omfanget av prosjektet den er i, i stedet for å kjøre hver kontroll som standard. Spesialiseringene er i stadig utvikling, og hvilken som helst av dem kan endres eller erstattes når som helst. Bidraget er mønsteret, ikke spesialiseringene i seg selv. > **Definisjon** > > **Prompt-on-demand:** Agenten velger hvilken sikkerhetskunnskap som skal aktiveres ved å matche den mot omfanget av prosjektet foran seg, slik at den relevante kunnskapen hentes inn ut fra hva prosjektet faktisk er, i stedet for at hver kontroll kjører som standard. > **Definisjon** > > **Ikke-kallbar spesialisering:** En fokusert, språkuavhengig enhet med sikkerhetskunnskap for én kontekst, som filopplasting eller kode som kjører i nettleseren. Den reviderer og forklarer, skriver aldri om kode og lager aldri angrepsinndata. Den er ikke en kommando: Den lastes når konteksten den dekker, er innenfor omfanget, eller når en prompt ber om den ved navn. Hver spesialisering navngir de tryggere formene for risikoene den dekker, og forteller agenten hvordan den skal handle på et funn i hver fase som bruker den: hvordan funnet skal vurderes under oppdagelsen, hvordan utbedringen tas trygt i bruk under utbedringen, og hvordan den bevises under verifiseringen. Det definerende trekket er at en spesialisering **ikke kan kalles på egen hånd**: Den er ikke en kommando, og inne i flyten er det et treff som laster den. Oppdagelsesfasen lister katalogen én gang, matcher konteksten i prosjektet mot det hver oppføring dekker, og laster bare spesialiseringene hvis kontekst finnes innenfor omfanget. De senere fasene gjenbruker den matchede listen i stedet for å liste på nytt, så én matching tjener hele kjeden, og den forebyggende modusen (`§IX`) kjører den samme matchingen mot arbeidet som skal bygges. En spesialisering hvis kontekst mangler, hoppes over, og det å hoppe over er like etterprøvbart som å laste: Hver oppføring i katalogen får en eksplisitt konklusjon, tatt i bruk eller hoppet over, med begrunnelsen lest ut av koden, så en vag følelse av irrelevans aldri erstatter faktisk fravær. Å ikke finne noen som gjelder, er et gyldig utfall. Katalogen er data, og vekst er én kunnskapsfil pluss én katalograd, aldri en ny kommando. De innebygde spesialiseringene er gruppert i kategorier, som OWASP, et språk eller KI-integrasjoner, og katalogen et prosjekt bruker, inneholder de innebygde fra kategoriene det valgte pluss prosjektets egne spesialiseringer. Prosjektet registrerer det valget sammen med resten av tilstanden sin, så et helt team matcher mot den samme katalogen. Dette er det samme kontekstbevisste prinsippet som i fasene, brukt på kunnskap: Den relevante kunnskapen hentes inn ut fra hva prosjektet faktisk er, i stedet for at hver kontroll kjører som standard. Den samme egenskapen lar brukeren, ikke bare vedlikeholderen, utvide katalogen: En sikkerhetskilde eller et tema brukeren gir, destilleres til en ny spesialisering som tilhører prosjektet, blir med i katalogen uansett kategorier og lastes nøyaktig som en innebygd, og den overstyrer den innebygde med samme navn. Å skrive en spesialisering er i seg selv kun defensivt og følger den samme grensen spesialiseringene håndhever: En beskrivelse av et angrep kan være kilden, men spesialiseringen den gir, reviderer og forklarer og lager aldri en fungerende exploit. Slik strekker inversjonen fra `§I`, at intelligensen ligger i spesifikasjonen, seg til selve katalogen, som brukeren kan utdype for sin egen kontekst uten å skrive kode. Et kort eksempel illustrerer prompt-on-demand. Detect leser en mappe med kode som kjører i nettleseren. Den matcher den konteksten i katalogen, laster spesialiseringen som dekker den, og viser et funn på klientsiden gjennom de vanlige stegene i detect. Spesialiseringene hvis kontekst mangler i dette omfanget, gir ikke treff, så de lastes aldri, og hver av dem registreres som hoppet over. Det var prosjektet som avgjorde hvilken kunnskap som var relevant, ikke en fast konfigurasjon. Determinisme dukker opp nettopp der den betyr noe. En spesialisering kan ha en deterministisk kontroll, ikke bare tekst: Der en risikoklasse har en skarp beslutningsprosedyre, returnerer et lite program en fast konklusjon for en gitt verdi, for eksempel et lite sett ord som `safe`, `unsafe` eller `invalid input`. Noen risikoklasser kan avgjøres deterministisk på nettopp denne måten, med et etablert fagarbeid bak beslutningsprosedyren `[9]`, `[10]`, `[11]`. Kontrollen vurderer enten kandidater agenten leverer, eller skanner omfanget for å finne dem selv, og i begge tilfeller er det kontrollen, ikke agenten, som returnerer konklusjonen. En spesialisering som er universell nok, kan merkes som påkrevd i katalogen og tas da alltid i bruk, med kontrollen kjørt over hele omfanget. Dette er det ene tilfellet der kunnskap lastes uten et konteksttreff, og det deklareres i dataene i katalogen, aldri avgjort av agenten der og da. Det er her SDH forankrer agentens resonnering i noe repeterbart, uten å late som hele flyten er deterministisk. Til slutt er spesialiseringene **løsrivbare**. Fordi kunnskapen står på egne ben, kan en bruker kjøre en av dem direkte i en prompt som ikke har noe med hele SDH-flyten å gjøre, og holde sikkerheten med i vanlig utvikling. En spesialisering med en deterministisk kontroll kan for eksempel sjekke hver kandidat som produseres under vanlig koding og bare beholde de trygge. Denne løsrivbarheten er en del av grunnen til at SDH tilpasser seg så mange situasjoner, som er temaet for `§VIII`, og det fulle uttrykket for den er den forebyggende modusen (`§IX`), der den samme kunnskapen vokter vanlig utvikling fra start til slutt. --- ## VIII. Tilstandsuavhengighet og ikke-autoritativ tilpasningsevne To egenskaper skiller SDH fra rigide spec-metodikker. ### Tilstandsuavhengighet > **Definisjon** > > **Tilstandsuavhengighet:** Metodikken er ikke avhengig av utviklingstilstanden. Den passer til en tom mappe, et prosjekt under arbeid, én enkelt pull request eller en stor eldre kodebase, i hvilken som helst stack, fordi den lærer utgangspunktet ved å lese det. Hver fase fungerer likt enten prosjektet er helt nytt eller allerede finnes. Fasen charter utleder prinsipper fra den koden som finnes. Detect kartlegger den koden som er der, selv om det er svært lite. Det finnes ikke noe forutsatt utgangspunkt. ### Ikke-autoritativ tilpasningsevne > **Definisjon** > > **Ikke-autoritativ tilpasningsevne:** Metodikken tilpasser seg scenarioet i stedet for å påtvinge et fast omfang brukeren må følge. Når brukeren ikke vet hva som skal sies, leser den miljøet den ble kalt i, skaper kontekst og stiller spørsmålene som former hva den gjør videre. Forslagsmodusen i fasen charter er det tydeligste eksempelet: SDH utleder sikkerhetsprinsipper som er sikre som standard, ved å analysere prosjektet, spør brukeren bare når et hull faktisk endrer resultatet, skriver dem deretter og presenterer hvert prinsipp i et enkelt språk med risikoen det forebygger. Sikkerhetsprinsippene er et levende dokument brukeren omarbeider ved å kjøre fasen på nytt, ikke en kontrakt låst bak en godkjenningsforespørsel, så brukeren trenger aldri å vite hva det skal spørres om. Denne tilpasningsevnen viser seg som en følsomhet for formen på inndataene: Den samme fasen leser det den fikk, og velger en modus (figur 4). En fil i prompten, et funn fra listen, en bekymring, et fokusert oppdrag mot et kjent svakt punkt eller en forespørsel om en full brute force-gjennomgang: Hver av dem passer brukerens behov, fordi flyten er ikke-autoritativ av design. Ingenting av dette svekker grunnlaget som er sikkert som standard. Fleksibilitet former hvordan grunnlaget brukes, den senker det aldri. ```mermaid flowchart TB shape["fasen leser formen
på det den fikk"] shape --> none["ingen inndata"] shape --> paths["én eller flere stier"] shape --> concern["en beskrevet problemstilling"] shape --> finding["et navngitt funn"] shape --> band["et prioritetsnivå"] none --> auto["den automatiske modusen:
foreslå, eller skann
hele omfanget"] paths --> focus["fokuser bare på de
filene eller mappene"] concern --> scoped["avgrens til den
ene problemstillingen"] finding --> item["handle på det ene
sporede elementet"] band --> priority["handle bare på kritisk,
høy, middels eller lav"] ``` **Figur 4.** Ikke-autoritativ tilpasningsevne. Den samme fasen leser formen på inndataene og velger en modus, så omfanget er alltid brukerens, aldri påtvunget. --- ## IX. Den universelle forebyggende modusen: det samme forsvaret mens arbeidet bygges SDH har én utfyllende modus: vanlig utvikling utført med det samme forsvaret aktivt mens koden skrives. Brukeren ber om selve arbeidet, en innloggingsside, en opplasting, et endepunkt, og metodikken vokter byggingen mens den skjer, så resultatet er sikkert som standard i det øyeblikket det lander, i stedet for etter en senere herdingsrunde. > **Definisjon** > > **Den forebyggende modusen:** vanlig utvikling kjørt under det overordnede laget og kunnskapen i SDH. Sikkerhetsprinsippene binder byggingen, spesialiseringene som er relevante for det som skal lages, lastes ved behov, og resultatet holdes opp mot nøyaktig det forsvaret som ble brukt, før arbeidet regnes som ferdig. Modusen gjenbruker hver del fasene allerede har, rettet mot kode som ikke finnes ennå. Kontekstoppdagelsen flyttes fra koden til intensjonen: Agenten resonnerer seg gjennom det den skal til å bygge og grensene det arbeidet krysser (en innlogging innebærer påloggingsdetaljer, en økt og inndata utenfra), og det er den resonneringen kunnskapskatalogen matches mot. Prompt-on-demand (`§VII`) generaliseres her: Kontekst kan oppdages i planen for kode, ikke bare i kode som finnes. Sikkerhetsprinsippene styrer som alltid, og en forespørsel som ville bryte et prinsipp, vises som en konflikt og bygges aldri. Forsvaret brukes underveis, i det øyeblikket hver del skrives, med validering ved grensen og den trygge konstruksjonen valgt første gang, så en versjon som fungerer, men er usikker, aldri finnes og trenger å rettes. Modusen slutter slik verify begynner. Før arbeidet regnes som ferdig, holder den som bygger, sitt eget resultat opp mot forsvaret den brukte: Sikringstiltaket må ligge på risikoens vei, ikke ved siden av den, det må være komplett, og der en spesialisering har en deterministisk kontroll, går kontrollens konklusjon foran agentens egen lesning. Et hull som blir funnet her, lukkes som en del av det samme arbeidet, fordi å gjøre arbeidet ferdig betyr å gjøre det ferdig på en sikker måte. Det modusen avviser, er like bevisst som det den gjør. Den bygger bare det som ble bedt om, og reviderer ingenting rundt det: Å revidere det som finnes, hører til fasene. Den skriver ingen artefakt og sporer ingen funn, fordi et funn er en risiko oppdaget i det som finnes, og formålet med denne modusen er at den usikre versjonen aldri lander i det hele tatt. De to retningene utfyller hverandre: Fasene lukker det som allerede er der (`§V`), og den forebyggende modusen hindrer nytt arbeid i å gjenåpne det. En kjede i ro forblir i ro, ikke fordi utviklingen stoppet, men fordi det som bygges mens den er i ro, bygges med forsvaret på plass. --- ## X. Security-Driven Hardening versus Spec-Driven Development Security-Driven Hardening (SDH) vokste ut av grunnlaget i Spec-Driven Development (SDD) og skilte deretter tydelig lag med det. Den strukturelle arven er reell og anerkjent: spec-first, agentdrevet, et styrende dokument og et sett kommandoer i faser som agenten kjører. SDH gjenbruker den strukturen bevisst. Det som skiller seg, er formålet, autoritetsmodellen, den forutsatte tilstanden og sluttbetingelsen. Vi behandler SDD som en klasse og bruker rapporten til Piskala `[1]` som den kanoniske formuleringen av metodikken, Spec Kit fra GitHub `[2]` som det kanoniske agentverktøysettet og OpenSpec `[3]` som et annet verktøy fra samme familie. SDD snur tradisjonell utvikling på hodet ved å gjøre spesifikasjoner kjørbare: Spesifikasjonen genererer direkte en fungerende implementasjon i stedet for bare å veilede den `[1]`. Fasesettet driver et bygg fremover `[2]` (fastsett styrende prinsipper, spesifiser hva som skal bygges, planlegg teknologistakken, del planen opp i oppgaver og implementer). Det styrende dokumentet, en konstitusjon av prinsipper, er grunnsteinen agenten må følge hele veien. Det er kjernen i forskjellen. I SDD flyter autoriteten fra spesifikasjonen inn i byggingen, og implementasjonen forventes å følge den. SDH snur nesten hver akse i den kontrakten (tabell 3). > **Kjerneinnsikt** > > **Kjerneforskjellen:** I SDD flyter autoriteten fra spesifikasjonen inn i byggingen, og implementasjonen forventes å følge den. SDH er ikke-autoritativ og flyter motsatt vei, innover fra den oppdagede konteksten til systemet, og herder det som allerede er der. | Akse | SDD | SDH | | ------------------------- | ---------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- | | Mål | Levere funksjoner. Spesifikasjonen blir en fungerende implementasjon. | Herde det som finnes eller bygges. Hver fase er rammet inn for forsvar. | | Autoritetsmodell | Autoritativ. Spesifikasjonen og konstitusjonen begrenser byggingen til et omfang den må følge. | Ikke-autoritativ. SDH tilpasser seg scenarioet, og brukeren kan omformulere, droppe eller snevre inn. | | Forutsatt tilstand | Et bygg fremover fra en spesifikasjon. | Tilstandsuavhengig: tom mappe, prosjekt under arbeid, én enkelt PR eller eldre kode. | | Sluttbetingelse | Slutter når funksjonen er bygget. | Lukkbar. Et funn kommer til ro og åpnes igjen først når koden endres. | | Styrende dokument | En konstitusjon av prinsipper agenten må følge. | Sikkerhetsprinsipper rammet inn rundt risiko (hvert har en linje `Why:`), uttrykkelig ikke en fast kontrakt. | | Hvordan kunnskapen vokser | Legg til en kommando (eller utvid fasesettet). | Legg til en ikke-kallbar spesialisering agenten laster ved behov: én fil pluss én katalograd, ingen ny kommando. | | Hvem den tjener | En utvikler som driver en funksjon fremover. | Enhver bruker, utvikler eller ikke, gjennom den samme flyten. | | Hva som endrer kode | Implementasjonsfasen genererer byggingen. | Bare fasen harden endrer kode, én utbedring om gangen. | **Tabell 3.** SDD versus SDH langs åtte akser. Lånt struktur, snudd kontrakt. For å yte slekten rettferdighet: SDD er velprøvd forgjengerarbeid, og SDH skylder den strukturen den kjører på. Avviket er ikke en kritikk av SDD, som løser et annet problem (å bygge fremover) godt. SDH tar det samme velprøvde maskineriet og retter det mot forsvar, tilpasningsevne og lukking. OpenSpec `[3]`, organisert rundt endringsforslag, oppgavelister og spesifikasjoner per endring, bekrefter mønsteret: Familien driver et bygg fremover fra en spesifikasjon, mens SDH herder et system innover fra den oppdagede konteksten. Selv den forebyggende modusen i SDH (`§IX`), det ene stedet den følger et bygg fremover, beholder den snudde kontrakten: Den styrer hvordan arbeidet bygges og avgjør aldri hva som skal bygges. --- ## XI. Ingeniørmessig grundighet: sporingsdisiplinen Disiplinen "avstem, aldri bare legg til" (`§V`) trenger et underlag som overlever refaktoreringer. Et funn må forbli ett element gjennom hver fase som berører det, og en omdøpt eller flyttet fil må ikke bryte kjeden. SDH løser dette med **identitet etter navn** og **stier som bare finnes i sporingen**. > **Definisjon** > > **Identitet etter navn:** Identiteten til et funn er navnet, skrevet likt i hver artefakt. Teksten inneholder navnet, aldri en sti. Filstier ligger bare i sporingskartet, så en omdøpt eller flyttet fil bryter koblingen på nøyaktig ett sted. Hvert funn fra detect er ett sporet element. Identiteten er **navnet**, seksjonstittelen, skrevet likt i kartleggingen, forsvarsplanen og herdingsloggen. De senere fasene gjenbruker navnet ordrett når de handler på det samme elementet, og verify skriver konklusjonen sin i herdingsloggen under det samme navnet. Sporingskartet inneholder sporing og ingenting annet, én oppføring per element: ```json { "name": "File uploads", "paths": ["src/routes/upload.ts"] } ``` Kartet registrerer ingen tekst, ingen merknader, ingen separat identifikator og ingen fase. Tekstartefaktene bærer formuleringene, og kartet bærer bare identitet og stier. Filstier er det eneste flyktige, og de ligger bare her. En omdøpt eller flyttet fil kan bryte koblingen på nøyaktig ett sted, aldri i to kopier som glir fra hverandre. ```mermaid flowchart TB detect["kartleggingen"] --> name plan["forsvarsplanen"] --> name harden["herdingsloggen
verify skriver konklusjonen sin her"] --> name name["name = "File uploads"
teksten bærer navnet, aldri en sti"] name -.-> tracking tracking["sporingskartet
{ name: "File uploads",
paths: ["src/routes/upload.ts"] }
stien ligger bare her, så en omdøping retter bare denne oppføringen"] ``` **Figur 5.** Transportbåndet for identitet. Ett funnavn går gjennom hver artefakt, mens stien bare ligger i sporingskartet, så en omdøping rettes på ett sted. To handlinger vedlikeholder kartet i den vanlige flyten, og en tredje står for seg selv som vedlikehold. **Track** er tilleggsregistrering: En fase rapporterer funnene den skrev, og motoren registrerer de nye og følger en omdøpt sti for resten, og klassifiserer hvert funn som nytt, flyttet eller uendret. Den fjerner aldri noe fasen ikke rapporterte. **Untrack** tar ut funnene verify lukket: I én deterministisk gjennomgang destillerer den hvert av dem til en historikkoppføring, fjerner hele seksjonen fra artefaktene, sletter en artefakt der det siste funnet er borte, og fjerner sporingsoppføringen, så agenten gjør ingenting av dette for hånd. Der den deterministiske gjennomgangen ikke trygt kan gå videre (et uttatt navn som fortsatt siteres i teksten til et annet funn), flagger den stedet for agenten i stedet for å gjette en endring. Disse to er det fasene kaller mens de kjører. **Repair** er vedlikeholdshandlingen: En fase delegerer automatisk til den når dens egen avstemming finner sporingen inkonsistent (en registrert sti som ikke lenger finnes), og ellers kjøres den ved behov. Den justerer hele kartet på én gang, leser hver artefakt og den nåværende koden, retter stiene for hvert element og viser frem det den ikke kan avgjøre alene: et foreldreløst element (et sporet element ingen artefakt nevner lenger) eller en mulig omdøping (et element der stiene matcher et annet rapportert navn). Repair er vedlikehold, ikke en sjette fase. Den rører verken koden til brukeren eller tekstartefaktene, bare sporingen. Den leser kildekoden til brukeren av bare én grunn, for å finne den nye stien til en omdøpt fil, og den skriver aldri sikkerhetsinnhold. Mennesket har siste ord i den ene avgjørelsen motoren nekter å gjette: om et element som har forsvunnet, ble løst eller bare fikk nytt navn. Det er bedre å spørre enn å gjette, fordi et element som droppes ved en feil, bryter kjeden. Metodikken bruker sin egen forsvarsdisiplin på seg selv. De deterministiske motorene kalles som kommandolinjeprogrammer, og hver verdi sendes som et eget prosessargument, som holder den uskadelig, så en verdi med anførselstegn eller backticks aldri kan injiseres i kommandoen. En ukjent kontroll feiler i stedet for å svare, så en feilstavet kontroll aldri leses som et rent resultat. SDH unntar ikke sin egen infrastruktur fra prinsippet om sikker som standard. --- ## XII. Bæreren: agentuavhengig arkitektur som bevis på portabilitet For at SDH skal bli en konvensjon andre tar i bruk, kan den ikke være bundet til én agent eller én stack, så bæreren holder tre ansvarsområder adskilt (figur 6). Lagune beviser at dette er mulig. **Sikkerhetsverdien** skrives én gang og vet ingenting om hvilken agent som kjører den: faseinstruksjonene og malene de fyller ut, kunnskapskatalogen og de deterministiske motorene. **Leveransen** er tynn: Den eneste oppgaven er å bringe den verdien til en gitt agent i den formen og på det stedet agenten forventer, og den har ingen egen sikkerhetslogikk. **Prosjektets tilstand** hører til prosjektet: sikkerhetsprinsippene, faseartefaktene, sporingskartet, kategoriene det valgte og prosjektets egne spesialiseringer, committet og mulig å gjennomgå som enhver annen del av koden. ```mermaid flowchart TB value["sikkerhetsverdien, skrevet én gang
faseinstruksjoner · maler · kunnskapskatalog · deterministiske motorer
vet ingenting om hvilken agent som kjører den"] delivery["leveranse
bringer verdien til hver agent i den formen den forventer
har ingen sikkerhetslogikk"] agent["agenten
kjører fasene"] project["prosjektets tilstand
committet sammen med koden
sikkerhetsprinsipper · faseartefakter · sporing · kategorier · egne spesialiseringer"] value --> delivery --> agent agent -->|"leser og skriver"| project ``` **Figur 6.** Den agentuavhengige bæreren. Sikkerhetsverdien skrives én gang, en tynn leveranse bringer den til hver agent, og tilstanden forblir prosjektets. Fordi leveransen ikke har noen sikkerhetslogikk, endrer måten den bygges på ingenting i SDH. En bærer kan bygge leveransen selv eller overlate den til et økosystem som allerede distribuerer skills for agenter, slik referanseimplementasjonen gjør, og fasene, artefaktene og garantiene deres forblir de samme. Ingenting av dette er heller spesifikt for et språk eller en kjøretid. Referanseimplementasjonen er tilfeldigvis skrevet i én stack, men metodikken er grensen mellom disse ansvarsområdene, ikke verktøykjeden som bygger dem. Det samme designet kunne vært implementert på nytt i et helt annet språk uten å endre hva SDH er. --- ## XIII. Gjennomgått eksempel: SDH fra start til slutt > **Gjennomgått eksempel** > > **Defensiv herding av en opplastings- og adminflate.** > **Kontekst:** en liten app som tar imot filopplastinger fra brukere og lister dem på en adminside. > **Mønster:** charter → detect (med kunnskap ved behov aktivert av konteksten) → plan → harden → verify, med én lukking og én reell feil. > **Resultat (evne):** én risiko verifisert lukket og tatt ut av hele kjeden, og ett sikringstiltak verifisert som _ikke_ lukket og sendt tilbake til harden. Konklusjonen gjenspeiler koden, ikke loggen. _Dette er et illustrerende eksempel på mekanikken i metodikken, ikke en studie målt i felt, og det rapporterer ingen måltall for effekt._ Én sammenhengende gjennomgang viser metodikken i drift, ikke bare delene. Vi utvider tråden om filopplasting fra `§IV` med en aktivering av kunnskap ved behov og en lukking, og vi tar med én reell feil. 1. **charter** foreslår prinsippet "Alle inndata er ikke-klarerte til de er validert", med risikoen i et enkelt språk: Inndata som ikke sjekkes, er den vanligste måten et system blir brutt på. 2. **detect** skanner opplastingsruten og den lille adminsiden som lister opplastede filer. Den oppdager funnet for opplastingen (handleren stoler på MIME-typen fra klienten). Adminsiden kjører i nettleseren, en kontekst som prompt-on-demand (`§VII`) gjenkjenner, så detect laster spesialiseringen for den konteksten og viser et funn nummer to: et sted der et filnavn skrives inn i siden som markup i stedet for tekst, så et manipulert navn kan kjøre som skript i nettleseren til den besøkende. Spesialiseringer hvis kontekst mangler i dette omfanget, lastes aldri, og hver gang en hoppes over, registreres det med fraværet lest ut av koden. 3. **plan** gir utbedringen for opplastingen prioritet kritisk, knyttet til prinsippet: Sjekk den faktiske filtypen og størrelsen, gi filen nytt navn ved lagring, lagre der kode ikke kan kjøres. Den gir den andre utbedringen prioritet høy: Vis filnavnet som tekst, ikke markup. 4. **harden** tar i bruk utbedringen for opplastingen først (høyeste prioritet) og registrerer den som Applied, og deretter den andre, Applied. 5. **verify** leser hvert sted og holder koden opp mot loggen. Sikringstiltaket for opplastingen holder: Handleren oppdager den faktiske typen ut fra innholdet, håndhever en størrelsesgrense og avviser resten. Konklusjon: Risk closed. Verify tar funnet for opplastingen ut av hele kjeden, og det destillerte sammendraget havner i historikken. Den reelle feilen følger. Anta at den andre utbedringen fra harden la til en trygg hjelpefunksjon for tekstvisning, men lot det gamle kallet som skriver markup, fortsatt være nåbart via en annen kodesti. Verify leser siden, ser den trygge hjelpefunksjonen og ser også at den usikre stien fortsatt er aktiv. Sikringstiltaket finnes, men risikoen er ikke lukket. Verify nekter å myke opp konklusjonen for å passe loggen. Den returnerer "Risk not closed", registrerer gapet og peker tilbake til harden. Et sikringstiltak som ikke håndterer risikoen fullt ut, er ikke godkjent. Dette er metodikkens karakter i ett eksempel: kontekstbevisst oppdagelse, prioriterte utbedringer knyttet til prinsipper, forsiktig gjennomføring og en verifisering som rapporterer den faktiske tilstanden i koden, uansett hva loggen sier. --- ## XIV. Når du bør bruke SDH, og grensene SDH er sjelden uforholdsmessig slik en tung prosess kan være, fordi den er tilstandsuavhengig og lukkbar: Den kan skaleres ned til én enkelt fil og én enkelt problemstilling, og den kommer til ro i stedet for å etterlate en varig byrde. Grensen er ikke prosjektets størrelse, men **dybden i sikkerhetsgarantien**. ```mermaid flowchart TB q1{"Gjør koden noe som er relevant for sikkerheten?
(inndata, autentisering, data, hemmeligheter, eksterne kall)"} q1 -->|nei| little["SDH tilfører lite her."] q1 -->|ja| q2{"Kjør SDH. Finnes det et compliance-krav
eller en egen sikkerhetsfunksjon?"} q2 -->|nei| baseline["SDH er et forsvarbart grunnlag."] q2 -->|ja| carrier["SDH er den strukturerte bæreren:
den støtter ekspertgjennomgang og revisjon,
den erstatter dem ikke."] ``` **Figur 7.** Når du bør bruke SDH. Forgreningen spør først om sikkerhetsrelevans, deretter om dybden i sikkerhetsgarantien, aldri om prosjektets størrelse. Der SDH når grensen sin: atferd som bare viser seg når systemet kjører (verify leser kode, den kjører ikke systemet), risiko som avhenger av konfigurasjon eller et miljø agenten ikke kan lese, og kontekster med mye på spill der ekspertgjennomgang uansett er påkrevd. I hvert av disse tilfellene tilfører SDH fortsatt verdi som en strukturert første gjennomgang, men den er et gulv, ikke et tak. > **Kjerneinnsikt** > > **Grensen:** Begrensningen til SDH er dybden i sikkerhetsgarantien, ikke prosjektets størrelse. Den kan fungere som et forsvarbart grunnlag nesten overalt, og den støtter ekspertgjennomgang der mye står på spill, men den erstatter ikke testing av et kjørende system eller vurderingen til en sikkerhetsekspert. --- ## XV. Diskusjon: posisjonering, grenser og hva SDH ikke hevder SDH er presis om grensene sine. ### Den utvider, den erstatter ikke SDH erstatter ikke sikkerhetsfolk eller spesialiserte Blue Team-verktøy. Den utvider utviklerens kunnskap (`§VI`). En nøktern påstand er den riktige: Brukt godt **kan** SDH lukke reelle risikoer effektivt, særlig for prosjekter som ellers ikke ville fått noen sikkerhetsgjennomgang i det hele tatt. Den er ingen garanti, og den er ingen erstatning for ekspertgjennomgang der mye står på spill. ### Kun defensiv, per konstruksjon SDH reviderer, herder og verifiserer. Den lager aldri offensive verktøy, exploits eller teknikker for å unngå deteksjon for å gjøre skade. Sikkerhetsinnhold med dobbel bruk er bare akseptabelt i en tydelig defensiv og autorisert ramme. Dette er en absolutt grense, ikke en preferanse. ### Verifiseringen er reell, ikke teater Verify verifiserer ved å lese koden og holde den opp mot loggen, ikke ved å kjøre systemet. Dette er statisk verifisering: Den bekrefter at et sikringstiltak finnes og er korrekt i koden, og den beviser ikke at sikringstiltaket holder under angrep ved kjøring. Derfor er "Cannot tell from the code" en legitim konklusjon, ikke en feil skjult bak et bestått resultat. Når belegget ikke finnes i koden (det avhenger av konfigurasjon, eller av en sti agenten ikke kan lese), sier SDH det i stedet for å gjette. ### Determinismen er avgrenset og navngitt Det meste av SDH bygger på agentens resonnering, og det er det som gjør kontekstbevisstheten mulig. Determinisme er forbeholdt de deterministiske motorene: kontrollene en spesialisering kan ha (`§VII`), og sporingsmotoren (`§XI`). Dokumentet visker ikke ut dette skillet. Der et resultat er deterministisk, er det resultatet fra et program. Der det er resonnert, er det agentens lesning av koden, med brukeren som den som har siste ord. ### Kostnad og skala En full gjennomgang bruker mange tokens. De manuelle modusene (`§VI`, `§VIII`) finnes delvis for å holde kostnaden i forhold til problemstillingen. ### Brukeren har siste ord SDH ber mennesket avgjøre om et element fikk nytt navn eller ble løst, og godkjenningen av kodeendringene ligger der brukeren allerede styrer agenten sin, i tillatelsesmodusen agenten kjører i. Metodikken foreslår og verifiserer. Den overstyrer ikke personen. ### Innvendinger og svar En rettferdig skeptiker vil komme med flere innvendinger. De vesentlige er verdt å stille med skeptikerens egne ord. **"Er ikke dette bare en statisk analysator med en LLM skrudd på?"** Nei. En statisk analysator kjører alle reglene den har som standard. SDH oppdager først hva systemet er, og henter deretter den relevante kunnskapen (`§II`, `§VII`), og den _bygger inn_ en deterministisk kontroll bare der en risikoklasse har en skarp beslutningsprosedyre. Resonneringen starter med konteksten, og determinismen er målrettet. **"Er ikke dette bare en sikkerhetssjekkliste?"** Nei. SDH snur sjekklisten: Oppdagelsen kommer først, og kunnskapen hentes inn for det prosjektet faktisk gjør (`§II`, `§VII`). **"Er ikke dette bare SDD med ny merkevare for sikkerhet?"** Nei. SDH låner strukturen fra SDD og snur kontrakten: Autoritet, forutsatt tilstand, sluttbetingelse og hvem den tjener, er alle forskjellige (`§X`). Samme maskineri, motsatt retning. **"Hallusinerer ikke en metode basert på KI-resonnering bare funn?"** Designet begrenser muligheten til å finne på i stedet for å stole på at modellen oppfører seg. Detect registrerer bare det koden underbygger ("oppdage, ikke finne på", `§IV`), verify holder koden opp mot loggen og kan svare "Cannot tell from the code" (`§XV`), deterministiske kontroller forankrer de avgjørbare tilfellene (`§VII`), og brukeren har siste ord. Det gjør ikke agenten ufeilbarlig, men det gjør påstandene den kommer med, mulige å kontrollere. En merknad om posisjonering. SDH defineres her uavhengig av referanseimplementasjonen. De fem fasene, sikkerhetsprinsippene rammet inn rundt risiko, "avstem, aldri bare legg til" og lukkbarheten som følger av det, kunnskap via prompt-on-demand, den forebyggende modusen, sporing med identitet etter navn og grensen om kun forsvar er metodikken. Et annet team kunne implementert dem i en annen stack og et annet agentøkosystem, og resultatet ville fortsatt vært SDH. Lagune er beviset, ikke definisjonen. --- ## XVI. Fallgruver, og hvordan SDH unngår dem strukturelt Metodikker i denne familien har et kjent sett med feilmoduser. Svaret SDH har på de fleste av dem, er strukturelt, bygget inn i flyten i stedet for overlatt til disiplin. | Fallgruve | Feilen | Det strukturelle svaret i SDH | | -------------------------------------------- | -------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | | Forfalne spesifikasjoner, utdatert etterslep | Artefakter samler døde oppføringer ingen stoler på | "Avstem, aldri bare legg til" (`§V`): Hver kjøring sjekker hver oppføring på nytt og fjerner det som er løst | | Falsk trygghet, bestått resultat | Et sikringstiltak som finnes, antas å lukke risikoen | Verify holder koden opp mot loggen, så "Risk not closed" og "Cannot tell" er fullverdige konklusjoner (`§IV`, `§XV`) | | Sjekklisteflom | Generiske punkter skjuler den ene risikoen som betyr noe | Kontekstbevisst fremfor generisk, med prompt-on-demand som bare laster det omfanget krever (`§VII`) | | Innlåsing i verktøy | Metoden er sveiset fast til én leverandør eller agent | Agentuavhengig bærer: Sikkerhetsverdien skrives én gang, og leveransen til hver agent har ingen sikkerhetslogikk (`§XII`) | | Den endeløse løkken | Etterslepet lukkes aldri, arbeidet kommer aldri til ro | Lukkbarhet og tilstanden i ro (`§V`) | **Tabell 4.** Kjente fallgruver i denne metodikkfamilien og det strukturelle svaret SDH har på hver av dem. Poenget er å navngi fallgruven og peke på mekanismen: Dette er ikke advarsler om å være forsiktig, men egenskaper ved flyten. --- ## XVII. Videre arbeid Metodikken og referanseimplementasjonen har tydelige neste steg. - **Utvide kunnskapskatalogen:** Hvert tillegg beholder formen fra `§VII`: en kunnskapsfil og en katalograd, ingen ny kommando. Veien på brukersiden finnes allerede der: Brukeren destillerer sine egne spesialiseringer ved behov. Flere innebygde språk, kjøretider og risikoklasser, hver i en kategori, er retningen på vedlikeholdersiden, og spesialiseringene forventes å utvikle seg. - **Flere deterministiske kontroller:** Der en risikoklasse har en skarp beslutningsprosedyre, kan en spesialisering ha en deterministisk kontroll som forankrer agentens resonnering i en repeterbar konklusjon. Å utvide dette til flere risikoklasser er en naturlig retning. - **Empirisk evaluering:** Det viktigste åpne spørsmålet er målt effekt: kvaliteten på lukkingen og andelen feilaktige konklusjoner på tvers av virkelige kodebaser. En studie av sikkerhetsresultatene til SDH er fremtidig arbeid, og påstandene her er avgrenset deretter. --- ## XVIII. Konklusjon KI-assistert utvikling åpnet et sikkerhetsgap som generiske sjekklister ikke kan fylle, fordi risikoen som betyr noe, er spesifikk for det et system faktisk gjør, og personen som leverer det, kanskje ikke vet hva det skal spørres om. SDH lukker dette gapet med en kontekstbevisst, kun defensiv og lukkbar flyt der sikkerhetskunnskapen ligger i metodikken og spesialiseringene som lastes ved behov, et grunnlag enhver bruker kan bygge videre på. Den oppdager den reelle konteksten til systemet, prioriterer risikoene den konteksten fører med seg, tar i bruk utbedringer med omhu og verifiserer hver av dem, og tar deretter ut det den har lukket, så hvert funn når en sluttilstand. Det samme forsvaret kjører også forebyggende mens nytt arbeid bygges, så det flyten lukker, forblir lukket. Den tilpasser seg enhver utviklingstilstand i enhver stack, og den utvider utviklerens kunnskap i stedet for å erstatte menneskene og verktøyene som allerede gjør den jobben. Lagune er beviset, men bidraget er konvensjonen. SDH tilbys som den essensielle sikkerhetsflyten for tiden med KI-assistert utvikling, slik at andre kan ta den i bruk, forbedre den og implementere den i sine egne stacker. --- ## Referanser **[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. --- ## Vedlegg A: prinsippene, ordrett 1. **Sikker som standard, i et enkelt språk, likt for alle:** Hver standardinnstilling, melding og utbedring må være sikker fra start og forståelig for enhver bruker, utvikler eller ikke. Ingen brukergruppe er privilegert fremfor en annen. 2. **Kontekstbevisst fremfor generisk:** Hver fase må starte fra konteksten som ble oppdaget i detect, og handle ut fra det systemet faktisk gjør. Foretrekk anbefalinger som er spesifikke for den konteksten, fremfor generiske sjekklister. Sikkerhetskunnskapen ligger i spesifikasjonen og spesialiseringene som lastes ved behov, og utvider det brukeren tar med seg. 3. **Fleksibel fremfor rigid:** SDH tilpasser seg prosjektet og brukeren. Prinsipper, krav og anbefalinger er utgangspunkter, ikke en fast kontrakt. La brukeren omformulere, droppe, legge til eller snevre inn hva som helst. Fleksibilitet svekker aldri grunnlaget som er sikkert som standard, den lar bare brukeren forme hvordan det brukes. 4. **Avstem, aldri bare legg til:** Artefakter er levende dokumenter, ikke logger. Avstem hver eksisterende oppføring mot den nåværende sannheten når en fase kjøres på nytt: Behold det som fortsatt holder, skriv om det som er endret, og fjern det som ikke lenger gjelder. Lukking er den samme avstemmingen, ført helt til ende. 5. **Kun defensiv:** SDH reviderer, herder og verifiserer. Den lager aldri offensive verktøy, exploits for ondsinnet bruk eller teknikker for å unngå deteksjon for å gjøre skade. Sikkerhetsinnhold med dobbel bruk er bare akseptabelt i en tydelig defensiv og autorisert ramme. 6. **Spec-first, agentdrevet, innrettet mot sikkerhet:** Bygg arbeidsflyten på en velprøvd struktur: maler, kommandoer, styrende sikkerhetsprinsipper og en agent som kjører fasene. Implementer den strukturen på nytt med et defensivt formål. --- # Ordliste for Lagune: SDH, charter, funn og sikringstiltak > Alle begrepene i Lagune og Security-Driven Hardening forklart i et enkelt språk: SDH, charter, detect, funn, sikringstiltak, harden, verify, ta ut, lukkbarhet, spesialiseringer, kategorier og katalogen. Kanonisk URL: https://lagune.ai/no-NO/docs/references/glossary Språk: no-NO Original: https://lagune.ai/docs/references/glossary Sist oppdatert: 2026-11-09 Hvert sentralt begrep i Lagune og metodikken Security-Driven Hardening, definert én gang, i et enkelt språk. ### Security-Driven Hardening (SDH) Metodikken Lagune implementerer: en kontekstbevisst Blue Team-konvensjon som oppdager konteksten til et system, prioriterer risikoene den konteksten fører med seg og veileder utbedringene. Sikkerhetskunnskapen ligger i spesifikasjonen og spesialiseringene som lastes ved behov, så utviklere og ikke-utviklere bruker den samme flyten. ### Lagune Referanseimplementasjonen av SDH: ni agentkommandoer, hver med malen den fyller ut, som en KI-agent kjører for å herde en kodebase. Hver agent installerer dem gjennom sitt eget plugininstallasjonsprogram eller gjennom [**skills.sh**](https://www.skills.sh/wellwelwel/lagune), slik [installasjonssiden](https://lagune.ai/no-NO/docs) viser, og de kjører motoren i Lagune for hvert deterministiske steg. ### Charter Det overordnede laget i Lagune: et sett med prinsipper der sikkerheten kommer først, og som hver senere fase må respektere. Tenk på det som en kompileringstidskontroll for sikkerhetsnivået i et prosjekt. Det lagres i `.lagune/memory/charter.md`. ### Utviklingsflyt Den universelle kommandoen `/lagune`, som herder arbeidet mens det skrives. Den tar imot en hvilken som helst prompt på et hvilket som helst stadium, bygger det du ba om og herder det med sikre standardinnstillinger før den leverer det tilbake, styrt av sikkerhetsprinsippene når de finnes. Den skriver ingenting til sporingen i Lagune, så det eneste den produserer, er den herdede koden. Sammen med fasen charter (før) og Blue Team-flyten (etter) er det slik Lagune beskytter mens du bygger. ### Blue Team-flyt Revisjonen i fem faser i kjernen av Lagune: charter, detect, plan, harden, verify. Hver fase bygger på den forrige. "Blue Team" er sikkerhetstradisjonen til forsvarerne, i motsetning til det offensive Red Team. ### Funn Én oppdaget risiko. Hvert funn beskriver hva det er, hvorfor det betyr noe og belegget i koden. Et funn er den ene sporede enheten som plan, harden og verify fører videre, identifisert ved navn i hver artefakt. ### Sikringstiltak Et sikkerhetstiltak som tas i bruk for å lukke en risiko. Fasen harden tar i bruk sikringstiltak, og verify beviser at de holder. Lagune svekker aldri et sikringstiltak for å etterkomme en prompt. ### Detect Fasen som leser koden og kartlegger hva systemet gjør og hvor risikoene ligger. Den overordnede regelen er å oppdage, ikke finne på: den registrerer bare det koden underbygger. ### Harden Den eneste fasen som rører koden din. Den tar i bruk utbedringene fra forsvarsplanen én om gangen og registrerer hver som Applied, Partial eller Blocked. Applied betyr ikke at den er bevist ennå. ### Verify Fasen som beviser at hver utbedring som er tatt i bruk, holder, ved å lese koden og holde den opp mot det harden registrerte. Den gir én av tre konklusjoner: Risk closed, Risk not closed eller Cannot tell from the code. ### Ta ut Når verify beviser at en risiko er lukket, tas funnet ut: det fjernes fra hele kjeden, med din bekreftelse, slik at det ikke behandles på nytt. ### Lukkbarhet Egenskapen at sikkerhetsarbeid har en sluttilstand. Fordi et funn som er bevist lukket, tas ut, kan flyten komme til ro og åpnes igjen først når koden endres. SDH er lukkbar, ikke en endeløs løkke. ### Motor Pakken `lagune` på **npm**, som kommandoene kjører gjennom `npx` for hvert deterministiske steg: hookene, katalogen og kategoriene. ### Spesialisering En fokusert, språkuavhengig modul med sikkerhetskunnskap som bare lastes ved behov, aldri som standard. En spesialisering er ikke en kommando. Last en inn i en hvilken som helst prompt med `read catalog ` fra motoren, for eksempel `npx lagune read catalog regex`. ### Kategori En navngitt gruppe innebygde spesialiseringer, fra `owasp` til språkspesifikke som `javascript`, `python`, `go` og `rust`. Kategoriene et prosjekt bruker, registrert i `.lagune/configs.json`, avgjør hvilke innebygde spesialiseringer som blir med i katalogen. Så lenge ingen er registrert, bruker prosjektet bare `owasp`. ### Katalog Settet med spesialiseringer et prosjekt bruker: de innebygde fra kategoriene pluss prosjektets egne, skrevet med `/lagune-specialize`. Motoren lister den med `read catalog`, og fasene sammenligner den med koden. ### Prompt-on-demand Prinsippet om at den relevante sikkerhetskunnskapen hentes inn ut fra hva prosjektet faktisk er, i stedet for at hver kontroll kjører som standard. ### Identitet etter navn Sporingsmodellen i Lagune: navnet på hvert funn, skrevet likt som seksjonstittel i hver artefakt, er identiteten gjennom hele kjeden. Sporingskartet (`.lagune/tracking.json`) inneholder bare sporing, aldri løpende tekst. ## Vanlige spørsmål ### Hva er Security-Driven Hardening (SDH)? SDH er en kontekstbevisst Blue Team-metodikk for sikkerhet. Den oppdager konteksten til et system, prioriterer risikoene den konteksten fører med seg og veileder utbedringene, med hvert funn i et enkelt språk. Lagune er referanseimplementasjonen. ### Hva er sikkerhetsprinsippene (charter) i Lagune? Sikkerhetsprinsippene er det overordnede laget i Lagune, et sett med prinsipper der sikkerheten kommer først, og som hver senere fase må respektere. De lagres i .lagune/memory/charter.md. ### Hva betyr det å ta ut et funn? Når verify beviser at en risiko er lukket, tas funnet ut: det fjernes fra hele kjeden med din bekreftelse, slik at det ikke behandles på nytt. --- # Konfigurasjonsskjema > JSON Schema for konfigurasjonen i et prosjekt med Lagune, for autofullføring og validering i editoren din, enten det følger gjeldende versjon av Lagune eller er låst til en bestemt versjon. Kanonisk URL: https://lagune.ai/no-NO/docs/references/configs-schema Språk: no-NO Original: https://lagune.ai/docs/references/configs-schema Sist oppdatert: 2026-11-09 Filen `.lagune/configs.json` registrerer [**kategoriene**](https://lagune.ai/no-NO/docs/categories) et prosjekt bruker, indekserer prosjektets egne [**spesialiseringer**](https://lagune.ai/no-NO/docs/catalog) og angir hva [**kontrollene**](https://lagune.ai/no-NO/docs/hooks/configure) skal utelate. Med JSON Schema for filen kan editoren din autofullføre hvert felt og flagge en skrivefeil eller en ukjent kategori mens du redigerer. ## Gjeldende skjema Hver gang **Lagune** skriver filen og ikke finner noen `$schema` i den, peker den filen mot gjeldende skjema: ```json { "$schema": "https://lagune.ai/schemas/configs.json", "categories": ["owasp", "javascript"] } ``` Denne adressen følger alltid gjeldende versjon av **Lagune**. En fil skrevet før **Lagune** 0.16.0 får den ved neste endring, og frem til da gjør hver fase deg oppmerksom på det. ## Lås en versjon Hver utgivelse av **Lagune** fra og med 0.16.0 inneholder skjemaet slik det var i den versjonen, publisert på **npm** og levert av **jsDelivr**. For å låse en versjon setter du versjonen etter `lagune@` i adressen i `$schema`: ```json { "$schema": "https://cdn.jsdelivr.net/npm/lagune@0.16.0/schemas/configs.json" } ``` Versjonen godtar ethvert semver-område: | Versjon | Skjema | | --------------------- | ---------------------------------- | | `0.16.0` | Det fra 0.16.0 | | `0.16.x` eller `0.16` | Det fra den nyeste 0.16-utgivelsen | | `0.x` eller `0` | Det fra den nyeste 0.x-utgivelsen | | `latest` | Det fra den nyeste utgivelsen | ## Vanlige spørsmål ### Trenger Lagune skjemaet? Nei. Skjemaet hjelper bare editoren din, og Lagune leser filen på samme måte med eller uten $schema. ### Overskriver Lagune et låst skjema? Nei. Lagune skriver $schema bare når filen mangler det, og beholder enhver adresse du har satt. ### Når bør jeg låse en versjon? Når prosjektet kjører en bestemt versjon av Lagune, slik at editoren din validerer filen mot det den versjonen godtar. --- # Lagune vs. Deepsec: to KI-drevne sikkerhetstilnærminger side om side > En referanse som sammenligner Lagune og Deepsec fra Vercel: hvordan de fungerer, livssyklus, deteksjon, kostnad, funn og lukking. Kanonisk URL: https://lagune.ai/no-NO/docs/references/deepsec Språk: no-NO Original: https://lagune.ai/docs/references/deepsec Sist oppdatert: 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 problemet: sikkerhet i en tid der KI hjelper til med utviklingen. Premisset, begynnelsen, midten og slutten, og måten hvert av dem presenterer seg for brukeren på, skiller seg bevisst fra hverandre, også der mekanikken overlapper. **Tips** Er Lagune inspirert av Deepsec? Nei, Lagune er skrevet fra bunnen av og er inspirert av Spec-Driven Development og Security Hardening. De to prosjektene er utviklet uavhengig av hverandre, og sammenligningen her skal hjelpe brukerne med å forstå forskjellene. ## Kort oppsummert | Aspekt | Lagune | Deepsec | | ---------------- | --------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ | | Type | En metodikk (SDH) med en referanseimplementasjon | Et produkt: en agentdrevet sårbarhetsskanner | | Tyngdepunkt | Sikkerhetsprinsipper og kunnskap som lastes ved behov, styrer agenten, forankret i deterministiske hooks | Et bredt regex-nett mater en obligatorisk KI-undersøkelse | | Hva det leverer | Herdet kode, bevis og en sporet kjede av funn | En triagert rapport med funn, rangert etter alvorlighetsgrad | | Endrer koden din | Ja: `harden` redigerer koden din | Nei: bare statisk analyse, leverer funn og anbefalingstekst | | Kjøremiljø | Kjører på agenten og modellen du allerede bruker, uansett nivå | Kjører sin egen modellpipeline, som standard med en frontier-modell | | Kom i gang | Én plugininstallasjon eller `npx skills add`, og deretter styrer du det med vanlig språk, uten noe nytt verktøy å sette opp | Sett opp et arbeidsområde `.deepsec/`, installer avhengigheter og legg til en modellnøkkel | ## Slik fungerer det I Lagune kommer agenten først: Den styrer, henter inn kunnskap ved behov ut fra hva koden er, og overlater til de deterministiske hookene den delen de kan avgjøre. I Deepsec kommer det deterministiske først: En bred skanning flagger kandidater som viser en obligatorisk modell hva den skal undersøke og vurdere. | Aspekt | Lagune | Deepsec | | -------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------ | | Rekkefølge | Sikkerhetsprinsippene og kunnskapen som passer, styrer agenten, som delegerer til hooks og vurderer resten selv | Matchere flagger kandidater, modellen undersøker og vurderer hver av dem | | Deterministisk rolle | Hooks for flere språk som gir en konklusjon eller retter inn agenten, kombinert med kunnskapen i kategoriene | Matchere som flagger kandidater for den obligatoriske modellen å vurdere | | Utviklingsflyt | `/lagune` bygger sikkert underveis mens du koder | Det gjennomgår kode, men skriver den ikke | | Revisjonsflyt | `charter` → `detect` → `plan` → `harden` → `verify` | `scan` → `process` → `triage` → `revalidate` → `report` | | Oppgaven til KI-en | Resonnere ut fra kunnskapen, ta i bruk utbedringen og bevise at den holder | Undersøke hver kandidat og rapportere funnene | ## Livssyklus Lagune virker før, under og etter at koden er skrevet. Deepsec gjennomgår et repository når koden finnes. | Tidspunkt | Lagune | Deepsec | | -------------------- | ------------------------------------------------------------------------------- | --------------------------------------------------------------- | | Før koden finnes | `charter` lager en sikkerhetspolicy ut fra uttalte intensjoner | Starter fra eksisterende kode: `init` trenger en mappe | | Under byggingen | `/lagune` bygger sikkert som standard underveis, uten å etterlate noen artefakt | Gjennomgår etter byggingen, ikke underveis | | På eksisterende kode | `detect` → `plan` → `harden` → `verify` | `scan` → `process`, kjerneflyten | | Løpende gjennomgang | Kjør fasene på nytt per omfang, ingen ferdigpakket CI-sperre | Inkrementell ny skanning, `process --diff` som exit-sperre i CI | ## Deteksjonslag De to deterministiske lagene er motsatte av natur: Det ene avgjør, det andre flagger. | Aspekt | Lagune | Deepsec | | ---------------- | ------------------------------------------------------------------------------------ | -------------------------------------------------------------------- | | Gruppering | Hooks og spesialiseringer, gruppert i kategorier | Matchere per mønster eller rammeverk | | Utdata | Bokstavelig konklusjon (finding / review / advisory) pluss en klassifiseringsetikett | Kandidat uten konklusjon (slug, linjer, kodeutdrag, matchet mønster) | | Justering | Presisjon: tar hensyn til kommentarer, med vern for plassholdere og søkevinduer | Recall: brede nett, KI-en luker ut falske positiver etterpå | | Dybde | Dypere på klassene begge dekker | Bredere, men mindre dyp på klassene begge dekker | | Falske positiver | Holdes lave ved kilden og vurderes deretter i kontekst | Overproduseres med vilje og skjæres ned av en runde med `revalidate` | ## Kunnskap og vurdering Begge har sikkerhetskunnskap som regex ikke kan uttrykke. De skiller seg i hvor den ligger, og hvem som kan forme den. | Aspekt | Lagune | Deepsec | | ----------------------- | ---------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- | | Form | Redigerbare markdown-moduler, flere av dem støttet av en deterministisk hook | En kort prompt og høydepunkter per teknologi, som bygger på modellens egen kunnskap | | Utvalg | Tilpasset koden, lastes bare når konteksten finnes | Settes inn i hver KI-batch, pluss høydepunkter for teknologien som er oppdaget | | Hvem som skriver den | Brukeren redigerer moduler og legger til nye med `specialize` | Vedlikeholderen eier prompten, brukeren fyller ut en `INFO.md` | | Hvor vurderingen ligger | Hookene avgjør sitt grunnlag, agenten vurderer resten ut fra kunnskapen | Sentralisert: én KI-prosessor vurderer hver kandidat | | Gjenbruk | Én modul styrer både `detect` og `verify` | Én prompt driver det eneste trinnet, `process` | ## Funn og lukking Størst forskjell er det på hva et funn blir når det er løst. | Aspekt | Lagune | Deepsec | | ------------------------ | -------------------------------------------------------------------- | -------------------------------------------------------------------------------------- | | Alvorlighetsgrad | En CVSS v4.0-score, justert for eksponering og hva som står på spill | En alvorlighetsgrad fra KI, pluss en triage P0 / P1 / P2 av utnyttbarhet og konsekvens | | Konklusjoner | Risk closed, Risk not closed eller Cannot tell from the code | true-positive, false-positive, fixed, uncertain, accepted-risk, duplicate | | Lagring | Arbeidskjeden avstemmes, lukkede funn destilleres til en historikk | Poster per fil som bare utvides, ingenting fjernes | | Sluttilstand | Lukkbar: Et bevist funn tas ut, og kjeden kan komme i ro | Hvert funn beholdes for godt og skjules i visningene når det er løst | | Detaljnivå i historikken | Et kompakt sammendrag av hva risikoen var | Hele sporet av konklusjoner, inkludert hvordan det ble utbedret | ## Kostnad | Aspekt | Lagune | Deepsec | | ----------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Deterministisk grunnlag | Gratis: Hooks kjører uten KI og uten nøkkel, og gir allerede konklusjoner | Gratis: `scan` kjører uten KI, men gir ingen konklusjoner alene | | Typisk regning | Inngår i en agent du allerede kjører: ned til 0 dollar med en lokal modell, prisen på abonnementet du allerede har, eller per iterasjon ved bruk via API | [Omtrent 25 til 1200 dollar per kjøring for 100 til 2000 filer, mer i større skala](https://github.com/vercel-labs/deepsec/blob/f75a16803ec5250938bacfe41571d929e8564f45/docs/getting-started.md#run-the-ai-investigation) | | Billigste vei | Hvilken som helst modell, også en gratis lokal, lukker syklusen | Det finnes billigere betalte nivåer, men funn krever det betalte KI-trinnet | ## Utvidbarhet og styring Hver av dem åpner laget den andre holder lukket. | Aspekt | Lagune | Deepsec | | -------------------- | ------------------------------------------------------- | ------------------------------------------------------- | | Hva du utvider | Redigere moduler, eller legge til nye via `specialize` | Legge til matchere, agenter, varslere og eierskap | | Policylag | Sikkerhetsprinsippene styrer hver fase og er versjonert | Konfigurasjonen er operativ (matchere, modeller, stier) | | Overstyring via navn | En forbedret modul overstyrer den innebygde | Ved kollisjon mellom matcher-slugs vinner din matcher | ## Grensesnitt Deepsec leverer resultater til en sikkerhetsorganisasjon. Lagune viser en live-visning for den som kjører det. | Aspekt | Lagune | Deepsec | | ----------------------- | --------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | | Flate for mennesker | Et lokalt live-dashbord over hele kjeden, på vanlig språk | Filer for rapport, eksport, metrikker og PR-kommentarer, pluss et dokumentasjonsnettsted | | Ansvar | Viser filer og spesialiseringene som ble brukt | Foreslår en ansvarlig: vakthavende, leder eller committer | | Reproduserbart bevis | `prove` skriver kjørbare tester og et sikkerhetsvarsel for offentliggjøring | Forblir statisk med vilje og kjører aldri målet | | Verktøyets eget forsvar | Herder et lokalt skrive-API i dashbordet | Herder sin egen KI-kjøring mot ikke-klarert målkode | ## Skala og utrulling | Aspekt | Lagune | Deepsec | | ----------------- | ---------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------- | | Installasjon | Ni kommandoer fra pluginen til agenten din eller CLI-en til **skills**, uten at noe opprettes i prosjektet | Et arbeidsområde `.deepsec/` med egen pakke og egne avhengigheter | | Skaleringsretning | Avgrenses til et hvilket som helst utsnitt, en kontekst, fra én fil til hele prosjektet | Skanner hele repositories, helt opp til store monorepos | | Distribusjon | Bare lokalt, den ene serveren lytter på loopback | Valgfri fordeling over worker-VM-er i Vercel Sandbox | ## Brukeropplevelse Hvordan hver av dem møter den som kjører dem: hva den første kjøringen krever, og hvordan brukeren styrer dem. ### Oppstart Lagune kjører gjennom agenten som allerede er åpen. Deepsec setter først opp sitt eget arbeidsområde og tilgang til modellen. | Aspekt | Lagune | Deepsec | | ------------------------------ | --------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- | | Første kommando | Plugininstallasjonen eller `npx skills add wellwelwel/lagune`, deretter `/lagune-*` i agenten | `npx deepsec init`, deretter `cd .deepsec`, `pnpm install`, `scan`, `process` | | Påloggingsdetaljer for å kjøre | Ingen egen nøkkel, det bruker agenten du har nå | En modellnøkkel (f.eks. AI Gateway, et OIDC-token fra Vercel som varer i 12 timer, eller et token fra Anthropic) | ### Styring Begge tar imot føringer. Lagune leser formen på inndataene i hver fase. Deepsec snevrer inn filutvalget den samme undersøkelsen kjører over. | Aspekt | Lagune | Deepsec | | ------------------ | ---------------------------------------------------------------------------------------- | ------------------------------------------------------------ | | Hele prosjektet | En fase uten inndata skanner hele omfanget | `scan` og `process` skanner hele repositoryet | | Et utsnitt | Alle faser kan avgrenses til gitte filer eller mapper | `--files`, `--files-from` eller `--diff` avgrenser kjøringen | | En problemstilling | En fase kan avgrenses til en beskrevet bekymring | Prompten for undersøkelsen er fast | | Et prioritetsnivå | `harden` og `verify` kan avgrenses til kritisk, høy, middels eller lav | Funn merkes etter kjøringen | | Én enkelt verdi | En hook vurderer ett kodeutdrag, ett mønster eller én URL direkte (`--pattern`, `--url`) | Arbeidsenheten er en fil | ## Vanlige spørsmål ### Hva er forskjellen på Lagune og Deepsec? I Lagune kommer agenten først, og det virker før, under og etter at koden er skrevet: Det fastsetter policy før koden finnes, herder underveis mens du bygger, og reviderer, herder og verifiserer kode som allerede er skrevet. I Deepsec kommer det deterministiske først: En bred regex-skanning mater en obligatorisk undersøkelse med en frontier-modell, som gjennomgår eksisterende kode og rapporterer funn uten å endre den. ### Kan jeg bruke noen av dem gratis? Hele flyten i Lagune kan kjøre for 0 dollar på en gratis lokal modell, og de deterministiske hookene gir konklusjoner helt uten KI. Skanningen i Deepsec er gratis, men gir ingen konklusjoner, så alle funn krever det betalte KI-trinnet. ### Endrer noen av dem koden min? Lagune gjør det: harden tar i bruk utbedringer i koden din. Deepsec gjør det ikke: Det er bare statisk analyse og leverer funn og anbefalingstekst som en person eller agent tar i bruk separat. --- # OWASP-kilder > Hvor kunnskapen i de innebygde OWASP-spesialiseringene kommer fra, koblet til de kanoniske OWASP-sidene om angrep og Cheat Sheets. Kanonisk URL: https://lagune.ai/no-NO/docs/references/owasp-sources Språk: no-NO Original: https://lagune.ai/docs/references/owasp-sources Sist oppdatert: 2026-11-09 Dette dokumentet knytter hvert **angrep** (`www-community`) og hvert **Cheat Sheet** (`CheatSheetSeries`) fra OWASP til en sikkerhetskategori, hver med lenke til den kanoniske offentlige siden. Innenfor en kategori deler likeverdige oppføringer én linje i sjekklisten: Angrepene og Cheat Sheets som håndterer den samme risikoen, står sammen, skilt med komma. Oppføringer uten en direkte motpart står på en egen linje. - Æren tilhører OWASP. Angrepene ligger på `https://owasp.org/www-community/attacks/`, og Cheat Sheets på `https://cheatsheetseries.owasp.org/cheatsheets/.html`. --- ## 1. Injeksjon (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 databaseinjeksjon - [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 kommandoinjeksjon - [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-injeksjon - [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 videresendinger - [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. Tilgangskontroll og autorisasjon - [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. Autentisering og påloggingsdetaljer - [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. Økthå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øderasjon (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 transportsikkerhet - [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. Misbruk av HTTP-protokollen (headere, 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. Koding og innholdsforfalskning - [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 regnearkinjeksjon - [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. Tjenestenekt - [x] [Regular expression Denial of Service (ReDoS)](https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS) (regex) --- ## 20. Minnesikkerhet 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 kjøring av ikke-klarert 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. Skadevare 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. Logging, benektelse og feilhå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. Forretningslogikk og misbruk av funksjonalitet Forretningslogikk og misbruk av funksjonalitet har ingen enkelt flate i koden som en spesialisering per flate kan forsvare: Forsvaret ligger i applikasjonsspesifikt design, den samme vurderingen som trusselmodelleringen i prosjektet driver. Flyttet til "Utenfor omfanget". --- ## 26. Sikkerhet for KI, 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. Rammeverk og språkplattformer - [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. Webfrontend og nettleser - [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. Sky, containere og infrastruktur Konfigurasjon av containere og arbeidslaster er konfigurasjon som kode som utvikleren leverer sammen med appen (`Dockerfile`, Compose, `securityContext` for Pod), en reell flate som `harden` utbedrer og `verify` beviser, så den er innenfor omfanget. Klyngeadministrasjon (RBAC, etcd, API-server, admission, nettverkssegmentering) er driftsansvarliges domene og holdes utenfor 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 arbeidslaster og Pods. Klyngeadministrasjon holdes utenfor omfanget) - [x] [Serverless / FaaS Security](https://cheatsheetseries.owasp.org/cheatsheets/Serverless_FaaS_Security_Cheat_Sheet.html) (serverless) --- ## 32. Forsyningskjede 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. Hemmeligheter og konfigurasjon Håndtering av hemmeligheter er en driftsoppgave: hvelv, CI/CD, skykonfigurasjon, rotasjon. Den ene siden som gjelder koden (en hemmelighet hardkodet i kildekoden), dekkes av en deterministisk gjennomgang, ikke av en risikospesialisering. Flyttet til "Utenfor omfanget". --- ## 34. Prosess, design og styring Personvern for brukere handler om retningslinjer og design (dataminimering, åpenhet, oppbevaring), ikke om en flate i koden som en spesialisering forsvarer. Flyttet til "Utenfor omfanget". --- ## 35. Betalinger og etterlevelse - [x] [Secure Integration of Third-Party Payment Gateways](https://cheatsheetseries.owasp.org/cheatsheets/Third_Party_Payment_Gateway_Integration_Cheat_Sheet.html) (payment) --- ## 36. Innebygde systemer, IoT og spesialiserte domener Sikkerhet for kjøretøy og droner hører til domenet for innebygde systemer (CAN-buss, OTA-fastvare, integritet for sensorer og radio, fysisk tilgang), ikke til kildekoden for web- og API-applikasjoner som Lagune reviderer. Flyttet til "Utenfor omfanget". --- ## Utenfor omfanget (ingen flate i koden) Dette er ikke områder for spesialiseringer og har ingen avkrysningsboks: Det dreier seg om styring, prosess, herding av driften eller bruk av rammeverk, uten en enkelt flate i koden som en spesialisering per flate kan forsvare. Sikkerhetsverdien er reell, men den ligger i prosess og arkitektur (eller, for et rammeverk, i den egne skillen for det språket), ikke i et forsvar denne katalogen leverer. De står her som referanse, ikke som arbeid som gjenstår. - [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) (forsterkning via SOAP/WS-Addressing, en driftsmessig DoS-variant uten flate 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) (skadevare hos sluttbrukeren, ikke en flate i koden til prosjektet som revideres. Leveransen i nettleseren hører til `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 avveininger: IAM kontra signerte URL-er, offentlige og private VPC-er, tillitsgrenser, delt ansvar. I motsetning til `container` har den ingen konkret konfigurasjon som en spesialisering sjekker) - [Infrastructure as Code Security](https://cheatsheetseries.owasp.org/cheatsheets/Infrastructure_as_Code_Security_Cheat_Sheet.html) (til tross for navnet handler det om SDLC-prosess og verktøy for å _forvalte_ IaC: IDE-plugins, statisk analyse, skanning av images, CI/CD, signering. Den viser ingen vei fra et usikkert mønster til en trygg form i en Terraform- eller CloudFormation-fil) - [Kubernetes Security](https://cheatsheetseries.owasp.org/cheatsheets/Kubernetes_Security_Cheat_Sheet.html) (_bare delen om klyngeadministrasjon_: RBAC, etcd, API-server, admission. Delen om arbeidslaster og Pods er innenfor omfanget under `container`) - [Network Segmentation](https://cheatsheetseries.owasp.org/cheatsheets/Network_Segmentation_Cheat_Sheet.html) (nettverksarkitektur og brannmurregler) - [Subdomain Takeover Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Subdomain_Takeover_Prevention_Cheat_Sheet.html) (livssyklus og overvåking av DNS, ikke kode) - [Secrets Management](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html) (hvelv, CI/CD, rotasjon. Hardkodede hemmeligheter dekkes av en deterministisk gjennomgang, ikke av en risikospesialisering) - [C-Based Toolchain Hardening](https://cheatsheetseries.owasp.org/cheatsheets/C-Based_Toolchain_Hardening_Cheat_Sheet.html) (flagg for kompilator, linker og bygging, uten 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 konfigurasjon av feilhåndtering per stakk. Lekkasjen er den samme avsløringen som feilhå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) (applikasjonsspesifikt design, ingen enkelt sink i koden) - [User Privacy Protection](https://cheatsheetseries.owasp.org/cheatsheets/User_Privacy_Protection_Cheat_Sheet.html) (dataminimering, åpenhet, regler for oppbevaring) - [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) (domener for innebygde systemer: CAN-buss, OTA-fastvare, integritet for sensorer og radio, ikke kildekode for web og API) - [Mobile Application Security](https://cheatsheetseries.owasp.org/cheatsheets/Mobile_Application_Security_Cheat_Sheet.html) (herding av plattformene Android og iOS: lagring, biometri, pinning, personopplysninger. Den har ingen enkelt flate i koden, og innlasting av ikke-klarert kode ble flyttet til `interpreter`) - [Threat Modeling](https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html), [Threat Modeling _(fellesskapsside)_](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: Reparer ødelagt sporing av funn > Reparer kjeden når et nytt filnavn eller en flyttet fil forvirrer sporingen i Lagune. Kanonisk URL: https://lagune.ai/no-NO/docs/commands/repair Språk: no-NO Original: https://lagune.ai/docs/commands/repair Sist oppdatert: 2026-11-09 🧰 Reparer kjeden når et nytt filnavn eller en flyttet fil forvirrer den. **Internt vedlikehold, ikke en sikkerhetsfase** Repair er ikke en sjette fase i den lineære flyten. Jobben er å holde sporingen sammenhengende. ```prompt # Kommandoen tar ingen inndata: Den reparerer alltid hele kjeden /lagune-repair ``` ## Slik fungerer det Hvert funn fra detect er ett sporet element som plan, harden og verify tar videre, og hver av dem behandler det og rapporterer det på nytt under navnet. Dette navnet, skrevet likt som seksjonstittel i hver artefakt, er identiteten til elementet hele veien. Det eneste foranderlige sporingen lagrer, er filstiene elementet peker på. Disse stiene finnes ingen andre steder, så et nytt filnavn eller en flyttet fil kan bare bryte koblingen der, aldri i to kopier som glir fra hverandre. Når det skjer, retter repair kartet (`.lagune/tracking.json`), slik at identiteten overlever navneendringen. Kommandoen leser artefaktene og sporingskartet, leser kildekoden din bare for å finne den nye stien til en fil som har fått nytt navn, og skriver aldri sikkerhetsinnhold selv. I samme gjennomgang sjekker den hver minneartefakt mot malen og rapporterer hva som har drevet av, med henvisning til fasen som retter det. **Tips** - Den rører verken koden din eller tekstartefaktene, bare sporingen. - Du kjører den sjelden for hånd. Når en fase merker at kjeden er inkonsekvent, kjører den repair for deg og fortsetter. - Sporingen den vedlikeholder, ligger i `.lagune/tracking.json`, en intern tilstand du aldri redigerer for hånd. --- # Migrate: Flytt et prosjekt fra manifestbasert Lagune til skills og plugins > Flytt et prosjekt fra den manifestbaserte versjonen av Lagune til versjonen basert på skills, og behold sikkerhetsprinsippene, artefaktene, sporingen og dine egne spesialiseringer. Kanonisk URL: https://lagune.ai/no-NO/docs/commands/migrate Språk: no-NO Original: https://lagune.ai/docs/commands/migrate Sist oppdatert: 2026-11-09 🔀 Flytt et prosjekt fra den manifestbaserte versjonen av **Lagune** til versjonen av **Lagune** basert på skills, og behold alt du har skrevet. **Varsel om utfasing** Et prosjekt med manifest fungerer som før frem til `v1.x`: `npx lagune` overlater `init`, `pull`, `update`, `add`, `remove`, `list` og dashbordet til `lagune@0.15.0`, den siste manifestbaserte versjonen. ## Slik flytter du det 1. Sørg for at det du jobber med nå, er committet, og kjør deretter migrate fra rotmappen i prosjektet: ```bash npx lagune migrate ``` 2. Commit bare det migrate endret, slik at flyttingen forblir én endring som er lett å gå gjennom. 3. Installer kommandoene for agenten din, slik [installasjonssiden](https://lagune.ai/no-NO/docs) viser. 4. Har prosjektet allerede en artefakt fra detect, plan eller harden, be [`/lagune-repair`](https://lagune.ai/no-NO/docs/commands/repair) om å avstemme de gamle referansene i dem og i dine egne spesialiseringer: ```prompt /lagune-repair Avstem spesialiseringene som er tatt i bruk (tidligere sub-skills) i artefaktene under `.lagune/memory/` (`detect.md`, `plan.md` og `harden.md`) med navnene den nye katalogen lister opp, og skriv om hvert kall mine egne spesialiseringer i `.lagune/catalog/` gjør til de gamle hookene i `.lagune/hooks/`, til et kall til verktøyet `lagune_read` eller `lagune_write`. ``` ## Hva som endres | Før | Etter | | ---------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- | | `.lagune/templates/`, `.lagune/hooks/` og `.lagune/specializations.md` | Fjernet: Hver skill har med seg sin egen mal, og motoren kjører hookene | | Kopiene av innebygde spesialiseringer i `.lagune/skills/` | Fjernet: Motoren leverer de innebygde | | Dine egne spesialiseringer i `.lagune/skills/` | Flyttet til `.lagune/catalog/` | | `.lagune/skills.json`, indeksen over dine egne spesialiseringer | Slått sammen med `.lagune/configs.json` | | Kategoriene i manifestet | Registrert i `.lagune/configs.json` | | De gamle agentkommandoene, for eksempel `/lagune.detect` | Fjernet: Når du [installerer **Lagune**](https://lagune.ai/no-NO/docs), får du de nye, for eksempel `/lagune-detect` | | Blokken for **Lagune** i `.gitignore` | Fjernet, sammen med filen når den ikke inneholdt noe annet | | `.lagune/proofs/`, ignorert av den blokken | Holdt utenfor commits av sin egen `.gitignore` | | `.lagune/manifest.json` | Slettet, til sist | Sikkerhetsarbeidet ditt forblir som det er: sikkerhetsprinsippene, artefakten hver fase produserte, og sporingskartet med stiene hvert funn peker på. ## Vanlige spørsmål ### Må jeg migrere? Ja. Manifestbaserte prosjekter er utfaset og fungerer bare frem til v1.x, så kjør npx lagune migrate for å flytte ditt. ### Hva beholder migrate? Sikkerhetsprinsippene, hver artefakt fra fasene, sporingskartet, kategoriene og dine egne spesialiseringer. Spesialiseringene flyttes til .lagune/catalog/, og indeksen over dem havner sammen med kategoriene i .lagune/configs.json. ### Når installerer jeg de nye kommandoene? Etter migrate, slik installasjonssiden viser for agenten din. Det går også an å installere først, siden migrate beholder den nye /lagune. ### En kollega har allerede migrert. Hva kjører jeg? Hent flyttingen med pull, og kjør deretter npx lagune migrate én gang. Den fjerner det den manifestbaserte versjonen av Lagune etterlot i klonen din, som versjonskontrollen aldri tok med, og holder bevisene dine utenfor commits.