# Lagune > Security-Driven Hardening para cualquier código Lagune es un flujo de trabajo de Security-Driven Hardening (SDH) de código abierto y exclusivamente defensivo. Ayuda a tu agente de IA a reforzar la seguridad de cualquier código, en cualquier lenguaje y en todo momento: el charter fija las reglas de seguridad antes de que empieces a desarrollar, el comando universal /lagune bastiona el trabajo a medida que se escribe y el flujo Blue Team de cinco fases detecta lo que tu sistema hace realmente e impulsa las correcciones que importan en ese contexto. Sus comandos se instalan en tu agente con la CLI de skills, y no necesita clave de API. --- # Instalación: bastionado de seguridad para cualquier agente de IA > Instala Lagune en cualquier proyecto, como plugin si tu agente lo admite o con la CLI de skills en los demás, y elige las especializaciones de seguridad que encajan con él. URL canónica: https://lagune.ai/es-ES/docs Idioma: es-ES Original: https://lagune.ai/docs Última actualización: 2026-11-03 **Lagune** ayuda a tu agente de IA a hacer más seguro un proyecto. Lo pones a trabajar sobre tu código, y el agente averigua qué hace realmente tu sistema y luego te guía por el trabajo de seguridad que importa en su caso. **Lagune** es el primer proyecto de la metodología [Security-Driven Hardening (SDH)](https://lagune.ai/es-ES/docs/references/paper). **Apoya el código abierto** ¿Te encanta **Lagune**? [Danos una ⭐ en **GitHub**](https://github.com/wellwelwel/lagune) ## Elige tu agente - [Claude Code](https://lagune.ai/es-ES/docs/install/claude-code): La herramienta de programación agéntica de Anthropic - [Codex](https://lagune.ai/es-ES/docs/install/codex): El agente de programación de OpenAI - [Cursor](https://lagune.ai/es-ES/docs/install/cursor): El editor de código con IA - [GitHub Copilot](https://lagune.ai/es-ES/docs/install/github-copilot-cli): El compañero de programación con IA de GitHub - [Gemini CLI](https://lagune.ai/es-ES/docs/install/gemini-cli): El agente de terminal de código abierto de Google - [Antigravity](https://lagune.ai/es-ES/docs/install/antigravity-cli): La plataforma de desarrollo agéntico de Google - [OpenCode](https://lagune.ai/es-ES/docs/install/opencode): El agente de programación de código abierto - [Devin for Terminal](https://lagune.ai/es-ES/docs/install/devin-cli): El agente de terminal de Cognition - [Factory Droid](https://lagune.ai/es-ES/docs/install/factory-droid): El agente de desarrollo de software de Factory - [Grok Build](https://lagune.ai/es-ES/docs/install/grok-build): El agente de programación de xAI - [Qwen Code](https://lagune.ai/es-ES/docs/install/qwen-code): El agente de programación para terminal de Qwen - [Kimi Code](https://lagune.ai/es-ES/docs/install/kimi-code): El agente de programación de Moonshot AI - [Muse Code](https://lagune.ai/es-ES/docs/install/muse-code): El agente de programación de Meta - [Pi](https://lagune.ai/es-ES/docs/install/pi): Un agente de programación minimalista para terminal - [Hermes Agent](https://lagune.ai/es-ES/docs/install/hermes-agent): El agente de código abierto de Nous Research - [Universal](https://lagune.ai/es-ES/docs/install/universal): Cline, Kiro CLI, Windsurf, Zed y 66 más **Información** - **Lagune** funciona con **Node.js** por debajo, pero tú usas el lenguaje que quieras. - Para ejecutarlo totalmente sin conexión, instala **Lagune** en tu proyecto con `npm i -D lagune@0.16.0`. ## Categorías El conocimiento de seguridad de **Lagune** llega en forma de [**especializaciones**](https://lagune.ai/es-ES/docs/catalog), agrupadas en [**categorías**](https://lagune.ai/es-ES/docs/categories). - **OWASP** (`owasp`): Bastiona las aplicaciones frente a los riesgos de seguridad que recoge OWASP: inyección, pérdida de control de acceso y fallos de autenticación y criptográficos - **Infraestructura** (`infra`): Bastiona la configuración de contenedores, cargas de trabajo y serverless: Dockerfile, Compose, seguridad de Pods, IAM y desencadenadores de FaaS - **IA / LLM** (`ai`): Bastiona las integraciones de IA y LLM frente a la inyección de prompts y las conexiones inseguras con herramientas, agentes, recuperación de documentos y MCP - **Lovable** (`lovable`): Bastiona las aplicaciones de Supabase generadas por IA (Lovable y similares): huecos en RLS, claves service_role filtradas y valores por defecto inseguros - **JavaScript** (`javascript`): Bastiona el código JavaScript y sus entornos de ejecución frente a la RCE con eval y child_process, el recorrido de directorios y la contaminación de prototipos - **Python** (`python`): Bastiona el código Python frente a la RCE por deserialización de pickle y YAML, el recorrido de atributos con cadenas de formato de str.format y la contaminación de clases - **Rust** (`rust`): Bastiona el código Rust frente a las API unsafe no sólidas, el mal uso de transmute, el desbordamiento de enteros y el comportamiento indefinido en la frontera de FFI - **Java** (`java`): Bastiona el código Java frente a las cadenas de gadgets de deserialización con ObjectInputStream que culminan en la ejecución remota de código - **Ruby** (`ruby`): Bastiona el código Ruby frente a las cadenas de gadgets de deserialización con Marshal.load y YAML que llegan a la ejecución remota de código - **PHP** (`php`): Bastiona el código PHP frente a la evasión de la autenticación por type juggling, las cadenas de gadgets de inyección de objetos y los valores de configuración inseguros por defecto - **Go** (`go`): Bastiona el código Go frente a fallos de interfaces con nil tipado, carreras de datos entre goroutines y concurrencia insegura en rutas críticas para la seguridad - **C / C++** (`c-cpp`): Bastiona el código C y C++ frente a errores de cadena de formato, desbordamientos de búfer y escrituras fuera de límites que permiten ejecutar código - **.NET** (`dotnet`): Bastiona el código .NET y C# frente a la RCE por deserialización con BinaryFormatter y las evasiones del codificador que acaban en XSS Ejecuta `npx lagune write add --categories` con las claves de las categorías que elijas. **Consejo** Un proyecto empieza con `owasp`, y [`/lagune-charter`](https://lagune.ai/es-ES/docs/commands/charter) añade las categorías que justifica su lectura del proyecto. ## Requisitos Necesitas tener [**Node.js (LTS)**](https://nodejs.org/en/download/package-manager) instalado en tu sistema. ## Usa una insignia ✨ ¿Usas **Lagune**? Añade una a tu **README**: **Dos tonos** ![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) ``` **Color sólido** ![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) ``` ## Siguiente paso Descubre qué hace cada una de las [**skills**](https://lagune.ai/es-ES/docs/get-started/commands) de **Lagune**. ## Preguntas frecuentes ### ¿Qué es Lagune? Lagune es un flujo de trabajo de seguridad de código abierto y exclusivamente defensivo que ayuda a tu agente de IA a bastionar cualquier proyecto. Lo pones a trabajar sobre tu código, detecta qué hace realmente tu sistema y luego te guía en las correcciones de seguridad que importan en ese contexto. ### ¿Cómo instalo Lagune? Elige tu agente: Claude Code, GitHub Copilot CLI, Muse Code, Antigravity CLI, Cursor, Kimi Code, OpenCode, Codex CLI, Factory Droid, Grok Build, Devin CLI y Hermes Agent instalan Lagune como plugin, Gemini CLI y Qwen Code como extensión, Pi como paquete, y cualquier otro agente con npx skills add wellwelwel/lagune. Funciona tanto en proyectos nuevos como en los que ya existen. ### ¿Necesito una clave de API para usar Lagune? No. Funciona a través de tu propio agente de IA, así que no hace falta ninguna clave de API. ### ¿Cuáles son los requisitos? Necesitas tener Node.js (LTS) instalado en tu sistema. ### ¿Qué lenguajes de programación admite Lagune? Cualquiera. Lagune funciona con Node.js por debajo, pero audita y bastiona proyectos escritos en cualquier lenguaje de programación. ### ¿Qué añade Lagune a mi proyecto? Una carpeta .lagune/ con el estado de seguridad de tu proyecto, que crea el primer comando que escribe en ella. La CLI de skills también instala los comandos de barra en el proyecto, donde tu agente los lee, mientras que un plugin los mantiene dentro del agente. ### ¿Cómo actualizo Lagune? Igual que lo instalaste. La página de instalación de cada agente explica cómo actualizar Lagune en él, y la CLI de skills lo actualiza con npx skills update. Tus principios de seguridad, los artefactos de las fases y tus propias especializaciones quedan intactos. ### ¿Qué especializaciones usa un proyecto? Las integradas de sus categorías, más las suyas propias. El charter registra las categorías que justifica su lectura del proyecto, y npx lagune write add --categories las cambia. ### ¿Tengo que terminar de desarrollar antes de proteger mi proyecto? No. El comando /lagune bastiona el trabajo a medida que se escribe: acepta cualquier prompt, crea lo que pediste y lo bastiona con valores por defecto seguros, guiado por tus principios de seguridad. El flujo Blue Team de cinco fases audita lo que ya existe. ### ¿Puede Lagune auditar un proyecto que ya existe? Sí. El flujo Blue Team de cinco fases audita lo que ya existe: charter fija tus reglas de seguridad, detect identifica qué hace el sistema y dónde están los riesgos, plan puntúa cada hallazgo y le asigna una corrección, harden aplica las correcciones y verify demuestra que se sostienen y las cierra. ### ¿Qué diferencia hay entre usar Lagune y simplemente pedirle al agente que identifique vulnerabilidades y fallos de seguridad? Un agente que lee el código por su cuenta encuentra lo que parece una vulnerabilidad y pasa por alto lo que parece un control. Una lista de direcciones bloqueadas da la impresión de que alguien ya se ocupó del riesgo, así que nadie comprueba que se deja fuera la mayoría, y el código se publica. Lagune invierte esa presunción: una protección que ya está en el código se considera no demostrada hasta que se comprueba, cada especialización del catálogo recibe un veredicto explícito, y verify pregunta si el riesgo ha desaparecido, no si hay un control. Además, cada hallazgo sigue siendo un único elemento en seguimiento de una ejecución a otra, así que se puede demostrar que está cerrado y darlo de baja, mientras que una petición sin más te da un informe distinto cada vez, sin nada con lo que comparar. ### ¿Qué diferencia hay entre desarrollar con Lagune y simplemente pedirle al agente que escriba código seguro? Pedir código seguro deja en manos del agente decidir qué es seguro, y da por hecho que sabes qué pedir. El requisito suele estar ya dentro de tu petición sin que ninguno de los dos lo vea: pedir una página que muestre los cursos a los que tiene acceso un usuario enuncia una regla de autorización, y una comprobación que nunca se escribe no deja en el código nada que salte a la vista. El comando /lagune carga tus principios de seguridad y las especializaciones que encajan con lo que se va a construir antes de escribir la primera línea, y después vuelve a leer el resultado contrastándolo con la defensa que aplicó. La forma segura rara vez cuesta más que la insegura, así que lo que decide el resultado es saber cuál elegir, y eso es justo lo que llega desde el principio. ### ¿Lagune hace DAST (pruebas dinámicas de seguridad de aplicaciones) o prueba mi aplicación en ejecución? No. Lagune lee el código y nunca ejecuta tu sistema ni le envía peticiones manipuladas. Verify confirma que un control está presente y es correcto en el código fuente, que es una pregunta distinta de si resiste un ataque contra un sistema en funcionamiento, así que "cannot tell from the code" es un veredicto legítimo y no un aprobado silencioso. DAST responde a la pregunta sobre la ejecución y Lagune a la pregunta sobre el código fuente, así que ninguno sustituye al otro. Incluso el comando opcional prove respeta este límite: sus pruebas afirman el comportamiento seguro, nunca un payload de ataque. ### ¿Lagune sustituye a un pentest (test de intrusión)? ¡No, para nada! Un pentest es un encargo autorizado en el que un profesional aplica su propio criterio contra tu sistema en funcionamiento, encadenando hallazgos y explorando la lógica de negocio que ninguna regla por superficie describe. Los hallazgos de un pentest pueden entrar en el flujo Blue Team de Lagune pasándoselos a detect como preocupaciones, de modo que lo que recoge el informe de un profesional se planifica, se bastiona y se verifica. ## Política de seguridad Consulta [SECURITY.md](https://github.com/wellwelwel/lagune/blob/main/SECURITY.md). ## Licencia **Lagune** se distribuye bajo la [Apache License 2.0](https://github.com/wellwelwel/lagune/blob/main/LICENSE). Copyright © 2026-present [Weslley Araújo](https://github.com/wellwelwel) y [colaboradores](https://github.com/wellwelwel/lagune/graphs/contributors). --- # Instalar Lagune en Antigravity CLI como plugin > Instala Lagune en Antigravity CLI como plugin, mantenlo actualizado y permite su motor de antemano. URL canónica: https://lagune.ai/es-ES/docs/install/antigravity-cli Idioma: es-ES Original: https://lagune.ai/docs/install/antigravity-cli Última actualización: 2026-11-03 Instala el plugin desde tu terminal: ```bash agy plugin install https://github.com/wellwelwel/lagune/tree/plugin-antigravity ``` ## Actualización Para actualizar **Lagune**, vuelve a instalarlo: ```bash agy plugin install https://github.com/wellwelwel/lagune/tree/plugin-antigravity ``` ## Comandos Escribe los comandos precedidos del nombre del plugin, como `/lagune:lagune-charter` para `/lagune-charter`. --- **Permisos** El motor se ejecuta mediante dos herramientas: `lagune_read` solo lee tu proyecto y `lagune_write` solo escribe en `.lagune/`. Un comando enviado como primer mensaje de una sesión se ejecuta antes de que se carguen, así que usa **npx** en su lugar. Para permitir de antemano las herramientas y **npx**, añade estas reglas 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.]+)" ] } } ``` ## Preguntas frecuentes ### ¿Cómo instalo Lagune en Antigravity CLI? Ejecuta agy plugin install https://github.com/wellwelwel/lagune/tree/plugin-antigravity. ### ¿Cómo actualizo Lagune en Antigravity CLI? Vuelve a ejecutar agy plugin install https://github.com/wellwelwel/lagune/tree/plugin-antigravity. ### ¿Cómo ejecuto los comandos de Lagune en Antigravity CLI? Escríbelos precedidos del nombre del plugin, como /lagune:lagune-charter. ### ¿Puede Antigravity CLI ejecutar Lagune sin pedir permiso? Sí. Permite mcp(lagune_lagune/lagune_read), mcp(lagune_lagune/lagune_write) y command(regex:npx --yes lagune@[0-9.]+) en la configuración de Antigravity CLI. La regla de npx cubre el comando enviado como primer mensaje de una sesión. --- # Instalar Lagune en Claude Code como plugin > Instala Lagune en Claude Code como plugin, en el terminal, la extensión o la aplicación de escritorio, mantenlo actualizado y permite su motor de antemano. URL canónica: https://lagune.ai/es-ES/docs/install/claude-code Idioma: es-ES Original: https://lagune.ai/docs/install/claude-code Última actualización: 2026-11-03 **Terminal** Instala el plugin desde tu terminal: ```bash claude plugin install lagune --marketplace wellwelwel/lagune ``` O desde una sesión de **Claude Code**: ```text /plugin marketplace add wellwelwel/lagune /plugin install lagune@lagune ``` **Extensión** - Escribe `/plugin` y selecciona **Manage plugins**. - Añade `wellwelwel/lagune` en la pestaña **Marketplaces**. - Instala `lagune` en la pestaña **Plugins**. **Escritorio** - Instala **Lagune** desde el terminal o desde la extensión, y en la extensión elige **Install for you**. - Inicia una sesión nueva en la aplicación de escritorio, que carga los plugins que instalas para ti. ## Actualización **Terminal** Para actualizar **Lagune**, ejecuta: ```bash claude plugin marketplace update lagune claude plugin update lagune@lagune ``` Para mantenerlo actualizado, selecciona **Enable auto-update** en el marketplace `lagune`, dentro de `/plugin`. **Extensión** - Escribe `/plugin` y selecciona **Manage plugins**. - Abre la pestaña **Marketplaces**. - Selecciona el icono de actualizar de `lagune`. **Escritorio** - Actualiza **Lagune** desde el terminal o desde la extensión. - Inicia una sesión nueva en la aplicación de escritorio. ## Comandos Escribe los comandos por su nombre, como `/lagune-charter`, o precedidos del nombre del plugin, como `/lagune:lagune-charter`. --- **Permisos** El motor se ejecuta mediante dos herramientas: `lagune_read` solo lee tu proyecto y `lagune_write` solo escribe en `.lagune/`. Para permitirlas de antemano, añade estas reglas a `.claude/settings.json` para un solo proyecto, o a `~/.claude/settings.json` para todos: ```json { "permissions": { "allow": [ "mcp__plugin_lagune_lagune__lagune_read", "mcp__plugin_lagune_lagune__lagune_write" ] } } ``` Cuando el motor se ejecuta mediante **npx**, como ocurre con **skills.sh**, permite `Bash(npx --yes lagune@*)`. Con el sandbox activado, añade también `registry.npmjs.org` a `sandbox.network.allowedDomains`. ## Preguntas frecuentes ### ¿Cómo instalo Lagune en Claude Code? Ejecuta claude plugin install lagune --marketplace wellwelwel/lagune. En una sesión o en la extensión, añade el marketplace wellwelwel/lagune desde el gestor de plugins e instala lagune. La aplicación de escritorio lo carga en cuanto lo instalas para ti en el terminal o en la extensión. ### ¿Cómo actualizo Lagune en Claude Code? Ejecuta claude plugin marketplace update lagune y después claude plugin update lagune@lagune, o selecciona Enable auto-update en el marketplace lagune, dentro de /plugin. En la extensión, abre Manage plugins desde /plugin y selecciona el icono de actualizar del marketplace lagune. La aplicación de escritorio carga la actualización en su siguiente sesión. ### ¿Cómo ejecuto los comandos de Lagune en Claude Code? Escríbelos por su nombre, como /lagune-charter, o precedidos del nombre del plugin, como /lagune:lagune-charter. ### ¿Puede Claude Code ejecutar Lagune sin pedir permiso? Sí. Permite mcp__plugin_lagune_lagune__lagune_read y mcp__plugin_lagune_lagune__lagune_write en la configuración de Claude Code, además de Bash(npx --yes lagune@*) cuando el motor se ejecuta mediante npx. --- # Instalar Lagune en Codex CLI como plugin > Instala Lagune en Codex CLI como plugin, mantenlo actualizado y ejecuta su motor dentro del sandbox. URL canónica: https://lagune.ai/es-ES/docs/install/codex Idioma: es-ES Original: https://lagune.ai/docs/install/codex Última actualización: 2026-11-03 Instala el plugin desde tu terminal: ```bash codex plugin marketplace add wellwelwel/lagune codex plugin add lagune@lagune ``` ## Actualización Para actualizar **Lagune**, ejecuta: ```bash codex plugin marketplace upgrade lagune ``` ## Comandos Escribe `$` y el comando precedido del nombre del plugin, seguido de tu petición, como `$lagune:lagune-charter` para `/lagune-charter`. Al escribir `$` aparece la lista de comandos, y al elegir uno se inserta su nombre completo. --- **Permisos** El sandbox de **Codex** no tiene acceso a la red. Instala el motor en tu proyecto desde tu propio terminal, una vez y tras cada actualización: ```bash npm i -D lagune@0.16.0 ``` ## Preguntas frecuentes ### ¿Cómo instalo Lagune en Codex CLI? Ejecuta codex plugin marketplace add wellwelwel/lagune y después codex plugin add lagune@lagune. ### ¿Cómo actualizo Lagune en Codex CLI? Ejecuta codex plugin marketplace upgrade lagune. ### ¿Cómo ejecuto los comandos de Lagune en Codex CLI? Escribe $ y el comando precedido del nombre del plugin, seguido de tu petición, como $lagune:lagune-charter. ### ¿Funciona Lagune dentro del sandbox de Codex? Sí, en cuanto instales el motor en tu proyecto con npm i -D lagune@0.16.0 desde tu propio terminal, una vez y tras cada actualización. --- # Instalar Lagune en Cursor como plugin > Instala Lagune en Cursor y en Cursor CLI como plugin, mantenlo actualizado y permite su motor de antemano. URL canónica: https://lagune.ai/es-ES/docs/install/cursor Idioma: es-ES Original: https://lagune.ai/docs/install/cursor Última actualización: 2026-11-03 **Cursor** - Abre **Customize**. - Selecciona **From GitHub Repository** e introduce `https://github.com/wellwelwel/lagune`. - Selecciona **Install** en **Lagune** y elige el ámbito de proyecto o de usuario. **Cursor CLI** - Añade el marketplace desde tu terminal: ```bash agent plugin marketplace add https://github.com/wellwelwel/lagune --git-ref plugin-cursor ``` - Escribe `/plugins` en una sesión de `agent`. - Instala **Lagune**. Si ya tienes **Lagune** instalado en **Claude Code**, **Cursor CLI** lo carga desde ahí. ## Actualización **Cursor** - Abre **Customize**. - Selecciona **Refresh** en el marketplace `lagune`. **Cursor CLI** - Sustituye el marketplace desde tu terminal: ```bash agent plugin marketplace remove lagune agent plugin marketplace add https://github.com/wellwelwel/lagune --git-ref plugin-cursor ``` - Escribe `/plugins` en una sesión de `agent`. - Vuelve a instalar **Lagune**. ## Comandos Escribe los comandos por su nombre, como `/lagune-charter`. --- **Permisos** En **Cursor**, los comandos ejecutan el motor mediante **npx**, que el modo predeterminado, Auto-review, permite sin preguntar. En **Cursor CLI**, el motor se ejecuta mediante dos herramientas: `lagune_read` solo lee tu proyecto y `lagune_write` solo escribe en `.lagune/`. Para permitirlas de antemano, añade estas reglas a `.cursor/cli.json` para un solo proyecto, o a `~/.cursor/cli-config.json` para todos: ```json { "permissions": { "allow": [ "Mcp(plugin-lagune-lagune:lagune_read)", "Mcp(plugin-lagune-lagune:lagune_write)" ] } } ``` Cuando el motor se ejecuta mediante **npx**, como ocurre con **skills.sh**, permite `Shell(npx:--yes lagune@*)`. ## Preguntas frecuentes ### ¿Cómo instalo Lagune en Cursor? En Cursor, abre Customize, selecciona From GitHub Repository, introduce https://github.com/wellwelwel/lagune e instala Lagune. En Cursor CLI, ejecuta agent plugin marketplace add https://github.com/wellwelwel/lagune --git-ref plugin-cursor y después instala Lagune desde /plugins. ### ¿Cómo actualizo Lagune en Cursor? En Cursor, selecciona Refresh en el marketplace lagune, dentro de Customize. En Cursor CLI, elimina el marketplace lagune, vuelve a añadirlo y después vuelve a instalar Lagune desde /plugins. ### ¿Cómo ejecuto los comandos de Lagune en Cursor? Escríbelos por su nombre, como /lagune-charter. ### ¿Puede Cursor ejecutar Lagune sin pedir permiso? Sí. El modo predeterminado de Cursor, Auto-review, ya lo permite. En Cursor CLI, permite Mcp(plugin-lagune-lagune:lagune_read) y Mcp(plugin-lagune-lagune:lagune_write), además de Shell(npx:--yes lagune@*) cuando el motor se ejecuta mediante npx. --- # Instalar Lagune en Devin CLI como plugin > Instala Lagune en Devin CLI como plugin y mantenlo actualizado. URL canónica: https://lagune.ai/es-ES/docs/install/devin-cli Idioma: es-ES Original: https://lagune.ai/docs/install/devin-cli Última actualización: 2026-11-03 Inicia sesión en **Devin** y después instala el plugin desde tu terminal: ```bash devin auth login devin plugins install wellwelwel/lagune ``` ## Actualización Para actualizar **Lagune**, ejecuta: ```bash devin plugins update lagune ``` ## Comandos Escribe los comandos precedidos del nombre del plugin, como `/lagune:lagune-charter` para `/lagune-charter`. El menú `/` también los muestra. ## Preguntas frecuentes ### ¿Cómo instalo Lagune en Devin CLI? Inicia sesión con devin auth login y después ejecuta devin plugins install wellwelwel/lagune. ### ¿Cómo actualizo Lagune en Devin CLI? Ejecuta devin plugins update lagune. ### ¿Cómo ejecuto los comandos de Lagune en Devin CLI? Escríbelos precedidos del nombre del plugin, como /lagune:lagune-charter. El menú / también los muestra. --- # Instalar Lagune en Factory Droid como plugin > Instala Lagune en Factory Droid como plugin, mantenlo actualizado y permite las herramientas de su motor. URL canónica: https://lagune.ai/es-ES/docs/install/factory-droid Idioma: es-ES Original: https://lagune.ai/docs/install/factory-droid Última actualización: 2026-11-03 Instala el plugin desde tu terminal: ```bash droid plugin marketplace add wellwelwel/lagune droid plugin install lagune@lagune ``` ## Actualización Para actualizar **Lagune**, ejecuta: ```bash droid plugin marketplace update lagune droid plugin update lagune@lagune ``` ## Comandos Escribe los comandos por su nombre, como `/lagune-charter`. --- **Permisos** El motor se ejecuta mediante dos herramientas: `lagune_read` solo lee tu proyecto y `lagune_write` solo escribe en `.lagune/`. Cuando **Factory Droid** pregunte, elige permitir siempre cada una. Vuelve a preguntar tras sincronizar un commit nuevo del marketplace `lagune`, algo que puede hacer al arrancar. ## Preguntas frecuentes ### ¿Cómo instalo Lagune en Factory Droid? Ejecuta droid plugin marketplace add wellwelwel/lagune y después droid plugin install lagune@lagune. ### ¿Cómo actualizo Lagune en Factory Droid? Ejecuta droid plugin marketplace update lagune y después droid plugin update lagune@lagune. ### ¿Cómo ejecuto los comandos de Lagune en Factory Droid? Escríbelos por su nombre, como /lagune-charter. ### ¿Puede Factory Droid ejecutar Lagune sin pedir permiso? Sí. Elige permitir siempre lagune_read y lagune_write cuando Factory Droid pregunte. Vuelve a preguntar tras sincronizar un commit nuevo del marketplace lagune. --- # Instalar Lagune en Gemini CLI como extensión > Instala Lagune en Gemini CLI como extensión, mantenlo actualizado y permite su motor de antemano. URL canónica: https://lagune.ai/es-ES/docs/install/gemini-cli Idioma: es-ES Original: https://lagune.ai/docs/install/gemini-cli Última actualización: 2026-11-03 Instala la extensión desde tu terminal: ```bash gemini extensions install https://github.com/wellwelwel/lagune ``` ## Actualización Para actualizar **Lagune**, ejecuta: ```bash gemini extensions update lagune ``` Para mantenerlo actualizado, instálalo con `--auto-update`. ## Comandos Escribe los comandos precedidos del nombre de la extensión, como `/lagune:lagune-charter` para `/lagune-charter`. --- **Permisos** El motor se ejecuta mediante dos herramientas: `lagune_read` solo lee tu proyecto y `lagune_write` solo escribe en `.lagune/`. **Gemini CLI** solo las inicia en una carpeta de confianza. Para permitirlas de antemano, guarda esta regla como `~/.gemini/policies/lagune.toml`: ```toml [[rule]] mcpName = "lagune" toolName = ["lagune_read", "lagune_write"] decision = "allow" priority = 100 ``` Cuando el motor se ejecuta mediante **npx**, como ocurre con **skills.sh**, añade esta regla al mismo archivo: ```toml [[rule]] toolName = "run_shell_command" commandRegex = 'npx --yes lagune@\d+\.\d+\.\d+\s' decision = "allow" priority = 100 ``` ## Preguntas frecuentes ### ¿Cómo instalo Lagune en Gemini CLI? Ejecuta gemini extensions install https://github.com/wellwelwel/lagune. ### ¿Cómo actualizo Lagune en Gemini CLI? Ejecuta gemini extensions update lagune o instala la extensión con --auto-update. ### ¿Cómo ejecuto los comandos de Lagune en Gemini CLI? Escríbelos precedidos del nombre de la extensión, como /lagune:lagune-charter. ### ¿Puede Gemini CLI ejecutar Lagune sin pedir permiso? Sí. Añade una regla de política que permita las herramientas lagune_read y lagune_write del servidor lagune, y otra para run_shell_command con npx --yes lagune@ y una versión cuando el motor se ejecuta mediante npx. --- # Instalar Lagune en GitHub Copilot CLI como plugin > Instala Lagune en GitHub Copilot CLI como plugin y mantenlo actualizado. URL canónica: https://lagune.ai/es-ES/docs/install/github-copilot-cli Idioma: es-ES Original: https://lagune.ai/docs/install/github-copilot-cli Última actualización: 2026-11-03 Instala el plugin desde tu terminal: ```bash copilot plugin marketplace add wellwelwel/lagune copilot plugin install lagune@lagune ``` En un editor, instala **Lagune** para **GitHub Copilot** con [**skills.sh**](https://lagune.ai/es-ES/docs/install/universal). ## Actualización Para actualizar **Lagune**, ejecuta: ```bash copilot plugin marketplace update lagune copilot plugin update lagune@lagune ``` ## Comandos Escribe los comandos por su nombre, como `/lagune-charter`. ## Preguntas frecuentes ### ¿Cómo instalo Lagune en GitHub Copilot CLI? Ejecuta copilot plugin marketplace add wellwelwel/lagune y después copilot plugin install lagune@lagune. ### ¿Cómo actualizo Lagune en GitHub Copilot CLI? Ejecuta copilot plugin marketplace update lagune y después copilot plugin update lagune@lagune. ### ¿Cómo ejecuto los comandos de Lagune en GitHub Copilot CLI? Escríbelos por su nombre, como /lagune-charter. ### ¿Puedo usar Lagune con GitHub Copilot en VS Code? Sí. En VS Code o en otro editor, instala Lagune con skills.sh en lugar del plugin. --- # Instalar Lagune en Grok Build como plugin > Instala Lagune en Grok Build como plugin, mantenlo actualizado y permite su motor de antemano. URL canónica: https://lagune.ai/es-ES/docs/install/grok-build Idioma: es-ES Original: https://lagune.ai/docs/install/grok-build Última actualización: 2026-11-03 Instala el plugin desde tu terminal: ```bash grok plugin install wellwelwel/lagune@plugin-grok --trust ``` ## Actualización Para actualizar **Lagune**, ejecuta: ```bash grok plugin update lagune ``` ## Comandos Escribe los comandos por su nombre, como `/lagune-charter`, o precedidos del nombre del plugin, como `/lagune:lagune-charter`. --- **Permisos** El motor se ejecuta mediante dos herramientas: `lagune_read` solo lee tu proyecto y `lagune_write` solo escribe en `.lagune/`. Para permitirlas de antemano, añade estas reglas a `~/.grok/config.toml`: ```toml [permission] allow = ["MCPTool(lagune__lagune_read)", "MCPTool(lagune__lagune_write)"] ``` Cuando el motor se ejecuta mediante **npx**, como ocurre con **skills.sh**, permite `Bash(npx --yes lagune@*)`. ## Preguntas frecuentes ### ¿Cómo instalo Lagune en Grok Build? Ejecuta grok plugin install wellwelwel/lagune@plugin-grok --trust. ### ¿Cómo actualizo Lagune en Grok Build? Ejecuta grok plugin update lagune. ### ¿Cómo ejecuto los comandos de Lagune en Grok Build? Escríbelos por su nombre, como /lagune-charter, o precedidos del nombre del plugin, como /lagune:lagune-charter. ### ¿Puede Grok Build ejecutar Lagune sin pedir permiso? Sí. Permite MCPTool(lagune__lagune_read) y MCPTool(lagune__lagune_write) en la configuración de Grok Build, además de Bash(npx --yes lagune@*) cuando el motor se ejecuta mediante npx. --- # Instalar Lagune en Hermes Agent como plugin > Instala Lagune en Hermes Agent como plugin y mantenlo actualizado. URL canónica: https://lagune.ai/es-ES/docs/install/hermes-agent Idioma: es-ES Original: https://lagune.ai/docs/install/hermes-agent Última actualización: 2026-11-03 Instala el plugin desde tu terminal: ```bash hermes plugins install wellwelwel/lagune --enable ``` - Cuando **Hermes Agent** te pida confirmar un plugin ajeno a su catálogo, **confírmalo**. - Cuando se ofrezca a instalar las dependencias de **Node.js** del repositorio, **recházalo**. ## Actualización Para actualizar **Lagune**, ejecuta: ```bash hermes plugins update lagune ``` ## Comandos Escribe los comandos precedidos del nombre del plugin, como `/lagune:lagune-charter` para `/lagune-charter` y `/lagune:lagune` para `/lagune`. ## Preguntas frecuentes ### ¿Cómo instalo Lagune en Hermes Agent? Ejecuta hermes plugins install wellwelwel/lagune --enable. Confirma el plugin cuando te lo pida y rechaza instalar las dependencias de Node.js del repositorio. ### ¿Cómo actualizo Lagune en Hermes Agent? Ejecuta hermes plugins update lagune. ### ¿Cómo ejecuto los comandos de Lagune en Hermes Agent? Escríbelos precedidos del nombre del plugin, como /lagune:lagune-charter y /lagune:lagune. --- # Instalar Lagune en Kimi Code como plugin > Instala Lagune en Kimi Code como plugin y mantenlo actualizado. URL canónica: https://lagune.ai/es-ES/docs/install/kimi-code Idioma: es-ES Original: https://lagune.ai/docs/install/kimi-code Última actualización: 2026-11-03 Instala el plugin desde una sesión de **Kimi Code**, elige **Trust and install** y después inicia una sesión nueva para cargarlo: ```text /plugins install https://github.com/wellwelwel/lagune /new ``` ## Actualización Para actualizar **Lagune**, vuelve a instalarlo: ```text /plugins install https://github.com/wellwelwel/lagune /new ``` ## Comandos Escribe los comandos precedidos del nombre del plugin, como `/lagune:lagune-charter` para `/lagune-charter`. El menú `/` los muestra como `/skill:lagune:lagune-charter`, que también funciona. ## Preguntas frecuentes ### ¿Cómo instalo Lagune en Kimi Code? En una sesión de Kimi Code, ejecuta /plugins install https://github.com/wellwelwel/lagune, elige Trust and install y después ejecuta /new. ### ¿Cómo actualizo Lagune en Kimi Code? Vuelve a ejecutar /plugins install https://github.com/wellwelwel/lagune y después /new. ### ¿Cómo ejecuto los comandos de Lagune en Kimi Code? Escríbelos precedidos del nombre del plugin, como /lagune:lagune-charter, o tal como los muestra el menú /, como /skill:lagune:lagune-charter. --- # Instalar Lagune en Muse Code como plugin > Instala Lagune en Muse Code como plugin, mantenlo actualizado y ejecuta su motor dentro del sandbox. URL canónica: https://lagune.ai/es-ES/docs/install/muse-code Idioma: es-ES Original: https://lagune.ai/docs/install/muse-code Última actualización: 2026-11-03 Instala el plugin desde tu terminal: ```bash muse plugins marketplace add lagune wellwelwel/lagune muse plugins install lagune@lagune ``` ## Actualización Para actualizar **Lagune**, refresca el marketplace y vuelve a instalar el plugin: ```bash muse plugins marketplace update lagune muse plugins remove lagune muse plugins install lagune@lagune ``` ## Comandos Escribe los comandos por su nombre, como `/lagune-charter`, o precedidos del nombre del plugin, como `/lagune:lagune-charter`. --- **Permisos** El sandbox de **Muse Code** no puede descargar el motor. Instálalo en tu proyecto desde tu propio terminal, una vez y tras cada actualización: ```bash npm i -D lagune@0.16.0 ``` ## Preguntas frecuentes ### ¿Cómo instalo Lagune en Muse Code? Ejecuta muse plugins marketplace add lagune wellwelwel/lagune y después muse plugins install lagune@lagune. ### ¿Cómo actualizo Lagune en Muse Code? Ejecuta muse plugins marketplace update lagune y después reinstálalo con muse plugins remove lagune y muse plugins install lagune@lagune. ### ¿Cómo ejecuto los comandos de Lagune en Muse Code? Escríbelos por su nombre, como /lagune-charter, o precedidos del nombre del plugin, como /lagune:lagune-charter. ### ¿Funciona Lagune dentro del sandbox de Muse Code? Sí, en cuanto instales el motor en tu proyecto con npm i -D lagune@0.16.0 desde tu propio terminal, una vez y tras cada actualización. --- # Instalar Lagune en OpenCode como plugin > Instala Lagune en OpenCode 1.x y 2.x como plugin y mantenlo actualizado. URL canónica: https://lagune.ai/es-ES/docs/install/opencode Idioma: es-ES Original: https://lagune.ai/docs/install/opencode Última actualización: 2026-11-03 **OpenCode 2.x** Instala el plugin desde tu terminal: ```bash opencode plugin add lagune ``` O añádelo a la lista `plugins` de `opencode.json`: ```json { "plugins": ["lagune"] } ``` **OpenCode 1.x** Instala el plugin en tu proyecto desde tu terminal, o añade `-g` para instalarlo en todos tus proyectos: ```bash opencode plugin lagune ``` O añádelo a la lista `plugin` de `opencode.json`: ```json { "plugin": ["lagune"] } ``` ## Actualización **OpenCode 2.x** Para actualizar **Lagune**, ejecuta: ```bash opencode plugin update lagune opencode reload ``` **OpenCode 1.x** Para actualizar **Lagune**, instala la nueva versión sobre la anterior, añadiendo `-g` si lo instalaste en todos tus proyectos: ```bash opencode plugin lagune@0.16.0 --force ``` ## Comandos **OpenCode 2.x** Escribe `@` y elige el comando, como `@lagune-charter`, y después escribe tu petición en el mismo mensaje. **OpenCode 1.x** Escribe los comandos por su nombre, como `/lagune-charter`. Aparecen en `/skills`, no en el menú `/`. --- **Permisos** El motor se ejecuta mediante dos herramientas: `lagune_read` solo lee tu proyecto y `lagune_write` solo escribe en `.lagune/`. **OpenCode** las ejecuta sin preguntar. ## Preguntas frecuentes ### ¿Cómo instalo Lagune en OpenCode? En OpenCode 2.x, ejecuta opencode plugin add lagune. En OpenCode 1.x, ejecuta opencode plugin lagune, añadiendo -g para instalarlo en todos tus proyectos. ### ¿Cómo actualizo Lagune en OpenCode? En OpenCode 2.x, ejecuta opencode plugin update lagune y después opencode reload. En OpenCode 1.x, ejecuta opencode plugin lagune@0.16.0 --force. ### ¿Cómo ejecuto los comandos de Lagune en OpenCode? En OpenCode 2.x, escribe @ y elige el comando, como @lagune-charter, y después escribe tu petición en el mismo mensaje. En OpenCode 1.x, escríbelos por su nombre, como /lagune-charter, o búscalos en /skills. ### ¿OpenCode pide permiso antes de ejecutar Lagune? No. OpenCode ejecuta las dos herramientas del motor, lagune_read y lagune_write, sin preguntar. --- # Instalar Lagune en Pi como paquete > Instala Lagune en Pi como paquete, desde npm o desde GitHub, y mantenlo actualizado. URL canónica: https://lagune.ai/es-ES/docs/install/pi Idioma: es-ES Original: https://lagune.ai/docs/install/pi Última actualización: 2026-11-03 **npm** Instala el paquete desde tu terminal: ```bash pi install npm:lagune ``` **GitHub** Instala el último commit de **GitHub**, que ejecuta el motor mediante **npx**: ```bash pi install git:github.com/wellwelwel/lagune ``` ## Actualización **npm** Para actualizar **Lagune**, ejecuta: ```bash pi update npm:lagune ``` **GitHub** Para actualizar **Lagune**, ejecuta: ```bash pi update git:github.com/wellwelwel/lagune ``` `pi update --extensions` actualiza todos los paquetes que hayas instalado, mientras que `pi update` a secas actualiza únicamente **Pi**. ## Comandos Escribe los comandos con el prefijo `skill:`, como `/skill:lagune-charter` para `/lagune-charter`. ## Preguntas frecuentes ### ¿Cómo instalo Lagune en Pi? Ejecuta pi install npm:lagune, o pi install git:github.com/wellwelwel/lagune para el último commit de GitHub. ### ¿Cómo actualizo Lagune en Pi? Ejecuta pi update npm:lagune, o pi update git:github.com/wellwelwel/lagune si lo instalaste desde GitHub. pi update --extensions actualiza todos los paquetes que hayas instalado. ### ¿Cómo ejecuto los comandos de Lagune en Pi? Escríbelos con el prefijo skill:, como /skill:lagune-charter. --- # Instalar Lagune en Qwen Code como extensión > Instala Lagune en Qwen Code como extensión, mantenlo actualizado y permite su motor de antemano. URL canónica: https://lagune.ai/es-ES/docs/install/qwen-code Idioma: es-ES Original: https://lagune.ai/docs/install/qwen-code Última actualización: 2026-11-03 Instala la extensión desde tu terminal: ```bash qwen extensions install lagune ``` ## Actualización Para actualizar **Lagune**, ejecuta: ```bash qwen extensions update lagune ``` Para mantenerlo actualizado, instálalo con `--auto-update`. ## Comandos Escribe los comandos precedidos del nombre de la extensión, como `/lagune:lagune-charter` para `/lagune-charter`. --- **Permisos** El motor se ejecuta mediante dos herramientas: `lagune_read` solo lee tu proyecto y `lagune_write` solo escribe en `.lagune/`. Para permitirlas de antemano, añade estas reglas a `.qwen/settings.json` para un solo proyecto, o a `~/.qwen/settings.json` para todos: ```json { "permissions": { "allow": ["mcp__lagune__lagune_read", "mcp__lagune__lagune_write"] } } ``` Cuando el motor se ejecuta mediante **npx**, como ocurre con **skills.sh**, permite `Shell(npx --yes lagune@*)`. ## Preguntas frecuentes ### ¿Cómo instalo Lagune en Qwen Code? Ejecuta qwen extensions install lagune. ### ¿Cómo actualizo Lagune en Qwen Code? Ejecuta qwen extensions update lagune o instala la extensión con --auto-update. ### ¿Cómo ejecuto los comandos de Lagune en Qwen Code? Escríbelos precedidos del nombre de la extensión, como /lagune:lagune-charter. ### ¿Puede Qwen Code ejecutar Lagune sin pedir permiso? Sí. Permite mcp__lagune__lagune_read y mcp__lagune__lagune_write en la configuración de Qwen Code, además de Shell(npx --yes lagune@*) cuando el motor se ejecuta mediante npx. --- # Instalar Lagune en cualquier agente con skills.sh > Instala Lagune en cualquier agente de IA con la CLI de skills y mantenlo actualizado. URL canónica: https://lagune.ai/es-ES/docs/install/universal Idioma: es-ES Original: https://lagune.ai/docs/install/universal Última actualización: 2026-11-03 **Terminal** Instala los comandos de **Lagune** desde tu terminal con [**skills.sh**](https://www.skills.sh/wellwelwel/lagune): ```bash npx skills add wellwelwel/lagune ``` **Prompt** Pega este prompt en tu agente: ```md Ejecuta `npx --yes skills add wellwelwel/lagune` y sigue ahora las instrucciones de skill que genere. Lee su salida completa, redirigiéndola antes a un archivo temporal si hace falta. Resuelve las rutas relativas a partir del directorio de archivos de apoyo que indique. ``` ## Actualización **Terminal** Para actualizar **Lagune**, ejecuta: ```bash npx skills update ``` **Prompt** Para actualizar **Lagune**, pega este prompt en tu agente: ```md Ejecuta `npx --yes skills update -y` y lee su salida completa, redirigiéndola antes a un archivo temporal si hace falta. ``` --- **Una sola vía de instalación por agente** Instala **Lagune** con **skills.sh** o con su **plugin**, nunca con ambos. **Permisos** Los comandos ejecutan el motor como `npx --yes lagune@0.16.0`, y la [página de instalación de cada agente](https://lagune.ai/es-ES/docs) muestra la regla que lo permite de antemano. En un sandbox sin acceso a la red, instala el motor en tu proyecto desde tu propio terminal, una vez y tras cada actualización: ```bash npm i -D lagune@0.16.0 ``` ## Preguntas frecuentes ### ¿Cómo instalo Lagune en cualquier agente de IA? Ejecuta npx skills add wellwelwel/lagune en tu proyecto o pega el prompt de instalación en tu agente. ### ¿Cómo actualizo Lagune si lo instalé con la CLI de skills? Ejecuta npx skills update o pega el prompt de actualización en tu agente. ### ¿Puedo instalar Lagune con la CLI de skills y con un plugin a la vez? No. Con ambos, el agente muestra cada comando dos veces, o usa una copia y oculta la otra. --- # Skills de seguridad para agentes de IA > Las skills que tu agente de IA desbloquea con Lagune: audita un proyecto que ya existe o protege el trabajo nuevo mientras desarrollas, todo ello regido por tus principios de seguridad. URL canónica: https://lagune.ai/es-ES/docs/get-started/commands Idioma: es-ES Original: https://lagune.ai/docs/get-started/commands Última actualización: 2026-11-03 Una vez que [instalas](https://lagune.ai/es-ES/docs) **Lagune**, tu agente de **IA** desbloquea un conjunto de skills. Hay dos formas de usarlas, y ambas se rigen por tus **principios de seguridad**: proteger el trabajo nuevo a medida que lo desarrollas, o ejecutar la auditoría completa sobre un proyecto. **⌨️ Construcción / Desarrollo** No hace falta que termines tu trabajo antes de protegerlo. Usa [**`/lagune`**](https://lagune.ai/es-ES/docs/commands/lagune) para lo que estás escribiendo **ahora mismo**: | Skill | Qué hace por ti | | --------------------------------------------- | ----------------------------------------------------------------------------------------------- | | [**/lagune-charter**](https://lagune.ai/es-ES/docs/commands/charter) | Fija las reglas de seguridad de tu proyecto, la base sobre la que construye `/lagune` | | [**/lagune**](https://lagune.ai/es-ES/docs/commands/lagune) | Crea lo que pides y lo bastiona a medida que se escribe, guiado por tus principios de seguridad | **Úsalo cuando quieras** [**`/lagune`**](https://lagune.ai/es-ES/docs/commands/lagune) respeta tus principios de seguridad cada vez que se ejecuta. Acepta cualquier prompt, crea lo que pediste y lo bastiona con valores por defecto seguros sobre la marcha, no después. --- #### Skills especiales | Skill | Qué hace | | --------------------------------------------------- | -------------------------------------------------------------------------------------------------- | | [**/lagune-specialize**](https://lagune.ai/es-ES/docs/commands/specialize) | Enseña a **Lagune** una nueva especialización de seguridad a partir de artículos, exploits o temas | **🔬 Auditoría: flujo Blue Team** El **flujo Blue Team** completo: leer lo que hace un proyecto, identificar sus riesgos y cerrarlos. Cada fase se apoya en la anterior, así que basta con seguir la lista de arriba abajo: | # | Skill | Qué hace por ti | | --- | --------------------------------------------- | --------------------------------------------------------------------------------------------- | | 1 | [**/lagune-charter**](https://lagune.ai/es-ES/docs/commands/charter) | Fija las reglas de seguridad de tu proyecto, propuestas para ti o adaptadas a lo que le digas | | 2 | [**/lagune-detect**](https://lagune.ai/es-ES/docs/commands/detect) | Lee tu código e identifica qué hace tu sistema y dónde están los riesgos | | 3 | [**/lagune-plan**](https://lagune.ai/es-ES/docs/commands/plan) | Convierte lo que encontró detect en un plan de defensa, con una corrección para cada hallazgo | | 4 | [**/lagune-harden**](https://lagune.ai/es-ES/docs/commands/harden) | Aplica a tu código las correcciones del plan, de forma segura y una a una | | 5 | [**/lagune-verify**](https://lagune.ai/es-ES/docs/commands/verify) | Demuestra que cada corrección aplicada se sostiene y cierra las que superan la prueba | --- #### Skills especiales | Skill | Qué hace | | --------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- | | [**/lagune-specialize**](https://lagune.ai/es-ES/docs/commands/specialize) | Enseña a **Lagune** una nueva especialización de seguridad a partir de artículos, exploits o temas | | [**/lagune-prove**](https://lagune.ai/es-ES/docs/commands/prove) | Convierte cada hallazgo detectado en una prueba ejecutable y exclusivamente defensiva para la divulgación responsable | --- #### Skills internas | Skill | Qué hace | | ------------------------------------------- | ------------------------------------------- | | [**/lagune-repair**](https://lagune.ai/es-ES/docs/commands/repair) | Repara el seguimiento interno de **Lagune** | **Consejo** La seguridad no es un gasto, es una inversión: lo que pones al principio lo ahorras con creces en los incidentes que nunca llegas a tener 🙋🏻‍♂️ ## Preguntas frecuentes ### ¿Qué skills añade Lagune? /lagune, para bastionar el trabajo mientras lo desarrollas, y el flujo de auditoría Blue Team de cinco fases: /lagune-charter, /lagune-detect, /lagune-plan, /lagune-harden y /lagune-verify. Además, /lagune-specialize y /lagune-prove. ### ¿Qué es el flujo Blue Team de Lagune? Una auditoría en cinco fases: charter (fija las reglas), detect (identifica los riesgos), plan (puntúa y planifica las correcciones), harden (aplica las correcciones) y verify (demuestra que se sostienen y las cierra). ### ¿Qué diferencia hay entre /lagune y el flujo de auditoría? /lagune protege el trabajo nuevo mientras lo escribes, sin ningún flujo que seguir. El flujo de auditoría ejecuta las cinco fases en orden sobre un proyecto que ya existe. --- # Dashboard > Consulta los principios de seguridad, los hallazgos y el catálogo de tu proyecto en una vista local y en tiempo real que se abre con un solo comando. URL canónica: https://lagune.ai/es-ES/docs/get-started/dashboard Idioma: es-ES Original: https://lagune.ai/docs/get-started/dashboard Última actualización: 2026-11-03 Ejecuta **Lagune** directamente, sin subcomando, para ver `.lagune/` en una vista interactiva y en tiempo real. Arranca un dashboard y lo abre en un puerto aleatorio: ```bash npx lagune ``` - [x] **Recarga automática** - [x] **Privado** y **local** - [x] Muestra todo lo que contenga `.lagune/`, desde el primer charter - [x] **Gestiona** las categorías del proyecto directamente desde tu navegador - [x] No necesita `node_modules` ni `package.json` 📦 ![Charter en el dashboard de Lagune](https://lagune.ai/img/dashboard/02.webp) ![Hallazgos en el dashboard de Lagune](https://lagune.ai/img/dashboard/03.webp) ![Side quests en el dashboard de Lagune](https://lagune.ai/img/dashboard/04.webp) ![Detalle de un hallazgo en el dashboard de Lagune](https://lagune.ai/img/dashboard/05.webp) ![Catálogo en el dashboard de Lagune](https://lagune.ai/img/dashboard/06.webp) **Consejo** - 🚪 Usa `--port` para indicar un puerto personalizado. - ⏏️ Pulsa `Ctrl+C` para detenerlo. ## Preguntas frecuentes ### ¿Cómo abro el dashboard de Lagune? Ejecuta npx lagune sin subcomando en la raíz de tu proyecto. Arranca una vista en tiempo real de .lagune/ en un puerto aleatorio y la abre en tu navegador. ### ¿El dashboard es privado? Sí. Solo se ejecuta en tu propio equipo, en una dirección local a la que ningún otro ordenador puede acceder. ### ¿Puedo modificar mi proyecto desde el dashboard? Solo sus categorías, desde tu navegador. Todo lo demás que muestra el dashboard es de solo lectura. --- # /lagune: código seguro mientras tu IA lo escribe > Crea lo que pides y lo bastiona a medida que se escribe, guiado por tus principios de seguridad y sin ningún flujo que seguir. URL canónica: https://lagune.ai/es-ES/docs/commands/lagune Idioma: es-ES Original: https://lagune.ai/docs/commands/lagune Última actualización: 2026-11-03 ⌨️ Hace el trabajo que pediste y lo protege a medida que se escribe. **`/lagune`** acepta cualquier prompt en cualquier etapa, crea lo que querías y lo bastiona con valores por defecto seguros antes de devolvértelo. ## Cómo usarlo Añade **`/lagune`** a cualquier prompt y describe el trabajo como siempre lo harías. **📘 Instrucciones para agentes** ```md # Instrucciones de mi proyecto para agentes ## Seguridad - Usa la skill `/lagune` siempre que crees o modifiques código, para que mejore la seguridad por defecto. ``` - Por ejemplo: **AGENTS.md**, **CLAUDE.md**, **.github/copilot-instructions.md**, **.cursorrules**, etc. **💬 Una funcionalidad** ```prompt /lagune permite que los usuarios suban una foto personalizada a su perfil. ``` **💬 Una corrección** ```prompt /lagune no pasa nada cuando el usuario envía el formulario. Averigua qué puede ser y arréglalo. ``` **💬 Una refactorización** ```prompt /lagune desacopla y mejora la lógica del payload ``` **Principios de seguridad opcionales, pero mejor con ellos** **`/lagune`** funciona con principios de seguridad o sin ellos. Con ellos, las reglas propias de tu proyecto dan forma a todo lo que crea. Fíjalas una vez con [`/lagune-charter`](https://lagune.ai/es-ES/docs/commands/charter). ## Cómo funciona Envuelve el trabajo en tres pasos, sin escribir nada en Lagune: 1. Carga tus principios de seguridad, si existen, para que rijan todo el desarrollo, y recurre a una base segura por defecto cuando aún no tienes ninguno. 2. Lista el [catálogo](https://lagune.ai/es-ES/docs/catalog) de tu proyecto y carga solo las especializaciones relacionadas con tu trabajo, el mismo conocimiento bajo demanda que usa el flujo de auditoría. 3. Aplica la defensa a medida que se escribe el código y luego vuelve a leer su propio resultado para confirmar que los controles se sostienen de verdad antes de devolverte el trabajo. El resultado es código que funciona en tu proyecto, seguro desde la primera línea. **Úsalo cuando quieras** Sin detect, sin plan y sin limpieza posterior. **`/lagune`** encaja igual de bien en un esqueleto de proyecto recién creado que en un cambio sobre un código maduro, y bastiona el trabajo sobre la marcha, no después. ## Lo que no hace - No escribe nada en la carpeta `.lagune`, ni artefactos ni seguimiento, así que lo único que produce es el código bastionado que pediste. - No relaja ninguna regla para satisfacer un prompt, así que si lo que pides infringiría uno de tus principios de seguridad, se detiene y te avisa primero, en lugar de construirlo directamente de forma insegura. ## Preguntas frecuentes ### ¿Qué hace /lagune? Acepta cualquier prompt en cualquier etapa, crea lo que pediste y lo bastiona con valores por defecto seguros antes de devolvértelo. Aplica la defensa a medida que se escribe el código, no después. ### ¿Necesito definir principios de seguridad para usar /lagune? No. Funciona con ellos o sin ellos. Con ellos, las reglas propias de tu proyecto dan forma a todo lo que crea. Sin ellos, recurre a una base segura por defecto. ### ¿Qué diferencia hay entre /lagune y el flujo Blue Team? /lagune protege el trabajo nuevo mientras lo escribes, sin ningún flujo que seguir. El flujo Blue Team ejecuta las cinco fases de auditoría en orden sobre un proyecto que ya existe. ### ¿Hace /lagune seguimiento de los hallazgos o escribe artefactos? No. No escribe nada en la carpeta .lagune, ni artefactos ni seguimiento. Lo único que produce es el código bastionado que pediste. ### ¿Cómo hago que mi agente use /lagune automáticamente? Añade al archivo de instrucciones de tu agente (AGENTS.md, CLAUDE.md, .cursorrules y similares) una instrucción que le pida usar la skill /lagune siempre que cree o modifique código. --- # /lagune-charter: define tus principios de seguridad > Establece los principios de seguridad de tu proyecto, las reglas que respetan todas las fases posteriores, y registra las categorías de especializaciones que justifica su lectura del proyecto. URL canónica: https://lagune.ai/es-ES/docs/commands/charter Idioma: es-ES Original: https://lagune.ai/docs/commands/charter Última actualización: 2026-11-03 🧬 Cuéntale a **Lagune** qué es tu proyecto y lo convierte en tus reglas de seguridad (o, si no lo describes, las deduce a partir del propio proyecto). El charter es la capa rectora: un conjunto de principios que ponen la seguridad por delante y que todas las fases posteriores deben respetar. Piensa en él como la comprobación en tiempo de compilación de la postura de seguridad de tu proyecto. ## Cómo usarlo **Describirlo** ```prompt /lagune-charter Mi proyecto es una tienda online de videojuegos. Los clientes añaden productos a un carrito y pagan con tarjeta de crédito o por transferencia bancaria. Pueden ver sus pedidos y el estado de cada uno. ``` **Dejar que Lagune proponga** ```prompt /lagune-charter ``` > _Veo una biblioteca de pagos, un sistema de inicio de sesión y un modelo de pedidos vinculado a un cliente. Parece una tienda online que vende algo. Los clientes pagan y hacen el seguimiento de sus propios pedidos..._ ☁️ ## Lo que deduce **Lagune** toma tu descripción o tu **PRD** como guía, deduce lo que implica para la seguridad y luego lee el proyecto para ir más allá de lo que mencionaste. Por ejemplo: - Un carrito que guarda pedidos implica que hay una **base de datos**: - p. ej., `"¿Dónde se guardan los datos?"`, `"¿Quién puede acceder a ellos?"`, `"¿Se filtran?"`. - Que los clientes puedan ver sus propios pedidos implica algún tipo de **inicio de sesión o control de acceso**: - p. ej., `"¿Puede un cliente acceder a los pedidos de otro?"`, `"¿Están protegidas las sesiones?"`. - Aceptar pagos con tarjeta y por transferencia implica que **hay dinero y datos sensibles en juego**: - p. ej., `"¿Se guardan los datos de las tarjetas?"`, `"¿Se verifican los pagos?"`. Tu descripción y el proyecto se suman: tu descripción marca la intención, y la lectura de las dependencias, el README y la configuración saca a la luz lo que no mencionaste. Si algo importante sigue sin estar claro, **Lagune** te hace una pregunta breve y sencilla en lugar de suponer. A partir de ahí, **Lagune** crea un conjunto de reglas de seguridad a medida para el proyecto, que puedes revisar y ajustar siempre que lo necesites. **Sácale el máximo partido** - También puedes definir tus propias reglas de seguridad para el proyecto. - Cuantos más detalles relevantes des, mejor será el informe final: - Explica el proyecto, cómo funciona y qué ocurre por dentro. - ¿Quién es el usuario final? ¿Qué pueden hacer los usuarios y qué no? - Los detalles de comportamiento valen tanto como los técnicos. - La memoria del charter se guarda en `.lagune/memory/charter.md`. ## Las categorías que registra Las especializaciones, el conocimiento de seguridad que las fases posteriores cargan bajo demanda, se incorporan al [catálogo](https://lagune.ai/es-ES/docs/catalog) de tu proyecto por [categoría](https://lagune.ai/es-ES/docs/categories). Mientras tu proyecto no tenga ninguna categoría registrada, el charter registra cada una que justifique su lectura, como el lenguaje de tu proyecto, las llamadas a un LLM o los contenedores, y las nombra en su resumen. Una vez registradas las categorías, el charter las deja como están y solo menciona las categorías que tu proyecto aún no usa. Cámbialas tú mismo cuando quieras: ```bash npx lagune write add --categories python npx lagune write remove --categories python ``` ## Siguiente paso Con las reglas fijadas, identifica qué hace realmente tu sistema: [`/lagune-detect`](https://lagune.ai/es-ES/docs/commands/detect). ## Preguntas frecuentes ### ¿Qué es el charter en Lagune? El charter es la capa rectora de Lagune, un conjunto de principios que ponen la seguridad por delante y que todas las fases posteriores deben respetar. Piensa en él como la comprobación en tiempo de compilación de la postura de seguridad de tu proyecto. ### ¿Dónde se guarda el charter? En .lagune/memory/charter.md. ### ¿Puedo escribir mis propias reglas en el charter? Sí. Lagune propone reglas a partir de tu descripción y de tu código, y puedes reformularlas, eliminarlas, añadir otras o acotar su alcance. ### ¿El charter elige mis categorías de especializaciones? Solo mientras no haya ninguna registrada. En ese caso registra cada categoría que justifique su lectura, como tu lenguaje o las llamadas a un LLM. Una vez registradas, nunca las cambia. --- # /lagune-detect: identifica qué hace tu sistema y sus riesgos > Lee tu código e identifica qué hace tu sistema y dónde están los riesgos. URL canónica: https://lagune.ai/es-ES/docs/commands/detect Idioma: es-ES Original: https://lagune.ai/docs/commands/detect Última actualización: 2026-11-03 🔬 Descubre qué hace realmente tu sistema y dónde están los riesgos. Detect lee el código y registra solo lo que realmente encuentra, con la evidencia que necesitan las fases posteriores. Su instrucción rectora es detectar, no inventar. ## Cómo usarlo **Análisis completo** ```prompt /lagune-detect ``` **Indicar rutas** ```prompt /lagune-detect src/routes/ src/auth.ts ``` **Describir una preocupación** ```prompt /lagune-detect asegúrate de que los datos de los clientes nunca queden expuestos ``` ## Lo que identifica **Lagune** lee el código e identifica lo que encuentra. Cada hallazgo indica qué es, por qué importa y la evidencia. Por ejemplo: - **Subida de archivos**, el sistema acepta archivos de los usuarios: - _Por qué importa:_ un archivo disfrazado de imagen puede ocultar código malicioso. - _Evidencia:_ el handler de `POST /upload` se fía del tipo MIME que envía el cliente, sin comprobar el tipo real del archivo. - **Inicio de sesión y sesiones**, los usuarios se identifican para acceder a su cuenta: - _Por qué importa:_ una gestión débil de las sesiones permite que alguien se haga con la cuenta de otra persona. - _Evidencia:_ la lógica de emisión de sesiones, que las emite sin fecha de caducidad. Por el camino, detect emite un veredicto para cada especialización del [catálogo](https://lagune.ai/es-ES/docs/catalog) de tu proyecto contrastándola con el código, aplica aquellas cuyo contexto está presente y las registra en **Applied specializations**, la lista que reutilizan harden y verify. Con eso tienes un mapa claro de lo que hace tu sistema y de dónde están los riesgos, listo para que los siguientes pasos actúen sobre él. **Consejo** - Volver a ejecutarlo actualiza el mapa: los hallazgos resueltos desaparecen y entran los nuevos. - El mapa de detect se guarda en `.lagune/memory/detect.md`. ## Siguiente paso Convierte el mapa en un plan: [`/lagune-plan`](https://lagune.ai/es-ES/docs/commands/plan). ## Preguntas frecuentes ### ¿Qué hace /lagune-detect? Lee tu código e identifica qué hace tu sistema y dónde están los riesgos, y registra solo lo que realmente encuentra. Su regla es detectar, no inventar. ### ¿Qué es un hallazgo en Lagune? Un hallazgo es un riesgo detectado, con lo que es, por qué importa y la evidencia en el código. Es la unidad en seguimiento que plan, harden y verify van trasladando de una fase a la siguiente. ### ¿Dónde se guarda el mapa de detect? En .lagune/memory/detect.md. ### ¿Qué especializaciones usa detect? Todas las del catálogo de tu proyecto reciben un veredicto contrastado con el código. Detect aplica aquellas cuyo contexto está presente y las registra en Applied specializations. --- # /lagune-plan: puntúa los hallazgos y planifica las correcciones > Convierte lo que ha encontrado detect en un plan de defensa: evalúa cada hallazgo con una categoría y una puntuación CVSS v4.0, y asígnale una corrección. URL canónica: https://lagune.ai/es-ES/docs/commands/plan Idioma: es-ES Original: https://lagune.ai/docs/commands/plan Última actualización: 2026-11-03 🛡️ Convierte lo que ha encontrado detect en un plan de defensa: evalúa cada hallazgo con una categoría y una puntuación CVSS v4.0, y asígnale la corrección que hay que aplicar. ## Cómo usarlo **Planificar todo** ```prompt /lagune-plan ``` **Indicar rutas** ```prompt /lagune-plan src/routes/upload.ts ``` **Centrarse en una preocupación** ```prompt /lagune-plan dónde podrían filtrarse datos sensibles ``` ## Cómo funciona Esta fase continúa donde lo dejó detect. Detect ya ha averiguado qué hace tu sistema y qué riesgo conlleva cada cosa, así que el plan no repite el riesgo, sino que evalúa su gravedad y decide qué hacer con él. Plan nunca lee el código, lo que obliga a que cada corrección apunte a algo que detect haya detectado de verdad. Evalúa cada hallazgo con el método CVSS v4.0: una categoría, un vector CVSS v4.0 razonado a partir de lo que recogieron detect y el charter y puntuado por el [hook `cvss`](https://lagune.ai/es-ES/docs/hooks/cvss), y el nivel de prioridad en el que cae esa puntuación. Cada corrección indica además el principio del charter que respeta. Por ejemplo: - **Subida de archivos** (Prioridad: **Critical**) - _Categoría:_ subida de archivos sin restricciones (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). - _Por qué esta prioridad:_ cualquiera puede llegar a la subida desde internet, y está en el servidor que guarda los archivos de los clientes. - _Respeta:_ III. Toda entrada se considera no fiable hasta que se valida. - _Corrección:_ comprobar el tipo real y el tamaño del archivo, renombrarlo al guardarlo y almacenar las subidas donde no puedan ejecutarse como código. Con eso tienes una lista de correcciones evaluadas y priorizadas, cada una vinculada a un hallazgo y lista para que la siguiente fase la aplique. La puntuación se calcula, nunca se estima: el vector recoge la exposición del proyecto y lo que está en juego como métricas de entorno (Environmental), y cualquiera puede pegarlo en la calculadora de FIRST o de NVD y obtener de nuevo la misma puntuación. **Consejo** - Se basa por completo en detect. Si un archivo o una preocupación nunca se identificó, te indica que ejecutes primero `/lagune-detect` sobre ello. - Volver a ejecutarlo actualiza el plan: salen las correcciones ya hechas y entran las nuevas. - El plan de defensa está en `.lagune/memory/plan.md`. **Depende de detect** Plan solo trabaja con lo que [`/lagune-detect`](https://lagune.ai/es-ES/docs/commands/detect) ya ha identificado, así que ejecuta detect primero. ## Siguiente paso Aplica el plan: [`/lagune-harden`](https://lagune.ai/es-ES/docs/commands/harden). ## Preguntas frecuentes ### ¿Cómo prioriza Lagune las vulnerabilidades? /lagune-plan evalúa cada hallazgo con una categoría y una puntuación CVSS v4.0 calculada por el hook cvss, y le asigna la corrección que hay que aplicar. ### ¿Lagune usa CVSS v4.0? Sí. Cada hallazgo recibe un vector y una puntuación CVSS v4.0, calculados por el hook cvss con la misma aritmética que la calculadora de FIRST, así que cualquiera puede pegar ahí el vector y obtener de nuevo la puntuación. ### ¿La fase plan lee mi código? No. Plan nunca lee el código, lo que obliga a que cada corrección apunte a algo que detect haya detectado de verdad. --- # /lagune-harden: aplica correcciones de seguridad a tu código > Aplica a tu código las correcciones del plan, de forma segura y de una en una. URL canónica: https://lagune.ai/es-ES/docs/commands/harden Idioma: es-ES Original: https://lagune.ai/docs/commands/harden Última actualización: 2026-11-03 🔧 Aplica a tu código las correcciones del plan, de forma segura y de una en una. ## Cómo usarlo **Aplicar todo** ```prompt /lagune-harden ``` **Indicar rutas** ```prompt /lagune-harden src/routes/upload.ts ``` **Por prioridad** ```prompt /lagune-harden prioridad crítica y alta ``` ## Cómo funciona El plan ya ha decidido cada corrección, así que harden solo tiene que aplicarla. Como es la única fase que toca tu código, avanza con cuidado: aplica las correcciones de una en una para que cada cambio sea fácil de revisar, y nunca debilita un control para que una corrección encaje. Por ejemplo, la corrección de la subida de archivos: - **Subida de archivos** (Estado: **Applied**) - _Qué ha cambiado:_ comprueba el tipo real y el tamaño del archivo, rechaza todo lo inesperado, lo renombra al guardarlo y lo almacena donde no puede ejecutarse como código. - _Dónde:_ la función `handleUpload`, además de la función auxiliar de almacenamiento a la que llama. Si una corrección no se puede aplicar por completo, harden hace lo que puede sin riesgo, marca el resto como **Partial** o **Blocked** y lo deja abierto. **Applied no significa verificado** Applied aún no significa demostrado. Para eso está [verify](https://lagune.ai/es-ES/docs/commands/verify). **Consejo** - Se basa por completo en el plan. Si una corrección o un archivo nunca se planificó, te indica que ejecutes primero `/lagune-plan` sobre ello. - Volver a ejecutarlo concilia el registro: salen los cambios revertidos y entran las correcciones recién aplicadas. - El registro del bastionado está en `.lagune/memory/harden.md`. **Depende de plan y cambia tu código** Harden se basa en [`/lagune-plan`](https://lagune.ai/es-ES/docs/commands/plan). Es la única fase que cambia tu código. ## Siguiente paso Demuestra que cada corrección se sostiene: [`/lagune-verify`](https://lagune.ai/es-ES/docs/commands/verify). ## Preguntas frecuentes ### ¿/lagune-harden cambia mi código? Sí. Es la única fase que toca tu código, y aplica las correcciones del plan de una en una. ### ¿Qué significan Applied, Partial y Blocked? Son el estado que Lagune registra para cada corrección. Applied significa que la corrección se ha hecho, Partial que solo se ha hecho en parte y Blocked que no se ha podido aplicar. Applied aún no significa demostrado. ### ¿Lagune aplica correcciones sin preguntar? Que una edición necesite tu aprobación depende de tu agente y del modo de permisos con el que lo ejecutas, no de Lagune, que no añade ninguna confirmación propia. Aun así, nunca debilita un control para satisfacer una corrección, y si una corrección entrara en conflicto con una regla del charter, se detiene y te avisa antes. --- # /lagune-verify: demuestra que los controles de seguridad se sostienen > Demuestra que cada corrección aplicada se sostiene y cierra las que superen la prueba. URL canónica: https://lagune.ai/es-ES/docs/commands/verify Idioma: es-ES Original: https://lagune.ai/docs/commands/verify Última actualización: 2026-11-03 ⚖️ Demuestra que cada corrección aplicada se sostiene leyendo el código y contrastándolo con lo que registró harden, y cierra las que superen la prueba. ## Cómo usarlo **Verificar todo** ```prompt /lagune-verify ``` **Indicar rutas** ```prompt /lagune-verify src/routes/upload.ts ``` **Por prioridad** ```prompt /lagune-verify prioridad crítica y alta ``` ## Cómo funciona Lee el código en cada punto que registró harden y confirma que de verdad se corresponde con lo que se afirma. La prueba es ese contraste, el código frente al registro. Cada control recibe uno de estos tres veredictos: | Veredicto | Significado | | ---------------------------- | ------------------------------------------------------ | | ✅ Risk closed | El código hace exactamente lo que afirma el registro. | | ❌ Risk not closed | El control sigue abierto. Verify te devuelve a harden. | | ❓ Cannot tell from the code | La evidencia no se ve solo con el código. | Después, con tu confirmación, el riesgo que se demuestra cerrado se da de baja de la cadena. Por ejemplo: - **Subida de archivos** (Veredicto: **✅ Risk closed**) - _Cómo se ha demostrado:_ se ha leído el handler de subida y se ha comprobado que detecta el tipo real del archivo a partir de su contenido, impone un límite de tamaño y rechaza todo lo demás, exactamente como afirma el registro. - _Evidencia:_ la función `handleUpload`, que detecta el tipo real del archivo a partir de su contenido. Si el riesgo no está cerrado, verify lo dice con claridad y te devuelve a [`/lagune-harden`](https://lagune.ai/es-ES/docs/commands/harden), porque la corrección sigue abierta. **Consejo** - Se basa por completo en el registro del bastionado. - Solo lee tu código para juzgarlo, y nunca debilita un control ni reescribe el código para que un veredicto salga favorable. - Volver a ejecutarlo concilia los veredictos: salen los que han quedado obsoletos, y un riesgo que ya no está cerrado se vuelve a señalar. - Cuando se demuestra que un riesgo está cerrado, pregunta una vez y después elimina ese hallazgo de toda la cadena (detect, plan, harden y el seguimiento). - No escribe ningún informe propio: cada veredicto queda en el bloque de su control en `.lagune/memory/harden.md`, donde harden lo lee en la siguiente ejecución. **Depende de harden** Verify se basa en [`/lagune-harden`](https://lagune.ai/es-ES/docs/commands/harden). ## El ciclo se cierra Cuando todo lo que entra en el alcance se ha dado de baja, el ciclo queda en reposo, y solo se reabre cuando cambia el código. La seguridad se puede cerrar, así que el flujo tiene un estado final, no un bucle sin fin. ## Preguntas frecuentes ### ¿Cómo verifica Lagune una corrección? /lagune-verify lee el código y lo contrasta con lo que registró harden, y devuelve uno de tres veredictos: Risk closed, Risk not closed o Cannot tell from the code. ### ¿Qué significa dar de baja un hallazgo? Cuando verify demuestra que un riesgo está cerrado, el hallazgo se da de baja: se elimina de toda la cadena, con tu confirmación, para que deje de procesarse una y otra vez. ### ¿Se puede terminar alguna vez el trabajo de seguridad? Sí. En SDH la seguridad se puede cerrar: un hallazgo que se demuestra cerrado se da de baja, así que el flujo tiene un estado final, no un bucle sin fin. --- # Categorías > Las categorías de especializaciones que puede usar un proyecto de Lagune, desde OWASP hasta el bastionado por lenguaje para JavaScript, Python, Go y Rust, y cómo cambiarlas. URL canónica: https://lagune.ai/es-ES/docs/categories Idioma: es-ES Original: https://lagune.ai/docs/categories Última actualización: 2026-11-03 **Lagune** agrupa sus [**especializaciones**](https://lagune.ai/es-ES/docs/catalog) integradas en **13 categorías**. Las categorías que usa un proyecto deciden qué integradas entran en su [**catálogo**](https://lagune.ai/es-ES/docs/catalog), y se dividen en dos grupos: qué hace el sistema y en qué está escrito. Mientras no haya ninguna categoría registrada, un proyecto usa solo `owasp`. [`/lagune-charter`](https://lagune.ai/es-ES/docs/commands/charter) registra cada categoría que respalda su lectura del proyecto, y tú puedes cambiarlas cuando quieras. ## Qué hace el sistema | Categoría | Clave | Qué bastiona | | --------------- | --------- | --------------------------------------------------------------------------------------------------------------------------------------------- | | OWASP | `owasp` | Los riesgos de seguridad de aplicaciones que sigue OWASP: inyección, pérdida de control de acceso y fallos de autenticación y criptográficos | | Infraestructura | `infra` | Configuración de contenedores, cargas de trabajo y serverless: Dockerfile, Compose, seguridad de Pods, IAM y disparadores de FaaS | | IA / LLM | `ai` | Integraciones de IA y LLM, frente a la inyección de prompts y a conexiones inseguras de herramientas, agentes, recuperación (retrieval) y MCP | | Lovable | `lovable` | Apps de Supabase generadas por IA (Lovable y similares): huecos en RLS, claves `service_role` filtradas y valores por defecto inseguros | ## En qué está escrito | Categoría | Clave | Qué bastiona | | ---------- | ------------ | ---------------------------------------------------------------------------------------------------------------------------------- | | JavaScript | `javascript` | RCE con `eval` y `child_process`, recorrido de directorios y contaminación de prototipos, en todos sus entornos de ejecución | | Python | `python` | RCE por deserialización con `pickle` y YAML, recorrido de atributos con `str.format` y contaminación de clases | | Rust | `rust` | APIs `unsafe` que no son sólidas, mal uso de `transmute`, desbordamiento de enteros y comportamiento indefinido en la frontera FFI | | C / C++ | `c-cpp` | Fallos de cadenas de formato, desbordamientos de búfer y escrituras fuera de límites que permiten ejecutar código | | PHP | `php` | Evasión de la autenticación por type juggling, cadenas de gadgets de inyección de objetos y configuraciones por defecto inseguras | | Go | `go` | Fallos de interfaces typed nil, carreras de datos entre goroutines y concurrencia insegura en código crítico para la seguridad | | Java | `java` | Cadenas de gadgets de deserialización con `ObjectInputStream` que acaban en ejecución remota de código | | Ruby | `ruby` | Cadenas de gadgets de deserialización con `Marshal.load` y YAML que llegan a la ejecución remota de código | | .NET / C# | `dotnet` | RCE por deserialización con `BinaryFormatter` y las formas de eludir el codificador que llevan a XSS | **Consejo** **Lagune** es independiente del lenguaje: todo el flujo lee tu proyecto esté escrito en lo que esté, y estas categorías solo profundizan en los escollos propios de un lenguaje concreto. ## Añade y quita cuando quieras Una categoría es un punto de partida, no un compromiso. Usa las que encajen con el proyecto ahora y cámbialas cuando quieras por su clave, con `write add` y `write remove`. En un terminal, `--categories` sin valor abre un selector interactivo (espacio para marcar o desmarcar, Intro para confirmar, vacío para omitir). Fuera de un terminal, pon las categorías justo después. **Añadir** ```bash npx lagune write add --categories # interactive npx lagune write add --categories owasp npx lagune write add --categories owasp rust ``` **Quitar** ```bash npx lagune write remove --categories # interactive npx lagune write remove --categories owasp npx lagune write remove --categories owasp rust ``` El primer `write add` o `write remove` parte de `owasp`, así que quitar todas las categorías deja una lista vacía, nunca el valor por defecto. Cada cambio queda en `.lagune/configs.json`, de modo que todo el equipo trabaja con el mismo conjunto. ## Consulta qué usa un proyecto `read list --categories` muestra todas las categorías y si el proyecto usa cada una: ```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 el [**Catálogo**](https://lagune.ai/es-ES/docs/catalog) para ver qué especializaciones incluye cada categoría. Tus propias especializaciones, escritas con [`/lagune-specialize`](https://lagune.ai/es-ES/docs/commands/specialize), se suman al catálogo sean cuales sean las categorías. ## Preguntas frecuentes ### ¿Cómo añado una categoría? Pasa la clave de la categoría a --categories, por ejemplo npx lagune write add --categories javascript. Mientras no haya ninguna registrada, el charter también registra las categorías que respalda su lectura del proyecto. ### ¿Puedo usar más de una categoría? Sí. Escríbelas en la misma línea, una detrás de otra. ### ¿Qué categoría debería usar un proyecto? Empieza por owasp, la categoría por defecto, y después añade la de tu lenguaje o tu stack. Las especializaciones solo se cargan bajo demanda, así que una categoría no cuesta nada hasta que una fase necesita alguna de sus especializaciones. --- # Catálogo: especializaciones de seguridad bajo demanda > Cómo se cargan las especializaciones del catálogo de tu proyecto: bajo demanda desde una fase o directamente por ti. URL canónica: https://lagune.ai/es-ES/docs/catalog Idioma: es-ES Original: https://lagune.ai/docs/catalog Última actualización: 2026-11-03 🧠 Las especializaciones de **Lagune** son módulos acotados de conocimiento de seguridad, independientes del lenguaje, que se cargan solo bajo demanda, nunca por defecto. No son comandos. El catálogo de tu proyecto es el conjunto que usa: las especializaciones integradas de sus [categorías](https://lagune.ai/es-ES/docs/categories) más las suyas propias. Las fases detect y verify recurren a ellas mientras se ejecutan, y tú puedes cargar una directamente cuando quieras. **Resumen** *La vista general interactiva del catálogo está en la página web. Todas las especializaciones integradas aparecen en la tabla de abajo.* **Cómo funciona** ## Úsala por tu cuenta Para usar una especialización directamente, pide a tu agente que la cargue con `read catalog ` y escribe la tarea en el mismo prompt. El conocimiento actúa entonces sobre lo que has pedido. Funciona en cualquier prompt, incluso en uno que no tenga nada que ver con el flujo de **Lagune**. Por ejemplo, un prompt directo y libre para generar una colección segura de **RegExp** con **Python**: ```prompt Carga la especialización regex con `npx lagune read catalog regex` y después crea en @src/utils/regex.py una colección de expresiones regulares para validar correos electrónicos y nombres de usuario. ``` Esto usa un hook determinista para comprobar cada **RegExp** frente a **ReDoS**, se queda con las seguras y genera algo como esto: ```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 ``` **Prueba el comprobador de ReDoS** Comprueba tú mismo un patrón en [**devina.io/redos-checker**](https://devina.io/redos-checker). ## Las especializaciones integradas Las especializaciones integradas se agrupan en [**categorías**](https://lagune.ai/es-ES/docs/categories). Este es el conjunto que incluye **Lagune**: | Especialización | Categoría | Enfoque | | --------------------- | --------------------------- | --------------------------------------------------------------------------------------------------------------------- | | `regex` | `owasp` | **ReDoS:** patrones que se disparan con entradas manipuladas. | | `network` | `owasp` | **SSRF y redirecciones:** destinos de peticiones o redirecciones que aporta el usuario. | | `interpreter` | `owasp`, `lovable` | **Inyección de código:** `eval`, inclusión dinámica, despacho por nombre. | | `sql` | `owasp` | **Bases de datos relacionales:** inyección, llamadas en crudo al ORM, privilegios, alcance del motor. | | `path` | `owasp` | **Rutas del sistema de archivos:** recorrido de directorios, byte nulo, flujos de NTFS, plantado de archivos. | | `upload` | `owasp` | **Subida de archivos:** tipo/firma, contenido malicioso, almacenamiento, límites. | | `access-control` | `owasp`, `lovable` | **Autenticación, autorización y sesión:** IDOR, asignación masiva, tenants, sesiones. | | `credential-endpoint` | `owasp`, `lovable` | **Adivinación de credenciales y bots:** fuerza bruta, password spraying, credential stuffing, limitación de intentos. | | `federation` | `owasp` | **Confianza en tokens:** OAuth/OIDC, SAML, validación de JWT, inicio de sesión con QR. | | `http-request` | `owasp` | **Origen de las peticiones:** CSRF, CORS mal configurado, IP de cliente suplantada. | | `transport` | `owasp` | **Seguridad del canal:** configuración de TLS, HTTPS/texto en claro, HSTS, pinning. | | `crypto` | `owasp`, `lovable` | **Criptografía en reposo:** algoritmos débiles o propios, CSPRNG, gestión de claves. | | `secrets` | `owasp`, `lovable` | **Credenciales incrustadas:** claves, tokens y contraseñas escritos tal cual en el código fuente. | | `api-endpoint` | `owasp` | **Superficies no REST:** GraphQL, gRPC, autorización en WebSocket, DoS, esquema. | | `payment` | `owasp`, `lovable` | **Flujo de pago:** verificar la pasarela en el servidor, callbacks firmados, idempotencia. | | `xml` | `owasp` | **Procesamiento de XML:** XXE, entidades externas, expansión billion laughs. | | `csv` | `owasp` | **Inyección de fórmulas:** celdas de hoja de cálculo que empiezan por `=`/`+`/`-`/`@`. | | `container` | `owasp`, `infra` | **Configuración de contenedores:** root, capabilities, montaje del socket, bastionado de la imagen. | | `infra` | `infra` | **Infraestructura como código:** Terraform, Dockerfile, GitHub Actions. | | `serverless` | `owasp`, `infra`, `lovable` | **Funciones FaaS:** IAM de mínimo privilegio, entrada de eventos, contexto, secretos. | | `llm` | `ai`, `lovable` | **Riesgos de IA y LLM:** inyección de prompts, agencia, RAG, MCP, salida. | | `supabase` | `lovable` | **Backend de Supabase:** RLS desactivado por defecto, políticas mal generadas por IA, modelo de claves. | | `browser` | `javascript`, `lovable` | **Riesgos en el cliente:** XSS, CSP, framing, almacenamiento, etc. | | `javascript` | `javascript` | **Riesgos del lenguaje:** RCE, contaminación de prototipos, etc. | | `python` | `python` | **Riesgos del lenguaje:** RCE con `pickle`, contaminación de clases, `-O`, etc. | | `rust` | `rust` | **Solidez de `unsafe`:** UB alcanzable desde código seguro, `transmute`, desbordamiento. | | `java` | `java` | **Deserialización y código móvil:** cadenas de `readObject`, secuestro de objetos. | | `ruby` | `ruby` | **Deserialización y `open`:** reconstrucción de objetos con `Marshal`/YAML, la peculiaridad de las tuberías. | | `php` | `php` | **Type juggling y `unserialize`:** hashes mágicos, cadenas POP. | | `go` | `go` | **Typed nil y carreras de datos:** `nil != nil`, goroutines con memoria compartida. | | `c-cpp` | `c-cpp` | **Cadenas de formato:** `printf(user_input)`, escritura arbitraria (write-what-where) con `%n`. | | `dotnet` | `dotnet` | **Riesgos de la plataforma:** RCE con `BinaryFormatter`, `@Html.Raw`, huecos en los enum. | La mayor parte del conocimiento integrado procede de OWASP. Consulta [**Fuentes de OWASP**](https://lagune.ai/es-ES/docs/references/owasp-sources) para ver la correspondencia completa entre cada especialización y sus páginas canónicas de ataques y de Cheat Sheets de OWASP. Unos pocos módulos específicos de un stack se basan, en cambio, en la guía del propio fabricante: `supabase`, por ejemplo, procede de la documentación de Supabase y de CVE-2025-48757. ## Tus propias especializaciones Las integradas crecen añadiendo un archivo de conocimiento más una fila en el índice, nunca un comando nuevo. Las tuyas se añaden igual, con [`/lagune-specialize`](https://lagune.ai/es-ES/docs/commands/specialize): indícale un artículo o un tema y condensará una nueva especialización en tu proyecto, con el archivo en `.lagune/catalog/` y su entrada en `.lagune/configs.json`. Las tuyas siempre están en el catálogo, sean cuales sean sus categorías, y una tuya prevalece sobre una integrada con el mismo nombre. **Internamente, Lagune carga las especializaciones de forma automática y bajo demanda** Cuando la fase detect o verify se encuentra con un contexto que cubre una especialización, la carga ella misma con `read catalog `. Ocurre automáticamente, como parte de la fase. No tienes que hacer nada a mano para que funcione. ## Descubre qué hay disponible Para listar el catálogo de tu proyecto desde el terminal, con una especialización por línea y sus etiquetas: ```bash npx lagune read catalog # regex: Regular Expression [required] # network: Requests, Webhook, URL Fetch, Socket, IMDS, Redirect # interpreter: Evaluator, Sink, Shell, Dynamic Execution # ... ``` Una especialización `[required]` se aplica siempre, sea cual sea el trabajo. Qué integradas aparecen en la lista depende de las [**categorías**](https://lagune.ai/es-ES/docs/categories) de tu proyecto. **Las especializaciones no se cargan por defecto** Se incorpora el conocimiento pertinente para lo que el proyecto es en realidad, en lugar de ejecutar todas las comprobaciones por defecto. ## Preguntas frecuentes ### ¿Qué es una especialización de Lagune? Un módulo acotado de conocimiento de seguridad, independiente del lenguaje, que se carga solo bajo demanda, nunca por defecto. No es un comando como las skills del agente. ### ¿Qué es el catálogo de un proyecto? Las especializaciones que usa el proyecto: las integradas de sus categorías más las suyas propias. Mientras no haya ninguna categoría registrada, usa solo OWASP. ### ¿Las especializaciones se cargan por defecto? No. Solo se cargan bajo demanda, según lo que el proyecto es en realidad. ### ¿Cómo cargo una especialización directamente? En el mismo prompt de la tarea, pide a tu agente que ejecute npx lagune read catalog . --- # /lagune-specialize: entrena una especialización de seguridad con texto plano > Condensa una fuente o un tema de seguridad que le proporciones en una nueva especialización bajo demanda. URL canónica: https://lagune.ai/es-ES/docs/commands/specialize Idioma: es-ES Original: https://lagune.ai/docs/commands/specialize Última actualización: 2026-11-03 🎓 Enseña a **Lagune** una nueva especialización a partir de una fuente o un tema que le des. Lee el material y lo condensa en una especialización acotada y exclusivamente defensiva, con la misma forma que las [integradas](https://lagune.ai/es-ES/docs/catalog), para que las fases detect y verify la carguen después como cualquier otra. Solo audita y explica: nunca escribe entradas de ataque ni exploits, y nunca toca tu código. **A partir de un artículo** ```prompt # Un enlace o una referencia: Lagune lo condensa en la defensa /lagune-specialize https://owasp.org/www-community/attacks/SQL_Injection ``` **A partir de un exploit** ```prompt # Un ataque como fuente: la especialización sigue siendo la defensa /lagune-specialize "' OR 1=1 -- inserta SQL en el texto de la consulta" ``` **A partir de un tema** ```prompt # O simplemente nombra lo que quieres cubrir /lagune-specialize inyección SQL ``` **Un ataque puede ser la fuente, nunca el resultado** Darle un ataque está bien cuando el objetivo es defenderse de él: la descripción de un exploit es material de estudio que condensa en la defensa. La especialización que genera siempre audita y explica, y nunca produce un exploit funcional, un payload ni una técnica de evasión. ## Qué escribe El resultado son dos archivos en tu proyecto, versionados y revisables junto a tu código: - La especialización, en `.lagune/catalog/.md`, con la misma forma que las [integradas](https://lagune.ai/es-ES/docs/catalog). - Su entrada en `.lagune/configs.json`, donde tu proyecto indexa sus propias especializaciones para que el catálogo las combine con las integradas. Después lista el catálogo para confirmar que la nueva entrada está ahí. Tus propias especializaciones siempre están en el catálogo, sean cuales sean sus categorías. Nunca añades un comando ni tocas el paquete: una nueva especialidad es un archivo de conocimiento más una entrada en el índice, escritos en tu propio proyecto. ## Refina, nunca sobrescribe Especializar un nombre que ya existe, ya sea una integrada como `regex` o una que hayas especializado antes, **concilia** el archivo actual en lugar de sustituirlo. Lee lo que hay, incorpora el nuevo conocimiento, conserva lo que sigue siendo válido y reescribe lo que ha cambiado. No se descarta nada sin revisarlo. Una especialización tuya prevalece sobre una integrada con el mismo nombre, así que puedes afinar una integrada para tu propio proyecto sin perderla. **Consejo** - La nueva especialización se carga exactamente igual que una integrada: las fases detect y verify la recogen bajo demanda, o puedes cargarla tú con `npx lagune read catalog ` y darle una tarea. - Cuando el material tiene un origen identificable (un artículo, un autor, un enlace, un estándar), la especialización lo cita. Un tema sin más no lleva fuente. **Nota** **Solo se ejecuta cuando lo invocas:** el agente nunca lo inicia por su cuenta. ## Preguntas frecuentes ### ¿Cómo añado una especialización de seguridad personalizada? Ejecuta /lagune-specialize con una fuente o un tema. Lo condensa en una especialización exclusivamente defensiva, que escribe en .lagune/catalog/.md junto con su entrada en .lagune/configs.json. ### ¿Lagune puede aprender de la descripción de un exploit? Sí, como fuente, nunca como resultado. Un ataque puede ser la fuente, nunca el producto. Specialize nunca escribe entradas de ataque ni exploits. ### ¿Specialize sobrescribe las especializaciones integradas? No. Refina, nunca sobrescribe. --- # /lagune-prove: prueba de concepto exclusivamente defensiva > Convierte cada hallazgo detectado en una prueba de concepto (PoC) ejecutable y exclusivamente defensiva, con un aviso de seguridad para la divulgación responsable. URL canónica: https://lagune.ai/es-ES/docs/commands/prove Idioma: es-ES Original: https://lagune.ai/docs/commands/prove Última actualización: 2026-11-03 🧪 Convierte cada hallazgo detectado en evidencia ejecutable y exclusivamente defensiva para la divulgación responsable. Para cada hallazgo que recoge el mapa de detect, escribe un aviso de seguridad autocontenido y un test que comprueba el **camino seguro**, de modo que el test falla mientras el problema sigue presente y pasa en cuanto se corrige el código. **Consejo** Los tests de **Lagune** quedan aislados en `.lagune/`, separados de tus propios tests. ## Cómo usarlo **Todos los hallazgos** ```prompt /lagune-prove ``` **Un hallazgo por su nombre** Consulta por su nombre los hallazgos que ya están en seguimiento: ```prompt npx lagune read list --findings # Findings # ... # • Inyección SQL en la búsqueda de usuarios # ... ``` ```prompt # Después, demuestra uno de ellos /lagune-prove Inyección SQL en la búsqueda de usuarios ``` ## Cómo funciona Lee el código fuente al que apunta cada hallazgo y escribe en `.lagune/proofs/` un directorio por cada hallazgo demostrado, con exactamente dos archivos: | Archivo | Qué es | | ---------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | | `report.test.mjs` (o `.cjs`) | El test. Se ejecuta con Poku cuando tu proyecto ya lo usa y, si no, con el ejecutor de tests nativo de Node.js, así que no necesita instalar nada. | | `report.md` | Un aviso de seguridad autocontenido: gravedad, impacto, cómo se reproduce y el comando para ejecutarlo, legible por sí solo. | Las pruebas siempre están en JavaScript, así que siguen siendo portables sea cual sea el lenguaje de tu proyecto. Un índice `README.md` enlaza todas las pruebas y ofrece un único comando para ejecutarlas todas. **Consejo** - Es **opcional y autónomo**: no es una de las cinco fases ni forma parte de la cadena de seguimiento. - Solo escribe en `.lagune/proofs/` y nunca toca los artefactos de las fases ni tu código, que solo lee. - Un hallazgo cuyo test no reproduce el problema se queda sin prueba, y te indica que ejecutes [`/lagune-detect`](https://lagune.ai/es-ES/docs/commands/detect) sobre ese punto para conciliarlo. - Volver a ejecutarlo concilia las pruebas: si un hallazgo ha desaparecido o ya no se reproduce, se elimina su directorio. **Nota** **Solo se ejecuta cuando lo invocas:** el agente nunca lo inicia por su cuenta. **Se basa en detect** Prove lee el mapa de detect que genera [`/lagune-detect`](https://lagune.ai/es-ES/docs/commands/detect), así que ejecuta detect primero. ## Solo defensa, y con autorización Antes de generar nada, confirma que tienes autorización para probar el objetivo, y rechaza cualquier petición de un exploit funcional, de un payload de ataque o de técnicas para evadir la detección. Una prueba demuestra el comportamiento seguro y nunca emite una entrada de ataque. ## De la prueba a la divulgación Los dos archivos de cada hallazgo demostrado van juntos en un **GitHub Gist privado** para informar de la vulnerabilidad. Son evidencia de un problema presente y aún sin divulgar, así que un `.gitignore` dentro de `.lagune/proofs/` los mantiene fuera de todos los commits: compártelos solo a través de ese Gist hasta que los mantenedores lo hayan resuelto. Cerrar un hallazgo en la cadena de **Lagune** sigue siendo tarea de [`/lagune-harden`](https://lagune.ai/es-ES/docs/commands/harden) y [`/lagune-verify`](https://lagune.ai/es-ES/docs/commands/verify): prove genera evidencia, no cierra nada. ## Preguntas frecuentes ### ¿Lagune genera exploits? No. /lagune-prove escribe evidencia exclusivamente defensiva: un test que comprueba el camino seguro, de modo que falla mientras el problema sigue presente y pasa en cuanto se corrige el código, además de un aviso de seguridad para la divulgación responsable. ### ¿Qué genera prove? Dos archivos por hallazgo: un test (report.test.mjs o .cjs) y un aviso de seguridad (report.md). ### ¿Cómo divulgo de forma responsable un fallo que ha encontrado Lagune? Prove escribe un aviso de seguridad autocontenido que puedes compartir por un canal privado, como un GitHub Gist privado, siguiendo la divulgación responsable. --- # Hook agent: detecta bucles de agente sin límite > Analiza un proyecto en busca de llamadas a agentes y LLM sin límite de pasos ni de tiempo, o evalúa una sola llamada, desde la línea de comandos. URL canónica: https://lagune.ai/es-ES/docs/hooks/agent Idioma: es-ES Original: https://lagune.ai/docs/hooks/agent Última actualización: 2026-11-03 El hook `agent` señala **runtimes de agente que iteran en bucle sin límite de turnos, de presupuesto ni de tiempo**, el agujero de autonomía descontrolada que convierte una entrada manipulada en un coste ilimitado o en una escalada por inyección de prompts. **Tiene en cuenta el lenguaje** y cubre los dos ecosistemas de frameworks de agentes: **JavaScript** (el runtime `query` del SDK de agentes de **Claude**) y **Python** (**LangChain**, **LangGraph**, **CrewAI**, **OpenAI Agents**). Es el motor determinista en el que se apoya la [especialización `llm`](https://lagune.ai/es-ES/docs/catalog), y puedes ejecutarlo tú mismo en modo **scan** o **check**. ## Cómo ejecutarlo **Analizar el proyecto** ```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 ``` **Comprobar una llamada** ```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 ``` Cada línea bajo **Uncapped agent loops found** es, en un archivo que importa un SDK de agentes, o bien una llamada al runtime `query` del SDK de agentes de Claude sin límite de turnos, de presupuesto ni de tiempo (JavaScript, sin límite por defecto), o bien la eliminación explícita del límite por defecto de un framework, como `max_iterations=None` / `max_turns=None` (Python, con límite por defecto). En ambos casos, el hook termina con un código de salida distinto de cero. En el Vercel AI SDK, `generateText`/`streamText` usan por defecto un solo paso (`stopWhen: stepCountIs(1)`), así que una llamada sin opciones no puede entrar en bucle y no se señala, y un `db.query(...)` corriente nunca se confunde con una llamada a un agente. Si no encuentra nada, muestra `no uncapped agent loops found`. ## Cómo interpretar el veredicto | Veredicto | Significado | | ---------- | ---------------------------------------------------------------------------------------------------------------------------- | | `uncapped` | Una llamada al runtime `query` sin límite (JS), o la eliminación explícita de un límite (`=None`, Py). | | `safe` | Una llamada a `query` que fija un límite, una generación de un solo paso o la llamada a un framework con límite por defecto. | | `invalid` | El fragmento de código no contiene ninguna llamada a un agente reconocible que evaluar. | ### Opciones de la CLI | Opción | Valor | Descripción | | ----------- | ---------------------- | ---------------------------------------------------------------------------------- | | `--pattern` | un fragmento de código | Comprueba una llamada. Repítela para comprobar varias, con un veredicto por línea. | | `--lang` | un lenguaje | Obligatoria con `--pattern`: `javascript` o `python`. | | `--dir` | un directorio | Limita el análisis a un directorio. Se puede repetir y combinar con `--file`. | | `--file` | un archivo | Limita el análisis a un solo archivo. Se puede repetir y combinar con `--dir`. | Sin ninguna opción, analiza todo el proyecto. `--pattern` necesita `--lang` y no se puede combinar con `--dir` ni con `--file`. **Orientativo, no exhaustivo** Un bucle de agente escrito a mano, en cualquier lenguaje, queda fuera del alcance de un análisis estático. Tómalo como una base sólida, no como un inventario completo. **Consejo** El hook solo decide el límite: el alcance de las capacidades, la mezcla de niveles de confianza y la autorización son cuestiones de criterio que sigue cubriendo la [especialización `llm`](https://lagune.ai/es-ES/docs/catalog). ## Preguntas frecuentes ### ¿Por qué limitar el bucle de un agente? Un agente sin límite puede acabar en una recursión, un coste o una escalada por inyección de prompts sin fin. Fijar maxTurns/maxBudgetUsd/stopWhen/signal lo acota, y el hook agent señala cualquier llamada al runtime query que no fije ninguno. --- # Hook cors: audita los orígenes CORS > Analiza el código fuente en busca de una lista de orígenes CORS permitidos que se pueda eludir, o evalúa si un único valor de origen concede un acceso demasiado permisivo, desde la línea de comandos. URL canónica: https://lagune.ai/es-ES/docs/hooks/cors Idioma: es-ES Original: https://lagune.ai/docs/hooks/cors Última actualización: 2026-11-03 El hook `cors` es el motor determinista en el que se apoya la [especialización `http-request`](https://lagune.ai/es-ES/docs/catalog), y puedes ejecutarlo tú mismo. Funciona en dos modos desde un mismo comando: un **scan**, que analiza el código fuente en busca de una **lista de orígenes permitidos que se puede eludir** (una regex de validación de host que un host atacante consigue burlar), y un **score**, que califica un único valor de **origen CORS** como `wildcard`, `null` o `safe`. ## Analizar un proyecto Sin ninguna opción, analiza todo el proyecto. **Todo el proyecto** ```bash npx lagune read cors ``` **Un directorio** ```bash npx lagune read cors --dir src/server ``` **Un solo archivo** ```bash npx lagune read cors --file internal/auth/origin.go ``` Enumera todas las listas de permitidos que se pueden eludir bajo un único encabezado, agrupadas por archivo. Un validador de host cuyo `.+`/`.*` está en el segmento de autoridad, antes del sufijo del host de confianza (`^https?://.+\.trusted\.com`), deja pasar un host atacante como `your-site.com.attacker.com`. ```text Origin-allowlist patterns with a greedy wildcard (bypassable, review): internal/auth/origin.go ^https?://.+\.trusted\.com ``` Es un indicio que revisar, no un hallazgo cerrado: el texto no permite decidir si la regex controla una decisión de confianza real, así que el análisis nunca cambia el código de salida. Lee cada una y confirma que la lista de permitidos compara por igualdad exacta. Si no encuentra nada, muestra una sola línea. ```bash npx lagune read cors --dir src/clean # => no bypassable origin allowlist found ``` ## Evaluar un origen Pasa cada origen con `--origin`. El hook muestra una palabra por origen y termina con un código de salida distinto de cero ante cualquier `wildcard` o `null`. **Un origen** ```bash npx lagune read cors --origin '*' # => wildcard npx lagune read cors --origin 'null' # => null npx lagune read cors --origin 'https://app.example.com' # => safe ``` **Varios orígenes** Repite `--origin` para evaluar toda una lista de permitidos en una sola llamada, con un veredicto por línea y en el mismo orden. ```bash npx lagune read cors \ --origin 'https://app.example.com' \ --origin '*' \ --origin 'null' # => safe # => wildcard # => null ``` | Veredicto | Significado | | ---------- | ---------------------------------------------------------------------------------------------------------- | | `safe` | No es `*`, `null` ni un glob con `*`. No garantiza que el origen esté bien formado. | | `wildcard` | `*`, un glob de subdominio, host o puerto: cualquier sitio (o un conjunto amplio) puede leer la respuesta. | | `null` | El origen `null`, que los iframes en sandbox y las redirecciones pueden falsificar. | Solo `safe` equivale a permitir, y `--origin` es un oráculo de valores: juzga el valor, no el handler, así que confirma el handler con la especialización `http-request`. ### Opciones de la CLI | Opción | Valor | Descripción | | ---------- | ------------- | ------------------------------------------------------------------------------ | | `--origin` | un origen | Evalúa un valor de origen. Repítela para evaluar varios, uno por línea. | | `--dir` | un directorio | Limita el análisis a un directorio. Se puede repetir y combinar con `--file`. | | `--file` | un archivo | Limita el análisis a un solo archivo. Se puede repetir y combinar con `--dir`. | Sin ninguna opción, analiza todo el proyecto. `--origin` es el modo score y no se puede combinar con `--dir` ni con `--file`. **Lo que no cubre** El análisis detecta la forma de **regex que se puede eludir**, y `--origin` evalúa **valores** de origen. Hay dos patrones del código fuente que quedan fuera de su alcance: el reflejo del `Origin` de la petición (el servidor devuelve el `Origin` entrante tal cual, o lo combina con credenciales) y una lista de permitidos permisiva basada en `endsWith` o en subcadenas. Reconócelos en el código y trátalos como describe la [especialización `http-request`](https://lagune.ai/es-ES/docs/catalog). ## Preguntas frecuentes ### ¿Por qué es peligroso un origen CORS null? Los iframes en sandbox y algunas redirecciones envían Origin: null, así que una lista de permitidos que confía en null da acceso de lectura a esos contextos. El hook cors lo señala junto con el comodín. ### ¿Cómo detecto una lista de orígenes CORS permitidos que se puede eludir? Ejecuta npx lagune read cors sobre el proyecto. Señala cualquier regex de validación de host cuyo comodín voraz esté antes del sufijo de confianza, de modo que un host atacante como your-site.com.attacker.com consigue colarse. --- # Hook crypto: detecta criptografía débil > Analiza un proyecto en busca de primitivas criptográficas débiles, o evalúa un único fragmento de código, desde la línea de comandos. URL canónica: https://lagune.ai/es-ES/docs/hooks/crypto Idioma: es-ES Original: https://lagune.ai/docs/hooks/crypto Última actualización: 2026-11-03 El hook `crypto` señala **primitivas criptográficas débiles** en el punto de llamada: un cifrado obsoleto, un modo inseguro o un hash roto. **Tiene en cuenta el lenguaje**: lee cada archivo según sus propias reglas, así que nunca señala una construcción de Python en un archivo de Rust. Es el motor determinista en el que se apoya la [especialización `crypto`](https://lagune.ai/es-ES/docs/catalog), y puedes ejecutarlo tú mismo en modo **scan** o **check**. ## Cómo ejecutarlo **Analizar el proyecto** ```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 ``` **Comprobar un fragmento** ```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 ``` El análisis muestra hasta dos secciones. **Weak cryptography found** es el conjunto de hallazgos (DES/3DES/RC4/Blowfish/RC2, modo ECB): cada uno es una primitiva de cifrado rota, así que el hook termina con un código de salida distinto de cero. **Cryptography to review manually** es un conjunto de indicios que no puede juzgar por sí solo: un hash MD5/SHA-1 (roto para usos de seguridad, pero legítimo como simple suma de comprobación, así que decide la intención), un RNG no criptográfico en un contexto de seguridad o una comparación vulnerable a ataques de temporización. Si no encuentra nada, muestra `no weak cryptography found`. ## Cómo interpretar el veredicto | Veredicto | Significado | | --------- | --------------------------------------------------------------------------------------------------------------------------- | | `weak` | El fragmento usa una primitiva de cifrado rota (DES/3DES, RC4, Blowfish, RC2 o el modo ECB). | | `review` | Una primitiva cuyo riesgo depende de la intención: un hash MD5/SHA-1 o un RNG no criptográfico en un contexto de seguridad. | | `safe` | El fragmento usa criptografía y no se ha encontrado ninguna primitiva débil. | | `invalid` | El fragmento no contiene ninguna construcción criptográfica reconocible que evaluar. | ### Opciones de la CLI | Opción | Valor | Descripción | | ----------- | ---------------------- | ---------------------------------------------------------------------------------------------------------- | | `--pattern` | un fragmento de código | Comprueba un fragmento. Repítela para comprobar varios, con un veredicto por línea. | | `--lang` | un lenguaje | Obligatoria con `--pattern`: uno de javascript, python, go, java, kotlin, php, ruby, rust, csharp, c, cpp. | | `--dir` | un directorio | Limita el análisis a un directorio. Se puede repetir y combinar con `--file`. | | `--file` | un archivo | Limita el análisis a un solo archivo. Se puede repetir y combinar con `--dir`. | Sin ninguna opción, analiza todo el proyecto. `--pattern` necesita `--lang` y no se puede combinar con `--dir` ni con `--file`. ### Lenguajes compatibles El análisis lee estos lenguajes, identificados por la extensión del archivo, y comprueba cada uno con sus propias API criptográficas. | Lenguaje | Cifrados débiles (hallazgo), hashes y RNG (revisión) | | --------------------------- | ------------------------------------------------------------------------------------------------------------------- | | **JavaScript / TypeScript** | `createCipher`, `CryptoJS.DES/RC4`, `*-ecb` entre comillas; 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()` | **Orientativo, no exhaustivo** Lee el código fuente como texto, así que se le puede escapar una primitiva construida en tiempo de ejecución, oculta tras un alias o escrita de una forma que no reconoce. Toma la tabla como un buen punto de partida, no como un inventario completo. **Consejo** El hook garantiza el mínimo (que estas construcciones existen): la gestión de claves, la reutilización de IV y el relleno de RSA son cuestiones de criterio que sigue cubriendo la [especialización `crypto`](https://lagune.ai/es-ES/docs/catalog). ## Preguntas frecuentes ### ¿Cómo analizo un proyecto en busca de criptografía débil? Ejecuta el hook crypto sin ninguna opción. Los cifrados rotos y el modo ECB son hallazgos que terminan con un código de salida distinto de cero. Un hash MD5/SHA-1 es un indicio que revisar, porque está roto para usos de seguridad pero es legítimo como simple suma de comprobación. ### ¿El hook crypto señala Math.random()? Solo como indicio que revisar en un contexto de seguridad, nunca como hallazgo automático, porque la aleatoriedad es legítima para el jitter o para ordenar elementos de la interfaz. --- # Hook cvss: calcula la puntuación de un vector CVSS v4.0 > Calcula la puntuación de uno o varios vectores CVSS v4.0 desde la línea de comandos, con los mismos cálculos que la calculadora de FIRST, y consulta cada uno explicado en lenguaje llano. URL canónica: https://lagune.ai/es-ES/docs/hooks/cvss Idioma: es-ES Original: https://lagune.ai/docs/hooks/cvss Última actualización: 2026-11-03 El hook `cvss` calcula la puntuación de un **vector CVSS v4.0** y muestra esa puntuación y su franja de gravedad, la calificación que [`/lagune-plan`](https://lagune.ai/es-ES/docs/commands/plan) escribe en cada corrección y [`/lagune-prove`](https://lagune.ai/es-ES/docs/commands/prove) en cada aviso de seguridad. Es el motor determinista que produce esas calificaciones, con los mismos cálculos que la [calculadora de FIRST](https://www.first.org/cvss/calculator/4.0), y puedes ejecutarlo tú mismo. ## Cómo ejecutarlo Pasa cada vector con `--vector`. El hook muestra una línea por vector: su puntuación y su franja. **Un vector** ```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 ``` **Varios vectores** Repite `--vector` para puntuar varios a la vez, con una línea para cada uno y en el mismo orden. ```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 ``` **En lenguaje llano** Añade `--explain` para ver cada métrica explicada en lenguaje llano. Cuando las métricas de amenaza o de entorno cambian la puntuación, primero aparece la puntuación base por sí sola. ```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 # => ... ``` ## Cómo interpretar el resultado | Franja | Puntuación | | ---------- | ---------- | | `None` | 0.0 | | `Low` | 0.1 a 3.9 | | `Medium` | 4.0 a 6.9 | | `High` | 7.0 a 8.9 | | `Critical` | 9.0 a 10.0 | Un vector que solo tiene métricas base puntúa el fallo en sí, suponiendo lo peor: todos los requisitos de seguridad en High y el fallo explotado activamente. Las métricas de entorno (`MAV` y las demás métricas modificadas, además de `CR`, `IR` y `AR`) la ajustan a un despliegue concreto, y la métrica de amenaza (`E`), a lo que se sabe sobre su explotación. Con un vector no válido, el hook muestra `invalid vector:` y qué falla, y termina con un código de salida distinto de cero. ### Opciones de la CLI | Opción | Valor | Descripción | | ----------- | -------------------- | --------------------------------------------------------------------------------------------- | | `--vector` | un vector `CVSS:4.0` | Puntúa un vector. Repítela para puntuar varios, con una línea por vector y en el mismo orden. | | `--explain` | | Añade cada métrica en lenguaje llano debajo de cada línea de calificación. | Se necesita al menos un `--vector`. El vector nunca va como argumento posicional suelto, así que no se puede confundir con una opción. **Por qué como valor de una opción** Cada vector se pasa como valor de una opción, nunca interpolado en el comando. Un valor con comillas o comillas invertidas queda inerte y no puede inyectar nada en la shell. Escríbelo siempre entre comillas simples para que tu shell no lo expanda antes. **Lo que no cubre** Solo CVSS v4.0: un vector v2.0, v3.0 o v3.1 se rechaza en lugar de puntuarse, porque **Lagune** califica todos los hallazgos en v4.0. **Consejo** La validación de la fase plan repite estos mismos cálculos en cada línea CVSS, así que una puntuación que ya no corresponde a su vector se detecta antes de aceptar el plan. ## Preguntas frecuentes ### ¿Cómo calcula Lagune una puntuación CVSS? El hook cvss sigue la calculadora de referencia de FIRST para CVSS v4.0, así que un vector obtiene exactamente la misma puntuación que en el sitio web de FIRST. ### ¿Puedo puntuar con él un vector CVSS v3.1? No. Lagune califica todos los hallazgos en CVSS v4.0, y el hook rechaza cualquier otra versión en lugar de puntuarla. ### ¿Qué hace la opción --explain? Explica cada métrica en lenguaje llano y muestra la puntuación base junto a la global, para que cualquiera pueda ver qué dice el vector y cuánto ha movido la puntuación el contexto del proyecto. --- # Hook infra: detecta errores de configuración en IaC > Analiza Terraform, Dockerfiles y GitHub Actions en busca de errores de configuración, o evalúa un único fragmento de código, desde la línea de comandos. URL canónica: https://lagune.ai/es-ES/docs/hooks/infra Idioma: es-ES Original: https://lagune.ai/docs/hooks/infra Última actualización: 2026-11-03 El hook `infra` señala **errores de configuración en la infraestructura como código** que se pueden determinar a partir del propio archivo: una red abierta a todo el mundo, un permiso con comodín, un secreto en un manifiesto, un contenedor que se ejecuta como root, un valor no fiable en una shell de CI. Solo lee archivos de IaC (`.tf`/`.tf.json`/`.hcl`, `Dockerfile*`, `.github/workflows/**`). Es el motor determinista en el que se apoya la [especialización `infra`](https://lagune.ai/es-ES/docs/catalog), en modo **scan** o **check**. ## Cómo ejecutarlo **Analizar el proyecto** ```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 ``` **Comprobar un fragmento** Pasa el fragmento con `--pattern` y su 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 ``` El análisis muestra hasta dos secciones. **Infrastructure risks found** hace que el hook termine con un código de salida distinto de cero y reúne los defectos que se pueden determinar (una regla de entrada desde `0.0.0.0/0` en un puerto sensible, una instrucción IAM con comodín, un secreto en un manifiesto, `encrypted = false`, un módulo git sin versión fijada, una imagen que se ejecuta explícitamente como root, un `curl | sh`, una inyección de scripts en CI, `permissions: write-all`). **Infrastructure hardening advisories** no cambia el código de salida (una etiqueta de imagen base mutable, una acción fijada por etiqueta). Si no encuentra nada, muestra `no infrastructure risks found`. ## Cómo interpretar el veredicto El modo check muestra la etiqueta de mayor gravedad que ha detectado (por ejemplo `public-ingress`, `iam-wildcard`, `root-user`, `curl-pipe`, `script-injection`, `write-all`), una etiqueta de aviso (`mutable-tag`, `unpinned-action`) o `safe`. Solo una etiqueta con gravedad de hallazgo hace que termine con un código de salida distinto de cero. ### Opciones de la CLI | Opción | Valor | Descripción | | ----------- | ----------------------------------------------- | ------------------------------------------------------------------------------ | | `--pattern` | un fragmento de código | Comprueba un fragmento. Requiere `--kind`. Repítela para comprobar varios. | | `--kind` | `terraform` \| `dockerfile` \| `github-actions` | El tipo con el que se evalúa el fragmento. | | `--dir` | un directorio | Limita el análisis a un directorio. Se puede repetir y combinar con `--file`. | | `--file` | un archivo | Limita el análisis a un solo archivo. Se puede repetir y combinar con `--dir`. | Sin ninguna opción, analiza todos los archivos de IaC del proyecto. `--pattern` no se puede combinar con `--dir` ni con `--file`. **Consejo** El hook detecta los casos evidentes y decidibles: la ausencia de cifrado, la exposición de `pull_request_target` y el alcance IAM adecuado son cuestiones de criterio que sigue cubriendo la [especialización `infra`](https://lagune.ai/es-ES/docs/catalog). ## Preguntas frecuentes ### ¿Qué archivos de infraestructura lee el hook infra? Los de Terraform/HCL (.tf, .tf.json, .hcl), los Dockerfiles y los YAML de flujos de trabajo y de acciones de GitHub Actions dentro de .github/. Llega a esos archivos aunque los analizadores de código fuente se los salten. --- # Hook interpreter: señala sinks de ejecución dinámica de código > Analiza un proyecto en busca de sinks de ejecución dinámica de código en varios lenguajes, o evalúa un único fragmento de código, desde la línea de comandos. URL canónica: https://lagune.ai/es-ES/docs/hooks/interpreter Idioma: es-ES Original: https://lagune.ai/docs/hooks/interpreter Última actualización: 2026-11-03 El hook `interpreter` señala **sinks de ejecución dinámica de código**: construcciones que convierten datos en código que se ejecuta o que se los pasan a una shell, desde `eval` hasta la deserialización nativa. Tiene en cuenta el lenguaje, ya que lee cada archivo según sus propias reglas. Es el motor determinista en el que se apoya la [especialización `interpreter`](https://lagune.ai/es-ES/docs/catalog), y puedes ejecutarlo tú mismo en modo **scan** o **check**. ## Cómo ejecutarlo **Analizar el proyecto** ```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 ``` **Comprobar un fragmento** ```bash npx lagune read interpreter --lang javascript --pattern 'eval(x)' # => careful npx lagune read interpreter --lang python --pattern 'json.loads(x)' # => safe ``` Estos sinks son de doble uso: un análisis estático no puede decidir si una entrada influida por un atacante llega a alguno de ellos, así que cada coincidencia es una **advertencia que revisar**, nunca un hallazgo confirmado. El análisis muestra una única sección, **Dynamic-execution sinks to review**, agrupada por archivo. Si no encuentra nada, muestra `no dynamic-execution sinks found`. **¡Lee el código señalado, nunca lo ejecutes!** Estudia cada sink de forma **estática**, rastreando si una entrada no fiable llega hasta él. Nunca ejecutes ni pases por `eval` el código señalado, ni ningún código remoto o descargado en tiempo de ejecución que este cargue, para "probar" lo que hace. ## Cómo interpretar el veredicto | Veredicto | Significado | | --------- | ------------------------------------------------------------------------------------------------------------------ | | `careful` | El fragmento contiene un sink de ejecución dinámica propio de su lenguaje. Revísalo leyéndolo, nunca ejecutándolo. | | `safe` | No se ha encontrado ningún sink de ejecución dinámica para el lenguaje indicado. | ### Opciones de la CLI | Opción | Valor | Descripción | | ----------- | ---------------------- | ---------------------------------------------------------------------------------------------------------- | | `--pattern` | un fragmento de código | Comprueba un fragmento. Repítela para comprobar varios, con un veredicto por línea. | | `--lang` | un lenguaje | Obligatoria con `--pattern`: uno de javascript, python, php, ruby, java, kotlin, go, rust, c, cpp, csharp. | | `--dir` | un directorio | Limita el análisis a un directorio. Se puede repetir y combinar con `--file`. | | `--file` | un archivo | Limita el análisis a un solo archivo. Se puede repetir y combinar con `--dir`. | Sin ninguna opción, analiza todo el proyecto. `--pattern` necesita `--lang` y no se puede combinar con `--dir` ni con `--file`. ### Lenguajes compatibles El análisis lee estos lenguajes, identificados por la extensión del archivo, y comprueba cada uno con su propio conjunto de sinks de ejecución dinámica. | # | Lenguaje | Extensiones | Sinks que señala | | --- | --------------------------- | ------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1 | **JavaScript / TypeScript** | `.js`, `.jsx`, `.mjs`, `.cjs`, `.ts`, `.tsx`, `.mts`, `.cts`, `.astro`, `.vue`, `.svelte`, `.marko`, `.riot` | `eval()`, constructor Function, `setTimeout`/`setInterval` con el cuerpo en una cadena, módulo `vm`, exec de `child_process`, `require()` dinámico, `import()` dinámico | | 2 | **Python** | `.py`, `.pyi` | `eval`/`exec`, `__import__()`, `os.system`/`os.popen`, `subprocess` `shell=True`, `pickle.load`/`loads`, `yaml.load` (inseguro) | | 3 | **Ruby** | `.rb` | familia eval (`instance_eval`/`class_eval`/`module_eval`/`eval`), `system`/`exec`, comillas invertidas 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()` sobre una cadena, `create_function()`, ejecución en shell (`system`/`exec`/`shell_exec`/`passthru`/`popen`/`proc_open`), `call_user_func`/`call_user_func_array`, `include`/`require` con una ruta construida en tiempo de ejecución | | 6 | **Rust** | `.rs` | `Command::new`, `process::Command` | | 7 | **Java** | `.java` | `Runtime.exec`, `ProcessBuilder`, `ScriptEngine`, `ObjectInputStream.readObject` | | 8 | **Kotlin** | `.kt`, `.kts` | Los sinks de la JVM: `Runtime.exec`, `ProcessBuilder`, `ScriptEngine`, `ObjectInputStream.readObject` | | 9 | **C#** | `.cs` | `Process.Start` / `new Process`, `BinaryFormatter`, `Assembly.Load` | | 10 | **C** | `.c`, `.h` | `system()`, `popen()`, la familia `exec*` (`execl`, `execve`, `execvp`, …) | | 11 | **C++** | `.cc`, `.cpp`, `.cxx`, `.hpp`, `.hh`, `.hxx` | `system()`, `popen()`, la familia `exec*` (`execl`, `execve`, `execvp`, …) | **Orientativo, no exhaustivo** Lee el código fuente como texto, así que se le puede escapar un sink construido en tiempo de ejecución, oculto tras un alias o escrito de una forma que no reconoce. Toma la tabla como un buen punto de partida, no como un inventario completo. **Consejo** El hook garantiza el mínimo (que estos sinks existen y dónde están): decidir si un valor no fiable llega realmente a alguno es la cuestión de criterio que cubre la [especialización `interpreter`](https://lagune.ai/es-ES/docs/catalog). ## Preguntas frecuentes ### ¿El hook interpreter confirma una vulnerabilidad? No. Señala los sinks de ejecución dinámica como advertencias que revisar, nunca como hallazgos confirmados, porque un análisis estático no puede decidir si una entrada influida por un atacante llega al sink. ### ¿Qué lenguajes cubre el hook interpreter? Lee los lenguajes de la tabla de lenguajes compatibles, identificados por la extensión del archivo, y comprueba cada uno con su propio conjunto de sinks. Los demás lenguajes no producen ningún sink. --- # Hook jwt: detecta verificaciones de JWT sin algoritmo fijado > Analiza un proyecto en busca de verificaciones de JWT que no fijan el algoritmo, o evalúa una sola llamada, desde la línea de comandos. URL canónica: https://lagune.ai/es-ES/docs/hooks/jwt Idioma: es-ES Original: https://lagune.ai/docs/hooks/jwt Última actualización: 2026-11-03 El hook `jwt` señala las **verificaciones de JWT que no fijan el algoritmo**, el agujero de la confusión de algoritmos, en el que un verificador se fía de la cabecera `alg` del propio token, y las **verificaciones desactivadas por completo**. **Tiene en cuenta el lenguaje**: lee cada archivo según su propia biblioteca de JWT. Es el motor determinista en el que se apoya la [especialización `federation`](https://lagune.ai/es-ES/docs/catalog), y puedes ejecutarlo tú mismo en modo **scan** o **check**. ## Cómo ejecutarlo **Analizar el proyecto** ```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 ``` **Comprobar una llamada** ```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 ``` Cada línea bajo **Unpinned JWT verification found** es una llamada de verificación que no define ninguna lista de permitidos `algorithms` (cuando la biblioteca la necesita), que acepta una insegura (`none`, o un algoritmo asimétrico mezclado con HMAC) o que desactiva directamente la comprobación de la firma, de modo que se fía del `alg` del propio token. Es una exposición confirmada, así que el hook termina con un código de salida distinto de cero. Si no encuentra nada, muestra `no unpinned JWT verification found`. ## Cómo interpretar el veredicto | Veredicto | Significado | | ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | | `unpinned` | Una llamada de verificación sin lista de algoritmos permitidos (cuando hace falta una), con una lista insegura o con la verificación desactivada. | | `safe` | Una llamada de verificación que fija una lista segura de algoritmos permitidos, o cuya biblioteca la fija implícitamente. | | `invalid` | El fragmento de código no contiene ninguna llamada de verificación reconocible que evaluar. | ### Opciones de la CLI | Opción | Valor | Descripción | | ----------- | ---------------------- | -------------------------------------------------------------------------------------------------- | | `--pattern` | un fragmento de código | Comprueba una llamada. Repítela para comprobar varias, con un veredicto por línea. | | `--lang` | un lenguaje | Obligatoria con `--pattern`: uno de javascript, python, go, java, kotlin, php, ruby, rust, csharp. | | `--dir` | un directorio | Limita el análisis a un directorio. Se puede repetir y combinar con `--file`. | | `--file` | un archivo | Limita el análisis a un solo archivo. Se puede repetir y combinar con `--dir`. | Sin ninguna opción, analiza todo el proyecto. `--pattern` necesita `--lang` y no se puede combinar con `--dir` ni con `--file`. ### Lenguajes compatibles El análisis lee estas bibliotecas, identificadas por la extensión del archivo. Como algunas fijan el algoritmo de forma implícita (no tener una lista explícita es correcto), la regla "sin lista de permitidos ⇒ unpinned" solo se aplica donde la biblioteca espera una lista explícita, así que nunca se señala una llamada bien configurada. | Lenguaje | Biblioteca | ¿Señala como unpinned la falta de lista? | Siempre señala | | --------------------------- | ----------------------- | ------------------------------------------------------------------ | ----------------------------------------------- | | **JavaScript / TypeScript** | jsonwebtoken, jose | Sí | `none`, mezcla de asimétrico y HMAC | | **Python** | PyJWT, python-jose | Sí (PyJWT la exige, python-jose usa `algorithms=None` por defecto) | `none`, `verify_signature: False` | | **Go** | golang-jwt | Sí (sin `WithValidMethods`) | `none`, `ParseUnverified` | | **Ruby** | ruby-jwt | Sí | `none`, `verify = false` | | **Java / Kotlin** | jjwt, nimbus | No (se deriva de la clave) | `none`, un parser sin firma o `unsecured` | | **PHP** | firebase/php-jwt | No (`Key` incluye el algoritmo) | `none` | | **Rust** | jsonwebtoken | No (`Validation` exige uno) | `none`, `insecure_disable_signature_validation` | | **C#** | Microsoft.IdentityModel | No (parámetros en varias líneas) | `none`, `RequireSignedTokens = false` | **Consejo** El hook solo decide si el algoritmo está fijado: las comprobaciones de claims, de claves y de flujos son cuestiones de criterio que sigue cubriendo la [especialización `federation`](https://lagune.ai/es-ES/docs/catalog). ## Preguntas frecuentes ### ¿Qué es la confusión de algoritmos en JWT? Un verificador que lee el algoritmo de la cabecera del token permite que un atacante cambie RS256 por HS256 y firme con la clave pública. Fijar en el código una lista segura de algoritmos permitidos lo evita, y el hook jwt señala cualquier llamada de verificación que no fije ninguna o que fije una insegura. --- # Hook network: evalúa el riesgo de SSRF de las URL > Evalúa el riesgo de SSRF de uno o varios destinos de petición, directamente desde la línea de comandos. URL canónica: https://lagune.ai/es-ES/docs/hooks/network Idioma: es-ES Original: https://lagune.ai/docs/hooks/network Última actualización: 2026-11-03 El hook `network` decide si el destino de una petición hecha desde el servidor está a salvo de **SSRF** (una petición que se puede dirigir contra servicios internos, metadatos de la nube o hosts privados). Es el motor determinista en el que se apoya la [especialización `network`](https://lagune.ai/es-ES/docs/catalog), y puedes ejecutarlo tú mismo. ## Cómo ejecutarlo Pasa cada destino con `--url`. El hook muestra una palabra por destino, que se interpreta con la tabla de más abajo. **Un destino** ```bash npx lagune read network --url 'http://example.com/' # => safe npx lagune read network --url 'http://0x7f000001/' # => private-target ``` **Varios destinos** Repite `--url` para evaluar toda una lista de permitidos o de bloqueados en una sola llamada, con un veredicto por línea y en el mismo orden. ```bash npx lagune read network \ --url 'http://example.com/' \ --url 'http://[::1]/' \ --url 'http://allowed.com@evil.example/' # => safe # => private-target # => parser-divergent ``` Resuelve el host igual que lo hace la red, así que las formas codificadas de una dirección interna no se cuelan: hexadecimal, octal, decimal sin puntos, abreviada, IPv6 e IPv4 mapeada dan todas `private-target`. Y cuando un validador descuidado y el cliente que hace la petición real leerían hosts distintos, el veredicto es `parser-divergent`. ## Cómo interpretar el veredicto | Veredicto | Significado | | ------------------ | --------------------------------------------------------------------------------------------------------------------- | | `safe` | El destino apunta a un host público, y un validador descuidado leería el mismo host. | | `private-target` | El host se resuelve a una dirección privada, de loopback, de enlace local, no especificada o de metadatos de la nube. | | `parser-divergent` | Un validador de texto descuidado leería un host real distinto del host al que se conecta el cliente. | | `invalid url` | La cadena no es una URL válida, así que no hay nada que pedir. | Solo `safe` equivale a permitir. Trata `private-target`, `parser-divergent` e `invalid url` como un bloqueo. ### Opciones de la CLI | Opción | Valor | Descripción | | ------- | ----------------- | --------------------------------------------------------------------------------- | | `--url` | una URL o un host | Comprueba un destino. Repítela para comprobar varios, con un veredicto por línea. | Se necesita al menos un `--url`. El destino nunca va como argumento posicional suelto, así que no se puede confundir con una opción. **Por qué como valor de una opción** Cada destino se pasa como valor de una opción, nunca interpolado en el comando. Un valor con comillas o comillas invertidas queda inerte y no puede inyectar nada en la shell. Escríbelo siempre entre comillas simples para que tu shell no lo expanda antes. **Lo que no cubre** El hook es puro y nunca resuelve DNS, así que dos huecos que solo aparecen en tiempo de ejecución quedan fuera de su alcance: el **DNS rebinding** (un nombre que se resuelve a una dirección pública al comprobarlo y a una interna al hacer la petición) y las **cadenas de redirecciones** (un primer salto que pasa la comprobación y luego redirige hacia dentro). Ciérralos resolviendo una sola vez y conectándote a la dirección validada, y rechazando las redirecciones. Trata los nombres de loopback reservados (`localhost` y la familia `.localhost`) como internos sin consultar el DNS, pero cualquier otro nombre DNS da `safe`, porque afirmar que se resuelve hacia dentro exigiría resolverlo: de esos nombres se encarga la lista de permitidos, que es justo lo que este comprobador valida. **Consejo** Es la misma comprobación que ejecuta la [especialización `network`](https://lagune.ai/es-ES/docs/catalog) para demostrar que un filtro de destinos se sostiene. ## Preguntas frecuentes ### ¿Cómo compruebo si una URL es vulnerable a SSRF? Ejecuta el hook network. Evalúa el destino de una petición y devuelve safe, private-target, parser-divergent o invalid url. Solo safe equivale a permitir. ### ¿Qué es una URL parser-divergent? Una URL que distintos parsers leen de forma diferente, una forma clásica de eludir la protección contra SSRF. El hook network la señala en lugar de permitirla. --- # Hook regex: detecta patrones vulnerables a ReDoS > Analiza un proyecto en busca de regex vulnerables a ReDoS, o evalúa un único patrón, desde la línea de comandos. URL canónica: https://lagune.ai/es-ES/docs/hooks/regex Idioma: es-ES Original: https://lagune.ai/docs/hooks/regex Última actualización: 2026-11-03 El hook `regex` es el motor determinista de seguridad de regex que ejecuta la [especialización `regex`](https://lagune.ai/es-ES/docs/catalog), y puedes ejecutarlo tú mismo. Funciona en dos modos desde un mismo comando: un **scan**, que analiza un proyecto en busca de patrones vulnerables a **ReDoS** y de patrones construidos en tiempo de ejecución, y un **check**, que evalúa un único patrón que tú le pases. ## Analizar un proyecto Sin ninguna opción, analiza todo el proyecto. `--dir` limita el análisis a un directorio, y `--file`, a un solo archivo. Ambas se pueden repetir y se combinan en un único informe, en el que cada archivo aparece una sola vez aunque lo cubra más de un objetivo. **Todo el proyecto** ```bash npx lagune read regex ``` **Un directorio** ```bash npx lagune read regex --dir src/services ``` **Un solo archivo** ```bash npx lagune read regex --file bin/import.pl ``` **Varios objetivos** ```bash npx lagune read regex --dir core --dir workers --file Sources/App/Router.swift ``` **Con un límite** `--limit` fija el umbral de ReDoS para el análisis (25 por defecto), el mismo límite que admite el modo check. Cuanto más bajo es el límite, más estricto. ```bash npx lagune read regex --dir src/services --limit 15 ``` La salida es texto plano, y sus encabezados indican cómo interpretar cada sección. Una sección solo aparece cuando tiene hallazgos. ```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 ``` Si no encuentra nada, muestra una sola línea. ```bash npx lagune read regex --dir src/clean # => no unsafe patterns found ``` ### Cómo interpretar las secciones | Sección | Significado | | ------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Vulnerable regular expressions found` | Patrones vulnerables a ReDoS, agrupados por archivo con cada patrón sangrado debajo, seguido entre paréntesis del motivo por el que es inseguro y, cuando los tiene, de su alcance y sus modificadores. Todas las líneas son inseguras, así que el veredicto no se repite. | | `Regular expressions the analysis could not settle (review manually)` | Patrones que el análisis no pudo resolver dentro de su límite de trabajo, enumerados de la misma forma. | | `Dynamically built regular expressions (review manually by simulating a constructed regex)` | Archivos que construyen una regex a partir de una variable, una concatenación o una interpolación. | | `Static regex wrapped in a constructor (use a literal instead)` | Archivos que pasan un literal de cadena simple a un constructor de regex cuando un literal de regex es más sencillo y se ahorra una compilación en tiempo de ejecución. | La primera sección es un hallazgo de seguridad. La segunda y la tercera no son hallazgos por sí solas: señalan código que una comprobación estática no puede resolver, así que piden que lo lea una persona. La cuarta es una sugerencia de claridad, no un hallazgo de seguridad. ### Opciones de la CLI | Opción | Valor | Descripción | | ----------- | ---------------------- | ------------------------------------------------------------------------------------------------------------------- | | `--pattern` | el texto de una regex | Comprueba un patrón. Repítela para comprobar varios, con un veredicto por patrón y en el mismo orden. | | `--flags` | modificadores de regex | Comprueba cada `--pattern` con estos modificadores, como `im`. Solo se aplica al modo check. | | `--dir` | un directorio | Limita el análisis a un directorio. Se puede repetir y combinar con `--file`. | | `--file` | un archivo | Limita el análisis a un solo archivo. Se puede repetir y combinar con `--dir`. | | `--limit` | un entero no negativo | Fija el límite de repeticiones de ReDoS (25 por defecto). Se aplica a los dos modos. Cuanto más bajo, más estricto. | Sin ninguna opción, analiza todo el proyecto. `--pattern` es el modo check y no se puede combinar con `--dir` ni con `--file`. ### Lenguajes compatibles El análisis lee estos lenguajes, identificados por la extensión del archivo, cada uno según sus propias reglas, así que un patrón de un lenguaje nunca se prueba con las reglas de otro. Todo lo demás se omite en lugar de analizarse con reglas equivocadas. | # | Lenguaje | Extensiones | | --- | --------------------------- | ------------------------------------------------------------------------------------------------------------ | | 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` | **Orientativo, no exhaustivo** Lee el código fuente como texto, así que no puede juzgar un patrón construido en tiempo de ejecución, y se le puede escapar un patrón repartido en varias líneas, oculto tras un alias o escrito de una forma que no reconoce. Toma las secciones como un buen punto de partida, no como un inventario completo, y sigue leyendo el código para cubrir lo que ellas no alcanzan. ## Comprobar un único patrón Pasa `--pattern` con el texto del patrón para evaluarlo. El hook muestra una palabra: `safe`, `unsafe`, `undetermined` cuando el análisis alcanza su límite de trabajo antes de resolver el patrón, o `invalid regex`. Repite `--pattern` para evaluar varios a la vez, con un veredicto por patrón y en el mismo orden. **Un patrón** ```bash npx lagune read regex --pattern '(a+)+$' # => unsafe npx lagune read regex --pattern '^[a-z0-9_]{3,20}$' # => safe ``` **Varios patrones** ```bash npx lagune read regex --pattern '(a+)+$' --pattern '^[a-z]+$' # => unsafe # => safe ``` **Con modificadores** `--flags` comprueba cada `--pattern` de la llamada con los modificadores con los que se ejecuta, porque un modificador cambia los caracteres que reconoce un patrón. ```bash npx lagune read regex --pattern '^(?:a|A)+$' # => safe npx lagune read regex --pattern '^(?:a|A)+$' --flags 'i' # => unsafe ``` **Con un límite** `--limit` fija el límite de repeticiones (25 por defecto) y se aplica a cada `--pattern` de la llamada. Cuanto más bajo es el límite, más estricto. ```bash npx lagune read regex --pattern 'a?a?a?' --limit 2 # => unsafe ``` **Por qué un argumento entre comillas** Cada patrón se pasa como valor de una opción, nunca interpolado en el comando. Un valor con comillas o comillas invertidas queda inerte y no puede inyectar nada en la shell. Escribe siempre el patrón entre comillas simples para que tu shell no lo expanda antes. **Consejo** Es el mismo motor que ejecuta la [especialización `regex`](https://lagune.ai/es-ES/docs/catalog): el modo scan abre la revisión de ReDoS y el modo check confirma los patrones que esa revisión saca a la luz. ## Preguntas frecuentes ### ¿Cómo compruebo desde la CLI si una regex es vulnerable a ReDoS? Ejecuta npx lagune read regex --pattern ''. Devuelve safe, unsafe, undetermined o invalid regex. ### ¿Cómo analizo todo un proyecto en busca de regex inseguras? Ejecuta el hook regex en modo scan sobre el proyecto. Informa de los patrones vulnerables a ReDoS en 25 lenguajes compatibles. --- # Hook secrets: detecta secretos incrustados en el código > Analiza un proyecto en busca de credenciales incrustadas en el código, desde la línea de comandos. URL canónica: https://lagune.ai/es-ES/docs/hooks/secrets Idioma: es-ES Original: https://lagune.ai/docs/hooks/secrets Última actualización: 2026-11-03 El hook `secrets` señala las **credenciales incrustadas en el código fuente** en lugar de leídas del entorno. Se fija en la **procedencia** (un literal frente a una lectura del entorno), no en el contenido del valor, así que no necesita un catálogo exhaustivo de prefijos de proveedores y apenas produce falsos positivos. Es el motor determinista en el que se apoya la [especialización `secrets`](https://lagune.ai/es-ES/docs/catalog). Las firmas con el formato de un proveedor, las credenciales en cadenas de conexión y los literales asignados a un identificador con nombre de secreto son **independientes del lenguaje**: la misma cadena se lee igual en cualquier archivo. Las dos heurísticas que dependen de la sintaxis, una lectura del entorno con un valor por defecto incrustado y un secreto que acaba en un sink de logs, **tienen en cuenta el lenguaje**, así que un `console.log` de JavaScript nunca se busca en un archivo de Rust y el `os.getenv("X", "default")` de Python se reconoce por sí mismo. ## Cómo ejecutarlo ```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 ``` El análisis muestra hasta dos secciones. **Hardcoded secrets found** es el conjunto de hallazgos (un valor por defecto incrustado para una variable de entorno con nombre de secreto, una credencial incluida en una cadena de conexión o un valor que coincide con uno de los formatos de proveedor seleccionados), así que el hook termina con un código de salida distinto de cero. **Secret handling to review manually** es un conjunto de indicios: un literal simple asignado a un identificador con nombre de secreto (su procedencia se puede determinar, pero no si el valor es un secreto real) y un valor con nombre de secreto que acaba en un sink de logs o de respuesta. Si no encuentra nada, muestra `no hardcoded secrets found`. ### Opciones de la CLI | Opción | Valor | Descripción | | -------- | ------------- | ------------------------------------------------------------------------------ | | `--dir` | un directorio | Limita el análisis a un directorio. Se puede repetir y combinar con `--file`. | | `--file` | un archivo | Limita el análisis a un solo archivo. Se puede repetir y combinar con `--dir`. | Sin ninguna opción, analiza todo el proyecto. ### Cobertura de lenguajes El hallazgo del valor por defecto del entorno y el indicio del sink de logs leen un conjunto de formas propio de cada lenguaje, así que cubren los lenguajes de abajo y no señalan nada en los demás. Las otras tres señales se ejecutan en **todos** los archivos. | Señal | Lenguajes | | ----------------------------- | ------------------------------------------------------------------------------- | | Valor por defecto del entorno | JavaScript/TypeScript, Python, Ruby, PHP, Kotlin, Java, Go (`cmp.Or`), Rust, C# | | Sink de logs o de respuesta | JavaScript/TypeScript, Python, Ruby, PHP, Java, Kotlin, Go, Rust, C, C++, C# | **¿Esto incumple alguna política?** No. Detectar el formato de un secreto para avisar de que se ha incluido en un commit es una práctica habitual de las herramientas defensivas, la misma operación que hacen gitleaks, trufflehog y la push protection de GitHub. El hook incluye firmas de detección (**formatos** públicos de tokens), nunca un secreto activo, y audita y explica en lugar de exfiltrar. ## Preguntas frecuentes ### ¿Cómo evita falsos positivos el hook secrets? Se fija en la procedencia, no en el contenido del valor. Los formatos de alta confianza (tokens de proveedores, valores por defecto del entorno, cadenas de conexión) son hallazgos que terminan con un código de salida distinto de cero. Un literal simple asignado a un identificador con nombre de secreto es un indicio que hay que confirmar, y ese mismo identificador leído de process.env no se señala en absoluto. --- # Ejemplos de prompts de Lagune: automatiza el flujo Blue Team > Prompts de Lagune listos para copiar: un análisis de solo lectura, el flujo Blue Team completo y una auditoría Zero Trust, además de detección acotada a un commit, al diff de una rama o PR, o a un incidente real. URL canónica: https://lagune.ai/es-ES/docs/examples/prompts Idioma: es-ES Original: https://lagune.ai/docs/examples/prompts Última actualización: 2026-11-03 Prompts de Lagune listos para copiar y pegar directamente en tu agente de IA. ## 💧 Análisis superficial Un análisis de solo lectura que revisa el código por su cuenta e informa de cada fallo con su corrección, sin ejecutar el flujo Blue Team ni escribir en el seguimiento de Lagune. **Consejo** Funciona mejor en modo de planificación y con un charter (`/lagune-charter`) definido. **🪼 Predeterminado** | Aspecto | Contrapartida | Nivel | | ----------------- | ------------------------------------------------------------------------ | ------------------- | | **Esfuerzo** | Un solo agente analiza e informa, sin subagentes. | 1/5 | | **Tiempo** | Rápido. Una sola pasada de solo lectura, sin aplicar nada. | 2/5 | | **Uso de tokens** | Moderado y compartido. Todo el análisis se ejecuta en un mismo contexto. | 2/5 | ```md /lagune Eres un investigador de ciberseguridad con amplia experiencia en seguridad defensiva y usas Lagune para mejorar tus conocimientos y tu precisión. Analiza el espacio de trabajo por tu cuenta y asocia a cada fallo que encuentres una corrección concreta. Es un análisis independiente, no el flujo Blue Team: no ejecutes detect, plan, harden ni verify, y no escribas nada en el seguimiento de Lagune. Al final, enumera todos los fallos que hayas encontrado, cada uno con su gravedad y una corrección concreta. ``` **🐬 Multiagente** | Aspecto | Contrapartida | Nivel | | ----------------- | ------------------------------------------------------------------------------------------- | ------------------- | | **Esfuerzo** | Un subagente por archivo, en proporción al tamaño de tu código. | 2/5 | | **Tiempo** | En paralelo por archivo y luego unificado en un solo informe. Sigue siendo de solo lectura. | 3/5 | | **Uso de tokens** | Mayor, pero aislado. Cada subagente analiza en su propio contexto. | 3/5 | ````md /lagune Eres un orquestador de ciberseguridad que usa Lagune para enumerar las rutas, lanzar un subagente por ruta y unificar sus informes (todo el contenido lo leen los subagentes). Debes delegar la tarea en subagentes según el tamaño del proyecto actual: cuanto más grande sea el código, más subagentes deben lanzarse, todos en paralelo, y cada uno con el prompt siguiente: ```prompt /lagune Eres un investigador de ciberseguridad con amplia experiencia en seguridad defensiva y usas Lagune para mejorar tus conocimientos y tu precisión. Analiza por tu cuenta y asocia a cada fallo que encuentres una corrección concreta. Es un análisis independiente, no el flujo Blue Team: no ejecutes detect, plan, harden ni verify, y no escribas nada en el seguimiento de Lagune. Al final, enumera todos los fallos de , cada uno con su gravedad y una corrección concreta. ``` Al final, unifica los informes de todos los subagentes en una sola lista priorizada de fallos y correcciones. ```` **Aviso** Un análisis rápido es un único prompt amplio y sin acotar, así que es más probable que algunos agentes lo rechacen o lo dejen a medias. Si el tuyo se resiste, ejecuta en su lugar el **flujo Blue Team** completo que encontrarás más abajo: sus fases acotadas y paso a paso tienen muchas menos probabilidades de bloquearse. --- ## 🌊 Flujo de auditoría Blue Team automático Ejecuta el [flujo completo de comandos](https://lagune.ai/es-ES/docs/get-started/commands) de principio a fin sin detenerse a pedirte nada. **🪼 Predeterminado** | Aspecto | Contrapartida | Nivel | | ----------------- | -------------------------------------------------------------------------------------------------- | ------------------- | | **Esfuerzo** | Un solo agente, sin subagentes, sea cual sea el tamaño del código. | 3/5 | | **Tiempo** | Medio, pero menos exhaustivo en proyectos grandes. Cada comando se ejecuta una vez, uno tras otro. | 4/5 | | **Uso de tokens** | Menor, pero menos aislado. Todos los comandos comparten el mismo contexto. | 4/5 | ```md Ejecuta los siguientes comandos, uno a uno: `/lagune-charter`, `/lagune-detect`, `/lagune-plan`, `/lagune-harden` y `/lagune-verify`. ## Bucle Cuando `/lagune-verify` rechace una o más correcciones, repite `/lagune-harden` y luego `/lagune-verify` hasta que todos los hallazgos queden bien resueltos. ## Importante - No te detengas ni preguntes: en caso de duda, hazlo todo en modo "full". ``` **🐋 Multiagente (análisis profundo)** | Aspecto | Contrapartida | Nivel | | ----------------- | ------------------------------------------------------------------------------------------------------------------------ | ------------------- | | **Esfuerzo** | El número de subagentes se ajusta al tamaño de tu código. | 5/5 | | **Tiempo** | Más largo, pero más exhaustivo. Lanza varios subagentes para detectar, planificar y bastionar los hallazgos en paralelo. | 5/5 | | **Uso de tokens** | Mayor, pero más seguro. Cada subagente tiene su propio contexto aislado, sin sesgos. | 5/5 | ````md Ejecuta cada uno de los siguientes comandos en un subagente distinto, de uno en uno (sin comillas invertidas, solo el comando): Prompt del subagente 1: `/lagune-charter` Prompt del subagente 2: `/lagune-detect` Prompt del subagente 3: `/lagune-plan` Prompt del subagente 4: `/lagune-harden` Prompt del subagente 5: `/lagune-verify` En los comandos `/lagune-detect`, `/lagune-plan`, `/lagune-harden` y `/lagune-verify`, debes delegar la tarea en subagentes según el tamaño del proyecto actual: cuanto más grande sea el código, más subagentes deben lanzarse. Por ejemplo: ```prompt /lagune-detect ``` ```prompt /lagune-plan ``` ```prompt /lagune-harden ``` ```prompt /lagune-verify ``` - Si varios agentes ejecutan el mismo comando, lánzalos en paralelo. - Cuando terminen todos los subagentes de `/lagune-detect`, ejecuta: ```prompt /lagune-detect unifica los hallazgos equivalentes. No busques hallazgos nuevos ni vuelvas a analizar el código. ``` ## Bucle Cuando `/lagune-verify` rechace una o más correcciones, repite `/lagune-harden` y luego `/lagune-verify` hasta que todos los hallazgos queden bien resueltos. ## Importante - No te detengas ni preguntes: en caso de duda, hazlo todo en modo "full". ```` --- ## 🪄 Detección acotada Dirige [`/lagune-detect`](https://lagune.ai/es-ES/docs/commands/detect) a una parte de tu proyecto en lugar de a todo él. Describe el ámbito en lenguaje sencillo (un commit, un pull request o una situación real) e identificará solo los hallazgos relevantes para la seguridad dentro de él. **Consejo** Todo lo que detecta aquí es un hallazgo normal, así que puedes llevarlo directamente a `/lagune-plan`, `/lagune-harden` y `/lagune-verify`, acotados solo a esos elementos. **📌 Desde un commit** Somete un lote reciente de commits a su propia revisión de seguridad, acotada solo a lo que han cambiado, por ejemplo: ```prompt /lagune-detect Limita la detección a todo lo que ha cambiado desde el commit `a1b2c3d`. ``` **🔀 Diff de una rama o PR** Revisa la seguridad de un pull request antes de fusionarlo, acotando la revisión a su diff, por ejemplo: ```prompt /lagune-detect Limita la detección a los cambios que introduce esta rama respecto a `main`. ``` **⛑️ Tras un incidente** Describe lo ocurrido con tus propias palabras. Lagune interpreta la situación, no un flag, y la convierte en una búsqueda focalizada, por ejemplo: ```prompt /lagune-detect Hace unas semanas nuestra web sufrió una fuga de datos. No sé exactamente cómo ocurrió y me preocupa que siga habiendo algo abierto por donde se puedan volver a filtrar datos. Revisa el código con cuidado, céntrate en cualquier punto donde se lean, almacenen o expongan datos sensibles e identifica todo lo que todavía pueda ser una vía de salida. Trátalo como un incidente real, no como un simulacro. ``` --- ## 🚨 Auditoría Zero Trust Trata todo el espacio de trabajo y cada dependencia como hostiles: busca intérpretes, llamadas de red, payloads codificados y código escondido en lugares insospechados para burlar los escáneres, y termina con un veredicto claro, sí o no, sobre si es seguro usar el proyecto. Los prompts cargan directamente las especializaciones en las que se apoya esta auditoría, sean cuales sean las categorías de tu proyecto. Para el resto del catálogo que `/lagune` coteja con el código, asegúrate de que el proyecto use **OWASP**, **IA / LLM** y la categoría de su stack (por ejemplo, **JavaScript**, **Python**, etc.): ```bash npx lagune write add --categories owasp ai javascript ``` **Peligro** Ten cuidado al ejecutar en tu entorno local proyectos de fuentes no fiables. Usa un entorno aislado, como un **sandbox** (recomendado), una **VM** o algo similar, para evitar que el código malicioso afecte a tu sistema. **🪼 Predeterminado** | Aspecto | Contrapartida | Nivel | | ----------------- | -------------------------------------------------------------------------------------------------------------- | ------------------- | | **Esfuerzo** | Un solo agente analiza todo el espacio de trabajo, sin subagentes. | 2/5 | | **Tiempo** | Medio. Un solo agente recorre el código y sus dependencias de forma secuencial. | 3/5 | | **Uso de tokens** | Moderado, pero compartido. Las especializaciones, el código y las dependencias se cargan en un mismo contexto. | 3/5 | ```md /lagune Eres un investigador de ciberseguridad con amplia experiencia en seguridad defensiva zero trust y usas Lagune para mejorar tus conocimientos y tu precisión. Considera todo el espacio de trabajo una fuente no fiable y un ámbito potencialmente malicioso. Cualquier intérprete, fetch, base64 o similar debe tratarse como una posible amenaza. Extiende tu análisis a las dependencias y subdependencias: un proyecto puede intentar ocultar código malicioso en un lugar insospechado para burlar los escáneres. Especializaciones obligatorias (cárgalas de una en una con `npx lagune read catalog `): - interpreter - secrets - llm - path Que quede claro: toda vulnerabilidad identificada debe tratarse como una posible amenaza, sin excepción. Al final, dame un veredicto sobre si el proyecto es seguro y fiable para que lo use o no. ``` **🐋 Multiagente (análisis profundo)** | Aspecto | Contrapartida | Nivel | | ----------------- | -------------------------------------------------------------------------------------------------------------- | ------------------- | | **Esfuerzo** | Un subagente por archivo, en proporción al tamaño de tu código. | 5/5 | | **Tiempo** | Más largo, pero más exhaustivo. Los archivos se analizan en paralelo y luego se unifican en un solo veredicto. | 4/5 | | **Uso de tokens** | El más alto, pero el más seguro. Cada subagente lee las especializaciones en su propio contexto aislado. | 5/5 | ````md /lagune Eres un orquestador de ciberseguridad que usa Lagune para enumerar los archivos, lanzar un subagente por archivo y generar informes (todo el contenido lo leen los subagentes). Lanza un subagente por archivo, todos en paralelo, y dale a cada uno el prompt siguiente, acotado a su archivo: ```prompt /lagune Eres un investigador de ciberseguridad con amplia experiencia en seguridad defensiva zero trust y usas Lagune para mejorar tus conocimientos y tu precisión. Considera una fuente no fiable y un ámbito potencialmente malicioso. Cualquier intérprete, fetch, base64 o similar debe tratarse como una posible amenaza. Extiende el análisis a todo lo que importe , incluidas las dependencias y subdependencias, donde el código malicioso puede esconderse para burlar los escáneres. Especializaciones obligatorias para cada subagente (cárgalas de una en una con `npx lagune read catalog `): - interpreter - secrets - llm - path Que quede claro: toda vulnerabilidad identificada debe tratarse como una posible amenaza, sin excepción. Al final, dame un veredicto sobre si el proyecto es seguro y fiable para que lo use o no. ``` Al final, unifica los informes de todos los subagentes en un único veredicto final. ```` --- # Security-Driven Hardening: una convención para la era del desarrollo asistido por IA > La metodología Security-Driven Hardening (SDH): una convención Blue Team, adaptada al contexto, para auditar y bastionar software desarrollado con ayuda de IA o con vibe coding. URL canónica: https://lagune.ai/es-ES/docs/references/paper Idioma: es-ES Original: https://lagune.ai/docs/references/paper Última actualización: 2026-11-03 - **Weslley Araújo** - **Artículo de metodología, 2026.** --- ## Resumen Security-Driven Hardening (SDH) es una metodología de seguridad estructurada, guiada por IA y exclusivamente defensiva, pensada para una época en la que el software lo escriben cada vez más agentes de IA y personas que no son especialistas en seguridad. En lugar de aplicar una lista de comprobación genérica, SDH detecta primero lo que un sistema hace realmente (inicio de sesión, subida de archivos, pagos, exposición de datos, etc.) y después dirige el trabajo de seguridad propio de ese contexto. La rigen principios seguros por defecto, se plantea por completo desde la defensa y se expresa en lenguaje claro para que cualquier usuario pueda actuar a partir de ella. Este documento sostiene que SDH es una convención que faltaba, no una herramienta concreta. El conocimiento de seguridad reside en la metodología y en sus especializaciones bajo demanda, una base sobre la que cualquier usuario puede construir, y eso le permite atender a un principiante y a un experto con el mismo flujo. Dos propiedades la distinguen de los enfoques spec-first anteriores `[1]`. SDH es **independiente del estado**: se adapta a un directorio vacío, a un proyecto en curso, a un único pull request o a un gran código heredado, con cualquier stack. Y con SDH **la seguridad se puede cerrar**: un riesgo cuyo cierre se ha verificado se da de baja de todo el flujo, de modo que ese hallazgo queda en reposo y solo se reabre cuando cambia el código. SDH no sustituye a los profesionales de seguridad ni a las herramientas especializadas de Blue Team. Amplía el conocimiento del propio desarrollador, y cuanto más sabe de seguridad un desarrollador, más puede dirigir la metodología. **Lagune** es la implementación de referencia y demuestra que la metodología se puede construir y llevar a otros entornos. SDH se ofrece como una convención que otros pueden adoptar. > **Palabras clave** > > desarrollo asistido por IA, seguridad del software, seguridad defensiva, spec-driven development, bastionado, flujos de trabajo guiados por agentes, posibilidad de cierre, seguridad adaptada al contexto, conocimiento bajo demanda, herramientas independientes del agente. --- ## I. Introducción: la brecha de seguridad que abrió el desarrollo asistido por IA Cada vez más software sale de manos de personas, y de agentes de IA, que no saben reconocer con fiabilidad un patrón inseguro: un secreto filtrado, una comprobación de autorización que falta, una consulta vulnerable a inyección. No son riesgos exóticos. Figuran entre las clases de riesgo que dominan los incidentes reales, documentadas desde hace años en referencias públicas `[6]`, `[7]`, y estudios recientes indican que una parte significativa del código generado por IA se publica justo con este tipo de defectos `[8]`. Los asistentes de programación con IA agravaron el problema al permitir que personas que no son desarrolladoras publiquen software real, pero la brecha va más allá de cualquier público concreto. La mayoría de los proyectos nunca reciben una revisión de seguridad específica para lo que hacen realmente. El ecosistema se vuelve más frágil con cada decisión precipitada de "funciona, publícalo". Los consejos de seguridad genéricos no cierran esta brecha. Una lista de comprobación estática no es específica de lo que hace un sistema, así que inunda un proyecto pequeño de elementos irrelevantes y aun así pasa por alto el riesgo que importa en ese proyecto concreto. El problema no es que falte conocimiento de seguridad en el mundo. El problema es asociar el conocimiento adecuado al sistema que el usuario tiene delante, y hacerlo para alguien que quizá no sepa qué pedir. SDH responde con una sola inversión: **el conocimiento de seguridad reside en la especificación y en sus especializaciones bajo demanda, una base sobre la que cualquier usuario puede construir**. La metodología detecta el contexto, hace el triaje de los riesgos que conlleva ese contexto y guía las correcciones, de modo que el mismo flujo sirve tanto a quien desarrolla como a quien no. Los hallazgos y las recomendaciones se mantienen en lenguaje claro para que se puedan poner en práctica sea cual sea el nivel técnico de quien los lee. Al experto esto no lo limita, sino que lo potencia, una dualidad que desarrollamos en `§VI`. > **Idea clave** > > **La inversión central:** el conocimiento de seguridad reside en la especificación y en sus especializaciones bajo demanda, una base sobre la que cualquier usuario puede construir. La metodología aprende qué hace el sistema, ajusta a él el trabajo de seguridad y amplía lo que el usuario ya sabe. Pensemos en un desarrollador que le dice a un asistente de IA: "mi aplicación permite a los usuarios subir una foto de perfil". Sin una revisión de seguridad, el asistente produce código que funciona y que, sin que nadie lo note, confía en todo lo que envía el cliente: el tipo de archivo declarado, el nombre del archivo, el tamaño. La subida sale a producción, y un archivo disfrazado de imagen puede llevar código, un nombre manipulado puede escaparse de la ruta de almacenamiento y un archivo demasiado grande puede agotar el servidor. Nada de esto se ve en una demostración, así que sale tal cual. El mismo código, pasado por SDH, se comporta de otra forma. SDH detecta que el sistema acepta archivos del exterior (detección), lo traduce en los riesgos que conlleva una subida (triaje), propone comprobar el tipo real y el tamaño del archivo, renombrarlo al guardarlo y almacenarlo donde no se pueda ejecutar código (remediación), y después lee el resultado y confirma que cada control se sostiene de verdad (verificación). El desarrollador nunca tuvo que conocer la expresión "subida de archivos sin restricciones". La metodología se la aportó. Este documento hace las siguientes aportaciones: - Una definición precisa de SDH como metodología, independiente de cualquier implementación concreta, con sus principios de diseño (`§III`). - Un ciclo de vida defensivo de cinco fases en el que la separación de responsabilidades es en sí la aportación: la detección nunca inventa, la planificación nunca lee código, solo una fase modifica el código y la verificación nunca suaviza su juicio (`§IV`). - La **posibilidad de cierre** como postura metodológica: cada hallazgo tiene un estado final, no un bucle sin fin (`§V`). - La dualidad de la **extensión del conocimiento del desarrollador**: un único flujo que protege al principiante y potencia al experto (`§VI`). - **Especializaciones no invocables y prompt bajo demanda**: conocimiento de seguridad acotado que el agente carga cuando el contexto del proyecto lo requiere, nunca por defecto (`§VII`). - **Independencia del estado** y **adaptabilidad no prescriptiva**: SDH se ajusta a cualquier estado de desarrollo y se adapta al escenario en lugar de imponer un alcance fijo (`§VIII`). - Un **modo preventivo**: la misma defensa aplicada mientras se desarrolla el trabajo habitual, para que el código llegue seguro por defecto y las fases tengan menos que corregir (`§IX`). - Una comparación específica con Spec-Driven Development, el linaje del que surgió SDH y del que después se apartó (`§X`). - Las disciplinas de ingeniería que permiten a la metodología sobrevivir a las refactorizaciones y mantenerse independiente de cualquier agente: el seguimiento con identidad por nombre (`§XI`) y un vehículo independiente del agente (`§XII`). --- ## II. Antecedentes y trabajos relacionados SDH se apoya en trabajos previos. Hereda una estructura probada del desarrollo spec-first guiado por agentes `[1]`, `[2]`, `[3]`: plantillas, comandos de barra que consume un agente, un documento rector y un agente que ejecuta las fases. Reimplementa esa estructura con un propósito defensivo. El linaje es deliberado, y uno de los principios de trabajo de SDH lo nombra directamente: construir el flujo de trabajo a partir de una estructura probada y después orientarlo a la seguridad. SDH no es una lista de comprobación estática de recomendaciones genéricas. Una lista de comprobación sabe mucho de seguridad en general y nada del proyecto que tiene delante. SDH invierte ese énfasis. Dedica su primer esfuerzo a la detección, a aprender qué hace el sistema, y solo entonces recurre al conocimiento que la detección vuelve relevante. SDH tampoco sustituye a los profesionales de seguridad ni a las herramientas especializadas de Blue Team. Amplía el conocimiento del desarrollador (`§VI`). Un equipo con una función de seguridad dedicada debería conservarla. SDH le da a ese equipo un vehículo estructurado, y a un equipo sin ella, una base defendible. SDH convive también con los analizadores de seguridad deterministas (análisis estático, linters) `[4]`, `[5]`. Esas herramientas son valiosas precisamente porque son deterministas y repetibles. SDH se basa sobre todo en el razonamiento del agente, lo que sacrifica el determinismo estricto a cambio de adaptarse al contexto. La metodología no finge lo contrario. Donde el determinismo importa, integra un motor determinista dentro del razonamiento (`§VII`): el agente decide si merece la pena comprobar una entrada, y un programa determinista decide si esa entrada es peligrosa. El antecedente más directo es Spec-Driven Development (SDD), la familia de metodologías spec-first que hace avanzar la construcción de software a partir de una especificación ejecutable. Tratamos SDD como una clase. Su formulación más clara como metodología práctica es el informe de Piskala `[1]`, y su kit de herramientas guiado por agentes más visible es Spec Kit de GitHub `[2]`, con OpenSpec `[3]` como segunda herramienta de la misma familia. Estas son las referencias canónicas de la comparación de `§X`. --- ## III. SDH: definición y principios de diseño **Security-Driven Hardening** es una metodología de seguridad estructurada y guiada por IA que hace más seguro un proyecto dirigiendo el trabajo desde una especificación que ejecuta el agente, y no a base de correcciones improvisadas. El nombre se inspira en los **Blue Teams**, los defensores en el ámbito de la seguridad. SDH trata de defensa, bastionado y verificación, nunca de ataque. > **Definición** > > **Security-Driven Hardening (SDH):** una metodología de seguridad estructurada, guiada por IA y exclusivamente defensiva que primero detecta lo que un sistema hace realmente y después dirige el trabajo de seguridad específico de ese contexto, regida por principios seguros por defecto y expresada en lenguaje claro. SDH se define por un conjunto de principios vinculantes. Cada uno es una regla, y cada uno ofrece al usuario una garantía concreta. | Principio | La regla | Lo que garantiza al usuario | | ----------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Seguro por defecto, en lenguaje claro, para todos por igual | Cada valor por defecto, mensaje y corrección es seguro desde el principio y comprensible para cualquier lector, sea desarrollador o no. No se privilegia a ningún tipo de usuario. | Un principiante recibe una base segura sin pedirla y lee el resultado en sus propios términos. | | Adaptado al contexto antes que genérico | Cada fase parte del contexto detectado en detect y actúa sobre lo que el sistema hace realmente. | Las recomendaciones se ajustan al proyecto, no a una lista de comprobación. El conocimiento de seguridad reside en la especificación y en sus especializaciones bajo demanda, y amplía lo que aporte el usuario. | | Flexible antes que rígido | Los principios, requisitos y recomendaciones son puntos de partida. El usuario puede reformular, descartar, añadir o acotar cualquier cosa. | La metodología se adapta al proyecto y al usuario, y nunca con más rigidez de la que el usuario quiere. La flexibilidad nunca debilita la base segura por defecto. | | Conciliar, nunca solo añadir | Los artefactos son documentos vivos, no logs. Cada ejecución revisa todas las entradas: conserva lo que se sostiene, reescribe lo que cambió y elimina lo que ya no es válido. | El registro siempre refleja el presente, así que nunca degenera en una lista de pendientes obsoleta. | | Solo defensa | SDH audita, bastiona y verifica. Nunca produce herramientas ofensivas, exploits con fines maliciosos ni técnicas de evasión de la detección para causar daño. | La metodología no puede convertirse en un arma. El contenido de doble uso solo aparece en un marco claramente defensivo. | | Spec-first, guiado por agentes, orientado a la seguridad | El flujo de trabajo se construye con plantillas, comandos, un charter rector y un agente que ejecuta las fases. | Una estructura de desarrollo probada, reorientada para que el agente haga el trabajo de seguridad de fondo. | **Tabla 1.** Los principios de diseño de SDH y la garantía que cada uno ofrece al usuario. Estos principios no son decorativos. Son las restricciones que debe respetar cada fase descrita a continuación, y la discusión de `§XV` vuelve sobre ellos para marcar los límites de la metodología. El resto del documento desarrolla nueve pilares con nombre propio. Son las partes que un lector debería poder retener, y las que otro equipo reimplementaría para afirmar que hace SDH. | Pilar | Qué aporta | Sección | | -------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- | | La inversión adaptada al contexto | El conocimiento de seguridad reside en la especificación y en sus especializaciones bajo demanda, así que un principiante y un experto comparten un mismo flujo. | `§I`, `§VI` | | El ciclo de vida defensivo de cinco fases | Separación de responsabilidades: política, detección, triaje, remediación y verificación, cada una con una sola tarea. | `§IV` | | La posibilidad de cierre | Un hallazgo tiene un estado final, no un bucle sin fin. El trabajo cerrado se da de baja. | `§V` | | La dualidad de la extensión del conocimiento del desarrollador | Un único flujo que protege al principiante y potencia al experto, sin sustituir nunca a ninguno de los dos. | `§VI` | | Prompt bajo demanda, conocimiento no invocable | El conocimiento de seguridad relevante se carga según lo que es el proyecto, nunca por defecto. | `§VII` | | Independencia del estado y adaptabilidad no prescriptiva | Se ajusta a cualquier estado de desarrollo con cualquier stack, y se adapta al escenario en lugar de imponer un alcance. | `§VIII` | | El modo preventivo | La misma defensa actúa mientras se desarrolla el trabajo nuevo, para que el código llegue seguro por defecto. | `§IX` | | Seguimiento con identidad por nombre | Un hallazgo sigue siendo un único elemento a lo largo de las fases, y un cambio de nombre rompe el vínculo en un solo lugar. | `§XI` | | El vehículo independiente del agente | El valor de seguridad se escribe una sola vez y no depende de ningún agente ni stack. | `§XII` | **Tabla 2.** Los nueve pilares de SDH y dónde se desarrolla cada uno. --- ## IV. El flujo Blue Team de 5 fases SDH estructura el trabajo como un ciclo de vida defensivo de cinco fases (figura 1). Cada fase se plantea desde la defensa, cada una se apoya en la anterior, y las fases siguen la actividad real de un Blue Team: establecer la política, detectar, hacer el triaje, remediar y verificar. ```mermaid flowchart TB charter["1 · charter (política)
lee: el proyecto y, si la hay, la descripción del usuario
escribe: el charter
cada principio incluye el riesgo que previene, en lenguaje claro"] detect["2 · detect (detección)
lee: el código del usuario
escribe: el mapa de detect
detección, no invención: registra solo lo que respalda el código"] plan["3 · plan (triaje)
lee: el mapa de detect, nunca el código
escribe: el plan de defensa
cada corrección apunta a algo que detect identificó de verdad"] harden["4 · harden (remediación)
lee: el plan de defensa y el código que toca
escribe: el código y el registro de bastionado
la única fase que modifica el código, una corrección cada vez, el cambio mínimo que se sostiene"] verify["5 · verify (verificación)
lee: el código y el registro de bastionado
escribe: cada veredicto abierto en el registro de bastionado
el contraste del código con el registro, estático, nunca suavizado"] charter --> detect --> plan --> harden --> verify verify -.->|"no superado: trabajo reabierto para harden,
reaplicado según el motivo registrado"| harden verify -.->|"cierre: da de baja lo que demostró cerrado
en toda la cadena,
una línea en el historial"| detect ``` **Figura 1.** El flujo de cinco fases: qué lee cada fase, qué escribe y su invariante esencial. Verify origina los dos retornos: un control que no supera la verificación reabre harden, y un hallazgo cuyo cierre se ha demostrado se da de baja en toda la cadena, con una línea en el historial. La separación de responsabilidades es la aportación. Como cada fase tiene una sola tarea, cualquier fallo queda contenido en un solo lugar, y el lector puede fiarse de lo que afirma cada artefacto. > **Idea clave** > > **Applied no significa verificado:** harden registra que se aplicó una corrección. Verify la comprueba contrastando el código con ese registro, y el veredicto nunca se suaviza para que coincida con el registro. Un control puede estar presente en el código y aun así dejar el riesgo alcanzable, y entonces el veredicto honesto es "Risk not closed". ### charter (política) El charter establece los principios de seguridad del proyecto, las reglas que toda fase posterior debe respetar. Es la capa rectora, una especie de comprobación en tiempo de compilación de la postura de seguridad del proyecto. Cada principio tiene un nombre claro, una regla innegociable que se puede contrastar con el código y una línea `Why:` que expone el riesgo que previene, no solo la corrección. El charter siempre lee el propio proyecto (sus manifiestos, su estructura y sus dependencias), y la descripción del usuario, cuando la hay, es una orientación que esa lectura amplía después más allá de lo que el usuario mencionó. Sin descripción, el proyecto es la única fuente. Ambas se suman en lugar de competir, y el charter registra la política que el proyecto debería cumplir, no el estado de su código. Alguien que no sea desarrollador debería poder leerlo y entender tanto la regla como el riesgo. ### detect (detección) Detect lee el código e identifica lo que el sistema hace realmente y que tiene peso para la seguridad. La instrucción que lo rige es "detección, no invención": registrar solo lo que respalda el código, con la evidencia que necesitan las fases posteriores. Detect es neutral. No fuerza sus hallazgos para que encajen con el charter, porque cotejar los riesgos con las reglas del charter es tarea de la fase plan. Cada hallazgo tiene tres partes: qué es (una descripción en lenguaje claro), por qué importa (el riesgo, no solo el hecho) y la evidencia (la función o la ruta donde se encuentra). La evidencia no incluye ninguna ruta de archivo. La ruta vive solo en el mapa de seguimiento (`§XI`), así que el texto nunca contiene una ruta que pueda quedar obsoleta. ### plan (triaje) Plan convierte cada hallazgo en una corrección, nombrada por su clase de riesgo (citando las referencias establecidas, CWE y OWASP, cuando la fundamentan) y vinculada al principio del charter que esa corrección defiende. La prioridad (crítica, alta, media, baja) no es una elección libre: plan puntúa cada hallazgo con el método Base y Environmental de CVSS v4.0, de modo que la franja es la puntuación expresada en palabras sencillas, justificada con una línea en lenguaje claro sobre la exposición y lo que está en juego, y dos ejecuciones dan el mismo orden. El vector es el ancla precisa para un experto, y la franja con su justificación, la misma valoración que cualquiera puede seguir. Plan trabaja solo a partir del mapa de detect y nunca lee el código. Es una restricción deliberada, no una limitación: obliga a que cada corrección apunte a algo que detect detectó de verdad. Si un ámbito nunca se identificó, plan se detiene y devuelve al usuario a detect en lugar de suponer. ### harden (remediación) Harden es la única fase que modifica el código, así que avanza con cautela. Que una edición necesite o no la aprobación del usuario depende del agente y del modo de permisos con el que se ejecuta, así que harden no añade ningún paso de confirmación propio. Aplica una corrección cada vez, primero las dependencias y después la de mayor prioridad, para que cada cambio sea pequeño, revisable y fácil de deshacer. Nunca debilita un control existente para que encaje una corrección nueva, y nunca incumple un principio del charter. Si una corrección entrara en conflicto con un principio, harden se detiene y expone el conflicto en lugar de aplicarla. Cada bloque se registra como Applied, Partial o Blocked. "Applied todavía no significa verificado", y de eso se ocupa la fase siguiente. ### verify (verificación) Verify comprueba cada control aplicado leyendo el código y contrastándolo con lo que registró harden. La verificación es ese contraste, el código frente al registro, y es estática: confirma que un control está presente y es correcto en el código, no que el control resista un ataque en un sistema en ejecución. Esa comprobación en tiempo de ejecución, la que lanza ataques reales o simulados contra el sistema en funcionamiento, queda fuera del alcance por diseño. Verify devuelve uno de tres veredictos: Risk closed, Risk not closed o Cannot tell from the code. No produce ningún artefacto propio: harden y verify comparten el registro de bastionado, harden es dueño de lo que se hizo y verify, del veredicto y su motivo, y ninguno escribe nunca en los campos del otro. Un control que no supera la verificación es trabajo reabierto para harden, cuya siguiente ejecución antepone el veredicto a su propia lectura del código y vuelve a aplicar la corrección contra la carencia exacta que indica el motivo. Verify confía más en el código que en el registro, porque un registro puede afirmar más de lo que el código cumple. Es de solo lectura sobre el código del usuario y nunca suaviza un veredicto para que coincida con el registro. Un control puede estar presente y aun así dejar el riesgo alcanzable por otra vía, y en ese caso el veredicto honesto es "Risk not closed". Si, mientras lee, verify advierte un problema de seguridad que el mapa de detect nunca cubrió, no se inventa un veredicto para él, porque detectar es tarea de detect: expone el problema y devuelve al usuario a detect, para que el hallazgo entre por el mismo flujo en lugar de saltárselo. > **Hilo conductor: subida de archivos.** Un único hallazgo muestra la columna vertebral del flujo de principio a fin. > > - **detect** lo encuentra: el sistema acepta archivos de los usuarios, y el handler de subida confía en el tipo MIME que envía el cliente sin comprobar el tipo real del archivo. _Por qué importa:_ un archivo disfrazado de imagen puede ocultar código malicioso. > - **plan** decide la corrección, con prioridad **crítica**, en defensa del principio "Ninguna entrada es fiable hasta que se valida": comprobar el tipo real y el tamaño del archivo, renombrarlo al guardarlo y almacenar las subidas donde no puedan ejecutarse como código. > - **harden** la aplica, con estado **Applied**: el handler ahora detecta el tipo real a partir del contenido, impone un límite de tamaño, rechaza todo lo inesperado, renombra al guardar y almacena donde no se puede ejecutar código. > - **verify** lee el handler, lo contrasta con el registro y devuelve **Risk closed**: el código hace exactamente lo que afirma el registro. > > El mismo nombre de hallazgo recorre el mapa de detect, el plan y el registro de bastionado, y verify actúa sobre ese registro con el mismo nombre: un veredicto abierto se escribe en el bloque del hallazgo, y un hallazgo cuyo cierre se ha demostrado se da de baja (`§V`). Ese nombre compartido es su identidad (`§XI`). --- ## V. Posibilidad de cierre: un hallazgo tiene un estado final La mayoría de las herramientas de seguridad dejan al usuario una lista de pendientes que no para de crecer. SDH adopta otra postura: **un hallazgo se puede cerrar, así que tiene un estado final en lugar de vivir en una lista de pendientes interminable** (figura 2). Esto se deriva directamente del principio de conciliación. > **Definición** > > **Posibilidad de cierre:** un riesgo cuyo cierre se ha verificado se da de baja de todo el flujo, de modo que ese hallazgo queda en reposo y solo se reabre cuando cambia el código. Un hallazgo tiene un estado final, aunque el programa de seguridad en sí siga siendo continuo. Los artefactos de SDH son documentos vivos, no logs. Cada vez que una fase se vuelve a ejecutar, concilia cada entrada existente con la realidad actual y hace una de tres cosas: conserva lo que sigue siendo válido, reescribe lo que cambió o elimina lo que ya no lo es. Un hallazgo que, según el código, ya está resuelto simplemente se elimina. El registro de trabajo refleja el presente, no el pasado. El cierre es esa misma conciliación llegando a su conclusión. Cuando verify comprueba que un riesgo está cerrado, da de baja el hallazgo en todo el flujo: el mapa de detect, el plan, el registro de bastionado y el mapa de seguimiento. Por eso verify es la única fase que escribe en los artefactos de las demás: es la fase que cierra el ciclo. Cuando el hallazgo sale de la cadena, darlo de baja lo resume en una entrada breve de un historial que vive fuera de la cadena de trabajo y nunca se vuelve a procesar. Esa es la línea entre desaparecer y cerrarse: un hallazgo que la conciliación eliminó porque dejó de ser cierto no deja rastro, mientras que un hallazgo cuyo cierre se ha demostrado se gana su línea en el historial. Un hallazgo dado de baja ya no aparece en ningún artefacto de trabajo, y esa ausencia es lo esperado, no una cadena rota. ```mermaid stateDiagram-v2 direction TB [*] --> OPEN: detect lo detecta OPEN --> Plan: plan Plan --> Harden: harden Harden --> Verify: verify Verify --> StoodDown: Risk closed StoodDown --> SETTLED SETTLED --> OPEN: los cambios en el código reabren un hallazgo Plan: plan Harden: harden Verify: verify StoodDown: STOOD DOWN · una línea en el historial ``` **Figura 2.** La máquina de estados de la posibilidad de cierre. Un hallazgo pasa por OPEN → STOOD DOWN → SETTLED y solo se reabre cuando cambia el código. Cuando todo lo que está dentro del alcance se ha dado de baja, el ciclo queda en reposo, y ese estado tiene una forma concreta: un artefacto cuyo último hallazgo se cerró se elimina entero, así que una cadena completamente cerrada deja solo el charter y el historial, la política y la prueba. El ciclo solo se reabre cuando cambia el código. La metodología da a cada hallazgo un final definido, justo lo que una lista de pendientes interminable no puede dar. --- ## VI. La dualidad de la extensión del conocimiento del desarrollador SDH no sustituye a las personas ni a las herramientas especializadas de Blue Team. **Amplía el conocimiento del propio desarrollador**. Cuanto más entiende un desarrollador de seguridad, con más precisión puede dirigir el flujo y más autonomía tiene. Un desarrollador que entiende poco recibe igualmente un resultado seguro, porque el modo automático lo protege. La inversión de `§I`, según la cual el conocimiento de seguridad reside en la especificación, funciona en ambos sentidos. Para el principiante es protección: no necesita saber qué pedir, porque la especificación propone. Para el experto es amplificación: la misma especificación le permite dirigir el flujo con precisión en lugar de pelearse con una lista de comprobación fija. Cada fase lleva esta dualidad en su propio funcionamiento (figura 3). Sin ninguna entrada, actúa sobre todo el alcance en nombre del usuario. Con una orientación, la misma fase se limita exactamente a aquello a lo que el usuario la dirigió. ```mermaid flowchart TB inversion["una inversión, dos sentidos:
el conocimiento de seguridad reside en la especificación"] inversion --> auto["modo automático (sin entrada)
la fase propone y actúa
sobre todo el alcance"] inversion --> directed["modo dirigido (con entrada)
la fase se limita exactamente
a lo que el usuario le indicó"] auto --> novice["el principiante, protegido:
un resultado seguro sin
saber qué pedir"] directed --> expert["el experto, potenciado:
el flujo dirigido con precisión,
no una lista de comprobación fija"] novice -.-> phases["las mismas cinco fases sirven a ambos:
charter · detect · plan · harden · verify"] expert -.-> phases ``` **Figura 3.** La dualidad de la extensión del conocimiento del desarrollador. Una sola inversión sirve a dos públicos: el modo automático protege al principiante y el modo dirigido potencia al experto, con las mismas cinco fases. Las especializaciones bajo demanda (`§VII`) hacen explícita la dualidad en su propio texto. Cada una le dice al agente que su conocimiento "amplía tu criterio" y que siga razonando más allá de lo que aporta la especialización. El conocimiento es un suelo, no un techo. Esto es lo que sirve a ambos públicos en el equilibrio que busca el documento: la comunidad de desarrolladores obtiene un instrumento sólido, y el profesional de Blue Team, un vehículo estructurado que no pretende hacer su trabajo por él. --- ## VII. Especializaciones no invocables y prompt bajo demanda Este es el patrón más novedoso de la metodología. SDH incluye conocimiento de seguridad acotado en forma de especializaciones que se cargan **solo bajo demanda**, y es el propio agente quien decide cuáles cargar cotejándolas con el contexto del proyecto. Lo llamamos **prompt bajo demanda**: una forma de que el agente elija qué conocimiento activar según el alcance del proyecto en el que está, en lugar de ejecutar todas las comprobaciones por defecto. Las especializaciones evolucionan, y cualquiera de ellas puede cambiar o sustituirse en cualquier momento. La aportación es el patrón, no las especializaciones en sí. > **Definición** > > **Prompt bajo demanda:** el agente selecciona qué conocimiento de seguridad activar cotejándolo con el alcance del proyecto que tiene delante, de modo que se incorpora el conocimiento relevante para lo que el proyecto es realmente, en lugar de ejecutar todas las comprobaciones por defecto. > **Definición** > > **Especialización no invocable:** una unidad acotada de conocimiento de seguridad, independiente del lenguaje, dedicada a un contexto, como la subida de archivos o el código que se ejecuta en el navegador. Audita y explica, nunca reescribe código y nunca produce una entrada de ataque. No es un comando: se carga cuando el contexto que cubre está dentro del alcance, o cuando un prompt la pide por su nombre. Cada especialización nombra las formas más seguras para los riesgos que cubre y le indica al agente cómo actuar sobre un hallazgo en cada fase que la usa: cómo valorarlo en la detección, cómo aplicar su corrección de forma segura en la remediación y cómo demostrarlo en la verificación. El rasgo que la define es que una especialización **no se puede invocar por sí sola**: no es un comando, y dentro del flujo lo que la carga es una coincidencia. La fase de detección lista el catálogo una vez, coteja el contexto del proyecto con lo que cubre cada entrada y carga solo las especializaciones cuyo contexto está presente en el alcance. Las fases posteriores reutilizan esa lista de coincidencias en lugar de volver a listar, así que un solo cotejo sirve a toda la cadena, y el modo preventivo (`§IX`) hace el mismo cotejo con el trabajo que está a punto de desarrollarse. Una especialización cuyo contexto no está presente se omite, y la omisión se justifica igual que la carga: cada entrada del catálogo recibe un veredicto explícito, aplicada u omitida con el motivo extraído del código, de modo que una vaga sensación de irrelevancia nunca sustituye a la ausencia. No encontrar ninguna aplicable es un resultado válido. El catálogo son datos, y crecer consiste en añadir un archivo de conocimiento y una fila al catálogo, nunca un comando nuevo. Las especializaciones integradas se agrupan en categorías, como OWASP, un lenguaje o las integraciones de IA, y el catálogo que usa un proyecto reúne las integradas de las categorías que eligió más sus propias especializaciones. El proyecto registra esa elección junto con el resto de su estado, así que todo un equipo coteja con el mismo catálogo. Es el mismo principio de adaptación al contexto que el de las fases, aplicado al conocimiento: se incorpora el conocimiento relevante para lo que el proyecto es realmente, en lugar de ejecutar todas las comprobaciones por defecto. Esa misma propiedad permite que sea el usuario, y no solo quien lo mantiene, quien amplíe el catálogo: una fuente o un tema de seguridad que aporta el usuario se condensa en una especialización nueva que pertenece al proyecto, se suma a su catálogo sean cuales sean las categorías y se carga exactamente igual que una integrada, a la que sustituye si tiene el mismo nombre. Crear una especialización también es una actividad exclusivamente defensiva y respeta el mismo límite que imponen las especializaciones: un informe de ataque puede ser la fuente, pero la especialización resultante audita y explica, y nunca emite un exploit funcional. Así, la inversión de `§I`, la inteligencia que reside en la especificación, se extiende al propio catálogo, que el usuario puede enriquecer para su contexto sin escribir código. Un ejemplo breve ilustra el prompt bajo demanda. Detect lee una carpeta de código que se ejecuta en el navegador. Coteja ese contexto con el catálogo, carga la especialización que lo cubre y expone un hallazgo del lado del cliente siguiendo los pasos habituales de detect. Las especializaciones cuyo contexto no está en este alcance no coinciden, así que nunca se cargan, y cada una queda registrada como omitida. Fue el proyecto, y no una configuración fija, lo que decidió qué conocimiento era relevante. El determinismo aparece justo donde importa. Una especialización puede incluir un comprobador determinista, no solo prosa: cuando una clase de riesgo tiene un procedimiento de decisión claro, un pequeño programa devuelve un veredicto fijo para una entrada dada, por ejemplo un conjunto corto de palabras como `safe`, `unsafe` o `invalid input`. Algunas clases de riesgo se pueden decidir de forma determinista exactamente así, con un cuerpo de trabajos previos que respalda el procedimiento de decisión `[9]`, `[10]`, `[11]`. El comprobador puntúa los candidatos que le pasa el agente o analiza el alcance para encontrarlos por sí mismo, y en ambos casos es el comprobador, no el agente, quien devuelve el veredicto. Una especialización lo bastante universal puede marcarse como obligatoria en el catálogo, y entonces se aplica siempre, con su comprobador ejecutado sobre todo el alcance. Es el único caso en que un conocimiento se carga sin coincidir con el contexto, y se declara en los datos del catálogo, nunca lo decide el agente sobre la marcha. Aquí es donde SDH ancla el razonamiento del agente en algo repetible, sin fingir que todo el flujo es determinista. Por último, las especializaciones son **separables**. Como el conocimiento se sostiene por sí mismo, un usuario puede ejecutar una directamente en un prompt que no tiene nada que ver con el flujo completo de SDH, y mantener así la seguridad junto al desarrollo habitual. Una especialización con un comprobador determinista puede, por ejemplo, filtrar cada candidato generado durante la programación habitual y quedarse solo con los seguros. Esta posibilidad de usarlas por separado explica en parte por qué SDH se adapta a tantas situaciones, que es el tema de `§VIII`, y su expresión más completa es el modo preventivo (`§IX`), en el que el mismo conocimiento protege el desarrollo habitual de principio a fin. --- ## VIII. Independencia del estado y adaptabilidad no prescriptiva Dos propiedades distinguen SDH de las metodologías de especificación rígidas. ### Independencia del estado > **Definición** > > **Independencia del estado:** la metodología no depende del estado del desarrollo. Se ajusta a un directorio vacío, a un proyecto en curso, a un único pull request o a un gran código heredado, con cualquier stack, porque averigua el punto de partida leyéndolo. Cada fase funciona igual tanto si el proyecto es totalmente nuevo como si ya existe. El charter infiere principios a partir del código que haya. Detect identifica el código que encuentre, aunque sea muy poco. No se presupone ningún punto de partida. ### Adaptabilidad no prescriptiva > **Definición** > > **Adaptabilidad no prescriptiva:** la metodología se adapta al escenario en lugar de imponer un alcance fijo que el usuario deba seguir. Cuando el usuario no sabe qué decir, lee el entorno desde el que se la invocó, genera contexto y hace las preguntas que determinan lo que hará a continuación. El modo de propuesta del charter es el caso más claro: SDH deriva un charter seguro por defecto analizando el proyecto, pregunta al usuario solo cuando una carencia cambia de verdad el resultado y, después, lo escribe y presenta cada principio en lenguaje claro junto con el riesgo que previene. El charter es un documento vivo que el usuario reelabora volviendo a ejecutarlo, no un contrato bloqueado tras una petición de aprobación, así que nunca exige que el usuario sepa qué pedir. Esta adaptabilidad se manifiesta como una sensibilidad a la forma de la entrada: la misma fase lee lo que ha recibido y elige un modo (figura 4). Un archivo en el prompt, un hallazgo de la lista, una preocupación, una misión acotada contra un punto débil conocido o la petición de un análisis completo por fuerza bruta: cada uno se ajusta a lo que necesita el usuario, porque el flujo es no prescriptivo por diseño. Nada de esto debilita la base segura por defecto. La flexibilidad determina cómo se aplica la base, nunca la rebaja. ```mermaid flowchart TB shape["la fase lee la forma
de lo que ha recibido"] shape --> none["sin entrada"] shape --> paths["una o más rutas"] shape --> concern["una preocupación descrita"] shape --> finding["un hallazgo con nombre"] shape --> band["una franja de prioridad"] none --> auto["el modo automático:
proponer o analizar
todo el alcance"] paths --> focus["centrarse solo en esos
archivos o directorios"] concern --> scoped["limitar el alcance a
esa preocupación"] finding --> item["actuar sobre ese único
elemento en seguimiento"] band --> priority["actuar solo sobre crítica,
alta, media o baja"] ``` **Figura 4.** Adaptabilidad no prescriptiva. La misma fase lee la forma de su entrada y elige un modo, así que el alcance siempre lo decide el usuario, nunca se impone. --- ## IX. El modo preventivo universal: la misma defensa mientras se desarrolla el trabajo SDH incluye un modo complementario: el desarrollo habitual hecho con la misma defensa activa mientras se escribe el código. El usuario pide el propio trabajo, una página de inicio de sesión, una subida de archivos, un endpoint, y la metodología protege el desarrollo a medida que avanza, para que el resultado sea seguro por defecto desde el momento en que llega, en lugar de después de una pasada posterior de bastionado. > **Definición** > > **El modo preventivo:** desarrollo habitual ejecutado bajo la capa rectora y el conocimiento de SDH. El charter rige el desarrollo, las especializaciones relevantes para lo que está a punto de crearse se cargan bajo demanda, y el resultado se contrasta exactamente con la defensa que se usó antes de dar el trabajo por terminado. El modo reutiliza cada pieza que ya llevan las fases, apuntada a código que todavía no existe. La detección de contexto pasa del código a la intención: el agente razona sobre lo que va a construir y las fronteras que cruza ese trabajo (un inicio de sesión implica credenciales, una sesión y entradas del exterior), y ese razonamiento es lo que se coteja con el catálogo de conocimiento. El prompt bajo demanda (`§VII`) se generaliza aquí: el contexto puede detectarse en el plan del código, no solo en código que ya existe. El charter rige como siempre, y una petición que incumpliría un principio se expone como conflicto, nunca se construye. La defensa se aplica sobre la marcha, en el momento en que se escribe cada parte, validando en la frontera y recurriendo a la construcción segura desde el primer momento, así que nunca llega a existir una versión que funciona pero es insegura y que haya que corregir. El modo termina como empieza verify. Antes de dar el trabajo por terminado, quien lo construye contrasta su propio resultado con la defensa que usó: el control debe estar en el camino del riesgo, no al lado, debe estar completo y, cuando una especialización incluye un comprobador determinista, el veredicto del comprobador prevalece sobre la propia lectura del agente. Una carencia encontrada aquí se cierra como parte del mismo trabajo, porque terminar el trabajo significa terminarlo de forma segura. Lo que el modo rechaza es tan deliberado como lo que hace. Construye solo lo que se pidió y no audita nada de su alrededor: auditar lo que ya existe es cosa de las fases. No escribe ningún artefacto ni hace seguimiento de ningún hallazgo, porque un hallazgo es un riesgo detectado en lo que ya existe, y el propósito de este modo es que la versión insegura nunca llegue a existir. Las dos direcciones se complementan: las fases cierran lo que ya está ahí (`§V`), y el modo preventivo evita que el trabajo nuevo lo reabra. Una cadena en reposo sigue en reposo no porque el desarrollo se haya detenido, sino porque lo que se construye mientras descansa se construye ya defendido. --- ## X. Security-Driven Hardening frente a Spec-Driven Development Security-Driven Hardening (SDH) nació de la base de Spec-Driven Development (SDD) y después se apartó claramente de ella. La herencia estructural es real y reconocida: spec-first, guiado por agentes, un documento rector y un conjunto de comandos por fases que ejecuta el agente. SDH reutiliza esa estructura de forma deliberada. Lo que cambia es el propósito, el modelo de autoridad, el estado que se presupone y la condición de finalización. Tratamos SDD como una clase, y tomamos el informe de Piskala `[1]` como la formulación canónica de la metodología, Spec Kit de GitHub `[2]` como el kit de herramientas canónico para agentes y OpenSpec `[3]` como segunda herramienta de la misma familia. SDD da la vuelta al desarrollo tradicional al hacer ejecutables las especificaciones: la especificación genera directamente una implementación que funciona, en lugar de limitarse a orientarla `[1]`. Su conjunto de fases hace avanzar la construcción `[2]` (establecer los principios rectores, especificar qué construir, planificar el stack tecnológico, dividir el plan en tareas y después implementar). Su documento rector, una constitución de principios, es la pieza fundamental a la que el agente debe ceñirse en todo momento. Ahí está el núcleo de la diferencia. En SDD, la autoridad fluye de la especificación hacia la construcción, y se espera que la implementación la siga. SDH invierte casi todos los ejes de ese contrato (tabla 3). > **Idea clave** > > **La diferencia central:** en SDD, la autoridad fluye de la especificación hacia la construcción, y se espera que la implementación la siga. SDH es no prescriptiva y fluye en sentido contrario, hacia dentro, a partir del contexto detectado en el sistema, bastionando lo que ya existe. | Eje | SDD | SDH | | -------------------------- | ------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | | Objetivo | Entregar funcionalidades. La especificación se convierte en una implementación que funciona. | Bastionar lo que existe o se está construyendo. Cada fase se plantea desde la defensa. | | Modelo de autoridad | Prescriptivo. La especificación y la constitución limitan la construcción a un alcance que debe seguir. | No prescriptivo. SDH se adapta al escenario, y el usuario puede reformular, descartar o acotar. | | Estado que presupone | Una construcción hacia delante a partir de una especificación. | Independiente del estado: directorio vacío, proyecto en curso, un único PR o código heredado. | | Condición de finalización | Termina cuando se ha construido la funcionalidad. | Se puede cerrar. Un hallazgo queda en reposo y solo se reabre cuando cambia el código. | | Documento rector | Una constitución de principios a la que el agente debe ceñirse. | Un charter de principios planteados desde el riesgo (cada uno con una línea `Why:`), que expresamente no es un contrato fijo. | | Cómo crece el conocimiento | Añadiendo un comando (o ampliando el conjunto de fases). | Añadiendo una especialización no invocable que el agente carga bajo demanda: un archivo más una fila del catálogo, sin comandos nuevos. | | A quién sirve | A quien impulsa el desarrollo de una funcionalidad. | A cualquier usuario, sea desarrollador o no, con el mismo flujo. | | Qué modifica el código | La fase de implementación genera la construcción. | Solo la fase harden modifica el código, una corrección cada vez. | **Tabla 3.** SDD frente a SDH en ocho ejes. Estructura prestada, contrato invertido. Para ser justos con el linaje: SDD es un antecedente probado, y SDH le debe la estructura sobre la que funciona. La divergencia no es una crítica a SDD, que resuelve bien otro problema (construir hacia delante). SDH toma la misma maquinaria probada y la orienta a la defensa, la adaptabilidad y el cierre. OpenSpec `[3]`, organizado en torno a propuestas de cambio, listas de tareas y especificaciones por cambio, confirma el patrón: la familia hace avanzar una construcción a partir de una especificación, mientras que SDH bastiona un sistema hacia dentro a partir de su contexto detectado. Incluso el modo preventivo de SDH (`§IX`), el único punto en el que acompaña una construcción hacia delante, mantiene el contrato invertido: rige cómo se construye el trabajo y nunca decide qué construir. --- ## XI. Rigor de ingeniería: la disciplina del seguimiento La disciplina de conciliar, nunca solo añadir (`§V`) necesita una base que sobreviva a las refactorizaciones. Un hallazgo debe seguir siendo un único elemento en todas las fases que lo tocan, y un archivo renombrado o movido no debe romper la cadena. SDH lo resuelve con la **identidad por nombre** y las **rutas guardadas solo en el seguimiento**. > **Definición** > > **Identidad por nombre:** la identidad de un hallazgo es su nombre, escrito de forma idéntica en todos los artefactos. El texto lleva el nombre, nunca una ruta. Las rutas de archivo viven solo en el mapa de seguimiento, así que un cambio de nombre o un archivo movido rompe el vínculo en un único lugar. Cada hallazgo de detect es un elemento en seguimiento. Su identidad es su **nombre**, el título de la sección, escrito de forma idéntica en el mapa de detect, el plan y el registro de bastionado. Las fases posteriores reutilizan ese nombre al pie de la letra cuando actúan sobre el mismo elemento, y verify escribe su veredicto en el registro de bastionado con ese mismo nombre. El mapa de seguimiento contiene seguimiento y nada más, una entrada por elemento: ```json { "name": "File uploads", "paths": ["src/routes/upload.ts"] } ``` El mapa no registra texto, ni anotaciones, ni un identificador aparte, ni la fase. Los artefactos de texto llevan la redacción, y el mapa solo lleva la identidad y las rutas. Las rutas de archivo son lo único volátil, y viven solo aquí. Un cambio de nombre o un archivo movido puede romper el vínculo en un único lugar, nunca en dos copias que divergen. ```mermaid flowchart TB detect["el mapa de detect"] --> name plan["el plan de defensa"] --> name harden["el registro de bastionado
verify escribe aquí su veredicto"] --> name name["name = "File uploads"
el texto lleva el nombre, nunca una ruta"] name -.-> tracking tracking["el mapa de seguimiento
{ name: "File uploads",
paths: ["src/routes/upload.ts"] }
la ruta vive solo aquí, así que un cambio de nombre solo corrige esta entrada"] ``` **Figura 5.** La cinta transportadora de la identidad. Un único nombre de hallazgo recorre todos los artefactos, mientras que su ruta vive solo en el mapa de seguimiento, así que un cambio de nombre se corrige en un solo lugar. Dos actos mantienen el mapa en el flujo normal, y un tercero queda aparte como mantenimiento. **Track** es el registro aditivo: una fase comunica los hallazgos que ha escrito, y el motor registra los nuevos y sigue la ruta renombrada del resto, clasificando cada uno como nuevo, movido o sin cambios. Nunca elimina nada que la fase no haya comunicado. **Untrack** da de baja los hallazgos que verify cerró: en una sola pasada determinista, resume cada uno en su entrada del historial, elimina su sección entera de los artefactos, borra un artefacto cuyo último hallazgo ha desaparecido y quita su entrada de seguimiento, así que el agente no hace nada de eso a mano. Donde la pasada determinista no puede avanzar con seguridad, como un nombre dado de baja que aún se cita en el texto de otro hallazgo, señala ese punto al agente en lugar de adivinar una edición. Estos dos son los que llaman las fases mientras se ejecutan. **Repair** es el acto de mantenimiento: una fase delega en él automáticamente cuando su propia conciliación encuentra el seguimiento incoherente (una ruta registrada que ya no existe), y en los demás casos se ejecuta bajo demanda. Realinea todo el mapa de una vez, leyendo todos los artefactos y el código actual, corrigiendo las rutas de cada elemento y exponiendo lo que no puede decidir solo: un huérfano (un elemento en seguimiento que ya no nombra ningún artefacto) o un posible renombrado (un elemento cuyas rutas coinciden con otro nombre comunicado). Repair es mantenimiento, no una sexta fase. No toca ni el código del usuario ni los artefactos de texto, solo el seguimiento. Lee el código fuente del usuario por un único motivo, averiguar la nueva ruta de un archivo renombrado, y nunca crea contenido de seguridad. La persona tiene la última palabra en la única decisión que el motor se niega a adivinar: si un elemento desaparecido se resolvió o solo se renombró. Mejor preguntar que adivinar, porque un elemento descartado por error rompe la cadena. La metodología se aplica a sí misma su disciplina defensiva. Los motores deterministas se invocan como programas de línea de comandos, y cada entrada se pasa como un argumento de proceso independiente, lo que la mantiene inerte, de modo que un valor con comillas o comillas invertidas nunca puede inyectarse en el comando. Una comprobación desconocida falla en lugar de responder, así que una mal escrita nunca se lee como un resultado limpio. SDH no exime a su propia infraestructura interna del principio de seguridad por defecto. --- ## XII. El vehículo: una arquitectura independiente del agente como prueba de portabilidad Para que SDH sea una convención que otros adopten, no puede estar atada a un agente ni a un stack, así que su vehículo mantiene separadas tres responsabilidades (figura 6). Lagune demuestra que es posible. **El valor de seguridad** se escribe una sola vez y no sabe nada del agente que lo ejecuta: las instrucciones de las fases y las plantillas que rellenan, el catálogo de conocimiento y los motores deterministas. **La distribución** es ligera: su única tarea es llevar ese valor a cada agente en la forma y el lugar que el agente espera, y no incluye lógica de seguridad propia. **El estado del proyecto** pertenece al proyecto: el charter, los artefactos de las fases, el mapa de seguimiento, las categorías que eligió y sus propias especializaciones, versionados y revisables como cualquier otra parte de su código. ```mermaid flowchart TB value["el valor de seguridad, escrito una sola vez
instrucciones de las fases · plantillas · catálogo de conocimiento · motores deterministas
no sabe nada del agente que lo ejecuta"] delivery["la distribución
lleva ese valor a cada agente en la forma que espera
no incluye lógica de seguridad"] agent["el agente
ejecuta las fases"] project["el estado del proyecto
versionado con su código
charter · artefactos de las fases · seguimiento · categorías · especializaciones propias"] value --> delivery --> agent agent -->|"lee y escribe"| project ``` **Figura 6.** El vehículo independiente del agente. El valor de seguridad se escribe una sola vez, una distribución ligera lo lleva a cada agente y el estado sigue siendo del proyecto. Como la distribución no incluye lógica de seguridad, la forma de construirla no cambia nada en SDH. Un vehículo puede construir la distribución por sí mismo o delegarla en un ecosistema que ya distribuye skills de agentes, como hace la implementación de referencia, y las fases, sus artefactos y sus garantías siguen siendo los mismos. Nada de esto depende tampoco de un lenguaje o un entorno de ejecución. La implementación de referencia está escrita en un stack concreto, pero la metodología es la frontera entre estas responsabilidades, no la cadena de herramientas que las construye. El mismo diseño podría reimplementarse en un lenguaje completamente distinto sin cambiar lo que es SDH. --- ## XIII. Caso práctico: SDH de principio a fin > **Caso práctico** > > **Bastionado defensivo de una superficie de subida de archivos y administración.** > **Contexto:** una pequeña aplicación que acepta archivos subidos por los usuarios y los lista en una página de administración. > **Patrón:** charter → detect (con conocimiento bajo demanda activado por el contexto) → plan → harden → verify, con un cierre y un fallo real. > **Resultado (capacidad):** un riesgo cuyo cierre se verifica y que se da de baja en toda la cadena, y un control que se verifica como _no_ cerrado y se devuelve a harden. El veredicto refleja el código, no el registro. _Este es un ejemplo práctico ilustrativo de la mecánica de la metodología, no un estudio medido en condiciones reales, y no aporta métricas de eficacia._ Un recorrido continuo muestra la metodología en funcionamiento, no solo sus partes. Ampliamos el hilo de la subida de archivos de `§IV` con una activación de conocimiento bajo demanda y un cierre, e incluimos un fallo real. 1. **charter** propone el principio "Ninguna entrada es fiable hasta que se valida", con su riesgo en lenguaje claro: la entrada que no se comprueba es la forma más habitual de comprometer un sistema. 2. **detect** analiza la ruta de subida y la pequeña página de administración que lista los archivos subidos. Detecta el hallazgo de la subida (el handler confía en el tipo MIME del cliente). La página de administración se ejecuta en el navegador, un contexto que el prompt bajo demanda (`§VII`) reconoce, así que detect carga la especialización de ese contexto y expone un segundo hallazgo: un punto donde un nombre de archivo se escribe en la página como marcado en lugar de como texto, de modo que un nombre manipulado puede ejecutarse como script en el navegador del visitante. Las especializaciones cuyo contexto no está en este alcance nunca se cargan, y cada omisión se registra con la ausencia extraída del código. 3. **plan** asigna a la corrección de la subida la prioridad crítica, vinculada al principio: comprobar el tipo real y el tamaño del archivo, renombrarlo al guardarlo y almacenarlo donde no se pueda ejecutar código. Asigna a la segunda corrección la prioridad alta: mostrar el nombre del archivo como texto, no como marcado. 4. **harden** aplica primero la corrección de la subida (la de mayor prioridad) y la registra como Applied, y después la segunda, también Applied. 5. **verify** lee cada punto y contrasta el código con el registro. El control de la subida se sostiene: el handler detecta el tipo real a partir del contenido, impone un límite de tamaño y rechaza el resto. Veredicto: Risk closed. Verify da de baja el hallazgo de la subida en toda la cadena, y su resumen pasa al historial. A continuación viene el fallo real. Supongamos que la segunda corrección de harden añadió una función auxiliar segura para mostrar texto, pero dejó la antigua llamada que escribe marcado todavía alcanzable por otro camino del código. Verify lee la página, ve la función auxiliar segura y ve también que el camino inseguro sigue activo. El control está presente, pero el riesgo no está cerrado. Verify se niega a suavizar el veredicto para que coincida con el registro. Devuelve "Risk not closed", registra la carencia y remite de nuevo a harden. Un control que no aborda el riesgo por completo no es un aprobado. Así es la metodología en un solo ejemplo: detección adaptada al contexto, correcciones priorizadas y vinculadas a principios, aplicación cuidadosa y una verificación que informa del estado real del código, diga lo que diga el registro. --- ## XIV. Cuándo usar SDH y cuáles son sus límites SDH rara vez resulta desproporcionada como puede serlo un proceso pesado, porque es independiente del estado y se puede cerrar: se reduce a un solo archivo y una sola preocupación, y llega a un estado de reposo en lugar de dejar una carga permanente. Su límite no es el tamaño del proyecto, sino la **profundidad de la garantía**. ```mermaid flowchart TB q1{"¿El código hace algo relevante para la seguridad?
(entradas, autenticación, datos, secretos, llamadas externas)"} q1 -->|no| little["SDH aporta poco aquí."] q1 -->|sí| q2{"Ejecuta SDH. ¿Hay un requisito de cumplimiento normativo
o una función de seguridad dedicada?"} q2 -->|no| baseline["SDH es una base defendible."] q2 -->|sí| carrier["SDH es el vehículo estructurado:
apoya la revisión y la auditoría expertas,
no las sustituye."] ``` **Figura 7.** Cuándo usar SDH. La decisión depende primero de la relevancia para la seguridad y después de la profundidad de la garantía, nunca del tamaño del proyecto. SDH llega a su límite en estos casos: el comportamiento que solo aparece cuando el sistema se ejecuta (verify lee el código, no ejecuta el sistema), el riesgo que depende de una configuración o de un entorno que el agente no puede leer, y los contextos en los que hay mucho en juego y la revisión experta es obligatoria en cualquier caso. En todos ellos, SDH sigue aportando valor como primera pasada estructurada, pero es un suelo, no un techo. > **Idea clave** > > **El límite:** el límite de SDH es la profundidad de la garantía, no el tamaño del proyecto. Puede servir como base defendible casi en cualquier parte y apoya la revisión experta cuando lo que está en juego lo exige, pero no sustituye las pruebas sobre un sistema en ejecución ni el criterio de un profesional de seguridad. --- ## XV. Discusión: posicionamiento, límites y lo que SDH no afirma SDH es precisa sobre sus límites. ### Amplía, no sustituye SDH no sustituye a los profesionales de seguridad ni a las herramientas especializadas de Blue Team. Amplía el conocimiento del desarrollador (`§VI`). Lo correcto es una afirmación mesurada: bien aplicada, SDH **puede** cerrar riesgos reales con eficacia, sobre todo en proyectos que de otro modo no recibirían ninguna revisión de seguridad. No es una garantía, ni sustituye a la revisión experta cuando lo que está en juego la exige. ### Solo defensa, por construcción SDH audita, bastiona y verifica. Nunca produce herramientas ofensivas, exploits ni técnicas de evasión de la detección para causar daño. El contenido de seguridad de doble uso solo es aceptable en un marco claramente defensivo y autorizado. Es un límite firme, no una preferencia. ### La verificación es sustancial, no teatral Verify verifica leyendo el código y contrastándolo con el registro, no ejecutando el sistema. Es una verificación estática: confirma que un control está presente y es correcto en el código, y no demuestra que el control resista un ataque en tiempo de ejecución. Por eso "Cannot tell from the code" es un veredicto legítimo, no un fallo disfrazado de aprobado. Cuando la evidencia no está en el código (depende de la configuración o de un camino que el agente no puede leer), SDH lo dice en lugar de suponer. ### El determinismo está acotado y tiene nombre La mayor parte de SDH se basa en el razonamiento del agente, que es lo que hace posible su adaptación al contexto. El determinismo se reserva para los motores deterministas: los comprobadores que puede incluir una especialización (`§VII`) y el motor de seguimiento (`§XI`). El documento no difumina esta línea. Donde un resultado es determinista, es el resultado de un programa. Donde es razonado, es la lectura del código que hace el agente, con el usuario como árbitro final. ### Coste y escala Un análisis completo consume muchos tokens. Los modos manuales (`§VI`, `§VIII`) existen en parte para que el coste sea proporcional a la preocupación. ### El usuario es el árbitro final SDH pide a la persona que decida entre renombrado y resuelto, y la aprobación de sus ediciones de código se queda donde el usuario ya gobierna a su agente, en el modo de permisos con el que lo ejecuta. La metodología propone y verifica. No pasa por encima de la persona. ### Objeciones y respuestas Un escéptico razonable planteará varias objeciones. Las de fondo merecen formularse con sus propias palabras. **"¿No es esto solo un analizador estático con un LLM encima?"** No. Un analizador estático ejecuta por defecto todas las reglas que tiene. SDH detecta primero qué es el sistema, después recurre al conocimiento relevante (`§II`, `§VII`), y solo _integra_ un comprobador determinista donde una clase de riesgo tiene un procedimiento de decisión claro. El razonamiento parte del contexto, y el determinismo es selectivo. **"¿No es esto solo una lista de comprobación de seguridad?"** No. SDH invierte la lista de comprobación: la detección va primero, y el conocimiento se incorpora según lo que el proyecto hace realmente (`§II`, `§VII`). **"¿No es esto solo SDD rebautizado para la seguridad?"** No. SDH toma prestada la estructura de SDD e invierte su contrato: la autoridad, el estado que presupone, la condición de finalización y a quién sirve son distintos (`§X`). La misma maquinaria, en sentido contrario. **"¿Un método razonado por IA no se limita a alucinar hallazgos?"** El diseño restringe la invención en lugar de confiar en que el modelo se porte bien. Detect registra solo lo que respalda el código ("detección, no invención", `§IV`), verify contrasta el código con el registro y puede responder "Cannot tell from the code" (`§XV`), los comprobadores deterministas fundamentan los casos decidibles (`§VII`) y el usuario es el árbitro final. Esto no hace infalible al agente, pero sí hace verificables sus afirmaciones. Una nota sobre el posicionamiento. Aquí SDH se define con independencia de su implementación de referencia. Las cinco fases, el charter planteado desde el riesgo, conciliar en lugar de solo añadir y su posibilidad de cierre, el conocimiento con prompt bajo demanda, el modo preventivo, el seguimiento con identidad por nombre y el límite exclusivamente defensivo son la metodología. Otro equipo podría implementarlos en otro stack y en otro ecosistema de agentes, y el resultado seguiría siendo SDH. Lagune es su prueba, no su definición. --- ## XVI. Escollos y cómo los evita SDH por su estructura Las metodologías de esta familia comparten un conjunto conocido de modos de fallo. La respuesta de SDH a la mayoría es estructural: está integrada en el flujo en lugar de dejarse a la disciplina. | Escollo | El fallo | La respuesta estructural de SDH | | -------------------------------------------------------- | ------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------- | | Especificación deteriorada, lista de pendientes obsoleta | Los artefactos acumulan entradas muertas de las que nadie se fía | Conciliar, nunca solo añadir (`§V`): cada ejecución revisa todas las entradas y elimina lo resuelto | | Falsa confianza, resultado favorable | Se da por hecho que un control presente cierra el riesgo | Verify contrasta el código con el registro, así que "Risk not closed" y "Cannot tell" son veredictos de primera clase (`§IV`, `§XV`) | | Avalancha de comprobaciones | Los elementos genéricos tapan el único riesgo que importa | Adaptado al contexto antes que genérico, con el prompt bajo demanda cargando solo lo que pide el alcance (`§VII`) | | Dependencia de una herramienta | El método queda soldado a un proveedor o agente | Vehículo independiente del agente: el valor de seguridad se escribe una sola vez, y su distribución a cada agente no incluye lógica de seguridad (`§XII`) | | El bucle sin fin | La lista de pendientes nunca se cierra y el trabajo nunca descansa | La posibilidad de cierre y el estado de reposo (`§V`) | **Tabla 4.** Escollos conocidos en esta familia de metodologías y la respuesta estructural de SDH a cada uno. Lo importante es nombrar el escollo y señalar el mecanismo: no son avisos para tener cuidado, son propiedades del flujo. --- ## XVII. Trabajo futuro La metodología y su implementación de referencia tienen próximos pasos claros. - **Ampliar el catálogo de conocimiento:** Cada incorporación mantiene la forma de `§VII`: un archivo de conocimiento y una fila del catálogo, sin comandos nuevos. La vía del usuario ya existe ahí: el usuario condensa sus propias especializaciones bajo demanda. Más lenguajes, entornos de ejecución y clases de riesgo integrados, cada uno dentro de una categoría, son la dirección por parte de quien mantiene el proyecto, y se espera que las especializaciones evolucionen. - **Más comprobadores deterministas:** Cuando una clase de riesgo tiene un procedimiento de decisión claro, una especialización puede incluir un comprobador determinista que ancle el razonamiento del agente en un veredicto repetible. Extender esto a más clases de riesgo es una dirección natural. - **Evaluación empírica:** La pregunta abierta más importante es la eficacia medida: la calidad de los cierres y la tasa de veredictos erróneos en proyectos reales. Un estudio de los resultados de seguridad de SDH queda como trabajo futuro, y las afirmaciones de este documento se limitan en consecuencia. --- ## XVIII. Conclusión El desarrollo asistido por IA abrió una brecha de seguridad que las listas de comprobación genéricas no pueden cubrir, porque el riesgo que importa depende de lo que hace realmente cada sistema, y quien lo publica puede no saber qué pedir. SDH cierra esa brecha con un flujo adaptado al contexto, exclusivamente defensivo y que se puede cerrar, en el que el conocimiento de seguridad reside en la metodología y en sus especializaciones bajo demanda, una base sobre la que cualquier usuario puede construir. Detecta el contexto real del sistema, hace el triaje de los riesgos que ese contexto conlleva, aplica las correcciones con cuidado y verifica cada una, y después da de baja lo que ha cerrado para que cada hallazgo llegue a un estado final. La misma defensa actúa también de forma preventiva mientras se desarrolla el trabajo nuevo, así que lo que el flujo cierra sigue cerrado. Se adapta a cualquier estado de desarrollo con cualquier stack, y amplía el conocimiento del desarrollador en lugar de sustituir a las personas y herramientas que ya hacen ese trabajo. Lagune es la prueba, pero la aportación es la convención. SDH se ofrece como el flujo de seguridad esencial para la era del desarrollo con IA, para que otros lo adopten, lo perfeccionen y lo implementen en sus propios stacks. --- ## Referencias **[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. --- ## Apéndice A: los principios, al pie de la letra 1. **Seguro por defecto, en lenguaje claro, para todos por igual:** Cada valor por defecto, mensaje y corrección debe ser seguro desde el principio y comprensible para cualquier usuario, sea desarrollador o no. No se privilegia a ningún tipo de usuario sobre otro. 2. **Adaptado al contexto antes que genérico:** Cada fase debe partir del contexto detectado en detect y actuar sobre lo que el sistema hace realmente. Prioriza las recomendaciones específicas de ese contexto frente a las listas de comprobación genéricas. El conocimiento de seguridad reside en la especificación y en sus especializaciones bajo demanda, y amplía lo que aporte el usuario. 3. **Flexible antes que rígido:** SDH se adapta al proyecto y al usuario. Los principios, requisitos y recomendaciones son puntos de partida, no un contrato fijo. Deja que el usuario reformule, descarte, añada o acote cualquier cosa. La flexibilidad nunca debilita la base segura por defecto, solo permite al usuario decidir cómo se aplica. 4. **Conciliar, nunca solo añadir:** Los artefactos son documentos vivos, no logs. Cuando una fase se vuelve a ejecutar, concilia cada entrada existente con la realidad actual: conserva lo que sigue siendo válido, reescribe lo que cambió y elimina lo que ya no lo es. El cierre es esa misma conciliación llegando a su conclusión. 5. **Solo defensa:** SDH audita, bastiona y verifica. Nunca produce herramientas ofensivas, exploits con fines maliciosos ni técnicas de evasión de la detección para causar daño. El contenido de seguridad de doble uso solo es aceptable en un marco claramente defensivo y autorizado. 6. **Spec-first, guiado por agentes, orientado a la seguridad:** Construye el flujo de trabajo a partir de una estructura probada: plantillas, comandos, un charter rector y un agente que ejecuta las fases. Reimplementa esa estructura con un propósito defensivo. --- # Glosario de Lagune: SDH, charter, hallazgos y controles > Definiciones en lenguaje sencillo de cada término de Lagune y de Security-Driven Hardening: SDH, charter, detect, hallazgo, control, harden, verify, dar de baja, posibilidad de cierre, especializaciones, categorías y el catálogo. URL canónica: https://lagune.ai/es-ES/docs/references/glossary Idioma: es-ES Original: https://lagune.ai/docs/references/glossary Última actualización: 2026-11-03 Cada término clave de Lagune y de la metodología Security-Driven Hardening, definido una sola vez y en lenguaje sencillo. ### Security-Driven Hardening (SDH) La metodología que implementa Lagune: una convención Blue Team, adaptada al contexto, que detecta el contexto de un sistema, hace el triaje de los riesgos que ese contexto conlleva y guía las correcciones. El conocimiento de seguridad reside en la especificación y en sus especializaciones bajo demanda, así que quien programa y quien no programa siguen el mismo flujo. ### Lagune La implementación de referencia de SDH: nueve comandos de agente, cada uno con la plantilla que rellena, que un agente de IA ejecuta para bastionar un proyecto. Cada agente los instala con su propio instalador de plugins o con [**skills.sh**](https://www.skills.sh/wellwelwel/lagune), como muestra la [página de instalación](https://lagune.ai/es-ES/docs), y estos ejecutan el motor de Lagune en cada paso determinista. ### Charter La capa rectora de Lagune: un conjunto de principios que anteponen la seguridad y que toda fase posterior debe respetar. Piensa en él como la comprobación en tiempo de compilación de la postura de seguridad de un proyecto. Se guarda en `.lagune/memory/charter.md`. ### Flujo de desarrollo El comando universal `/lagune`, que bastiona el trabajo a medida que se escribe. Acepta cualquier prompt en cualquier etapa, construye lo que has pedido y lo bastiona con valores por defecto seguros antes de devolvértelo, guiado por el charter cuando existe. No escribe nada en el seguimiento de Lagune, así que su único producto es el código bastionado. Junto con el charter (antes) y el flujo Blue Team (después), es la forma en que Lagune protege durante el desarrollo. ### Flujo Blue Team La auditoría en cinco fases que está en el centro de Lagune: charter, detect, plan, harden y verify. Cada fase se apoya en la anterior. "Blue Team" es la tradición de seguridad de los defensores, en contraposición al Red Team, que es ofensivo. ### Hallazgo Un riesgo detectado. Cada hallazgo recoge qué es, por qué importa y la evidencia en el código. Un hallazgo es la unidad de seguimiento que plan, harden y verify llevan de una fase a la siguiente, identificada por su nombre en todos los artefactos. ### Control Una medida de seguridad que se aplica para cerrar un riesgo. Harden aplica los controles y verify demuestra que se sostienen. Lagune nunca debilita un control para satisfacer lo que pide un prompt. ### Detect La fase que lee el código e identifica qué hace el sistema y dónde están los riesgos. Su regla rectora es detectar, no inventar: solo registra lo que el código respalda. ### Harden La única fase que toca tu código. Aplica las correcciones del plan de una en una y registra cada una como Applied, Partial o Blocked. Applied no significa que ya esté demostrada. ### Verify La fase que demuestra que cada corrección aplicada se sostiene, leyendo el código y contrastándolo con lo que registró harden. Devuelve uno de tres veredictos: Risk closed, Risk not closed o Cannot tell from the code. ### Dar de baja Cuando verify demuestra que un riesgo está cerrado, el hallazgo se da de baja: se elimina de toda la cadena, con tu confirmación, para que deje de reprocesarse. ### Posibilidad de cierre La propiedad de que el trabajo de seguridad tenga un estado final. Como un hallazgo cuyo cierre se ha demostrado se da de baja, el flujo puede quedar en reposo, y solo se reabre cuando cambia el código. Con SDH, la seguridad se puede cerrar: no es un bucle sin fin. ### Motor El paquete `lagune` en **npm**, que los comandos ejecutan mediante `npx` en cada paso determinista: los hooks, el catálogo y las categorías. ### Especialización Un módulo de conocimiento de seguridad acotado e independiente del lenguaje, que solo se carga bajo demanda, nunca por defecto. Una especialización no es un comando. Carga una en cualquier prompt con `read catalog ` del motor, por ejemplo `npx lagune read catalog regex`. ### Categoría Un grupo con nombre de especializaciones integradas, desde `owasp` hasta las de cada lenguaje, como `javascript`, `python`, `go` y `rust`. Las categorías que usa un proyecto, registradas en `.lagune/configs.json`, deciden qué especializaciones integradas entran en su catálogo. Mientras no haya ninguna registrada, el proyecto usa solo `owasp`. ### Catálogo El conjunto de especializaciones que usa un proyecto: las integradas de sus categorías más las suyas propias, escritas con `/lagune-specialize`. El `read catalog` del motor lo lista, y las fases lo cotejan con el código. ### Prompt bajo demanda El principio según el cual se carga el conocimiento de seguridad relevante para lo que el proyecto es realmente, en lugar de ejecutar todas las comprobaciones por defecto. ### Identidad por nombre El modelo de seguimiento de Lagune: el nombre de cada hallazgo, escrito de forma idéntica como título de sección en todos los artefactos, es su identidad en toda la cadena. El mapa de seguimiento (`.lagune/tracking.json`) solo contiene seguimiento, nunca prosa. ## Preguntas frecuentes ### ¿Qué es Security-Driven Hardening (SDH)? SDH es una metodología de seguridad Blue Team adaptada al contexto. Detecta el contexto de un sistema, hace el triaje de los riesgos que ese contexto conlleva y guía las correcciones, con cada hallazgo expresado en lenguaje sencillo. Lagune es su implementación de referencia. ### ¿Qué es el charter en Lagune? El charter es la capa rectora de Lagune, un conjunto de principios que anteponen la seguridad y que toda fase posterior debe respetar. Se guarda en .lagune/memory/charter.md. ### ¿Qué significa dar de baja un hallazgo? Cuando verify demuestra que un riesgo está cerrado, el hallazgo se da de baja: se elimina de toda la cadena con tu confirmación, para que deje de reprocesarse. --- # Esquema de configuración > El JSON Schema de la configuración de un proyecto Lagune, para autocompletar y validar en tu editor, siguiendo la versión actual de Lagune o fijado a una versión concreta. URL canónica: https://lagune.ai/es-ES/docs/references/configs-schema Idioma: es-ES Original: https://lagune.ai/docs/references/configs-schema Última actualización: 2026-11-03 El archivo `.lagune/configs.json` registra las [**categorías**](https://lagune.ai/es-ES/docs/categories) que usa un proyecto e indexa sus propias [**especializaciones**](https://lagune.ai/es-ES/docs/catalog). Su JSON Schema permite que tu editor autocomplete cada campo y señale una errata o una categoría desconocida mientras editas el archivo. ## El esquema actual Siempre que **Lagune** escribe el archivo y no encuentra ningún `$schema` en él, lo apunta al esquema actual: ```json { "$schema": "https://lagune.ai/schemas/configs.json", "categories": ["owasp", "javascript"] } ``` Esta dirección sigue siempre la versión actual de **Lagune**. Un archivo escrito antes de **Lagune** 0.16.0 la recibe en su próximo cambio, y hasta entonces todas las fases lo advierten. ## Fijar una versión Cada versión de **Lagune** a partir de la 0.16.0 incluye el esquema tal como era en ella, publicado en **npm** y servido por **jsDelivr**. Para fijar una, pon la versión después de `lagune@` en la dirección de `$schema`: ```json { "$schema": "https://cdn.jsdelivr.net/npm/lagune@0.16.0/schemas/configs.json" } ``` La versión admite cualquier rango semver: | Versión | Esquema | | ----------------- | ---------------------------- | | `0.16.0` | El de la 0.16.0 | | `0.16.x` o `0.16` | El de la última versión 0.16 | | `0.x` o `0` | El de la última versión 0.x | | `latest` | El de la última versión | ## Preguntas frecuentes ### ¿Lagune necesita el esquema? No. El esquema solo ayuda a tu editor, y Lagune lee el archivo igual con $schema o sin él. ### ¿Lagune sobrescribirá un esquema fijado? No. Lagune solo escribe $schema cuando el archivo no tiene ninguno, y conserva cualquier dirección que hayas puesto. ### ¿Cuándo debo fijar una versión? Cuando el proyecto usa una versión concreta de Lagune, para que tu editor valide el archivo según lo que acepta esa versión. --- # Lagune vs. Deepsec: dos enfoques de seguridad con IA, frente a frente > Una referencia que compara Lagune y Deepsec, de Vercel, en cómo funcionan, ciclo de vida, detección, coste, hallazgos y cierre. URL canónica: https://lagune.ai/es-ES/docs/references/deepsec Idioma: es-ES Original: https://lagune.ai/docs/references/deepsec Última actualización: 2026-11-03 [Lagune](https://github.com/wellwelwel/lagune) y [Deepsec](https://github.com/vercel-labs/deepsec) (`v2.2.1`) son dos respuestas defensivas al mismo problema: la seguridad en la era del desarrollo asistido por IA. Su premisa, su principio, su desarrollo y su final, y la forma en que cada uno se presenta al usuario difieren por diseño, incluso donde sus mecanismos coinciden. **Consejo** ¿Lagune se inspira en Deepsec? No. Lagune está escrito desde cero y se inspira en Spec-Driven Development y en Security Hardening. Los dos proyectos se desarrollaron de forma independiente, y esta comparación sirve para ayudar a los usuarios a entender sus diferencias. ## De un vistazo | Aspecto | Lagune | Deepsec | | ------------------ | ------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ | | Tipo | Una metodología (SDH) con una implementación de referencia | Un producto: un escáner de vulnerabilidades impulsado por agentes | | Centro de gravedad | Un charter y el conocimiento bajo demanda guían al agente, con hooks deterministas como base | Una amplia red de regex alimenta una investigación obligatoria con IA | | Qué produce | Código bastionado, pruebas y una cadena de hallazgos en seguimiento | Un informe de hallazgos clasificados y ordenados por gravedad | | Toca tu código | Sí: `harden` edita tu código | No: solo análisis estático, emite hallazgos y texto con recomendaciones | | Ejecución | Funciona con el agente y el modelo que ya usas, de cualquier gama | Ejecuta su propio pipeline de modelos, con un modelo puntero por defecto | | Primeros pasos | Una instalación de plugin o `npx skills add`, y luego lo guías en lenguaje sencillo, sin montar ninguna herramienta nueva | Montar un espacio de trabajo `.deepsec/`, instalar las dependencias y añadir una clave de modelo | ## Cómo funciona En Lagune, el agente va primero: lleva el control, carga bajo demanda el conocimiento que corresponde a lo que es el código y delega en los hooks deterministas la parte que estos pueden decidir. En Deepsec, lo determinista va primero: un análisis amplio señala candidatos que indican a un modelo obligatorio qué investigar y juzgar. | Aspecto | Lagune | Deepsec | | ------------------- | --------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------- | | Orden | El charter y el conocimiento que coincide con el código guían al agente, que delega en los hooks y juzga el resto | Los matchers señalan candidatos, y el modelo investiga y juzga cada uno | | Papel determinista | Hooks multilenguaje que devuelven un veredicto u orientan al agente, combinados con el conocimiento de las categorías | Matchers que señalan candidatos para que el modelo obligatorio los juzgue | | Flujo de desarrollo | `/lagune` construye de forma segura sobre la marcha mientras programas | Revisa código, no lo escribe | | Flujo de auditoría | `charter` → `detect` → `plan` → `harden` → `verify` | `scan` → `process` → `triage` → `revalidate` → `report` | | El papel de la IA | Razonar a partir del conocimiento, aplicar la corrección y demostrar que se sostiene | Investigar cada candidato e informar de los hallazgos | ## Ciclo de vida Lagune actúa antes, durante y después de escribir el código. Deepsec revisa un repositorio cuando el código ya existe. | Momento | Lagune | Deepsec | | -------------------------- | ------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------- | | Antes de que exista código | `charter` crea una política de seguridad a partir de la intención declarada | Parte de código existente: `init` necesita un directorio | | Durante el desarrollo | `/lagune` construye de forma segura por defecto sobre la marcha, sin dejar ningún artefacto | Revisa después del desarrollo, no durante | | Sobre código existente | `detect` → `plan` → `harden` → `verify` | `scan` → `process`, el flujo principal | | Revisión continua | Vuelve a ejecutar las fases por ámbito, sin un filtro de CI listo para usar | Nuevo análisis incremental, con `process --diff` como filtro de salida en CI | ## Capa de detección Las dos capas deterministas son de naturaleza opuesta: una decide y la otra señala. | Aspecto | Lagune | Deepsec | | ---------------- | ------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------- | | Agrupación | Hooks y especializaciones, agrupados en categorías | Matchers por patrón o framework | | Salida | Veredicto literal (finding / review / advisory) más una etiqueta de clasificación | Candidato sin veredicto (slug, líneas, fragmento de código, patrón coincidente) | | Ajuste | Precisión: reconoce los comentarios y aplica salvaguardas de marcadores de posición y de ventana | Exhaustividad: redes amplias, y la IA descarta después los falsos positivos | | Profundidad | Más profundo en las clases que ambos cubren | Más amplio, menos profundo en las clases que ambos cubren | | Falsos positivos | Se mantienen bajos en origen y luego se juzgan en contexto | Se generan de más a propósito y se recortan con una pasada de `revalidate` | ## Conocimiento y juicio Ambos aportan conocimiento de seguridad que las regex no alcanzan. Difieren en dónde reside y en quién puede darle forma. | Aspecto | Lagune | Deepsec | | ---------------------- | -------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | | Forma | Módulos markdown editables, varios de ellos respaldados por un hook determinista | Un prompt breve y puntos destacados por tecnología, apoyados en el conocimiento propio del modelo | | Selección | Se coteja con el código y solo se carga cuando su contexto está presente | Se inyecta en cada lote de IA, junto con los puntos destacados de la tecnología detectada | | Quién lo redacta | El usuario edita los módulos y añade otros nuevos con `specialize` | El mantenedor es dueño del prompt, y el usuario rellena un `INFO.md` | | Dónde reside el juicio | Los hooks deciden su base, y el agente juzga el resto a partir del conocimiento | Centralizado: un único procesador de IA juzga cada candidato | | Reutilización | Un mismo módulo guía tanto `detect` como `verify` | Un solo prompt dirige la etapa única de `process` | ## Hallazgos y cierre En lo que más difieren es en qué se convierte un hallazgo una vez resuelto. | Aspecto | Lagune | Deepsec | | --------------------- | ---------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- | | Gravedad | Una puntuación CVSS v4.0, ajustada según la exposición y lo que está en juego | Una gravedad asignada por la IA, más un triaje P0 / P1 / P2 de explotabilidad e impacto | | Veredictos | Risk closed, Risk not closed o Cannot tell from the code | true-positive, false-positive, fixed, uncertain, accepted-risk, duplicate | | Persistencia | La cadena de trabajo se concilia, y los hallazgos cerrados se condensan en un historial | Registros por archivo a los que solo se añade, sin eliminar nada | | Estado final | Se puede cerrar: un hallazgo demostrado se da de baja y la cadena puede quedar en reposo | Cada hallazgo se conserva para siempre, oculto de las vistas una vez resuelto | | Detalle del historial | Un resumen breve de cuál era el riesgo | El rastro completo de veredictos, incluido cómo se corrigió | ## Coste | Aspecto | Lagune | Deepsec | | ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Base determinista | Gratis: los hooks se ejecutan sin IA y sin clave, y ya emiten veredictos | Gratis: `scan` se ejecuta sin IA, pero no emite veredictos por sí solo | | Factura habitual | Integrada en un agente que ya usas: desde 0 dólares con un modelo local, el precio del plan que ya pagas o por iteración si lo usas a través de una API | [Entre unos 25 y 1200 dólares por ejecución para entre 100 y 2000 archivos, y más a gran escala](https://github.com/vercel-labs/deepsec/blob/f75a16803ec5250938bacfe41571d929e8564f45/docs/getting-started.md#run-the-ai-investigation) | | La vía más barata | Cualquier modelo, incluido uno local y gratuito, cierra el ciclo | Hay planes de pago más baratos, pero los hallazgos requieren la etapa de IA de pago | ## Extensibilidad y gobernanza Cada uno abre la capa que el otro mantiene cerrada. | Aspecto | Lagune | Deepsec | | ---------------------- | ----------------------------------------------------- | ---------------------------------------------------------------------- | | Qué puedes ampliar | Editar módulos o añadir otros nuevos con `specialize` | Añadir matchers, agentes, notificadores y asignaciones de responsables | | Capa de políticas | El charter rige cada fase y está versionado | La configuración es operativa (matchers, modelos, rutas) | | Sustitución por nombre | Un módulo refinado prevalece sobre el integrado | Ante una colisión de slug de matcher, gana tu matcher | ## Interfaces Deepsec genera entregables para una organización de seguridad. Lagune muestra una vista en tiempo real para quien lo ejecuta. | Aspecto | Lagune | Deepsec | | ----------------------------- | ----------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- | | Interfaz para personas | Un dashboard local en tiempo real de toda la cadena, en lenguaje sencillo | Archivos de informe, exportación, métricas y comentarios de PR, más un sitio de documentación | | Responsabilidad | Muestra los archivos y las especializaciones que se aplicaron | Propone a quién asignarlo: la persona de guardia, su responsable o el autor del commit | | Prueba reproducible | `prove` escribe tests ejecutables y un aviso de seguridad para su divulgación | Se mantiene estático por diseño y nunca ejecuta el objetivo | | Autodefensa de la herramienta | Bastiona una API local de escritura del dashboard | Bastiona su propia ejecución de IA frente a código no fiable del objetivo | ## Escala y despliegue | Aspecto | Lagune | Deepsec | | ------------------- | ----------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------- | | Instalación | Nueve comandos desde el plugin de tu agente o la CLI de skills, sin generar nada en el proyecto | Un espacio de trabajo `.deepsec/` con su propio paquete y sus dependencias | | Dirección de escala | Se acota a cualquier parte, un contexto, desde un archivo hasta todo el proyecto | Analiza repositorios completos, hasta grandes monorepos | | Distribución | Solo local, y su único servidor escucha en loopback | Reparto opcional entre VM de workers de Vercel Sandbox | ## Experiencia de usuario Cómo recibe cada uno a quien lo ejecuta: qué exige la primera ejecución y cómo lo orienta quien lo maneja. ### Puesta en marcha Lagune funciona a través del agente que ya tienes abierto. Deepsec prepara primero su propio espacio de trabajo y el acceso al modelo. | Aspecto | Lagune | Deepsec | | ---------------------------- | ------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------- | | Primer comando | La instalación del plugin o `npx skills add wellwelwel/lagune`, y luego `/lagune-*` en el agente | `npx deepsec init`, luego `cd .deepsec`, `pnpm install`, `scan`, `process` | | Credenciales para ejecutarlo | Ninguna clave aparte, usa tu agente actual | Una clave de modelo (por ejemplo, AI Gateway, un token OIDC de Vercel de 12 horas o un token de Anthropic) | ### Cómo dirigirlo Ambos admiten indicaciones. Lagune interpreta la forma de la entrada en cada fase. Deepsec acota el conjunto de archivos sobre el que se ejecuta la misma investigación. | Aspecto | Lagune | Deepsec | | ----------------------- | ---------------------------------------------------------------------------------------------- | -------------------------------------------------------- | | Todo el proyecto | Una fase sin entrada analiza todo el ámbito | `scan` y `process` analizan el repositorio | | Una parte | Cualquier fase se acota a los archivos o directorios indicados | `--files`, `--files-from` o `--diff` acotan la ejecución | | Una preocupación | Una fase se acota a una preocupación descrita | El prompt de investigación es fijo | | Una franja de prioridad | `harden` y `verify` se acotan a la gravedad crítica, alta, media o baja | Los hallazgos se etiquetan después de la ejecución | | Un valor concreto | Un hook puntúa directamente un fragmento de código, un patrón o una URL (`--pattern`, `--url`) | La unidad de trabajo es un archivo | ## Preguntas frecuentes ### ¿En qué se diferencia Lagune de Deepsec? Lagune pone al agente primero y actúa antes, durante y después de escribir el código: fija la política antes del código, bastiona sobre la marcha durante el desarrollo, y audita, bastiona y verifica el código ya escrito. Deepsec pone lo determinista primero: un análisis amplio con regex alimenta una investigación obligatoria con un modelo puntero, que revisa el código existente e informa de los hallazgos sin modificarlo. ### ¿Puedo usar alguno de los dos gratis? Todo el flujo de Lagune puede funcionar por 0 dólares con un modelo local gratuito, y sus hooks deterministas emiten veredictos sin nada de IA. El scan de Deepsec es gratuito pero no emite veredictos, así que cualquier hallazgo requiere su etapa de IA de pago. ### ¿Alguno de los dos modifica mi código? Lagune sí: harden aplica las correcciones en tu código. Deepsec no: solo hace análisis estático y emite hallazgos y texto con recomendaciones que una persona o un agente aplica por separado. --- # Fuentes de OWASP > De dónde procede el conocimiento de las especializaciones OWASP integradas, relacionado con sus páginas canónicas de ataques y Cheat Sheets de OWASP. URL canónica: https://lagune.ai/es-ES/docs/references/owasp-sources Idioma: es-ES Original: https://lagune.ai/docs/references/owasp-sources Última actualización: 2026-11-03 Este documento relaciona cada **ataque** (`www-community`) y cada **Cheat Sheet** (`CheatSheetSeries`) de OWASP con una categoría de seguridad, cada uno enlazado a su página pública canónica. Dentro de una categoría, los elementos equivalentes comparten una única línea de la lista: los ataques y las cheat sheets que abordan el mismo riesgo aparecen juntos, separados por comas. Los elementos sin un equivalente directo ocupan su propia línea. - El mérito es de OWASP. Los ataques están en `https://owasp.org/www-community/attacks/` y las cheat sheets en `https://cheatsheetseries.owasp.org/cheatsheets/.html`. --- ## 1. Inyección (genérica) - [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. Inyección SQL y en bases de datos - [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. Inyección de comandos del 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. Inyección LDAP, XPath y 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) y 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. Redirecciones y reenvíos - [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. Control de acceso y autorización - [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. Autenticación y credenciales - [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. Gestión de sesiones - [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. Federación de identidades (OAuth, SAML y 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. Criptografía y seguridad del transporte - [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. Recorrido de directorios y manejo de archivos - [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 protocolo HTTP (cabeceras, caché y 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) (repartido entre browser, transport, http-request y 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. Codificación y suplantación de contenido - [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. Inyección en CSV y hojas de cálculo - [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. Denegación de servicio - [x] [Regular expression Denial of Service (ReDoS)](https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS) (regex) --- ## 20. Seguridad de la memoria y código 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. Código móvil y ejecución de código no fiable - [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. Deserialización - [x] [Deserialization](https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html) (repartido entre python, ruby, php, java y dotnet) --- ## 23. Malware y amenazas del lado del cliente - [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. Registro de eventos, repudio y gestión de errores - [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. Lógica de negocio y abuso de funcionalidades La lógica de negocio y el abuso de funcionalidades no tienen una única superficie en el código que pueda defender una especialización por superficie: la defensa es un diseño propio de cada aplicación, el mismo razonamiento que guía el modelado de amenazas del proyecto. Se ha movido a "Fuera del alcance". --- ## 26. Seguridad de IA, LLM y agentes - [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. Contaminación de prototipos y cross-site leaks - [x] [Prototype Pollution Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Prototype_Pollution_Prevention_Cheat_Sheet.html) (javascript) - [x] [Cross-site leaks (XS-Leaks)](https://cheatsheetseries.owasp.org/cheatsheets/XS_Leaks_Cheat_Sheet.html) (browser) --- ## 28. Frameworks y plataformas de lenguaje - [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 y navegador - [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) (repartido entre access-control y browser) --- ## 30. API y servicios - [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. Nube, contenedores e infraestructura La configuración de contenedores y cargas de trabajo es configuración como código que el desarrollador entrega con la aplicación (`Dockerfile`, Compose, el `securityContext` del Pod), una superficie real que `harden` corrige y `verify` demuestra, así que está dentro del alcance. La administración del clúster (RBAC, etcd, API server, admission, segmentación de red) es terreno del operador y queda fuera del alcance. - [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 de cargas de trabajo y Pods. La administración del clúster queda fuera del alcance) - [x] [Serverless / FaaS Security](https://cheatsheetseries.owasp.org/cheatsheets/Serverless_FaaS_Security_Cheat_Sheet.html) (serverless) --- ## 32. Cadena de suministro y 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. Secretos y configuración La gestión de secretos es operativa: almacenes de secretos, CI/CD, configuración en la nube, rotación. La única faceta a nivel de código (un secreto escrito directamente en el código fuente) es un análisis determinista, no una especialización de riesgo. Se ha movido a "Fuera del alcance". --- ## 34. Procesos, diseño y gobernanza La protección de la privacidad del usuario es una cuestión de políticas y de diseño (minimización de datos, transparencia, conservación), no una superficie en el código que defienda una especialización. Se ha movido a "Fuera del alcance". --- ## 35. Pagos y cumplimiento normativo - [x] [Secure Integration of Third-Party Payment Gateways](https://cheatsheetseries.owasp.org/cheatsheets/Third_Party_Payment_Gateway_Integration_Cheat_Sheet.html) (payment) --- ## 36. Sistemas embebidos, IoT y ámbitos especializados La seguridad de automoción y la de drones son ámbitos de sistemas embebidos (bus CAN, firmware OTA, integridad de sensores y radio, acceso físico), no el código fuente de aplicaciones web o de API que audita Lagune. Se ha movido a "Fuera del alcance". --- ## Fuera del alcance (sin superficie en el código) Estos elementos no son terreno de especializaciones y no llevan casilla: son gobernanza, procesos, bastionado operativo o uso de frameworks, sin una única superficie en el código que pueda defender una especialización por superficie. Su valor para la seguridad es real, pero reside en los procesos y la arquitectura (o, en el caso de un framework, en la skill de su propio lenguaje), no en una defensa que incluya este catálogo. Se enumeran como referencia, no como trabajo pendiente. - [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) (amplificación mediante SOAP y WS-Addressing, una variante operativa de DoS sin superficie en el código) - [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 que afecta al usuario final, no una superficie en el código del proyecto auditado. La faceta de distribución a través del navegador está en `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) (diseño y compromisos: IAM frente a URL firmadas, VPC públicas y privadas, fronteras de confianza, responsabilidad compartida. A diferencia de `container`, no tiene una configuración concreta que compruebe una especialización) - [Infrastructure as Code Security](https://cheatsheetseries.owasp.org/cheatsheets/Infrastructure_as_Code_Security_Cheat_Sheet.html) (pese a su nombre, trata del proceso del SDLC y de las herramientas para _gestionar_ IaC: plugins de IDE, análisis estático, análisis de imágenes, CI/CD, firma. No ofrece ningún paso de patrón inseguro a forma segura dentro de un archivo de Terraform o CloudFormation) - [Kubernetes Security](https://cheatsheetseries.owasp.org/cheatsheets/Kubernetes_Security_Cheat_Sheet.html) (_solo la parte de administración del clúster_: RBAC, etcd, API server, admission. La parte de cargas de trabajo y Pods está dentro del alcance en `container`) - [Network Segmentation](https://cheatsheetseries.owasp.org/cheatsheets/Network_Segmentation_Cheat_Sheet.html) (arquitectura de red y política de cortafuegos) - [Subdomain Takeover Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Subdomain_Takeover_Prevention_Cheat_Sheet.html) (ciclo de vida y monitorización del DNS, no código) - [Secrets Management](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html) (almacenes de secretos, CI/CD, rotación. La faceta del secreto escrito en el código es un análisis determinista, no una especialización de riesgo) - [C-Based Toolchain Hardening](https://cheatsheetseries.owasp.org/cheatsheets/C-Based_Toolchain_Hardening_Cheat_Sheet.html) (opciones del compilador, del enlazador y de compilación, sin ningún sink en el código fuente) - [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) (configuración global del gestor de errores en cada stack. La fuga es la misma exposición de información que ya regula la gestión de errores) - [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 _(histórico)_](https://cheatsheetseries.owasp.org/cheatsheets/Abuse_Case_Cheat_Sheet.html) (diseño propio de cada aplicación, sin un único sink en el código) - [User Privacy Protection](https://cheatsheetseries.owasp.org/cheatsheets/User_Privacy_Protection_Cheat_Sheet.html) (minimización de datos, transparencia, política de conservación) - [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) (ámbitos de sistemas embebidos: bus CAN, firmware OTA, integridad de sensores y radio, no código fuente web o de API) - [Mobile Application Security](https://cheatsheetseries.owasp.org/cheatsheets/Mobile_Application_Security_Cheat_Sheet.html) (bastionado de las plataformas Android e iOS: almacenamiento, biometría, pinning, PII. No tiene una única superficie en el código, y la faceta de carga de código no fiable pasó a `interpreter`) - [Threat Modeling](https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html), [Threat Modeling _(página de la comunidad)_](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: repara el seguimiento roto de los hallazgos > Repara la cadena cuando un cambio de nombre o un archivo movido confunde el seguimiento de Lagune. URL canónica: https://lagune.ai/es-ES/docs/commands/repair Idioma: es-ES Original: https://lagune.ai/docs/commands/repair Última actualización: 2026-11-03 🧰 Repara la cadena cuando un cambio de nombre o un archivo movido la confunde. **Mantenimiento interno, no una fase de seguridad** Repair no es una sexta fase del flujo lineal. Su trabajo es mantener coherente el seguimiento. ```prompt # No recibe ninguna entrada: siempre repara toda la cadena /lagune-repair ``` ## Cómo funciona Cada hallazgo de detect es un elemento en seguimiento que plan, harden y verify van pasándose de una fase a otra, y cada una actúa sobre él y vuelve a informar de él por su nombre. Ese nombre, escrito igual como título de sección en todos los artefactos, es su identidad de principio a fin. Lo único volátil que guarda el seguimiento son las rutas de los archivos a los que apunta el elemento. Esas rutas no están en ningún otro sitio, así que un cambio de nombre o un archivo movido solo puede romper el vínculo ahí, nunca en dos copias que divergen. Cuando ocurre, repair corrige el mapa (`.lagune/tracking.json`) para que la identidad sobreviva al cambio de nombre. Lee los artefactos y el mapa de seguimiento, lee tu código fuente solo para conocer la nueva ruta de un archivo renombrado, y nunca redacta contenido de seguridad. En la misma pasada, compara cada artefacto de memoria con su plantilla e informa de lo que se ha desviado, indicando en cada caso la fase que lo corrige. **Consejo** - No toca ni tu código ni el texto de los artefactos, solo el seguimiento. - Rara vez lo ejecutarás a mano. Cuando una fase detecta que la cadena es incoherente, ejecuta repair por ti y continúa. - El seguimiento que mantiene está en `.lagune/tracking.json`, un estado interno que nunca editas a mano. --- # Migrate: lleva un proyecto de Lagune basado en manifiesto a las skills y los plugins > Migra un proyecto de Lagune basado en manifiesto a la versión de Lagune basada en skills, conservando tu charter, tus artefactos, el seguimiento y tus propias especializaciones. URL canónica: https://lagune.ai/es-ES/docs/commands/migrate Idioma: es-ES Original: https://lagune.ai/docs/commands/migrate Última actualización: 2026-11-03 🔀 Lleva un proyecto de **Lagune** basado en manifiesto a la versión de **Lagune** basada en skills, sin perder nada de lo que has escrito. **Aviso de obsolescencia** Un proyecto con manifiesto sigue funcionando tal cual hasta `v1.x`: `npx lagune` delega `init`, `pull`, `update`, `add`, `remove`, `list` y el dashboard en `lagune@0.15.0`, la última versión basada en manifiesto. ## Cómo migrarlo 1. Asegúrate de que tu trabajo actual está en un commit y después ejecuta migrate desde la raíz del proyecto: ```bash npx lagune migrate ``` 2. Haz un commit aparte con lo que ha cambiado, para que la migración quede como un único cambio revisable. 3. Instala los comandos para tu agente, como indica la [página de instalación](https://lagune.ai/es-ES/docs). 4. Si el proyecto ya tiene un artefacto de detect, plan o harden, pide a [`/lagune-repair`](https://lagune.ai/es-ES/docs/commands/repair) que concilie las referencias antiguas que hay en ellos y en tus propias especializaciones: ```prompt /lagune-repair Concilia las especializaciones aplicadas (antes llamadas sub-skills) de los artefactos de `.lagune/memory/` (`detect.md`, `plan.md` y `harden.md`) con los nombres que lista el nuevo catálogo, y reescribe cada llamada que mis propias especializaciones de `.lagune/catalog/` hacen a los hooks antiguos de `.lagune/hooks/` como una llamada a la herramienta `lagune_read` o `lagune_write`. ``` ## Qué cambia | Antes | Después | | --------------------------------------------------------------------- | ------------------------------------------------------------------------------- | | `.lagune/templates/`, `.lagune/hooks/` y `.lagune/specializations.md` | Eliminados: cada skill lleva su plantilla y el motor ejecuta los hooks | | Las copias de las especializaciones integradas en `.lagune/skills/` | Eliminadas: el motor sirve las integradas | | Tus propias especializaciones en `.lagune/skills/` | Movidas a `.lagune/catalog/` | | `.lagune/skills.json`, el índice de tus propias especializaciones | Fusionado en `.lagune/configs.json` | | Las categorías del manifiesto | Registradas en `.lagune/configs.json` | | Los comandos antiguos del agente, como `/lagune.detect` | Eliminados: [instalar **Lagune**](https://lagune.ai/es-ES/docs) trae los nuevos, como `/lagune-detect` | | El bloque de **Lagune** en `.gitignore` | Eliminado, junto con el archivo cuando no contenía nada más | | `.lagune/proofs/`, que ignoraba ese bloque | Queda fuera de los commits gracias a su propio `.gitignore` | | `.lagune/manifest.json` | Eliminado, en último lugar | Tu trabajo de seguridad se queda como está: el charter, el artefacto que generó cada fase y el mapa de seguimiento con las rutas a las que apunta cada hallazgo. ## Preguntas frecuentes ### ¿Tengo que migrar? Sí. Los proyectos basados en manifiesto están obsoletos y solo siguen funcionando hasta v1.x, así que ejecuta npx lagune migrate para migrar el tuyo. ### ¿Qué conserva migrate? Tu charter, todos los artefactos de las fases, el mapa de seguimiento, tus categorías y tus propias especializaciones. Las especializaciones pasan a .lagune/catalog/, y su índice se une a tus categorías en .lagune/configs.json. ### ¿Cuándo instalo los comandos nuevos? Después de migrate, como indica la página de instalación para tu agente. Instalar primero también funciona, porque migrate conserva el nuevo /lagune. ### Un compañero ya ha migrado. ¿Qué ejecuto? Haz pull de la migración y después ejecuta npx lagune migrate una vez. Elimina lo que la versión de Lagune basada en manifiesto dejó en tu copia local y que el control de versiones nunca llegó a incluir, y mantiene tus pruebas fuera de los commits.