# Lagune > Security-Driven Hardening per qualsiasi codebase Lagune è un flusso di lavoro di Security-Driven Hardening (SDH) open source ed esclusivamente difensivo. Aiuta il tuo agente IA a mettere in sicurezza qualsiasi codebase, in qualsiasi linguaggio e in ogni momento: il charter stabilisce le regole di sicurezza prima che tu inizi a sviluppare, il comando universale /lagune mette in sicurezza il lavoro mentre viene scritto e il flusso Blue Team in cinque fasi rileva cosa fa davvero il tuo sistema e guida le correzioni che contano in quel contesto. I suoi comandi si installano nel tuo agente con la CLI di skills, e non serve alcuna chiave API. --- # Installazione: hardening di sicurezza per qualsiasi agente IA > Installa Lagune in qualsiasi progetto, come plugin dove il tuo agente lo supporta o altrove con la CLI di skills, poi scegli le specializzazioni di sicurezza adatte. Canonico: https://lagune.ai/it-IT/docs Lingua: it-IT Originale: https://lagune.ai/docs Ultimo aggiornamento: 2026-11-03 **Lagune** aiuta il tuo agente IA a rendere un progetto più sicuro. Lo punti sul tuo codice e l'agente capisce cosa fa davvero il tuo sistema, poi ti guida nel lavoro di sicurezza che conta per quel sistema. **Lagune** è il primo progetto della metodologia [Security-Driven Hardening (SDH)](https://lagune.ai/it-IT/docs/references/paper). **Sostieni l'open source** Ti piace **Lagune**? [Lasciaci una ⭐ su **GitHub**](https://github.com/wellwelwel/lagune) ## Scegli il tuo agente - [Claude Code](https://lagune.ai/it-IT/docs/install/claude-code): Lo strumento di programmazione agentico di Anthropic - [Codex](https://lagune.ai/it-IT/docs/install/codex): L'agente di programmazione di OpenAI - [Cursor](https://lagune.ai/it-IT/docs/install/cursor): L'editor di codice con l'IA - [GitHub Copilot](https://lagune.ai/it-IT/docs/install/github-copilot-cli): Il programmatore in coppia con l'IA di GitHub - [Gemini CLI](https://lagune.ai/it-IT/docs/install/gemini-cli): L'agente da terminale open source di Google - [Antigravity](https://lagune.ai/it-IT/docs/install/antigravity-cli): La piattaforma di sviluppo agentica di Google - [OpenCode](https://lagune.ai/it-IT/docs/install/opencode): L'agente di programmazione open source - [Devin for Terminal](https://lagune.ai/it-IT/docs/install/devin-cli): L'agente da terminale di Cognition - [Factory Droid](https://lagune.ai/it-IT/docs/install/factory-droid): L'agente di sviluppo software di Factory - [Grok Build](https://lagune.ai/it-IT/docs/install/grok-build): L'agente di programmazione di xAI - [Qwen Code](https://lagune.ai/it-IT/docs/install/qwen-code): L'agente di programmazione da terminale di Qwen - [Kimi Code](https://lagune.ai/it-IT/docs/install/kimi-code): L'agente di programmazione di Moonshot AI - [Muse Code](https://lagune.ai/it-IT/docs/install/muse-code): L'agente di programmazione di Meta - [Pi](https://lagune.ai/it-IT/docs/install/pi): Un agente di programmazione minimale da terminale - [Hermes Agent](https://lagune.ai/it-IT/docs/install/hermes-agent): L'agente open source di Nous Research - [Universale](https://lagune.ai/it-IT/docs/install/universal): Cline, Kiro CLI, Windsurf, Zed e altri 66 **Info** - **Lagune** gira su **Node.js** dietro le quinte, ma tu usi il linguaggio che preferisci. - Per lavorare completamente offline, installa **Lagune** nel tuo progetto con `npm i -D lagune@0.16.0`. ## Categorie Le conoscenze di sicurezza di **Lagune** arrivano come [**specializzazioni**](https://lagune.ai/it-IT/docs/catalog), raggruppate in [**categorie**](https://lagune.ai/it-IT/docs/categories). - **OWASP** (`owasp`): Protegge dai rischi di sicurezza applicativa che OWASP monitora: injection, controllo degli accessi inefficace, falle di autenticazione e di crittografia - **Infrastruttura** (`infra`): Mette in sicurezza la configurazione di container, workload e serverless: Dockerfile, Compose, sicurezza dei Pod, IAM e trigger FaaS - **IA / LLM** (`ai`): Protegge le integrazioni di IA e LLM dalla prompt injection e da collegamenti non sicuri con strumenti, agenti, retrieval e MCP - **Lovable** (`lovable`): Mette in sicurezza le app Supabase generate dall'IA (Lovable e simili): lacune nelle RLS, chiavi service_role esposte e impostazioni predefinite non sicure - **JavaScript** (`javascript`): Protegge JavaScript e i suoi runtime dalla RCE tramite eval e child_process, dal path traversal e dalla prototype pollution - **Python** (`python`): Protegge Python dalla RCE per deserializzazione con pickle e YAML, dall'attraversamento tramite str.format e dalla class pollution - **Rust** (`rust`): Protegge Rust da API unsafe non corrette, uso improprio di transmute, integer overflow e comportamento indefinito al confine FFI - **Java** (`java`): Protegge Java dalle catene di gadget di deserializzazione con ObjectInputStream che culminano nell'esecuzione di codice remoto - **Ruby** (`ruby`): Protegge Ruby dalle catene di gadget di deserializzazione con Marshal.load e YAML che portano all'esecuzione di codice remoto - **PHP** (`php`): Protegge PHP dall'aggiramento dell'autenticazione per type juggling, dalle catene di gadget di object injection e dalle configurazioni predefinite non sicure - **Go** (`go`): Protegge Go da bug di interfacce con nil tipizzato, data race tra goroutine e concorrenza non sicura nei percorsi di sicurezza - **C / C++** (`c-cpp`): Protegge C e C++ da bug di format string, buffer overflow e scritture fuori dai limiti che permettono l'esecuzione di codice - **.NET** (`dotnet`): Protegge .NET e C# dalla RCE per deserializzazione con BinaryFormatter e dagli aggiramenti degli encoder che portano a XSS Esegui `npx lagune write add --categories` con le chiavi delle categorie che scegli. **Suggerimento** Un progetto parte con `owasp`, e [`/lagune-charter`](https://lagune.ai/it-IT/docs/commands/charter) aggiunge le categorie che la sua lettura del progetto giustifica. ## Requisiti Ti serve [**Node.js (LTS)**](https://nodejs.org/en/download/package-manager) installato sul tuo sistema. ## Usa un badge ✨ Usi **Lagune**? Aggiungine uno al tuo **README**: **Due toni** ![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) ``` **Tinta unita** ![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) ``` ## Passo successivo Scopri cosa fa ciascuna delle [**skill**](https://lagune.ai/it-IT/docs/get-started/commands) di **Lagune**. ## Domande frequenti ### Che cos'è Lagune? Lagune è un flusso di sicurezza open source ed esclusivamente difensivo che aiuta il tuo agente IA a mettere in sicurezza qualsiasi codebase. Lo punti sul tuo codice, rileva cosa fa davvero il tuo sistema, poi guida le correzioni di sicurezza che contano in quel contesto. ### Come si installa Lagune? Scegli il tuo agente: Claude Code, GitHub Copilot CLI, Muse Code, Antigravity CLI, Cursor, Kimi Code, OpenCode, Codex CLI, Factory Droid, Grok Build, Devin CLI e Hermes Agent installano Lagune come plugin, Gemini CLI e Qwen Code come estensione, Pi come pacchetto e qualsiasi altro agente con npx skills add wellwelwel/lagune. Funziona sia nei progetti nuovi sia in quelli esistenti. ### Lagune ha bisogno di una chiave API? No. Funziona tramite il tuo agente IA, quindi non serve alcuna chiave API. ### Quali sono i requisiti? Ti serve Node.js (LTS) installato sul tuo sistema. ### Quali linguaggi di programmazione supporta Lagune? Tutti. Lagune gira su Node.js dietro le quinte, ma verifica e mette in sicurezza progetti scritti in qualsiasi linguaggio di programmazione. ### Cosa aggiunge Lagune al mio progetto? Una directory .lagune/ con lo stato di sicurezza del tuo progetto, creata dal primo comando che scrive. La CLI di skills installa anche i comandi slash nel progetto, dove il tuo agente li legge, mentre un plugin li tiene dentro l'agente. ### Come si aggiorna Lagune? Nello stesso modo in cui l'hai installato. La pagina di installazione di ogni agente mostra come aggiornare Lagune lì, e la CLI di skills lo aggiorna con npx skills update. Il tuo charter, gli artefatti delle fasi e le tue specializzazioni restano intatti. ### Quali specializzazioni usa un progetto? Quelle integrate delle sue categorie, più le sue. Il charter registra le categorie che la sua lettura del progetto giustifica, e npx lagune write add --categories le modifica. ### Devo finire di sviluppare prima di mettere in sicurezza il mio progetto? No. Il comando /lagune mette in sicurezza il lavoro mentre viene scritto: accetta qualsiasi prompt, costruisce ciò che hai chiesto e lo mette in sicurezza con impostazioni predefinite sicure, guidato dal charter. Il flusso Blue Team in cinque fasi verifica ciò che esiste già. ### Lagune può fare l'audit di un progetto esistente? Sì. Il flusso Blue Team in cinque fasi verifica ciò che esiste già: charter stabilisce le tue regole di sicurezza, detect mappa cosa fa il sistema e dove sono i rischi, plan assegna un punteggio a ogni rilievo e lo abbina a una correzione, harden applica le correzioni e verify dimostra che reggono e le chiude. ### Qual è la differenza tra usare Lagune e chiedere semplicemente all'agente di mappare vulnerabilità e falle di sicurezza? Un agente che legge da solo trova ciò che sembra una vulnerabilità e salta ciò che sembra un controllo. Un elenco di indirizzi bloccati dà l'impressione che qualcuno abbia già gestito il rischio, così nessuno verifica che ne manchi la maggior parte, e il codice va in produzione. Lagune ribalta questa impostazione: una protezione già presente nel codice è considerata non dimostrata finché non viene verificata, ogni specializzazione del catalogo riceve un verdetto esplicito e verify chiede se il rischio è sparito, non se c'è un controllo. Ogni rilievo resta inoltre un unico elemento tracciato da un'esecuzione all'altra, così può essere dimostrato chiuso e archiviato, mentre una semplice richiesta ti dà ogni volta un report diverso, senza nulla da confrontare. ### Qual è la differenza tra sviluppare con Lagune e chiedere semplicemente all'agente di scrivere codice sicuro? Chiedere codice sicuro lascia all'agente la definizione di sicuro, e presuppone che tu sappia cosa chiedere. Il requisito di solito è già dentro la tua richiesta senza che nessuno dei due lo veda: chiedere una pagina che mostri i corsi a cui un utente ha accesso enuncia una regola di autorizzazione, e un controllo mai scritto non lascia nulla nel codice da notare. Il comando /lagune carica il tuo charter e le specializzazioni che corrispondono a ciò che sta per essere costruito prima che venga scritta la prima riga, poi rilegge il risultato confrontandolo con la difesa che ha usato. La forma sicura raramente costa più di quella non sicura, quindi a decidere l'esito è sapere quale scegliere, ed è proprio questo che arriva in anticipo. ### Lagune esegue DAST (Dynamic Application Security Testing) o testa la mia applicazione in esecuzione? No. Lagune legge il codice e non esegue mai il tuo sistema né gli invia richieste costruite ad arte. Verify conferma che un controllo è presente e corretto nel sorgente, che è una domanda diversa dal chiedersi se resiste a un attacco su un bersaglio in esecuzione, quindi "non si può stabilire dal codice" è un verdetto legittimo invece di un via libera silenzioso. Il DAST risponde alla domanda sul runtime e Lagune a quella sul sorgente, quindi nessuno dei due sostituisce l'altro. Anche il comando facoltativo prove tiene questa linea: i suoi test verificano il comportamento sicuro, mai un payload di attacco. ### Lagune sostituisce un pentest (penetration test)? No, assolutamente! Un pentest è un incarico autorizzato in cui un professionista esercita il proprio giudizio sul tuo sistema in esecuzione, concatenando i rilievi e sondando la logica di business che nessuna regola per singola superficie descrive. I rilievi di un pentest possono entrare nel flusso Blue Team di Lagune, nella fase detect, così ciò che un professionista segnala viene pianificato, messo in sicurezza e verificato. ## Politica di sicurezza Consulta il file [SECURITY.md](https://github.com/wellwelwel/lagune/blob/main/SECURITY.md). ## Licenza **Lagune** è distribuito con la [Apache License 2.0](https://github.com/wellwelwel/lagune/blob/main/LICENSE). Copyright © 2026-oggi [Weslley Araújo](https://github.com/wellwelwel) e [collaboratori](https://github.com/wellwelwel/lagune/graphs/contributors). --- # Installa Lagune su Antigravity CLI come plugin > Installa Lagune su Antigravity CLI come plugin, tienilo aggiornato e consenti il suo motore in anticipo. Canonico: https://lagune.ai/it-IT/docs/install/antigravity-cli Lingua: it-IT Originale: https://lagune.ai/docs/install/antigravity-cli Ultimo aggiornamento: 2026-11-03 Installa il plugin dal terminale: ```bash agy plugin install https://github.com/wellwelwel/lagune/tree/plugin-antigravity ``` ## Aggiornamento Per aggiornare **Lagune**, installalo di nuovo: ```bash agy plugin install https://github.com/wellwelwel/lagune/tree/plugin-antigravity ``` ## Comandi Digita i comandi con il nome del plugin, come `/lagune:lagune-charter` per `/lagune-charter`. --- **Permessi** Il motore funziona tramite due strumenti: `lagune_read` legge soltanto il tuo progetto e `lagune_write` scrive soltanto in `.lagune/`. Un comando inviato come primo messaggio di una sessione viene eseguito prima che si carichino, quindi usa **npx** al loro posto. Per consentire in anticipo gli strumenti e **npx**, aggiungi queste regole a `~/.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.]+)" ] } } ``` ## Domande frequenti ### Come installo Lagune su Antigravity CLI? Esegui agy plugin install https://github.com/wellwelwel/lagune/tree/plugin-antigravity. ### Come aggiorno Lagune su Antigravity CLI? Esegui di nuovo agy plugin install https://github.com/wellwelwel/lagune/tree/plugin-antigravity. ### Come eseguo i comandi di Lagune su Antigravity CLI? Digitali con il nome del plugin, come /lagune:lagune-charter. ### Antigravity CLI può eseguire Lagune senza chiedere il permesso? Sì. Consenti mcp(lagune_lagune/lagune_read), mcp(lagune_lagune/lagune_write) e command(regex:npx --yes lagune@[0-9.]+) nelle impostazioni di Antigravity CLI. La regola per npx copre un comando inviato come primo messaggio di una sessione. --- # Installa Lagune su Claude Code come plugin > Installa Lagune su Claude Code come plugin, nel terminale, nell'estensione o nell'app desktop, tienilo aggiornato e consenti il suo motore in anticipo. Canonico: https://lagune.ai/it-IT/docs/install/claude-code Lingua: it-IT Originale: https://lagune.ai/docs/install/claude-code Ultimo aggiornamento: 2026-11-03 **Terminale** Installa il plugin dal terminale: ```bash claude plugin install lagune --marketplace wellwelwel/lagune ``` Oppure da una sessione di **Claude Code**: ```text /plugin marketplace add wellwelwel/lagune /plugin install lagune@lagune ``` **Estensione** - Digita `/plugin` e seleziona **Manage plugins**. - Aggiungi `wellwelwel/lagune` nella scheda **Marketplaces**. - Installa `lagune` nella scheda **Plugins**. **Desktop** - Installa **Lagune** dal terminale o dall'estensione, scegliendo **Install for you** nell'estensione. - Avvia una nuova sessione nell'app desktop, che carica i plugin che installi per te. ## Aggiornamento **Terminale** Per aggiornare **Lagune**, esegui: ```bash claude plugin marketplace update lagune claude plugin update lagune@lagune ``` Per tenerlo aggiornato, seleziona **Enable auto-update** per il marketplace `lagune` in `/plugin`. **Estensione** - Digita `/plugin` e seleziona **Manage plugins**. - Apri la scheda **Marketplaces**. - Seleziona l'icona di aggiornamento su `lagune`. **Desktop** - Aggiorna **Lagune** dal terminale o dall'estensione. - Avvia una nuova sessione nell'app desktop. ## Comandi Digita i comandi per nome, come `/lagune-charter`, oppure con il nome del plugin, come `/lagune:lagune-charter`. --- **Permessi** Il motore funziona tramite due strumenti: `lagune_read` legge soltanto il tuo progetto e `lagune_write` scrive soltanto in `.lagune/`. Per consentirli in anticipo, aggiungi queste regole a `.claude/settings.json` per un singolo progetto, oppure a `~/.claude/settings.json` per tutti: ```json { "permissions": { "allow": [ "mcp__plugin_lagune_lagune__lagune_read", "mcp__plugin_lagune_lagune__lagune_write" ] } } ``` Quando il motore viene eseguito tramite **npx**, come con **skills.sh**, consenti `Bash(npx --yes lagune@*)`. Con la sandbox attiva, aggiungi anche `registry.npmjs.org` a `sandbox.network.allowedDomains`. ## Domande frequenti ### Come installo Lagune su Claude Code? Esegui claude plugin install lagune --marketplace wellwelwel/lagune. In una sessione o nell'estensione, aggiungi il marketplace wellwelwel/lagune dal gestore dei plugin e installa lagune. L'app desktop lo carica una volta che l'hai installato per te nel terminale o nell'estensione. ### Come aggiorno Lagune su Claude Code? Esegui claude plugin marketplace update lagune, poi claude plugin update lagune@lagune, oppure seleziona Enable auto-update per il marketplace lagune in /plugin. Nell'estensione, apri Manage plugins da /plugin e seleziona l'icona di aggiornamento sul marketplace lagune. L'app desktop carica l'aggiornamento nella sessione successiva. ### Come eseguo i comandi di Lagune su Claude Code? Digitali per nome, come /lagune-charter, oppure con il nome del plugin, come /lagune:lagune-charter. ### Claude Code può eseguire Lagune senza chiedere il permesso? Sì. Consenti mcp__plugin_lagune_lagune__lagune_read e mcp__plugin_lagune_lagune__lagune_write nelle impostazioni di Claude Code, più Bash(npx --yes lagune@*) quando il motore viene eseguito tramite npx. --- # Installa Lagune su Codex CLI come plugin > Installa Lagune su Codex CLI come plugin, tienilo aggiornato ed esegui il suo motore dentro la sandbox. Canonico: https://lagune.ai/it-IT/docs/install/codex Lingua: it-IT Originale: https://lagune.ai/docs/install/codex Ultimo aggiornamento: 2026-11-03 Installa il plugin dal terminale: ```bash codex plugin marketplace add wellwelwel/lagune codex plugin add lagune@lagune ``` ## Aggiornamento Per aggiornare **Lagune**, esegui: ```bash codex plugin marketplace upgrade lagune ``` ## Comandi Digita `$` e il comando con il nome del plugin, seguito dal tuo input, come `$lagune:lagune-charter` per `/lagune-charter`. Digitando `$` vengono elencati i comandi, e sceglierne uno ne inserisce il nome completo. --- **Permessi** La sandbox di **Codex** non ha accesso alla rete. Installa il motore nel tuo progetto dal tuo terminale, una volta e dopo ogni aggiornamento: ```bash npm i -D lagune@0.16.0 ``` ## Domande frequenti ### Come installo Lagune su Codex CLI? Esegui codex plugin marketplace add wellwelwel/lagune, poi codex plugin add lagune@lagune. ### Come aggiorno Lagune su Codex CLI? Esegui codex plugin marketplace upgrade lagune. ### Come eseguo i comandi di Lagune su Codex CLI? Digita $ e il comando con il nome del plugin, seguito dal tuo input, come $lagune:lagune-charter. ### Lagune funziona dentro la sandbox di Codex? Sì, una volta installato il motore nel tuo progetto con npm i -D lagune@0.16.0 dal tuo terminale, una volta e dopo ogni aggiornamento. --- # Installa Lagune su Cursor come plugin > Installa Lagune su Cursor e sulla Cursor CLI come plugin, tienilo aggiornato e consenti il suo motore in anticipo. Canonico: https://lagune.ai/it-IT/docs/install/cursor Lingua: it-IT Originale: https://lagune.ai/docs/install/cursor Ultimo aggiornamento: 2026-11-03 **Cursor** - Apri **Customize**. - Seleziona **From GitHub Repository** e inserisci `https://github.com/wellwelwel/lagune`. - Seleziona **Install** su **Lagune** e scegli l'ambito di progetto o di utente. **Cursor CLI** - Aggiungi il marketplace dal terminale: ```bash agent plugin marketplace add https://github.com/wellwelwel/lagune --git-ref plugin-cursor ``` - Digita `/plugins` in una sessione di `agent`. - Installa **Lagune**. Se **Lagune** è già installato in **Claude Code**, la **Cursor CLI** lo carica da lì. ## Aggiornamento **Cursor** - Apri **Customize**. - Seleziona **Refresh** sul marketplace `lagune`. **Cursor CLI** - Sostituisci il marketplace dal terminale: ```bash agent plugin marketplace remove lagune agent plugin marketplace add https://github.com/wellwelwel/lagune --git-ref plugin-cursor ``` - Digita `/plugins` in una sessione di `agent`. - Installa di nuovo **Lagune**. ## Comandi Digita i comandi per nome, come `/lagune-charter`. --- **Permessi** In **Cursor**, i comandi eseguono il motore tramite **npx**, che la modalità Auto-review predefinita consente senza chiedere. Nella **Cursor CLI**, il motore funziona tramite due strumenti: `lagune_read` legge soltanto il tuo progetto e `lagune_write` scrive soltanto in `.lagune/`. Per consentirli in anticipo, aggiungi queste regole a `.cursor/cli.json` per un singolo progetto, oppure a `~/.cursor/cli-config.json` per tutti: ```json { "permissions": { "allow": [ "Mcp(plugin-lagune-lagune:lagune_read)", "Mcp(plugin-lagune-lagune:lagune_write)" ] } } ``` Quando il motore viene eseguito tramite **npx**, come con **skills.sh**, consenti `Shell(npx:--yes lagune@*)`. ## Domande frequenti ### Come installo Lagune su Cursor? In Cursor, apri Customize, seleziona From GitHub Repository, inserisci https://github.com/wellwelwel/lagune e installa Lagune. Nella Cursor CLI, esegui agent plugin marketplace add https://github.com/wellwelwel/lagune --git-ref plugin-cursor, poi installa Lagune da /plugins. ### Come aggiorno Lagune su Cursor? In Cursor, seleziona Refresh sul marketplace lagune in Customize. Nella Cursor CLI, rimuovi il marketplace lagune, aggiungilo di nuovo, poi installa di nuovo Lagune da /plugins. ### Come eseguo i comandi di Lagune su Cursor? Digitali per nome, come /lagune-charter. ### Cursor può eseguire Lagune senza chiedere il permesso? Sì. La modalità Auto-review predefinita di Cursor lo consente già. Nella Cursor CLI, consenti Mcp(plugin-lagune-lagune:lagune_read) e Mcp(plugin-lagune-lagune:lagune_write), più Shell(npx:--yes lagune@*) quando il motore viene eseguito tramite npx. --- # Installa Lagune su Devin CLI come plugin > Installa Lagune su Devin CLI come plugin e tienilo aggiornato. Canonico: https://lagune.ai/it-IT/docs/install/devin-cli Lingua: it-IT Originale: https://lagune.ai/docs/install/devin-cli Ultimo aggiornamento: 2026-11-03 Accedi a **Devin**, poi installa il plugin dal terminale: ```bash devin auth login devin plugins install wellwelwel/lagune ``` ## Aggiornamento Per aggiornare **Lagune**, esegui: ```bash devin plugins update lagune ``` ## Comandi Digita i comandi con il nome del plugin, come `/lagune:lagune-charter` per `/lagune-charter`. Li elenca anche il menu `/`. ## Domande frequenti ### Come installo Lagune su Devin CLI? Accedi con devin auth login, poi esegui devin plugins install wellwelwel/lagune. ### Come aggiorno Lagune su Devin CLI? Esegui devin plugins update lagune. ### Come eseguo i comandi di Lagune su Devin CLI? Digitali con il nome del plugin, come /lagune:lagune-charter. Li elenca anche il menu /. --- # Installa Lagune su Factory Droid come plugin > Installa Lagune su Factory Droid come plugin, tienilo aggiornato e consenti gli strumenti del suo motore. Canonico: https://lagune.ai/it-IT/docs/install/factory-droid Lingua: it-IT Originale: https://lagune.ai/docs/install/factory-droid Ultimo aggiornamento: 2026-11-03 Installa il plugin dal terminale: ```bash droid plugin marketplace add wellwelwel/lagune droid plugin install lagune@lagune ``` ## Aggiornamento Per aggiornare **Lagune**, esegui: ```bash droid plugin marketplace update lagune droid plugin update lagune@lagune ``` ## Comandi Digita i comandi per nome, come `/lagune-charter`. --- **Permessi** Il motore funziona tramite due strumenti: `lagune_read` legge soltanto il tuo progetto e `lagune_write` scrive soltanto in `.lagune/`. Quando **Factory Droid** lo chiede, scegli di consentire sempre ciascuno dei due. Lo chiede di nuovo dopo aver sincronizzato un nuovo commit del marketplace `lagune`, cosa che può fare all'avvio. ## Domande frequenti ### Come installo Lagune su Factory Droid? Esegui droid plugin marketplace add wellwelwel/lagune, poi droid plugin install lagune@lagune. ### Come aggiorno Lagune su Factory Droid? Esegui droid plugin marketplace update lagune, poi droid plugin update lagune@lagune. ### Come eseguo i comandi di Lagune su Factory Droid? Digitali per nome, come /lagune-charter. ### Factory Droid può eseguire Lagune senza chiedere il permesso? Sì. Scegli di consentire sempre lagune_read e lagune_write quando Factory Droid lo chiede. Lo chiede di nuovo dopo aver sincronizzato un nuovo commit del marketplace lagune. --- # Installa Lagune su Gemini CLI come estensione > Installa Lagune su Gemini CLI come estensione, tienilo aggiornato e consenti il suo motore in anticipo. Canonico: https://lagune.ai/it-IT/docs/install/gemini-cli Lingua: it-IT Originale: https://lagune.ai/docs/install/gemini-cli Ultimo aggiornamento: 2026-11-03 Installa l'estensione dal terminale: ```bash gemini extensions install https://github.com/wellwelwel/lagune ``` ## Aggiornamento Per aggiornare **Lagune**, esegui: ```bash gemini extensions update lagune ``` Per tenerlo aggiornato, installalo con `--auto-update`. ## Comandi Digita i comandi con il nome dell'estensione, come `/lagune:lagune-charter` per `/lagune-charter`. --- **Permessi** Il motore funziona tramite due strumenti: `lagune_read` legge soltanto il tuo progetto e `lagune_write` scrive soltanto in `.lagune/`. **Gemini CLI** li avvia solo in una cartella attendibile. Per consentirli in anticipo, salva questa regola come `~/.gemini/policies/lagune.toml`: ```toml [[rule]] mcpName = "lagune" toolName = ["lagune_read", "lagune_write"] decision = "allow" priority = 100 ``` Quando il motore viene eseguito tramite **npx**, come con **skills.sh**, aggiungi questa regola allo stesso file: ```toml [[rule]] toolName = "run_shell_command" commandRegex = 'npx --yes lagune@\d+\.\d+\.\d+\s' decision = "allow" priority = 100 ``` ## Domande frequenti ### Come installo Lagune su Gemini CLI? Esegui gemini extensions install https://github.com/wellwelwel/lagune. ### Come aggiorno Lagune su Gemini CLI? Esegui gemini extensions update lagune, oppure installa l'estensione con --auto-update. ### Come eseguo i comandi di Lagune su Gemini CLI? Digitali con il nome dell'estensione, come /lagune:lagune-charter. ### Gemini CLI può eseguire Lagune senza chiedere il permesso? Sì. Aggiungi una regola di policy che consenta gli strumenti lagune_read e lagune_write del server lagune, più una per run_shell_command con npx --yes lagune@ e una versione quando il motore viene eseguito tramite npx. --- # Installa Lagune su GitHub Copilot CLI come plugin > Installa Lagune su GitHub Copilot CLI come plugin e tienilo aggiornato. Canonico: https://lagune.ai/it-IT/docs/install/github-copilot-cli Lingua: it-IT Originale: https://lagune.ai/docs/install/github-copilot-cli Ultimo aggiornamento: 2026-11-03 Installa il plugin dal terminale: ```bash copilot plugin marketplace add wellwelwel/lagune copilot plugin install lagune@lagune ``` In un editor, installa **Lagune** per **GitHub Copilot** con [**skills.sh**](https://lagune.ai/it-IT/docs/install/universal). ## Aggiornamento Per aggiornare **Lagune**, esegui: ```bash copilot plugin marketplace update lagune copilot plugin update lagune@lagune ``` ## Comandi Digita i comandi per nome, come `/lagune-charter`. ## Domande frequenti ### Come installo Lagune su GitHub Copilot CLI? Esegui copilot plugin marketplace add wellwelwel/lagune, poi copilot plugin install lagune@lagune. ### Come aggiorno Lagune su GitHub Copilot CLI? Esegui copilot plugin marketplace update lagune, poi copilot plugin update lagune@lagune. ### Come eseguo i comandi di Lagune su GitHub Copilot CLI? Digitali per nome, come /lagune-charter. ### Posso usare Lagune con GitHub Copilot in VS Code? Sì. In VS Code o in un altro editor, installa Lagune con skills.sh invece che con il plugin. --- # Installa Lagune su Grok Build come plugin > Installa Lagune su Grok Build come plugin, tienilo aggiornato e consenti il suo motore in anticipo. Canonico: https://lagune.ai/it-IT/docs/install/grok-build Lingua: it-IT Originale: https://lagune.ai/docs/install/grok-build Ultimo aggiornamento: 2026-11-03 Installa il plugin dal terminale: ```bash grok plugin install wellwelwel/lagune@plugin-grok --trust ``` ## Aggiornamento Per aggiornare **Lagune**, esegui: ```bash grok plugin update lagune ``` ## Comandi Digita i comandi per nome, come `/lagune-charter`, oppure con il nome del plugin, come `/lagune:lagune-charter`. --- **Permessi** Il motore funziona tramite due strumenti: `lagune_read` legge soltanto il tuo progetto e `lagune_write` scrive soltanto in `.lagune/`. Per consentirli in anticipo, aggiungi queste regole a `~/.grok/config.toml`: ```toml [permission] allow = ["MCPTool(lagune__lagune_read)", "MCPTool(lagune__lagune_write)"] ``` Quando il motore viene eseguito tramite **npx**, come con **skills.sh**, consenti `Bash(npx --yes lagune@*)`. ## Domande frequenti ### Come installo Lagune su Grok Build? Esegui grok plugin install wellwelwel/lagune@plugin-grok --trust. ### Come aggiorno Lagune su Grok Build? Esegui grok plugin update lagune. ### Come eseguo i comandi di Lagune su Grok Build? Digitali per nome, come /lagune-charter, oppure con il nome del plugin, come /lagune:lagune-charter. ### Grok Build può eseguire Lagune senza chiedere il permesso? Sì. Consenti MCPTool(lagune__lagune_read) e MCPTool(lagune__lagune_write) nella configurazione di Grok Build, più Bash(npx --yes lagune@*) quando il motore viene eseguito tramite npx. --- # Installa Lagune su Hermes Agent come plugin > Installa Lagune su Hermes Agent come plugin e tienilo aggiornato. Canonico: https://lagune.ai/it-IT/docs/install/hermes-agent Lingua: it-IT Originale: https://lagune.ai/docs/install/hermes-agent Ultimo aggiornamento: 2026-11-03 Installa il plugin dal terminale: ```bash hermes plugins install wellwelwel/lagune --enable ``` - Quando **Hermes Agent** ti chiede di confermare un plugin esterno al suo catalogo, **confermalo**. - Quando propone di installare le dipendenze **Node.js** del repository, **rifiuta**. ## Aggiornamento Per aggiornare **Lagune**, esegui: ```bash hermes plugins update lagune ``` ## Comandi Digita i comandi con il nome del plugin, come `/lagune:lagune-charter` per `/lagune-charter` e `/lagune:lagune` per `/lagune`. ## Domande frequenti ### Come installo Lagune su Hermes Agent? Esegui hermes plugins install wellwelwel/lagune --enable. Conferma il plugin quando richiesto e rifiuta l'installazione delle dipendenze Node.js del repository. ### Come aggiorno Lagune su Hermes Agent? Esegui hermes plugins update lagune. ### Come eseguo i comandi di Lagune su Hermes Agent? Digitali con il nome del plugin, come /lagune:lagune-charter e /lagune:lagune. --- # Installa Lagune su Kimi Code come plugin > Installa Lagune su Kimi Code come plugin e tienilo aggiornato. Canonico: https://lagune.ai/it-IT/docs/install/kimi-code Lingua: it-IT Originale: https://lagune.ai/docs/install/kimi-code Ultimo aggiornamento: 2026-11-03 Installa il plugin da una sessione di **Kimi Code**, scegli **Trust and install**, poi avvia una nuova sessione per caricarlo: ```text /plugins install https://github.com/wellwelwel/lagune /new ``` ## Aggiornamento Per aggiornare **Lagune**, installalo di nuovo: ```text /plugins install https://github.com/wellwelwel/lagune /new ``` ## Comandi Digita i comandi con il nome del plugin, come `/lagune:lagune-charter` per `/lagune-charter`. Il menu `/` li elenca come `/skill:lagune:lagune-charter`, e funziona anche così. ## Domande frequenti ### Come installo Lagune su Kimi Code? In una sessione di Kimi Code, esegui /plugins install https://github.com/wellwelwel/lagune, scegli Trust and install, poi esegui /new. ### Come aggiorno Lagune su Kimi Code? Esegui di nuovo /plugins install https://github.com/wellwelwel/lagune, poi /new. ### Come eseguo i comandi di Lagune su Kimi Code? Digitali con il nome del plugin, come /lagune:lagune-charter, oppure come li elenca il menu /, come /skill:lagune:lagune-charter. --- # Installa Lagune su Muse Code come plugin > Installa Lagune su Muse Code come plugin, tienilo aggiornato ed esegui il suo motore dentro la sandbox. Canonico: https://lagune.ai/it-IT/docs/install/muse-code Lingua: it-IT Originale: https://lagune.ai/docs/install/muse-code Ultimo aggiornamento: 2026-11-03 Installa il plugin dal terminale: ```bash muse plugins marketplace add lagune wellwelwel/lagune muse plugins install lagune@lagune ``` ## Aggiornamento Per aggiornare **Lagune**, aggiorna il marketplace e reinstalla il plugin: ```bash muse plugins marketplace update lagune muse plugins remove lagune muse plugins install lagune@lagune ``` ## Comandi Digita i comandi per nome, come `/lagune-charter`, oppure con il nome del plugin, come `/lagune:lagune-charter`. --- **Permessi** La sandbox di **Muse Code** non può scaricare il motore. Installalo nel tuo progetto dal tuo terminale, una volta e dopo ogni aggiornamento: ```bash npm i -D lagune@0.16.0 ``` ## Domande frequenti ### Come installo Lagune su Muse Code? Esegui muse plugins marketplace add lagune wellwelwel/lagune, poi muse plugins install lagune@lagune. ### Come aggiorno Lagune su Muse Code? Esegui muse plugins marketplace update lagune, poi reinstalla con muse plugins remove lagune e muse plugins install lagune@lagune. ### Come eseguo i comandi di Lagune su Muse Code? Digitali per nome, come /lagune-charter, oppure con il nome del plugin, come /lagune:lagune-charter. ### Lagune funziona dentro la sandbox di Muse Code? Sì, una volta installato il motore nel tuo progetto con npm i -D lagune@0.16.0 dal tuo terminale, una volta e dopo ogni aggiornamento. --- # Installa Lagune su OpenCode come plugin > Installa Lagune su OpenCode 1.x e 2.x come plugin e tienilo aggiornato. Canonico: https://lagune.ai/it-IT/docs/install/opencode Lingua: it-IT Originale: https://lagune.ai/docs/install/opencode Ultimo aggiornamento: 2026-11-03 **OpenCode 2.x** Installa il plugin dal terminale: ```bash opencode plugin add lagune ``` Oppure aggiungilo all'elenco `plugins` di `opencode.json`: ```json { "plugins": ["lagune"] } ``` **OpenCode 1.x** Installa il plugin nel tuo progetto dal terminale, oppure aggiungi `-g` per installarlo per tutti i tuoi progetti: ```bash opencode plugin lagune ``` Oppure aggiungilo all'elenco `plugin` di `opencode.json`: ```json { "plugin": ["lagune"] } ``` ## Aggiornamento **OpenCode 2.x** Per aggiornare **Lagune**, esegui: ```bash opencode plugin update lagune opencode reload ``` **OpenCode 1.x** Per aggiornare **Lagune**, installa la nuova release sopra quella vecchia, aggiungendo `-g` se l'hai installato per tutti i tuoi progetti: ```bash opencode plugin lagune@0.16.0 --force ``` ## Comandi **OpenCode 2.x** Digita `@` e scegli il comando, come `@lagune-charter`, poi scrivi il tuo input nello stesso messaggio. **OpenCode 1.x** Digita i comandi per nome, come `/lagune-charter`. Sono elencati sotto `/skills`, non nel menu `/`. --- **Permessi** Il motore funziona tramite due strumenti: `lagune_read` legge soltanto il tuo progetto e `lagune_write` scrive soltanto in `.lagune/`. **OpenCode** li esegue senza chiedere. ## Domande frequenti ### Come installo Lagune su OpenCode? Su OpenCode 2.x, esegui opencode plugin add lagune. Su OpenCode 1.x, esegui opencode plugin lagune, aggiungendo -g per installarlo per tutti i tuoi progetti. ### Come aggiorno Lagune su OpenCode? Su OpenCode 2.x, esegui opencode plugin update lagune, poi opencode reload. Su OpenCode 1.x, esegui opencode plugin lagune@0.16.0 --force. ### Come eseguo i comandi di Lagune su OpenCode? Su OpenCode 2.x, digita @ e scegli il comando, come @lagune-charter, poi scrivi il tuo input nello stesso messaggio. Su OpenCode 1.x, digitali per nome, come /lagune-charter, oppure trovali sotto /skills. ### OpenCode chiede il permesso prima di eseguire Lagune? No. OpenCode esegue i due strumenti del motore, lagune_read e lagune_write, senza chiedere. --- # Installa Lagune su Pi come pacchetto > Installa Lagune su Pi come pacchetto, da npm o da GitHub, e tienilo aggiornato. Canonico: https://lagune.ai/it-IT/docs/install/pi Lingua: it-IT Originale: https://lagune.ai/docs/install/pi Ultimo aggiornamento: 2026-11-03 **npm** Installa il pacchetto dal terminale: ```bash pi install npm:lagune ``` **GitHub** Installa l'ultimo commit da **GitHub**, che esegue il motore tramite **npx**: ```bash pi install git:github.com/wellwelwel/lagune ``` ## Aggiornamento **npm** Per aggiornare **Lagune**, esegui: ```bash pi update npm:lagune ``` **GitHub** Per aggiornare **Lagune**, esegui: ```bash pi update git:github.com/wellwelwel/lagune ``` `pi update --extensions` aggiorna tutti i pacchetti che hai installato, mentre `pi update` da solo aggiorna soltanto **Pi**. ## Comandi Digita i comandi con il prefisso `skill:`, come `/skill:lagune-charter` per `/lagune-charter`. ## Domande frequenti ### Come installo Lagune su Pi? Esegui pi install npm:lagune, oppure pi install git:github.com/wellwelwel/lagune per l'ultimo commit da GitHub. ### Come aggiorno Lagune su Pi? Esegui pi update npm:lagune, oppure pi update git:github.com/wellwelwel/lagune per un'installazione da GitHub. pi update --extensions aggiorna tutti i pacchetti che hai installato. ### Come eseguo i comandi di Lagune su Pi? Digitali con il prefisso skill:, come /skill:lagune-charter. --- # Installa Lagune su Qwen Code come estensione > Installa Lagune su Qwen Code come estensione, tienilo aggiornato e consenti il suo motore in anticipo. Canonico: https://lagune.ai/it-IT/docs/install/qwen-code Lingua: it-IT Originale: https://lagune.ai/docs/install/qwen-code Ultimo aggiornamento: 2026-11-03 Installa l'estensione dal terminale: ```bash qwen extensions install lagune ``` ## Aggiornamento Per aggiornare **Lagune**, esegui: ```bash qwen extensions update lagune ``` Per tenerlo aggiornato, installalo con `--auto-update`. ## Comandi Digita i comandi con il nome dell'estensione, come `/lagune:lagune-charter` per `/lagune-charter`. --- **Permessi** Il motore funziona tramite due strumenti: `lagune_read` legge soltanto il tuo progetto e `lagune_write` scrive soltanto in `.lagune/`. Per consentirli in anticipo, aggiungi queste regole a `.qwen/settings.json` per un singolo progetto, oppure a `~/.qwen/settings.json` per tutti: ```json { "permissions": { "allow": ["mcp__lagune__lagune_read", "mcp__lagune__lagune_write"] } } ``` Quando il motore viene eseguito tramite **npx**, come con **skills.sh**, consenti `Shell(npx --yes lagune@*)`. ## Domande frequenti ### Come installo Lagune su Qwen Code? Esegui qwen extensions install lagune. ### Come aggiorno Lagune su Qwen Code? Esegui qwen extensions update lagune, oppure installa l'estensione con --auto-update. ### Come eseguo i comandi di Lagune su Qwen Code? Digitali con il nome dell'estensione, come /lagune:lagune-charter. ### Qwen Code può eseguire Lagune senza chiedere il permesso? Sì. Consenti mcp__lagune__lagune_read e mcp__lagune__lagune_write nelle impostazioni di Qwen Code, più Shell(npx --yes lagune@*) quando il motore viene eseguito tramite npx. --- # Installa Lagune in qualsiasi agente con skills.sh > Installa Lagune in qualsiasi agente IA con la CLI di skills e tienilo aggiornato. Canonico: https://lagune.ai/it-IT/docs/install/universal Lingua: it-IT Originale: https://lagune.ai/docs/install/universal Ultimo aggiornamento: 2026-11-03 **Terminale** Installa i comandi di **Lagune** dal terminale con [**skills.sh**](https://www.skills.sh/wellwelwel/lagune): ```bash npx skills add wellwelwel/lagune ``` **Prompt** Incolla questo prompt nel tuo agente: ```md Esegui `npx --yes skills add wellwelwel/lagune` e segui subito le istruzioni della skill generate. Leggi il suo output completo, reindirizzandolo prima a un file temporaneo se necessario. Risolvi i percorsi relativi partendo dalla directory dei file di supporto che indica. ``` ## Aggiornamento **Terminale** Per aggiornare **Lagune**, esegui: ```bash npx skills update ``` **Prompt** Per aggiornare **Lagune**, incolla questo prompt nel tuo agente: ```md Esegui `npx --yes skills update -y` e leggi il suo output completo, reindirizzandolo prima a un file temporaneo se necessario. ``` --- **Una sola via per agente** Installa **Lagune** tramite **skills.sh** o tramite il suo **plugin**, mai entrambi. **Permessi** I comandi eseguono il motore come `npx --yes lagune@0.16.0`, e la [pagina di installazione di ogni agente](https://lagune.ai/it-IT/docs) mostra la regola che lo consente in anticipo. In una sandbox senza accesso alla rete, installa il motore nel tuo progetto dal tuo terminale, una volta e dopo ogni aggiornamento: ```bash npm i -D lagune@0.16.0 ``` ## Domande frequenti ### Come installo Lagune in qualsiasi agente IA? Esegui npx skills add wellwelwel/lagune nel tuo progetto, oppure incolla il prompt di installazione nel tuo agente. ### Come aggiorno Lagune installato con la CLI di skills? Esegui npx skills update, oppure incolla il prompt di aggiornamento nel tuo agente. ### Posso installare Lagune sia con la CLI di skills sia con un plugin? No. Con entrambi, l'agente elenca ogni comando due volte, oppure usa una copia e nasconde l'altra. --- # Skill di sicurezza per agenti IA > Le skill che il tuo agente IA sblocca con Lagune: fai l'audit di un progetto esistente o proteggi il nuovo lavoro mentre sviluppi, sempre sotto il governo del charter. Canonico: https://lagune.ai/it-IT/docs/get-started/commands Lingua: it-IT Originale: https://lagune.ai/docs/get-started/commands Ultimo aggiornamento: 2026-11-03 Una volta [installato](https://lagune.ai/it-IT/docs) **Lagune**, il tuo agente **IA** sblocca una serie di skill. Ci sono due modi di usarle, ed entrambi sono governati dal **charter**: proteggere il nuovo lavoro mentre lo costruisci, oppure eseguire l'audit completo su un progetto. **⌨️ Costruzione e sviluppo** Non devi finire il tuo lavoro prima di metterlo in sicurezza. Usa [**`/lagune`**](https://lagune.ai/it-IT/docs/commands/lagune) per il lavoro che stai scrivendo **in questo momento**: | Skill | Cosa fa per te | | --------------------------------------------- | ------------------------------------------------------------------------------------------- | | [**/lagune-charter**](https://lagune.ai/it-IT/docs/commands/charter) | Definisce le regole di sicurezza del tuo progetto, la base su cui `/lagune` costruisce | | [**/lagune**](https://lagune.ai/it-IT/docs/commands/lagune) | Costruisce ciò che chiedi e lo mette in sicurezza mentre viene scritto, guidato dal charter | **Usalo quando vuoi** [**`/lagune`**](https://lagune.ai/it-IT/docs/commands/lagune) rispetta le regole del tuo charter ogni volta che viene eseguito. Accetta qualsiasi prompt, costruisce ciò che hai chiesto e lo mette in sicurezza con impostazioni predefinite sicure strada facendo, non dopo. --- #### Skill speciali | Skill | Cosa fa | | --------------------------------------------------- | ---------------------------------------------------------------------------------------- | | [**/lagune-specialize**](https://lagune.ai/it-IT/docs/commands/specialize) | Insegna a **Lagune** una nuova specializzazione di sicurezza da articoli, exploit o temi | **🔬 Audit: flusso Blue Team** Il **flusso Blue Team** completo: leggere cosa fa un progetto, mapparne i rischi e chiuderli. Ogni fase si basa sulla precedente, quindi basta seguire l'elenco dall'alto verso il basso: | # | Skill | Cosa fa per te | | --- | --------------------------------------------- | ---------------------------------------------------------------------------------------------- | | 1 | [**/lagune-charter**](https://lagune.ai/it-IT/docs/commands/charter) | Definisce le regole di sicurezza del tuo progetto, proposte per te o modellate su ciò che dici | | 2 | [**/lagune-detect**](https://lagune.ai/it-IT/docs/commands/detect) | Legge il tuo codice e mappa cosa fa il sistema e dove sono i rischi | | 3 | [**/lagune-plan**](https://lagune.ai/it-IT/docs/commands/plan) | Trasforma ciò che detect ha trovato in un piano di difesa, con una correzione per ogni rilievo | | 4 | [**/lagune-harden**](https://lagune.ai/it-IT/docs/commands/harden) | Applica al tuo codice le correzioni del piano, in sicurezza e una alla volta | | 5 | [**/lagune-verify**](https://lagune.ai/it-IT/docs/commands/verify) | Dimostra che ogni correzione applicata regge e chiude quelle che reggono | --- #### Skill speciali | Skill | Cosa fa | | --------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- | | [**/lagune-specialize**](https://lagune.ai/it-IT/docs/commands/specialize) | Insegna a **Lagune** una nuova specializzazione di sicurezza da articoli, exploit o temi | | [**/lagune-prove**](https://lagune.ai/it-IT/docs/commands/prove) | Trasforma ogni rilievo individuato in una prova eseguibile ed esclusivamente difensiva per la divulgazione responsabile | --- #### Skill interne | Skill | Cosa fa | | ------------------------------------------- | -------------------------------------------- | | [**/lagune-repair**](https://lagune.ai/it-IT/docs/commands/repair) | Ripara il tracciamento interno di **Lagune** | **Suggerimento** La sicurezza non è un costo, è un investimento: ciò che metti all'inizio lo risparmi molte volte negli incidenti che non avrai mai 🙋🏻‍♂️ ## Domande frequenti ### Quali skill aggiunge Lagune? /lagune per mettere in sicurezza il lavoro mentre lo costruisci, e il flusso di audit Blue Team in cinque fasi: /lagune-charter, /lagune-detect, /lagune-plan, /lagune-harden, /lagune-verify. Più /lagune-specialize e /lagune-prove. ### Che cos'è il flusso Blue Team di Lagune? Un audit in cinque fasi: charter (definire le regole), detect (mappare i rischi), plan (assegnare un punteggio e pianificare le correzioni), harden (applicare le correzioni), verify (dimostrare che reggono e chiuderle). ### Qual è la differenza tra /lagune e il flusso di audit? /lagune protegge il nuovo lavoro mentre lo scrivi, senza alcun flusso da seguire. Il flusso di audit esegue le cinque fasi in ordine su un progetto esistente. --- # Dashboard > Guarda il charter, i rilievi e il catalogo del tuo progetto in una vista locale in tempo reale che si apre con un solo comando. Canonico: https://lagune.ai/it-IT/docs/get-started/dashboard Lingua: it-IT Originale: https://lagune.ai/docs/get-started/dashboard Ultimo aggiornamento: 2026-11-03 Esegui **Lagune** direttamente, senza sottocomando, per una vista interattiva e in tempo reale di `.lagune/`. Serve una dashboard e la apre su una porta casuale: ```bash npx lagune ``` - [x] **Live reload** - [x] **Privata** e **locale** - [x] Mostra qualunque cosa contenga `.lagune/`, a partire dal primo charter - [x] **Gestisci** le categorie del progetto direttamente dal browser - [x] Non servono `node_modules` né `package.json` 📦 ![Charter nella dashboard di Lagune](https://lagune.ai/img/dashboard/02.webp) ![Rilievi nella dashboard di Lagune](https://lagune.ai/img/dashboard/03.webp) ![Missioni secondarie nella dashboard di Lagune](https://lagune.ai/img/dashboard/04.webp) ![Dettaglio di un rilievo nella dashboard di Lagune](https://lagune.ai/img/dashboard/05.webp) ![Catalogo nella dashboard di Lagune](https://lagune.ai/img/dashboard/06.webp) **Suggerimento** - 🚪 Usa `--port` per indicare una porta personalizzata. - ⏏️ Premi `Ctrl+C` per fermarla. ## Domande frequenti ### Come apro la dashboard di Lagune? Esegui npx lagune senza sottocomando nella radice del tuo progetto. Serve una vista in tempo reale di .lagune/ su una porta casuale e la apre nel tuo browser. ### La dashboard è privata? Sì. Gira solo sulla tua macchina, a un indirizzo locale che nessun altro computer può raggiungere. ### Posso modificare il mio progetto dalla dashboard? Solo le sue categorie, dal browser. Tutto il resto che la dashboard mostra è in sola lettura. --- # /lagune: codice sicuro mentre la tua IA lo scrive > Costruisce ciò che chiedi e lo mette in sicurezza mentre viene scritto, guidato dal charter, senza alcun flusso da seguire. Canonico: https://lagune.ai/it-IT/docs/commands/lagune Lingua: it-IT Originale: https://lagune.ai/docs/commands/lagune Ultimo aggiornamento: 2026-11-03 ⌨️ Fai il lavoro che hai chiesto, protetto mentre viene scritto. **`/lagune`** accetta qualsiasi prompt in qualsiasi fase, costruisce ciò che volevi e lo mette in sicurezza con impostazioni predefinite sicure prima di restituirtelo. ## Come usarlo Aggiungi **`/lagune`** a qualsiasi prompt e descrivi il lavoro come faresti sempre. **📘 Istruzioni per l** ```md # Le istruzioni del mio progetto per gli agenti ## Sicurezza - Usa la skill `/lagune` ogni volta che costruisci o modifichi codice, così migliora la sicurezza per impostazione predefinita. ``` - Per esempio: **AGENTS.md**, **CLAUDE.md**, **.github/copilot-instructions.md**, **.cursorrules** e così via. **💬 Una funzionalità** ```prompt /lagune permetti agli utenti di caricare una foto personalizzata nel loro profilo. ``` **💬 Una correzione** ```prompt /lagune quando l'utente invia il modulo non succede nulla. Scopri quale può essere la causa e correggila. ``` **💬 Un refactoring** ```prompt /lagune disaccoppia e migliora la logica del payload ``` **Il charter è facoltativo, ma è meglio averlo** **`/lagune`** funziona con o senza charter. Se c'è, le regole del tuo progetto plasmano ogni costruzione. Definiscile una volta con [`/lagune-charter`](https://lagune.ai/it-IT/docs/commands/charter). ## Come funziona Avvolge il lavoro in tre movimenti, senza scrivere nulla in Lagune: 1. Carica il tuo charter, se esiste, e i suoi principi governano l'intera costruzione, ripiegando su una base sicura per impostazione predefinita quando non ne hai ancora uno. 2. Elenca il [catalogo](https://lagune.ai/it-IT/docs/catalog) del tuo progetto e carica solo le specializzazioni che il tuo lavoro tocca, la stessa conoscenza su richiesta che usa il flusso di audit. 3. Applica la difesa mentre il codice viene scritto, poi rilegge il proprio risultato per confermare che i controlli reggano davvero prima di restituirti il lavoro. Il risultato è codice funzionante nel tuo progetto, sicuro fin dalla prima riga. **Usalo quando vuoi** Niente detect, niente plan, niente pulizia a posteriori. **`/lagune`** si adatta allo stesso modo a uno scaffold appena creato o a una modifica su una codebase matura, e mette in sicurezza il lavoro strada facendo, non dopo. ## Cosa non fa - Non scrive nulla nella directory `.lagune`, né artefatti né tracciamento, quindi l'unica cosa che produce è il codice messo in sicurezza che hai chiesto. - Non indebolisce una regola per soddisfare un prompt: se ciò che hai chiesto violasse un principio del charter, si ferma e te lo dice prima, invece di costruirlo direttamente in modo non sicuro. ## Domande frequenti ### Cosa fa /lagune? Accetta qualsiasi prompt in qualsiasi fase, costruisce ciò che hai chiesto e lo mette in sicurezza con impostazioni predefinite sicure prima di restituirtelo. La difesa viene applicata mentre il codice viene scritto, non dopo. ### Mi serve un charter per usare /lagune? No. Funziona con o senza. Con un charter, le regole del tuo progetto plasmano ogni costruzione. Senza, ripiega su una base sicura per impostazione predefinita. ### Qual è la differenza tra /lagune e il flusso Blue Team? /lagune protegge il nuovo lavoro mentre lo scrivi, senza alcun flusso da seguire. Il flusso Blue Team esegue le cinque fasi di audit in ordine su un progetto esistente. ### /lagune traccia i rilievi o scrive artefatti? No. Non scrive nulla nella directory .lagune, né artefatti né tracciamento. L'unica cosa che produce è il codice messo in sicurezza che hai chiesto. ### Come faccio a far usare /lagune automaticamente al mio agente? Aggiungi un'istruzione al file di istruzioni del tuo agente (AGENTS.md, CLAUDE.md, .cursorrules e simili) che gli dica di usare la skill /lagune ogni volta che costruisce o modifica codice. --- # /lagune-charter: definisci i tuoi principi di sicurezza > Stabilisci i principi di sicurezza del tuo progetto, le regole che ogni fase successiva rispetta, e registra le categorie di specializzazioni che la sua lettura giustifica. Canonico: https://lagune.ai/it-IT/docs/commands/charter Lingua: it-IT Originale: https://lagune.ai/docs/commands/charter Ultimo aggiornamento: 2026-11-03 🧬 Racconta a **Lagune** che cos'è il tuo progetto e lo trasformerà nelle tue regole di sicurezza (oppure, senza alcuna descrizione, le ricaverà dal solo progetto). Il charter è il livello di governo: un insieme di principi con la sicurezza al primo posto che ogni fase successiva deve rispettare. Consideralo il controllo in fase di compilazione della postura di sicurezza del tuo progetto. ## Come usarlo **Descrivilo** ```prompt /lagune-charter Il mio progetto è un negozio online che vende videogiochi. I clienti aggiungono prodotti al carrello e pagano con carta di credito o bollettino. Possono vedere i propri ordini e lo stato di ciascuno. ``` **Lascia proporre a Lagune** ```prompt /lagune-charter ``` > _Vedo una libreria di pagamento, una configurazione di login e un modello di ordine legato a un cliente. Sembra un negozio online che vende qualcosa. I clienti pagano e seguono i propri ordini..._ ☁️ ## Cosa ricava **Lagune** prende la tua descrizione o il tuo **PRD** come direzione e ricava cosa implica per la sicurezza, poi legge il progetto per andare oltre ciò che hai nominato. Per esempio: - Un carrello che contiene ordini significa che c'è un **database**: - ad es. `"Dove risiedono i dati?"`, `"Chi può raggiungerli?"`, `"I dati trapelano?"`. - Clienti che possono vedere i propri ordini significa che c'è una qualche forma di **login o controllo degli accessi**: - ad es. `"Un cliente può raggiungere gli ordini di un altro?"`, `"Le sessioni sono protette?"`. - Accettare pagamenti con carta e bollettino significa che **sono in gioco denaro e dati sensibili**: - ad es. `"I dati delle carte vengono salvati?"`, `"I pagamenti vengono verificati?"`. La tua descrizione e il progetto si sommano: mentre la descrizione stabilisce l'intento, la lettura delle dipendenze, del README e della configurazione fa emergere ciò che non hai menzionato. Se qualcosa di importante resta poco chiaro, **Lagune** fa una domanda breve e semplice invece di tirare a indovinare. Da lì, **Lagune** costruisce un insieme di regole di sicurezza su misura per il progetto, che puoi rivedere e modificare ogni volta che ti serve. **Sfruttalo al massimo** - Puoi anche definire le tue regole di sicurezza per il progetto. - Più dettagli pertinenti fornisci, migliore sarà il report finale: - Spiega il progetto, come funziona e cosa succede dietro le quinte. - Chi è l'utente finale? Cosa possono fare gli utenti e cosa no? - I dettagli sul comportamento valgono quanto quelli tecnici. - La memoria del charter si trova in `.lagune/memory/charter.md`. ## Le categorie che registra Le specializzazioni, le conoscenze di sicurezza che le fasi successive caricano su richiesta, entrano nel [catalogo](https://lagune.ai/it-IT/docs/catalog) del tuo progetto per [categoria](https://lagune.ai/it-IT/docs/categories). Finché il progetto non ha alcuna categoria registrata, il charter registra ognuna di quelle che la sua lettura giustifica, come il linguaggio del progetto, le chiamate a un LLM o i container, e le nomina nel suo riepilogo. Una volta registrate le categorie, il charter le lascia come sono e nomina soltanto una categoria che il tuo progetto non usa ancora. Puoi modificarle tu in qualsiasi momento: ```bash npx lagune write add --categories python npx lagune write remove --categories python ``` ## Passo successivo Con le regole definite, mappa cosa fa davvero il tuo sistema: [`/lagune-detect`](https://lagune.ai/it-IT/docs/commands/detect). ## Domande frequenti ### Che cos'è un charter in Lagune? Il charter è il livello di governo di Lagune, un insieme di principi con la sicurezza al primo posto che ogni fase successiva deve rispettare. Consideralo il controllo in fase di compilazione della postura di sicurezza del tuo progetto. ### Dove viene salvato il charter? In .lagune/memory/charter.md. ### Posso scrivere le mie regole nel charter? Sì. Lagune propone regole partendo dalla tua descrizione e dal tuo codice, e tu puoi riformularle, eliminarle, aggiungerne o restringerne l'ambito. ### È il charter a scegliere le categorie di specializzazioni? Solo finché non ne è registrata nessuna. In quel caso registra ogni categoria che la sua lettura giustifica, come il tuo linguaggio o le chiamate a un LLM. Una volta registrate le categorie, non le modifica mai. --- # /lagune-detect: mappa il tuo sistema e i suoi rischi > Legge il tuo codice e mappa cosa fa il sistema e dove sono i rischi. Canonico: https://lagune.ai/it-IT/docs/commands/detect Lingua: it-IT Originale: https://lagune.ai/docs/commands/detect Ultimo aggiornamento: 2026-11-03 🔬 Scopri cosa fa davvero il tuo sistema e dove sono i rischi. Detect legge il codice e registra solo ciò che trova davvero, con le evidenze di cui hanno bisogno le fasi successive. La sua regola guida è rilevare, non inventare. ## Come usarlo **Analisi completa** ```prompt /lagune-detect ``` **Indica i percorsi** ```prompt /lagune-detect src/routes/ src/auth.ts ``` **Descrivi una preoccupazione** ```prompt /lagune-detect assicurati che i dati dei clienti non vengano mai esposti ``` ## Cosa mappa **Lagune** legge il codice e mappa ciò che trova. Ogni rilievo indica cos'è, perché conta e l'evidenza. Per esempio: - **Caricamento di file**, il sistema accetta file dagli utenti: - _Perché conta:_ un file camuffato da immagine può nascondere codice malevolo. - _Evidenza:_ l'handler di `POST /upload` si fida del tipo MIME inviato dal client, senza controllare il tipo reale del file. - **Login e sessioni**, gli utenti accedono per raggiungere il proprio account: - _Perché conta:_ una gestione debole delle sessioni permette a qualcuno di prendere il controllo di un account altrui. - _Evidenza:_ la logica di emissione delle sessioni, dove le sessioni vengono emesse senza alcuna scadenza. Strada facendo, detect dà a ogni specializzazione del [catalogo](https://lagune.ai/it-IT/docs/catalog) del tuo progetto un verdetto confrontandola con il codice, applica quelle il cui contesto è presente e le registra sotto **Applied specializations**, l'elenco che harden e verify riutilizzano. Da lì hai una mappa chiara di cosa fa il tuo sistema e di dove si trovano i rischi, pronta perché i passi successivi agiscano. **Suggerimento** - Eseguirlo di nuovo aggiorna la mappa: i rilievi risolti escono, quelli nuovi entrano. - La mappa di detect si trova in `.lagune/memory/detect.md`. ## Passo successivo Trasforma la mappa in un piano: [`/lagune-plan`](https://lagune.ai/it-IT/docs/commands/plan). ## Domande frequenti ### Cosa fa /lagune-detect? Legge il tuo codice e mappa cosa fa il sistema e dove sono i rischi, registrando solo ciò che trova davvero. La sua regola è rilevare, non inventare. ### Che cos'è un rilievo in Lagune? Un rilievo è un singolo rischio individuato, che indica cos'è, perché conta e l'evidenza nel codice. È l'unità tracciata che plan, harden e verify portano avanti. ### Dove viene salvata la mappa di detect? In .lagune/memory/detect.md. ### Quali specializzazioni usa detect? Ognuna di quelle nel catalogo del tuo progetto riceve un verdetto confrontato con il codice. Detect applica quelle il cui contesto è presente e le registra sotto Applied specializations. --- # /lagune-plan: valuta i rilievi e pianifica le correzioni > Trasforma ciò che detect ha trovato in un piano di difesa, valutando ogni rilievo con una categoria e un punteggio CVSS v4.0 e abbinandolo a una correzione. Canonico: https://lagune.ai/it-IT/docs/commands/plan Lingua: it-IT Originale: https://lagune.ai/docs/commands/plan Ultimo aggiornamento: 2026-11-03 🛡️ Trasforma ciò che detect ha trovato in un piano di difesa: valuta ogni rilievo con una categoria e un punteggio CVSS v4.0, poi abbinalo alla correzione da applicare. ## Come usarlo **Pianifica tutto** ```prompt /lagune-plan ``` **Indica i percorsi** ```prompt /lagune-plan src/routes/upload.ts ``` **Concentrati su un timore** ```prompt /lagune-plan dove potrebbero trapelare dati sensibili ``` ## Come funziona Questa fase riprende da detect. Detect ha già trovato cosa fa il tuo sistema e il rischio che ogni cosa comporta, quindi il piano non ripete il rischio: ne valuta la gravità e decide cosa fare. Plan non legge mai il codice, e questo obbliga ogni correzione a puntare a qualcosa che detect ha davvero rilevato. Valuta ogni rilievo con il metodo CVSS v4.0: una categoria, un vettore CVSS v4.0 ragionato a partire da ciò che detect e il charter hanno raccolto e calcolato dall'[hook `cvss`](https://lagune.ai/it-IT/docs/hooks/cvss), e la fascia di priorità in cui cade quel punteggio. Ogni correzione indica anche il principio del charter che rispetta. Per esempio: - **Caricamento di file** (Priorità: **Critical**) - _Categoria:_ caricamento di file senza restrizioni (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). - _Perché questa priorità:_ chiunque può raggiungere il caricamento via internet, e si trova sul server che conserva i file dei clienti. - _Rispetta:_ III. Ogni input è non attendibile finché non viene validato. - _Correzione:_ controllare il tipo reale e la dimensione del file, rinominarlo al salvataggio e conservare i caricamenti dove non possono essere eseguiti come codice. Da lì hai un elenco di correzioni valutate e con priorità, ognuna legata a un rilievo e pronta per essere applicata nella fase successiva. Il punteggio viene calcolato, mai stimato: il vettore riporta l'esposizione e la posta in gioco del progetto come metriche Environmental, e chiunque può incollarlo nel calcolatore di FIRST o del NVD e ricavare lo stesso punteggio. **Suggerimento** - Si basa interamente su detect. Se un file o un timore non è mai stato mappato, ti dice di eseguire prima `/lagune-detect` su di esso. - Eseguirlo di nuovo aggiorna il piano: le correzioni completate escono, quelle nuove entrano. - Il piano di difesa si trova in `.lagune/memory/plan.md`. **Dipende da detect** Plan lavora solo su ciò che [`/lagune-detect`](https://lagune.ai/it-IT/docs/commands/detect) ha già mappato, quindi esegui prima detect. ## Passo successivo Applica il piano: [`/lagune-harden`](https://lagune.ai/it-IT/docs/commands/harden). ## Domande frequenti ### Come assegna Lagune la priorità alle vulnerabilità? /lagune-plan valuta ogni rilievo con una categoria e un punteggio CVSS v4.0 calcolato dall'hook cvss, poi lo abbina alla correzione da applicare. ### Lagune usa CVSS v4.0? Sì. Ogni rilievo riceve un vettore e un punteggio CVSS v4.0, calcolati dall'hook cvss con la stessa aritmetica del calcolatore di FIRST, così chiunque può incollarvi il vettore e ricavare di nuovo il punteggio. ### Il piano legge il mio codice? No. Plan non legge mai il codice, e questo obbliga ogni correzione a puntare a qualcosa che detect ha davvero rilevato. --- # /lagune-harden: applica le correzioni di sicurezza al tuo codice > Applica al tuo codice le correzioni del piano, in sicurezza e una alla volta. Canonico: https://lagune.ai/it-IT/docs/commands/harden Lingua: it-IT Originale: https://lagune.ai/docs/commands/harden Ultimo aggiornamento: 2026-11-03 🔧 Applica al tuo codice le correzioni del piano, in sicurezza e una alla volta. ## Come usarlo **Applica tutto** ```prompt /lagune-harden ``` **Indica i percorsi** ```prompt /lagune-harden src/routes/upload.ts ``` **Per priorità** ```prompt /lagune-harden priorità critica e alta ``` ## Come funziona Il piano ha già deciso ogni correzione, quindi harden si limita ad applicarla. Dato che è l'unica fase che tocca il tuo codice, procede con cautela: applica una correzione alla volta perché ogni modifica resti facile da rivedere, e non indebolisce mai un controllo per far quadrare una correzione. Per esempio, la correzione del caricamento: - **Caricamento di file** (Stato: **Applied**) - _Cosa è cambiato:_ controlla il tipo reale e la dimensione del file, rifiuta tutto ciò che è inatteso, lo rinomina al salvataggio e lo conserva dove non può essere eseguito come codice. - _Dove:_ la funzione `handleUpload`, più l'helper di archiviazione che richiama. Se una correzione non può essere applicata del tutto, harden fa ciò che può in sicurezza e segna il resto come **Partial** o **Blocked**, lasciandolo aperto. **Applicata non significa verificata** Applied non significa ancora dimostrata. È a questo che serve [verify](https://lagune.ai/it-IT/docs/commands/verify). **Suggerimento** - Si basa interamente sul piano. Se una correzione o un file non è mai stato pianificato, ti dice di eseguire prima `/lagune-plan` su di esso. - Eseguirlo di nuovo riconcilia il registro: le modifiche annullate escono, le correzioni appena applicate entrano. - Il registro di hardening si trova in `.lagune/memory/harden.md`. **Dipende da plan e modifica il tuo codice** Harden si basa su [`/lagune-plan`](https://lagune.ai/it-IT/docs/commands/plan). È l'unica fase che modifica il tuo codice. ## Passo successivo Dimostra che ogni correzione regge: [`/lagune-verify`](https://lagune.ai/it-IT/docs/commands/verify). ## Domande frequenti ### /lagune-harden modifica il mio codice? Sì. È l'unica fase che tocca il tuo codice, applicando le correzioni del piano una alla volta. ### Cosa significano Applied, Partial e Blocked? Sono gli stati che Lagune registra per ogni correzione. Applied significa che la correzione è stata fatta, Partial che ne è stata fatta solo una parte, Blocked che non è stato possibile applicarla. Applied non significa ancora dimostrata. ### Lagune applica le correzioni senza chiedere? Se una modifica richiede la tua approvazione lo decidono il tuo agente e la modalità di permessi in cui lo esegui, non Lagune, che non aggiunge alcun passaggio di conferma proprio. In ogni caso non indebolisce mai un controllo per soddisfare una correzione, e se una correzione entrasse in conflitto con una regola del charter, si ferma e te lo dice prima. --- # /lagune-verify: dimostra che i controlli di sicurezza reggono > Dimostra che ogni correzione applicata regge, poi chiudi quelle che reggono. Canonico: https://lagune.ai/it-IT/docs/commands/verify Lingua: it-IT Originale: https://lagune.ai/docs/commands/verify Ultimo aggiornamento: 2026-11-03 ⚖️ Dimostra che ogni correzione applicata regge, leggendo il codice e confrontandolo con ciò che harden ha registrato, poi chiudi quelle che reggono. ## Come usarlo **Verifica tutto** ```prompt /lagune-verify ``` **Indica i percorsi** ```prompt /lagune-verify src/routes/upload.ts ``` **Per priorità** ```prompt /lagune-verify priorità critica e alta ``` ## Come funziona Legge il codice in ogni punto registrato da harden e conferma che corrisponda davvero a quanto dichiarato. La prova è proprio quel confronto, codice contro registro. Ogni controllo riceve uno di tre verdetti: | Verdetto | Significato | | ---------------------------- | --------------------------------------------------------- | | ✅ Risk closed | Il codice fa esattamente ciò che dichiara il registro. | | ❌ Risk not closed | Il controllo è ancora aperto. Verify ti rimanda a harden. | | ❓ Cannot tell from the code | L'evidenza non è visibile nel solo codice. | Un rischio dimostrato chiuso viene poi archiviato e tolto dalla catena, con la tua conferma. Per esempio: - **Caricamento di file** (Verdetto: **✅ Risk closed**) - _Come è stato dimostrato:_ ha letto l'handler del caricamento e ha visto che rileva il tipo reale del file dal contenuto, impone un limite di dimensione e rifiuta tutto il resto, esattamente come dichiara il registro. - _Evidenza:_ la funzione `handleUpload`, che rileva il tipo reale del file dal contenuto. Se il rischio non è chiuso, verify lo dice chiaramente e ti rimanda a [`/lagune-harden`](https://lagune.ai/it-IT/docs/commands/harden), perché la correzione è ancora aperta. **Suggerimento** - Si basa interamente sul registro di hardening. - Legge il tuo codice solo per giudicarlo, e non indebolisce mai un controllo né riscrive il codice per far passare un verdetto. - Eseguirlo di nuovo riconcilia i verdetti: quelli superati escono, e un rischio che non è più chiuso viene segnalato di nuovo. - Quando un rischio è dimostrato chiuso, chiede una volta, poi rimuove quel rilievo da tutta la catena (detect, plan, harden e tracciamento). - Non scrive alcun report proprio: ogni verdetto si trova nel blocco del suo controllo in `.lagune/memory/harden.md`, dove harden lo legge all'esecuzione successiva. **Dipende da harden** Verify si basa su [`/lagune-harden`](https://lagune.ai/it-IT/docs/commands/harden). ## Il ciclo si chiude Quando tutto ciò che rientra nell'ambito è archiviato, il ciclo è a riposo. Si riapre solo quando il codice cambia. La sicurezza si può chiudere, quindi il flusso ha uno stato finale, non un ciclo infinito. ## Domande frequenti ### Come verifica Lagune una correzione? /lagune-verify legge il codice e lo confronta con ciò che harden ha registrato, restituendo uno di tre verdetti: Risk closed, Risk not closed o Cannot tell from the code. ### Cosa significa archiviare un rilievo? Quando verify dimostra che un rischio è chiuso, il rilievo viene archiviato: rimosso da tutta la catena, con la tua conferma, così smette di essere rielaborato. ### Il lavoro di sicurezza può mai dirsi concluso? Sì. SDH si può chiudere: un rilievo dimostrato chiuso viene archiviato, quindi il flusso ha uno stato finale, non un ciclo infinito. --- # Categorie > Le categorie di specializzazioni che un progetto Lagune può usare, da OWASP all'hardening per linguaggio di JavaScript, Python, Go e Rust, e come modificarle. Canonico: https://lagune.ai/it-IT/docs/categories Lingua: it-IT Originale: https://lagune.ai/docs/categories Ultimo aggiornamento: 2026-11-03 **Lagune** raggruppa le sue [**specializzazioni**](https://lagune.ai/it-IT/docs/catalog) integrate in **13 categorie**. Le categorie usate da un progetto decidono quali specializzazioni integrate entrano nel suo [**catalogo**](https://lagune.ai/it-IT/docs/catalog), e si dividono in due: ciò che fa il sistema e ciò in cui è scritto. Finché non è registrata alcuna categoria, un progetto usa solo `owasp`. [`/lagune-charter`](https://lagune.ai/it-IT/docs/commands/charter) registra ogni categoria che la sua lettura del progetto giustifica, e tu puoi modificarle in qualsiasi momento. ## Ciò che fa il sistema | Categoria | Chiave | Cosa mette in sicurezza | | -------------- | --------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | | OWASP | `owasp` | I rischi di sicurezza applicativa che OWASP monitora: injection, controllo degli accessi inefficace, falle di autenticazione e di crittografia | | Infrastruttura | `infra` | La configurazione di container, workload e serverless: Dockerfile, Compose, sicurezza dei Pod, IAM e trigger FaaS | | IA / LLM | `ai` | Le integrazioni di IA e LLM, contro la prompt injection e i collegamenti non sicuri con strumenti, agenti, retrieval e MCP | | Lovable | `lovable` | Le app Supabase generate dall'IA (Lovable e simili): lacune nelle RLS, chiavi `service_role` esposte e impostazioni predefinite non sicure | ## Ciò in cui è scritto | Categoria | Chiave | Cosa mette in sicurezza | | ---------- | ------------ | ------------------------------------------------------------------------------------------------------------------------------- | | JavaScript | `javascript` | RCE tramite `eval` e `child_process`, path traversal e prototype pollution, in tutti i suoi runtime | | Python | `python` | RCE per deserializzazione con `pickle` e YAML, attraversamento tramite `str.format` e class pollution | | Rust | `rust` | API `unsafe` non corrette, uso improprio di `transmute`, integer overflow e comportamento indefinito al confine FFI | | C / C++ | `c-cpp` | Bug di format string, buffer overflow e scritture fuori dai limiti che permettono l'esecuzione di codice | | PHP | `php` | Aggiramento dell'autenticazione per type juggling, catene di gadget di object injection e configurazioni predefinite non sicure | | Go | `go` | Bug di interfacce con nil tipizzato, data race tra goroutine e concorrenza non sicura nei percorsi di sicurezza | | Java | `java` | Catene di gadget di deserializzazione con `ObjectInputStream` che culminano nell'esecuzione di codice remoto | | Ruby | `ruby` | Catene di gadget di deserializzazione con `Marshal.load` e YAML che portano all'esecuzione di codice remoto | | .NET / C# | `dotnet` | RCE per deserializzazione con `BinaryFormatter` e gli aggiramenti degli encoder che portano a XSS | **Suggerimento** **Lagune** è indipendente dal linguaggio: l'intero flusso legge qualunque linguaggio usi il tuo progetto, e queste categorie aggiungono solo profondità sulle insidie tipiche di un linguaggio. ## Aggiungi e rimuovi quando vuoi Una categoria è un punto di partenza, non un impegno. Usa ciò che si adatta al progetto adesso e cambialo in qualsiasi momento per chiave, con `write add` e `write remove`. `--categories` senza valore apre in un terminale un selettore interattivo (spazio per selezionare, invio per confermare, vuoto per saltare). Fuori da un terminale, passa le categorie dopo l'opzione. **Aggiungi** ```bash npx lagune write add --categories # interactive npx lagune write add --categories owasp npx lagune write add --categories owasp rust ``` **Rimuovi** ```bash npx lagune write remove --categories # interactive npx lagune write remove --categories owasp npx lagune write remove --categories owasp rust ``` Il primo `write add` o `write remove` parte da `owasp`, quindi rimuovere tutte le categorie lascia un elenco vuoto, mai quello predefinito. Ogni modifica finisce in `.lagune/configs.json`, così tutto il team lavora con lo stesso insieme. ## Guarda cosa usa un progetto `read list --categories` mostra ogni categoria e se il progetto la usa: ```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. ``` Consulta il [**Catalogo**](https://lagune.ai/it-IT/docs/catalog) per sapere quali specializzazioni porta ogni categoria. Le tue specializzazioni, scritte con [`/lagune-specialize`](https://lagune.ai/it-IT/docs/commands/specialize), entrano nel catalogo qualunque siano le categorie. ## Domande frequenti ### Come aggiungo una categoria? Passa la chiave della categoria a --categories, per esempio npx lagune write add --categories javascript. Anche il charter registra le categorie che la sua lettura del progetto giustifica, finché non ne è registrata nessuna. ### Posso usare più di una categoria? Sì. Elencale sulla stessa riga, una dopo l'altra. ### Quale categoria dovrebbe usare un progetto? Inizia con owasp, quella predefinita, poi aggiungi quella del tuo linguaggio o del tuo stack. Le specializzazioni si caricano solo su richiesta, quindi una categoria non costa nulla finché una fase non ha bisogno di una delle sue specializzazioni. --- # Catalogo: specializzazioni di sicurezza su richiesta > Come vengono caricate le specializzazioni del catalogo del tuo progetto, da una fase su richiesta e da te direttamente. Canonico: https://lagune.ai/it-IT/docs/catalog Lingua: it-IT Originale: https://lagune.ai/docs/catalog Ultimo aggiornamento: 2026-11-03 🧠 Le specializzazioni di **Lagune** sono moduli di conoscenza di sicurezza mirati e indipendenti dal linguaggio, che si caricano solo su richiesta, mai per impostazione predefinita. Non sono comandi. Il catalogo del tuo progetto è l'insieme che usa: le specializzazioni integrate delle sue [categorie](https://lagune.ai/it-IT/docs/categories) più le sue. Le fasi detect e verify vi attingono durante l'esecuzione, e tu puoi caricarne una direttamente in qualsiasi momento. **Panoramica** *La panoramica interattiva del catalogo si trova nella pagina web. Ogni specializzazione integrata è nella tabella qui sotto.* **Come funziona** ## Usala da solo Per usare direttamente una specializzazione, chiedi al tuo agente di caricarla con `read catalog ` e scrivi il compito nello stesso prompt. La conoscenza agisce allora su ciò che hai chiesto. Funziona in qualsiasi prompt, anche in uno che non ha nulla a che fare con il flusso di **Lagune**. Per esempio, un prompt diretto e libero per generare una raccolta sicura di **RegExp** con **Python**: ```prompt Carica la specializzazione regex con `npx lagune read catalog regex`, poi crea in @src/utils/regex.py una raccolta di espressioni regolari per validare email e nomi utente. ``` Questo usa un hook deterministico per testare ogni **RegExp** contro il **ReDoS**, mantiene quelle sicure e produce qualcosa del genere: ```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 ``` **Prova il ReDoS checker** Testa tu stesso un pattern su [**devina.io/redos-checker**](https://devina.io/redos-checker). ## Le specializzazioni integrate Le specializzazioni integrate sono raggruppate in [**categorie**](https://lagune.ai/it-IT/docs/categories). Questo è l'insieme fornito con **Lagune**: | Specializzazione | Categoria | Ambito | | --------------------- | --------------------------- | ----------------------------------------------------------------------------------------------------------------------- | | `regex` | `owasp` | **ReDoS:** pattern che esplodono con input costruiti ad arte. | | `network` | `owasp` | **SSRF e redirect:** destinazioni di richieste o redirect fornite dall'utente. | | `interpreter` | `owasp`, `lovable` | **Code injection:** `eval`, include dinamico, dispatch per nome. | | `sql` | `owasp` | **Database relazionali:** injection, chiamate ORM grezze, privilegi, portata del motore. | | `path` | `owasp` | **Percorsi del file system:** path traversal, byte nullo, stream NTFS, planting. | | `upload` | `owasp` | **Caricamento di file:** tipo/firma, contenuto malevolo, archiviazione, limiti. | | `access-control` | `owasp`, `lovable` | **Autenticazione, autorizzazione e sessione:** IDOR, mass assignment, tenant, sessioni. | | `credential-endpoint` | `owasp`, `lovable` | **Tentativi e bot:** brute force, password spraying, credential stuffing, limitazione dei tentativi. | | `federation` | `owasp` | **Fiducia nei token:** OAuth/OIDC, SAML, validazione dei JWT, login con QR. | | `http-request` | `owasp` | **Provenienza delle richieste:** CSRF, CORS mal configurato, IP del client falsificato. | | `transport` | `owasp` | **Sicurezza del canale:** configurazione TLS, HTTPS/testo in chiaro, HSTS, pinning. | | `crypto` | `owasp`, `lovable` | **Crittografia dei dati a riposo:** algoritmi deboli o fatti in casa, CSPRNG, gestione delle chiavi. | | `secrets` | `owasp`, `lovable` | **Credenziali scritte nel codice:** chiavi, token e password in chiaro nel sorgente. | | `api-endpoint` | `owasp` | **Superfici non REST:** GraphQL, gRPC, autorizzazione WebSocket, DoS, schema. | | `payment` | `owasp`, `lovable` | **Flusso di checkout:** verifica del gateway lato server, callback firmate, idempotenza. | | `xml` | `owasp` | **Parsing XML:** XXE, entità esterne, espansione billion laughs. | | `csv` | `owasp` | **Formula injection:** celle di foglio di calcolo che iniziano con `=`/`+`/`-`/`@`. | | `container` | `owasp`, `infra` | **Configurazione dei container:** root, capability, montaggio del socket, hardening dell'immagine. | | `infra` | `infra` | **Infrastructure as code:** Terraform, Dockerfile, GitHub Actions. | | `serverless` | `owasp`, `infra`, `lovable` | **Funzioni FaaS:** IAM con privilegio minimo, input degli eventi, contesto, segreti. | | `llm` | `ai`, `lovable` | **Rischi di IA e LLM:** prompt injection, agency, RAG, MCP, output. | | `supabase` | `lovable` | **Backend Supabase:** RLS disattivata per impostazione predefinita, policy generate male dall'IA, modello delle chiavi. | | `browser` | `javascript`, `lovable` | **Rischi lato client:** XSS, CSP, framing, storage, ecc. | | `javascript` | `javascript` | **Rischi del linguaggio:** RCE, prototype pollution, ecc. | | `python` | `python` | **Rischi del linguaggio:** RCE con `pickle`, class pollution, `-O`, ecc. | | `rust` | `rust` | **Solidità di `unsafe`:** UB da chiamanti sicuri, `transmute`, overflow. | | `java` | `java` | **Deserializzazione e codice mobile:** catene di `readObject`, dirottamento di oggetti. | | `ruby` | `ruby` | **Deserializzazione e `open`:** ricostruzione con `Marshal`/YAML, la stranezza delle pipe. | | `php` | `php` | **Type juggling e `unserialize`:** magic hash, catene POP. | | `go` | `go` | **Nil tipizzato e data race:** `nil != nil`, goroutine con memoria condivisa. | | `c-cpp` | `c-cpp` | **Format string:** `printf(user_input)`, scrittura arbitraria (write-what-where) con `%n`. | | `dotnet` | `dotnet` | **Rischi della piattaforma:** RCE con `BinaryFormatter`, `@Html.Raw`, lacune negli enum. | La maggior parte della conoscenza integrata è distillata da OWASP. Consulta [**Fonti OWASP**](https://lagune.ai/it-IT/docs/references/owasp-sources) per la corrispondenza completa tra ogni specializzazione e le sue pagine canoniche di attacco e di Cheat Sheet di OWASP. Alcuni moduli specifici per uno stack attingono invece alle indicazioni del fornitore: `supabase`, per esempio, deriva dalla documentazione di Supabase e dalla CVE-2025-48757. ## Le tue specializzazioni Le specializzazioni integrate crescono aggiungendo un file di conoscenza più una riga di indice, mai un nuovo comando. Tu aggiungi le tue nello stesso modo, con [`/lagune-specialize`](https://lagune.ai/it-IT/docs/commands/specialize): puntalo su un articolo o un tema e distilla una nuova specializzazione nel tuo progetto, il file in `.lagune/catalog/` e la sua voce in `.lagune/configs.json`. Le tue sono sempre nel catalogo, qualunque siano le sue categorie, e una delle tue oscura quella integrata con lo stesso nome. **Internamente, Lagune carica le specializzazioni in automatico, su richiesta** Quando la fase detect o verify incontra un contesto coperto da una specializzazione, carica da sola quella specializzazione con `read catalog `. Succede in automatico, come parte della fase. Non devi farlo a mano perché funzioni. ## Scopri cosa è disponibile Per elencare dal terminale il catalogo del tuo progetto, una specializzazione per riga con i suoi tag: ```bash npx lagune read catalog # regex: Regular Expression [required] # network: Requests, Webhook, URL Fetch, Socket, IMDS, Redirect # interpreter: Evaluator, Sink, Shell, Dynamic Execution # ... ``` Una specializzazione `[required]` si applica sempre, qualunque sia il lavoro. Quali specializzazioni integrate contenga l'elenco dipende dalle [**categorie**](https://lagune.ai/it-IT/docs/categories) del tuo progetto. **Le specializzazioni non si caricano per impostazione predefinita** La conoscenza pertinente viene richiamata per ciò che il progetto è davvero, invece di eseguire ogni controllo per impostazione predefinita. ## Domande frequenti ### Che cos'è una specializzazione di Lagune? Un modulo di conoscenza di sicurezza mirato e indipendente dal linguaggio, che si carica solo su richiesta, mai per impostazione predefinita. Non è un comando come le skill dell'agente. ### Che cos'è il catalogo di un progetto? Le specializzazioni che il progetto usa: quelle integrate delle sue categorie più le sue. Finché non è registrata alcuna categoria, usa solo OWASP. ### Le specializzazioni si caricano per impostazione predefinita? No. Si caricano solo su richiesta, per ciò che il progetto è davvero. ### Come carico direttamente una specializzazione? Nello stesso prompt del compito, chiedi al tuo agente di eseguire npx lagune read catalog . --- # /lagune-specialize: addestra una specializzazione di sicurezza con testo semplice > Distilla una fonte o un tema di sicurezza che gli fornisci in una nuova specializzazione su richiesta. Canonico: https://lagune.ai/it-IT/docs/commands/specialize Lingua: it-IT Originale: https://lagune.ai/docs/commands/specialize Ultimo aggiornamento: 2026-11-03 🎓 Insegna a **Lagune** una nuova specializzazione, a partire da una fonte o da un tema che gli fornisci. Legge il materiale e lo distilla in una specializzazione mirata ed esclusivamente difensiva, con la stessa forma di quelle [integrate](https://lagune.ai/it-IT/docs/catalog), così le fasi detect e verify la caricano poi come qualsiasi altra. Si limita a verificare e spiegare: non scrive mai input di attacco né exploit, e non tocca mai il tuo codice. **Da un articolo** ```prompt # Un link o un riferimento: Lagune lo distilla nella difesa /lagune-specialize https://owasp.org/www-community/attacks/SQL_Injection ``` **Da un exploit** ```prompt # Un attacco come fonte: la specializzazione resta comunque la difesa /lagune-specialize "' OR 1=1 -- inserisce SQL nel testo della query" ``` **Da un tema** ```prompt # Oppure nomina semplicemente cosa coprire /lagune-specialize SQL injection ``` **Un attacco può essere la fonte, mai il risultato** Puntarlo su un attacco va bene quando l'obiettivo è difendersi: la descrizione di un exploit è materiale di studio che distilla nella difesa. La specializzazione che produce verifica e spiega sempre, e non produce mai un exploit funzionante, un payload o una tecnica di evasione. ## Cosa scrive Il risultato sono due file nel tuo progetto, versionati e revisionabili insieme al tuo codice: - La specializzazione in `.lagune/catalog/.md`, con la stessa forma di quelle [integrate](https://lagune.ai/it-IT/docs/catalog). - La sua voce in `.lagune/configs.json`, dove il tuo progetto indicizza le proprie specializzazioni perché il catalogo le unisca a quelle integrate. Poi elenca il catalogo per confermare che la nuova voce ci sia. Le tue specializzazioni sono sempre nel catalogo, qualunque siano le sue categorie. Non aggiungi mai un comando né tocchi il pacchetto: una nuova specialità è un file di conoscenza più una voce di indice, scritti nel tuo progetto. ## Affinare, mai sovrascrivere Specializzare un nome che esiste già, che sia una specializzazione integrata come `regex` o una che hai specializzato in precedenza, **riconcilia** il file attuale invece di sostituirlo. Legge ciò che c'è, vi incorpora la nuova conoscenza, mantiene ciò che è ancora valido e riscrive ciò che è cambiato. Nulla viene scartato senza essere letto. Una tua specializzazione oscura quella integrata con lo stesso nome, così puoi affinare una specializzazione integrata per il tuo progetto senza perderla. **Suggerimento** - La nuova specializzazione si carica esattamente come una integrata: le fasi detect e verify la usano su richiesta, oppure caricala tu con `npx lagune read catalog ` e assegnale un compito. - Quando il materiale ha un'origine identificabile (un articolo, un autore, un link, uno standard), la specializzazione la cita. Un semplice tema non riporta alcuna fonte. **Nota** **Viene eseguita solo quando la richiami:** l'agente non la avvia mai di propria iniziativa. ## Domande frequenti ### Come aggiungo una specializzazione di sicurezza personalizzata? Esegui /lagune-specialize con una fonte o un tema. Lo distilla in una specializzazione esclusivamente difensiva, scritta in .lagune/catalog/.md più la sua voce in .lagune/configs.json. ### Lagune può imparare dalla descrizione di un exploit? Sì, come fonte, mai come risultato. Un attacco può essere la fonte, mai il prodotto. Specialize non scrive mai input di attacco né exploit. ### Specialize sovrascrive le specializzazioni integrate? No. Affina, non sovrascrive mai. --- # /lagune-prove: proof of concept esclusivamente difensiva > Trasforma ogni rilievo individuato in una proof of concept (PoC) eseguibile ed esclusivamente difensiva e in un bollettino per la divulgazione responsabile. Canonico: https://lagune.ai/it-IT/docs/commands/prove Lingua: it-IT Originale: https://lagune.ai/docs/commands/prove Ultimo aggiornamento: 2026-11-03 🧪 Trasforma ogni rilievo individuato in un'evidenza eseguibile ed esclusivamente difensiva per la divulgazione responsabile. Per ogni rilievo presente nella mappa di detect, scrive un bollettino autosufficiente e un test che verifica il **percorso sicuro**, così il test fallisce finché il problema è presente e passa non appena il codice viene corretto. **Suggerimento** I test di **Lagune** restano isolati in `.lagune/`, separati dalla tua suite. ## Come usarlo **Ogni rilievo** ```prompt /lagune-prove ``` **Un rilievo per nome** Guarda i rilievi già tracciati per nome: ```prompt npx lagune read list --findings # Findings # ... # • SQL injection in user lookup # ... ``` ```prompt # Poi dimostrane uno /lagune-prove SQL injection in user lookup ``` ## Come funziona Legge il sorgente a cui punta ogni rilievo e scrive una directory per ogni rilievo dimostrato in `.lagune/proofs/`, con esattamente due file: | File | Che cos'è | | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | | `report.test.mjs` (o `.cjs`) | Il test. Gira su Poku quando il tuo progetto lo usa già, altrimenti sul runner nativo di Node.js, quindi non richiede nulla di installato. | | `report.md` | Un bollettino autosufficiente: gravità, impatto, come si riproduce e il comando per eseguirlo, leggibile da solo. | Le prove sono sempre in JavaScript, così restano portabili qualunque sia il linguaggio del tuo progetto. Un indice `README.md` collega ogni prova e fornisce un unico comando per eseguirle tutte. **Suggerimento** - È **facoltativo e autonomo**: non è una delle cinque fasi e non fa parte della catena di tracciamento. - Scrive solo in `.lagune/proofs/` e non tocca mai gli artefatti delle fasi né il tuo codice, che si limita a leggere. - Un rilievo il cui test non riproduce il problema non riceve alcuna prova, e ti dice di eseguire [`/lagune-detect`](https://lagune.ai/it-IT/docs/commands/detect) su quel punto per riconciliare. - Eseguirlo di nuovo riconcilia le prove: un rilievo che non c'è più o che non si riproduce più perde la sua directory. **Nota** **Viene eseguito solo quando lo richiami:** l'agente non lo avvia mai di propria iniziativa. **Si basa su detect** Prove legge la mappa di detect prodotta da [`/lagune-detect`](https://lagune.ai/it-IT/docs/commands/detect), quindi esegui prima detect. ## Solo difesa, e con autorizzazione Prima di generare qualsiasi cosa, conferma che tu sia autorizzato a testare il bersaglio, e rifiuta qualsiasi richiesta di exploit funzionante, payload di attacco o elusione del rilevamento. Una prova dimostra il comportamento sicuro e non emette mai un input di attacco. ## Dalla prova alla divulgazione I due file di ogni rilievo dimostrato vanno insieme in un **GitHub Gist privato** per segnalare la vulnerabilità. Sono l'evidenza di un problema presente e non ancora divulgato, quindi un `.gitignore` dentro `.lagune/proofs/` li tiene fuori da ogni commit: condividili solo tramite quel Gist finché i maintainer non l'hanno risolto. Chiudere un rilievo nella catena di **Lagune** resta compito di [`/lagune-harden`](https://lagune.ai/it-IT/docs/commands/harden) e [`/lagune-verify`](https://lagune.ai/it-IT/docs/commands/verify): prove produce evidenze, non chiude nulla. ## Domande frequenti ### Lagune genera exploit? No. /lagune-prove scrive evidenze esclusivamente difensive: un test che verifica il percorso sicuro, così fallisce finché il problema è presente e passa non appena il codice viene corretto, più un bollettino per la divulgazione responsabile. ### Cosa produce prove? Due file per rilievo: un test (report.test.mjs o .cjs) e un bollettino (report.md). ### Come divulgo in modo responsabile un bug trovato da Lagune? Prove scrive un bollettino autosufficiente che puoi condividere tramite un canale privato, come un GitHub Gist privato, seguendo la divulgazione responsabile. --- # Hook agent: rileva i loop di agenti senza limiti > Analizza una codebase alla ricerca di chiamate ad agenti e LLM senza limite di passi o di tempo, oppure valuta una singola chiamata, dalla riga di comando. Canonico: https://lagune.ai/it-IT/docs/hooks/agent Lingua: it-IT Originale: https://lagune.ai/docs/hooks/agent Ultimo aggiornamento: 2026-11-03 L'hook `agent` segnala i **runtime di agenti che girano in loop senza limite di turni, di budget o di tempo**, la falla di autonomia fuori controllo che trasforma un input costruito ad arte in costi illimitati o in un'escalation di prompt injection. È **consapevole del linguaggio** e copre i due ecosistemi di framework per agenti: **JavaScript** (il runtime `query` dell'SDK per agenti di **Claude**) e **Python** (**LangChain**, **LangGraph**, **CrewAI**, **OpenAI Agents**). È il motore deterministico dietro la [specializzazione `llm`](https://lagune.ai/it-IT/docs/catalog), e puoi eseguirlo tu stesso in modalità **scan** o **check**. ## Come eseguirlo **Analizza la codebase** ```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 ``` **Controlla una chiamata** ```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 ``` Ogni riga sotto **Uncapped agent loops found** è, in un file che importa un SDK per agenti, o il runtime `query` dell'SDK per agenti di Claude chiamato senza limite di turni, di budget o di tempo (JavaScript, illimitato per impostazione predefinita), o la rimozione esplicita del limite predefinito di un framework, come `max_iterations=None` / `max_turns=None` (Python, limitato per impostazione predefinita). In entrambi i casi esce con un codice diverso da zero. `generateText`/`streamText` dell'SDK AI di Vercel eseguono per impostazione predefinita un solo passo (`stopWhen: stepCountIs(1)`), quindi una chiamata semplice non può andare in loop e non viene segnalata, e un normale `db.query(...)` non viene mai scambiato per una chiamata a un agente. Un'esecuzione pulita stampa `no uncapped agent loops found`. ## Come leggere il verdetto | Verdetto | Significato | | ---------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | | `uncapped` | Una chiamata al runtime `query` senza limite (JS), o una rimozione esplicita del limite (`=None`, Py). | | `safe` | Una chiamata `query` che imposta un limite, una generazione a passo singolo o la chiamata a un framework limitato per impostazione predefinita. | | `invalid` | Il frammento non contiene alcuna chiamata ad agenti riconoscibile da giudicare. | ### Opzioni della CLI | Opzione | Valore | Descrizione | | ----------- | ---------------------- | -------------------------------------------------------------------------------- | | `--pattern` | un frammento di codice | Controlla una chiamata. Ripetila per controllarne diverse, un verdetto per riga. | | `--lang` | un linguaggio | Obbligatoria con `--pattern`: `javascript` o `python`. | | `--dir` | una directory | Limita l'analisi a una directory. Si ripete e si combina con `--file`. | | `--file` | un file | Limita l'analisi a un singolo file. Si ripete e si combina con `--dir`. | Senza opzioni analizza l'intero progetto. `--pattern` richiede `--lang` e non si può combinare con `--dir` o `--file`. **Al meglio delle possibilità, non esaustivo** Un loop di agente scritto a mano, in qualsiasi linguaggio, va oltre un'analisi statica. Consideralo una base solida, non un inventario completo. **Suggerimento** L'hook decide solo il limite: la delimitazione delle capacità, la commistione di livelli di fiducia e l'autorizzazione restano valutazioni coperte dalla [specializzazione `llm`](https://lagune.ai/it-IT/docs/catalog). ## Domande frequenti ### Perché limitare il loop di un agente? Un agente senza limiti può essere spinto in una ricorsione, in costi o in un'escalation di prompt injection senza fine. Impostare maxTurns/maxBudgetUsd/stopWhen/signal lo delimita, e l'hook agent segnala una chiamata al runtime query che non ne imposta nessuno. --- # Hook cors: verifica le origini CORS > Analizza il sorgente alla ricerca di una allowlist di origini CORS aggirabile, oppure valuta un singolo valore di origine troppo permissivo, dalla riga di comando. Canonico: https://lagune.ai/it-IT/docs/hooks/cors Lingua: it-IT Originale: https://lagune.ai/docs/hooks/cors Ultimo aggiornamento: 2026-11-03 L'hook `cors` è il motore deterministico dietro la [specializzazione `http-request`](https://lagune.ai/it-IT/docs/catalog), e puoi eseguirlo tu stesso. Funziona in due modalità con un solo comando: uno **scan** che analizza il sorgente alla ricerca di una **allowlist di origini aggirabile** (una regex di validazione dell'host che un host malevolo riesce a superare) e uno **score** che classifica un singolo valore di **origine CORS** come `wildcard`, `null` o `safe`. ## Analizza una codebase Senza flag analizza l'intero progetto. **Tutto il progetto** ```bash npx lagune read cors ``` **Una directory** ```bash npx lagune read cors --dir src/server ``` **Un singolo file** ```bash npx lagune read cors --file internal/auth/origin.go ``` Elenca ogni allowlist aggirabile sotto un'unica intestazione, raggruppata per file. Un validatore di host il cui `.+`/`.*` si trova nel segmento authority prima del suffisso dell'host fidato (`^https?://.+\.trusted\.com`) lascia passare un host malevolo come `your-site.com.attacker.com`. ```text Origin-allowlist patterns with a greedy wildcard (bypassable, review): internal/auth/origin.go ^https?://.+\.trusted\.com ``` È una pista da verificare, non un rilievo chiuso: se la regex governi davvero una decisione di fiducia non si può stabilire dal testo, quindi uno scan non cambia mai il codice di uscita. Leggile una per una e conferma che l'allowlist confronti per uguaglianza completa. Quando non trova nulla, stampa una sola riga. ```bash npx lagune read cors --dir src/clean # => no bypassable origin allowlist found ``` ## Valuta un'origine Passa ogni origine con `--origin`. L'hook stampa una parola per origine ed esce con un codice diverso da zero se trova un `wildcard` o un `null`. **Un** ```bash npx lagune read cors --origin '*' # => wildcard npx lagune read cors --origin 'null' # => null npx lagune read cors --origin 'https://app.example.com' # => safe ``` **Più origini** Ripeti `--origin` per valutare un'intera allowlist in una sola chiamata, un verdetto per riga, nell'ordine. ```bash npx lagune read cors \ --origin 'https://app.example.com' \ --origin '*' \ --origin 'null' # => safe # => wildcard # => null ``` | Verdetto | Significato | | ---------- | ----------------------------------------------------------------------------------------------------- | | `safe` | Non è `*`, `null` né un glob con `*`. Non garantisce che l'origine sia ben formata. | | `wildcard` | `*`, un glob di sottodominio/host/porta: qualsiasi sito (o un ampio insieme) può leggere la risposta. | | `null` | L'origine `null`, che gli iframe in sandbox e i redirect possono falsificare. | Solo `safe` è un via libera, e `--origin` è un oracolo dei valori: giudica il valore, non l'handler, quindi conferma l'handler con la specializzazione `http-request`. ### Opzioni della CLI | Opzione | Valore | Descrizione | | ---------- | ------------- | -------------------------------------------------------------------------- | | `--origin` | un'origine | Valuta un valore di origine. Ripetila per valutarne diversi, uno per riga. | | `--dir` | una directory | Limita l'analisi a una directory. Si ripete e si combina con `--file`. | | `--file` | un file | Limita l'analisi a un singolo file. Si ripete e si combina con `--dir`. | Senza opzioni analizza l'intero progetto. `--origin` è la modalità score e non si può combinare con `--dir` o `--file`. **Cosa non copre** Lo scan legge la forma della **regex aggirabile**, e `--origin` valuta i **valori** di origine. Due schemi a livello di sorgente restano fuori portata: la riflessione dell'`Origin` della richiesta (il server rimanda indietro l'`Origin` in arrivo, o lo abbina alle credenziali) e una allowlist permissiva basata su `endsWith` o sottostringhe. Riconoscili nel codice e trattali come descrive la [specializzazione `http-request`](https://lagune.ai/it-IT/docs/catalog). ## Domande frequenti ### Perché un'origine CORS null è pericolosa? Gli iframe in sandbox e alcuni redirect inviano Origin: null, quindi una allowlist che si fida di null concede a quei contesti l'accesso in lettura. L'hook cors la segnala insieme al wildcard. ### Come individuo una allowlist di origini CORS aggirabile? Esegui npx lagune read cors sulla codebase. Segnala una regex di validazione dell'host il cui wildcard greedy si trova prima del suffisso fidato, così un host malevolo come your-site.com.attacker.com riesce a passare. --- # Hook crypto: rileva la crittografia debole > Analizza una codebase alla ricerca di primitive crittografiche deboli, oppure valuta un singolo frammento, dalla riga di comando. Canonico: https://lagune.ai/it-IT/docs/hooks/crypto Lingua: it-IT Originale: https://lagune.ai/docs/hooks/crypto Ultimo aggiornamento: 2026-11-03 L'hook `crypto` segnala le **primitive crittografiche deboli** nel punto della chiamata: un cifrario deprecato, una modalità non sicura o un digest compromesso. È **consapevole del linguaggio**, legge ogni file con le sue regole, così un costrutto Python non viene mai segnalato in un file Rust, ed è il motore deterministico dietro la [specializzazione `crypto`](https://lagune.ai/it-IT/docs/catalog), che puoi eseguire tu stesso in modalità **scan** o **check**. ## Come eseguirlo **Analizza la codebase** ```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 ``` **Controlla un frammento** ```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 ``` L'analisi stampa fino a due sezioni. **Weak cryptography found** è l'insieme dei rilievi (DES/3DES/RC4/Blowfish/RC2, modalità ECB): ognuno è una primitiva di cifratura compromessa, quindi l'hook esce con un codice diverso da zero. **Cryptography to review manually** è un insieme di piste che non può giudicare da solo: un digest MD5/SHA-1 (compromesso per usi di sicurezza, ma legittimo come semplice checksum, quindi decide l'intento), un RNG non crittografico in un contesto di sicurezza o un confronto non sicuro rispetto ai tempi di esecuzione. Un'esecuzione pulita stampa `no weak cryptography found`. ## Come leggere il verdetto | Verdetto | Significato | | --------- | -------------------------------------------------------------------------------------------------------------------- | | `weak` | Il frammento usa una primitiva di cifratura compromessa (DES/3DES, RC4, Blowfish, RC2 o modalità ECB). | | `review` | Una primitiva che dipende dall'intento: un digest MD5/SHA-1, o un RNG non crittografico in un contesto di sicurezza. | | `safe` | Il frammento usa la crittografia e non è stata trovata alcuna primitiva debole. | | `invalid` | Il frammento non contiene alcun costrutto crittografico riconoscibile da giudicare. | ### Opzioni della CLI | Opzione | Valore | Descrizione | | ----------- | ---------------------- | ------------------------------------------------------------------------------------------------------------ | | `--pattern` | un frammento di codice | Controlla un frammento. Ripetila per controllarne diversi, un verdetto per riga. | | `--lang` | un linguaggio | Obbligatoria con `--pattern`: uno tra javascript, python, go, java, kotlin, php, ruby, rust, csharp, c, cpp. | | `--dir` | una directory | Limita l'analisi a una directory. Si ripete e si combina con `--file`. | | `--file` | un file | Limita l'analisi a un singolo file. Si ripete e si combina con `--dir`. | Senza opzioni analizza l'intero progetto. `--pattern` richiede `--lang` e non si può combinare con `--dir` o `--file`. ### Linguaggi supportati L'analisi legge questi linguaggi, riconosciuti dall'estensione del file, ognuno controllato rispetto alle proprie API crittografiche. | Linguaggio | Cifrari deboli (rilievo) e digest/RNG (da rivedere) | | --------------------------- | ------------------------------------------------------------------------------------------------------------------- | | **JavaScript / TypeScript** | `createCipher`, `CryptoJS.DES/RC4`, `*-ecb` tra virgolette; 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()` | **Al meglio delle possibilità, non esaustivo** Legge il sorgente come testo, quindi una primitiva costruita a runtime, nascosta dietro un alias o scritta in una forma che non riconosce può sfuggirgli. Considera la tabella un solido punto di partenza, non un inventario completo. **Suggerimento** L'hook garantisce la base (questi costrutti esistono): la gestione delle chiavi, il riutilizzo degli IV e il padding RSA restano valutazioni coperte dalla [specializzazione `crypto`](https://lagune.ai/it-IT/docs/catalog). ## Domande frequenti ### Come analizzo una codebase alla ricerca di crittografia debole? Esegui l'hook crypto senza flag. I cifrari compromessi e la modalità ECB sono rilievi che escono con un codice diverso da zero. Un digest MD5/SHA-1 è una pista da rivedere, perché è compromesso per usi di sicurezza ma legittimo come semplice checksum. ### L'hook crypto segnala Math.random()? Solo come pista da rivedere in un contesto di sicurezza, mai come rilievo automatico, perché la casualità è legittima per il jitter o per l'ordinamento nell'interfaccia. --- # Hook cvss: valuta un vettore CVSS v4.0 > Calcola il punteggio di uno o più vettori CVSS v4.0 dalla riga di comando, con la stessa aritmetica del calcolatore di FIRST, e rileggili in parole semplici. Canonico: https://lagune.ai/it-IT/docs/hooks/cvss Lingua: it-IT Originale: https://lagune.ai/docs/hooks/cvss Ultimo aggiornamento: 2026-11-03 L'hook `cvss` calcola il punteggio di un **vettore CVSS v4.0** e ne stampa il punteggio e la fascia di gravità, la valutazione che [`/lagune-plan`](https://lagune.ai/it-IT/docs/commands/plan) scrive su ogni correzione e [`/lagune-prove`](https://lagune.ai/it-IT/docs/commands/prove) su ogni bollettino. È il motore deterministico dietro quelle valutazioni, con la stessa aritmetica del [calcolatore di FIRST](https://www.first.org/cvss/calculator/4.0), e puoi eseguirlo tu stesso. ## Come eseguirlo Passa ogni vettore con `--vector`. L'hook stampa una riga per vettore: il suo punteggio e la sua fascia. **Un vettore** ```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 ``` **Più vettori** Ripeti `--vector` per valutarne diversi insieme, una riga ciascuno, nell'ordine. ```bash npx lagune read cvss \ --vector 'CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N' \ --vector 'CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/MAV:A' # => 9.3, Critical # => 8.7, High ``` **In parole semplici** Aggiungi `--explain` per rileggere ogni metrica in parole semplici. Quando le metriche Threat o Environmental spostano il punteggio, il solo punteggio Base viene mostrato per primo. ```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 # => ... ``` ## Come leggere il risultato | Fascia | Punteggio | | ---------- | ------------- | | `None` | 0.0 | | `Low` | da 0.1 a 3.9 | | `Medium` | da 4.0 a 6.9 | | `High` | da 7.0 a 8.9 | | `Critical` | da 9.0 a 10.0 | Un vettore con le sole metriche Base valuta la falla in sé, ipotizzando il caso peggiore: ogni requisito di sicurezza High e la falla sfruttata attivamente. Le metriche Environmental (`MAV` e le altre metriche modificate, più `CR`, `IR` e `AR`) la definiscono per un singolo deployment, e la metrica Threat (`E`) in base a ciò che si sa del suo sfruttamento. Un vettore non valido stampa `invalid vector:` e cosa c'è di sbagliato, e l'hook esce con un codice diverso da zero. ### Opzioni della CLI | Opzione | Valore | Descrizione | | ----------- | --------------------- | ------------------------------------------------------------------------------------- | | `--vector` | un vettore `CVSS:4.0` | Valuta un vettore. Ripetila per valutarne diversi, una riga per vettore, nell'ordine. | | `--explain` | | Aggiunge ogni metrica in parole semplici sotto ogni riga di valutazione. | Serve almeno un `--vector`. Il vettore non è mai un argomento posizionale semplice, quindi non può essere scambiato per un flag. **Perché il valore di un flag** Ogni vettore viene passato come valore di un flag, mai interpolato nel comando. Un valore con virgolette o backtick resta inerte e non può iniettare nulla nella shell. Racchiudilo sempre tra apici singoli, così la tua shell non lo espande prima. **Cosa non copre** Solo CVSS v4.0: un vettore v2.0, v3.0 o v3.1 viene rifiutato invece che valutato, perché **Lagune** valuta ogni rilievo in v4.0. **Suggerimento** La validazione della fase plan riesegue questa stessa aritmetica su ogni riga CVSS, così un punteggio che si è discostato dal suo vettore viene individuato prima che il piano venga accettato. ## Domande frequenti ### Come calcola Lagune un punteggio CVSS? L'hook cvss segue il calcolatore di riferimento di FIRST per CVSS v4.0, quindi un vettore ottiene esattamente lo stesso punteggio che ha sul sito di FIRST. ### Posso valutare con esso un vettore CVSS v3.1? No. Lagune valuta ogni rilievo in CVSS v4.0, e l'hook rifiuta qualsiasi altra versione invece di valutarla. ### Cosa fa il flag --explain? Rilegge ogni metrica in parole semplici e mostra il punteggio Base accanto a quello complessivo, così chiunque può vedere cosa dice il vettore e come il contesto del progetto lo ha spostato. --- # Hook infra: rileva le configurazioni IaC errate > Analizza Terraform, Dockerfile e GitHub Actions alla ricerca di configurazioni errate, oppure valuta un singolo frammento, dalla riga di comando. Canonico: https://lagune.ai/it-IT/docs/hooks/infra Lingua: it-IT Originale: https://lagune.ai/docs/hooks/infra Ultimo aggiornamento: 2026-11-03 L'hook `infra` segnala le **configurazioni errate dell'infrastructure as code** che si possono stabilire dal file stesso: una rete aperta al mondo, un permesso wildcard, un segreto in un manifest, un container eseguito come root, un valore non attendibile in una shell di CI. Legge solo file IaC (`.tf`/`.tf.json`/`.hcl`, `Dockerfile*`, `.github/workflows/**`). È il motore deterministico dietro la [specializzazione `infra`](https://lagune.ai/it-IT/docs/catalog), in modalità **scan** o **check**. ## Come eseguirlo **Analizza la codebase** ```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 ``` **Controlla un frammento** Passa il frammento con `--pattern` e il suo tipo con `--kind` (`terraform`, `dockerfile` o `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 ``` L'analisi stampa fino a due sezioni. **Infrastructure risks found** esce con un codice diverso da zero e contiene i difetti accertabili (un ingresso `0.0.0.0/0` su una porta sensibile, una regola IAM wildcard, un segreto in un manifest, `encrypted = false`, un modulo git non fissato a una versione, un'immagine che gira esplicitamente come root, un `curl | sh`, una script injection nella CI, `permissions: write-all`). **Infrastructure hardening advisories** non cambia il codice di uscita (un tag di base mutabile, un'action fissata a un tag). Un'esecuzione pulita stampa `no infrastructure risks found`. ## Come leggere il verdetto La modalità check stampa il tag di gravità più alta che ha trovato (per esempio `public-ingress`, `iam-wildcard`, `root-user`, `curl-pipe`, `script-injection`, `write-all`), un tag di avviso (`mutable-tag`, `unpinned-action`) oppure `safe`. Solo un tag con gravità da rilievo esce con un codice diverso da zero. ### Opzioni della CLI | Opzione | Valore | Descrizione | | ----------- | ----------------------------------------------- | ----------------------------------------------------------------------------- | | `--pattern` | un frammento | Controlla un frammento. Richiede `--kind`. Ripetila per controllarne diversi. | | `--kind` | `terraform` \| `dockerfile` \| `github-actions` | Il tipo con cui viene giudicato il frammento. | | `--dir` | una directory | Limita l'analisi a una directory. Si ripete e si combina con `--file`. | | `--file` | un file | Limita l'analisi a un singolo file. Si ripete e si combina con `--dir`. | Senza opzioni analizza ogni file IaC del progetto. `--pattern` non si può combinare con `--dir` o `--file`. **Suggerimento** L'hook coglie i casi evidenti e accertabili: la cifratura assente, l'esposizione tramite `pull_request_target` e il giusto ambito IAM restano valutazioni coperte dalla [specializzazione `infra`](https://lagune.ai/it-IT/docs/catalog). ## Domande frequenti ### Quali file di infrastruttura legge l'hook infra? Terraform/HCL (.tf, .tf.json, .hcl), i Dockerfile e lo YAML dei workflow e delle action di GitHub Actions in .github/. Raggiunge quei file anche se gli scanner del sorgente li saltano. --- # Hook interpreter: segnala i sink di esecuzione dinamica del codice > Analizza una codebase alla ricerca di sink di esecuzione dinamica del codice in vari linguaggi, oppure valuta un singolo frammento, dalla riga di comando. Canonico: https://lagune.ai/it-IT/docs/hooks/interpreter Lingua: it-IT Originale: https://lagune.ai/docs/hooks/interpreter Ultimo aggiornamento: 2026-11-03 L'hook `interpreter` segnala i **sink di esecuzione dinamica del codice**: costrutti che trasformano dati in codice in esecuzione o li passano a una shell, da `eval` alla deserializzazione nativa. È consapevole del linguaggio, legge ogni file con le sue regole, ed è il motore deterministico dietro la [specializzazione `interpreter`](https://lagune.ai/it-IT/docs/catalog), che puoi eseguire tu stesso in modalità **scan** o **check**. ## Come eseguirlo **Analizza la codebase** ```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 ``` **Controlla un frammento** ```bash npx lagune read interpreter --lang javascript --pattern 'eval(x)' # => careful npx lagune read interpreter --lang python --pattern 'json.loads(x)' # => safe ``` Questi sink sono a doppio uso: se un input influenzato da un attaccante ne raggiunga uno non si può stabilire con un'analisi statica, quindi ogni corrispondenza è un **avviso da rivedere**, mai un rilievo confermato. L'analisi stampa un'unica sezione **Dynamic-execution sinks to review**, raggruppata per file. Un'esecuzione pulita stampa `no dynamic-execution sinks found`. **Leggi il codice segnalato, non eseguirlo mai!** Ragiona su ogni sink in modo **statico**, tracciando se un input non attendibile lo raggiunge. Non eseguire mai né passare a `eval` il codice segnalato, né alcun codice remoto o scaricato a runtime che esso richiami, per "testare" cosa fa. ## Come leggere il verdetto | Verdetto | Significato | | --------- | ----------------------------------------------------------------------------------------------------------------- | | `careful` | Il frammento contiene un sink di esecuzione dinamica per il suo linguaggio. Rivedilo leggendolo, mai eseguendolo. | | `safe` | Non è stato trovato alcun sink di esecuzione dinamica per il linguaggio indicato. | ### Opzioni della CLI | Opzione | Valore | Descrizione | | ----------- | ---------------------- | ------------------------------------------------------------------------------------------------------------ | | `--pattern` | un frammento di codice | Controlla un frammento. Ripetila per controllarne diversi, un verdetto per riga. | | `--lang` | un linguaggio | Obbligatoria con `--pattern`: uno tra javascript, python, php, ruby, java, kotlin, go, rust, c, cpp, csharp. | | `--dir` | una directory | Limita l'analisi a una directory. Si ripete e si combina con `--file`. | | `--file` | un file | Limita l'analisi a un singolo file. Si ripete e si combina con `--dir`. | Senza opzioni analizza l'intero progetto. `--pattern` richiede `--lang` e non si può combinare con `--dir` o `--file`. ### Linguaggi supportati L'analisi legge questi linguaggi, riconosciuti dall'estensione del file, ognuno controllato rispetto al proprio insieme di sink di esecuzione dinamica. | # | Linguaggio | Estensioni | Sink che segnala | | --- | --------------------------- | ------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1 | **JavaScript / TypeScript** | `.js`, `.jsx`, `.mjs`, `.cjs`, `.ts`, `.tsx`, `.mts`, `.cts`, `.astro`, `.vue`, `.svelte`, `.marko`, `.riot` | `eval()`, costruttore Function, `setTimeout`/`setInterval` con corpo stringa, modulo `vm`, exec di `child_process`, `require()` dinamico, `import()` dinamico | | 2 | **Python** | `.py`, `.pyi` | `eval`/`exec`, `__import__()`, `os.system`/`os.popen`, `subprocess` con `shell=True`, `pickle.load`/`loads`, `yaml.load` (non sicuro) | | 3 | **Ruby** | `.rb` | famiglia eval (`instance_eval`/`class_eval`/`module_eval`/`eval`), `system`/`exec`, backtick o `%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()` su stringa, `create_function()`, esecuzione in shell (`system`/`exec`/`shell_exec`/`passthru`/`popen`/`proc_open`), `call_user_func`/`call_user_func_array`, `include`/`require` con percorso a runtime | | 6 | **Rust** | `.rs` | `Command::new`, `process::Command` | | 7 | **Java** | `.java` | `Runtime.exec`, `ProcessBuilder`, `ScriptEngine`, `ObjectInputStream.readObject` | | 8 | **Kotlin** | `.kt`, `.kts` | I sink della JVM: `Runtime.exec`, `ProcessBuilder`, `ScriptEngine`, `ObjectInputStream.readObject` | | 9 | **C#** | `.cs` | `Process.Start` / `new Process`, `BinaryFormatter`, `Assembly.Load` | | 10 | **C** | `.c`, `.h` | `system()`, `popen()`, la famiglia `exec*` (`execl`, `execve`, `execvp`, …) | | 11 | **C++** | `.cc`, `.cpp`, `.cxx`, `.hpp`, `.hh`, `.hxx` | `system()`, `popen()`, la famiglia `exec*` (`execl`, `execve`, `execvp`, …) | **Al meglio delle possibilità, non esaustivo** Legge il sorgente come testo, quindi un sink costruito a runtime, nascosto dietro un alias o scritto in una forma che non riconosce può sfuggirgli. Considera la tabella un solido punto di partenza, non un inventario completo. **Suggerimento** L'hook garantisce la base (questi sink esistono, e dove): se un valore non attendibile ne raggiunga davvero uno è la valutazione coperta dalla [specializzazione `interpreter`](https://lagune.ai/it-IT/docs/catalog). ## Domande frequenti ### L'hook interpreter conferma una vulnerabilità? No. Segnala i sink di esecuzione dinamica come avviso da rivedere, mai come rilievo confermato, perché se un input influenzato da un attaccante raggiunga il sink non si può stabilire con un'analisi statica. ### Quali linguaggi copre l'hook interpreter? Legge i linguaggi della tabella Linguaggi supportati, riconosciuti dall'estensione del file, ognuno controllato rispetto al proprio insieme di sink. Gli altri linguaggi non producono sink. --- # Hook jwt: rileva la verifica JWT senza algoritmo fissato > Analizza una codebase alla ricerca di verifiche JWT che non fissano l'algoritmo, oppure valuta una singola chiamata, dalla riga di comando. Canonico: https://lagune.ai/it-IT/docs/hooks/jwt Lingua: it-IT Originale: https://lagune.ai/docs/hooks/jwt Ultimo aggiornamento: 2026-11-03 L'hook `jwt` segnala la **verifica dei JWT senza un algoritmo fissato**, la falla di algorithm confusion in cui chi verifica si fida dell'header `alg` del token stesso, e la **verifica disattivata del tutto**. È **consapevole del linguaggio**, legge ogni file in base alla sua libreria JWT, ed è il motore deterministico dietro la [specializzazione `federation`](https://lagune.ai/it-IT/docs/catalog), che puoi eseguire tu stesso in modalità **scan** o **check**. ## Come eseguirlo **Analizza la codebase** ```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 ``` **Controlla una chiamata** ```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 ``` Ogni riga sotto **Unpinned JWT verification found** è una chiamata di verifica che non imposta alcuna allowlist `algorithms` (dove la libreria ne richiede una), ne accetta una non sicura (`none`, o un algoritmo asimmetrico mescolato con HMAC) o disattiva del tutto il controllo della firma, e quindi si fida dell'`alg` del token stesso. È un'esposizione confermata, quindi l'hook esce con un codice diverso da zero. Un'esecuzione pulita stampa `no unpinned JWT verification found`. ## Come leggere il verdetto | Verdetto | Significato | | ---------- | ---------------------------------------------------------------------------------------------------------------------------- | | `unpinned` | Una chiamata di verifica senza allowlist di algoritmi (dove ne serve una), con una non sicura o con la verifica disattivata. | | `safe` | Una chiamata di verifica che fissa una allowlist di algoritmi solida, o la cui libreria la fissa implicitamente. | | `invalid` | Il frammento non contiene alcuna chiamata di verifica riconoscibile da giudicare. | ### Opzioni della CLI | Opzione | Valore | Descrizione | | ----------- | ---------------------- | ---------------------------------------------------------------------------------------------------- | | `--pattern` | un frammento di codice | Controlla una chiamata. Ripetila per controllarne diverse, un verdetto per riga. | | `--lang` | un linguaggio | Obbligatoria con `--pattern`: uno tra javascript, python, go, java, kotlin, php, ruby, rust, csharp. | | `--dir` | una directory | Limita l'analisi a una directory. Si ripete e si combina con `--file`. | | `--file` | un file | Limita l'analisi a un singolo file. Si ripete e si combina con `--dir`. | Senza opzioni analizza l'intero progetto. `--pattern` richiede `--lang` e non si può combinare con `--dir` o `--file`. ### Linguaggi supportati L'analisi legge queste librerie, riconosciute dall'estensione del file. Dato che alcune fissano l'algoritmo implicitamente (l'assenza di un elenco esplicito è corretta), la regola "nessuna allowlist ⇒ unpinned" si applica solo dove la libreria se ne aspetta una esplicita, così una chiamata configurata correttamente non viene mai segnalata. | Linguaggio | Libreria | Segnala come unpinned l'assenza di allowlist? | Segnala sempre | | --------------------------- | ----------------------- | -------------------------------------------------------------------------------------- | ----------------------------------------------- | | **JavaScript / TypeScript** | jsonwebtoken, jose | Sì | `none`, mix asimmetrico+HMAC | | **Python** | PyJWT, python-jose | Sì (PyJWT la richiede, python-jose usa per impostazione predefinita `algorithms=None`) | `none`, `verify_signature: False` | | **Go** | golang-jwt | Sì (senza `WithValidMethods`) | `none`, `ParseUnverified` | | **Ruby** | ruby-jwt | Sì | `none`, `verify = false` | | **Java / Kotlin** | jjwt, nimbus | No (derivato dalla chiave) | `none`, un parser unsigned/`unsecured` | | **PHP** | firebase/php-jwt | No (`Key` porta con sé l'algoritmo) | `none` | | **Rust** | jsonwebtoken | No (`Validation` ne richiede uno) | `none`, `insecure_disable_signature_validation` | | **C#** | Microsoft.IdentityModel | No (parametri su più righe) | `none`, `RequireSignedTokens = false` | **Suggerimento** L'hook decide solo se l'algoritmo è fissato: i controlli su claim, chiavi e flussi restano valutazioni coperte dalla [specializzazione `federation`](https://lagune.ai/it-IT/docs/catalog). ## Domande frequenti ### Che cos'è l'algorithm confusion nei JWT? Un verificatore che legge l'algoritmo dall'header del token permette a un attaccante di sostituire RS256 con HS256 e firmare con la chiave pubblica. Fissare nel codice una allowlist di algoritmi solida lo impedisce, e l'hook jwt segnala una chiamata di verifica che non ne imposta nessuna o ne imposta una non sicura. --- # Hook network: valuta gli URL contro la SSRF > Valuta una o più destinazioni di richiesta contro la SSRF, direttamente dalla riga di comando. Canonico: https://lagune.ai/it-IT/docs/hooks/network Lingua: it-IT Originale: https://lagune.ai/docs/hooks/network Ultimo aggiornamento: 2026-11-03 L'hook `network` decide se la destinazione di una richiesta lato server è al sicuro dalla **SSRF** (una richiesta che può essere puntata verso servizi interni, metadati del cloud o host privati). È il motore deterministico dietro la [specializzazione `network`](https://lagune.ai/it-IT/docs/catalog), e puoi eseguirlo tu stesso. ## Come eseguirlo Passa ogni destinazione con `--url`. L'hook stampa una parola per destinazione, da leggere con la tabella qui sotto. **Una destinazione** ```bash npx lagune read network --url 'http://example.com/' # => safe npx lagune read network --url 'http://0x7f000001/' # => private-target ``` **Più destinazioni** Ripeti `--url` per valutare un'intera allowlist o denylist in una sola chiamata, un verdetto per riga, nell'ordine. ```bash npx lagune read network \ --url 'http://example.com/' \ --url 'http://[::1]/' \ --url 'http://allowed.com@evil.example/' # => safe # => private-target # => parser-divergent ``` Risolve l'host come fa la rete, così le forme codificate di un indirizzo interno non sfuggono: esadecimale, ottale, decimale senza punti, forma abbreviata, IPv6 e IPv4 mappato su IPv6 risultano tutte `private-target`. E dove un validatore approssimativo e il vero client leggerebbero host diversi, il verdetto è `parser-divergent`. ## Come leggere il verdetto | Verdetto | Significato | | ------------------ | ------------------------------------------------------------------------------------------------------------- | | `safe` | La destinazione si collega a un host pubblico, e un validatore approssimativo leggerebbe lo stesso host. | | `private-target` | L'host si risolve in un indirizzo privato, di loopback, link-local, non specificato o dei metadati del cloud. | | `parser-divergent` | Un validatore testuale approssimativo leggerebbe un host reale diverso da quello a cui si collega il client. | | `invalid url` | La stringa non è analizzabile come URL, quindi non c'è nulla da richiedere. | Solo `safe` è un via libera. Tratta `private-target`, `parser-divergent` e `invalid url` tutti come un blocco. ### Opzioni della CLI | Opzione | Valore | Descrizione | | ------- | ---------------- | ------------------------------------------------------------------------------------ | | `--url` | un URL o un host | Controlla una destinazione. Ripetila per controllarne diverse, un verdetto per riga. | Serve almeno un `--url`. La destinazione non è mai un argomento posizionale semplice, quindi non può essere scambiata per un flag. **Perché il valore di un flag** Ogni destinazione viene passata come valore di un flag, mai interpolata nel comando. Un valore con virgolette o backtick resta inerte e non può iniettare nulla nella shell. Racchiudilo sempre tra apici singoli, così la tua shell non lo espande prima. **Cosa non copre** L'hook è puro e non risolve mai il DNS, quindi due lacune a runtime restano fuori dal suo ambito: il **DNS rebinding** (un nome che risulta pubblico al controllo e interno al momento della richiesta) e le **catene di redirect** (un primo salto che passa e poi reindirizza verso l'interno). Chiudile risolvendo una sola volta e collegandoti all'indirizzo validato, e rifiutando i redirect. Associa i nomi di loopback riservati (`localhost` e la famiglia `.localhost`) a indirizzi interni senza alcuna risoluzione, ma qualsiasi altro nome DNS risulta `safe`, perché affermare che si risolve verso l'interno richiederebbe una risoluzione: a proteggerli è l'allowlist, ed è proprio ciò che questo controllo valida. **Suggerimento** È lo stesso controllo che la [specializzazione `network`](https://lagune.ai/it-IT/docs/catalog) esegue per dimostrare che un filtro delle destinazioni regge. ## Domande frequenti ### Come verifico se un URL è esposto alla SSRF? Esegui l'hook network. Valuta la destinazione di una richiesta e restituisce safe, private-target, parser-divergent o invalid url. Solo safe è un via libera. ### Che cos'è un URL parser-divergent? Un URL che parser diversi leggono in modo diverso, un classico aggiramento della SSRF. L'hook network lo segnala invece di consentirlo. --- # Hook regex: rileva i pattern ReDoS > Analizza una codebase alla ricerca di regex esposte al ReDoS, oppure valuta un singolo pattern, dalla riga di comando. Canonico: https://lagune.ai/it-IT/docs/hooks/regex Lingua: it-IT Originale: https://lagune.ai/docs/hooks/regex Ultimo aggiornamento: 2026-11-03 L'hook `regex` è il motore deterministico di sicurezza delle regex che la [specializzazione `regex`](https://lagune.ai/it-IT/docs/catalog) esegue, e puoi eseguirlo tu stesso. Funziona in due modalità con un solo comando: uno **scan** che analizza una codebase alla ricerca di pattern esposti al **ReDoS** e costruiti a runtime, e un **check** che valuta un singolo pattern che gli fornisci. ## Analizza una codebase Senza flag analizza l'intero progetto. `--dir` limita l'analisi a una directory, `--file` a un singolo file. Entrambi si ripetono e si combinano in un unico report, con ogni file elencato una sola volta anche quando più di un obiettivo lo copre. **Tutto il progetto** ```bash npx lagune read regex ``` **Una directory** ```bash npx lagune read regex --dir src/services ``` **Un singolo file** ```bash npx lagune read regex --file bin/import.pl ``` **Più obiettivi** ```bash npx lagune read regex --dir core --dir workers --file Sources/App/Router.swift ``` **Con un limite** `--limit` imposta la soglia ReDoS per l'analisi (predefinita 25), lo stesso limite che accetta la modalità check. Un limite più basso è più severo. ```bash npx lagune read regex --dir src/services --limit 15 ``` L'output è testo semplice, le cui intestazioni dicono come leggere ogni sezione. Una sezione viene mostrata solo quando ha dei rilievi. ```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 ``` Quando non trova nulla, stampa una sola riga. ```bash npx lagune read regex --dir src/clean # => no unsafe patterns found ``` ### Come leggere le sezioni | Sezione | Significato | | ------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `Vulnerable regular expressions found` | Pattern esposti al ReDoS, raggruppati per file con ogni pattern rientrato sotto, seguito tra parentesi dal motivo per cui non è sicuro e, quando li ha, dal suo ambito e dai suoi flag. Ogni riga è non sicura, quindi il verdetto non viene ripetuto. | | `Regular expressions the analysis could not settle (review manually)` | Pattern che l'analisi non è riuscita a definire entro il suo limite di lavoro, elencati nello stesso modo. | | `Dynamically built regular expressions (review manually by simulating a constructed regex)` | File che costruiscono una regex a partire da una variabile, una concatenazione o un'interpolazione. | | `Static regex wrapped in a constructor (use a literal instead)` | File che passano un semplice letterale stringa a un costruttore di regex dove un letterale regex è più semplice ed evita una compilazione a runtime. | La prima sezione è un rilievo di sicurezza. La seconda e la terza non sono rilievi di per sé: indicano codice che un controllo statico non può definire, quindi richiedono una lettura umana. La quarta è un suggerimento di chiarezza, non un rilievo di sicurezza. ### Opzioni della CLI | Opzione | Valore | Descrizione | | ----------- | ------------------------ | ----------------------------------------------------------------------------------------------------------------------------- | | `--pattern` | il sorgente di una regex | Controlla un pattern. Ripetila per controllarne diversi, un verdetto per pattern, nell'ordine. | | `--flags` | flag della regex | Controlla ogni `--pattern` con questi flag, come `im`. Si applica solo alla modalità check. | | `--dir` | una directory | Limita l'analisi a una directory. Si ripete e si combina con `--file`. | | `--file` | un file | Limita l'analisi a un singolo file. Si ripete e si combina con `--dir`. | | `--limit` | un intero non negativo | Imposta il limite di ripetizione ReDoS (predefinito 25). Si applica a entrambe le modalità. Un limite più basso è più severo. | Senza opzioni analizza l'intero progetto. `--pattern` è la modalità check e non si può combinare con `--dir` o `--file`. ### Linguaggi supportati L'analisi legge questi linguaggi, riconosciuti dall'estensione del file, ognuno con le sue regole, così un pattern di un linguaggio non viene mai testato con le regole di un altro. Tutto il resto viene saltato invece di essere analizzato con le regole sbagliate. | # | Linguaggio | Estensioni | | --- | --------------------------- | ------------------------------------------------------------------------------------------------------------ | | 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` | **Al meglio delle possibilità, non esaustivo** Legge il sorgente come testo, quindi non può giudicare un pattern costruito a runtime, e un pattern distribuito su più righe, nascosto dietro un alias o scritto in una forma che non riconosce può sfuggirgli. Considera le sezioni un solido punto di partenza, non un inventario completo, e continua a leggere il codice per ciò che non riescono a raggiungere. ## Controlla un singolo pattern Passa `--pattern` con il sorgente del pattern per valutarlo. L'hook stampa una parola: `safe`, `unsafe`, `undetermined` quando l'analisi raggiunge il suo limite di lavoro prima di definire il pattern, oppure `invalid regex`. Ripeti `--pattern` per valutarne diversi insieme, un verdetto per pattern, nell'ordine. **Un pattern** ```bash npx lagune read regex --pattern '(a+)+$' # => unsafe npx lagune read regex --pattern '^[a-z0-9_]{3,20}$' # => safe ``` **Più pattern** ```bash npx lagune read regex --pattern '(a+)+$' --pattern '^[a-z]+$' # => unsafe # => safe ``` **Con i flag** `--flags` controlla ogni `--pattern` della chiamata con i flag con cui viene eseguito, perché un flag cambia quali caratteri un pattern riconosce. ```bash npx lagune read regex --pattern '^(?:a|A)+$' # => safe npx lagune read regex --pattern '^(?:a|A)+$' --flags 'i' # => unsafe ``` **Con un limite** `--limit` imposta il limite di ripetizione (predefinito 25) e si applica a ogni `--pattern` della chiamata. Un limite più basso è più severo. ```bash npx lagune read regex --pattern 'a?a?a?' --limit 2 # => unsafe ``` **Perché un argomento tra apici** Ogni pattern viene passato come valore di un flag, mai interpolato nel comando. Un valore con virgolette o backtick resta inerte e non può iniettare nulla nella shell. Racchiudi sempre il pattern tra apici singoli, così la tua shell non lo espande prima. **Suggerimento** È lo stesso motore che esegue la [specializzazione `regex`](https://lagune.ai/it-IT/docs/catalog): lo scan avvia un passaggio ReDoS, il check conferma un pattern che fa emergere. ## Domande frequenti ### Come controllo una regex contro il ReDoS dalla CLI? Esegui npx lagune read regex --pattern ''. Restituisce safe, unsafe, undetermined o invalid regex. ### Come analizzo un intero progetto alla ricerca di regex non sicure? Esegui l'hook regex in modalità scan sulla codebase. Segnala i pattern esposti al ReDoS in 25 linguaggi supportati. --- # Hook secrets: rileva i segreti scritti nel codice > Analizza una codebase alla ricerca di credenziali scritte nel codice, dalla riga di comando. Canonico: https://lagune.ai/it-IT/docs/hooks/secrets Lingua: it-IT Originale: https://lagune.ai/docs/hooks/secrets Ultimo aggiornamento: 2026-11-03 L'hook `secrets` segnala le **credenziali compilate nel sorgente** invece che lette dall'ambiente. Si basa sulla **provenienza** (un letterale contro una lettura dall'ambiente), non sul contenuto del valore, quindi non ha bisogno di un catalogo esaustivo dei prefissi dei fornitori e non produce quasi falsi positivi. È il motore deterministico dietro la [specializzazione `secrets`](https://lagune.ai/it-IT/docs/catalog). Le firme dei formati dei fornitori, le credenziali nelle stringhe di connessione e un letterale associato a un identificatore dal nome di segreto sono **indipendenti dal linguaggio**: la stessa stringa si legge allo stesso modo in qualsiasi file. Le due euristiche che dipendono dalla sintassi, una lettura dall'ambiente con un valore predefinito scritto nel codice e un segreto che finisce in un sink di log, sono **consapevoli del linguaggio**, così un `console.log` di JavaScript non viene mai letto in un file Rust e `os.getenv("X", "default")` di Python viene riconosciuto per quello che è. ## Come eseguirlo ```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 ``` L'analisi stampa fino a due sezioni. **Hardcoded secrets found** è l'insieme dei rilievi (un valore predefinito scritto nel codice per una variabile d'ambiente dal nome di segreto, una credenziale incorporata in una stringa di connessione o un valore che corrisponde a un formato di fornitore selezionato), quindi l'hook esce con un codice diverso da zero. **Secret handling to review manually** è un insieme di piste: un semplice letterale associato a un identificatore dal nome di segreto (la sua provenienza si può stabilire, ma se il valore sia davvero un segreto no) e un valore dal nome di segreto che finisce in un sink di log o di risposta. Un'esecuzione pulita stampa `no hardcoded secrets found`. ### Opzioni della CLI | Opzione | Valore | Descrizione | | -------- | ------------- | ----------------------------------------------------------------------- | | `--dir` | una directory | Limita l'analisi a una directory. Si ripete e si combina con `--file`. | | `--file` | un file | Limita l'analisi a un singolo file. Si ripete e si combina con `--dir`. | Senza opzioni analizza l'intero progetto. ### Copertura dei linguaggi Il rilievo sul valore predefinito dell'ambiente e la pista sui sink di log leggono un insieme di forme per ogni linguaggio, quindi coprono i linguaggi qui sotto e restano in silenzio altrove. Gli altri tre segnali vengono eseguiti su **ogni** file. | Segnale | Linguaggi | | -------------------------------- | ------------------------------------------------------------------------------- | | Valore predefinito dell'ambiente | JavaScript/TypeScript, Python, Ruby, PHP, Kotlin, Java, Go (`cmp.Or`), Rust, C# | | Sink di log o di risposta | JavaScript/TypeScript, Python, Ruby, PHP, Java, Kotlin, Go, Rust, C, C++, C# | **È un problema di policy?** No. Riconoscere il formato di un segreto per avvisare che è finito in un commit è uno strumento difensivo standard, la stessa operazione che svolgono gitleaks, trufflehog e la push protection di GitHub. L'hook include firme di rilevamento (i **formati** pubblici dei token), mai un segreto reale, e verifica e spiega invece di esfiltrare. ## Domande frequenti ### Come evita i falsi positivi l'hook secrets? Si basa sulla provenienza, non sul contenuto del valore. I formati ad alta affidabilità (token dei fornitori, valori predefiniti dell'ambiente, stringhe di connessione) sono rilievi che escono con un codice diverso da zero. Un semplice letterale associato a un identificatore dal nome di segreto è una pista da confermare, e lo stesso identificatore letto da process.env non viene segnalato affatto. --- # Esempi di prompt per Lagune: automatizza il flusso Blue Team > Prompt di Lagune pronti da copiare: un'analisi in sola lettura, il flusso Blue Team completo e un audit Zero Trust, più il rilevamento limitato a un commit, al diff di un branch o di una PR, o a un incidente reale. Canonico: https://lagune.ai/it-IT/docs/examples/prompts Lingua: it-IT Originale: https://lagune.ai/docs/examples/prompts Ultimo aggiornamento: 2026-11-03 Prompt di Lagune pronti da copiare, da incollare direttamente nel tuo agente IA. ## 💧 Analisi superficiale Un'analisi in sola lettura che legge il codice per conto suo e segnala ogni falla con una correzione, senza eseguire il flusso Blue Team né scrivere nel tracciamento di Lagune. **Suggerimento** Funziona meglio in modalità di pianificazione e con un charter (`/lagune-charter`) definito. **🪼 Predefinito** | Aspetto | Compromesso | Livello | | -------------------- | ---------------------------------------------------------------------- | ------------------- | | **Impegno** | Un solo agente analizza e riferisce, senza sub-agenti. | 1/5 | | **Tempo** | Rapido. Un unico passaggio in sola lettura, non viene applicato nulla. | 2/5 | | **Consumo di token** | Moderato, condiviso. Tutta l'analisi avviene in un solo contesto. | 2/5 | ```md /lagune Sei un ricercatore di cybersicurezza con una profonda esperienza in sicurezza difensiva, e usi Lagune per migliorare le tue conoscenze e la tua precisione. Analizza il workspace per conto tuo e abbina a ogni falla che trovi una correzione concreta. È un'analisi a sé stante, non il flusso Blue Team: non eseguire detect, plan, harden o verify, e non scrivere nulla nel tracciamento di Lagune. Alla fine, elenca ogni falla che hai trovato, ciascuna con la sua gravità e una correzione concreta. ``` **🐬 Multi-agente** | Aspetto | Compromesso | Livello | | -------------------- | ---------------------------------------------------------------------------- | ------------------- | | **Impegno** | Un sub-agente per file, proporzionato alle dimensioni della tua codebase. | 2/5 | | **Tempo** | In parallelo per file, poi unito in un unico report. Sempre in sola lettura. | 3/5 | | **Consumo di token** | Più alto, ma isolato. Ogni sub-agente analizza nel proprio contesto. | 3/5 | ````md /lagune Sei un orchestratore di cybersicurezza che usa Lagune per enumerare, assegnare un sub-agente a ogni percorso e unire i loro report (tutto il contenuto viene letto dai sub-agenti). Devi delegare il compito ai sub-agenti in base alle dimensioni del progetto attuale: più grande è la codebase, più sub-agenti vanno avviati, tutti in parallelo, dando a ciascuno il prompt qui sotto: ```prompt /lagune Sei un ricercatore di cybersicurezza con una profonda esperienza in sicurezza difensiva, e usi Lagune per migliorare le tue conoscenze e la tua precisione. Analizza per conto tuo e abbina a ogni falla che trovi una correzione concreta. È un'analisi a sé stante, non il flusso Blue Team: non eseguire detect, plan, harden o verify, e non scrivere nulla nel tracciamento di Lagune. Alla fine, elenca ogni falla in , ciascuna con la sua gravità e una correzione concreta. ``` Alla fine, unisci tutti i report dei sub-agenti in un unico elenco di falle e correzioni ordinato per priorità. ```` **Avviso** Un'analisi rapida è un unico prompt ampio e non circoscritto, quindi alcuni agenti hanno più probabilità di rifiutarla o di interromperla a metà. Se il tuo si oppone, esegui invece il **flusso Blue Team** completo qui sotto: le sue fasi circoscritte e passo per passo hanno molte meno probabilità di essere bloccate. --- ## 🌊 Flusso di audit Blue Team automatico Esegue il [flusso completo dei comandi](https://lagune.ai/it-IT/docs/get-started/commands) dall'inizio alla fine senza fermarsi a chiedere input. **🪼 Predefinito** | Aspetto | Compromesso | Livello | | -------------------- | ------------------------------------------------------------------------------------------------------- | ------------------- | | **Impegno** | Un solo agente, senza sub-agenti, qualunque sia la dimensione della codebase. | 3/5 | | **Tempo** | Medio, ma meno accurato nelle codebase grandi. Ogni comando viene eseguito una volta, uno dopo l'altro. | 4/5 | | **Consumo di token** | Più basso, ma meno isolato. Tutti i comandi condividono lo stesso contesto. | 4/5 | ```md Esegui i seguenti comandi, uno alla volta: `/lagune-charter`, `/lagune-detect`, `/lagune-plan`, `/lagune-harden` e `/lagune-verify`. ## Ciclo Quando `/lagune-verify` boccia una o più correzioni, ripeti `/lagune-harden` e poi `/lagune-verify` finché tutti i rilievi non sono risolti correttamente. ## Importante - Non fermarti, non chiedere: in caso di dubbio, fai tutto in modalità "full". ``` **🐋 Multi-agente (deep scan)** | Aspetto | Compromesso | Livello | | -------------------- | ------------------------------------------------------------------------------------------------------------------------- | ------------------- | | **Impegno** | Il numero di sub-agenti è proporzionato alle dimensioni della tua codebase. | 5/5 | | **Tempo** | Più lungo, ma più accurato. Avvia più sub-agenti per rilevare, pianificare e mettere in sicurezza i rilievi in parallelo. | 5/5 | | **Consumo di token** | Più alto, ma più sicuro. Ogni sub-agente ha il proprio contesto isolato, senza condizionamenti. | 5/5 | ````md Esegui i seguenti comandi assegnando ciascuno a un sub-agente, uno alla volta (senza backtick, solo il comando): Prompt del sub-agente 1: `/lagune-charter` Prompt del sub-agente 2: `/lagune-detect` Prompt del sub-agente 3: `/lagune-plan` Prompt del sub-agente 4: `/lagune-harden` Prompt del sub-agente 5: `/lagune-verify` Nei comandi `/lagune-detect`, `/lagune-plan`, `/lagune-harden` e `/lagune-verify`, devi delegare il compito ai sub-agenti in base alle dimensioni del progetto attuale: più grande è la codebase, più sub-agenti vanno avviati. Per esempio: ```prompt /lagune-detect ``` ```prompt /lagune-plan ``` ```prompt /lagune-harden ``` ```prompt /lagune-verify ``` - Più agenti sullo stesso comando vanno avviati in parallelo. - Al termine di tutti i sub-agenti di `/lagune-detect`, esegui: ```prompt /lagune-detect unisci i rilievi equivalenti. Non cercare nuovi rilievi e non analizzare di nuovo la codebase. ``` ## Ciclo Quando `/lagune-verify` boccia una o più correzioni, ripeti `/lagune-harden` e poi `/lagune-verify` finché tutti i rilievi non sono risolti correttamente. ## Importante - Non fermarti, non chiedere: in caso di dubbio, fai tutto in modalità "full". ```` --- ## 🪄 Rilevamento circoscritto Punta [`/lagune-detect`](https://lagune.ai/it-IT/docs/commands/detect) su una parte del tuo progetto invece che su tutto. Descrivi l'ambito in linguaggio semplice (un commit, una pull request o una situazione reale) e mapperà solo i rilievi rilevanti per la sicurezza in quella parte. **Suggerimento** Tutto ciò che rileva qui è un rilievo normale, quindi puoi portarlo direttamente in `/lagune-plan`, `/lagune-harden` e `/lagune-verify`, limitandoti a quegli elementi. **📌 Da un commit** Dai a una serie di commit recenti il loro passaggio di sicurezza, limitato solo a ciò che hanno modificato, per esempio: ```prompt /lagune-detect Limita il rilevamento a tutto ciò che è cambiato dal commit `a1b2c3d`. ``` **🔀 Diff di un branch o di una PR** Rivedi la sicurezza di una pull request prima che venga unita, limitandoti al suo diff, per esempio: ```prompt /lagune-detect Limita il rilevamento alle modifiche che questo branch introduce rispetto a `main`. ``` **⛑️ Dopo un incidente** Descrivi con parole tue cosa è successo. Lagune legge la situazione, non un flag, e la trasforma in una ricerca mirata, per esempio: ```prompt /lagune-detect Qualche settimana fa il nostro sito ha avuto una fuga di dati. Non so esattamente come sia successo, e temo che ci sia ancora qualcosa di aperto che potrebbe far trapelare di nuovo i dati. Esamina il codice con attenzione, concentrati su ogni punto in cui i dati sensibili vengono letti, salvati o esposti, e mappa tutto ciò che potrebbe ancora essere una via d'uscita. Trattalo come un incidente reale, non come un'esercitazione. ``` --- ## 🚨 Audit Zero Trust Tratta l'intero workspace e ogni dipendenza come ostili: cerca interpreti, chiamate di rete, payload codificati e codice nascosto in punti improbabili per sfuggire agli scanner, poi si conclude con un verdetto sì o no sulla sicurezza d'uso del progetto. I prompt caricano direttamente le specializzazioni su cui si basa questo audit, qualunque siano le categorie del tuo progetto. Per il resto del catalogo che `/lagune` confronta, assicurati che il progetto usi **OWASP**, **AI/LLM** e la categoria del suo stack (ad es. **JavaScript**, **Python** e così via): ```bash npx lagune write add --categories owasp ai javascript ``` **Pericolo** Fai attenzione quando esegui nel tuo ambiente locale progetti provenienti da fonti non attendibili. Usa un ambiente isolato, come una **sandbox** (consigliata), una **VM** o simili, per evitare che codice malevolo colpisca il tuo sistema. **🪼 Predefinito** | Aspetto | Compromesso | Livello | | -------------------- | ------------------------------------------------------------------------------------------------------------- | ------------------- | | **Impegno** | Un solo agente analizza l'intero workspace, senza sub-agenti. | 2/5 | | **Tempo** | Medio. Un solo agente esamina in sequenza il codice e le sue dipendenze. | 3/5 | | **Consumo di token** | Moderato, ma condiviso. Le specializzazioni, il codice e le dipendenze si caricano tutti in un solo contesto. | 3/5 | ```md /lagune Sei un ricercatore di cybersicurezza con una profonda esperienza in sicurezza difensiva zero trust, e usi Lagune per migliorare le tue conoscenze e la tua precisione. Mappa l'intero workspace come una fonte non attendibile e un ambito potenzialmente malevolo. Ogni interprete, fetch, base64 e simili va trattato come una potenziale minaccia. Estendi la tua analisi alle dipendenze e alle sotto-dipendenze: un progetto può cercare di nascondere codice malevolo in un punto improbabile per sfuggire agli scanner. Specializzazioni obbligatorie (caricale una alla volta con `npx lagune read catalog `): - interpreter - secrets - llm - path Per essere chiari: ogni vulnerabilità mappata va trattata come una potenziale minaccia, senza eccezioni. Alla fine, dai un verdetto sul fatto che il progetto sia sicuro e affidabile da usare per me oppure no. ``` **🐋 Multi-agente (deep scan)** | Aspetto | Compromesso | Livello | | -------------------- | ------------------------------------------------------------------------------------------------------ | ------------------- | | **Impegno** | Un sub-agente per file, proporzionato alle dimensioni della tua codebase. | 5/5 | | **Tempo** | Più lungo, ma più accurato. I file vengono analizzati in parallelo, poi uniti in un unico verdetto. | 4/5 | | **Consumo di token** | Il più alto, ma il più sicuro. Ogni sub-agente legge le specializzazioni nel proprio contesto isolato. | 5/5 | ````md /lagune Sei un orchestratore di cybersicurezza che usa Lagune per enumerare, assegnare un sub-agente a ogni file e generare report (tutto il contenuto viene letto dai sub-agenti). Avvia un sub-agente per file, tutti in parallelo, dando a ciascuno il prompt qui sotto, limitato al suo file: ```prompt /lagune Sei un ricercatore di cybersicurezza con una profonda esperienza in sicurezza difensiva zero trust, e usi Lagune per migliorare le tue conoscenze e la tua precisione. Tratta come una fonte non attendibile e un ambito potenzialmente malevolo. Ogni interprete, fetch, base64 e simili va trattato come una potenziale minaccia. Estendi l'analisi a tutto ciò che importa, comprese le dipendenze e le sotto-dipendenze, dove può nascondersi codice malevolo per sfuggire agli scanner. Specializzazioni obbligatorie per ogni sub-agente (caricale una alla volta con `npx lagune read catalog `): - interpreter - secrets - llm - path Per essere chiari: ogni vulnerabilità mappata va trattata come una potenziale minaccia, senza eccezioni. Alla fine, dai un verdetto sul fatto che il progetto sia sicuro e affidabile da usare per me oppure no. ``` Alla fine, unisci tutti i report dei sub-agenti in un unico verdetto finale. ```` --- # Security-Driven Hardening: una convenzione per l'era dello sviluppo assistito dall'IA > La metodologia Security-Driven Hardening (SDH): una convenzione blue team sensibile al contesto per verificare e mettere in sicurezza il software sviluppato con l'aiuto dell'IA o in vibe coding. Canonico: https://lagune.ai/it-IT/docs/references/paper Lingua: it-IT Originale: https://lagune.ai/docs/references/paper Ultimo aggiornamento: 2026-11-03 - **Weslley Araújo** - **Articolo sulla metodologia, 2026.** --- ## Abstract Security-Driven Hardening (SDH) è una metodologia di sicurezza strutturata, guidata dall'IA ed esclusivamente difensiva, pensata per un'epoca in cui il software viene scritto sempre più spesso da agenti IA e da persone che non sono specialisti di sicurezza. Invece di seguire una checklist generica, SDH rileva prima cosa fa davvero un sistema (login, caricamento di file, pagamenti, esposizione di dati e così via) e poi guida il lavoro di sicurezza specifico per quel contesto. È governata da principi sicuri per impostazione predefinita, è interamente orientata alla difesa ed è espressa in linguaggio semplice, così che qualsiasi utente possa agire di conseguenza. Questo documento sostiene che SDH è una convenzione mancante, non un singolo strumento. Le conoscenze di sicurezza risiedono nella metodologia e nelle sue specializzazioni su richiesta, una base su cui ogni utente può costruire, e questo le permette di servire un principiante e un esperto attraverso lo stesso flusso. Due proprietà la distinguono dagli approcci spec-first precedenti `[1]`. SDH è **indipendente dallo stato**: si adatta a una directory vuota, a un progetto in corso, a una singola pull request o a una grande codebase legacy, in qualsiasi stack. E SDH **si può chiudere**: un rischio verificato come chiuso viene archiviato e tolto dall'intero flusso, così quel rilievo raggiunge uno stato definitivo e viene riaperto solo quando il codice cambia. SDH non sostituisce i professionisti della sicurezza né gli strumenti Blue Team specializzati. Estende le conoscenze dello sviluppatore stesso, e più uno sviluppatore capisce di sicurezza, più può guidarla. **Lagune** è l'implementazione di riferimento, e dimostra che la metodologia è realizzabile e portabile. SDH viene proposta come una convenzione che altri possono adottare. > **Parole chiave** > > sviluppo assistito dall'IA, sicurezza del software, sicurezza difensiva, spec-driven development, hardening di sicurezza, flussi di lavoro guidati da agenti, chiudibilità, sicurezza sensibile al contesto, conoscenza su richiesta, strumenti indipendenti dall'agente. --- ## I. Introduzione: la lacuna di sicurezza aperta dallo sviluppo assistito dall'IA Il software viene rilasciato sempre più spesso da persone, e da agenti IA, che non sanno riconoscere in modo affidabile un pattern non sicuro: un segreto esposto, un controllo di autorizzazione mancante, una query vulnerabile all'injection. Non sono rischi esotici. Rientrano tra le classi di rischio che dominano gli incidenti reali, documentate da anni in riferimenti pubblici `[6]`, `[7]`, e studi recenti riportano che una quota significativa del codice generato dall'IA viene rilasciata proprio con difetti di questo tipo `[8]`. Gli assistenti di programmazione con IA hanno reso il problema acuto permettendo a chi non è sviluppatore di rilasciare software reale, ma la lacuna è più ampia di qualsiasi singolo pubblico. La maggior parte dei progetti non riceve mai un passaggio di sicurezza specifico per ciò che fa davvero. L'ecosistema diventa più fragile a ogni decisione prematura del tipo "funziona, rilascialo". I consigli di sicurezza generici non colmano questa lacuna. Una checklist statica non è specifica per ciò che fa un sistema, quindi sommerge un piccolo progetto di voci irrilevanti e manca comunque il rischio che conta per quel progetto. Il problema non è la scarsità di conoscenze di sicurezza nel mondo. Il problema è abbinare la conoscenza giusta al sistema che l'utente ha davvero davanti, e farlo per qualcuno che potrebbe non sapere cosa chiedere. SDH risponde con un'unica inversione: **le conoscenze di sicurezza risiedono nella specifica e nelle sue specializzazioni su richiesta, una base su cui ogni utente può costruire**. La metodologia rileva il contesto, classifica i rischi che quel contesto comporta e guida le correzioni, così uno sviluppatore e chi non lo è vengono serviti attraverso lo stesso flusso. I rilievi e le raccomandazioni restano in linguaggio semplice, quindi sono utilizzabili qualunque sia la preparazione tecnica di chi legge. L'esperto non ne è limitato, ma potenziato, una dualità che sviluppiamo in `§VI`. > **Concetto chiave** > > **L'inversione centrale:** le conoscenze di sicurezza risiedono nella specifica e nelle sue specializzazioni su richiesta, una base su cui ogni utente può costruire. La metodologia scopre cosa fa il sistema, vi abbina il lavoro di sicurezza ed estende ciò che l'utente già sa. Prendi uno sviluppatore che dice a un assistente IA: "la mia app permette agli utenti di caricare una foto del profilo". Senza un passaggio di sicurezza, l'assistente produce codice funzionante che si fida in silenzio di tutto ciò che invia il client: il tipo di file dichiarato, il nome del file, la dimensione. Il caricamento va in produzione, e un file camuffato da immagine può contenere codice, un nome costruito ad arte può uscire dal percorso di archiviazione, un file troppo grande può esaurire le risorse del server. Niente di tutto questo si vede in una demo, quindi va in produzione. Lo stesso codice, passato attraverso SDH, si comporta in modo diverso. SDH rileva che il sistema accetta file dall'esterno (detect), lo traduce nei rischi che un caricamento comporta (triage), propone di controllare il tipo reale e la dimensione del file, di rinominarlo al salvataggio e di conservarlo dove il codice non può essere eseguito (remediate), poi legge il risultato e conferma che ogni controllo regga davvero (verify). Lo sviluppatore non ha mai dovuto conoscere l'espressione "unrestricted file upload". Gliel'ha fornita la metodologia. Questo documento offre i seguenti contributi: - Una definizione precisa di SDH come metodologia, indipendente da qualsiasi implementazione, con i suoi principi di progettazione (`§III`). - Un ciclo di vita difensivo in cinque fasi in cui la separazione dei compiti è essa stessa il contributo: il rilevamento non inventa mai, la pianificazione non legge mai il codice, una sola fase modifica il codice e la verifica non ammorbidisce mai il proprio giudizio (`§IV`). - La **chiudibilità** come presa di posizione metodologica: un singolo rilievo ha uno stato finale, non un ciclo infinito (`§V`). - La dualità dell'**estensore delle conoscenze dello sviluppatore**: un unico flusso che protegge il principiante e potenzia l'esperto (`§VI`). - **Specializzazioni non invocabili e prompt su richiesta**: conoscenze di sicurezza mirate che l'agente carica quando il contesto del progetto lo richiede, mai per impostazione predefinita (`§VII`). - **Indipendenza dallo stato** e **adattività non autoritaria**: SDH si adatta a qualsiasi stato di sviluppo e allo scenario, invece di imporre un ambito fisso (`§VIII`). - Una **modalità preventiva**: la stessa difesa eseguita mentre si costruisce il lavoro ordinario, così il codice nasce sicuro per impostazione predefinita e le fasi hanno meno da correggere (`§IX`). - Un confronto dedicato con lo Spec-Driven Development, la tradizione da cui SDH è nata e da cui poi si è distaccata (`§X`). - Le discipline di ingegneria che permettono alla metodologia di sopravvivere ai refactoring e di restare indipendente da qualsiasi agente: il tracciamento dell'identità per nome (`§XI`) e un veicolo indipendente dall'agente (`§XII`). --- ## II. Contesto e lavori correlati SDH si basa su lavori precedenti. Eredita una struttura collaudata dallo sviluppo spec-first guidato da agenti `[1]`, `[2]`, `[3]`: template, comandi slash consumati da un agente, un documento di governo e un agente che esegue le fasi. Reimplementa quella struttura con uno scopo difensivo. La discendenza è voluta, e uno dei principi di lavoro di SDH la nomina esplicitamente: costruire il flusso di lavoro a partire da una struttura collaudata, poi inquadrarlo per la sicurezza. SDH non è una checklist statica di raccomandazioni generiche. Una checklist sa moltissimo della sicurezza in generale e nulla del progetto che ha davanti. SDH ribalta questa enfasi. Dedica il suo primo sforzo al rilevamento, a scoprire cosa fa il sistema, e solo dopo attinge alla conoscenza che il rilevamento rende pertinente. SDH non sostituisce nemmeno le persone che si occupano di sicurezza o gli strumenti Blue Team specializzati. È un estensore delle conoscenze dello sviluppatore (`§VI`). Un team con una funzione di sicurezza dedicata dovrebbe mantenerla. SDH dà a quel team un veicolo strutturato, e a un team che non ne ha una dà una base difendibile. SDH si affianca anche agli scanner di sicurezza deterministici (analisi statica, linter) `[4]`, `[5]`. Quegli strumenti sono preziosi proprio perché sono deterministici e ripetibili. SDH si basa soprattutto sul ragionamento dell'agente, e scambia il determinismo rigoroso con la sensibilità al contesto. La metodologia non finge il contrario. Dove il determinismo conta, incorpora un motore deterministico all'interno del ragionamento (`§VII`): l'agente decide se vale la pena controllare un input, e un programma deterministico decide se quell'input è pericoloso. Il precedente più diretto è lo Spec-Driven Development (SDD), la famiglia di metodologie spec-first che porta avanti uno sviluppo a partire da una specifica eseguibile. Trattiamo l'SDD come una classe. La sua formulazione più chiara come metodologia per professionisti è il report di Piskala `[1]`, e il suo toolkit guidato da agenti più visibile è Spec Kit di GitHub `[2]`, con OpenSpec `[3]` come secondo strumento della stessa famiglia. Questi sono i riferimenti canonici per il confronto in `§X`. --- ## III. SDH: definizione e principi di progettazione **Security-Driven Hardening** è una metodologia di sicurezza strutturata e guidata dall'IA che rende una codebase più sicura portando avanti il lavoro a partire da una specifica eseguita dall'agente, invece che da correzioni improvvisate. Il nome si ispira ai **Blue Team**, i difensori nel campo della sicurezza. SDH riguarda la difesa, l'hardening e la verifica, mai l'attacco. > **Definizione** > > **Security-Driven Hardening (SDH):** una metodologia di sicurezza strutturata, guidata dall'IA ed esclusivamente difensiva che rileva prima cosa fa davvero un sistema, poi guida il lavoro di sicurezza specifico per quel contesto, governata da principi sicuri per impostazione predefinita ed espressa in linguaggio semplice. SDH è definita da un insieme di principi vincolanti. Ognuno è una regola, e ognuno offre all'utente una garanzia specifica. | Principio | La regola | Cosa garantisce all'utente | | --------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Sicuro per impostazione predefinita, in linguaggio semplice, per tutti allo stesso modo | Ogni impostazione predefinita, messaggio e correzione è sicuro fin da subito e comprensibile a chiunque legga, sviluppatore o no. Nessuna categoria di utenti è privilegiata. | Un principiante riceve una base sicura senza chiederla, e legge il risultato con parole sue. | | Sensibile al contesto più che generico | Ogni fase parte dal contesto rilevato in detect e agisce su ciò che il sistema fa davvero. | Le raccomandazioni si adattano al progetto, non a una checklist. Le conoscenze di sicurezza risiedono nella specifica e nelle sue specializzazioni su richiesta, ed estendono ciò che l'utente porta con sé. | | Flessibile più che rigido | Principi, requisiti e raccomandazioni sono punti di partenza. L'utente può riformulare, eliminare, aggiungere o restringere qualsiasi cosa. | La metodologia si piega al progetto e all'utente, e mai più rigidamente di quanto l'utente voglia. La flessibilità non indebolisce mai la base sicura per impostazione predefinita. | | Riconciliare, mai solo aggiungere | Gli artefatti sono documenti vivi, non log. Ogni esecuzione ricontrolla ogni voce: mantiene ciò che regge, riscrive ciò che è cambiato, rimuove ciò che non vale più. | Il registro riflette sempre il presente, quindi non degenera mai in un arretrato superato. | | Solo difesa | SDH verifica, mette in sicurezza e controlla. Non produce mai strumenti offensivi, exploit per uso malevolo o tecniche di elusione del rilevamento per nuocere. | La metodologia non può essere trasformata in un'arma. I contenuti a doppio uso compaiono solo in un contesto chiaramente difensivo. | | Spec-first, guidato da agenti, orientato alla sicurezza | Il flusso di lavoro è costruito a partire da template, comandi, un charter di governo e un agente che esegue le fasi. | Una struttura di sviluppo collaudata, riadattata perché sia l'agente a svolgere il lavoro di sicurezza sostanziale. | **Tabella 1.** I principi di progettazione di SDH e la garanzia che ognuno offre all'utente. Questi principi non sono ornamentali. Sono i vincoli che ogni fase descritta qui sotto deve rispettare, e la discussione in `§XV` vi ritorna per segnare i limiti della metodologia. Il resto del documento sviluppa nove pilastri con un nome. Sono le parti che chi legge dovrebbe riuscire a tenere a mente, e quelle che un altro team dovrebbe reimplementare per poter dire di fare SDH. | Pilastro | Cosa offre | Sezione | | ------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- | | L'inversione sensibile al contesto | Le conoscenze di sicurezza risiedono nella specifica e nelle sue specializzazioni su richiesta, così un principiante e un esperto condividono un unico flusso. | `§I`, `§VI` | | Il ciclo di vita difensivo in cinque fasi | Separazione dei compiti: policy, detect, triage, remediate, verify, ognuna con un solo compito. | `§IV` | | La chiudibilità | Un rilievo ha uno stato finale, non un ciclo infinito. Il lavoro chiuso viene archiviato. | `§V` | | La dualità dell'estensore delle conoscenze dello sviluppatore | Un unico flusso che protegge il principiante e potenzia l'esperto, senza mai sostituire nessuno dei due. | `§VI` | | Prompt su richiesta, conoscenza non invocabile | La conoscenza di sicurezza pertinente viene caricata per ciò che è il progetto, mai per impostazione predefinita. | `§VII` | | Indipendenza dallo stato e adattività non autoritaria | Si adatta a qualsiasi stato di sviluppo in qualsiasi stack, e allo scenario invece di imporre un ambito. | `§VIII` | | La modalità preventiva | La stessa difesa agisce mentre si costruisce il nuovo lavoro, così il codice nasce sicuro per impostazione predefinita. | `§IX` | | Il tracciamento dell'identità per nome | Un rilievo resta un unico elemento attraverso le fasi, e una rinomina rompe il collegamento in un solo punto. | `§XI` | | Il veicolo indipendente dall'agente | Il valore di sicurezza viene scritto una sola volta e non dipende da alcun agente o stack. | `§XII` | **Tabella 2.** I nove pilastri di SDH e dove viene sviluppato ciascuno. --- ## IV. Il flusso Blue Team in cinque fasi SDH struttura il lavoro come un ciclo di vita difensivo in cinque fasi (Figura 1). Ogni fase è orientata alla difesa, ognuna si basa sulla precedente, e le fasi seguono la reale attività di un Blue Team: stabilire una policy, rilevare, classificare, porre rimedio, verificare. ```mermaid flowchart TB charter["1 · charter (policy)
legge: il progetto, e la descrizione dell'utente se fornita
scrive: il charter
i principi indicano il rischio che prevengono, in linguaggio semplice"] detect["2 · detect (detect)
legge: il codice dell'utente
scrive: la mappa di detect
rilevare, non inventare: registrare solo ciò che il codice sostiene"] plan["3 · plan (triage)
legge: la mappa di detect, mai il codice
scrive: il piano di difesa
ogni correzione punta a qualcosa che detect ha davvero mappato"] harden["4 · harden (remediate)
legge: il piano di difesa, e il codice che tocca
scrive: il codice, e il registro di hardening
l'unica fase che modifica il codice, una correzione alla volta, la modifica minima che regge"] verify["5 · verify (verify)
legge: il codice, e il registro di hardening
scrive: ogni verdetto aperto sul registro di hardening
il confronto tra codice e registro, statico, mai ammorbidito"] charter --> detect --> plan --> harden --> verify verify -.->|"bocciata: lavoro riaperto per harden,
riapplicato in base al motivo registrato"| harden verify -.->|"chiusura: archivia ciò che ha dimostrato chiuso
in tutta la catena,
una riga nello storico"| detect ``` **Figura 1.** Il flusso in cinque fasi: cosa legge ogni fase, cosa scrive e la sua invariante portante. Verify guida entrambi i ritorni: un controllo bocciato riapre harden, e un rilievo dimostrato chiuso viene archiviato in tutta la catena, con una riga nello storico. La separazione dei compiti è il contributo. Dato che ogni fase ha un solo compito, una modalità di guasto resta confinata in un punto, e chi legge può fidarsi di ciò che ogni artefatto dichiara. > **Concetto chiave** > > **Applicata non significa verificata:** harden registra che una correzione è stata applicata. Verify la verifica confrontando il codice con quel registro, e il verdetto non viene mai ammorbidito per farlo coincidere con il registro. Un controllo può essere presente nel codice e lasciare comunque raggiungibile il rischio, e allora il verdetto onesto è "Risk not closed". ### charter (policy) Il charter stabilisce i principi di sicurezza del progetto, le regole che ogni fase successiva deve rispettare. È il livello di governo, una sorta di controllo in fase di compilazione della postura di sicurezza del progetto. Ogni principio ha un nome chiaro, una regola non negoziabile che si può verificare sul codice e una riga `Why:` che indica il rischio che previene, non solo la correzione. Il charter legge sempre il progetto stesso (i suoi manifest, la sua struttura e le sue dipendenze), e la descrizione dell'utente, quando c'è, è una direzione che la lettura poi allarga oltre ciò che l'utente ha nominato. Senza descrizione, il progetto è l'unica fonte. Le due si sommano invece di competere, e il charter registra la policy a cui il progetto dovrebbe attenersi, non lo stato del suo codice. Chi non è sviluppatore dovrebbe poterlo leggere e capire sia la regola sia il rischio. ### detect (detect) Detect legge il codice e mappa ciò che il sistema fa davvero e che ha un peso per la sicurezza. L'istruzione guida è "rilevare, non inventare": registrare solo ciò che il codice sostiene, con le evidenze di cui hanno bisogno le fasi successive. Detect è neutrale. Non costringe i suoi rilievi ad adattarsi al charter, perché confrontare i rischi con le regole del charter è compito della fase plan. Ogni rilievo ha tre parti: cos'è (descrizione in linguaggio semplice), perché conta (il rischio, non solo il fatto) e l'evidenza (la funzione o la route in cui si trova). L'evidenza non contiene alcun percorso di file. Il percorso si trova solo nella mappa di tracciamento (`§XI`), così la prosa non contiene mai un percorso che possa diventare obsoleto. ### plan (triage) Plan trasforma ogni rilievo in una correzione, indicata con la sua classe di rischio (citando i riferimenti consolidati, CWE e OWASP, dove la sostengono) e legata al principio del charter che la correzione rispetta. La priorità (Critical, High, Medium, Low) non è una scelta libera: plan valuta ogni rilievo con il metodo Base ed Environmental di CVSS v4.0, quindi la fascia è il punteggio espresso a parole, giustificato da una riga in linguaggio semplice su esposizione e posta in gioco, e due esecuzioni producono lo stesso ordine. Il vettore è l'ancora precisa per un esperto, la fascia e la sua giustificazione la stessa valutazione che chiunque può seguire. Plan lavora solo a partire dalla mappa di detect e non legge mai il codice. È un vincolo voluto, non un limite: obbliga ogni correzione a puntare a qualcosa che detect ha davvero rilevato. Se un ambito non è mai stato mappato, plan si ferma e rimanda l'utente a detect invece di tirare a indovinare. ### harden (remediate) Harden è l'unica fase che modifica il codice, quindi procede con cautela. Se una modifica richieda l'approvazione dell'utente dipende dall'agente e dalla modalità di permessi in cui viene eseguito, quindi harden non aggiunge alcun passaggio di conferma proprio. Applica una correzione alla volta, prima le dipendenze, poi la priorità più alta, così ogni modifica resta piccola, revisionabile e facile da annullare. Non indebolisce mai un controllo esistente per far quadrare una nuova correzione, e non viola mai un principio del charter. Se una correzione entrasse in conflitto con un principio, harden si ferma e fa emergere il conflitto invece di applicarla. Ogni blocco viene registrato come Applied, Partial o Blocked. "Applicata non significa ancora verificata", ed è la questione di cui si occupa la fase successiva. ### verify (verify) Verify verifica ogni controllo applicato leggendo il codice e confrontandolo con ciò che harden ha registrato. La verifica è proprio quel confronto, codice contro registro, ed è statica: conferma che un controllo è presente e corretto nel codice, non che il controllo regga sotto attacco su un sistema in esecuzione. Quel controllo a runtime, del tipo che esegue attacchi reali o simulati contro il sistema in produzione, è fuori ambito per scelta progettuale. Verify restituisce uno di tre verdetti: Risk closed, Risk not closed o Cannot tell from the code. Non produce alcun artefatto proprio: harden e verify condividono il registro di hardening, harden possiede ciò che è stato fatto e verify il verdetto e il suo motivo, e nessuno dei due scrive mai nei campi dell'altro. Un controllo bocciato è lavoro riaperto per harden, la cui esecuzione successiva considera il verdetto prevalente sulla propria lettura del codice e riapplica la correzione sulla lacuna esatta indicata dal motivo. Verify si fida del codice più che del registro, perché un registro può dichiarare più di quanto il codice offra. È in sola lettura sul codice dell'utente, e non ammorbidisce mai un verdetto per farlo coincidere con il registro. Un controllo può essere presente e lasciare comunque il rischio raggiungibile per un'altra via, e in quel caso il verdetto onesto è "Risk not closed". Se, durante la lettura, verify nota un problema di sicurezza che la mappa di detect non ha mai coperto, non inventa un verdetto, perché rilevare è compito di detect: fa emergere il problema e rimanda l'utente a detect, così il rilievo entra attraverso lo stesso flusso invece di aggirarlo. > **Filo conduttore: il caricamento di file.** Un singolo rilievo mostra la spina dorsale dall'inizio alla fine. > > - **detect** lo trova: il sistema accetta file dagli utenti, e l'handler del caricamento si fida del tipo MIME inviato dal client senza controllare il tipo reale del file. _Perché conta:_ un file camuffato da immagine può nascondere codice malevolo. > - **plan** decide la correzione, priorità **Critical**, nel rispetto del principio "Ogni input è non attendibile finché non viene validato": controllare il tipo reale e la dimensione del file, rinominarlo al salvataggio e conservare i caricamenti dove non possono essere eseguiti come codice. > - **harden** la applica, stato **Applied**: ora l'handler rileva il tipo reale dal contenuto, impone un limite di dimensione, rifiuta tutto ciò che è inatteso, rinomina al salvataggio e conserva dove il codice non può essere eseguito. > - **verify** legge l'handler, lo confronta con il registro e restituisce **Risk closed**: il codice fa esattamente ciò che dichiara il registro. > > Lo stesso nome del rilievo attraversa la mappa di detect, il piano e il registro di hardening, e verify agisce su quel registro con lo stesso nome: un verdetto aperto viene scritto nel blocco del rilievo, e un rilievo dimostrato chiuso viene archiviato (`§V`). Quel nome condiviso è la sua identità (`§XI`). --- ## V. Chiudibilità: un rilievo ha uno stato finale La maggior parte degli strumenti di sicurezza lascia all'utente un arretrato che non fa che crescere. SDH adotta una posizione diversa: **un rilievo si può chiudere, quindi ha uno stato finale invece di vivere in un arretrato infinito** (Figura 2). Questo deriva direttamente dal principio di riconciliazione. > **Definizione** > > **Chiudibilità:** un rischio verificato come chiuso viene archiviato e tolto dall'intero flusso, così quel rilievo raggiunge uno stato definitivo e viene riaperto solo quando il codice cambia. Un rilievo ha uno stato finale, anche se il programma di sicurezza in sé resta continuo. Gli artefatti di SDH sono documenti vivi, non log. Ogni volta che una fase viene rieseguita, ricontrolla ogni voce esistente rispetto alla verità attuale e fa una di tre cose: mantiene ciò che è ancora valido, riscrive ciò che è cambiato o rimuove ciò che non vale più. Un rilievo che il codice mostra ormai risolto viene semplicemente rimosso. Il registro di lavoro riflette il presente, non il passato. La chiusura è quella stessa riconciliazione che arriva alla sua conclusione. Quando verify verifica che un rischio è chiuso, archivia il rilievo in tutto il flusso: la mappa di detect, il piano, il registro di hardening e la mappa di tracciamento. Per questo verify è l'unica fase che scrive negli artefatti delle altre fasi: è la fase che chiude il cerchio. Mentre il rilievo lascia la catena, l'archiviazione lo distilla in una breve voce di un registro storico che vive fuori dalla catena di lavoro e non viene mai rielaborato. È questo il confine tra sparire e chiudersi: un rilievo che la riconciliazione ha rimosso perché ha smesso di essere vero non lascia nulla dietro di sé, mentre un rilievo dimostrato chiuso si guadagna la sua riga nello storico. Un rilievo archiviato è poi assente da ogni artefatto di lavoro, e questa assenza è attesa, non una catena rotta. ```mermaid stateDiagram-v2 direction TB [*] --> OPEN: detect rileva OPEN --> Plan: plan Plan --> Harden: harden Harden --> Verify: verify Verify --> StoodDown: Risk closed StoodDown --> SETTLED SETTLED --> OPEN: modifiche al codice riaprono un rilievo Plan: plan Harden: harden Verify: verify StoodDown: ARCHIVIATO · una riga nello storico ``` **Figura 2.** La macchina a stati della chiudibilità. Un rilievo passa da OPEN ad ARCHIVIATO a SETTLED, e si riapre solo quando il codice cambia. Quando tutto ciò che rientra nell'ambito è archiviato, il ciclo è a riposo, e lo stato di riposo ha una forma concreta: un artefatto il cui ultimo rilievo è stato chiuso viene rimosso per intero, quindi una catena completamente chiusa lascia solo il charter e lo storico, la policy e la prova. Il ciclo si riapre solo quando il codice cambia. La metodologia dà a ogni rilievo una fine definita, ed è esattamente ciò che un arretrato infinito non può fare. --- ## VI. La dualità dell'estensore delle conoscenze dello sviluppatore SDH non sostituisce le persone, e non sostituisce gli strumenti Blue Team specializzati. **Estende le conoscenze dello sviluppatore stesso**. Più uno sviluppatore capisce di sicurezza, più precisamente può guidare il flusso, e più autonomia ha. Uno sviluppatore che ne capisce poco riceve comunque un risultato sicuro, perché la modalità automatica lo tutela. L'inversione di `§I`, le conoscenze di sicurezza che risiedono nella specifica, vale in entrambe le direzioni. Per il principiante è protezione: non ha bisogno di sapere cosa chiedere, perché la specifica propone. Per l'esperto è potenziamento: la stessa specifica gli permette di indirizzare il flusso con precisione invece di lavorare contro una checklist fissa. Ogni fase porta questa dualità nel proprio funzionamento (Figura 3). Eseguita senza input, agisce sull'intero ambito per conto dell'utente. Con un'indicazione, la stessa fase si restringe esattamente a ciò su cui l'utente l'ha puntata. ```mermaid flowchart TB inversion["un'inversione, due direzioni:
le conoscenze di sicurezza risiedono nella specifica"] inversion --> auto["modalità automatica (nessun input)
la fase propone e agisce
sull'intero ambito"] inversion --> directed["modalità guidata (con input)
la fase si restringe esattamente
a ciò su cui l'utente l'ha puntata"] auto --> novice["il principiante, protetto:
un risultato sicuro senza
sapere cosa chiedere"] directed --> expert["l'esperto, potenziato:
il flusso indirizzato con precisione,
non una checklist fissa"] novice -.-> phases["le stesse cinque fasi servono entrambi:
charter · detect · plan · harden · verify"] expert -.-> phases ``` **Figura 3.** La dualità dell'estensore delle conoscenze dello sviluppatore. Un'unica inversione serve due pubblici: la modalità automatica protegge il principiante e la modalità guidata potenzia l'esperto, attraverso le stesse cinque fasi. Le specializzazioni su richiesta (`§VII`) rendono esplicita la dualità nel loro stesso testo. Ognuna dice all'agente che la sua conoscenza "estende il tuo giudizio" e di continuare a ragionare oltre ciò che la specializzazione fornisce. La conoscenza è un pavimento, non un soffitto. È questo che serve entrambi i pubblici nell'equilibrio voluto dal documento: la comunità degli sviluppatori ottiene uno strumento sostanziale, e il professionista Blue Team ottiene un veicolo strutturato che non finge di fare il suo lavoro al posto suo. --- ## VII. Specializzazioni non invocabili e prompt su richiesta È lo schema più innovativo della metodologia. SDH porta conoscenze di sicurezza mirate sotto forma di specializzazioni che si caricano **solo su richiesta**, ed è l'agente stesso a decidere quali caricare, abbinandole al contesto del progetto. Lo chiamiamo **prompt su richiesta**: un modo per l'agente di scegliere quale conoscenza attivare in base all'ambito del progetto in cui si trova, invece di eseguire ogni controllo per impostazione predefinita. Le specializzazioni sono evolutive, e ognuna può cambiare o essere sostituita in qualsiasi momento. Il contributo è lo schema, non le specializzazioni in sé. > **Definizione** > > **Prompt su richiesta:** l'agente seleziona quale conoscenza di sicurezza attivare confrontandola con l'ambito del progetto che ha davanti, così la conoscenza pertinente viene richiamata per ciò che il progetto è davvero, invece di eseguire ogni controllo per impostazione predefinita. > **Definizione** > > **Specializzazione non invocabile:** un'unità di conoscenza di sicurezza mirata e indipendente dal linguaggio per un singolo contesto, come il caricamento di file o il codice che gira nel browser. Verifica e spiega, non riscrive mai il codice e non produce mai un input di attacco. Non è un comando: si carica quando il contesto che copre rientra nell'ambito, o quando un prompt la richiede per nome. Ogni specializzazione indica le forme più sicure per i rischi che copre e dice all'agente come agire su un rilievo in ogni fase che la utilizza: come giudicarlo nel rilevamento, come applicarne la correzione in sicurezza nel rimedio e come dimostrarla nella verifica. Il tratto distintivo è che una specializzazione è **non invocabile da sola**: non è un comando, e all'interno del flusso è una corrispondenza a caricarla. La fase di rilevamento elenca il catalogo una volta, confronta il contesto del progetto con ciò che copre ogni voce e carica solo le specializzazioni il cui contesto è presente nell'ambito. Le fasi successive riutilizzano quell'elenco invece di rielencare, così un'unica corrispondenza serve l'intera catena, e la modalità preventiva (`§IX`) esegue la stessa corrispondenza sul lavoro che sta per essere costruito. Una specializzazione il cui contesto è assente viene saltata, e il salto deve essere giustificato quanto il caricamento: ogni voce del catalogo riceve un verdetto esplicito, applicata o saltata con il motivo ricavato dal codice, così una vaga impressione di irrilevanza non prende mai il posto dell'assenza. Non trovarne nessuna applicabile è un esito valido. Il catalogo è fatto di dati, e la crescita è un file di conoscenza più una riga di catalogo, mai un nuovo comando. Le specializzazioni integrate sono raggruppate in categorie, come OWASP, un linguaggio o le integrazioni di IA, e il catalogo usato da un progetto contiene le specializzazioni integrate delle categorie scelte più le sue specializzazioni. Il progetto registra quella scelta insieme al resto del suo stato, così tutto il team lavora sullo stesso catalogo. È lo stesso principio di sensibilità al contesto delle fasi, applicato alla conoscenza: la conoscenza pertinente viene richiamata per ciò che il progetto è davvero, invece di eseguire ogni controllo per impostazione predefinita. La stessa proprietà permette all'utente, non solo al maintainer, di far crescere il catalogo: una fonte o un tema di sicurezza fornito dall'utente viene distillato in una nuova specializzazione che appartiene al progetto, entra nel suo catalogo qualunque siano le categorie e si carica esattamente come una integrata, sostituendo quella integrata con lo stesso nome. Anche scrivere una specializzazione è un'attività esclusivamente difensiva e rispetta lo stesso confine che le specializzazioni fanno valere: la descrizione di un attacco può essere la fonte, ma la specializzazione che ne deriva verifica e spiega, e non emette mai un exploit funzionante. Così l'inversione di `§I`, l'intelligenza che risiede nella specifica, si estende al catalogo stesso, che l'utente può approfondire per il proprio contesto senza scrivere codice. Un breve esempio illustra il prompt su richiesta. Detect legge una cartella di codice che gira nel browser. Abbina quel contesto nel catalogo, carica la specializzazione che lo copre e fa emergere un rilievo lato client attraverso i normali passi di detect. Le specializzazioni il cui contesto è assente da questo ambito non corrispondono, quindi non si caricano mai, e ognuna viene registrata come saltata. È stato il progetto a decidere quale conoscenza fosse pertinente, non una configurazione fissa. Il determinismo compare proprio dove conta. Una specializzazione può portare con sé un controllo deterministico, non solo prosa: dove una classe di rischio ha una procedura di decisione netta, un piccolo programma restituisce un verdetto fisso per un dato input, per esempio un breve insieme di parole come `safe`, `unsafe` o `invalid input`. Alcune classi di rischio si possono decidere in modo deterministico esattamente così, con un corpus di lavori precedenti alla base della procedura di decisione `[9]`, `[10]`, `[11]`. Il controllo valuta i candidati forniti dall'agente oppure analizza l'ambito per trovarli da solo, e in entrambi i casi è il controllo, non l'agente, a restituire il verdetto. Una specializzazione abbastanza universale può essere contrassegnata come obbligatoria nel catalogo e viene allora sempre applicata, con il suo controllo eseguito sull'intero ambito. È l'unico caso in cui la conoscenza si carica senza una corrispondenza di contesto, ed è dichiarato nei dati del catalogo, mai deciso dall'agente sul momento. È qui che SDH ancora il ragionamento dell'agente a qualcosa di ripetibile, senza fingere che l'intero flusso sia deterministico. Infine, le specializzazioni sono **separabili**. Dato che la conoscenza sta in piedi da sola, un utente può eseguirne una direttamente in un prompt che non ha nulla a che fare con il flusso SDH completo, tenendo la sicurezza accanto allo sviluppo ordinario. Una specializzazione con un controllo deterministico può, per esempio, vagliare ogni candidato prodotto durante la normale scrittura del codice e tenere solo quelli sicuri. Questa separabilità è uno dei motivi per cui SDH si adatta a così tante situazioni, che sono l'oggetto di `§VIII`, e la sua espressione completa è la modalità preventiva (`§IX`), in cui la stessa conoscenza protegge lo sviluppo ordinario dall'inizio alla fine. --- ## VIII. Indipendenza dallo stato e adattività non autoritaria Due proprietà separano SDH dalle metodologie di specifica rigide. ### Indipendenza dallo stato > **Definizione** > > **Indipendenza dallo stato:** la metodologia non dipende dallo stato di sviluppo. Si adatta a una directory vuota, a un progetto in corso, a una singola pull request o a una grande codebase legacy, in qualsiasi stack, perché scopre il punto di partenza leggendolo. Ogni fase funziona allo stesso modo, che il progetto sia nuovo di zecca o esista già. Il charter deduce i principi da qualunque codice sia presente. Detect mappa qualunque codice ci sia, anche se è pochissimo. Non c'è alcun punto di partenza presupposto. ### Adattività non autoritaria > **Definizione** > > **Adattività non autoritaria:** la metodologia si adatta allo scenario invece di imporre un ambito fisso che l'utente deve seguire. Quando l'utente non sa cosa dire, legge l'ambiente in cui è stata invocata, genera contesto e pone le domande che orientano ciò che farà dopo. La modalità di proposta del charter è il caso più chiaro: SDH ricava un charter sicuro per impostazione predefinita analizzando il progetto, chiedendo all'utente solo quando una lacuna cambia davvero il risultato, poi lo scrive e presenta ogni principio in linguaggio semplice con il rischio che previene. Il charter è un documento vivo che l'utente rielabora rieseguendolo, non un contratto subordinato a una richiesta di approvazione, quindi non richiede mai all'utente di sapere cosa chiedere. Questa adattività si manifesta come sensibilità alla forma dell'input: la stessa fase legge ciò che ha ricevuto e sceglie una modalità (Figura 4). Un file nel prompt, un rilievo dall'elenco, un timore, una missione mirata contro un punto debole noto o la richiesta di un'analisi completa a tappeto: ognuno risponde al bisogno dell'utente, perché il flusso è non autoritario per scelta progettuale. Niente di tutto questo indebolisce la base sicura per impostazione predefinita. La flessibilità plasma il modo in cui la base viene applicata, non la abbassa mai. ```mermaid flowchart TB shape["la fase legge la forma
di ciò che ha ricevuto"] shape --> none["nessun input"] shape --> paths["uno o più percorsi"] shape --> concern["una preoccupazione descritta"] shape --> finding["un rilievo con nome"] shape --> band["una fascia di priorità"] none --> auto["la modalità automatica:
proporre, o analizzare
l'intero ambito"] paths --> focus["concentrarsi solo su quei
file o directory"] concern --> scoped["limitarsi a quella
sola preoccupazione"] finding --> item["agire su quel singolo
elemento tracciato"] band --> priority["agire solo su Critical,
High, Medium o Low"] ``` **Figura 4.** Adattività non autoritaria. La stessa fase legge la forma del suo input e sceglie una modalità, così l'ambito è sempre dell'utente, mai imposto. --- ## IX. La modalità preventiva universale: la stessa difesa mentre si costruisce il lavoro SDH porta con sé una modalità complementare: lo sviluppo ordinario svolto con la stessa difesa attiva mentre il codice viene scritto. L'utente chiede il lavoro in sé, una pagina di login, un caricamento, un endpoint, e la metodologia protegge lo sviluppo mentre avviene, così il risultato è sicuro per impostazione predefinita nel momento in cui arriva, invece che dopo un successivo passaggio di hardening. > **Definizione** > > **La modalità preventiva:** lo sviluppo ordinario eseguito sotto il livello di governo e la conoscenza di SDH. Il charter vincola lo sviluppo, le specializzazioni pertinenti a ciò che sta per essere creato si caricano su richiesta, e il risultato viene confrontato esattamente con la difesa usata prima che il lavoro sia considerato concluso. La modalità riutilizza ogni elemento che le fasi già portano con sé, puntato su codice che non esiste ancora. Il rilevamento del contesto passa dal codice all'intento: l'agente ragiona su ciò che sta per costruire e sui confini che quel lavoro attraversa (un login implica credenziali, una sessione e input dall'esterno), ed è con quel ragionamento che viene confrontato il catalogo delle conoscenze. Il prompt su richiesta (`§VII`) si generalizza qui: il contesto si può rilevare nel piano per il codice, non solo nel codice che esiste. Il charter governa come sempre, e una richiesta che violerebbe un principio viene fatta emergere come conflitto, mai costruita. La difesa viene applicata in linea, nel momento in cui ogni parte viene scritta, validando al confine e scegliendo il costrutto sicuro fin dalla prima volta, così una versione funzionante ma non sicura non esiste mai e non c'è nulla da correggere. La modalità finisce dove inizia verify. Prima che il lavoro sia considerato concluso, chi lo costruisce confronta il proprio risultato con la difesa che ha usato: il controllo deve trovarsi sul percorso del rischio, non accanto, deve essere completo e, dove una specializzazione porta con sé un controllo deterministico, il verdetto del controllo prevale sulla lettura dell'agente stesso. Una lacuna trovata qui viene chiusa come parte dello stesso lavoro, perché finire il lavoro significa finirlo in sicurezza. Ciò che la modalità rifiuta è voluto quanto ciò che fa. Costruisce solo ciò che è stato chiesto e non verifica nulla di ciò che sta intorno: verificare ciò che esiste spetta alle fasi. Non scrive alcun artefatto e non traccia alcun rilievo, perché un rilievo è un rischio individuato in ciò che esiste, e lo scopo di questa modalità è che la versione non sicura non arrivi mai. Le due direzioni si completano a vicenda: le fasi chiudono ciò che c'è già (`§V`), e la modalità preventiva impedisce al nuovo lavoro di riaprirlo. Una catena a riposo resta a riposo non perché lo sviluppo si sia fermato, ma perché ciò che si costruisce mentre riposa viene costruito già difeso. --- ## X. Security-Driven Hardening a confronto con lo Spec-Driven Development Security-Driven Hardening (SDH) è nata dalla base dello Spec-Driven Development (SDD) e poi se n'è distaccata nettamente. L'eredità strutturale è reale e riconosciuta: spec-first, guidato da agenti, un documento di governo e una serie di comandi a fasi che l'agente esegue. SDH riutilizza quella struttura deliberatamente. Ciò che cambia è lo scopo, il modello di autorità, lo stato presupposto e la condizione finale. Trattiamo l'SDD come una classe, usando il report di Piskala `[1]` come formulazione canonica della metodologia, Spec Kit di GitHub `[2]` come toolkit canonico per agenti e OpenSpec `[3]` come secondo strumento della stessa famiglia. L'SDD capovolge lo sviluppo tradizionale rendendo eseguibili le specifiche: la specifica genera direttamente un'implementazione funzionante invece di limitarsi a guidarla `[1]`. Il suo insieme di fasi porta avanti uno sviluppo `[2]` (stabilire i principi di governo, specificare cosa costruire, pianificare lo stack tecnologico, suddividere il piano in task, poi implementare). Il suo documento di governo, una costituzione di principi, è l'elemento fondante a cui l'agente deve attenersi in ogni momento. È questo il cuore della differenza. Nell'SDD l'autorità scorre dalla specifica verso lo sviluppo, e ci si aspetta che l'implementazione la segua. SDH ribalta quasi ogni asse di quel contratto (Tabella 3). > **Concetto chiave** > > **La differenza centrale:** nell'SDD l'autorità scorre dalla specifica verso lo sviluppo, e ci si aspetta che l'implementazione la segua. SDH è non autoritaria e scorre nella direzione opposta, verso l'interno a partire dal contesto rilevato del sistema, mettendo in sicurezza ciò che c'è già. | Asse | SDD | SDH | | ------------------------- | ------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------- | | Obiettivo | Consegnare funzionalità. La specifica diventa un'implementazione funzionante. | Mettere in sicurezza ciò che esiste o che si sta costruendo. Ogni fase è orientata alla difesa. | | Modello di autorità | Autoritario. La specifica e la costituzione confinano lo sviluppo in un ambito da seguire. | Non autoritario. SDH si adatta allo scenario, e l'utente può riformulare, eliminare o restringere. | | Stato presupposto | Uno sviluppo in avanti a partire da una specifica. | Indipendente dallo stato: directory vuota, progetto in corso, una singola PR o codice legacy. | | Condizione finale | Finisce quando la funzionalità è costruita. | Si può chiudere. Un rilievo raggiunge uno stato definitivo e si riapre solo quando il codice cambia. | | Documento di governo | Una costituzione di principi a cui l'agente deve attenersi. | Un charter di principi formulati in termini di rischio (ognuno con una riga `Why:`), esplicitamente non un contratto fisso. | | Come cresce la conoscenza | Si aggiunge un comando (o si estende l'insieme di fasi). | Si aggiunge una specializzazione non invocabile che l'agente carica su richiesta: un file più una riga di catalogo, nessun nuovo comando. | | Chi serve | Chi costruisce e porta avanti una funzionalità. | Qualsiasi utente, sviluppatore o no, servito attraverso lo stesso flusso. | | Cosa modifica il codice | La fase di implementazione genera lo sviluppo. | Solo la fase harden modifica il codice, una correzione alla volta. | **Tabella 3.** SDD e SDH a confronto su otto assi. Struttura presa in prestito, contratto ribaltato. Per correttezza nei confronti della tradizione: l'SDD è un precedente collaudato, e SDH gli deve la struttura su cui gira. Il distacco non è una critica all'SDD, che risolve bene un problema diverso (costruire in avanti). SDH prende lo stesso meccanismo collaudato e lo punta verso la difesa, l'adattività e la chiusura. OpenSpec `[3]`, organizzato intorno a proposte di modifica, elenchi di task e specifiche per ogni modifica, conferma lo schema: la famiglia porta avanti uno sviluppo a partire da una specifica, mentre SDH mette in sicurezza un sistema verso l'interno a partire dal suo contesto rilevato. Anche la modalità preventiva di SDH (`§IX`), l'unico punto in cui accompagna uno sviluppo in avanti, mantiene il contratto ribaltato: governa il modo in cui il lavoro viene costruito e non decide mai cosa costruire. --- ## XI. Rigore ingegneristico: la disciplina del tracciamento La disciplina del riconciliare senza mai solo aggiungere (`§V`) ha bisogno di un substrato che sopravviva ai refactoring. Un rilievo deve restare un unico elemento in ogni fase che lo tocca, e un file rinominato o spostato non deve rompere la catena. SDH risolve il problema con l'**identità per nome** e con **i percorsi conservati solo nel tracciamento**. > **Definizione** > > **Identità per nome:** l'identità di un rilievo è il suo nome, scritto in modo identico in ogni artefatto. La prosa contiene il nome, mai un percorso. I percorsi dei file si trovano solo nella mappa di tracciamento, così un file rinominato o spostato rompe il collegamento esattamente in un punto. Ogni rilievo di detect è un elemento tracciato. La sua identità è il suo **nome**, il titolo della sezione, scritto in modo identico nella mappa di detect, nel piano e nel registro di hardening. Le fasi successive riutilizzano quel nome alla lettera mentre agiscono sullo stesso elemento, e verify scrive il suo verdetto nel registro di hardening con quello stesso nome. La mappa di tracciamento contiene il tracciamento e nient'altro, una voce per elemento: ```json { "name": "File uploads", "paths": ["src/routes/upload.ts"] } ``` La mappa non registra prosa, annotazioni, identificatori separati né fasi. Gli artefatti in prosa contengono la formulazione, e la mappa contiene solo identità e percorsi. I percorsi dei file sono l'unico elemento volatile, e si trovano solo qui. Un file rinominato o spostato può rompere il collegamento esattamente in un punto, mai in due copie divergenti. ```mermaid flowchart TB detect["la mappa di detect"] --> name plan["il piano di difesa"] --> name harden["il registro di hardening
verify vi scrive il suo verdetto"] --> name name["name = "File uploads"
la prosa contiene il nome, mai un percorso"] name -.-> tracking tracking["la mappa di tracciamento
{ name: "File uploads",
paths: ["src/routes/upload.ts"] }
il percorso si trova solo qui, quindi una rinomina corregge solo questa voce"] ``` **Figura 5.** Il trasportatore dell'identità. Il nome di un rilievo attraversa ogni artefatto, mentre il suo percorso si trova solo nella mappa di tracciamento, così una rinomina viene corretta in un solo punto. Due atti mantengono la mappa nel flusso normale, e un terzo si distingue come manutenzione. **Track** è una registrazione additiva: una fase riporta i rilievi che ha scritto, e il motore registra quelli nuovi e segue un percorso rinominato per gli altri, classificandoli come nuovi, spostati o invariati. Non rimuove mai nulla che la fase non abbia riportato. **Untrack** archivia i rilievi che verify ha chiuso: in un unico passaggio deterministico distilla ognuno nella sua voce di storico, rimuove la sua intera sezione dagli artefatti, elimina un artefatto il cui ultimo rilievo non c'è più ed elimina la sua voce di tracciamento, così l'agente non fa nulla di tutto ciò a mano. Dove il passaggio deterministico non può procedere in sicurezza, un nome archiviato ancora citato nella prosa di un altro rilievo, segnala il punto all'agente invece di tirare a indovinare una modifica. Questi due sono gli atti che le fasi richiamano durante l'esecuzione. **Repair** è l'atto di manutenzione: una fase lo delega automaticamente quando la propria riconciliazione trova il tracciamento incoerente (un percorso registrato che non esiste più), e altrimenti viene eseguito su richiesta. Riallinea l'intera mappa in una volta sola, leggendo ogni artefatto e il codice attuale, correggendo i percorsi di ogni elemento e facendo emergere ciò che non può decidere da solo, un orfano (un elemento tracciato che nessun artefatto nomina più) o un candidato alla rinomina (un elemento i cui percorsi corrispondono a un nome riportato diverso). Repair è manutenzione, non una sesta fase. Non tocca né il codice dell'utente né gli artefatti in prosa, solo il tracciamento. Legge il sorgente dell'utente per un unico motivo, scoprire il nuovo percorso di un file rinominato, e non scrive mai contenuti di sicurezza. La persona è l'arbitro finale sull'unica decisione che il motore si rifiuta di indovinare: se un elemento scomparso sia stato risolto o soltanto rinominato. Meglio chiedere che indovinare, perché un elemento eliminato per errore rompe la catena. La metodologia applica a se stessa la propria disciplina difensiva. I motori deterministici vengono invocati come programmi da riga di comando, e ogni input viene passato come argomento di processo a sé stante, il che lo mantiene inerte, così un valore con virgolette o backtick non può mai iniettare nulla nel comando. Un controllo sconosciuto fallisce invece di rispondere, così un nome scritto male non risulta mai come un esito pulito. SDH non esenta la propria infrastruttura dal principio della sicurezza per impostazione predefinita. --- ## XII. Il veicolo: un'architettura indipendente dall'agente come prova di portabilità Perché SDH sia una convenzione che altri adottano, non deve essere legata a un solo agente o a un solo stack, quindi il suo veicolo tiene separate tre responsabilità (Figura 6). Lagune dimostra che è possibile. **Il valore di sicurezza** viene scritto una sola volta e non sa nulla di quale agente lo esegua: le istruzioni delle fasi e i template che compilano, il catalogo delle conoscenze e i motori deterministici. **La distribuzione** è sottile: il suo unico compito è portare quel valore a un dato agente nella forma e nel posto che l'agente si aspetta, e non contiene alcuna logica di sicurezza propria. **Lo stato del progetto** appartiene al progetto: il charter, gli artefatti delle fasi, la mappa di tracciamento, le categorie scelte e le sue specializzazioni, versionati e revisionabili come qualsiasi altra parte del suo codice. ```mermaid flowchart TB value["il valore di sicurezza, scritto una sola volta
istruzioni delle fasi · template · catalogo delle conoscenze · motori deterministici
non sa nulla di quale agente lo esegua"] delivery["la distribuzione
porta quel valore a ogni agente nella forma che si aspetta
non contiene logica di sicurezza"] agent["l'agente
esegue le fasi"] project["lo stato del progetto
versionato con il suo codice
charter · artefatti delle fasi · tracciamento · categorie · specializzazioni proprie"] value --> delivery --> agent agent -->|"legge e scrive"| project ``` **Figura 6.** Il veicolo indipendente dall'agente. Il valore di sicurezza viene scritto una sola volta, una distribuzione sottile lo porta a ogni agente, e lo stato resta del progetto. Dato che la distribuzione non contiene logica di sicurezza, il modo in cui viene costruita non cambia nulla in SDH. Un veicolo può costruire la distribuzione da sé o affidarla a un ecosistema che già distribuisce skill per agenti, come fa l'implementazione di riferimento, e le fasi, i loro artefatti e le loro garanzie restano gli stessi. Niente di tutto questo è specifico di un linguaggio o di un runtime. L'implementazione di riferimento è scritta in un certo stack, ma la metodologia è il confine tra queste responsabilità, non la toolchain che le costruisce. Lo stesso progetto si potrebbe reimplementare in un linguaggio completamente diverso senza cambiare ciò che SDH è. --- ## XIII. Caso pratico: SDH dall'inizio alla fine > **Caso pratico** > > **Hardening difensivo di una superficie di caricamento e di amministrazione.** > **Contesto:** una piccola app che accetta file caricati dagli utenti e li elenca in una pagina di amministrazione. > **Schema:** charter → detect (con conoscenza su richiesta attivata dal contesto) → plan → harden → verify, con una chiusura e un fallimento reale. > **Esito (capacità):** un rischio verificato come chiuso e archiviato in tutta la catena, e un controllo verificato come _non_ chiuso e rimandato a harden. Il verdetto riflette il codice, non il registro. _Questo è un esempio illustrativo dei meccanismi della metodologia, non uno studio misurato sul campo, e non riporta metriche di efficacia._ Un'unica dimostrazione continua mostra la metodologia in azione, non solo le sue parti. Estendiamo il filo del caricamento di file di `§IV` con un'attivazione di conoscenza su richiesta e una chiusura, e includiamo un fallimento reale. 1. **charter** propone il principio "Ogni input è non attendibile finché non viene validato", con il suo rischio in linguaggio semplice: l'input non controllato è il modo più comune in cui un sistema viene violato. 2. **detect** analizza la route del caricamento e la piccola pagina di amministrazione che elenca i file caricati. Rileva il rilievo sul caricamento (l'handler si fida del tipo MIME del client). La pagina di amministrazione gira nel browser, un contesto che il prompt su richiesta (`§VII`) riconosce, quindi detect carica la specializzazione per quel contesto e fa emergere un secondo rilievo, un punto in cui il nome di un file viene scritto nella pagina come markup invece che come testo, così un nome costruito ad arte può essere eseguito come script nel browser del visitatore. Le specializzazioni il cui contesto è assente da questo ambito non si caricano mai, e ogni salto viene registrato con l'assenza ricavata dal codice. 3. **plan** assegna alla correzione del caricamento la priorità Critical, legata al principio: controllare il tipo reale e la dimensione del file, rinominarlo al salvataggio, conservarlo dove il codice non può essere eseguito. Assegna alla seconda correzione la priorità High: mostrare il nome del file come testo, non come markup. 4. **harden** applica prima la correzione del caricamento (priorità più alta) e la registra come Applied, poi la seconda, anch'essa Applied. 5. **verify** legge ogni punto e confronta il codice con il registro. Il controllo sul caricamento regge: l'handler rileva il tipo reale dal contenuto, impone un limite di dimensione e rifiuta il resto. Verdetto: Risk closed. Verify archivia il rilievo sul caricamento in tutta la catena, e il suo riepilogo distillato finisce nello storico. Segue il fallimento reale. Supponiamo che la seconda correzione di harden abbia aggiunto un helper sicuro per mostrare il testo, ma abbia lasciato la vecchia chiamata che scrive markup ancora raggiungibile da un altro percorso del codice. Verify legge la pagina, vede l'helper sicuro e vede anche che il percorso non sicuro è ancora attivo. Il controllo è presente, ma il rischio non è chiuso. Verify si rifiuta di ammorbidire il verdetto per farlo coincidere con il registro. Restituisce "Risk not closed", registra la lacuna e rimanda a harden. Un controllo che non affronta completamente il rischio non è un via libera. Questo è il carattere della metodologia in un solo esempio: rilevamento sensibile al contesto, correzioni con priorità legate ai principi, applicazione attenta e una verifica che riporta lo stato reale del codice, qualunque cosa dica il registro. --- ## XIV. Quando usare SDH, e i suoi limiti SDH è raramente sproporzionata come può esserlo un processo pesante, perché è indipendente dallo stato e si può chiudere: si riduce fino a un singolo file e a una singola preoccupazione, e raggiunge uno stato definitivo invece di lasciare un peso permanente. Il suo confine non è la dimensione del progetto, è la **profondità della garanzia**. ```mermaid flowchart TB q1{"Il codice fa qualcosa di rilevante per la sicurezza?
(input, autenticazione, dati, segreti, chiamate esterne)"} q1 -->|no| little["Qui SDH aggiunge poco."] q1 -->|sì| q2{"Esegui SDH. C'è un requisito di conformità,
o una funzione di sicurezza dedicata?"} q2 -->|no| baseline["SDH è una base difendibile."] q2 -->|sì| carrier["SDH è il veicolo strutturato:
supporta la revisione e l'audit degli esperti,
non li sostituisce."] ``` **Figura 7.** Quando usare SDH. La diramazione riguarda prima la rilevanza per la sicurezza, poi la profondità della garanzia, mai la dimensione del progetto. Dove SDH raggiunge il suo confine: i comportamenti che emergono solo quando il sistema è in esecuzione (verify legge il codice, non esegue il sistema), i rischi che dipendono da una configurazione o da un ambiente che l'agente non può leggere, e i contesti ad alto rischio in cui la revisione di un esperto è comunque necessaria. In ognuno di questi casi SDH aggiunge comunque valore come primo passaggio strutturato, ma è un pavimento, non un soffitto. > **Concetto chiave** > > **Il confine:** il limite di SDH è la profondità della garanzia, non la dimensione del progetto. Può fare da base difendibile quasi ovunque e supporta la revisione degli esperti dove la posta in gioco lo richiede, ma non sostituisce i test sul sistema in esecuzione né il giudizio di un professionista della sicurezza. --- ## XV. Discussione: posizionamento, limiti e ciò che SDH non afferma SDH è precisa sui propri confini. ### Estende, non sostituisce SDH non sostituisce i professionisti della sicurezza né gli strumenti Blue Team specializzati. Estende le conoscenze dello sviluppatore (`§VI`). L'affermazione corretta è misurata: applicata bene, SDH **può** chiudere rischi reali in modo efficace, soprattutto per i progetti che altrimenti non riceverebbero alcun passaggio di sicurezza. Non è una garanzia, e non sostituisce la revisione di un esperto dove la posta in gioco la richiede. ### Solo difesa, per costruzione SDH verifica, mette in sicurezza e controlla. Non produce mai strumenti offensivi, exploit o tecniche di elusione del rilevamento per nuocere. I contenuti di sicurezza a doppio uso sono accettabili solo in un contesto chiaramente difensivo e autorizzato. È un confine rigido, non una preferenza. ### La verifica è sostanziale, non scenica Verify verifica leggendo il codice e confrontandolo con il registro, non eseguendo il sistema. È una verifica statica: conferma che un controllo è presente e corretto nel codice, e non dimostra che il controllo regga sotto attacco a runtime. Per questo "Cannot tell from the code" è un verdetto legittimo, non un fallimento nascosto dietro un esito positivo. Quando l'evidenza non è nel codice (dipende dalla configurazione, o da un percorso che l'agente non può leggere), SDH lo dice invece di tirare a indovinare. ### Il determinismo è circoscritto, e dichiarato Gran parte di SDH si basa sul ragionamento dell'agente, ed è questo che ne permette la sensibilità al contesto. Il determinismo è riservato ai motori deterministici: i controlli che una specializzazione può portare con sé (`§VII`) e il motore di tracciamento (`§XI`). Il documento non sfuma questo confine. Dove un risultato è deterministico, è il risultato di un programma. Dove è ragionato, è la lettura del codice da parte dell'agente, con l'utente come arbitro finale. ### Costi e scala Un'analisi completa consuma molti token. Le modalità manuali (`§VI`, `§VIII`) esistono in parte per mantenere il costo proporzionato alla preoccupazione. ### L'utente è l'arbitro finale SDH chiede alla persona di decidere tra rinominato e risolto, e l'approvazione delle sue modifiche al codice resta dove l'utente già governa il proprio agente, nella modalità di permessi in cui lo esegue. La metodologia propone e verifica. Non scavalca la persona. ### Obiezioni e risposte Uno scettico onesto solleverà diverse obiezioni. Quelle sostanziali meritano di essere poste con parole loro. **"Non è solo un analizzatore statico con un LLM attaccato sopra?"** No. Un analizzatore statico esegue per impostazione predefinita ogni regola che ha. SDH rileva prima che cos'è il sistema, poi attinge alla conoscenza pertinente (`§II`, `§VII`), e _incorpora_ un controllo deterministico solo dove una classe di rischio ha una procedura di decisione netta. Il ragionamento parte dal contesto, il determinismo è mirato. **"Non è solo una checklist di sicurezza?"** No. SDH ribalta la checklist: il rilevamento viene prima, e la conoscenza viene richiamata per ciò che il progetto fa davvero (`§II`, `§VII`). **"Non è solo l'SDD rinominato per la sicurezza?"** No. SDH prende in prestito la struttura dell'SDD e ne ribalta il contratto: autorità, stato presupposto, condizione finale e destinatari sono tutti diversi (`§X`). Stesso meccanismo, direzione opposta. **"Un metodo basato sul ragionamento dell'IA non finisce per allucinare i rilievi?"** Il progetto limita l'invenzione invece di confidare che il modello si comporti bene. Detect registra solo ciò che il codice sostiene ("rilevare, non inventare", `§IV`), verify confronta il codice con il registro e può rispondere "Cannot tell from the code" (`§XV`), i controlli deterministici ancorano i casi decidibili (`§VII`) e l'utente è l'arbitro finale. Questo non rende l'agente infallibile, rende verificabili le sue affermazioni. Una nota sul posizionamento. SDH è definita qui indipendentemente dalla sua implementazione di riferimento. Le cinque fasi, il charter formulato in termini di rischio, il riconciliare senza mai solo aggiungere e la sua chiudibilità, la conoscenza su richiesta, la modalità preventiva, il tracciamento dell'identità per nome e il confine esclusivamente difensivo sono la metodologia. Un altro team potrebbe implementarli in un altro stack e in un altro ecosistema di agenti, e il risultato sarebbe ancora SDH. Lagune ne è la prova, non la definizione. --- ## XVI. Le insidie, e come SDH le evita per struttura Le metodologie di questa famiglia condividono un insieme noto di modalità di fallimento. La risposta di SDH alla maggior parte di esse è strutturale, incorporata nel flusso invece di essere lasciata alla disciplina. | Insidia | Il fallimento | La risposta strutturale di SDH | | --------------------------------------------- | ---------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Specifiche che marciscono, arretrato superato | Gli artefatti accumulano voci morte di cui nessuno si fida | Riconciliare senza mai solo aggiungere (`§V`): ogni esecuzione ricontrolla ogni voce e rimuove ciò che è risolto | | Falsa sicurezza, esito positivo | Si presume che un controllo presente chiuda il rischio | Verify confronta il codice con il registro, quindi "Risk not closed" e "Cannot tell" sono verdetti a pieno titolo (`§IV`, `§XV`) | | Valanga di checklist | Le voci generiche nascondono l'unico rischio che conta | Sensibile al contesto più che generico, con il prompt su richiesta che carica solo ciò che l'ambito richiede (`§VII`) | | Dipendenza da uno strumento | Il metodo è saldato a un solo fornitore o agente | Veicolo indipendente dall'agente: il valore di sicurezza viene scritto una sola volta, e la sua distribuzione a ogni agente non contiene logica di sicurezza (`§XII`) | | Il ciclo infinito | L'arretrato non si chiude mai, il lavoro non si ferma mai | La chiudibilità e lo stato di riposo (`§V`) | **Tabella 4.** Le insidie note di questa famiglia di metodologie e la risposta strutturale di SDH a ciascuna. Il punto è nominare l'insidia e indicare il meccanismo: non sono inviti alla prudenza, sono proprietà del flusso. --- ## XVII. Sviluppi futuri La metodologia e la sua implementazione di riferimento hanno passi successivi chiari. - **Far crescere il catalogo delle conoscenze:** Ogni aggiunta mantiene la forma di `§VII`: un file di conoscenza e una riga di catalogo, nessun nuovo comando. La via dal lato dell'utente esiste già: l'utente distilla su richiesta le proprie specializzazioni. Più linguaggi, runtime e classi di rischio integrati, ognuno inserito in una categoria, sono la direzione dal lato del maintainer, e ci si aspetta che le specializzazioni evolvano. - **Più controlli deterministici:** Dove una classe di rischio ha una procedura di decisione netta, una specializzazione può portare con sé un controllo deterministico che ancora il ragionamento dell'agente a un verdetto ripetibile. Estenderlo a più classi di rischio è una direzione naturale. - **Valutazione empirica:** La questione aperta più importante è l'efficacia misurata: la qualità delle chiusure e il tasso di verdetti errati su codebase reali. Uno studio sui risultati di sicurezza di SDH è uno sviluppo futuro, e le affermazioni qui sono limitate di conseguenza. --- ## XVIII. Conclusione Lo sviluppo assistito dall'IA ha aperto una lacuna di sicurezza che le checklist generiche non possono colmare, perché il rischio che conta è specifico di ciò che un sistema fa davvero, e chi lo rilascia potrebbe non sapere cosa chiedere. SDH colma questa lacuna con un flusso sensibile al contesto, esclusivamente difensivo e che si può chiudere, in cui le conoscenze di sicurezza risiedono nella metodologia e nelle sue specializzazioni su richiesta, una base su cui ogni utente può costruire. Rileva il contesto reale del sistema, classifica i rischi che quel contesto comporta, applica le correzioni con attenzione e verifica ognuna, poi archivia ciò che ha chiuso, così ogni rilievo raggiunge uno stato finale. La stessa difesa agisce anche in modo preventivo mentre si costruisce il nuovo lavoro, così ciò che il flusso chiude resta chiuso. Si adatta a qualsiasi stato di sviluppo in qualsiasi stack, ed estende le conoscenze dello sviluppatore invece di sostituire le persone e gli strumenti che già svolgono quel compito. Lagune è la prova, ma il contributo è la convenzione. SDH viene proposta come il flusso di sicurezza essenziale per l'era dello sviluppo con l'IA, perché altri la adottino, la affinino e la implementino nei propri stack. --- ## Riferimenti **[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. --- ## Appendice A: i principi, alla lettera 1. **Sicuro per impostazione predefinita, in linguaggio semplice, per tutti allo stesso modo:** Ogni impostazione predefinita, messaggio e correzione deve essere sicuro fin da subito e comprensibile a qualsiasi utente, sviluppatore o no. Nessuna categoria di utenti è privilegiata rispetto a un'altra. 2. **Sensibile al contesto più che generico:** Ogni fase deve partire dal contesto rilevato in detect e agire su ciò che il sistema fa davvero. Preferisci raccomandazioni specifiche per quel contesto alle checklist generiche. Le conoscenze di sicurezza risiedono nella specifica e nelle sue specializzazioni su richiesta, ed estendono ciò che l'utente porta con sé. 3. **Flessibile più che rigido:** SDH si adatta al progetto e all'utente. Principi, requisiti e raccomandazioni sono punti di partenza, non un contratto fisso. Lascia che l'utente riformuli, elimini, aggiunga o restringa qualsiasi cosa. La flessibilità non indebolisce mai la base sicura per impostazione predefinita, permette solo all'utente di plasmare il modo in cui viene applicata. 4. **Riconciliare, mai solo aggiungere:** Gli artefatti sono documenti vivi, non log. Quando una fase viene rieseguita, riconcilia ogni voce esistente con la verità attuale: mantieni ciò che è ancora valido, riscrivi ciò che è cambiato e rimuovi ciò che non vale più. La chiusura è questa stessa riconciliazione che arriva alla sua conclusione. 5. **Solo difesa:** SDH verifica, mette in sicurezza e controlla. Non produce mai strumenti offensivi, exploit per uso malevolo o tecniche di elusione del rilevamento per nuocere. I contenuti di sicurezza a doppio uso sono accettabili solo in un contesto chiaramente difensivo e autorizzato. 6. **Spec-first, guidato da agenti, orientato alla sicurezza:** Costruisci il flusso di lavoro a partire da una struttura collaudata: template, comandi, un charter di governo e un agente che esegue le fasi. Reimplementa quella struttura con uno scopo difensivo. --- # Glossario di Lagune: SDH, charter, rilievi e controlli > Definizioni in linguaggio semplice di ogni termine di Lagune e del Security-Driven Hardening: SDH, charter, detect, rilievo, controllo, harden, verify, archiviazione, chiudibilità, specializzazioni, categorie e catalogo. Canonico: https://lagune.ai/it-IT/docs/references/glossary Lingua: it-IT Originale: https://lagune.ai/docs/references/glossary Ultimo aggiornamento: 2026-11-03 Ogni termine portante di Lagune e della metodologia Security-Driven Hardening, definito una sola volta, in linguaggio semplice. ### Security-Driven Hardening (SDH) La metodologia che Lagune implementa: una convenzione blue team sensibile al contesto che rileva il contesto di un sistema, classifica i rischi che quel contesto comporta e guida le correzioni. Le conoscenze di sicurezza risiedono nella specifica e nelle sue specializzazioni su richiesta, così uno sviluppatore e chi non lo è vengono serviti attraverso lo stesso flusso. ### Lagune L'implementazione di riferimento di SDH: nove comandi per agenti, ognuno con il template che compila, che un agente IA esegue per mettere in sicurezza una codebase. Ogni agente li installa tramite il proprio installer di plugin o tramite [**skills.sh**](https://www.skills.sh/wellwelwel/lagune), come mostra la [pagina di installazione](https://lagune.ai/it-IT/docs), ed eseguono il motore di Lagune per ogni passo deterministico. ### Charter Il livello di governo di Lagune: un insieme di principi con la sicurezza al primo posto che ogni fase successiva deve rispettare. Consideralo il controllo in fase di compilazione della postura di sicurezza di un progetto. Viene salvato in `.lagune/memory/charter.md`. ### Flusso di sviluppo Il comando universale `/lagune`, che mette in sicurezza il lavoro mentre viene scritto. Accetta qualsiasi prompt in qualsiasi fase, costruisce ciò che hai chiesto e lo mette in sicurezza con impostazioni predefinite sicure prima di restituirtelo, guidato dal charter quando ne esiste uno. Non scrive nulla nel tracciamento di Lagune, quindi il suo unico prodotto è il codice messo in sicurezza. Insieme al charter (prima) e al flusso Blue Team (dopo), è il modo in cui Lagune protegge durante lo sviluppo. ### Flusso Blue Team L'audit in cinque fasi al centro di Lagune: charter, detect, plan, harden, verify. Ogni fase si basa sulla precedente. "Blue Team" è la tradizione di sicurezza dei difensori, in contrapposizione al Red Team offensivo. ### Rilievo Un singolo rischio individuato. Ogni rilievo indica cos'è, perché conta e l'evidenza nel codice. Un rilievo è l'unica unità tracciata che plan, harden e verify portano avanti, identificata per nome in ogni artefatto. ### Controllo Una misura di sicurezza applicata per chiudere un rischio. Harden applica i controlli, verify dimostra che reggono. Lagune non indebolisce mai un controllo per soddisfare un prompt. ### Detect La fase che legge il codice e mappa cosa fa il sistema e dove sono i rischi. La sua regola guida è rilevare, non inventare: registra solo ciò che il codice sostiene. ### Harden L'unica fase che tocca il tuo codice. Applica le correzioni del piano una alla volta e registra ognuna come Applied, Partial o Blocked. Applied non significa ancora dimostrata. ### Verify La fase che dimostra che ogni correzione applicata regge, leggendo il codice e confrontandolo con ciò che harden ha registrato. Restituisce uno di tre verdetti: Risk closed, Risk not closed o Cannot tell from the code. ### Archiviazione Quando verify dimostra che un rischio è chiuso, il rilievo viene archiviato: rimosso da tutta la catena, con la tua conferma, così smette di essere rielaborato. ### Chiudibilità La proprietà per cui il lavoro di sicurezza ha uno stato finale. Dato che un rilievo dimostrato chiuso viene archiviato, il flusso può arrivare a riposo, e si riapre solo quando il codice cambia. SDH si può chiudere, non è un ciclo infinito. ### Motore Il pacchetto `lagune` su **npm**, che i comandi eseguono tramite `npx` per ogni passo deterministico: gli hook, il catalogo e le categorie. ### Specializzazione Un modulo di conoscenza di sicurezza mirato e indipendente dal linguaggio, che si carica solo su richiesta, mai per impostazione predefinita. Una specializzazione non è un comando. Caricane una in qualsiasi prompt con `read catalog ` del motore, per esempio `npx lagune read catalog regex`. ### Categoria Un gruppo con nome di specializzazioni integrate, da `owasp` a quelle per linguaggio come `javascript`, `python`, `go` e `rust`. Le categorie usate da un progetto, registrate in `.lagune/configs.json`, decidono quali specializzazioni integrate entrano nel suo catalogo. Finché non ne è registrata nessuna, il progetto usa solo `owasp`. ### Catalogo L'insieme delle specializzazioni che un progetto usa: quelle integrate delle sue categorie più le sue, scritte con `/lagune-specialize`. `read catalog` del motore lo elenca, e le fasi lo confrontano con il codice. ### Prompt su richiesta Il principio per cui la conoscenza di sicurezza pertinente viene richiamata per ciò che il progetto è davvero, invece di eseguire ogni controllo per impostazione predefinita. ### Identità per nome Il modello di tracciamento di Lagune: il nome di ogni rilievo, scritto in modo identico come titolo di sezione in ogni artefatto, è la sua identità in tutta la catena. La mappa di tracciamento (`.lagune/tracking.json`) contiene solo il tracciamento, mai prosa. ## Domande frequenti ### Che cos'è il Security-Driven Hardening (SDH)? SDH è una metodologia di sicurezza blue team sensibile al contesto. Rileva il contesto di un sistema, classifica i rischi che quel contesto comporta e guida le correzioni, esprimendo ogni rilievo in linguaggio semplice. Lagune ne è l'implementazione di riferimento. ### Che cos'è un charter in Lagune? Il charter è il livello di governo di Lagune, un insieme di principi con la sicurezza al primo posto che ogni fase successiva deve rispettare. Viene salvato in .lagune/memory/charter.md. ### Cosa significa archiviare un rilievo? Quando verify dimostra che un rischio è chiuso, il rilievo viene archiviato: rimosso da tutta la catena con la tua conferma, così smette di essere rielaborato. --- # Schema delle configurazioni > Lo JSON Schema delle configurazioni di un progetto Lagune, per l'autocompletamento e la validazione nel tuo editor, allineato al Lagune attuale o fissato a una versione. Canonico: https://lagune.ai/it-IT/docs/references/configs-schema Lingua: it-IT Originale: https://lagune.ai/docs/references/configs-schema Ultimo aggiornamento: 2026-11-03 `.lagune/configs.json` registra le [**categorie**](https://lagune.ai/it-IT/docs/categories) usate da un progetto e indicizza le sue [**specializzazioni**](https://lagune.ai/it-IT/docs/catalog). Il suo JSON Schema permette al tuo editor di completare automaticamente ogni campo e di segnalare un refuso o una categoria sconosciuta mentre modifichi il file. ## Lo schema attuale Ogni volta che **Lagune** scrive il file e non vi trova alcun `$schema`, fa puntare il file allo schema attuale: ```json { "$schema": "https://lagune.ai/schemas/configs.json", "categories": ["owasp", "javascript"] } ``` Questo indirizzo segue sempre il **Lagune** attuale. Un file scritto prima di **Lagune** 0.16.0 lo riceve alla modifica successiva, e fino ad allora ogni fase lo fa notare. ## Fissa una versione Ogni release di **Lagune** dalla 0.16.0 in poi porta con sé lo schema com'era in quella versione, pubblicato su **npm** e servito da **jsDelivr**. Per fissarne una, metti la versione dopo `lagune@` nell'indirizzo di `$schema`: ```json { "$schema": "https://cdn.jsdelivr.net/npm/lagune@0.16.0/schemas/configs.json" } ``` La versione accetta qualsiasi intervallo semver: | Versione | Schema | | ----------------- | ------------------------------- | | `0.16.0` | Quello della 0.16.0 | | `0.16.x` o `0.16` | Quello dell'ultima release 0.16 | | `0.x` o `0` | Quello dell'ultima release 0.x | | `latest` | Quello dell'ultima release | ## Domande frequenti ### Lagune ha bisogno dello schema? No. Lo schema aiuta solo il tuo editor, e Lagune legge il file nello stesso modo con o senza $schema. ### Lagune sovrascrive uno schema fissato? No. Lagune scrive $schema solo quando il file non ne ha uno, e mantiene qualsiasi indirizzo tu abbia impostato. ### Quando dovrei fissare una versione? Quando il progetto usa una versione specifica di Lagune, così il tuo editor valida il file rispetto a ciò che quella versione accetta. --- # Lagune vs. Deepsec: due approcci alla sicurezza guidati dall'IA a confronto > Un riferimento che confronta Lagune e Deepsec di Vercel per funzionamento, ciclo di vita, rilevamento, costi, rilievi e chiusura. Canonico: https://lagune.ai/it-IT/docs/references/deepsec Lingua: it-IT Originale: https://lagune.ai/docs/references/deepsec Ultimo aggiornamento: 2026-11-03 [Lagune](https://github.com/wellwelwel/lagune) e [Deepsec](https://github.com/vercel-labs/deepsec) (`v2.2.1`) sono due risposte difensive allo stesso problema: la sicurezza nell'era dello sviluppo assistito dall'IA. La loro premessa, il loro inizio, svolgimento e fine, e il modo in cui ciascuno si presenta all'utente divergono per scelta progettuale, anche dove i loro meccanismi si sovrappongono. **Suggerimento** Lagune si ispira a Deepsec? No, Lagune è scritto da zero e si ispira allo Spec-Driven Development e al Security Hardening. I due progetti sono stati sviluppati in modo indipendente, e questo confronto serve ad aiutare gli utenti a capirne le differenze. ## In sintesi | Aspetto | Lagune | Deepsec | | ------------------- | ------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- | | Natura | Una metodologia (SDH) con un'implementazione di riferimento | Un prodotto: uno scanner di vulnerabilità basato su agenti | | Baricentro | Un charter e una conoscenza su richiesta guidano l'agente, ancorati a hook deterministici | Un'ampia rete di regex alimenta un'indagine obbligatoria dell'IA | | Cosa produce | Codice messo in sicurezza, prove e una catena tracciata di rilievi | Un report di rilievi classificati e ordinati per gravità | | Tocca il tuo codice | Sì: `harden` modifica il tuo codice | No: solo analisi statica, emette rilievi e testo di raccomandazioni | | Esecuzione | Gira sull'agente e sul modello che già usi, di qualsiasi livello | Esegue la propria pipeline di modelli, di livello frontier per impostazione predefinita | | Per iniziare | Un'installazione del plugin o `npx skills add`, poi lo guidi in linguaggio semplice, senza nuovi strumenti da configurare | Configura un workspace `.deepsec/`, installa le dipendenze e aggiungi una chiave del modello | ## Come funziona Lagune parte dall'agente: l'agente guida, attinge su richiesta alla conoscenza adatta a ciò che è il codice e delega agli hook deterministici la parte che si può decidere. Deepsec parte dal determinismo: un'analisi ampia segnala candidati che indicano a un modello obbligatorio cosa indagare e giudicare. | Aspetto | Lagune | Deepsec | | -------------------- | ---------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------ | | Ordine | Il charter e la conoscenza pertinente orientano l'agente, che delega agli hook e giudica il resto | I matcher segnalano i candidati, il modello indaga e giudica ognuno | | Ruolo deterministico | Hook multilinguaggio che restituiscono un verdetto o indirizzano l'agente, combinati con la conoscenza delle categorie | Matcher che segnalano candidati da far giudicare al modello obbligatorio | | Flusso di sviluppo | `/lagune` costruisce in modo sicuro mentre scrivi il codice | Rivede il codice, non lo scrive | | Flusso di audit | `charter` → `detect` → `plan` → `harden` → `verify` | `scan` → `process` → `triage` → `revalidate` → `report` | | Il compito dell'IA | Ragionare a partire dalla conoscenza, applicare la correzione e dimostrare che regge | Indagare ogni candidato e riferire i rilievi | ## Ciclo di vita Lagune lavora prima, durante e dopo la scrittura del codice. Deepsec rivede un repository quando il codice esiste già. | Momento | Lagune | Deepsec | | -------------------------- | ------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------ | | Prima che il codice esista | `charter` ricava una politica di sicurezza dall'intento dichiarato | Parte dal codice esistente: `init` richiede una directory | | Durante lo sviluppo | `/lagune` costruisce in modo sicuro per impostazione predefinita, senza lasciare artefatti | Rivede dopo lo sviluppo, non durante | | Sul codice esistente | `detect` → `plan` → `harden` → `verify` | `scan` → `process`, il flusso principale | | Revisione continua | Riesegui le fasi per ambito, senza un controllo di CI già pronto | Nuova analisi incrementale, `process --diff` come controllo di uscita nella CI | ## Livello di rilevamento I due livelli deterministici sono di natura opposta: uno decide, l'altro segnala. | Aspetto | Lagune | Deepsec | | -------------- | --------------------------------------------------------------------------------------- | ----------------------------------------------------------------------- | | Raggruppamento | Hook e specializzazioni, raggruppati in categorie | Matcher per pattern o per framework | | Output | Verdetto letterale (rilievo / da rivedere / avviso) più un'etichetta di classificazione | Candidato senza verdetto (slug, righe, frammento, pattern riconosciuto) | | Taratura | Precisione: consapevole dei commenti, con protezioni per segnaposto e finestre | Richiamo: reti ampie, l'IA elimina i falsi positivi in seguito | | Profondità | Più profondo sulle classi in comune | Più ampio, meno profondo sulle classi in comune | | Falsi positivi | Tenuti bassi alla fonte, poi giudicati nel contesto | Generati in eccesso di proposito, ridotti da un passaggio `revalidate` | ## Conoscenza e giudizio Entrambi portano conoscenze di sicurezza che le regex non possono avere. Differiscono in dove risiedono e in chi può plasmarle. | Aspetto | Lagune | Deepsec | | -------------------- | ------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------- | | Forma | Moduli markdown modificabili, diversi dei quali sostenuti da un hook deterministico | Un breve prompt e punti salienti per tecnologia, che attingono alla conoscenza del modello stesso | | Selezione | Abbinati al codice, caricati solo quando il loro contesto è presente | Iniettati in ogni batch dell'IA, più i punti salienti per la tecnologia rilevata | | Chi li scrive | L'utente modifica i moduli e ne aggiunge di nuovi con `specialize` | Il maintainer possiede il prompt, l'utente compila un `INFO.md` | | Dove sta il giudizio | Gli hook decidono la loro base, l'agente giudica il resto a partire dalla conoscenza | Centralizzato: un unico processore IA giudica ogni candidato | | Riutilizzo | Un solo modulo guida sia `detect` sia `verify` | Un solo prompt guida l'unica fase `process` | ## Rilievi e chiusura Divergono soprattutto su ciò che diventa un rilievo una volta risolto. | Aspetto | Lagune | Deepsec | | ----------------- | ------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- | | Gravità | Un punteggio CVSS v4.0, adattato all'esposizione e alla posta in gioco | Una gravità stabilita dall'IA, più una classificazione P0 / P1 / P2 di sfruttabilità e impatto | | Verdetti | Risk closed, Risk not closed o Cannot tell from the code | true-positive, false-positive, fixed, uncertain, accepted-risk, duplicate | | Persistenza | La catena di lavoro si riconcilia, i rilievi chiusi vengono distillati in uno storico | Record per file in sola aggiunta, non viene rimosso nulla | | Stato finale | Si può chiudere: un rilievo dimostrato viene archiviato, la catena può riposare | Ogni rilievo viene conservato per sempre, nascosto dalle viste una volta risolto | | Dettaglio storico | Un riepilogo compatto di quale fosse il rischio | L'intera traccia dei verdetti, compreso come è stato corretto | ## Costi | Aspetto | Lagune | Deepsec | | ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Base deterministica | Gratuita: gli hook girano senza IA e senza chiave, ed emettono già dei verdetti | Gratuita: `scan` gira senza IA, ma da solo non emette verdetti | | Spesa tipica | Assorbita in un agente che usi già: fino a 0 $ con un modello locale, il prezzo del piano che già paghi, oppure per iterazione con l'uso tramite API | [Circa da 25 $ a 1200 $ per esecuzione per 100-2000 file, di più su larga scala](https://github.com/vercel-labs/deepsec/blob/f75a16803ec5250938bacfe41571d929e8564f45/docs/getting-started.md#run-the-ai-investigation) | | Via più economica | Qualsiasi modello, compreso uno locale gratuito, chiude il ciclo | Esistono livelli a pagamento più economici, ma i rilievi richiedono la fase IA a pagamento | ## Estensibilità e governance Ciascuno apre il livello che l'altro tiene chiuso. | Aspetto | Lagune | Deepsec | | -------------------- | ------------------------------------------------------------- | ------------------------------------------------------------ | | Cosa estendi | Modifichi i moduli, o ne aggiungi di nuovi con `specialize` | Aggiungi matcher, agenti, notificatori e responsabilità | | Livello di politiche | Il charter governa ogni fase ed è sotto controllo di versione | La configurazione è operativa (matcher, modelli, percorsi) | | Override per nome | Un modulo affinato oscura quello integrato | In caso di collisione dello slug di un matcher, vince il tuo | ## Interfacce Deepsec produce deliverable per un'organizzazione di sicurezza. Lagune mostra una vista in tempo reale a chiunque lo esegua. | Aspetto | Lagune | Deepsec | | -------------------------- | ------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------ | | Superficie per le persone | Una dashboard locale in tempo reale dell'intera catena, in linguaggio semplice | File di report, esportazione, metriche e commenti alle PR, più un sito di documentazione | | Responsabilità | Mostra i file e le specializzazioni che sono state applicate | Indica un assegnatario suggerito: reperibile, manager o autore del commit | | Prova riproducibile | `prove` scrive test eseguibili e un bollettino per la divulgazione | Resta statico per scelta progettuale, non esegue mai il bersaglio | | Autodifesa dello strumento | Mette in sicurezza un'API locale di scrittura nella dashboard | Mette in sicurezza la propria esecuzione IA contro il codice non attendibile del bersaglio | ## Scala e distribuzione | Aspetto | Lagune | Deepsec | | ------------------ | -------------------------------------------------------------------------------------- | ---------------------------------------------------------------------- | | Installazione | Nove comandi dal plugin del tuo agente o dalla CLI di skills, senza alcuno scaffolding | Un workspace `.deepsec/` con un proprio pacchetto e proprie dipendenze | | Direzione di scala | Si limita a qualsiasi porzione, un contesto, da un file all'intero progetto | Analizza interi repository, fino a monorepo di grandi dimensioni | | Distribuzione | Solo locale, l'unico server si mette in ascolto sul loopback | Distribuzione facoltativa del lavoro su VM worker di Vercel Sandbox | ## Esperienza d'uso Come ciascuno si presenta a chi lo esegue: cosa richiede la prima esecuzione e come l'operatore lo indirizza. ### Primi passi Lagune funziona tramite l'agente già aperto. Deepsec prepara prima il proprio workspace e l'accesso ai modelli. | Aspetto | Lagune | Deepsec | | ---------------------------- | -------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- | | Primo comando | L'installazione del plugin o `npx skills add wellwelwel/lagune`, poi `/lagune-*` nell'agente | `npx deepsec init`, poi `cd .deepsec`, `pnpm install`, `scan`, `process` | | Credenziali per l'esecuzione | Nessuna chiave separata, usa il tuo agente attuale | Una chiave del modello (ad es. AI Gateway, un token OIDC di Vercel da 12 ore o un token di Anthropic) | ### Come guidarlo Entrambi accettano indicazioni. Lagune legge la forma dell'input in ogni fase. Deepsec restringe l'insieme di file su cui gira la stessa indagine. | Aspetto | Lagune | Deepsec | | ---------------------- | ------------------------------------------------------------------------------------ | ------------------------------------------------------------- | | Tutto il progetto | Una fase senza input analizza l'intero ambito | `scan` e `process` analizzano il repository | | Una porzione | Qualsiasi fase si limita ai file o alle directory indicati | `--files`, `--files-from` o `--diff` restringono l'esecuzione | | Una preoccupazione | Una fase si limita a un timore descritto | Il prompt dell'indagine è fisso | | Una fascia di priorità | `harden` e `verify` si limitano a Critical, High, Medium o Low | I rilievi vengono etichettati dopo l'esecuzione | | Un singolo valore | Un hook valuta direttamente un frammento, un pattern o un URL (`--pattern`, `--url`) | L'unità di lavoro è un file | ## Domande frequenti ### In cosa Lagune è diverso da Deepsec? Lagune parte dall'agente e lavora prima, durante e dopo la scrittura del codice: definisce la politica prima del codice, mette in sicurezza mentre sviluppi e fa l'audit, mette in sicurezza e verifica il codice già scritto. Deepsec parte dal determinismo: un'ampia analisi con regex alimenta un'indagine obbligatoria di un modello frontier che rivede il codice esistente e ne riferisce i rilievi, senza modificarlo. ### Posso usare uno dei due gratuitamente? L'intero flusso di Lagune può girare a 0 $ con un modello locale gratuito, e i suoi hook deterministici emettono verdetti senza alcuna IA. Lo scan di Deepsec è gratuito ma non emette verdetti, quindi qualsiasi rilievo richiede la sua fase IA a pagamento. ### Uno dei due modifica il mio codice? Lagune sì: harden applica le correzioni al tuo codice. Deepsec no: fa solo analisi statica, ed emette rilievi e testo di raccomandazioni che una persona o un agente applica separatamente. --- # Fonti OWASP > Da dove proviene la conoscenza delle specializzazioni OWASP integrate, collegata alle relative pagine canoniche di attacchi e Cheat Sheet di OWASP. Canonico: https://lagune.ai/it-IT/docs/references/owasp-sources Lingua: it-IT Originale: https://lagune.ai/docs/references/owasp-sources Ultimo aggiornamento: 2026-11-03 Questo documento collega ogni **attacco** (`www-community`) e ogni **Cheat Sheet** (`CheatSheetSeries`) di OWASP a una categoria di sicurezza, ognuno con il link alla sua pagina pubblica canonica. All'interno di una categoria, gli elementi equivalenti condividono un'unica riga dell'elenco: gli attacchi e le cheat sheet che affrontano lo stesso rischio sono elencati insieme, separati da virgole. Gli elementi senza un equivalente diretto stanno su una riga a sé. - Il merito è di OWASP. Gli attacchi si trovano in `https://owasp.org/www-community/attacks/` e le cheat sheet in `https://cheatsheetseries.owasp.org/cheatsheets/.html`. --- ## 1. Injection (generica) - [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 injection e injection nei database - [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. Command injection e injection nel sistema operativo - [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. Injection LDAP, XPath e XML - [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) e 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. Redirect e forward - [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. Controllo degli accessi e autorizzazione - [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. Autenticazione e credenziali - [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. Gestione delle sessioni - [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. Federazione delle identità (OAuth, SAML, 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. Crittografia e sicurezza del trasporto - [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 e gestione dei file - [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. Abuso del protocollo HTTP (header, caching, splitting) - [x] [HTTP Response Splitting](https://owasp.org/www-community/attacks/HTTP_Response_Splitting), [Cross-User Defacement](https://owasp.org/www-community/attacks/Cross-User_Defacement) (interpreter) - [x] [HTTP Security Response Headers](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html) (suddiviso tra browser, transport, http-request e 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. Codifica e content spoofing - [x] [Unicode Encoding](https://owasp.org/www-community/attacks/Unicode_Encoding) (interpreter) - [x] [Double Encoding](https://owasp.org/www-community/Double_Encoding) (interpreter) - [x] [Content Spoofing](https://owasp.org/www-community/attacks/Content_Spoofing) (browser) --- ## 17. Injection in CSV e fogli di calcolo - [x] [CSV Injection](https://owasp.org/www-community/attacks/CSV_Injection) (csv) --- ## 18. CORS (Cross-Origin Resource Sharing) - [x] [CORS OriginHeaderScrutiny](https://owasp.org/www-community/attacks/CORS_OriginHeaderScrutiny) (http-request) - [x] [CORS RequestPreflightScrutiny](https://owasp.org/www-community/attacks/CORS_RequestPreflightScrutiny) (http-request) --- ## 19. Denial of service - [x] [Regular expression Denial of Service (ReDoS)](https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS) (regex) --- ## 20. Sicurezza della memoria e codice nativo - [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. Codice mobile ed esecuzione di codice non attendibile - [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. Deserializzazione - [x] [Deserialization](https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html) (suddiviso tra python, ruby, php, java e dotnet) --- ## 23. Malware e minacce lato client - [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, ripudio e gestione degli errori - [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. Logica di business e abuso delle funzionalità La logica di business e l'abuso delle funzionalità non hanno un'unica superficie nel codice che una specializzazione per superficie possa difendere: la difesa è una progettazione specifica dell'applicazione, lo stesso ragionamento che guida il threat modeling del progetto. Spostati in "Fuori ambito". --- ## 26. Sicurezza di IA, LLM e agenti - [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 e cross-site leak - [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. Framework e piattaforme dei linguaggi - [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. Front-end web e browser - [x] [HTML5 Security](https://cheatsheetseries.owasp.org/cheatsheets/HTML5_Security_Cheat_Sheet.html) (browser) - [x] [AJAX Security](https://cheatsheetseries.owasp.org/cheatsheets/AJAX_Security_Cheat_Sheet.html) (browser) - [x] [Securing Cascading Style Sheets](https://cheatsheetseries.owasp.org/cheatsheets/Securing_Cascading_Style_Sheets_Cheat_Sheet.html) (suddiviso tra access-control e browser) --- ## 30. API e servizi - [x] [GraphQL](https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html) (api-endpoint) - [x] [gRPC Security](https://cheatsheetseries.owasp.org/cheatsheets/gRPC_Security_Cheat_Sheet.html) (api-endpoint) - [x] [WebSocket Security](https://cheatsheetseries.owasp.org/cheatsheets/WebSocket_Security_Cheat_Sheet.html) (api-endpoint) --- ## 31. Cloud, container e infrastruttura La configurazione di container e workload è configurazione come codice che lo sviluppatore distribuisce con l'app (`Dockerfile`, Compose, `securityContext` dei Pod), una superficie reale che `harden` corregge e `verify` dimostra, quindi rientra nell'ambito. L'amministrazione del cluster (RBAC, etcd, API server, admission, segmentazione della rete) è dominio dell'operatore e resta fuori ambito. - [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: la parte di workload e Pod. L'amministrazione del cluster resta fuori ambito) - [x] [Serverless / FaaS Security](https://cheatsheetseries.owasp.org/cheatsheets/Serverless_FaaS_Security_Cheat_Sheet.html) (serverless) --- ## 32. Supply chain e 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. Segreti e configurazione La gestione dei segreti è operativa: vault, CI/CD, configurazione del cloud, rotazione. L'unico aspetto a livello di codice (un segreto scritto nel sorgente) è un'analisi deterministica, non una specializzazione di rischio. Spostati in "Fuori ambito". --- ## 34. Processi, progettazione e governance La tutela della privacy degli utenti è una questione di politiche e di progettazione (minimizzazione dei dati, trasparenza, conservazione), non una superficie nel codice che una specializzazione difende. Spostata in "Fuori ambito". --- ## 35. Pagamenti e conformità - [x] [Secure Integration of Third-Party Payment Gateways](https://cheatsheetseries.owasp.org/cheatsheets/Third_Party_Payment_Gateway_Integration_Cheat_Sheet.html) (payment) --- ## 36. Embedded, IoT e domini specializzati La sicurezza automobilistica e quella dei droni sono domini dei sistemi embedded (bus CAN, firmware OTA, integrità di sensori e radio, accesso fisico), non il sorgente di applicazioni web e API che Lagune verifica. Spostate in "Fuori ambito". --- ## Fuori ambito (nessuna superficie nel codice) Questi non sono terreni da specializzazione e non hanno casella di spunta: sono governance, processi, hardening operativo o uso di framework, senza un'unica superficie nel codice che una specializzazione per superficie possa difendere. Il loro valore per la sicurezza è reale, ma risiede nei processi e nell'architettura (o, per un framework, nella skill del linguaggio stesso), non in una difesa fornita da questo catalogo. Sono elencati come riferimento, non come lavoro da fare. - [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) (amplificazione tramite SOAP e WS-Addressing, una variante operativa di DoS senza superficie nel codice) - [Cash Overflow](https://owasp.org/www-community/attacks/Cash_Overflow) - [Spyware](https://owasp.org/www-community/attacks/Spyware), [Trojan Horse](https://owasp.org/www-community/attacks/Trojan_Horse) (malware che colpisce l'utente finale, non una superficie nel codice del progetto verificato. L'aspetto della distribuzione tramite browser si trova in `browser`) - [REST Security](https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html), [REST Assessment](https://cheatsheetseries.owasp.org/cheatsheets/REST_Assessment_Cheat_Sheet.html) - [Web Service Security](https://cheatsheetseries.owasp.org/cheatsheets/Web_Service_Security_Cheat_Sheet.html) - [Cloud Architecture Security](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Cloud_Architecture_Cheat_Sheet.html) (progettazione e compromessi: IAM contro URL firmati, VPC pubbliche e private, confini di fiducia, responsabilità condivisa. A differenza di `container`, non ha una configurazione concreta che una specializzazione controlli) - [Infrastructure as Code Security](https://cheatsheetseries.owasp.org/cheatsheets/Infrastructure_as_Code_Security_Cheat_Sheet.html) (nonostante il nome, riguarda il processo SDLC e gli strumenti per _gestire_ l'IaC: plugin per IDE, analisi statica, analisi delle immagini, CI/CD, firma. Non offre alcun passaggio da pattern non sicuro a forma sicura in un file Terraform o CloudFormation) - [Kubernetes Security](https://cheatsheetseries.owasp.org/cheatsheets/Kubernetes_Security_Cheat_Sheet.html) (_solo la parte di amministrazione del cluster_: RBAC, etcd, API server, admission. La parte di workload e Pod rientra nell'ambito sotto `container`) - [Network Segmentation](https://cheatsheetseries.owasp.org/cheatsheets/Network_Segmentation_Cheat_Sheet.html) (architettura di rete e politiche del firewall) - [Subdomain Takeover Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Subdomain_Takeover_Prevention_Cheat_Sheet.html) (ciclo di vita e monitoraggio del DNS, non codice) - [Secrets Management](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html) (vault, CI/CD, rotazione. L'aspetto dei segreti scritti nel codice è un'analisi deterministica, non una specializzazione di rischio) - [C-Based Toolchain Hardening](https://cheatsheetseries.owasp.org/cheatsheets/C-Based_Toolchain_Hardening_Cheat_Sheet.html) (flag di compilatore, linker e build, senza alcun sink nel sorgente) - [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) (configurazione del gestore globale degli errori per ogni stack. La fuga è la stessa divulgazione che la gestione degli errori già governa) - [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 _(historical)_](https://cheatsheetseries.owasp.org/cheatsheets/Abuse_Case_Cheat_Sheet.html) (progettazione specifica dell'applicazione, senza un unico sink nel codice) - [User Privacy Protection](https://cheatsheetseries.owasp.org/cheatsheets/User_Privacy_Protection_Cheat_Sheet.html) (minimizzazione dei dati, trasparenza, politica di conservazione) - [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) (domini dei sistemi embedded: bus CAN, firmware OTA, integrità di sensori e radio, non sorgente web o API) - [Mobile Application Security](https://cheatsheetseries.owasp.org/cheatsheets/Mobile_Application_Security_Cheat_Sheet.html) (hardening delle piattaforme Android e iOS: archiviazione, biometria, pinning, dati personali. Non ha un'unica superficie nel codice, e l'aspetto del caricamento di codice non attendibile è passato a `interpreter`) - [Threat Modeling](https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html), [Threat Modeling _(community page)_](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: ripara il tracciamento dei rilievi > Ripara la catena quando un file rinominato o spostato confonde il tracciamento di Lagune. Canonico: https://lagune.ai/it-IT/docs/commands/repair Lingua: it-IT Originale: https://lagune.ai/docs/commands/repair Ultimo aggiornamento: 2026-11-03 🧰 Ripara la catena quando un file rinominato o spostato la confonde. **Manutenzione interna, non una fase di sicurezza** Repair non è una sesta fase del flusso lineare. Il suo compito è mantenere coerente il tracciamento. ```prompt # Non accetta input: ripara sempre l'intera catena /lagune-repair ``` ## Come funziona Ogni rilievo di detect è un elemento tracciato che plan, harden e verify portano avanti, ciascuno agendo su di esso e riportandolo per nome. Quel nome, scritto in modo identico come titolo di sezione in ogni artefatto, è la sua identità dall'inizio alla fine. L'unica cosa volatile che il tracciamento conserva sono i percorsi dei file a cui l'elemento punta. Quei percorsi non si trovano da nessun'altra parte, quindi un file rinominato o spostato può rompere il collegamento solo lì, mai in due copie divergenti. Quando succede, repair corregge la mappa (`.lagune/tracking.json`) perché l'identità sopravviva alla rinomina. Legge gli artefatti e la mappa di tracciamento, legge il tuo sorgente solo per scoprire il nuovo percorso di un file rinominato, e non scrive mai contenuti di sicurezza. Nello stesso passaggio, confronta ogni artefatto della memoria con il suo template e segnala ciò che si è discostato, indicando per ognuno la fase che lo corregge. **Suggerimento** - Non tocca né il tuo codice né gli artefatti in prosa, solo il tracciamento. - Raramente lo esegui a mano. Quando una fase nota che la catena è incoerente, esegue repair per te e prosegue. - Il tracciamento che mantiene si trova in `.lagune/tracking.json`, uno stato interno che non modifichi mai a mano. --- # Migrate: sposta un progetto Lagune basato sul manifest alle skill e ai plugin > Sposta un progetto Lagune basato sul manifest al Lagune basato sulle skill, mantenendo il charter, gli artefatti, il tracciamento e le tue specializzazioni. Canonico: https://lagune.ai/it-IT/docs/commands/migrate Lingua: it-IT Originale: https://lagune.ai/docs/commands/migrate Ultimo aggiornamento: 2026-11-03 🔀 Sposta un progetto **Lagune** basato sul manifest al **Lagune** basato sulle skill, mantenendo tutto ciò che hai scritto. **Avviso di deprecazione** Un progetto con un manifest continua a funzionare così com'è fino alla `v1.x`: `npx lagune` passa `init`, `pull`, `update`, `add`, `remove`, `list` e la dashboard a `lagune@0.15.0`, l'ultima versione basata sul manifest. ## Spostalo 1. Assicurati che il lavoro in corso sia nel commit, poi esegui migrate dalla radice del progetto: ```bash npx lagune migrate ``` 2. Fai un commit con le sole modifiche di migrate, così lo spostamento resta un'unica modifica revisionabile. 3. Installa i comandi per il tuo agente, come mostra la [pagina di installazione](https://lagune.ai/it-IT/docs). 4. Se il progetto ha già un artefatto di detect, plan o harden, chiedi a [`/lagune-repair`](https://lagune.ai/it-IT/docs/commands/repair) di riconciliare i vecchi riferimenti al loro interno e nelle tue specializzazioni: ```prompt /lagune-repair Riconcilia le specializzazioni applicate (prima chiamate sub-skill) negli artefatti in `.lagune/memory/` (`detect.md`, `plan.md` e `harden.md`) con i nomi elencati dal nuovo catalogo, e riscrivi ogni chiamata che le mie specializzazioni in `.lagune/catalog/` fanno ai vecchi hook in `.lagune/hooks/` come una chiamata allo strumento `lagune_read` o `lagune_write`. ``` ## Cosa cambia | Prima | Dopo | | --------------------------------------------------------------------- | --------------------------------------------------------------------------------- | | `.lagune/templates/`, `.lagune/hooks/` e `.lagune/specializations.md` | Rimossi: ogni skill porta con sé il suo template e il motore esegue gli hook | | Le copie delle specializzazioni integrate in `.lagune/skills/` | Rimosse: il motore serve quelle integrate | | Le tue specializzazioni in `.lagune/skills/` | Spostate in `.lagune/catalog/` | | `.lagune/skills.json`, l'indice delle tue specializzazioni | Unito a `.lagune/configs.json` | | Le categorie del manifest | Registrate in `.lagune/configs.json` | | I vecchi comandi dell'agente, come `/lagune.detect` | Rimossi: [installare **Lagune**](https://lagune.ai/it-IT/docs) porta quelli nuovi, come `/lagune-detect` | | Il blocco di **Lagune** in `.gitignore` | Rimosso, insieme al file quando non conteneva altro | | `.lagune/proofs/`, ignorata da quel blocco | Tenuta fuori dai commit dal suo `.gitignore` | | `.lagune/manifest.json` | Eliminato, per ultimo | Il tuo lavoro di sicurezza resta com'è: il charter, l'artefatto prodotto da ogni fase e la mappa di tracciamento con i percorsi a cui punta ogni rilievo. ## Domande frequenti ### Devo per forza migrare? Sì. I progetti basati sul manifest sono deprecati e continuano a funzionare solo fino alla v1.x, quindi esegui npx lagune migrate per spostare il tuo. ### Cosa mantiene migrate? Il tuo charter, ogni artefatto delle fasi, la mappa di tracciamento, le tue categorie e le tue specializzazioni. Le specializzazioni si spostano in .lagune/catalog/, e il loro indice si unisce alle tue categorie in .lagune/configs.json. ### Quando installo i nuovi comandi? Dopo migrate, come mostra la pagina di installazione per il tuo agente. Va bene anche installarli prima, perché migrate mantiene il nuovo /lagune. ### Un collega ha già fatto la migrazione. Cosa devo eseguire? Scarica lo spostamento, poi esegui npx lagune migrate una volta. Rimuove ciò che il Lagune basato sul manifest ha lasciato nel tuo clone, che il controllo di versione non ha mai portato, e tiene le tue prove fuori dai commit.