# Lagune > Security-Driven Hardening para qualquer código O Lagune é um fluxo de Security-Driven Hardening (SDH) open source e exclusivamente defensivo. Ele ajuda seu agente de IA a fortalecer a segurança de qualquer código, em qualquer linguagem e em qualquer momento: o charter define as regras de segurança antes de você construir, o comando universal /lagune aplica hardening ao trabalho enquanto ele é escrito, e o fluxo Blue Team de cinco fases detecta o que o seu sistema realmente faz e conduz as correções que importam para esse contexto. Seus comandos são instalados no seu agente com o skills CLI, e ele não precisa de chave de API. --- # Instalação: hardening de segurança para qualquer agente de IA > Instale o Lagune em qualquer projeto, como plugin quando o seu agente oferece suporte ou com o skills CLI nos demais, e escolha as especializações de segurança que combinam com ele. Canônica: https://lagune.ai/pt-BR/docs Idioma: pt-BR Original: https://lagune.ai/docs Última atualização: 2026-11-03 O **Lagune** ajuda seu agente de IA a deixar um projeto mais seguro. Você aponta para o seu código, o agente descobre o que o seu sistema realmente faz e então guia você pelo trabalho de segurança que importa para ele. O **Lagune** é o primeiro projeto da metodologia [Security-Driven Hardening (SDH)](https://lagune.ai/pt-BR/docs/references/paper). **Apoie o open source** Curtiu o **Lagune**? [Dê uma ⭐ no **GitHub**](https://github.com/wellwelwel/lagune) ## Escolha o seu agente - [Claude Code](https://lagune.ai/pt-BR/docs/install/claude-code): A ferramenta de programação agêntica da Anthropic - [Codex](https://lagune.ai/pt-BR/docs/install/codex): O agente de programação da OpenAI - [Cursor](https://lagune.ai/pt-BR/docs/install/cursor): O editor de código com IA - [GitHub Copilot](https://lagune.ai/pt-BR/docs/install/github-copilot-cli): O programador parceiro com IA do GitHub - [Gemini CLI](https://lagune.ai/pt-BR/docs/install/gemini-cli): O agente de terminal open source do Google - [Antigravity](https://lagune.ai/pt-BR/docs/install/antigravity-cli): A plataforma de desenvolvimento agêntico do Google - [OpenCode](https://lagune.ai/pt-BR/docs/install/opencode): O agente de programação open source - [Devin for Terminal](https://lagune.ai/pt-BR/docs/install/devin-cli): O agente de terminal da Cognition - [Factory Droid](https://lagune.ai/pt-BR/docs/install/factory-droid): O agente de desenvolvimento de software da Factory - [Grok Build](https://lagune.ai/pt-BR/docs/install/grok-build): O agente de programação da xAI - [Qwen Code](https://lagune.ai/pt-BR/docs/install/qwen-code): O agente de programação para terminal do Qwen - [Kimi Code](https://lagune.ai/pt-BR/docs/install/kimi-code): O agente de programação da Moonshot AI - [Muse Code](https://lagune.ai/pt-BR/docs/install/muse-code): O agente de programação da Meta - [Pi](https://lagune.ai/pt-BR/docs/install/pi): Um agente de programação minimalista para o terminal - [Hermes Agent](https://lagune.ai/pt-BR/docs/install/hermes-agent): O agente open source da Nous Research - [Universal](https://lagune.ai/pt-BR/docs/install/universal): Cline, Kiro CLI, Windsurf, Zed e mais 66 **Informação** - Por baixo dos panos, o **Lagune** roda em **Node.js**, mas você usa a linguagem que quiser. - Para rodar totalmente offline, instale o **Lagune** no seu projeto com `npm i -D lagune@0.16.0`. ## Categorias O conhecimento de segurança do **Lagune** vem em [**especializações**](https://lagune.ai/pt-BR/docs/catalog), agrupadas em [**categorias**](https://lagune.ai/pt-BR/docs/categories). - **OWASP** (`owasp`): Protege contra os riscos de segurança de aplicações que a OWASP acompanha: injection, controle de acesso quebrado, falhas de autenticação e de criptografia - **Infraestrutura** (`infra`): Protege a configuração de contêineres, workloads e serverless: Dockerfile, Compose, segurança de Pods, IAM e triggers de FaaS - **IA / LLM** (`ai`): Protege integrações de IA e LLM contra prompt injection e conexões inseguras de ferramentas, agentes, retrieval e MCP - **Lovable** (`lovable`): Protege apps Supabase gerados por IA (Lovable e similares): falhas de RLS, chaves service_role vazadas e padrões inseguros - **JavaScript** (`javascript`): Protege JavaScript e seus runtimes contra RCE por eval e child_process, path traversal e prototype pollution - **Python** (`python`): Protege Python contra RCE por desserialização de pickle e YAML, travessia de strings com str.format e class pollution - **Rust** (`rust`): Protege Rust contra APIs unsafe incorretas, mau uso de transmute, integer overflow e comportamento indefinido na fronteira de FFI - **Java** (`java`): Protege Java contra gadget chains de desserialização com ObjectInputStream que culminam em execução remota de código - **Ruby** (`ruby`): Protege Ruby contra gadget chains de desserialização com Marshal.load e YAML que chegam à execução remota de código - **PHP** (`php`): Protege PHP contra bypass de autenticação por type juggling, gadget chains de object injection e padrões de configuração inseguros - **Go** (`go`): Protege Go contra bugs de interface com nil tipado, data races entre goroutines e concorrência insegura em caminhos de segurança - **C / C++** (`c-cpp`): Protege C e C++ contra bugs de format string, buffer overflows e escritas fora dos limites que permitem execução de código - **.NET** (`dotnet`): Protege .NET e C# contra RCE por desserialização com BinaryFormatter e contra os bypasses de encoder que levam a XSS Execute `npx lagune write add --categories` com as chaves das categorias que você escolher. **Dica** Todo projeto começa com `owasp`, e o [`/lagune-charter`](https://lagune.ai/pt-BR/docs/commands/charter) adiciona as categorias que a leitura dele sobre o projeto justifica. ## Requisitos Você precisa ter o [**Node.js (LTS)**](https://nodejs.org/en/download/package-manager) instalado no seu sistema. ## Use um badge ✨ Usa o **Lagune**? Adicione um ao seu **README**: **Dois tons** ![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) ``` **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) ``` ## Próximo passo Veja o que cada uma das [**Skills**](https://lagune.ai/pt-BR/docs/get-started/commands) do **Lagune** faz. ## Perguntas frequentes ### O que é o Lagune? O Lagune é um fluxo de segurança open source, exclusivamente defensivo, que ajuda seu agente de IA a fortalecer a segurança de qualquer código. Você aponta para o seu código, ele detecta o que o seu sistema realmente faz e então orienta as correções de segurança que importam para esse contexto. ### Como instalar o Lagune? Escolha o seu agente: Claude Code, GitHub Copilot CLI, Muse Code, Antigravity CLI, Cursor, Kimi Code, OpenCode, Codex CLI, Factory Droid, Grok Build, Devin CLI e Hermes Agent instalam o Lagune como plugin, Gemini CLI e Qwen Code como extensão, o Pi como pacote e qualquer outro agente com npx skills add wellwelwel/lagune. Funciona tanto em projetos novos quanto em existentes. ### O Lagune precisa de chave de API? Não. Ele roda pelo seu próprio agente de IA, então nenhuma chave de API é necessária. ### Quais são os requisitos? Você precisa ter o Node.js (LTS) instalado no seu sistema. ### Quais linguagens de programação o Lagune suporta? Qualquer uma. Por baixo dos panos, o Lagune roda em Node.js, mas audita e fortalece a segurança de projetos escritos em qualquer linguagem de programação. ### O que o Lagune adiciona ao meu projeto? Um diretório .lagune/ com o estado de segurança do seu projeto, criado pelo primeiro comando que grava algo. O skills CLI também instala os slash commands no projeto, onde o seu agente os lê, enquanto um plugin os mantém dentro do agente. ### Como atualizar o Lagune? Do mesmo jeito que você instalou. A página de instalação de cada agente mostra como atualizar o Lagune nele, e o skills CLI o atualiza com npx skills update. Seu charter, os artefatos das fases e as suas próprias especializações continuam intactos. ### Quais especializações um projeto usa? As nativas das categorias dele, mais as suas próprias. O charter registra as categorias que a leitura dele sobre o projeto justifica, e npx lagune write add --categories as altera. ### Preciso terminar de desenvolver antes de proteger o meu projeto? Não. O comando /lagune aplica hardening ao trabalho enquanto ele é escrito: aceita qualquer prompt, constrói o que você pediu e o protege com padrões seguros, guiado pelo charter. O fluxo Blue Team de cinco fases audita o que já existe. ### O Lagune consegue auditar um projeto que já existe? Sim. O fluxo Blue Team de cinco fases audita o que já existe: o charter define suas regras de segurança, o detect mapeia o que o sistema faz e onde estão os riscos, o plan dá uma nota a cada achado e associa uma correção a ele, o harden aplica as correções e o verify comprova que elas se sustentam e as encerra. ### Qual é a diferença entre usar o Lagune e simplesmente pedir ao agente para mapear vulnerabilidades e falhas de segurança? Um agente lendo por conta própria encontra o que parece uma vulnerabilidade e ignora o que parece um controle. Uma lista de endereços bloqueados dá a impressão de que alguém já tratou o risco, então ninguém confere que ela deixa a maioria deles de fora, e o código vai para produção. O Lagune inverte esse padrão: uma proteção que já está no código é considerada não comprovada até ser verificada, cada especialização do catálogo recebe um veredito explícito, e o verify pergunta se o risco acabou, não se existe um controle. Cada achado também continua sendo um único item rastreado entre as execuções, então pode ser comprovado como resolvido e encerrado, enquanto um pedido simples entrega um relatório diferente a cada vez, sem nada para comparar. ### Qual é a diferença entre desenvolver com o Lagune e simplesmente pedir ao agente para escrever código seguro? Pedir código seguro deixa a definição de seguro por conta do agente e pressupõe que você sabe o que pedir. O requisito geralmente já está dentro do seu pedido sem que nenhum de vocês perceba: pedir uma página que mostra os cursos a que um usuário tem acesso estabelece uma regra de autorização, e uma verificação que nunca é escrita não deixa nada no código para ser notado. O comando /lagune carrega o seu charter e as especializações que combinam com o que está prestes a ser construído antes de a primeira linha ser escrita, e depois relê o resultado à luz da defesa que usou. A forma segura raramente custa mais do que a insegura, então o que decide o resultado é saber qual escolher, e é isso que chega de antemão. ### O Lagune faz DAST (Dynamic Application Security Testing) ou testa a minha aplicação em execução? Não. O Lagune lê código e nunca executa o seu sistema nem envia requisições manipuladas a ele. O verify confirma que um controle está presente e correto no código-fonte, o que é uma pergunta diferente de saber se ele resiste a um ataque contra um alvo em produção, então "não dá para saber pelo código" é um veredito legítimo, e não uma aprovação silenciosa. O DAST responde à pergunta sobre a execução e o Lagune responde à pergunta sobre o código-fonte, então um não substitui o outro. Até o comando opcional prove respeita esse limite: os testes dele verificam o comportamento seguro, nunca um payload de ataque. ### O Lagune substitui um pentest (teste de intrusão)? Não, de jeito nenhum! Um pentest é um trabalho autorizado em que um profissional usa o próprio julgamento contra o seu sistema em produção, encadeando achados e sondando a lógica de negócio que nenhuma regra por superfície descreve. Os achados de um pentest podem entrar no fluxo Blue Team do Lagune, para que o detect registre essas questões e o que um profissional relata seja planejado, fortalecido e verificado. ## Política de segurança Consulte o [SECURITY.md](https://github.com/wellwelwel/lagune/blob/main/SECURITY.md). ## Licença O **Lagune** é distribuído sob a [Apache License 2.0](https://github.com/wellwelwel/lagune/blob/main/LICENSE). Copyright © 2026-presente [Weslley Araújo](https://github.com/wellwelwel) e [colaboradores](https://github.com/wellwelwel/lagune/graphs/contributors). --- # Como instalar o Lagune no Antigravity CLI como plugin > Instale o Lagune no Antigravity CLI como plugin, mantenha-o atualizado e libere o engine dele de antemão. Canônica: https://lagune.ai/pt-BR/docs/install/antigravity-cli Idioma: pt-BR Original: https://lagune.ai/docs/install/antigravity-cli Última atualização: 2026-11-03 Instale o plugin pelo terminal: ```bash agy plugin install https://github.com/wellwelwel/lagune/tree/plugin-antigravity ``` ## Atualização Para atualizar o **Lagune**, instale-o de novo: ```bash agy plugin install https://github.com/wellwelwel/lagune/tree/plugin-antigravity ``` ## Comandos Digite os comandos com o nome do plugin na frente, como `/lagune:lagune-charter` para `/lagune-charter`. --- **Permissões** O engine roda por meio de duas ferramentas: `lagune_read` só lê o seu projeto, e `lagune_write` só grava em `.lagune/`. Um comando enviado como primeira mensagem de uma sessão roda antes de elas carregarem, então usa o **npx** no lugar delas. Para liberar as ferramentas e o **npx** de antemão, adicione estas regras 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.]+)" ] } } ``` ## Perguntas frequentes ### Como instalar o Lagune no Antigravity CLI? Execute agy plugin install https://github.com/wellwelwel/lagune/tree/plugin-antigravity. ### Como atualizar o Lagune no Antigravity CLI? Execute agy plugin install https://github.com/wellwelwel/lagune/tree/plugin-antigravity de novo. ### Como executar os comandos do Lagune no Antigravity CLI? Digite-os com o nome do plugin na frente, como /lagune:lagune-charter. ### O Antigravity CLI pode rodar o Lagune sem pedir permissão? Sim. Libere mcp(lagune_lagune/lagune_read), mcp(lagune_lagune/lagune_write) e command(regex:npx --yes lagune@[0-9.]+) nas configurações do Antigravity CLI. A regra do npx cobre um comando enviado como primeira mensagem de uma sessão. --- # Como instalar o Lagune no Claude Code como plugin > Instale o Lagune no Claude Code como plugin, no terminal, na extensão ou no app desktop, mantenha-o atualizado e libere o engine dele de antemão. Canônica: https://lagune.ai/pt-BR/docs/install/claude-code Idioma: pt-BR Original: https://lagune.ai/docs/install/claude-code Última atualização: 2026-11-03 **Terminal** Instale o plugin pelo terminal: ```bash claude plugin install lagune --marketplace wellwelwel/lagune ``` Ou em uma sessão do **Claude Code**: ```text /plugin marketplace add wellwelwel/lagune /plugin install lagune@lagune ``` **Extensão** - Digite `/plugin` e selecione **Manage plugins**. - Adicione `wellwelwel/lagune` na aba **Marketplaces**. - Instale `lagune` na aba **Plugins**. **Desktop** - Instale o **Lagune** pelo terminal ou pela extensão, escolhendo **Install for you** na extensão. - Inicie uma nova sessão no app desktop, que carrega os plugins que você instala para si mesmo. ## Atualização **Terminal** Para atualizar o **Lagune**, execute: ```bash claude plugin marketplace update lagune claude plugin update lagune@lagune ``` Para mantê-lo atualizado, selecione **Enable auto-update** para o marketplace `lagune` em `/plugin`. **Extensão** - Digite `/plugin` e selecione **Manage plugins**. - Abra a aba **Marketplaces**. - Selecione o ícone de atualizar em `lagune`. **Desktop** - Atualize o **Lagune** pelo terminal ou pela extensão. - Inicie uma nova sessão no app desktop. ## Comandos Digite os comandos pelo nome, como `/lagune-charter`, ou com o nome do plugin na frente, como `/lagune:lagune-charter`. --- **Permissões** O engine roda por meio de duas ferramentas: `lagune_read` só lê o seu projeto, e `lagune_write` só grava em `.lagune/`. Para liberá-las de antemão, adicione estas regras a `.claude/settings.json` para um projeto, ou a `~/.claude/settings.json` para todos eles: ```json { "permissions": { "allow": [ "mcp__plugin_lagune_lagune__lagune_read", "mcp__plugin_lagune_lagune__lagune_write" ] } } ``` Quando o engine roda pelo **npx**, como acontece com o **skills.sh**, libere `Bash(npx --yes lagune@*)`. Com o sandbox ativado, adicione também `registry.npmjs.org` a `sandbox.network.allowedDomains`. ## Perguntas frequentes ### Como instalar o Lagune no Claude Code? Execute claude plugin install lagune --marketplace wellwelwel/lagune. Em uma sessão ou na extensão, adicione o marketplace wellwelwel/lagune pelo gerenciador de plugins e instale lagune. O app desktop o carrega assim que você o instala para si mesmo no terminal ou na extensão. ### Como atualizar o Lagune no Claude Code? Execute claude plugin marketplace update lagune e depois claude plugin update lagune@lagune, ou selecione Enable auto-update para o marketplace lagune em /plugin. Na extensão, abra Manage plugins em /plugin e selecione o ícone de atualizar no marketplace lagune. O app desktop carrega a atualização na próxima sessão. ### Como executar os comandos do Lagune no Claude Code? Digite-os pelo nome, como /lagune-charter, ou com o nome do plugin na frente, como /lagune:lagune-charter. ### O Claude Code pode rodar o Lagune sem pedir permissão? Sim. Libere mcp__plugin_lagune_lagune__lagune_read e mcp__plugin_lagune_lagune__lagune_write nas configurações do Claude Code, além de Bash(npx --yes lagune@*) quando o engine roda pelo npx. --- # Como instalar o Lagune no Codex CLI como plugin > Instale o Lagune no Codex CLI como plugin, mantenha-o atualizado e rode o engine dele dentro do sandbox. Canônica: https://lagune.ai/pt-BR/docs/install/codex Idioma: pt-BR Original: https://lagune.ai/docs/install/codex Última atualização: 2026-11-03 Instale o plugin pelo terminal: ```bash codex plugin marketplace add wellwelwel/lagune codex plugin add lagune@lagune ``` ## Atualização Para atualizar o **Lagune**, execute: ```bash codex plugin marketplace upgrade lagune ``` ## Comandos Digite `$` e o comando com o nome do plugin na frente, seguido do seu pedido, como `$lagune:lagune-charter` para `/lagune-charter`. Ao digitar `$`, os comandos aparecem em uma lista, e escolher um insere o nome completo dele. --- **Permissões** O sandbox do **Codex** não tem acesso à rede. Instale o engine no seu projeto pelo seu próprio terminal, uma vez e de novo após cada atualização: ```bash npm i -D lagune@0.16.0 ``` ## Perguntas frequentes ### Como instalar o Lagune no Codex CLI? Execute codex plugin marketplace add wellwelwel/lagune e depois codex plugin add lagune@lagune. ### Como atualizar o Lagune no Codex CLI? Execute codex plugin marketplace upgrade lagune. ### Como executar os comandos do Lagune no Codex CLI? Digite $ e o comando com o nome do plugin na frente, seguido do seu pedido, como $lagune:lagune-charter. ### O Lagune funciona dentro do sandbox do Codex? Sim, depois que você instala o engine no seu projeto com npm i -D lagune@0.16.0 pelo seu próprio terminal, uma vez e de novo após cada atualização. --- # Como instalar o Lagune no Cursor como plugin > Instale o Lagune no Cursor e no Cursor CLI como plugin, mantenha-o atualizado e libere o engine dele de antemão. Canônica: https://lagune.ai/pt-BR/docs/install/cursor Idioma: pt-BR Original: https://lagune.ai/docs/install/cursor Última atualização: 2026-11-03 **Cursor** - Abra **Customize**. - Selecione **From GitHub Repository** e informe `https://github.com/wellwelwel/lagune`. - Selecione **Install** no **Lagune** e escolha o escopo de projeto ou de usuário. **Cursor CLI** - Adicione o marketplace pelo terminal: ```bash agent plugin marketplace add https://github.com/wellwelwel/lagune --git-ref plugin-cursor ``` - Digite `/plugins` em uma sessão do `agent`. - Instale o **Lagune**. Se o **Lagune** já estiver instalado no **Claude Code**, o **Cursor CLI** o carrega de lá. ## Atualização **Cursor** - Abra **Customize**. - Selecione **Refresh** no marketplace `lagune`. **Cursor CLI** - Substitua o marketplace pelo terminal: ```bash agent plugin marketplace remove lagune agent plugin marketplace add https://github.com/wellwelwel/lagune --git-ref plugin-cursor ``` - Digite `/plugins` em uma sessão do `agent`. - Instale o **Lagune** de novo. ## Comandos Digite os comandos pelo nome, como `/lagune-charter`. --- **Permissões** No **Cursor**, os comandos rodam o engine pelo **npx**, que o modo padrão Auto-review libera sem perguntar. No **Cursor CLI**, o engine roda por meio de duas ferramentas: `lagune_read` só lê o seu projeto, e `lagune_write` só grava em `.lagune/`. Para liberá-las de antemão, adicione estas regras a `.cursor/cli.json` para um projeto, ou a `~/.cursor/cli-config.json` para todos eles: ```json { "permissions": { "allow": [ "Mcp(plugin-lagune-lagune:lagune_read)", "Mcp(plugin-lagune-lagune:lagune_write)" ] } } ``` Quando o engine roda pelo **npx**, como acontece com o **skills.sh**, libere `Shell(npx:--yes lagune@*)`. ## Perguntas frequentes ### Como instalar o Lagune no Cursor? No Cursor, abra Customize, selecione From GitHub Repository, informe https://github.com/wellwelwel/lagune e instale o Lagune. No Cursor CLI, execute agent plugin marketplace add https://github.com/wellwelwel/lagune --git-ref plugin-cursor e depois instale o Lagune por /plugins. ### Como atualizar o Lagune no Cursor? No Cursor, selecione Refresh no marketplace lagune em Customize. No Cursor CLI, remova o marketplace lagune, adicione-o de novo e depois instale o Lagune de novo por /plugins. ### Como executar os comandos do Lagune no Cursor? Digite-os pelo nome, como /lagune-charter. ### O Cursor pode rodar o Lagune sem pedir permissão? Sim. O modo padrão Auto-review do Cursor já o libera. No Cursor CLI, libere Mcp(plugin-lagune-lagune:lagune_read) e Mcp(plugin-lagune-lagune:lagune_write), além de Shell(npx:--yes lagune@*) quando o engine roda pelo npx. --- # Como instalar o Lagune no Devin CLI como plugin > Instale o Lagune no Devin CLI como plugin e mantenha-o atualizado. Canônica: https://lagune.ai/pt-BR/docs/install/devin-cli Idioma: pt-BR Original: https://lagune.ai/docs/install/devin-cli Última atualização: 2026-11-03 Faça login no **Devin** e depois instale o plugin pelo terminal: ```bash devin auth login devin plugins install wellwelwel/lagune ``` ## Atualização Para atualizar o **Lagune**, execute: ```bash devin plugins update lagune ``` ## Comandos Digite os comandos com o nome do plugin na frente, como `/lagune:lagune-charter` para `/lagune-charter`. O menu `/` também os lista. ## Perguntas frequentes ### Como instalar o Lagune no Devin CLI? Faça login com devin auth login e depois execute devin plugins install wellwelwel/lagune. ### Como atualizar o Lagune no Devin CLI? Execute devin plugins update lagune. ### Como executar os comandos do Lagune no Devin CLI? Digite-os com o nome do plugin na frente, como /lagune:lagune-charter. O menu / também os lista. --- # Como instalar o Lagune no Factory Droid como plugin > Instale o Lagune no Factory Droid como plugin, mantenha-o atualizado e libere as ferramentas do engine dele. Canônica: https://lagune.ai/pt-BR/docs/install/factory-droid Idioma: pt-BR Original: https://lagune.ai/docs/install/factory-droid Última atualização: 2026-11-03 Instale o plugin pelo terminal: ```bash droid plugin marketplace add wellwelwel/lagune droid plugin install lagune@lagune ``` ## Atualização Para atualizar o **Lagune**, execute: ```bash droid plugin marketplace update lagune droid plugin update lagune@lagune ``` ## Comandos Digite os comandos pelo nome, como `/lagune-charter`. --- **Permissões** O engine roda por meio de duas ferramentas: `lagune_read` só lê o seu projeto, e `lagune_write` só grava em `.lagune/`. Quando o **Factory Droid** perguntar, escolha sempre liberar cada uma delas. Ele pergunta de novo depois de sincronizar um novo commit do marketplace `lagune`, o que pode acontecer quando ele inicia. ## Perguntas frequentes ### Como instalar o Lagune no Factory Droid? Execute droid plugin marketplace add wellwelwel/lagune e depois droid plugin install lagune@lagune. ### Como atualizar o Lagune no Factory Droid? Execute droid plugin marketplace update lagune e depois droid plugin update lagune@lagune. ### Como executar os comandos do Lagune no Factory Droid? Digite-os pelo nome, como /lagune-charter. ### O Factory Droid pode rodar o Lagune sem pedir permissão? Sim. Escolha sempre liberar lagune_read e lagune_write quando o Factory Droid perguntar. Ele pergunta de novo depois de sincronizar um novo commit do marketplace lagune. --- # Como instalar o Lagune no Gemini CLI como extensão > Instale o Lagune no Gemini CLI como extensão, mantenha-o atualizado e libere o engine dele de antemão. Canônica: https://lagune.ai/pt-BR/docs/install/gemini-cli Idioma: pt-BR Original: https://lagune.ai/docs/install/gemini-cli Última atualização: 2026-11-03 Instale a extensão pelo terminal: ```bash gemini extensions install https://github.com/wellwelwel/lagune ``` ## Atualização Para atualizar o **Lagune**, execute: ```bash gemini extensions update lagune ``` Para mantê-lo atualizado, instale-o com `--auto-update`. ## Comandos Digite os comandos com o nome da extensão na frente, como `/lagune:lagune-charter` para `/lagune-charter`. --- **Permissões** O engine roda por meio de duas ferramentas: `lagune_read` só lê o seu projeto, e `lagune_write` só grava em `.lagune/`. O **Gemini CLI** só as inicia em uma pasta confiável. Para liberá-las de antemão, salve esta regra como `~/.gemini/policies/lagune.toml`: ```toml [[rule]] mcpName = "lagune" toolName = ["lagune_read", "lagune_write"] decision = "allow" priority = 100 ``` Quando o engine roda pelo **npx**, como acontece com o **skills.sh**, adicione esta regra ao mesmo arquivo: ```toml [[rule]] toolName = "run_shell_command" commandRegex = 'npx --yes lagune@\d+\.\d+\.\d+\s' decision = "allow" priority = 100 ``` ## Perguntas frequentes ### Como instalar o Lagune no Gemini CLI? Execute gemini extensions install https://github.com/wellwelwel/lagune. ### Como atualizar o Lagune no Gemini CLI? Execute gemini extensions update lagune, ou instale a extensão com --auto-update. ### Como executar os comandos do Lagune no Gemini CLI? Digite-os com o nome da extensão na frente, como /lagune:lagune-charter. ### O Gemini CLI pode rodar o Lagune sem pedir permissão? Sim. Adicione uma regra de política que libere as ferramentas lagune_read e lagune_write do servidor lagune, além de uma para run_shell_command com npx --yes lagune@ e uma versão quando o engine roda pelo npx. --- # Como instalar o Lagune no GitHub Copilot CLI como plugin > Instale o Lagune no GitHub Copilot CLI como plugin e mantenha-o atualizado. Canônica: https://lagune.ai/pt-BR/docs/install/github-copilot-cli Idioma: pt-BR Original: https://lagune.ai/docs/install/github-copilot-cli Última atualização: 2026-11-03 Instale o plugin pelo terminal: ```bash copilot plugin marketplace add wellwelwel/lagune copilot plugin install lagune@lagune ``` Em um editor, instale o **Lagune** para o **GitHub Copilot** com o [**skills.sh**](https://lagune.ai/pt-BR/docs/install/universal). ## Atualização Para atualizar o **Lagune**, execute: ```bash copilot plugin marketplace update lagune copilot plugin update lagune@lagune ``` ## Comandos Digite os comandos pelo nome, como `/lagune-charter`. ## Perguntas frequentes ### Como instalar o Lagune no GitHub Copilot CLI? Execute copilot plugin marketplace add wellwelwel/lagune e depois copilot plugin install lagune@lagune. ### Como atualizar o Lagune no GitHub Copilot CLI? Execute copilot plugin marketplace update lagune e depois copilot plugin update lagune@lagune. ### Como executar os comandos do Lagune no GitHub Copilot CLI? Digite-os pelo nome, como /lagune-charter. ### Dá para usar o Lagune com o GitHub Copilot no VS Code? Sim. No VS Code ou em outro editor, instale o Lagune com o skills.sh em vez do plugin. --- # Como instalar o Lagune no Grok Build como plugin > Instale o Lagune no Grok Build como plugin, mantenha-o atualizado e libere o engine dele de antemão. Canônica: https://lagune.ai/pt-BR/docs/install/grok-build Idioma: pt-BR Original: https://lagune.ai/docs/install/grok-build Última atualização: 2026-11-03 Instale o plugin pelo terminal: ```bash grok plugin install wellwelwel/lagune@plugin-grok --trust ``` ## Atualização Para atualizar o **Lagune**, execute: ```bash grok plugin update lagune ``` ## Comandos Digite os comandos pelo nome, como `/lagune-charter`, ou com o nome do plugin na frente, como `/lagune:lagune-charter`. --- **Permissões** O engine roda por meio de duas ferramentas: `lagune_read` só lê o seu projeto, e `lagune_write` só grava em `.lagune/`. Para liberá-las de antemão, adicione estas regras a `~/.grok/config.toml`: ```toml [permission] allow = ["MCPTool(lagune__lagune_read)", "MCPTool(lagune__lagune_write)"] ``` Quando o engine roda pelo **npx**, como acontece com o **skills.sh**, libere `Bash(npx --yes lagune@*)`. ## Perguntas frequentes ### Como instalar o Lagune no Grok Build? Execute grok plugin install wellwelwel/lagune@plugin-grok --trust. ### Como atualizar o Lagune no Grok Build? Execute grok plugin update lagune. ### Como executar os comandos do Lagune no Grok Build? Digite-os pelo nome, como /lagune-charter, ou com o nome do plugin na frente, como /lagune:lagune-charter. ### O Grok Build pode rodar o Lagune sem pedir permissão? Sim. Libere MCPTool(lagune__lagune_read) e MCPTool(lagune__lagune_write) na configuração do Grok Build, além de Bash(npx --yes lagune@*) quando o engine roda pelo npx. --- # Como instalar o Lagune no Hermes Agent como plugin > Instale o Lagune no Hermes Agent como plugin e mantenha-o atualizado. Canônica: https://lagune.ai/pt-BR/docs/install/hermes-agent Idioma: pt-BR Original: https://lagune.ai/docs/install/hermes-agent Última atualização: 2026-11-03 Instale o plugin pelo terminal: ```bash hermes plugins install wellwelwel/lagune --enable ``` - Quando o **Hermes Agent** pedir para você confirmar um plugin de fora do catálogo dele, **confirme**. - Quando ele oferecer instalar as dependências de **Node.js** do repositório, **recuse**. ## Atualização Para atualizar o **Lagune**, execute: ```bash hermes plugins update lagune ``` ## Comandos Digite os comandos com o nome do plugin na frente, como `/lagune:lagune-charter` para `/lagune-charter` e `/lagune:lagune` para `/lagune`. ## Perguntas frequentes ### Como instalar o Lagune no Hermes Agent? Execute hermes plugins install wellwelwel/lagune --enable. Confirme o plugin quando for solicitado e recuse a instalação das dependências de Node.js do repositório. ### Como atualizar o Lagune no Hermes Agent? Execute hermes plugins update lagune. ### Como executar os comandos do Lagune no Hermes Agent? Digite-os com o nome do plugin na frente, como /lagune:lagune-charter e /lagune:lagune. --- # Como instalar o Lagune no Kimi Code como plugin > Instale o Lagune no Kimi Code como plugin e mantenha-o atualizado. Canônica: https://lagune.ai/pt-BR/docs/install/kimi-code Idioma: pt-BR Original: https://lagune.ai/docs/install/kimi-code Última atualização: 2026-11-03 Instale o plugin em uma sessão do **Kimi Code**, escolha **Trust and install** e depois inicie uma nova sessão para carregá-lo: ```text /plugins install https://github.com/wellwelwel/lagune /new ``` ## Atualização Para atualizar o **Lagune**, instale-o de novo: ```text /plugins install https://github.com/wellwelwel/lagune /new ``` ## Comandos Digite os comandos com o nome do plugin na frente, como `/lagune:lagune-charter` para `/lagune-charter`. O menu `/` os lista como `/skill:lagune:lagune-charter`, o que também funciona. ## Perguntas frequentes ### Como instalar o Lagune no Kimi Code? Em uma sessão do Kimi Code, execute /plugins install https://github.com/wellwelwel/lagune, escolha Trust and install e depois execute /new. ### Como atualizar o Lagune no Kimi Code? Execute /plugins install https://github.com/wellwelwel/lagune de novo e depois /new. ### Como executar os comandos do Lagune no Kimi Code? Digite-os com o nome do plugin na frente, como /lagune:lagune-charter, ou como o menu / os lista, como /skill:lagune:lagune-charter. --- # Como instalar o Lagune no Muse Code como plugin > Instale o Lagune no Muse Code como plugin, mantenha-o atualizado e rode o engine dele dentro do sandbox. Canônica: https://lagune.ai/pt-BR/docs/install/muse-code Idioma: pt-BR Original: https://lagune.ai/docs/install/muse-code Última atualização: 2026-11-03 Instale o plugin pelo terminal: ```bash muse plugins marketplace add lagune wellwelwel/lagune muse plugins install lagune@lagune ``` ## Atualização Para atualizar o **Lagune**, atualize o marketplace e reinstale o plugin: ```bash muse plugins marketplace update lagune muse plugins remove lagune muse plugins install lagune@lagune ``` ## Comandos Digite os comandos pelo nome, como `/lagune-charter`, ou com o nome do plugin na frente, como `/lagune:lagune-charter`. --- **Permissões** O sandbox do **Muse Code** não consegue baixar o engine. Instale-o no seu projeto pelo seu próprio terminal, uma vez e de novo após cada atualização: ```bash npm i -D lagune@0.16.0 ``` ## Perguntas frequentes ### Como instalar o Lagune no Muse Code? Execute muse plugins marketplace add lagune wellwelwel/lagune e depois muse plugins install lagune@lagune. ### Como atualizar o Lagune no Muse Code? Execute muse plugins marketplace update lagune e depois reinstale com muse plugins remove lagune e muse plugins install lagune@lagune. ### Como executar os comandos do Lagune no Muse Code? Digite-os pelo nome, como /lagune-charter, ou com o nome do plugin na frente, como /lagune:lagune-charter. ### O Lagune funciona dentro do sandbox do Muse Code? Sim, depois que você instala o engine no seu projeto com npm i -D lagune@0.16.0 pelo seu próprio terminal, uma vez e de novo após cada atualização. --- # Como instalar o Lagune no OpenCode como plugin > Instale o Lagune no OpenCode 1.x e 2.x como plugin e mantenha-o atualizado. Canônica: https://lagune.ai/pt-BR/docs/install/opencode Idioma: pt-BR Original: https://lagune.ai/docs/install/opencode Última atualização: 2026-11-03 **OpenCode 2.x** Instale o plugin pelo terminal: ```bash opencode plugin add lagune ``` Ou adicione-o à lista `plugins` do `opencode.json`: ```json { "plugins": ["lagune"] } ``` **OpenCode 1.x** Instale o plugin no seu projeto pelo terminal, ou adicione `-g` para instalá-lo em todos os seus projetos: ```bash opencode plugin lagune ``` Ou adicione-o à lista `plugin` do `opencode.json`: ```json { "plugin": ["lagune"] } ``` ## Atualização **OpenCode 2.x** Para atualizar o **Lagune**, execute: ```bash opencode plugin update lagune opencode reload ``` **OpenCode 1.x** Para atualizar o **Lagune**, instale a nova versão por cima da antiga, adicionando `-g` se você o instalou em todos os seus projetos: ```bash opencode plugin lagune@0.16.0 --force ``` ## Comandos **OpenCode 2.x** Digite `@` e escolha o comando, como `@lagune-charter`, depois escreva o seu pedido na mesma mensagem. **OpenCode 1.x** Digite os comandos pelo nome, como `/lagune-charter`. Eles aparecem em `/skills`, e não no menu `/`. --- **Permissões** O engine roda por meio de duas ferramentas: `lagune_read` só lê o seu projeto, e `lagune_write` só grava em `.lagune/`. O **OpenCode** as executa sem perguntar. ## Perguntas frequentes ### Como instalar o Lagune no OpenCode? No OpenCode 2.x, execute opencode plugin add lagune. No OpenCode 1.x, execute opencode plugin lagune, adicionando -g para instalá-lo em todos os seus projetos. ### Como atualizar o Lagune no OpenCode? No OpenCode 2.x, execute opencode plugin update lagune e depois opencode reload. No OpenCode 1.x, execute opencode plugin lagune@0.16.0 --force. ### Como executar os comandos do Lagune no OpenCode? No OpenCode 2.x, digite @ e escolha o comando, como @lagune-charter, depois escreva o seu pedido na mesma mensagem. No OpenCode 1.x, digite-os pelo nome, como /lagune-charter, ou encontre-os em /skills. ### O OpenCode pede permissão antes de rodar o Lagune? Não. O OpenCode executa as duas ferramentas do engine, lagune_read e lagune_write, sem perguntar. --- # Como instalar o Lagune no Pi como pacote > Instale o Lagune no Pi como pacote, pelo npm ou pelo GitHub, e mantenha-o atualizado. Canônica: https://lagune.ai/pt-BR/docs/install/pi Idioma: pt-BR Original: https://lagune.ai/docs/install/pi Última atualização: 2026-11-03 **npm** Instale o pacote pelo terminal: ```bash pi install npm:lagune ``` **GitHub** Instale o commit mais recente do **GitHub**, que roda o engine pelo **npx**: ```bash pi install git:github.com/wellwelwel/lagune ``` ## Atualização **npm** Para atualizar o **Lagune**, execute: ```bash pi update npm:lagune ``` **GitHub** Para atualizar o **Lagune**, execute: ```bash pi update git:github.com/wellwelwel/lagune ``` `pi update --extensions` atualiza todos os pacotes que você instalou, enquanto `pi update` sozinho atualiza apenas o **Pi**. ## Comandos Digite os comandos com o prefixo `skill:`, como `/skill:lagune-charter` para `/lagune-charter`. ## Perguntas frequentes ### Como instalar o Lagune no Pi? Execute pi install npm:lagune, ou pi install git:github.com/wellwelwel/lagune para o commit mais recente do GitHub. ### Como atualizar o Lagune no Pi? Execute pi update npm:lagune, ou pi update git:github.com/wellwelwel/lagune para uma instalação pelo GitHub. pi update --extensions atualiza todos os pacotes que você instalou. ### Como executar os comandos do Lagune no Pi? Digite-os com o prefixo skill:, como /skill:lagune-charter. --- # Como instalar o Lagune no Qwen Code como extensão > Instale o Lagune no Qwen Code como extensão, mantenha-o atualizado e libere o engine dele de antemão. Canônica: https://lagune.ai/pt-BR/docs/install/qwen-code Idioma: pt-BR Original: https://lagune.ai/docs/install/qwen-code Última atualização: 2026-11-03 Instale a extensão pelo terminal: ```bash qwen extensions install lagune ``` ## Atualização Para atualizar o **Lagune**, execute: ```bash qwen extensions update lagune ``` Para mantê-lo atualizado, instale-o com `--auto-update`. ## Comandos Digite os comandos com o nome da extensão na frente, como `/lagune:lagune-charter` para `/lagune-charter`. --- **Permissões** O engine roda por meio de duas ferramentas: `lagune_read` só lê o seu projeto, e `lagune_write` só grava em `.lagune/`. Para liberá-las de antemão, adicione estas regras a `.qwen/settings.json` para um projeto, ou a `~/.qwen/settings.json` para todos eles: ```json { "permissions": { "allow": ["mcp__lagune__lagune_read", "mcp__lagune__lagune_write"] } } ``` Quando o engine roda pelo **npx**, como acontece com o **skills.sh**, libere `Shell(npx --yes lagune@*)`. ## Perguntas frequentes ### Como instalar o Lagune no Qwen Code? Execute qwen extensions install lagune. ### Como atualizar o Lagune no Qwen Code? Execute qwen extensions update lagune, ou instale a extensão com --auto-update. ### Como executar os comandos do Lagune no Qwen Code? Digite-os com o nome da extensão na frente, como /lagune:lagune-charter. ### O Qwen Code pode rodar o Lagune sem pedir permissão? Sim. Libere mcp__lagune__lagune_read e mcp__lagune__lagune_write nas configurações do Qwen Code, além de Shell(npx --yes lagune@*) quando o engine roda pelo npx. --- # Como instalar o Lagune em qualquer agente com o skills.sh > Instale o Lagune em qualquer agente de IA com o skills CLI e mantenha-o atualizado. Canônica: https://lagune.ai/pt-BR/docs/install/universal Idioma: pt-BR Original: https://lagune.ai/docs/install/universal Última atualização: 2026-11-03 **Terminal** Instale os comandos do **Lagune** pelo terminal com o [**skills.sh**](https://www.skills.sh/wellwelwel/lagune): ```bash npx skills add wellwelwel/lagune ``` **Prompt** Cole este prompt no seu agente: ```md Execute `npx --yes skills add wellwelwel/lagune` e siga agora as instruções da skill geradas. Leia a saída completa do comando, redirecionando-a antes para um arquivo temporário se for preciso. Resolva os caminhos relativos a partir do diretório de arquivos de apoio que ele indicar. ``` ## Atualização **Terminal** Para atualizar o **Lagune**, execute: ```bash npx skills update ``` **Prompt** Para atualizar o **Lagune**, cole este prompt no seu agente: ```md Execute `npx --yes skills update -y` e leia a saída completa do comando, redirecionando-a antes para um arquivo temporário se for preciso. ``` --- **Uma forma de instalação por agente** Instale o **Lagune** pelo **skills.sh** ou pelo **plugin** dele, nunca pelos dois. **Permissões** Os comandos rodam o engine como `npx --yes lagune@0.16.0`, e a [página de instalação de cada agente](https://lagune.ai/pt-BR/docs) mostra a regra que o libera de antemão. Em um sandbox sem acesso à rede, instale o engine no seu projeto pelo seu próprio terminal, uma vez e de novo após cada atualização: ```bash npm i -D lagune@0.16.0 ``` ## Perguntas frequentes ### Como instalar o Lagune em qualquer agente de IA? Execute npx skills add wellwelwel/lagune no seu projeto, ou cole o prompt de instalação no seu agente. ### Como atualizar o Lagune instalado com o skills CLI? Execute npx skills update, ou cole o prompt de atualização no seu agente. ### Posso instalar o Lagune com o skills CLI e com um plugin ao mesmo tempo? Não. Com os dois, o agente lista cada comando duas vezes, ou usa uma cópia e esconde a outra. --- # Skills de segurança para agentes de IA > As skills que o seu agente de IA ganha com o Lagune: audite um projeto existente ou proteja o trabalho novo enquanto desenvolve, tudo regido pelo charter. Canônica: https://lagune.ai/pt-BR/docs/get-started/commands Idioma: pt-BR Original: https://lagune.ai/docs/get-started/commands Última atualização: 2026-11-03 Depois que o **Lagune** está [instalado](https://lagune.ai/pt-BR/docs), o seu agente de **IA** ganha um conjunto de skills. Há duas formas de usá-las, e as duas são regidas pelo **charter**: proteger o trabalho novo enquanto você o constrói ou rodar a auditoria completa em um projeto. **⌨️ Construção / desenvolvimento** Você não precisa terminar o seu trabalho antes de protegê-lo. Use o [**`/lagune`**](https://lagune.ai/pt-BR/docs/commands/lagune) para o trabalho que você está escrevendo **agora**: | Skill | O que ela faz por você | | --------------------------------------------- | -------------------------------------------------------------------------------------------- | | [**/lagune-charter**](https://lagune.ai/pt-BR/docs/commands/charter) | Define as regras de segurança do seu projeto, a base sobre a qual o `/lagune` constrói | | [**/lagune**](https://lagune.ai/pt-BR/docs/commands/lagune) | Constrói o que você pede e aplica hardening enquanto o código é escrito, guiado pelo charter | **Use a qualquer momento** O [**`/lagune`**](https://lagune.ai/pt-BR/docs/commands/lagune) respeita as regras do seu charter sempre que roda. Ele aceita qualquer prompt, constrói o que você pediu e o protege com padrões seguros ao longo do caminho, e não depois. --- #### Skills especiais | Skill | O que ela faz | | --------------------------------------------------- | ------------------------------------------------------------------------------------------------ | | [**/lagune-specialize**](https://lagune.ai/pt-BR/docs/commands/specialize) | Ensina ao **Lagune** uma nova especialização de segurança a partir de artigos, exploits ou temas | **🔬 Auditoria: fluxo Blue Team** O **fluxo Blue Team** completo: entender o que um projeto faz, mapear os riscos dele e eliminá-los. Cada skill se apoia na anterior, então basta seguir a lista de cima para baixo: | # | Skill | O que ela faz por você | | --- | --------------------------------------------- | -------------------------------------------------------------------------------------------------- | | 1 | [**/lagune-charter**](https://lagune.ai/pt-BR/docs/commands/charter) | Define as regras de segurança do seu projeto, propostas para você ou moldadas pelo que você disser | | 2 | [**/lagune-detect**](https://lagune.ai/pt-BR/docs/commands/detect) | Lê o seu código e mapeia o que o seu sistema faz e onde estão os riscos | | 3 | [**/lagune-plan**](https://lagune.ai/pt-BR/docs/commands/plan) | Transforma o que o detect encontrou em um plano de defesa, com uma correção para cada achado | | 4 | [**/lagune-harden**](https://lagune.ai/pt-BR/docs/commands/harden) | Aplica ao seu código as correções do plano, com segurança e uma de cada vez | | 5 | [**/lagune-verify**](https://lagune.ai/pt-BR/docs/commands/verify) | Comprova que cada correção aplicada se sustenta e encerra as que passarem | --- #### Skills especiais | Skill | O que ela faz | | --------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- | | [**/lagune-specialize**](https://lagune.ai/pt-BR/docs/commands/specialize) | Ensina ao **Lagune** uma nova especialização de segurança a partir de artigos, exploits ou temas | | [**/lagune-prove**](https://lagune.ai/pt-BR/docs/commands/prove) | Transforma cada achado detectado em uma prova executável e exclusivamente defensiva para divulgação responsável | --- #### Skills internas | Skill | O que ela faz | | ------------------------------------------- | ------------------------------------------- | | [**/lagune-repair**](https://lagune.ai/pt-BR/docs/commands/repair) | Repara o rastreamento interno do **Lagune** | **Dica** Segurança não é custo, é investimento: o que você aplica de antemão, você economiza muitas vezes nos incidentes que nunca acontecem 🙋🏻‍♂️ ## Perguntas frequentes ### Quais skills o Lagune adiciona? O /lagune, para aplicar hardening ao trabalho enquanto você o constrói, e o fluxo de auditoria Blue Team de cinco fases: /lagune-charter, /lagune-detect, /lagune-plan, /lagune-harden e /lagune-verify. Além do /lagune-specialize e do /lagune-prove. ### O que é o fluxo Blue Team do Lagune? Uma auditoria em cinco fases: charter (define as regras), detect (mapeia os riscos), plan (dá notas e planeja as correções), harden (aplica as correções) e verify (comprova que elas se sustentam e as encerra). ### Qual é a diferença entre o /lagune e o fluxo de auditoria? O /lagune protege o trabalho novo enquanto você o escreve, sem nenhum fluxo para seguir. O fluxo de auditoria executa as cinco fases em ordem sobre um projeto existente. --- # Dashboard > Veja o charter, os achados e o catálogo do seu projeto em uma visão local e ao vivo que abre com um único comando. Canônica: https://lagune.ai/pt-BR/docs/get-started/dashboard Idioma: pt-BR Original: https://lagune.ai/docs/get-started/dashboard Última atualização: 2026-11-03 Execute o **Lagune** diretamente, sem subcomando, para ter uma visão interativa e ao vivo de `.lagune/`. Ele serve um dashboard e o abre em uma porta aleatória: ```bash npx lagune ``` - [x] **Live reload** - [x] **Privado** e **local** - [x] Mostra tudo o que `.lagune/` contém, desde o primeiro charter - [x] **Gerencie** as categorias do projeto direto do seu navegador - [x] Não precisa de `node_modules` nem de `package.json` 📦 ![Charter no dashboard do Lagune](https://lagune.ai/img/dashboard/02.webp) ![Achados no dashboard do Lagune](https://lagune.ai/img/dashboard/03.webp) ![Side quests no dashboard do Lagune](https://lagune.ai/img/dashboard/04.webp) ![Detalhe de um achado no dashboard do Lagune](https://lagune.ai/img/dashboard/05.webp) ![Catálogo no dashboard do Lagune](https://lagune.ai/img/dashboard/06.webp) **Dica** - 🚪 Use `--port` para definir uma porta personalizada. - ⏏️ Pressione `Ctrl+C` para parar. ## Perguntas frequentes ### Como abrir o dashboard do Lagune? Execute npx lagune sem subcomando na raiz do seu projeto. Ele serve uma visão ao vivo de .lagune/ em uma porta aleatória e a abre no seu navegador. ### O dashboard é privado? Sim. Ele roda apenas na sua própria máquina, em um endereço local que nenhum outro computador alcança. ### Posso alterar o meu projeto pelo dashboard? Só as categorias, pelo seu navegador. Todo o resto que o dashboard mostra é somente leitura. --- # /lagune: código seguro enquanto a sua IA escreve > Construa o que você pede com hardening aplicado enquanto o código é escrito, guiado pelo charter e sem nenhum fluxo para seguir. Canônica: https://lagune.ai/pt-BR/docs/commands/lagune Idioma: pt-BR Original: https://lagune.ai/docs/commands/lagune Última atualização: 2026-11-03 ⌨️ Faça o trabalho que você pediu, protegido enquanto é escrito. O **`/lagune`** aceita qualquer prompt, em qualquer etapa, constrói o que você queria e o protege com padrões seguros antes de devolvê-lo. ## Como usar Coloque o **`/lagune`** em qualquer prompt e descreva o trabalho como você sempre faria. **📘 Instruções do agente** ```md # Instruções do meu projeto para agentes ## Segurança - Use a skill `/lagune` sempre que criar ou alterar código, para que ela torne o resultado mais seguro por padrão. ``` - Por exemplo: **AGENTS.md**, **CLAUDE.md**, **.github/copilot-instructions.md**, **.cursorrules** etc. **💬 Uma funcionalidade** ```prompt /lagune permita que os usuários enviem uma foto personalizada no perfil. ``` **💬 Uma correção** ```prompt /lagune nada acontece quando o usuário envia o formulário. Descubra o que pode ser e corrija. ``` **💬 Uma refatoração** ```prompt /lagune desacople e melhore a lógica do payload ``` **Charter opcional, mas melhor com ele** O **`/lagune`** roda com ou sem charter. Com um, as regras do seu próprio projeto moldam cada construção. Defina-as uma vez com o [`/lagune-charter`](https://lagune.ai/pt-BR/docs/commands/charter). ## Como funciona Ele envolve o trabalho em três movimentos, sem gravar nada no Lagune: 1. Carrega o seu charter, se ele existir, e os princípios dele regem toda a construção. Quando você ainda não tem um, recorre a uma base segura por padrão. 2. Lista o [catálogo](https://lagune.ai/pt-BR/docs/catalog) do seu projeto e carrega apenas as especializações que o seu trabalho toca, o mesmo conhecimento sob demanda que o fluxo de auditoria usa. 3. Aplica a defesa enquanto o código é escrito e depois relê o próprio resultado para confirmar que os controles realmente se sustentam antes de devolver o trabalho. O resultado é código funcionando no seu projeto, seguro desde a primeira linha. **Use a qualquer momento** Sem detect, sem plan, sem limpeza depois. O **`/lagune`** serve tanto para um projeto recém-criado quanto para uma mudança em um código maduro, e protege o trabalho ao longo do caminho, e não depois. ## O que ele não faz - Não grava nada no diretório `.lagune`, nem artefato nem rastreamento, então a única coisa que ele produz é o código protegido que você pediu. - Não afrouxa uma regra para atender a um prompt. Se o que você pediu violaria um princípio do charter, ele para e avisa você antes, em vez de construir direto de forma insegura. ## Perguntas frequentes ### O que o /lagune faz? Ele aceita qualquer prompt, em qualquer etapa, constrói o que você pediu e o protege com padrões seguros antes de devolvê-lo. A defesa é aplicada enquanto o código é escrito, e não depois. ### Preciso de um charter para usar o /lagune? Não. Ele roda com ou sem um. Com um charter, as regras do seu próprio projeto moldam cada construção. Sem ele, recorre a uma base segura por padrão. ### Qual é a diferença entre o /lagune e o fluxo Blue Team? O /lagune protege o trabalho novo enquanto você o escreve, sem nenhum fluxo para seguir. O fluxo Blue Team executa as cinco fases de auditoria em ordem sobre um projeto existente. ### O /lagune rastreia achados ou grava artefatos? Não. Ele não grava nada no diretório .lagune, nem artefato nem rastreamento. A única coisa que ele produz é o código protegido que você pediu. ### Como faço o meu agente usar o /lagune automaticamente? Adicione ao arquivo de instruções do seu agente (AGENTS.md, CLAUDE.md, .cursorrules e similares) uma instrução para ele usar a skill /lagune sempre que construir ou alterar código. --- # /lagune-charter: defina os seus princípios de segurança > Estabeleça os princípios de segurança do seu projeto, as regras que todas as fases seguintes respeitam, e registre as categorias de especialização que a leitura do projeto justifica. Canônica: https://lagune.ai/pt-BR/docs/commands/charter Idioma: pt-BR Original: https://lagune.ai/docs/commands/charter Última atualização: 2026-11-03 🧬 Conte ao **Lagune** o que é o seu projeto, e ele transforma isso nas suas regras de segurança (ou, sem descrição, as deduz só a partir do projeto). O charter é a camada que rege tudo: um conjunto de princípios que colocam a segurança em primeiro lugar e que todas as fases seguintes precisam respeitar. Pense nele como a verificação em tempo de compilação da postura de segurança do seu projeto. ## Como usar **Descreva o projeto** ```prompt /lagune-charter Meu projeto é uma loja virtual que vende jogos de videogames. Os clientes adicionam produtos ao carrinho e pagam com cartão de crédito ou boleto. Eles podem ver os próprios pedidos e o status de cada um. ``` **Deixe o Lagune propor** ```prompt /lagune-charter ``` > _Vejo uma biblioteca de pagamento, uma configuração de login e um modelo de pedido ligado a um cliente. Parece uma loja virtual que vende alguma coisa. Os clientes pagam e acompanham os próprios pedidos..._ ☁️ ## O que ele deduz O **Lagune** usa a sua descrição ou o seu **PRD** como direção, deduz o que isso implica para a segurança e então lê o projeto para ir além do que você mencionou. Por exemplo: - Um carrinho que guarda pedidos significa que existe um **banco de dados**: - por exemplo, `"Onde ficam os dados?"`, `"Quem consegue acessá-los?"`, `"Eles vazam?"`. - Clientes que podem ver os próprios pedidos significam que existe algum tipo de **login ou controle de acesso**: - por exemplo, `"Um cliente consegue acessar os pedidos de outro?"`, `"As sessões estão protegidas?"`. - Aceitar pagamentos com cartão e boleto significa que **dinheiro e dados sensíveis estão envolvidos**: - por exemplo, `"Os dados do cartão ficam armazenados?"`, `"Os pagamentos são verificados?"`. A sua descrição e o projeto se somam: enquanto a descrição define a intenção, a leitura das dependências, do README e da configuração revela o que você não mencionou. Se algo importante continuar incerto, o **Lagune** faz uma pergunta curta e simples em vez de tentar adivinhar. A partir daí, o **Lagune** monta um conjunto de regras de segurança sob medida para o projeto, que você pode revisar e ajustar sempre que precisar. **Aproveite ao máximo** - Você também pode definir as suas próprias regras de segurança para o projeto. - Quanto mais detalhes relevantes você der, melhor será o relatório final: - Explique o projeto, como ele funciona e o que acontece por baixo dos panos. - Quem é o usuário final? O que os usuários podem fazer, e o que não podem? - Detalhes de comportamento valem tanto quanto detalhes técnicos. - A memória do charter fica em `.lagune/memory/charter.md`. ## As categorias que ele registra As especializações, o conhecimento de segurança que as fases seguintes carregam sob demanda, entram no [catálogo](https://lagune.ai/pt-BR/docs/catalog) do seu projeto por [categoria](https://lagune.ai/pt-BR/docs/categories). Enquanto o seu projeto não tem nenhuma categoria registrada, o charter registra cada uma que a leitura dele justifica, como a linguagem do projeto, chamadas a um LLM ou contêineres, e as cita no resumo. Depois que as categorias estão registradas, o charter as mantém como estão e só cita uma categoria que o seu projeto ainda não usa. Você mesmo pode alterá-las a qualquer momento: ```bash npx lagune write add --categories python npx lagune write remove --categories python ``` ## Próximo passo Com as regras definidas, mapeie o que o seu sistema realmente faz: [`/lagune-detect`](https://lagune.ai/pt-BR/docs/commands/detect). ## Perguntas frequentes ### O que é o charter no Lagune? O charter é a camada que rege o Lagune, um conjunto de princípios que colocam a segurança em primeiro lugar e que todas as fases seguintes precisam respeitar. Pense nele como a verificação em tempo de compilação da postura de segurança do seu projeto. ### Onde o charter fica salvo? Em .lagune/memory/charter.md. ### Posso escrever as minhas próprias regras no charter? Sim. O Lagune propõe regras a partir da sua descrição e do seu código, e você pode reescrevê-las, removê-las, acrescentar novas ou reduzir o escopo delas. ### O charter escolhe as minhas categorias de especialização? Só enquanto nenhuma está registrada. Nesse caso, ele registra cada categoria que a leitura dele justifica, como a sua linguagem ou chamadas a um LLM. Depois que as categorias estão registradas, ele nunca as altera. --- # /lagune-detect: mapeie o seu sistema e os riscos dele > Leia o seu código e mapeie o que o seu sistema faz e onde estão os riscos. Canônica: https://lagune.ai/pt-BR/docs/commands/detect Idioma: pt-BR Original: https://lagune.ai/docs/commands/detect Última atualização: 2026-11-03 🔬 Descubra o que o seu sistema realmente faz e onde estão os riscos. O detect lê o código e registra apenas o que de fato encontra, com as evidências de que as fases seguintes precisam. A regra que o rege é detectar, não inventar. ## Como usar **Varredura completa** ```prompt /lagune-detect ``` **Aponte caminhos** ```prompt /lagune-detect src/routes/ src/auth.ts ``` **Descreva uma preocupação** ```prompt /lagune-detect garanta que os dados dos clientes nunca fiquem expostos ``` ## O que ele mapeia O **Lagune** lê o código e mapeia o que encontra. Cada achado traz o que ele é, por que importa e a evidência. Por exemplo: - **Upload de arquivos**: o sistema aceita arquivos enviados pelos usuários. - _Por que importa:_ um arquivo disfarçado de imagem pode esconder código malicioso. - _Evidência:_ o handler de `POST /upload` confia no MIME type enviado pelo cliente, sem verificar o tipo real do arquivo. - **Login e sessões**: os usuários entram para acessar a própria conta. - _Por que importa:_ um controle de sessão fraco permite que uma conta seja tomada por outra. - _Evidência:_ a lógica de emissão de sessões, em que as sessões são emitidas sem prazo de expiração. No caminho, o detect dá a cada especialização do [catálogo](https://lagune.ai/pt-BR/docs/catalog) do seu projeto um veredito em relação ao código, aplica aquelas cujo contexto está presente e as registra em **Applied specializations**, a lista que o harden e o verify reaproveitam. A partir daí, você tem um mapa claro do que o seu sistema faz e de onde estão os riscos, pronto para as próximas etapas agirem sobre ele. **Dica** - Rodar de novo atualiza o mapa: os achados resolvidos saem e os novos entram. - O mapa do detect fica em `.lagune/memory/detect.md`. ## Próximo passo Transforme o mapa em um plano: [`/lagune-plan`](https://lagune.ai/pt-BR/docs/commands/plan). ## Perguntas frequentes ### O que o /lagune-detect faz? Ele lê o seu código e mapeia o que o seu sistema faz e onde estão os riscos, registrando apenas o que de fato encontra. A regra dele é detectar, não inventar. ### O que é um achado no Lagune? Um achado é um risco detectado, com o que ele é, por que importa e a evidência no código. É a unidade rastreada que o plan, o harden e o verify levam adiante. ### Onde o mapa do detect fica salvo? Em .lagune/memory/detect.md. ### Quais especializações o detect usa? Cada uma do catálogo do seu projeto recebe um veredito em relação ao código. O detect aplica aquelas cujo contexto está presente e as registra em Applied specializations. --- # /lagune-plan: classifique os achados e planeje as correções > Transforme o que o detect encontrou em um plano de defesa, classificando cada achado com uma categoria e uma nota CVSS v4.0 e associando a ele uma correção. Canônica: https://lagune.ai/pt-BR/docs/commands/plan Idioma: pt-BR Original: https://lagune.ai/docs/commands/plan Última atualização: 2026-11-03 🛡️ Transforme o que o detect encontrou em um plano de defesa: classifique cada achado com uma categoria e uma nota CVSS v4.0 e depois associe a ele a correção a aplicar. ## Como usar **Planeje tudo** ```prompt /lagune-plan ``` **Aponte caminhos** ```prompt /lagune-plan src/routes/upload.ts ``` **Foque em uma preocupação** ```prompt /lagune-plan onde dados sensíveis podem vazar ``` ## Como funciona Esta fase continua a partir do detect. O detect já descobriu o que o seu sistema faz e o risco que cada parte carrega, então o plano não repete o risco: ele avalia a gravidade e decide o que fazer a respeito. O plan nunca lê o código, o que obriga cada correção a apontar para algo que o detect de fato detectou. Ele classifica cada achado pelo método CVSS v4.0: uma categoria, um vetor CVSS v4.0 deduzido a partir do que o detect e o charter registraram e calculado pelo [hook `cvss`](https://lagune.ai/pt-BR/docs/hooks/cvss), e a faixa de prioridade em que essa nota cai. Cada correção também traz o princípio do charter que ela sustenta. Por exemplo: - **Upload de arquivos** (Prioridade: **Crítica**) - _Categoria:_ upload de arquivos sem restrição (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, crítica). - _Por que esta prioridade:_ qualquer pessoa alcança o upload pela internet, e ele fica no servidor que guarda os arquivos dos clientes. - _Sustenta:_ III. Toda entrada é não confiável até ser validada. - _Correção:_ verificar o tipo real e o tamanho do arquivo, renomeá-lo ao salvar e guardar os uploads onde não possam ser executados como código. A partir daí, você tem uma lista de correções classificada e priorizada, cada uma ligada a um achado e pronta para a próxima fase aplicar. A nota é calculada, nunca estimada: o vetor carrega a exposição e o que está em jogo no projeto como métricas Environmental, e qualquer pessoa pode colá-lo na calculadora da FIRST ou do NVD e chegar à mesma nota. **Dica** - Ele se apoia inteiramente no detect. Se um arquivo ou uma preocupação nunca foi mapeado, ele pede que você rode o `/lagune-detect` sobre isso primeiro. - Rodar de novo atualiza o plano: as correções concluídas saem e as novas entram. - O plano de defesa fica em `.lagune/memory/plan.md`. **Depende do detect** O plan trabalha apenas com o que o [`/lagune-detect`](https://lagune.ai/pt-BR/docs/commands/detect) já mapeou, então rode o detect primeiro. ## Próximo passo Aplique o plano: [`/lagune-harden`](https://lagune.ai/pt-BR/docs/commands/harden). ## Perguntas frequentes ### Como o Lagune prioriza as vulnerabilidades? O /lagune-plan classifica cada achado com uma categoria e uma nota CVSS v4.0 calculada pelo hook cvss e depois associa a ele a correção a aplicar. ### O Lagune usa CVSS v4.0? Sim. Cada achado recebe um vetor e uma nota CVSS v4.0, calculados pelo hook cvss com a mesma aritmética da calculadora da FIRST, então qualquer pessoa pode colar o vetor lá e chegar à mesma nota. ### O plano lê o meu código? Não. O plan nunca lê o código, o que obriga cada correção a apontar para algo que o detect de fato detectou. --- # /lagune-harden: aplique correções de segurança ao seu código > Aplique ao seu código as correções do plano, com segurança e uma de cada vez. Canônica: https://lagune.ai/pt-BR/docs/commands/harden Idioma: pt-BR Original: https://lagune.ai/docs/commands/harden Última atualização: 2026-11-03 🔧 Aplique ao seu código as correções do plano, com segurança e uma de cada vez. ## Como usar **Aplique tudo** ```prompt /lagune-harden ``` **Aponte caminhos** ```prompt /lagune-harden src/routes/upload.ts ``` **Por prioridade** ```prompt /lagune-harden só as de prioridade crítica e alta ``` ## Como funciona O plano já definiu cada correção, então o harden apenas a aplica. Como esta é a única fase que mexe no seu código, ela age com cuidado: aplica uma correção de cada vez, para que cada mudança continue fácil de revisar, e nunca afrouxa um controle para encaixar uma correção. Por exemplo, a correção do upload: - **Upload de arquivos** (Status: **Applied**) - _O que mudou:_ verifica o tipo real e o tamanho do arquivo, rejeita qualquer coisa inesperada, renomeia o arquivo ao salvar e o guarda onde ele não pode ser executado como código. - _Onde:_ a função `handleUpload`, além do helper de armazenamento que ela chama. Se uma correção não puder ser aplicada por completo, o harden faz o que dá para fazer com segurança e marca o resto como **Partial** ou **Blocked**, deixando-o em aberto. **Aplicado não é verificado** Applied ainda não significa comprovado. É para isso que serve o [verify](https://lagune.ai/pt-BR/docs/commands/verify). **Dica** - Ele se apoia inteiramente no plano. Se uma correção ou um arquivo nunca foi planejado, ele pede que você rode o `/lagune-plan` sobre isso primeiro. - Rodar de novo reconcilia o registro: as mudanças revertidas saem e as correções recém-aplicadas entram. - O registro do hardening fica em `.lagune/memory/harden.md`. **Depende do plan e altera o seu código** O harden se apoia no [`/lagune-plan`](https://lagune.ai/pt-BR/docs/commands/plan). É a única fase que altera o seu código. ## Próximo passo Comprove que cada correção se sustenta: [`/lagune-verify`](https://lagune.ai/pt-BR/docs/commands/verify). ## Perguntas frequentes ### O /lagune-harden altera o meu código? Sim. É a única fase que mexe no seu código, aplicando as correções do plano uma de cada vez. ### O que significam Applied, Partial e Blocked? São os status que o Lagune registra para cada correção. Applied significa que a correção foi feita, Partial significa que só uma parte dela foi feita e Blocked significa que não foi possível aplicá-la. Applied ainda não significa comprovado. ### O Lagune aplica correções sem pedir permissão? Quem decide se uma edição precisa da sua aprovação é o seu agente e o modo de permissão em que você o executa, não o Lagune, que não acrescenta nenhuma etapa de confirmação própria. Mesmo assim, ele nunca afrouxa um controle para encaixar uma correção e, se uma correção entrar em conflito com uma regra do charter, ele para e avisa você antes. --- # /lagune-verify: comprove que os controles de segurança se sustentam > Comprove que cada correção aplicada se sustenta e encerre as que passarem. Canônica: https://lagune.ai/pt-BR/docs/commands/verify Idioma: pt-BR Original: https://lagune.ai/docs/commands/verify Última atualização: 2026-11-03 ⚖️ Comprove que cada correção aplicada se sustenta, lendo o código e confrontando-o com o que o harden registrou, e encerre as que passarem. ## Como usar **Verifique tudo** ```prompt /lagune-verify ``` **Aponte caminhos** ```prompt /lagune-verify src/routes/upload.ts ``` **Por prioridade** ```prompt /lagune-verify só as de prioridade crítica e alta ``` ## Como funciona Ele lê o código em cada ponto que o harden registrou e confirma que ele realmente corresponde ao que foi afirmado. A prova é esse confronto, o código contra o registro. Cada controle recebe um destes três vereditos: | Veredito | Significado | | ---------------------------- | ---------------------------------------------------------------------- | | ✅ Risk closed | O código faz exatamente o que o registro afirma. | | ❌ Risk not closed | O controle continua em aberto. O verify manda você de volta ao harden. | | ❓ Cannot tell from the code | A evidência não é visível apenas pelo código. | Um risco comprovadamente eliminado é então encerrado e sai da cadeia, com a sua confirmação. Por exemplo: - **Upload de arquivos** (Veredito: **✅ Risk closed**) - _Como foi comprovado:_ leu o handler de upload e viu que ele detecta o tipo real do arquivo pelo conteúdo, impõe um limite de tamanho e recusa todo o resto, exatamente como o registro afirma. - _Evidência:_ a função `handleUpload`, que detecta o tipo real do arquivo pelo conteúdo. Se o risco não foi eliminado, o verify diz isso com clareza e manda você de volta ao [`/lagune-harden`](https://lagune.ai/pt-BR/docs/commands/harden), já que a correção continua em aberto. **Dica** - Ele se apoia inteiramente no registro do hardening. - Ele só lê o seu código para julgá-lo e nunca afrouxa um controle nem reescreve o código para fazer um veredito passar. - Rodar de novo reconcilia os vereditos: os desatualizados saem, e um risco que deixou de estar eliminado volta a ser sinalizado. - Quando um risco é comprovadamente eliminado, ele pergunta uma vez e então remove esse achado de toda a cadeia (detect, plan, harden e rastreamento). - Ele não grava nenhum relatório próprio: cada veredito fica no bloco do controle correspondente em `.lagune/memory/harden.md`, onde o harden o lê na próxima execução. **Depende do harden** O verify se apoia no [`/lagune-harden`](https://lagune.ai/pt-BR/docs/commands/harden). ## O ciclo se fecha Quando tudo o que está no escopo é encerrado, o ciclo entra em repouso. Ele só reabre quando o código muda. A segurança pode ser concluída, então o fluxo tem um estado final, e não um loop infinito. ## Perguntas frequentes ### Como o Lagune verifica uma correção? O /lagune-verify lê o código e o confronta com o que o harden registrou, devolvendo um destes três vereditos: Risk closed (risco eliminado), Risk not closed (risco não eliminado) ou Cannot tell from the code (não dá para saber pelo código). ### O que significa encerrar um achado? Quando o verify comprova que um risco foi eliminado, o achado é encerrado: sai de toda a cadeia, com a sua confirmação, e deixa de ser reprocessado. ### O trabalho de segurança pode chegar ao fim? Sim. O SDH pode ser concluído: um achado comprovadamente eliminado é encerrado, então o fluxo tem um estado final, e não um loop infinito. --- # Categorias > As categorias de especializações que um projeto Lagune pode usar, do OWASP ao hardening por linguagem para JavaScript, Python, Go e Rust, e como alterá-las. Canônica: https://lagune.ai/pt-BR/docs/categories Idioma: pt-BR Original: https://lagune.ai/docs/categories Última atualização: 2026-11-03 O **Lagune** agrupa as suas [**especializações**](https://lagune.ai/pt-BR/docs/catalog) nativas em **13 categorias**. As categorias que um projeto usa decidem quais especializações nativas entram no [**catálogo**](https://lagune.ai/pt-BR/docs/catalog) dele, e elas se dividem em dois grupos: o que o sistema faz e em que ele é escrito. Enquanto nenhuma categoria está registrada, o projeto usa apenas `owasp`. O [`/lagune-charter`](https://lagune.ai/pt-BR/docs/commands/charter) registra cada categoria que a leitura dele sobre o projeto justifica, e você mesmo pode alterá-las a qualquer momento. ## O que o sistema faz | Categoria | Chave | O que ela protege | | -------------- | --------- | -------------------------------------------------------------------------------------------------------------------------------------------- | | OWASP | `owasp` | Os riscos de segurança de aplicações que a OWASP acompanha: injection, controle de acesso quebrado, falhas de autenticação e de criptografia | | Infraestrutura | `infra` | Configuração de contêineres, workloads e serverless: Dockerfile, Compose, segurança de Pods, IAM e triggers de FaaS | | IA / LLM | `ai` | Integrações de IA e LLM, contra prompt injection e conexões inseguras de ferramentas, agentes, retrieval e MCP | | Lovable | `lovable` | Apps Supabase gerados por IA (Lovable e similares): falhas de RLS, chaves `service_role` vazadas e padrões inseguros | ## Em que ele é escrito | Categoria | Chave | O que ela protege | | ---------- | ------------ | ----------------------------------------------------------------------------------------------------------------- | | JavaScript | `javascript` | RCE por `eval` e `child_process`, path traversal e prototype pollution, em todos os seus runtimes | | Python | `python` | RCE por desserialização de `pickle` e YAML, travessia de strings com `str.format` e class pollution | | Rust | `rust` | APIs `unsafe` incorretas, mau uso de `transmute`, integer overflow e comportamento indefinido na fronteira de FFI | | C / C++ | `c-cpp` | Bugs de format string, buffer overflows e escritas fora dos limites que permitem execução de código | | PHP | `php` | Bypass de autenticação por type juggling, gadget chains de object injection e padrões de configuração inseguros | | Go | `go` | Bugs de interface com nil tipado, data races entre goroutines e concorrência insegura em caminhos de segurança | | Java | `java` | Gadget chains de desserialização com `ObjectInputStream` que culminam em execução remota de código | | Ruby | `ruby` | Gadget chains de desserialização com `Marshal.load` e YAML que chegam à execução remota de código | | .NET / C# | `dotnet` | RCE por desserialização com `BinaryFormatter` e os bypasses de encoder que levam a XSS | **Dica** O **Lagune** é independente de linguagem: o fluxo inteiro lê o seu projeto, seja qual for a linguagem dele, e essas categorias só acrescentam profundidade nas armadilhas específicas de uma linguagem. ## Adicione e remova quando quiser Uma categoria é um ponto de partida, não um compromisso. Use o que serve ao projeto agora e altere quando quiser, pela chave, com `write add` e `write remove`. Em um terminal, `--categories` sem valor abre um seletor interativo (espaço para marcar ou desmarcar, enter para confirmar, nenhuma seleção para pular). Fora de um terminal, passe as categorias depois dele. **Adicionar** ```bash npx lagune write add --categories # interactive npx lagune write add --categories owasp npx lagune write add --categories owasp rust ``` **Remover** ```bash npx lagune write remove --categories # interactive npx lagune write remove --categories owasp npx lagune write remove --categories owasp rust ``` O primeiro `write add` ou `write remove` parte de `owasp`, então remover todas as categorias deixa uma lista vazia, nunca o padrão. Toda alteração vai para `.lagune/configs.json`, para que o time inteiro trabalhe com o mesmo conjunto. ## Veja o que um projeto usa O `read list --categories` mostra todas as categorias e se o projeto usa cada uma delas: ```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. ``` Veja o [**Catálogo**](https://lagune.ai/pt-BR/docs/catalog) para saber quais especializações cada categoria traz. As suas próprias especializações, escritas com o [`/lagune-specialize`](https://lagune.ai/pt-BR/docs/commands/specialize), entram no catálogo independentemente das categorias. ## Perguntas frequentes ### Como adicionar uma categoria? Passe a chave da categoria para --categories, por exemplo npx lagune write add --categories javascript. Enquanto nenhuma está registrada, o charter também registra as categorias que a leitura dele sobre o projeto justifica. ### Posso usar mais de uma categoria? Sim. Liste todas na mesma linha, uma depois da outra. ### Qual categoria um projeto deve usar? Comece com owasp, o padrão, e depois adicione a da sua linguagem ou stack. As especializações carregam apenas sob demanda, então uma categoria não custa nada até que uma fase precise de uma das especializações dela. --- # Catálogo: especializações de segurança sob demanda > Como as especializações do catálogo do seu projeto são carregadas, sob demanda por uma fase ou diretamente por você. Canônica: https://lagune.ai/pt-BR/docs/catalog Idioma: pt-BR Original: https://lagune.ai/docs/catalog Última atualização: 2026-11-03 🧠 As especializações do **Lagune** são módulos de conhecimento de segurança focados e independentes de linguagem, que carregam apenas sob demanda, nunca por padrão. Elas não são comandos. O catálogo do seu projeto é o conjunto que ele usa: as especializações nativas das suas [categorias](https://lagune.ai/pt-BR/docs/categories), mais as próprias. As fases detect e verify recorrem a elas enquanto rodam, e você pode carregar uma diretamente a qualquer momento. **Visão geral** *A visão geral interativa do catálogo está na página web. Todas as especializações nativas estão na tabela abaixo.* **Como funciona** ## Use você mesmo Para usar uma especialização diretamente, peça ao seu agente para carregá-la com `read catalog ` e escreva a tarefa no mesmo prompt. O conhecimento então atua sobre o que você pediu. Isso funciona em qualquer prompt, mesmo em um que não tenha relação com o fluxo do **Lagune**. Por exemplo, um prompt direto e livre para gerar uma coleção segura de **RegExp** em **Python**: ```prompt Carregue a especialização regex com `npx lagune read catalog regex` e depois crie uma coleção de expressões regulares em @src/utils/regex.py para validar e-mails e nomes de usuário. ``` Isso usa um hook determinístico para testar cada **RegExp** contra **ReDoS**, mantém as seguras e produz algo como: ```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 ``` **Experimente o verificador de ReDoS** Teste um padrão você mesmo em [**devina.io/redos-checker**](https://devina.io/redos-checker). ## As especializações nativas As especializações nativas são agrupadas em [**categorias**](https://lagune.ai/pt-BR/docs/categories). Este é o conjunto que vem com o **Lagune**: | Especialização | Categoria | Foco | | --------------------- | --------------------------- | ---------------------------------------------------------------------------------------------------- | | `regex` | `owasp` | **ReDoS:** padrões que explodem com uma entrada manipulada. | | `network` | `owasp` | **SSRF e redirecionamentos:** destinos de requisição ou de redirecionamento fornecidos pelo usuário. | | `interpreter` | `owasp`, `lovable` | **Injeção de código:** `eval`, include dinâmico, despacho por nome. | | `sql` | `owasp` | **Bancos de dados relacionais:** injection, chamadas brutas ao ORM, privilégios, alcance do engine. | | `path` | `owasp` | **Caminhos no sistema de arquivos:** traversal, byte nulo, streams NTFS, plantio de arquivos. | | `upload` | `owasp` | **Upload de arquivos:** tipo e assinatura, conteúdo malicioso, armazenamento, limites. | | `access-control` | `owasp`, `lovable` | **Autenticação, autorização e sessão:** IDOR, mass assignment, tenants, sessões. | | `credential-endpoint` | `owasp`, `lovable` | **Adivinhação e bots:** força bruta, spraying, stuffing, throttling. | | `federation` | `owasp` | **Confiança em tokens:** OAuth e OIDC, SAML, validação de JWT, login por QR code. | | `http-request` | `owasp` | **Origem da requisição:** CSRF, CORS mal configurado, IP de cliente falsificado. | | `transport` | `owasp` | **Segurança do canal:** configuração de TLS, HTTPS e texto puro, HSTS, pinning. | | `crypto` | `owasp`, `lovable` | **Criptografia em repouso:** algoritmos fracos ou caseiros, CSPRNG, gestão de chaves. | | `secrets` | `owasp`, `lovable` | **Credenciais hardcoded:** chaves, tokens e senhas escritos no código-fonte. | | `api-endpoint` | `owasp` | **Superfícies além do REST:** GraphQL, gRPC, autorização em WebSocket, DoS, schema. | | `payment` | `owasp`, `lovable` | **Fluxo de checkout:** verificação do gateway no servidor, callbacks assinados, idempotência. | | `xml` | `owasp` | **Parsing de XML:** XXE, entidades externas, expansão billion laughs. | | `csv` | `owasp` | **Formula injection:** células de planilha que começam com `=`/`+`/`-`/`@`. | | `container` | `owasp`, `infra` | **Configuração de contêineres:** root, capabilities, montagem do socket, hardening da imagem. | | `infra` | `infra` | **Infraestrutura como código:** Terraform, Dockerfile, GitHub Actions. | | `serverless` | `owasp`, `infra`, `lovable` | **Funções FaaS:** IAM de menor privilégio, entrada de eventos, contexto, segredos. | | `llm` | `ai`, `lovable` | **Riscos de IA e LLM:** prompt injection, agência, RAG, MCP, saída. | | `supabase` | `lovable` | **Backend Supabase:** RLS desligado por padrão, políticas mal geradas por IA, modelo de chaves. | | `browser` | `javascript`, `lovable` | **Riscos no cliente:** XSS, CSP, framing, armazenamento etc. | | `javascript` | `javascript` | **Riscos da linguagem:** RCE, prototype pollution etc. | | `python` | `python` | **Riscos da linguagem:** RCE por `pickle`, class pollution, `-O` etc. | | `rust` | `rust` | **Solidez do `unsafe`:** UB a partir de chamadores seguros, `transmute`, overflow. | | `java` | `java` | **Desserialização e código móvel:** cadeias de `readObject`, sequestro de objetos. | | `ruby` | `ruby` | **Desserialização e `open`:** revivência por `Marshal` e YAML, a peculiaridade do pipe. | | `php` | `php` | **Type juggling e `unserialize`:** magic hashes, POP chains. | | `go` | `go` | **Nil tipado e data races:** `nil != nil`, goroutines com memória compartilhada. | | `c-cpp` | `c-cpp` | **Format strings:** `printf(user_input)`, write-what-where com `%n`. | | `dotnet` | `dotnet` | **Riscos da plataforma:** RCE por `BinaryFormatter`, `@Html.Raw`, brechas em enums. | A maior parte do conhecimento nativo é destilada da OWASP. Veja as [**Fontes OWASP**](https://lagune.ai/pt-BR/docs/references/owasp-sources) para o mapeamento completo de cada especialização às páginas canônicas de ataque e de Cheat Sheet da OWASP. Alguns módulos específicos de uma stack se baseiam nas orientações do próprio fornecedor: o `supabase`, por exemplo, vem da documentação do Supabase e da CVE-2025-48757. ## As suas próprias especializações As nativas crescem com a adição de um arquivo de conhecimento e de uma linha no índice, nunca de um novo comando. Você adiciona as suas do mesmo jeito, com o [`/lagune-specialize`](https://lagune.ai/pt-BR/docs/commands/specialize): aponte para um artigo ou um tema e ele destila uma nova especialização no seu projeto, com o arquivo em `.lagune/catalog/` e a entrada dele em `.lagune/configs.json`. As suas sempre estão no catálogo, sejam quais forem as categorias dele, e uma especialização sua se sobrepõe a uma nativa de mesmo nome. **Internamente, o Lagune carrega as especializações automaticamente, sob demanda** Quando a fase detect ou verify encontra um contexto que uma especialização cobre, ela mesma carrega essa especialização com `read catalog `. Isso acontece automaticamente, como parte da fase. Você não precisa fazer nada à mão para que funcione. ## Descubra o que está disponível Para listar o catálogo do seu projeto no terminal, uma especialização por linha, com as tags dela: ```bash npx lagune read catalog # regex: Regular Expression [required] # network: Requests, Webhook, URL Fetch, Socket, IMDS, Redirect # interpreter: Evaluator, Sink, Shell, Dynamic Execution # ... ``` Uma especialização `[required]` sempre se aplica, seja qual for o trabalho. Quais nativas entram na lista depende das [**categorias**](https://lagune.ai/pt-BR/docs/categories) do seu projeto. **As especializações não são carregadas por padrão** O conhecimento relevante é trazido para o que o projeto realmente é, em vez de todas as verificações rodarem por padrão. ## Perguntas frequentes ### O que é uma especialização do Lagune? Um módulo de conhecimento de segurança focado e independente de linguagem, que carrega apenas sob demanda, nunca por padrão. Não é um comando como as skills do agente. ### O que é o catálogo de um projeto? As especializações que o projeto usa: as nativas das categorias dele, mais as próprias. Enquanto nenhuma categoria está registrada, ele usa apenas o OWASP. ### As especializações são carregadas por padrão? Não. Elas carregam apenas sob demanda, para o que o projeto realmente é. ### Como carregar uma especialização diretamente? No mesmo prompt da tarefa, peça ao seu agente para executar npx lagune read catalog . --- # /lagune-specialize: treine uma especialização de segurança com texto simples > Transforme uma fonte ou um tema de segurança que você fornecer em uma nova especialização sob demanda. Canônica: https://lagune.ai/pt-BR/docs/commands/specialize Idioma: pt-BR Original: https://lagune.ai/docs/commands/specialize Última atualização: 2026-11-03 🎓 Ensine ao **Lagune** uma nova especialização, a partir de uma fonte ou de um tema que você fornecer. Ele lê o material e o condensa em uma especialização focada e exclusivamente defensiva, com o mesmo formato das [nativas](https://lagune.ai/pt-BR/docs/catalog), para que as fases detect e verify a carreguem depois como qualquer outra. Ele só audita e explica: nunca escreve entradas de ataque nem exploits, e nunca mexe no seu código. **A partir de um artigo** ```prompt # Um link ou uma referência: o Lagune os transforma na defesa /lagune-specialize https://owasp.org/www-community/attacks/SQL_Injection ``` **A partir de um exploit** ```prompt # Um ataque como fonte: a especialização continua sendo a defesa /lagune-specialize "' OR 1=1 -- injeta SQL no texto da consulta" ``` **A partir de um tema** ```prompt # Ou apenas diga o que cobrir /lagune-specialize SQL injection ``` **Um ataque pode ser a fonte, nunca o resultado** Apontar para um ataque não tem problema quando o objetivo é se defender dele: o relato de um exploit é material de estudo que ele condensa na defesa. A especialização que ele produz sempre audita e explica, e nunca produz um exploit funcional, um payload ou uma técnica de evasão. ## O que ele grava O resultado são dois arquivos no seu projeto, versionados e revisáveis junto com o seu código: - A especialização em `.lagune/catalog/.md`, com o mesmo formato das [nativas](https://lagune.ai/pt-BR/docs/catalog). - A entrada dela em `.lagune/configs.json`, onde o seu projeto indexa as próprias especializações para o catálogo combiná-las com as nativas. Em seguida, ele lista o catálogo para confirmar que a nova entrada está lá. As suas próprias especializações estão sempre no catálogo, sejam quais forem as categorias dele. Você nunca adiciona um comando nem mexe no pacote: uma nova especialidade é um arquivo de conhecimento mais uma entrada no índice, gravados no seu próprio projeto. ## Refina, nunca sobrescreve Especializar um nome que já existe, seja uma nativa como `regex` ou uma que você especializou antes, **reconcilia** o arquivo atual em vez de substituí-lo. Ele lê o que está lá, incorpora o novo conhecimento, mantém o que continua válido e reescreve o que mudou. Nada é descartado sem ser lido. Uma especialização sua se sobrepõe a uma nativa de mesmo nome, então você pode aprimorar uma nativa para o seu próprio projeto sem perdê-la. **Dica** - A nova especialização carrega exatamente como uma nativa: as fases detect e verify a usam sob demanda, ou você mesmo a carrega com `npx lagune read catalog ` e lhe dá uma tarefa. - Quando o material tem uma origem identificável (um artigo, um autor, um link, um padrão), a especialização dá o crédito. Um tema solto não traz fonte. **Nota** **Ele só roda quando você o chama:** o agente nunca o inicia por conta própria. ## Perguntas frequentes ### Como adicionar uma especialização de segurança personalizada? Execute o /lagune-specialize com uma fonte ou um tema. Ele os condensa em uma especialização exclusivamente defensiva, gravada em .lagune/catalog/.md, mais a entrada dela em .lagune/configs.json. ### O Lagune consegue aprender com o relato de um exploit? Sim, como fonte, nunca como resultado. Um ataque pode ser a fonte, nunca o produto. O specialize nunca escreve entradas de ataque nem exploits. ### O specialize sobrescreve as especializações nativas? Não. Ele refina, nunca sobrescreve. --- # /lagune-prove: prova de conceito exclusivamente defensiva > Transforme cada achado detectado em uma prova de conceito (PoC) executável e exclusivamente defensiva, com um advisory para divulgação responsável. Canônica: https://lagune.ai/pt-BR/docs/commands/prove Idioma: pt-BR Original: https://lagune.ai/docs/commands/prove Última atualização: 2026-11-03 🧪 Transforme cada achado detectado em uma evidência executável e exclusivamente defensiva para divulgação responsável. Para cada achado do mapa do detect, ele escreve um advisory independente e um teste que verifica o **caminho seguro**, de modo que o teste falha enquanto o problema existe e passa assim que o código é corrigido. **Dica** Os testes do **Lagune** ficam isolados em `.lagune/`, separados da sua própria suíte. ## Como usar **Todos os achados** ```prompt /lagune-prove ``` **Um achado pelo nome** Veja os achados já rastreados pelo nome: ```prompt npx lagune read list --findings # Findings # ... # • SQL injection na busca de usuários # ... ``` ```prompt # Depois, prove um deles /lagune-prove SQL injection na busca de usuários ``` ## Como funciona Ele lê o código-fonte para o qual cada achado aponta e grava, em `.lagune/proofs/`, um diretório por achado comprovado, com exatamente dois arquivos: | Arquivo | O que é | | ----------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | | `report.test.mjs` (ou `.cjs`) | O teste. Ele roda no Poku quando o seu projeto já o usa e, caso contrário, no runner nativo do Node.js, então não precisa de nada instalado. | | `report.md` | Um advisory independente: severidade, impacto, como reproduzir e o comando para rodar, legível por si só. | As provas são sempre em JavaScript, então continuam portáveis seja qual for a linguagem do seu projeto. Um índice `README.md` traz o link de cada prova e um único comando para rodar todas. **Dica** - Ele é **opcional e autônomo**: não é uma das cinco fases nem faz parte da cadeia de rastreamento. - Ele grava apenas em `.lagune/proofs/` e nunca mexe nos artefatos das fases nem no seu código, que ele só lê. - Um achado cujo teste não reproduz o problema não recebe prova, e ele pede que você rode o [`/lagune-detect`](https://lagune.ai/pt-BR/docs/commands/detect) naquele ponto para reconciliar. - Rodar de novo reconcilia as provas: um achado que sumiu ou que não se reproduz mais tem o diretório removido. **Nota** **Ele só roda quando você o chama:** o agente nunca o inicia por conta própria. **Depende do detect** O prove lê o mapa do detect gerado pelo [`/lagune-detect`](https://lagune.ai/pt-BR/docs/commands/detect), então rode o detect primeiro. ## Só defesa, e com autorização Antes de gerar qualquer coisa, ele confirma que você tem autorização para testar o alvo e recusa qualquer pedido de exploit funcional, payload de ataque ou técnica para escapar da detecção. Uma prova demonstra o comportamento seguro e nunca emite uma entrada de ataque. ## Da prova à divulgação Os dois arquivos de cada achado comprovado vão juntos em um **GitHub Gist privado** para relatar a vulnerabilidade. Eles são evidência de um problema ativo e ainda não divulgado, então um `.gitignore` dentro de `.lagune/proofs/` os mantém fora de todos os commits: compartilhe-os apenas por esse Gist até que os mantenedores resolvam o problema. Encerrar um achado na cadeia do **Lagune** continua sendo trabalho do [`/lagune-harden`](https://lagune.ai/pt-BR/docs/commands/harden) e do [`/lagune-verify`](https://lagune.ai/pt-BR/docs/commands/verify): o prove produz evidências, mas não encerra nada. ## Perguntas frequentes ### O Lagune gera exploits? Não. O /lagune-prove escreve evidências exclusivamente defensivas: um teste que verifica o caminho seguro, de modo que falha enquanto o problema existe e passa assim que o código é corrigido, mais um advisory para divulgação responsável. ### O que o prove gera? Dois arquivos por achado: um teste (report.test.mjs ou .cjs) e um advisory (report.md). ### Como divulgar de forma responsável uma falha que o Lagune encontrou? O prove escreve um advisory independente que você pode compartilhar por um canal privado, como um GitHub Gist privado, seguindo a divulgação responsável. --- # Hook agent: detecte loops de agente sem limite > Varra um código em busca de chamadas a agentes e LLMs sem limite de passos ou de tempo, ou avalie uma única chamada, direto da linha de comando. Canônica: https://lagune.ai/pt-BR/docs/hooks/agent Idioma: pt-BR Original: https://lagune.ai/docs/hooks/agent Última atualização: 2026-11-03 O hook `agent` sinaliza **runtimes de agente que entram em loop sem limite de turnos, de orçamento ou de tempo**, a brecha de autonomia descontrolada que transforma uma entrada manipulada em custo ilimitado ou em escalada de prompt injection. Ele **reconhece a linguagem** e cobre os dois ecossistemas de frameworks de agentes: **JavaScript** (o runtime `query` do SDK de agentes do **Claude**) e **Python** (**LangChain**, **LangGraph**, **CrewAI**, **OpenAI Agents**). Ele é o engine determinístico por trás da [especialização `llm`](https://lagune.ai/pt-BR/docs/catalog), e você mesmo pode executá-lo no modo **scan** ou **check**. ## Como executar **Varrer o código** ```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 ``` **Verificar uma chamada** ```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 linha em **Uncapped agent loops found** é, em um arquivo que importa um SDK de agentes, ou o runtime `query` do SDK de agentes do Claude chamado sem limite de turnos, de orçamento ou de tempo (JavaScript, sem limite por padrão), ou a remoção explícita do limite padrão de um framework, como `max_iterations=None` / `max_turns=None` (Python, com limite por padrão). Qualquer um dos dois termina com código diferente de zero. No Vercel AI SDK, `generateText`/`streamText` usam por padrão um único passo (`stopWhen: stepCountIs(1)`), então uma chamada simples ali não entra em loop e não é sinalizada, e um `db.query(...)` comum nunca é confundido com uma chamada de agente. Uma execução sem achados imprime `no uncapped agent loops found`. ## Como ler o veredito | Veredito | Significado | | ---------- | ------------------------------------------------------------------------------------------------------------------------ | | `uncapped` | Uma chamada ao runtime `query` sem limite (JS), ou a remoção explícita de um limite (`=None`, Py). | | `safe` | Uma chamada `query` que define um limite, uma geração de passo único ou a chamada de um framework com limite por padrão. | | `invalid` | O trecho não contém nenhuma chamada de agente reconhecível para avaliar. | ### Opções da CLI | Opção | Valor | Descrição | | ----------- | ------------------- | ------------------------------------------------------------------------------------ | | `--pattern` | um trecho de código | Verifica uma chamada. Repita para verificar várias, com um veredito por linha. | | `--lang` | uma linguagem | Obrigatória com `--pattern`: `javascript` ou `python`. | | `--dir` | um diretório | Restringe a varredura a um diretório. Pode ser repetida e combinada com `--file`. | | `--file` | um arquivo | Restringe a varredura a um único arquivo. Pode ser repetida e combinada com `--dir`. | Sem nenhuma opção, ele varre o projeto inteiro. `--pattern` exige `--lang` e não pode ser combinada com `--dir` nem com `--file`. **Melhor esforço, não exaustivo** Um loop de agente feito à mão, em qualquer linguagem, está além do alcance de uma varredura estática. Trate isso como uma base sólida, não como um inventário completo. **Dica** O hook decide apenas o limite: o escopo de capacidades, a mistura de níveis de confiança e a autorização são questões de julgamento que a [especialização `llm`](https://lagune.ai/pt-BR/docs/catalog) continua cobrindo. ## Perguntas frequentes ### Por que limitar o loop de um agente? Um agente sem limite pode ser levado a recursão, custo ou escalada de prompt injection sem fim. Definir maxTurns/maxBudgetUsd/stopWhen/signal impõe esse limite, e o hook agent sinaliza uma chamada ao runtime query que não define nenhum deles. --- # Hook cors: audite as origens de CORS > Varra o código-fonte em busca de uma allowlist de origens CORS contornável, ou avalie se um único valor de origem dá acesso permissivo demais, direto da linha de comando. Canônica: https://lagune.ai/pt-BR/docs/hooks/cors Idioma: pt-BR Original: https://lagune.ai/docs/hooks/cors Última atualização: 2026-11-03 O hook `cors` é o engine determinístico por trás da [especialização `http-request`](https://lagune.ai/pt-BR/docs/catalog), e você mesmo pode executá-lo. Ele funciona em dois modos a partir de um único comando: um **scan**, que varre o código-fonte em busca de uma **allowlist de origens contornável** (uma regex de validação de host pela qual o host de um atacante passa), e um **score**, que classifica um único valor de **origem CORS** como `wildcard`, `null` ou `safe`. ## Varrer um código Sem nenhuma flag, ele varre o projeto inteiro. **Projeto inteiro** ```bash npx lagune read cors ``` **Um diretório** ```bash npx lagune read cors --dir src/server ``` **Um único arquivo** ```bash npx lagune read cors --file internal/auth/origin.go ``` Ele lista cada allowlist contornável sob um único cabeçalho, agrupada por arquivo. Um validador de host cujo `.+`/`.*` fica no segmento de autoridade antes do sufixo do host confiável (`^https?://.+\.trusted\.com`) deixa passar o host de um atacante como `your-site.com.attacker.com`. ```text Origin-allowlist patterns with a greedy wildcard (bypassable, review): internal/auth/origin.go ^https?://.+\.trusted\.com ``` Isso é uma pista para revisão, não um achado fechado: pelo texto, não dá para decidir se a regex controla uma decisão de confiança real, então um scan nunca altera o código de saída. Leia cada uma e confirme que a allowlist compara por igualdade completa. Quando nada é encontrado, ele imprime uma única linha. ```bash npx lagune read cors --dir src/clean # => no bypassable origin allowlist found ``` ## Avaliar uma origem Passe cada origem com `--origin`. O hook imprime uma palavra por origem e termina com código diferente de zero diante de qualquer `wildcard` ou `null`. **Uma origem** ```bash npx lagune read cors --origin '*' # => wildcard npx lagune read cors --origin 'null' # => null npx lagune read cors --origin 'https://app.example.com' # => safe ``` **Várias origens** Repita `--origin` para avaliar uma allowlist inteira em uma única chamada, com um veredito por linha, na ordem. ```bash npx lagune read cors \ --origin 'https://app.example.com' \ --origin '*' \ --origin 'null' # => safe # => wildcard # => null ``` | Veredito | Significado | | ---------- | ------------------------------------------------------------------------------------------------------- | | `safe` | Não é `*`, `null` nem um glob com `*`. Não garante uma origem bem formada. | | `wildcard` | `*`, ou um glob de subdomínio, host ou porta: qualquer site (ou um conjunto amplo) pode ler a resposta. | | `null` | A origem `null`, que iframes em sandbox e redirecionamentos conseguem forjar. | Só `safe` é uma permissão, e `--origin` é um oráculo de valores: ele julga o valor, não o handler, então confirme o handler com a especialização `http-request`. ### Opções da CLI | Opção | Valor | Descrição | | ---------- | ------------ | ------------------------------------------------------------------------------------ | | `--origin` | uma origem | Avalia um valor de origem. Repita para avaliar vários, um por linha. | | `--dir` | um diretório | Restringe a varredura a um diretório. Pode ser repetida e combinada com `--file`. | | `--file` | um arquivo | Restringe a varredura a um único arquivo. Pode ser repetida e combinada com `--dir`. | Sem nenhuma opção, ele varre o projeto inteiro. `--origin` é o modo score e não pode ser combinada com `--dir` nem com `--file`. **O que ele não cobre** O scan lê o formato de **regex contornável**, e `--origin` avalia **valores** de origem. Dois padrões no nível do código-fonte ficam fora de alcance: o reflexo do `Origin` da requisição (o servidor devolve o `Origin` recebido, ou o combina com credenciais) e uma allowlist permissiva por `endsWith` ou por substring. Reconheça esses padrões no código e trate-os como a [especialização `http-request`](https://lagune.ai/pt-BR/docs/catalog) descreve. ## Perguntas frequentes ### Por que uma origem CORS null é perigosa? Iframes em sandbox e alguns redirecionamentos enviam Origin: null, então uma allowlist que confia em null dá acesso de leitura a esses contextos. O hook cors a sinaliza junto com o wildcard. ### Como detectar uma allowlist de origens CORS contornável? Execute npx lagune read cors sobre o código. Ele sinaliza uma regex de validação de host cujo wildcard guloso fica antes do sufixo confiável, de modo que o host de um atacante como your-site.com.attacker.com passa por ela. --- # Hook crypto: detecte criptografia fraca > Varra um código em busca de primitivas criptográficas fracas, ou avalie um único trecho, direto da linha de comando. Canônica: https://lagune.ai/pt-BR/docs/hooks/crypto Idioma: pt-BR Original: https://lagune.ai/docs/hooks/crypto Última atualização: 2026-11-03 O hook `crypto` sinaliza **primitivas criptográficas fracas** no ponto da chamada: uma cifra obsoleta, um modo inseguro ou um digest quebrado. Ele **reconhece a linguagem**, lendo cada arquivo pelas regras dela, para que uma construção de Python nunca seja sinalizada em um arquivo Rust, e é o engine determinístico por trás da [especialização `crypto`](https://lagune.ai/pt-BR/docs/catalog), que você mesmo pode executar no modo **scan** ou **check**. ## Como executar **Varrer o código** ```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 ``` **Verificar um trecho** ```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 ``` O scan imprime até duas seções. **Weak cryptography found** é o conjunto de achados (DES, 3DES, RC4, Blowfish, RC2 e o modo ECB): cada um é uma primitiva de cifra quebrada, então o hook termina com código diferente de zero. **Cryptography to review manually** é um conjunto de pistas que ele não consegue julgar sozinho: um digest MD5 ou SHA-1 (quebrado para uso em segurança, mas legítimo como simples checksum, então a intenção decide), um RNG não criptográfico em um contexto de segurança ou uma comparação vulnerável a timing. Uma execução sem achados imprime `no weak cryptography found`. ## Como ler o veredito | Veredito | Significado | | --------- | ----------------------------------------------------------------------------------------------------------------------- | | `weak` | O trecho usa uma primitiva de cifra quebrada (DES ou 3DES, RC4, Blowfish, RC2 ou o modo ECB). | | `review` | Uma primitiva que depende da intenção: um digest MD5 ou SHA-1, ou um RNG não criptográfico em um contexto de segurança. | | `safe` | O trecho usa criptografia e nenhuma primitiva fraca foi encontrada. | | `invalid` | O trecho não contém nenhuma construção criptográfica reconhecível para avaliar. | ### Opções da CLI | Opção | Valor | Descrição | | ----------- | ------------------- | ----------------------------------------------------------------------------------------------------- | | `--pattern` | um trecho de código | Verifica um trecho. Repita para verificar vários, com um veredito por linha. | | `--lang` | uma linguagem | Obrigatória com `--pattern`: javascript, python, go, java, kotlin, php, ruby, rust, csharp, c ou cpp. | | `--dir` | um diretório | Restringe a varredura a um diretório. Pode ser repetida e combinada com `--file`. | | `--file` | um arquivo | Restringe a varredura a um único arquivo. Pode ser repetida e combinada com `--dir`. | Sem nenhuma opção, ele varre o projeto inteiro. `--pattern` exige `--lang` e não pode ser combinada com `--dir` nem com `--file`. ### Linguagens suportadas O scan lê estas linguagens, identificadas pela extensão do arquivo, e verifica cada uma contra as próprias APIs criptográficas. | Linguagem | Cifras fracas (achado) e digests ou RNG (revisão) | | --------------------------- | ---------------------------------------------------------------------------------------------------------------- | | **JavaScript / TypeScript** | `createCipher`, `CryptoJS.DES/RC4`, `*-ecb` entre aspas; 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()` | **Melhor esforço, não exaustivo** Ele lê o código-fonte como texto, então uma primitiva montada em tempo de execução, escondida atrás de um alias ou escrita de uma forma que ele não reconhece pode passar despercebida. Trate a tabela como um ponto de partida sólido, não como um inventário completo. **Dica** O hook garante a base (essas construções existem): a gestão de chaves, a reutilização de IV e o padding de RSA são questões de julgamento que a [especialização `crypto`](https://lagune.ai/pt-BR/docs/catalog) continua cobrindo. ## Perguntas frequentes ### Como varrer um código em busca de criptografia fraca? Execute o hook crypto sem nenhuma flag. Cifras quebradas e o modo ECB são achados que terminam com código diferente de zero. Um digest MD5/SHA-1 é uma pista para revisão, já que é quebrado para uso em segurança, mas legítimo como simples checksum. ### O hook crypto sinaliza Math.random()? Só como pista para revisão em um contexto de segurança, nunca como achado automático, já que a aleatoriedade é legítima para jitter ou para a ordenação de elementos na interface. --- # Hook cvss: calcule a nota de um vetor CVSS v4.0 > Calcule a nota de um ou de vários vetores CVSS v4.0 pela linha de comando, com a mesma aritmética da calculadora da FIRST, e leia cada um em palavras simples. Canônica: https://lagune.ai/pt-BR/docs/hooks/cvss Idioma: pt-BR Original: https://lagune.ai/docs/hooks/cvss Última atualização: 2026-11-03 O hook `cvss` calcula a nota de um **vetor CVSS v4.0** e imprime a nota e a faixa de severidade, a classificação que o [`/lagune-plan`](https://lagune.ai/pt-BR/docs/commands/plan) registra em cada correção e o [`/lagune-prove`](https://lagune.ai/pt-BR/docs/commands/prove) em cada advisory. Ele é o engine determinístico por trás dessas classificações, com a mesma aritmética da [calculadora da FIRST](https://www.first.org/cvss/calculator/4.0), e você mesmo pode executá-lo. ## Como executar Passe cada vetor com `--vector`. O hook imprime uma linha por vetor, com a nota e a faixa dele. **Um vetor** ```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 ``` **Vários vetores** Repita `--vector` para calcular vários de uma vez, com uma linha para cada um, na ordem. ```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 ``` **Em palavras simples** Adicione `--explain` para ler cada métrica em palavras simples. Quando as métricas de Threat ou Environmental mudam a nota, a nota Base sozinha aparece primeiro. ```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 # => ... ``` ## Como ler o resultado | Faixa | Nota | | ---------- | ---------- | | `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 | Um vetor só com métricas Base avalia a falha em si, presumindo o pior: todos os requisitos de segurança em High e a falha sendo explorada na prática. As métricas Environmental (`MAV` e as demais métricas modificadas, além de `CR`, `IR` e `AR`) ajustam a nota para uma implantação específica, e a métrica Threat (`E`), para o que se sabe sobre a exploração. Um vetor inválido imprime `invalid vector:` e o que está errado, e o hook termina com código diferente de zero. ### Opções da CLI | Opção | Valor | Descrição | | ----------- | ------------------- | ------------------------------------------------------------------------------------------- | | `--vector` | um vetor `CVSS:4.0` | Calcula a nota de um vetor. Repita para calcular vários, com uma linha por vetor, na ordem. | | `--explain` | | Adiciona cada métrica em palavras simples abaixo de cada linha de classificação. | É obrigatório passar pelo menos um `--vector`. O vetor nunca é um argumento posicional solto, então não pode ser confundido com uma flag. **Por que o valor de uma flag** Cada vetor é passado como o valor de uma flag, nunca interpolado no comando. Um valor com aspas ou crases continua inerte e não consegue fazer injeção no shell. Sempre coloque o vetor entre aspas simples para que o seu shell não o expanda antes. **O que ele não cobre** Apenas CVSS v4.0: um vetor v2.0, v3.0 ou v3.1 é rejeitado em vez de avaliado, já que o **Lagune** classifica todos os achados em v4.0. **Dica** A validação da fase plan refaz essa mesma aritmética em cada linha de CVSS, então uma nota que se desviou do seu vetor é detectada antes de o plano ser aceito. ## Perguntas frequentes ### Como o Lagune calcula uma nota CVSS? O hook cvss segue a calculadora de referência da FIRST para o CVSS v4.0, então um vetor recebe exatamente a mesma nota que receberia no site da FIRST. ### Dá para calcular a nota de um vetor CVSS v3.1 com ele? Não. O Lagune classifica todos os achados em CVSS v4.0, e o hook rejeita qualquer outra versão em vez de calculá-la. ### O que a flag --explain faz? Ela lê cada métrica em palavras simples e mostra a nota Base ao lado da nota geral, para que qualquer pessoa veja o que o vetor diz e como o contexto do projeto o alterou. --- # Hook infra: detecte erros de configuração em IaC > Varra arquivos Terraform, Dockerfiles e GitHub Actions em busca de erros de configuração, ou avalie um único trecho, direto da linha de comando. Canônica: https://lagune.ai/pt-BR/docs/hooks/infra Idioma: pt-BR Original: https://lagune.ai/docs/hooks/infra Última atualização: 2026-11-03 O hook `infra` sinaliza **erros de configuração em infraestrutura como código** que dá para decidir só pelo arquivo: uma rede aberta para o mundo, uma permissão curinga, um segredo em um manifesto, um contêiner rodando como root, um valor não confiável em um shell de CI. Ele lê apenas arquivos de IaC (`.tf`/`.tf.json`/`.hcl`, `Dockerfile*`, `.github/workflows/**`). É o engine determinístico por trás da [especialização `infra`](https://lagune.ai/pt-BR/docs/catalog), no modo **scan** ou **check**. ## Como executar **Varrer o código** ```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 ``` **Verificar um trecho** Passe o trecho com `--pattern` e o tipo dele com `--kind` (`terraform`, `dockerfile` ou `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 ``` A varredura imprime até duas seções. **Infrastructure risks found** termina com código de saída diferente de zero e reúne os defeitos decidíveis (um ingress `0.0.0.0/0` em uma porta sensível, uma declaração IAM curinga, um segredo em manifesto, `encrypted = false`, um módulo git sem versão fixada, uma imagem que roda explicitamente como root, um `curl | sh`, uma injeção de script em CI, `permissions: write-all`). **Infrastructure hardening advisories** não altera o código de saída (uma tag de imagem base mutável, uma action fixada por tag). Uma execução sem achados imprime `no infrastructure risks found`. ## Como ler o veredito O modo check imprime a tag de maior severidade que encontrou (por exemplo, `public-ingress`, `iam-wildcard`, `root-user`, `curl-pipe`, `script-injection`, `write-all`), uma tag de alerta (`mutable-tag`, `unpinned-action`) ou `safe`. Só uma tag com severidade de achado termina com código de saída diferente de zero. ### Opções da CLI | Opção | Valor | Descrição | | ----------- | ----------------------------------------------- | --------------------------------------------------------------------------------- | | `--pattern` | um trecho | Verifica um trecho. Exige `--kind`. Repita para verificar vários. | | `--kind` | `terraform` \| `dockerfile` \| `github-actions` | O tipo pelo qual o trecho é julgado. | | `--dir` | um diretório | Limita a varredura a um diretório. Pode ser repetida e combinada com `--file`. | | `--file` | um arquivo | Limita a varredura a um único arquivo. Pode ser repetida e combinada com `--dir`. | Sem nenhuma opção, ele varre todos os arquivos de IaC do projeto. `--pattern` não pode ser combinado com `--dir` nem com `--file`. **Dica** O hook pega os casos evidentes e decidíveis: a ausência de criptografia, a exposição de `pull_request_target` e o escopo certo de IAM são julgamentos que a [especialização `infra`](https://lagune.ai/pt-BR/docs/catalog) continua cobrindo. ## Perguntas frequentes ### Quais arquivos de infraestrutura o hook infra lê? Terraform/HCL (.tf, .tf.json, .hcl), Dockerfiles e os YAML de workflows e actions do GitHub Actions dentro de .github/. Ele alcança esses arquivos mesmo que os scanners de código-fonte os ignorem. --- # Hook interpreter: sinalize pontos de execução dinâmica de código > Varra um código em busca de pontos de execução dinâmica de código em várias linguagens, ou avalie um único trecho, direto da linha de comando. Canônica: https://lagune.ai/pt-BR/docs/hooks/interpreter Idioma: pt-BR Original: https://lagune.ai/docs/hooks/interpreter Última atualização: 2026-11-03 O hook `interpreter` sinaliza **pontos de execução dinâmica de código** (sinks): construções que transformam dados em código em execução ou os entregam a um shell, de `eval` à desserialização nativa. Ele reconhece a linguagem e lê cada arquivo pelas regras dela, e é o engine determinístico por trás da [especialização `interpreter`](https://lagune.ai/pt-BR/docs/catalog), que você mesmo pode executar no modo **scan** ou **check**. ## Como executar **Varrer o código** ```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 ``` **Verificar um trecho** ```bash npx lagune read interpreter --lang javascript --pattern 'eval(x)' # => careful npx lagune read interpreter --lang python --pattern 'json.loads(x)' # => safe ``` Esses sinks têm uso duplo: uma varredura estática não consegue decidir se uma entrada influenciada por um atacante chega até eles, então cada ocorrência é um **alerta para revisar**, nunca um achado confirmado. A varredura imprime uma única seção, **Dynamic-execution sinks to review**, agrupada por arquivo. Uma execução sem achados imprime `no dynamic-execution sinks found`. **Leia o código sinalizado, nunca o execute!** Analise cada sink de forma **estática**, rastreando se uma entrada não confiável chega até ele. Nunca execute nem passe por `eval` o código sinalizado, nem qualquer código remoto ou baixado em tempo de execução que ele traga, para "testar" o que ele faz. ## Como ler o veredito | Veredito | Significado | | --------- | ------------------------------------------------------------------------------------------------------ | | `careful` | O trecho contém um ponto de execução dinâmica para a linguagem dele. Revise-o lendo, nunca executando. | | `safe` | Nenhum ponto de execução dinâmica foi encontrado para a linguagem informada. | ### Opções da CLI | Opção | Valor | Descrição | | ----------- | ------------------- | ----------------------------------------------------------------------------------------------------- | | `--pattern` | um trecho de código | Verifica um trecho. Repita para verificar vários, com um veredito por linha. | | `--lang` | uma linguagem | Obrigatória com `--pattern`: javascript, python, php, ruby, java, kotlin, go, rust, c, cpp ou csharp. | | `--dir` | um diretório | Limita a varredura a um diretório. Pode ser repetida e combinada com `--file`. | | `--file` | um arquivo | Limita a varredura a um único arquivo. Pode ser repetida e combinada com `--dir`. | Sem nenhuma opção, ele varre o projeto inteiro. `--pattern` exige `--lang` e não pode ser combinado com `--dir` nem com `--file`. ### Linguagens suportadas A varredura lê estas linguagens, identificadas pela extensão do arquivo, e confere cada uma com o próprio conjunto de pontos de execução dinâmica. | # | Linguagem | Extensões | Sinks que ela sinaliza | | --- | --------------------------- | ------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1 | **JavaScript / TypeScript** | `.js`, `.jsx`, `.mjs`, `.cjs`, `.ts`, `.tsx`, `.mts`, `.cts`, `.astro`, `.vue`, `.svelte`, `.marko`, `.riot` | `eval()`, construtor Function, `setTimeout`/`setInterval` com corpo em string, 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` com `shell=True`, `pickle.load`/`loads`, `yaml.load` (inseguro) | | 3 | **Ruby** | `.rb` | família eval (`instance_eval`/`class_eval`/`module_eval`/`eval`), `system`/`exec`, crases ou `%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()` com string, `create_function()`, execução de shell (`system`/`exec`/`shell_exec`/`passthru`/`popen`/`proc_open`), `call_user_func`/`call_user_func_array`, `include`/`require` com caminho definido em tempo de execução | | 6 | **Rust** | `.rs` | `Command::new`, `process::Command` | | 7 | **Java** | `.java` | `Runtime.exec`, `ProcessBuilder`, `ScriptEngine`, `ObjectInputStream.readObject` | | 8 | **Kotlin** | `.kt`, `.kts` | Os sinks da JVM: `Runtime.exec`, `ProcessBuilder`, `ScriptEngine`, `ObjectInputStream.readObject` | | 9 | **C#** | `.cs` | `Process.Start` / `new Process`, `BinaryFormatter`, `Assembly.Load` | | 10 | **C** | `.c`, `.h` | `system()`, `popen()`, a família `exec*` (`execl`, `execve`, `execvp`, …) | | 11 | **C++** | `.cc`, `.cpp`, `.cxx`, `.hpp`, `.hh`, `.hxx` | `system()`, `popen()`, a família `exec*` (`execl`, `execve`, `execvp`, …) | **Melhor esforço, não exaustivo** Ele lê o código-fonte como texto, então um sink montado em tempo de execução, escondido atrás de um alias ou escrito de uma forma que ele não reconhece pode passar despercebido. Trate a tabela como um ponto de partida sólido, não como um inventário completo. **Dica** O hook garante o mínimo (que esses sinks existem e onde estão): saber se um valor não confiável realmente chega a um deles é o julgamento que a [especialização `interpreter`](https://lagune.ai/pt-BR/docs/catalog) cobre. ## Perguntas frequentes ### O hook interpreter confirma uma vulnerabilidade? Não. Ele sinaliza pontos de execução dinâmica como um alerta para revisar, nunca como um achado confirmado, porque uma varredura estática não consegue decidir se uma entrada influenciada por um atacante chega até eles. ### Quais linguagens o hook interpreter cobre? Ele lê as linguagens da tabela de linguagens suportadas, identificadas pela extensão do arquivo, e confere cada uma com o próprio conjunto de sinks. Outras linguagens não geram sinks. --- # Hook jwt: detecte verificação de JWT sem algoritmo fixado > Varra um código em busca de verificações de JWT sem algoritmo fixado, ou avalie uma única chamada, direto da linha de comando. Canônica: https://lagune.ai/pt-BR/docs/hooks/jwt Idioma: pt-BR Original: https://lagune.ai/docs/hooks/jwt Última atualização: 2026-11-03 O hook `jwt` sinaliza **verificações de JWT sem algoritmo fixado**, a brecha de algorithm confusion em que o verificador confia no próprio cabeçalho `alg` do token, e **verificações desativadas por completo**. Ele **reconhece a linguagem** e lê cada arquivo pela biblioteca de JWT dela, e é o engine determinístico por trás da [especialização `federation`](https://lagune.ai/pt-BR/docs/catalog), que você mesmo pode executar no modo **scan** ou **check**. ## Como executar **Varrer o código** ```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 ``` **Verificar uma chamada** ```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 linha em **Unpinned JWT verification found** é uma chamada de verificação que não define uma allowlist de `algorithms` (quando a biblioteca precisa de uma), aceita uma insegura (`none`, ou um algoritmo assimétrico misturado com HMAC) ou desativa de vez a checagem da assinatura, e por isso confia no próprio `alg` do token. É uma exposição confirmada, então o hook termina com código de saída diferente de zero. Uma execução sem achados imprime `no unpinned JWT verification found`. ## Como ler o veredito | Veredito | Significado | | ---------- | ----------------------------------------------------------------------------------------------------------------------------------------- | | `unpinned` | Uma chamada de verificação sem allowlist de algoritmos (quando é necessária), com uma allowlist insegura ou com a verificação desativada. | | `safe` | Uma chamada de verificação que fixa uma allowlist de algoritmos sólida, ou cuja biblioteca a fixa implicitamente. | | `invalid` | O trecho não contém nenhuma chamada de verificação reconhecível para julgar. | ### Opções da CLI | Opção | Valor | Descrição | | ----------- | ------------------- | --------------------------------------------------------------------------------------------- | | `--pattern` | um trecho de código | Verifica uma chamada. Repita para verificar várias, com um veredito por linha. | | `--lang` | uma linguagem | Obrigatória com `--pattern`: javascript, python, go, java, kotlin, php, ruby, rust ou csharp. | | `--dir` | um diretório | Limita a varredura a um diretório. Pode ser repetida e combinada com `--file`. | | `--file` | um arquivo | Limita a varredura a um único arquivo. Pode ser repetida e combinada com `--dir`. | Sem nenhuma opção, ele varre o projeto inteiro. `--pattern` exige `--lang` e não pode ser combinado com `--dir` nem com `--file`. ### Linguagens suportadas A varredura lê estas bibliotecas, identificadas pela extensão do arquivo. Como algumas fixam o algoritmo implicitamente (a falta de uma lista explícita é segura), a regra "sem allowlist ⇒ unpinned" só vale onde a biblioteca espera uma lista explícita, então uma chamada configurada corretamente nunca é sinalizada. | Linguagem | Biblioteca | Sinaliza a falta de allowlist como unpinned? | Sempre sinaliza | | --------------------------- | ----------------------- | ------------------------------------------------------------------- | ----------------------------------------------- | | **JavaScript / TypeScript** | jsonwebtoken, jose | Sim | `none`, mistura de assimétrico com HMAC | | **Python** | PyJWT, python-jose | Sim (o PyJWT exige, o python-jose usa `algorithms=None` por padrão) | `none`, `verify_signature: False` | | **Go** | golang-jwt | Sim (sem `WithValidMethods`) | `none`, `ParseUnverified` | | **Ruby** | ruby-jwt | Sim | `none`, `verify = false` | | **Java / Kotlin** | jjwt, nimbus | Não (derivado da chave) | `none`, um parser sem assinatura ou `unsecured` | | **PHP** | firebase/php-jwt | Não (a `Key` carrega o alg) | `none` | | **Rust** | jsonwebtoken | Não (a `Validation` exige um) | `none`, `insecure_disable_signature_validation` | | **C#** | Microsoft.IdentityModel | Não (parâmetros em várias linhas) | `none`, `RequireSignedTokens = false` | **Dica** O hook decide apenas a fixação do algoritmo: as verificações de claims, de chaves e do fluxo são julgamentos que a [especialização `federation`](https://lagune.ai/pt-BR/docs/catalog) continua cobrindo. ## Perguntas frequentes ### O que é algorithm confusion em JWT? Um verificador que lê o algoritmo do cabeçalho do token permite que um atacante troque RS256 por HS256 e assine com a chave pública. Fixar no código uma allowlist de algoritmos sólida impede isso, e o hook jwt sinaliza uma chamada de verificação que define none ou uma allowlist insegura. --- # Hook network: avalie URLs contra SSRF > Avalie um ou vários destinos de requisição contra SSRF, direto da linha de comando. Canônica: https://lagune.ai/pt-BR/docs/hooks/network Idioma: pt-BR Original: https://lagune.ai/docs/hooks/network Última atualização: 2026-11-03 O hook `network` decide se um destino de requisição feita pelo servidor está protegido contra **SSRF** (uma requisição que pode ser direcionada a serviços internos, metadados da nuvem ou hosts privados). É o engine determinístico por trás da [especialização `network`](https://lagune.ai/pt-BR/docs/catalog), e você mesmo pode executá-lo. ## Como executar Passe cada destino com `--url`. O hook imprime uma palavra por destino, explicada na tabela abaixo. **Um destino** ```bash npx lagune read network --url 'http://example.com/' # => safe npx lagune read network --url 'http://0x7f000001/' # => private-target ``` **Vários destinos** Repita `--url` para avaliar uma allowlist ou denylist inteira em uma só chamada, com um veredito por linha, na mesma ordem. ```bash npx lagune read network \ --url 'http://example.com/' \ --url 'http://[::1]/' \ --url 'http://allowed.com@evil.example/' # => safe # => private-target # => parser-divergent ``` Ele resolve o host do mesmo jeito que a rede, então as formas codificadas de um endereço interno não passam despercebidas: hexadecimal, octal, decimal sem pontos, abreviada, IPv6 e IPv4 mapeado em IPv6 resultam todas em `private-target`. E quando um validador descuidado e o cliente que faz a requisição leriam hosts diferentes, o veredito é `parser-divergent`. ## Como ler o veredito | Veredito | Significado | | ------------------ | ------------------------------------------------------------------------------------------------------------ | | `safe` | O destino se conecta a um host público, e um validador descuidado leria o mesmo host. | | `private-target` | O host resolve para um endereço privado, de loopback, link-local, não especificado ou de metadados da nuvem. | | `parser-divergent` | Um validador de texto descuidado leria um host real diferente daquele ao qual o cliente se conecta. | | `invalid url` | A string não pode ser interpretada como URL, então não há nada para buscar. | Só `safe` significa permitir. Trate `private-target`, `parser-divergent` e `invalid url` como bloqueio. ### Opções da CLI | Opção | Valor | Descrição | | ------- | ------------------ | ----------------------------------------------------------------------------- | | `--url` | uma URL ou um host | Verifica um destino. Repita para verificar vários, com um veredito por linha. | É obrigatório informar pelo menos um `--url`. O destino nunca é um argumento posicional solto, então não tem como ser confundido com uma flag. **Por que passar como flag** Cada destino é passado como valor de uma flag, nunca interpolado no comando. Um valor com aspas ou crases continua inerte e não consegue injetar nada no shell. Sempre coloque o valor entre aspas simples para que o seu shell não o expanda antes. **O que ele não cobre** O hook é puro e nunca resolve DNS, então duas lacunas de tempo de execução ficam fora do escopo: o **DNS rebinding** (um nome que resolve para um endereço público na verificação e para um interno na requisição) e as **cadeias de redirecionamento** (um primeiro salto que passa e depois redireciona para dentro). Feche essas lacunas resolvendo o nome uma única vez e se conectando ao endereço validado, e recusando redirecionamentos. Ele fixa os nomes de loopback reservados (`localhost` e a família `.localhost`) como internos sem nenhuma consulta, mas qualquer outro nome DNS resulta em `safe`, porque afirmar que ele resolve para dentro exigiria a resolução: quem protege esses nomes é a allowlist, e é ela que este verificador valida. **Dica** Esta é a mesma verificação que a [especialização `network`](https://lagune.ai/pt-BR/docs/catalog) executa para comprovar que um filtro de destinos se sustenta. ## Perguntas frequentes ### Como testar uma URL contra SSRF? Execute o hook network. Ele avalia um destino de requisição e retorna safe, private-target, parser-divergent ou invalid url. Só safe significa permitir. ### O que é uma URL parser-divergent? Uma URL que parsers diferentes leem de formas diferentes, o que é um bypass clássico de SSRF. O hook network a sinaliza em vez de permiti-la. --- # Hook regex: detecte padrões vulneráveis a ReDoS > Varra um código em busca de regex vulneráveis a ReDoS, ou avalie um único padrão, direto da linha de comando. Canônica: https://lagune.ai/pt-BR/docs/hooks/regex Idioma: pt-BR Original: https://lagune.ai/docs/hooks/regex Última atualização: 2026-11-03 O hook `regex` é o engine determinístico de segurança de regex que a [especialização `regex`](https://lagune.ai/pt-BR/docs/catalog) executa, e você mesmo pode executá-lo. Ele funciona em dois modos a partir de um único comando: um **scan**, que varre um código em busca de padrões vulneráveis a **ReDoS** e de padrões montados em tempo de execução, e um **check**, que avalia um único padrão que você passar. ## Varrer um código Sem nenhuma flag, ele varre o projeto inteiro. `--dir` limita a varredura a um diretório, e `--file`, a um único arquivo. As duas podem ser repetidas e se combinam em um único relatório, com cada arquivo listado uma vez, mesmo quando mais de um alvo o cobre. **Projeto inteiro** ```bash npx lagune read regex ``` **Um diretório** ```bash npx lagune read regex --dir src/services ``` **Um único arquivo** ```bash npx lagune read regex --file bin/import.pl ``` **Vários alvos** ```bash npx lagune read regex --dir core --dir workers --file Sources/App/Router.swift ``` **Com um limite** `--limit` define o limite de ReDoS da varredura (o padrão é 25), o mesmo limite que o modo check aceita. Um limite menor é mais rigoroso. ```bash npx lagune read regex --dir src/services --limit 15 ``` A saída é texto puro, e os cabeçalhos dizem como ler cada seção. Uma seção só aparece quando tem achados. ```text Vulnerable regular expressions found: cmd/server/main.go ([a-z]+)+$ (exponential, search) Dynamically built regular expressions (review manually by simulating a constructed regex): app/payments.php crates/parser/lexer.rs lib/validate.py Static regex wrapped in a constructor (use a literal instead): config/token.rb ``` Quando nada é encontrado, ele imprime uma única linha. ```bash npx lagune read regex --dir src/clean # => no unsafe patterns found ``` ### Como ler as seções | Seção | Significado | | ------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Vulnerable regular expressions found` | Padrões vulneráveis a ReDoS, agrupados por arquivo, com cada padrão recuado logo abaixo e seguido, entre parênteses, do motivo de ser inseguro e, quando houver, do escopo e das flags dele. Toda linha é insegura, então o veredito não se repete. | | `Regular expressions the analysis could not settle (review manually)` | Padrões que a análise não conseguiu resolver dentro do limite de trabalho dela, listados da mesma forma. | | `Dynamically built regular expressions (review manually by simulating a constructed regex)` | Arquivos que montam uma regex a partir de uma variável, de uma concatenação ou de uma interpolação. | | `Static regex wrapped in a constructor (use a literal instead)` | Arquivos que passam uma string literal simples a um construtor de regex quando um literal de regex seria mais simples e evitaria uma compilação em tempo de execução. | A primeira seção é um achado de segurança. A segunda e a terceira não são achados por si só: elas sinalizam código que uma verificação estática não consegue resolver, então pedem a leitura de uma pessoa. A quarta é uma dica de clareza, não um achado de segurança. ### Opções da CLI | Opção | Valor | Descrição | | ----------- | --------------------------- | ---------------------------------------------------------------------------------------------------------------- | | `--pattern` | o código-fonte de uma regex | Verifica um padrão. Repita para verificar vários, com um veredito por padrão, na mesma ordem. | | `--flags` | flags de regex | Verifica cada `--pattern` com essas flags, como `im`. Vale apenas para o modo check. | | `--dir` | um diretório | Limita a varredura a um diretório. Pode ser repetida e combinada com `--file`. | | `--file` | um arquivo | Limita a varredura a um único arquivo. Pode ser repetida e combinada com `--dir`. | | `--limit` | um inteiro não negativo | Define o limite de repetição de ReDoS (o padrão é 25). Vale para os dois modos. Um limite menor é mais rigoroso. | Sem nenhuma opção, ele varre o projeto inteiro. `--pattern` é o modo check e não pode ser combinado com `--dir` nem com `--file`. ### Linguagens suportadas A varredura lê estas linguagens, identificadas pela extensão do arquivo, cada uma pelas próprias regras, para que um padrão de uma nunca seja testado com as regras de outra. Todo o resto é ignorado em vez de ser varrido com as regras erradas. | # | Linguagem | Extensões | | --- | --------------------------- | ------------------------------------------------------------------------------------------------------------ | | 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` | **Melhor esforço, não exaustivo** Ele lê o código-fonte como texto, então não consegue julgar um padrão montado em tempo de execução, e um padrão espalhado por várias linhas, escondido atrás de um alias ou escrito de uma forma que ele não reconhece pode passar despercebido. Trate as seções como um ponto de partida sólido, não como um inventário completo, e continue lendo o código para o que elas não alcançam. ## Verificar um único padrão Passe `--pattern` com o código-fonte do padrão para avaliá-lo. O hook imprime uma palavra: `safe`, `unsafe`, `undetermined` quando a análise atinge o limite de trabalho antes de resolver o padrão, ou `invalid regex`. Repita `--pattern` para avaliar vários de uma vez, com um veredito por padrão, na mesma ordem. **Um padrão** ```bash npx lagune read regex --pattern '(a+)+$' # => unsafe npx lagune read regex --pattern '^[a-z0-9_]{3,20}$' # => safe ``` **Vários padrões** ```bash npx lagune read regex --pattern '(a+)+$' --pattern '^[a-z]+$' # => unsafe # => safe ``` **Com flags** `--flags` verifica cada `--pattern` da chamada com as flags com que ele roda, já que uma flag muda os caracteres que um padrão reconhece. ```bash npx lagune read regex --pattern '^(?:a|A)+$' # => safe npx lagune read regex --pattern '^(?:a|A)+$' --flags 'i' # => unsafe ``` **Com um limite** `--limit` define o limite de repetição (o padrão é 25) e vale para cada `--pattern` da chamada. Um limite menor é mais rigoroso. ```bash npx lagune read regex --pattern 'a?a?a?' --limit 2 # => unsafe ``` **Por que um argumento entre aspas** Cada padrão é passado como valor de uma flag, nunca interpolado no comando. Um valor com aspas ou crases continua inerte e não consegue injetar nada no shell. Sempre coloque o padrão entre aspas simples para que o seu shell não o expanda antes. **Dica** Este é o mesmo engine que a [especialização `regex`](https://lagune.ai/pt-BR/docs/catalog) executa: a varredura abre uma análise de ReDoS, e a verificação confirma um padrão que ela encontrar. ## Perguntas frequentes ### Como verificar se uma regex é vulnerável a ReDoS pela CLI? Execute npx lagune read regex --pattern ''. Ele retorna safe, unsafe, undetermined ou invalid regex. ### Como varrer um projeto inteiro em busca de regex inseguras? Execute o hook regex no modo scan sobre o código. Ele sinaliza padrões vulneráveis a ReDoS em 25 linguagens suportadas. --- # Hook secrets: detecte segredos hardcoded > Varra um código em busca de credenciais hardcoded, direto da linha de comando. Canônica: https://lagune.ai/pt-BR/docs/hooks/secrets Idioma: pt-BR Original: https://lagune.ai/docs/hooks/secrets Última atualização: 2026-11-03 O hook `secrets` sinaliza **credenciais embutidas no código-fonte** em vez de lidas do ambiente. Ele se baseia na **procedência** (um literal versus uma leitura do ambiente), não no conteúdo do valor, então não precisa de um catálogo exaustivo de prefixos de provedores e quase não gera falsos positivos. É o engine determinístico por trás da [especialização `secrets`](https://lagune.ai/pt-BR/docs/catalog). As assinaturas de formato de provedores, as credenciais em strings de conexão e um literal atribuído a um identificador com nome de segredo são **independentes de linguagem**: a mesma string é lida do mesmo jeito em qualquer arquivo. As duas heurísticas que dependem de sintaxe, uma leitura do ambiente com um valor padrão hardcoded e um segredo que vai parar em um ponto de log, **reconhecem a linguagem**, então um `console.log` de JavaScript nunca é procurado em um arquivo Rust, e o `os.getenv("X", "default")` do Python é reconhecido por si só. ## Como executar ```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 ``` A varredura imprime até duas seções. **Hardcoded secrets found** é o conjunto de achados (um valor padrão hardcoded para uma variável de ambiente com nome de segredo, uma credencial embutida em uma string de conexão ou um valor que corresponde a um formato de provedor catalogado), então o hook termina com código de saída diferente de zero. **Secret handling to review manually** é um conjunto de pistas: um literal simples atribuído a um identificador com nome de segredo (a procedência dele é decidível, mas não se o valor é um segredo real) e um valor com nome de segredo que vai parar em um ponto de log ou de resposta. Uma execução sem achados imprime `no hardcoded secrets found`. ### Opções da CLI | Opção | Valor | Descrição | | -------- | ------------ | --------------------------------------------------------------------------------- | | `--dir` | um diretório | Limita a varredura a um diretório. Pode ser repetida e combinada com `--file`. | | `--file` | um arquivo | Limita a varredura a um único arquivo. Pode ser repetida e combinada com `--dir`. | Sem nenhuma opção, ele varre o projeto inteiro. ### Cobertura de linguagens O achado de valor padrão do ambiente e a pista de ponto de log leem um conjunto de formas próprio de cada linguagem, então cobrem as linguagens abaixo e ficam em silêncio nas demais. Os outros três sinais rodam em **todos** os arquivos. | Sinal | Linguagens | | --------------------------- | ------------------------------------------------------------------------------- | | Valor padrão do ambiente | JavaScript/TypeScript, Python, Ruby, PHP, Kotlin, Java, Go (`cmp.Or`), Rust, C# | | Ponto de log ou de resposta | JavaScript/TypeScript, Python, Ruby, PHP, Java, Kotlin, Go, Rust, C, C++, C# | **Isso é um problema de política?** Não. Detectar o formato de um segredo para avisar que ele foi commitado é uma prática padrão de ferramentas defensivas, a mesma operação que o gitleaks, o trufflehog e o push protection do GitHub realizam. O hook traz assinaturas de detecção (os **formatos** públicos de tokens), nunca um segredo real, e audita e explica em vez de exfiltrar. ## Perguntas frequentes ### Como o hook secrets evita falsos positivos? Ele se baseia na procedência, não no conteúdo do valor. Os formatos de alta confiança (tokens de provedores, valores padrão do ambiente, strings de conexão) são achados que terminam com código de saída diferente de zero. Um literal simples atribuído a um identificador com nome de segredo é uma pista para revisar e confirmar, e o mesmo identificador lido de process.env não é sinalizado de forma alguma. --- # Exemplos de prompts do Lagune: automatize o fluxo Blue Team > Prompts do Lagune prontos para copiar: uma varredura somente leitura, o fluxo Blue Team completo e uma auditoria Zero Trust, além de detecção com escopo em um commit, no diff de uma branch ou PR ou em um incidente real. Canônica: https://lagune.ai/pt-BR/docs/examples/prompts Idioma: pt-BR Original: https://lagune.ai/docs/examples/prompts Última atualização: 2026-11-03 Prompts do Lagune prontos para copiar e colar direto no seu agente de IA. ## 💧 Varredura rápida Uma varredura somente leitura que lê o código por conta própria e aponta cada falha com uma correção, sem rodar o fluxo Blue Team nem gravar nada no rastreamento do Lagune. **Dica** Funciona melhor no modo de planejamento e com um charter (`/lagune-charter`) definido. **🪼 Padrão** | Aspecto | Trade-off | Nível | | ----------------- | --------------------------------------------------------------------- | ------------------- | | **Esforço** | Um único agente analisa e relata, sem subagentes. | 1/5 | | **Tempo** | Rápido. Uma única passada somente leitura, nada é aplicado. | 2/5 | | **Uso de tokens** | Moderado e compartilhado. A varredura inteira roda em um só contexto. | 2/5 | ```md /lagune Você é um pesquisador de cibersegurança com profundo conhecimento em segurança defensiva e usa o Lagune para aprimorar o seu conhecimento e a sua precisão. Analise o workspace por conta própria e associe cada falha que encontrar a uma correção concreta. Esta é uma varredura avulsa, não o fluxo Blue Team: não execute detect, plan, harden nem verify, e não grave nada no rastreamento do Lagune. No fim, liste todas as falhas que você encontrou, cada uma com a severidade dela e uma correção concreta. ``` **🐬 Multiagentes** | Aspecto | Trade-off | Nível | | ----------------- | --------------------------------------------------------------------------------------------- | ------------------- | | **Esforço** | Um subagente por arquivo, proporcional ao tamanho do seu código. | 2/5 | | **Tempo** | Em paralelo por arquivo e depois consolidado em um único relatório. Continua somente leitura. | 3/5 | | **Uso de tokens** | Maior, mas isolado. Cada subagente analisa no próprio contexto. | 3/5 | ````md /lagune Você é um orquestrador de cibersegurança que usa o Lagune para enumerar caminhos, disparar um subagente por caminho e consolidar os relatórios deles (todo o conteúdo é lido pelos subagentes). Você deve delegar a tarefa a subagentes de acordo com o tamanho do projeto atual: quanto maior o código, mais subagentes devem ser disparados, todos em paralelo, cada um com o prompt abaixo: ```prompt /lagune Você é um pesquisador de cibersegurança com profundo conhecimento em segurança defensiva e usa o Lagune para aprimorar o seu conhecimento e a sua precisão. Analise por conta própria e associe cada falha que encontrar a uma correção concreta. Esta é uma varredura avulsa, não o fluxo Blue Team: não execute detect, plan, harden nem verify, e não grave nada no rastreamento do Lagune. No fim, liste todas as falhas em , cada uma com a severidade dela e uma correção concreta. ``` No fim, consolide os relatórios de todos os subagentes em uma única lista priorizada de falhas e correções. ```` **Atenção** Uma varredura rápida é um único prompt amplo e sem escopo, então alguns agentes têm mais chance de recusá-la ou de interrompê-la no meio. Se o seu resistir, rode o **fluxo Blue Team** completo abaixo: as fases dele, com escopo e passo a passo, têm muito menos chance de serem bloqueadas. --- ## 🌊 Auditoria Blue Team automática Executa o [fluxo completo de comandos](https://lagune.ai/pt-BR/docs/get-started/commands) de ponta a ponta, sem parar para pedir informações. **🪼 Padrão** | Aspecto | Trade-off | Nível | | ----------------- | --------------------------------------------------------------------------------------------- | ------------------- | | **Esforço** | Um único agente, sem subagentes, seja qual for o tamanho do código. | 3/5 | | **Tempo** | Médio, mas menos minucioso em códigos grandes. Cada comando roda uma vez, um depois do outro. | 4/5 | | **Uso de tokens** | Menor, mas menos isolado. Todos os comandos compartilham o mesmo contexto. | 4/5 | ```md Execute os comandos a seguir, um por um: `/lagune-charter`, `/lagune-detect`, `/lagune-plan`, `/lagune-harden` e `/lagune-verify`. ## Loop Quando o `/lagune-verify` reprovar uma ou mais correções, repita o `/lagune-harden` e depois o `/lagune-verify` até que todos os achados estejam devidamente resolvidos. ## Importante - Não pare e não pergunte: em caso de dúvida, faça tudo no modo "full". ``` **🐋 Multiagentes (deep scan)** | Aspecto | Trade-off | Nível | | ----------------- | ------------------------------------------------------------------------------------------------------------------------ | ------------------- | | **Esforço** | A quantidade de subagentes é proporcional ao tamanho do seu código. | 5/5 | | **Tempo** | Mais longo, porém mais minucioso. Dispara vários subagentes para detectar, planejar e fortalecer os achados em paralelo. | 5/5 | | **Uso de tokens** | Maior, porém mais seguro. Cada subagente tem o próprio contexto isolado, sem viés. | 5/5 | ````md Execute cada um dos comandos a seguir em um subagente, um de cada vez (sem crases, apenas o comando): Prompt do subagente 1: `/lagune-charter` Prompt do subagente 2: `/lagune-detect` Prompt do subagente 3: `/lagune-plan` Prompt do subagente 4: `/lagune-harden` Prompt do subagente 5: `/lagune-verify` Nos comandos `/lagune-detect`, `/lagune-plan`, `/lagune-harden` e `/lagune-verify`, você deve delegar a tarefa a subagentes de acordo com o tamanho do projeto atual: quanto maior o código, mais subagentes devem ser disparados. Por exemplo: ```prompt /lagune-detect ``` ```prompt /lagune-plan ``` ```prompt /lagune-harden ``` ```prompt /lagune-verify ``` - Vários agentes no mesmo comando devem ser disparados em paralelo. - Quando todos os subagentes do `/lagune-detect` terminarem, execute: ```prompt /lagune-detect consolide os achados equivalentes. Não procure novos achados nem varra o código de novo. ``` ## Loop Quando o `/lagune-verify` reprovar uma ou mais correções, repita o `/lagune-harden` e depois o `/lagune-verify` até que todos os achados estejam devidamente resolvidos. ## Importante - Não pare e não pergunte: em caso de dúvida, faça tudo no modo "full". ```` --- ## 🪄 Detecção com escopo Aponte o [`/lagune-detect`](https://lagune.ai/pt-BR/docs/commands/detect) para uma parte do seu projeto em vez do projeto inteiro. Descreva o escopo em linguagem simples (um commit, um pull request ou uma situação real), e ele mapeia apenas os achados relevantes para a segurança ali. **Dica** Tudo o que ele detecta aqui é um achado normal, então você pode levá-lo direto para o `/lagune-plan`, o `/lagune-harden` e o `/lagune-verify`, com o escopo restrito a esses itens. **📌 Desde um commit** Dê a um lote recente de commits uma análise de segurança própria, restrita ao que eles mudaram, por exemplo: ```prompt /lagune-detect Restrinja a detecção a tudo o que mudou desde o commit `a1b2c3d`. ``` **🔀 Diff de branch ou PR** Revise a segurança de um pull request antes do merge, restrita ao diff dele, por exemplo: ```prompt /lagune-detect Restrinja a detecção às mudanças que esta branch introduz em relação à `main`. ``` **⛑️ Depois de um incidente** Descreva o que aconteceu com as suas próprias palavras. O Lagune lê a situação, não uma flag, e a transforma em uma investigação focada, por exemplo: ```prompt /lagune-detect Nosso site teve um vazamento de dados há algumas semanas. Não sei exatamente como aconteceu e tenho medo de que ainda haja alguma brecha aberta que possa vazar dados de novo. Revise o código com cuidado, concentre-se em todo lugar onde dados sensíveis são lidos, armazenados ou expostos e mapeie tudo o que ainda possa ser uma porta de saída. Trate isso como um incidente real, não como um simulado. ``` --- ## 🚨 Auditoria Zero Trust Trata o workspace inteiro e cada dependência como hostis: procura interpretadores, chamadas de rede, payloads codificados e código escondido em lugares improváveis para escapar dos scanners, e termina com um veredito de go ou no-go sobre se o projeto é seguro para usar. Os prompts carregam diretamente as especializações em que essa auditoria se apoia, sejam quais forem as categorias do seu projeto. Para o restante do catálogo que o `/lagune` combina, garanta que o projeto use **OWASP**, **IA / LLM** e a categoria da stack dele (por exemplo, **JavaScript**, **Python** etc.): ```bash npx lagune write add --categories owasp ai javascript ``` **Perigo** Tome cuidado ao rodar projetos de fontes não confiáveis no seu ambiente local. Use um ambiente isolado, como uma **sandbox** (recomendado), uma **VM** ou algo parecido, para impedir que código malicioso afete o seu sistema. **🪼 Padrão** | Aspecto | Trade-off | Nível | | ----------------- | ------------------------------------------------------------------------------------------------------------- | ------------------- | | **Esforço** | Um único agente varre o workspace inteiro, sem subagentes. | 2/5 | | **Tempo** | Médio. Um único agente percorre o código e as dependências dele em sequência. | 3/5 | | **Uso de tokens** | Moderado, mas compartilhado. As especializações, o código e as dependências carregam todos em um só contexto. | 3/5 | ```md /lagune Você é um pesquisador de cibersegurança com profundo conhecimento em segurança defensiva zero trust e usa o Lagune para aprimorar o seu conhecimento e a sua precisão. Mapeie o workspace inteiro como uma fonte não confiável e um escopo potencialmente malicioso. Todo interpretador, fetch, base64 e afins devem ser tratados como uma ameaça em potencial. Estenda a sua análise às dependências e subdependências: um projeto pode tentar esconder código malicioso em um lugar improvável para escapar dos scanners. Especializações obrigatórias (carregue uma de cada vez com `npx lagune read catalog `): - interpreter - secrets - llm - path Para deixar claro: toda vulnerabilidade mapeada deve ser tratada como uma ameaça em potencial, sem exceção. No fim, dê um veredito sobre se o projeto é seguro e confiável para eu usar ou não. ``` **🐋 Multiagentes (deep scan)** | Aspecto | Trade-off | Nível | | ----------------- | ------------------------------------------------------------------------------------------------------------------ | ------------------- | | **Esforço** | Um subagente por arquivo, proporcional ao tamanho do seu código. | 5/5 | | **Tempo** | Mais longo, porém mais minucioso. Os arquivos são varridos em paralelo e depois consolidados em um único veredito. | 4/5 | | **Uso de tokens** | O mais alto, porém o mais seguro. Cada subagente lê as especializações no próprio contexto isolado. | 5/5 | ````md /lagune Você é um orquestrador de cibersegurança que usa o Lagune para enumerar arquivos, disparar um subagente por arquivo e gerar relatórios (todo o conteúdo é lido pelos subagentes). Dispare um subagente por arquivo, todos em paralelo, cada um com o prompt abaixo, restrito ao próprio arquivo: ```prompt /lagune Você é um pesquisador de cibersegurança com profundo conhecimento em segurança defensiva zero trust e usa o Lagune para aprimorar o seu conhecimento e a sua precisão. Trate como uma fonte não confiável e um escopo potencialmente malicioso. Todo interpretador, fetch, base64 e afins devem ser tratados como uma ameaça em potencial. Estenda a análise a tudo o que importa, incluindo dependências e subdependências, onde código malicioso pode se esconder para escapar dos scanners. Especializações obrigatórias para todos os subagentes (carregue uma de cada vez com `npx lagune read catalog `): - interpreter - secrets - llm - path Para deixar claro: toda vulnerabilidade mapeada deve ser tratada como uma ameaça em potencial, sem exceção. No fim, dê um veredito sobre se o projeto é seguro e confiável para eu usar ou não. ``` No fim, consolide os relatórios de todos os subagentes em um único veredito final. ```` --- # Security-Driven Hardening: uma convenção para a era do desenvolvimento assistido por IA > A metodologia Security-Driven Hardening (SDH): uma convenção Blue Team, sensível ao contexto, para auditar e fortalecer a segurança de software feito com IA e com vibe coding. Canônica: https://lagune.ai/pt-BR/docs/references/paper Idioma: pt-BR Original: https://lagune.ai/docs/references/paper Última atualização: 2026-11-03 - **Weslley Araújo** - **Artigo de metodologia, 2026.** --- ## Resumo Security-Driven Hardening (SDH) é uma metodologia de segurança estruturada, conduzida por IA e exclusivamente defensiva, pensada para uma época em que o software é cada vez mais escrito por agentes de IA e por pessoas que não são especialistas em segurança. Em vez de seguir um checklist genérico, a SDH primeiro detecta o que um sistema realmente faz (login, upload de arquivos, pagamentos, exposição de dados etc.) e então conduz o trabalho de segurança específico desse contexto. Ela é regida por princípios seguros por padrão, inteiramente voltada para a defesa e expressa em linguagem simples, para que qualquer usuário consiga agir a partir dela. Este documento defende que a SDH é uma convenção que faltava, e não uma ferramenta isolada. O conhecimento de segurança está na metodologia e nas suas especializações sob demanda, uma base sobre a qual todo usuário pode construir, o que permite atender um iniciante e um especialista pelo mesmo fluxo. Duas propriedades a distinguem das abordagens spec-first anteriores `[1]`. A SDH é **independente de estado**: ela se adapta a um diretório vazio, a um projeto em andamento, a um único pull request ou a uma grande base de código legada, em qualquer stack. E a SDH é **encerrável**: um risco cujo fechamento foi verificado é encerrado em todo o fluxo, de modo que aquele achado chega a um estado de repouso e só é reaberto quando o código muda. A SDH não substitui profissionais de segurança nem ferramentas especializadas de Blue Team. Ela amplia o conhecimento do próprio desenvolvedor, e quanto mais um desenvolvedor entende de segurança, mais ele consegue conduzi-la. O **Lagune** é a implementação de referência e comprova que a metodologia pode ser construída e levada a outros contextos. A SDH é oferecida como uma convenção que outros podem adotar. > **Palavras-chave** > > desenvolvimento assistido por IA, segurança de software, segurança defensiva, spec-driven development, hardening de segurança, fluxos conduzidos por agentes, encerrabilidade, segurança sensível ao contexto, conhecimento sob demanda, ferramentas independentes de agente. --- ## I. Introdução: a lacuna de segurança que o desenvolvimento assistido por IA abriu O software é cada vez mais entregue por pessoas, e por agentes de IA, que não conseguem reconhecer com segurança um padrão inseguro: um segredo vazado, uma verificação de autorização ausente, uma consulta vulnerável a injeção. Não são riscos exóticos. Eles estão entre as classes de risco que dominam os incidentes reais, documentadas há anos em referências públicas `[6]`, `[7]`, e estudos recentes relatam que uma parcela relevante do código gerado por IA é entregue justamente com esses defeitos `[8]`. Os assistentes de programação com IA agravaram o problema ao permitir que não desenvolvedores entreguem software real, mas a lacuna é mais ampla do que qualquer público específico. A maioria dos projetos nunca recebe uma revisão de segurança específica para o que eles realmente fazem. O ecossistema fica mais frágil a cada decisão precipitada de "funciona, pode publicar". Conselhos genéricos de segurança não fecham essa lacuna. Um checklist estático não é específico para o que um sistema faz, então ele inunda um projeto pequeno com itens irrelevantes e ainda deixa passar o risco que importa para aquele projeto. O problema não é falta de conhecimento de segurança no mundo. O problema é associar o conhecimento certo ao sistema que está de fato diante do usuário, e fazer isso para alguém que talvez não saiba o que pedir. A SDH responde a isso com uma única inversão: **o conhecimento de segurança está na spec e nas suas especializações sob demanda, uma base sobre a qual todo usuário pode construir**. A metodologia detecta o contexto, faz a triagem dos riscos que esse contexto traz e orienta as correções, de modo que um desenvolvedor e um não desenvolvedor são atendidos pelo mesmo fluxo. Os achados e as recomendações continuam em linguagem simples, para que sejam acionáveis qualquer que seja a profundidade técnica de quem os lê. O especialista não é limitado por isso, e sim amplificado, uma dualidade que desenvolvemos na `§VI`. > **Ideia central** > > **A inversão central:** o conhecimento de segurança está na spec e nas suas especializações sob demanda, uma base sobre a qual todo usuário pode construir. A metodologia aprende o que o sistema faz, associa a ele o trabalho de segurança adequado e amplia o que o usuário já sabe. Pense em um desenvolvedor que diz a um assistente de IA: "meu app permite que os usuários enviem uma foto de perfil". Sem uma revisão de segurança, o assistente produz um código que funciona e que, discretamente, confia em tudo o que o cliente envia: o tipo de arquivo declarado, o nome do arquivo, o tamanho. O upload vai para produção, e um arquivo disfarçado de imagem pode carregar código, um nome manipulado pode escapar do caminho de armazenamento e um arquivo grande demais pode esgotar o servidor. Nada disso aparece em uma demonstração, então tudo vai para produção. O mesmo código, passando pela SDH, se comporta de outro jeito. Ela detecta que o sistema aceita arquivos vindos de fora (detecção), traduz isso nos riscos que um upload traz (triagem), propõe verificar o tipo real e o tamanho do arquivo, renomeá-lo ao salvar e armazená-lo onde código não pode ser executado (remediação), e então lê o resultado e confirma que cada controle realmente se sustenta (verificação). O desenvolvedor nunca precisou conhecer a expressão "upload de arquivos sem restrição". A metodologia a forneceu por ele. Este documento traz as seguintes contribuições: - Uma definição precisa da SDH como metodologia, independente de qualquer implementação, com os seus princípios de design (`§III`). - Um ciclo de vida defensivo de cinco fases em que a própria separação de responsabilidades é a contribuição: a detecção nunca inventa, o planejamento nunca lê o código, só uma fase altera o código e a verificação nunca suaviza o seu julgamento (`§IV`). - A **encerrabilidade** como postura metodológica: cada achado tem um estado final, e não um ciclo sem fim (`§V`). - A dualidade do **extensor do conhecimento do desenvolvedor**: um único fluxo que protege o iniciante e amplifica o especialista (`§VI`). - **Especializações não invocáveis e prompt sob demanda**: conhecimento de segurança focado que o agente carrega quando o contexto do projeto pede, nunca por padrão (`§VII`). - **Independência de estado** e **adaptabilidade não autoritativa**: a SDH se encaixa em qualquer estado de desenvolvimento e se adapta ao cenário em vez de impor um escopo fixo (`§VIII`). - Um **modo preventivo**: a mesma defesa aplicada enquanto o trabalho comum é construído, para que o código já chegue seguro por padrão e as fases tenham menos a corrigir (`§IX`). - Uma comparação dedicada com o Spec-Driven Development, a linhagem da qual a SDH nasceu e da qual depois se afastou (`§X`). - As disciplinas de engenharia que permitem à metodologia sobreviver a refatorações e permanecer independente de qualquer agente: o rastreamento por identidade pelo nome (`§XI`) e um veículo independente de agente (`§XII`). --- ## II. Contexto e trabalhos relacionados A SDH se apoia em trabalhos anteriores. Ela herda uma estrutura já comprovada do desenvolvimento spec-first conduzido por agentes `[1]`, `[2]`, `[3]`: templates, slash commands que um agente consome, um documento regente e um agente que executa as fases. Ela reimplementa essa estrutura com um propósito defensivo. A linhagem é intencional, e um dos princípios de trabalho da SDH a nomeia diretamente: construir o fluxo a partir de uma estrutura comprovada e então orientá-lo para a segurança. A SDH não é um checklist estático de recomendações genéricas. Um checklist sabe muito sobre segurança em geral e nada sobre o projeto diante dele. A SDH inverte essa ênfase. Ela dedica o primeiro esforço à detecção, a aprender o que o sistema faz, e só então recorre ao conhecimento que a detecção torna relevante. A SDH também não substitui as pessoas de segurança nem as ferramentas especializadas de Blue Team. Ela amplia o conhecimento do desenvolvedor (`§VI`). Uma equipe com uma função de segurança dedicada deve mantê-la. A SDH oferece a essa equipe um veículo estruturado e oferece a uma equipe sem essa função uma base defensável. A SDH também convive com scanners de segurança determinísticos (análise estática, linters) `[4]`, `[5]`. Essas ferramentas são valiosas justamente por serem determinísticas e repetíveis. A SDH é, em grande parte, raciocinada pelo agente, o que troca o determinismo estrito pela sensibilidade ao contexto. A metodologia não finge o contrário. Onde o determinismo importa, ela embute um engine determinístico dentro do raciocínio (`§VII`): o agente decide se vale a pena verificar uma entrada, e um programa determinístico decide se essa entrada é perigosa. O trabalho anterior mais diretamente relacionado é o Spec-Driven Development (SDD), a família de metodologias spec-first que conduz uma construção adiante a partir de uma especificação executável. Tratamos o SDD como uma classe. A sua formulação mais clara como metodologia prática é o relatório de Piskala `[1]`, e o seu toolkit mais visível conduzido por agentes é o Spec Kit do GitHub `[2]`, com o OpenSpec `[3]` como uma segunda ferramenta da mesma família. Essas são as referências canônicas da comparação na `§X`. --- ## III. SDH: definição e princípios de design **Security-Driven Hardening** é uma metodologia de segurança estruturada e conduzida por IA que torna uma base de código mais segura conduzindo o trabalho a partir de uma spec que o agente executa, e não de correções improvisadas. O nome se inspira nos **Blue Teams**, os defensores na segurança. A SDH trata de defesa, hardening e verificação, nunca de ataque. > **Definição** > > **Security-Driven Hardening (SDH):** uma metodologia de segurança estruturada, conduzida por IA e exclusivamente defensiva, que primeiro detecta o que um sistema realmente faz e então conduz o trabalho de segurança específico do contexto, regida por princípios seguros por padrão e expressa em linguagem simples. A SDH é definida por um conjunto de princípios obrigatórios. Cada um é uma regra, e cada um dá ao usuário uma garantia específica. | Princípio | A regra | O que ele garante ao usuário | | -------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Seguro por padrão, em linguagem simples, para todos igualmente | Todo padrão, mensagem e correção é seguro desde o início e compreensível para qualquer leitor, desenvolvedor ou não. Nenhum tipo de usuário é privilegiado. | Um iniciante recebe uma base segura sem precisar pedir e lê o resultado nos próprios termos. | | Sensível ao contexto em vez de genérico | Toda fase parte do contexto identificado no detect e age sobre o que o sistema realmente faz. | As recomendações se ajustam ao projeto, e não a um checklist. O conhecimento de segurança está na spec e nas suas especializações sob demanda, ampliando o que o usuário traz. | | Flexível em vez de rígido | Princípios, requisitos e recomendações são pontos de partida. O usuário pode reformular, descartar, acrescentar ou restringir o escopo de qualquer coisa. | A metodologia se molda ao projeto e ao usuário, e nunca é mais rígida do que o usuário quer. A flexibilidade nunca enfraquece a base segura por padrão. | | Reconciliar, nunca só acrescentar | Os artefatos são documentos vivos, não logs. Cada execução revisa cada entrada: mantém o que se sustenta, reescreve o que mudou e remove o que não se aplica mais. | O registro sempre reflete o presente, então nunca se degrada em um backlog desatualizado. | | Somente defesa | A SDH audita, fortalece e verifica. Ela nunca produz ferramentas ofensivas, exploits para uso malicioso nem técnicas de evasão de detecção para causar dano. | A metodologia não pode ser transformada em arma. Conteúdo de uso duplo só aparece em um enquadramento claramente defensivo. | | Spec-first, conduzido por agente, orientado para a segurança | O fluxo é construído a partir de templates, comandos, um charter regente e um agente que executa as fases. | Uma estrutura de desenvolvimento comprovada, reaproveitada para que o agente realize o trabalho de segurança de fato. | **Tabela 1.** Os princípios de design da SDH e a garantia que cada um dá ao usuário. Esses princípios não são decorativos. Eles são as restrições que toda fase descrita a seguir precisa respeitar, e a discussão na `§XV` volta a eles para marcar os limites da metodologia. O restante do documento desenvolve nove pilares nomeados. Eles são as partes que um leitor deve conseguir guardar na memória e as partes que outra equipe reimplementaria para afirmar que está fazendo SDH. | Pilar | O que ele oferece | Seção | | --------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- | | A inversão sensível ao contexto | O conhecimento de segurança está na spec e nas suas especializações sob demanda, então um iniciante e um especialista compartilham um único fluxo. | `§I`, `§VI` | | O ciclo de vida defensivo de cinco fases | Separação de responsabilidades: política, detecção, triagem, remediação e verificação, cada uma com uma única tarefa. | `§IV` | | Encerrabilidade | Um achado tem um estado final, e não um ciclo sem fim. O trabalho concluído é encerrado. | `§V` | | A dualidade do extensor do conhecimento do desenvolvedor | Um único fluxo que protege o iniciante e amplifica o especialista, sem nunca substituir nenhum dos dois. | `§VI` | | Prompt sob demanda, conhecimento não invocável | O conhecimento de segurança relevante é carregado para o que o projeto é, nunca por padrão. | `§VII` | | Independência de estado e adaptabilidade não autoritativa | Encaixa-se em qualquer estado de desenvolvimento, em qualquer stack, e se adapta ao cenário em vez de impor um escopo. | `§VIII` | | O modo preventivo | A mesma defesa roda enquanto o trabalho novo é construído, para que o código já chegue seguro por padrão. | `§IX` | | Rastreamento por identidade pelo nome | Um achado continua sendo um único item ao longo das fases, e uma renomeação quebra o vínculo em um só lugar. | `§XI` | | O veículo independente de agente | O valor de segurança é escrito uma única vez e não depende de nenhum agente nem de nenhuma stack. | `§XII` | **Tabela 2.** Os nove pilares nomeados da SDH e onde cada um é desenvolvido. --- ## IV. O fluxo Blue Team de 5 fases A SDH estrutura o trabalho como um ciclo de vida defensivo de cinco fases (Figura 1). Cada fase é orientada para a defesa, cada uma se apoia na anterior, e as fases seguem a atividade real de um Blue Team: estabelecer a política, detectar, fazer a triagem, remediar e verificar. ```mermaid flowchart TB charter["1 · charter (política)
lê: o projeto e a descrição do usuário, se houver
escreve: o charter
os princípios trazem o risco que previnem, em linguagem simples"] detect["2 · detect (detecção)
lê: o código do usuário
escreve: o mapa do detect
detecção, não invenção: registra só o que o código sustenta"] plan["3 · plan (triagem)
lê: o mapa do detect, nunca o código
escreve: o plano de defesa
toda correção aponta para algo que o detect realmente mapeou"] harden["4 · harden (remediação)
lê: o plano de defesa e o código que ele toca
escreve: o código e o registro de hardening
a única fase que altera o código, uma correção por vez, a menor mudança que se sustenta"] verify["5 · verify (verificação)
lê: o código e o registro de hardening
escreve: cada veredito em aberto no registro de hardening
o confronto do código com o registro, estático, nunca suavizado"] charter --> detect --> plan --> harden --> verify verify -.->|"reprovado: trabalho reaberto para o harden,
reaplicado conforme o motivo registrado"| harden verify -.->|"fechamento: encerra o que comprovou fechado
em toda a cadeia,
uma linha no histórico"| detect ``` **Figura 1.** O fluxo de cinco fases: o que cada fase lê, o que ela escreve e a sua invariante essencial. O verify conduz os dois retornos: um controle reprovado reabre o harden, e um achado comprovadamente fechado é encerrado em toda a cadeia, com uma linha no histórico. A separação de responsabilidades é a contribuição. Como cada fase tem uma única tarefa, uma falha fica contida em um só lugar, e o leitor pode confiar no que cada artefato afirma. > **Ideia central** > > **Applied não é verificado:** o harden registra que uma correção foi aplicada. O verify a verifica confrontando o código com esse registro, e o veredito nunca é suavizado para coincidir com o registro. Um controle pode estar presente no código e ainda deixar o risco alcançável, e então o veredito honesto é "risco não fechado". ### charter (política) O charter estabelece os princípios de segurança do projeto, as regras que todas as fases seguintes precisam respeitar. Ele é a camada regente, uma espécie de verificação em tempo de compilação da postura de segurança do projeto. Cada princípio tem um nome claro, uma regra inegociável que pode ser conferida no código e uma linha `Why:` que declara o risco que ele previne, e não apenas a correção. O charter sempre lê o próprio projeto (os manifestos, a estrutura e as dependências), e a descrição do usuário, quando existe, é uma direção que essa leitura depois amplia para além do que o usuário citou. Sem descrição, o projeto é a única fonte. As duas se somam em vez de competir, e o charter registra a política que o projeto deve seguir, não o estado do código. Um não desenvolvedor deve conseguir lê-lo e entender tanto a regra quanto o risco. ### detect (detecção) O detect lê o código e mapeia o que o sistema realmente faz que tem peso para a segurança. A instrução que o rege é "detecção, não invenção": registrar só o que o código sustenta, com as evidências de que as fases seguintes precisam. O detect é neutro. Ele não força os achados a se encaixarem no charter, porque confrontar os riscos com as regras do charter é tarefa da fase plan. Cada achado tem três partes: o que ele é (uma descrição em linguagem simples), por que importa (o risco, não apenas o fato) e a evidência (a função ou a rota em que ele está). A evidência não traz caminho de arquivo. O caminho fica apenas no mapa de rastreamento (`§XI`), então o texto nunca guarda um caminho que possa ficar desatualizado. ### plan (triagem) O plan transforma cada achado em uma correção, nomeada pela sua classe de risco (citando as referências consagradas, CWE e OWASP, quando elas a fundamentam) e vinculada ao princípio do charter que a correção sustenta. A prioridade (crítica, alta, média, baixa) não é uma escolha livre: o plan classifica cada achado pelo método Base-and-Environmental do CVSS v4.0, então a faixa é a nota em palavras simples, justificada por uma linha em linguagem simples sobre a exposição e o que está em jogo, e duas execuções chegam à mesma ordem. O vetor é a âncora precisa para um especialista, e a faixa com a sua justificativa é a mesma classificação que qualquer pessoa consegue acompanhar. O plan trabalha apenas a partir do mapa do detect e nunca lê o código. Essa é uma restrição deliberada, não uma limitação: ela obriga cada correção a apontar para algo que o detect realmente detectou. Se um escopo nunca foi mapeado, o plan para e leva o usuário de volta ao detect em vez de adivinhar. ### harden (remediação) O harden é a única fase que altera o código, então avança com cautela. Decidir se uma edição precisa da aprovação do usuário cabe ao agente e ao modo de permissão em que ele roda, por isso o harden não acrescenta nenhuma etapa de confirmação própria. Ele aplica uma correção por vez, primeiro as dependências e depois a maior prioridade, para que cada mudança continue pequena, revisável e fácil de desfazer. Ele nunca enfraquece um controle existente para encaixar uma nova correção e nunca viola um princípio do charter. Se uma correção entraria em conflito com um princípio, o harden para e expõe o conflito em vez de aplicá-la. Cada bloco é registrado como Applied, Partial ou Blocked. "Applied ainda não significa verificado", e é dessa questão que a fase seguinte trata. ### verify (verificação) O verify verifica cada controle aplicado lendo o código e confrontando-o com o que o harden registrou. A verificação é esse confronto, o código contra o registro, e ela é estática: confirma que um controle está presente e correto no código, não que ele resiste a um ataque contra um sistema em execução. Essa verificação em tempo de execução, do tipo que dispara ataques reais ou simulados contra o sistema em produção, fica fora do escopo por design. O verify devolve um de três vereditos: risco fechado, risco não fechado ou não dá para saber pelo código. Ele não produz nenhum artefato próprio: o harden e o verify compartilham o registro de hardening, o harden responde pelo que foi feito e o verify responde pelo veredito e pelo seu motivo, e nenhum dos dois escreve nos campos do outro. Um controle reprovado é trabalho reaberto para o harden, cuja próxima execução trata o veredito como superior à sua própria leitura do código e reaplica a correção exatamente na lacuna que o motivo aponta. O verify confia mais no código do que no registro, porque um registro pode afirmar mais do que o código entrega. Ele é somente leitura no código do usuário e nunca suaviza um veredito para coincidir com o registro. Um controle pode estar presente e ainda deixar o risco alcançável por outro caminho, e nesse caso o veredito honesto é "risco não fechado". Se, durante a leitura, o verify percebe um problema de segurança que o mapa do detect nunca cobriu, ele não inventa um veredito para esse problema, já que detectar é tarefa do detect: ele expõe o problema e leva o usuário de volta ao detect, para que o achado entre pelo mesmo fluxo em vez de contorná-lo. > **Fio condutor: upload de arquivos.** Um único achado mostra a espinha dorsal de ponta a ponta. > > - O **detect** o encontra: o sistema aceita arquivos dos usuários, e o handler de upload confia no tipo MIME que o cliente envia sem verificar o tipo real do arquivo. _Por que importa:_ um arquivo disfarçado de imagem pode esconder código malicioso. > - O **plan** decide a correção, com prioridade **crítica**, sustentando o princípio "Toda entrada é não confiável até ser validada": verificar o tipo real e o tamanho do arquivo, renomeá-lo ao salvar e armazenar os uploads onde eles não possam ser executados como código. > - O **harden** a aplica, com status **Applied**: o handler agora detecta o tipo real pelo conteúdo, impõe um limite de tamanho, rejeita qualquer coisa inesperada, renomeia ao salvar e armazena onde código não pode ser executado. > - O **verify** lê o handler, confronta-o com o registro e devolve **risco fechado**: o código faz exatamente o que o registro afirma. > > O mesmo nome de achado atravessa o mapa do detect, o plano e o registro de hardening, e o verify age sobre esse registro com o mesmo nome: um veredito em aberto é escrito no bloco do achado, e um achado comprovadamente fechado é encerrado (`§V`). Esse nome compartilhado é a sua identidade (`§XI`). --- ## V. Encerrabilidade: um achado tem um estado final A maioria das ferramentas de segurança deixa o usuário com um backlog que só cresce. A SDH adota outra posição: **um achado é encerrável, então tem um estado final em vez de viver em um backlog sem fim** (Figura 2). Isso decorre diretamente do princípio de reconciliação. > **Definição** > > **Encerrabilidade:** um risco cujo fechamento foi verificado é encerrado em todo o fluxo, de modo que aquele achado chega a um estado de repouso e só é reaberto quando o código muda. Um achado tem um estado final, ainda que o programa de segurança em si nunca pare. Os artefatos da SDH são documentos vivos, não logs. Sempre que uma fase roda de novo, ela confronta cada entrada existente com a verdade atual e faz uma de três coisas: mantém o que ainda se sustenta, reescreve o que mudou ou remove o que não se aplica mais. Um achado que o código mostra estar resolvido é simplesmente removido. O registro de trabalho reflete o presente, não o passado. O fechamento é essa mesma reconciliação chegando à sua conclusão. Quando o verify comprova que um risco está fechado, ele encerra o achado em todo o fluxo: no mapa do detect, no plano, no registro de hardening e no mapa de rastreamento. É por isso que o verify é a única fase que escreve nos artefatos das outras fases: é a fase que fecha o ciclo. Ao sair da cadeia, o achado encerrado é condensado em uma entrada curta de um registro de histórico que fica fora da cadeia de trabalho e nunca é reprocessado. Essa é a fronteira entre desaparecer e ser fechado: um achado que a reconciliação removeu porque deixou de ser verdadeiro não deixa nada para trás, enquanto um achado comprovadamente fechado ganha a sua linha no histórico. Um achado encerrado fica ausente de todos os artefatos de trabalho dali em diante, e essa ausência é esperada, não uma cadeia quebrada. ```mermaid stateDiagram-v2 direction TB [*] --> OPEN: o detect detecta OPEN --> Plan: plan Plan --> Harden: harden Harden --> Verify: verify Verify --> StoodDown: risco fechado StoodDown --> SETTLED SETTLED --> OPEN: mudanças no código reabrem um achado Plan: plan Harden: harden Verify: verify StoodDown: STOOD DOWN · uma linha no histórico ``` **Figura 2.** A máquina de estados da encerrabilidade. Um achado passa por OPEN → STOOD DOWN → SETTLED e só é reaberto quando o código muda. Quando tudo o que está no escopo foi encerrado, o ciclo entra em repouso, e esse estado de repouso tem uma forma concreta: um artefato cujo último achado foi fechado é removido por inteiro, então uma cadeia totalmente fechada deixa apenas o charter e o histórico, a política e a prova. O ciclo só é reaberto quando o código muda. A metodologia dá a cada achado um fim definido, exatamente o que um backlog sem fim não consegue dar. --- ## VI. A dualidade do extensor do conhecimento do desenvolvedor A SDH não substitui pessoas nem ferramentas especializadas de Blue Team. Ela **amplia o conhecimento do próprio desenvolvedor**. Quanto mais um desenvolvedor entende de segurança, com mais precisão consegue conduzir o fluxo e mais autonomia tem. Um desenvolvedor que entende pouco ainda recebe um resultado seguro, porque o modo automático o protege. A inversão da `§I`, segundo a qual o conhecimento de segurança está na spec, vale nas duas direções. Para o iniciante, ela é proteção: ele não precisa saber o que pedir, porque a spec propõe. Para o especialista, ela é amplificação: a mesma spec permite que ele direcione o fluxo com precisão em vez de lutar contra um checklist fixo. Cada fase carrega essa dualidade no próprio funcionamento (Figura 3). Executada sem nenhuma entrada, ela age sobre todo o escopo em nome do usuário. Com uma direção, a mesma fase se restringe exatamente ao que o usuário apontou. ```mermaid flowchart TB inversion["uma inversão, duas direções:
o conhecimento de segurança está na spec"] inversion --> auto["modo automático (sem entrada)
a fase propõe e age
sobre todo o escopo"] inversion --> directed["modo direcionado (com entrada)
a fase se restringe exatamente
ao que o usuário apontou"] auto --> novice["o iniciante, protegido:
um resultado seguro sem
saber o que pedir"] directed --> expert["o especialista, amplificado:
o fluxo direcionado com precisão,
não um checklist fixo"] novice -.-> phases["as mesmas cinco fases atendem os dois:
charter · detect · plan · harden · verify"] expert -.-> phases ``` **Figura 3.** A dualidade do extensor do conhecimento do desenvolvedor. Uma única inversão atende dois públicos: o modo automático protege o iniciante, e o modo direcionado amplifica o especialista, pelas mesmas cinco fases. As especializações sob demanda (`§VII`) tornam a dualidade explícita no próprio texto. Cada uma diz ao agente que o seu conhecimento "amplia o seu julgamento" e que ele deve continuar raciocinando além do que a especialização oferece. O conhecimento é um piso, não um teto. É isso que atende os dois públicos no equilíbrio que o documento pretende: a comunidade de desenvolvedores ganha um instrumento substancial, e o profissional de Blue Team ganha um veículo estruturado que não finge fazer o trabalho dele. --- ## VII. Especializações não invocáveis e prompt sob demanda Este é o padrão mais original da metodologia. A SDH carrega conhecimento de segurança focado na forma de especializações que são carregadas **apenas sob demanda**, e o próprio agente decide quais carregar associando-as ao contexto do projeto. Chamamos isso de **prompt sob demanda** (prompt-on-demand): uma forma de o agente escolher qual conhecimento ativar com base no escopo do projeto em que está, em vez de executar todas as verificações por padrão. As especializações são evolutivas, e qualquer uma delas pode mudar ou ser substituída a qualquer momento. A contribuição é o padrão, não as especializações em si. > **Definição** > > **Prompt sob demanda:** o agente seleciona qual conhecimento de segurança ativar confrontando-o com o escopo do projeto diante dele, de modo que o conhecimento relevante é carregado para o que o projeto realmente é, em vez de todas as verificações rodarem por padrão. > **Definição** > > **Especialização não invocável:** uma unidade de conhecimento de segurança focada e independente de linguagem, voltada para um contexto, como upload de arquivos ou código que roda no navegador. Ela audita e explica, nunca reescreve código e nunca produz uma entrada de ataque. Ela não é um comando: é carregada quando o contexto que cobre está no escopo, ou quando um prompt a pede pelo nome. Cada especialização nomeia as formas mais seguras para os riscos que cobre e diz ao agente como agir sobre um achado em cada fase que a consome: como avaliá-lo na detecção, como aplicar a correção com segurança na remediação e como comprová-lo na verificação. O traço que a define é que uma especialização **não pode ser invocada por conta própria**: ela não é um comando, e dentro do fluxo é uma correspondência que a carrega. A fase de detecção lista o catálogo uma vez, confronta o contexto do projeto com o que cada entrada cobre e carrega apenas as especializações cujo contexto está presente no escopo. As fases seguintes reutilizam essa lista em vez de listar de novo, então uma única correspondência serve toda a cadeia, e o modo preventivo (`§IX`) faz a mesma correspondência com o trabalho que está prestes a ser construído. Uma especialização cujo contexto está ausente é ignorada, e ignorá-la exige tanta justificativa quanto carregá-la: cada entrada do catálogo recebe um veredito explícito, aplicada ou ignorada, com o motivo tirado do código, de modo que uma vaga impressão de irrelevância nunca substitui a ausência. Não encontrar nenhuma aplicável é um resultado válido. O catálogo é dado, e crescer significa um arquivo de conhecimento a mais e uma linha a mais no catálogo, nunca um novo comando. As especializações nativas são agrupadas em categorias, como OWASP, uma linguagem ou integrações de IA, e o catálogo que um projeto usa contém as nativas das categorias que ele escolheu, mais as suas próprias especializações. O projeto registra essa escolha junto com o resto do seu estado, então uma equipe inteira faz a correspondência com o mesmo catálogo. É o mesmo princípio sensível ao contexto das fases, aplicado ao conhecimento: o conhecimento relevante é carregado para o que o projeto realmente é, em vez de todas as verificações rodarem por padrão. A mesma propriedade permite que o usuário, e não só o mantenedor, amplie o catálogo: uma fonte ou um tema de segurança que o usuário fornece é condensado em uma nova especialização que pertence ao projeto, entra no catálogo dele quaisquer que sejam as categorias e é carregada exatamente como uma nativa, substituindo a nativa de mesmo nome. Criar uma especialização também é algo exclusivamente defensivo e obedece ao mesmo limite que as especializações impõem: um relato de ataque pode ser a fonte, mas a especialização que resulta dele audita e explica, nunca emite um exploit funcional. Assim, a inversão da `§I`, com a inteligência morando na spec, se estende ao próprio catálogo, que o usuário pode aprofundar para o seu contexto sem escrever código. Um exemplo curto ilustra o prompt sob demanda. O detect lê uma pasta de código que roda no navegador. Ele encontra esse contexto no catálogo, carrega a especialização que o cobre e expõe um achado do lado do cliente pelas etapas normais do detect. As especializações cujo contexto está ausente desse escopo não correspondem, então nunca são carregadas, e cada uma é registrada como ignorada. Foi o projeto que decidiu qual conhecimento era relevante, não uma configuração fixa. O determinismo aparece justamente onde importa. Uma especialização pode carregar um verificador determinístico, e não apenas texto: quando uma classe de risco tem um procedimento de decisão bem definido, um pequeno programa devolve um veredito fixo para uma dada entrada, por exemplo um conjunto curto de palavras como `safe`, `unsafe` ou `invalid input`. Algumas classes de risco são decidíveis de forma determinística exatamente assim, com um conjunto de trabalhos anteriores por trás do procedimento de decisão `[9]`, `[10]`, `[11]`. O verificador ou avalia os candidatos que o agente fornece ou varre o escopo para encontrá-los por conta própria, e nos dois casos é o verificador, e não o agente, que devolve o veredito. Uma especialização universal o suficiente pode ser marcada como obrigatória no catálogo e passa a ser sempre aplicada, com o seu verificador rodando sobre todo o escopo. Esse é o único caso em que um conhecimento é carregado sem uma correspondência de contexto, e ele é declarado nos dados do catálogo, nunca decidido pelo agente no momento. É assim que a SDH ancora o raciocínio do agente em algo repetível, sem fingir que todo o fluxo é determinístico. Por fim, as especializações são **destacáveis**. Como o conhecimento se sustenta sozinho, um usuário pode executar uma delas diretamente em um prompt que não tem nada a ver com o fluxo completo da SDH, mantendo a segurança junto do desenvolvimento comum. Uma especialização com um verificador determinístico pode, por exemplo, filtrar cada candidato produzido durante a programação comum e manter apenas os seguros. Essa capacidade de se destacar é parte do motivo pelo qual a SDH se adapta a tantas situações, que são o tema da `§VIII`, e a sua expressão completa é o modo preventivo (`§IX`), em que o mesmo conhecimento protege o desenvolvimento comum de ponta a ponta. --- ## VIII. Independência de estado e adaptabilidade não autoritativa Duas propriedades separam a SDH das metodologias de spec rígidas. ### Independência de estado > **Definição** > > **Independência de estado:** a metodologia não depende do estado do desenvolvimento. Ela se encaixa em um diretório vazio, em um projeto em andamento, em um único pull request ou em uma grande base de código legada, em qualquer stack, porque descobre o ponto de partida lendo-o. Toda fase funciona da mesma forma, seja o projeto totalmente novo ou já existente. O charter infere princípios a partir de qualquer código presente. O detect mapeia o código que houver, mesmo que seja muito pouco. Não existe um ponto de partida pressuposto. ### Adaptabilidade não autoritativa > **Definição** > > **Adaptabilidade não autoritativa:** a metodologia se adapta ao cenário em vez de impor um escopo fixo que o usuário precisa seguir. Quando o usuário não sabe o que dizer, ela lê o ambiente em que foi invocada, gera contexto e faz as perguntas que definem o que ela faz em seguida. O modo de proposta do charter é o caso mais claro: a SDH deriva um charter seguro por padrão analisando o projeto, pergunta ao usuário apenas quando uma lacuna realmente muda o resultado, e então o escreve e apresenta cada princípio em linguagem simples, com o risco que ele previne. O charter é um documento vivo que o usuário reformula executando-o de novo, não um contrato preso a um pedido de aprovação, então ele nunca exige que o usuário saiba o que pedir. Essa adaptabilidade aparece como uma sensibilidade à forma da entrada: a mesma fase lê o que recebeu e escolhe um modo (Figura 4). Um arquivo no prompt, um achado da lista, uma preocupação, uma missão focada contra um ponto fraco conhecido ou um pedido de varredura completa por força bruta: cada um atende à necessidade do usuário, porque o fluxo é não autoritativo por design. Nada disso enfraquece a base segura por padrão. A flexibilidade molda como a base é aplicada, nunca a rebaixa. ```mermaid flowchart TB shape["a fase lê a forma
do que recebeu"] shape --> none["nenhuma entrada"] shape --> paths["um ou mais caminhos"] shape --> concern["uma preocupação descrita"] shape --> finding["um achado nomeado"] shape --> band["uma faixa de prioridade"] none --> auto["o modo automático:
propor ou varrer
todo o escopo"] paths --> focus["focar só nesses
arquivos ou diretórios"] concern --> scoped["restringir o escopo a
essa preocupação"] finding --> item["agir sobre esse único
item rastreado"] band --> priority["agir só sobre crítica,
alta, média ou baixa"] ``` **Figura 4.** Adaptabilidade não autoritativa. A mesma fase lê a forma da sua entrada e escolhe um modo, então o escopo é sempre do usuário, nunca imposto. --- ## IX. O modo preventivo universal: a mesma defesa enquanto o trabalho é construído A SDH tem um modo complementar: o desenvolvimento comum feito com a mesma defesa ativa enquanto o código é escrito. O usuário pede o próprio trabalho, uma página de login, um upload, um endpoint, e a metodologia protege a construção enquanto ela acontece, para que o resultado seja seguro por padrão no momento em que chega, e não depois de uma passada posterior de hardening. > **Definição** > > **O modo preventivo:** o desenvolvimento comum executado sob a camada regente e o conhecimento da SDH. O charter vincula a construção, as especializações relevantes para o que está prestes a ser criado são carregadas sob demanda, e o resultado é confrontado exatamente com a defesa que foi usada antes que o trabalho seja dado como concluído. O modo reaproveita cada peça que as fases já carregam, apontada para um código que ainda não existe. A detecção de contexto se desloca do código para a intenção: o agente raciocina sobre o que está prestes a construir e sobre as fronteiras que esse trabalho atravessa (um login implica credenciais, uma sessão e entrada vinda de fora), e é esse raciocínio que é confrontado com o catálogo de conhecimento. O prompt sob demanda (`§VII`) se generaliza aqui: o contexto pode ser detectado no plano do código, e não apenas no código que já existe. O charter rege como sempre, e um pedido que violaria um princípio é exposto como conflito, nunca construído. A defesa é aplicada na hora, no momento em que cada parte é escrita, validando na fronteira e recorrendo à construção segura logo na primeira vez, então uma versão que funciona mas é insegura nunca chega a existir para ser corrigida. O modo termina do jeito que o verify começa. Antes que o trabalho seja dado como concluído, quem construiu confronta o próprio resultado com a defesa que usou: o controle precisa estar no caminho do risco, e não ao lado dele, precisa estar completo, e, quando uma especialização carrega um verificador determinístico, o veredito do verificador prevalece sobre a leitura do próprio agente. Uma lacuna encontrada aqui é fechada como parte do mesmo trabalho, porque terminar o trabalho significa terminá-lo com segurança. O que o modo recusa é tão deliberado quanto o que ele faz. Ele constrói só o que foi pedido e não audita nada ao redor: auditar o que já existe é papel das fases. Ele não escreve nenhum artefato nem rastreia nenhum achado, porque um achado é um risco detectado no que já existe, e o propósito deste modo é que a versão insegura nunca chegue a existir. As duas direções se completam: as fases fecham o que já está lá (`§V`), e o modo preventivo impede que o trabalho novo o reabra. Uma cadeia em repouso continua em repouso não porque o desenvolvimento parou, mas porque o que é construído enquanto ela repousa já é construído com defesa. --- ## X. Security-Driven Hardening versus Spec-Driven Development O Security-Driven Hardening (SDH) nasceu da base do Spec-Driven Development (SDD) e depois se afastou dele de forma marcante. A herança estrutural é real e reconhecida: spec-first, conduzido por agentes, com um documento regente e um conjunto de comandos em fases que o agente executa. A SDH reaproveita essa estrutura de propósito. O que muda é o propósito, o modelo de autoridade, o estado pressuposto e a condição de término. Tratamos o SDD como uma classe, usando o relatório de Piskala `[1]` como a formulação canônica da metodologia, o Spec Kit do GitHub `[2]` como o toolkit canônico para agentes e o OpenSpec `[3]` como uma segunda ferramenta da mesma família. O SDD inverte o desenvolvimento tradicional ao tornar as especificações executáveis: a spec gera diretamente uma implementação funcional, em vez de apenas orientá-la `[1]`. O seu conjunto de fases conduz uma construção adiante `[2]` (estabelecer os princípios regentes, especificar o que construir, planejar a stack técnica, dividir o plano em tarefas e então implementar). O seu documento regente, uma constituição de princípios, é a peça fundamental à qual o agente precisa aderir do começo ao fim. É aí que está o cerne da diferença. No SDD, a autoridade flui da spec para a construção, e espera-se que a implementação a siga. A SDH inverte quase todos os eixos desse contrato (Tabela 3). > **Ideia central** > > **A diferença central:** no SDD, a autoridade flui da spec para a construção, e espera-se que a implementação a siga. A SDH é não autoritativa e flui no sentido oposto, para dentro, a partir do contexto detectado no sistema, fortalecendo a segurança do que já está lá. | Eixo | SDD | SDH | | -------------------------- | ----------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | | Objetivo | Entregar funcionalidades. A spec se torna uma implementação funcional. | Fortalecer a segurança do que existe ou está sendo construído. Toda fase é orientada para a defesa. | | Modelo de autoridade | Autoritativo. A spec e a constituição confinam a construção a um escopo que ela precisa seguir. | Não autoritativo. A SDH se adapta ao cenário, e o usuário pode reformular, descartar ou restringir o escopo. | | Estado pressuposto | Uma construção adiante a partir de uma especificação. | Independente de estado: diretório vazio, projeto em andamento, um único PR ou código legado. | | Condição de término | Termina quando a funcionalidade está construída. | Encerrável. Um achado chega a um estado de repouso e só é reaberto quando o código muda. | | Documento regente | Uma constituição de princípios à qual o agente precisa aderir. | Um charter de princípios orientados ao risco (cada um com uma linha `Why:`), explicitamente não um contrato fixo. | | Como o conhecimento cresce | Acrescentando um comando (ou ampliando o conjunto de fases). | Acrescentando uma especialização não invocável que o agente carrega sob demanda: um arquivo mais uma linha no catálogo, sem novo comando. | | A quem atende | A quem constrói e leva uma funcionalidade adiante. | Qualquer usuário, desenvolvedor ou não, atendido pelo mesmo fluxo. | | O que altera o código | A fase de implementação gera a construção. | Só a fase harden altera o código, uma correção por vez. | **Tabela 3.** SDD versus SDH em oito eixos. Estrutura emprestada, contrato invertido. Para ser justo com a linhagem: o SDD é um trabalho anterior comprovado, e a SDH deve a ele a estrutura sobre a qual roda. O afastamento não é uma crítica ao SDD, que resolve bem um problema diferente (construir adiante). A SDH pega a mesma maquinaria comprovada e a aponta para a defesa, a adaptabilidade e o fechamento. O OpenSpec `[3]`, organizado em torno de propostas de mudança, listas de tarefas e specs por mudança, confirma o padrão: a família conduz uma construção adiante a partir de uma spec, enquanto a SDH fortalece um sistema para dentro, a partir do seu contexto detectado. Até o modo preventivo da SDH (`§IX`), o único lugar em que ela acompanha uma construção adiante, mantém o contrato invertido: ele rege como o trabalho é construído e nunca decide o que construir. --- ## XI. Rigor de engenharia: a disciplina de rastreamento A disciplina de reconciliar sem nunca só acrescentar (`§V`) precisa de uma base que sobreviva a refatorações. Um achado precisa continuar sendo um único item em todas as fases que o tocam, e um arquivo renomeado ou movido não pode quebrar a cadeia. A SDH resolve isso com **identidade pelo nome** e **caminhos guardados apenas no rastreamento**. > **Definição** > > **Identidade pelo nome:** a identidade de um achado é o seu nome, escrito de forma idêntica em todos os artefatos. O texto carrega o nome, nunca um caminho. Os caminhos de arquivo ficam apenas no mapa de rastreamento, então uma renomeação ou um arquivo movido quebra o vínculo em exatamente um lugar. Cada achado do detect é um item rastreado. A sua identidade é o seu **nome**, o título da seção, escrito de forma idêntica no mapa do detect, no plano e no registro de hardening. As fases seguintes reutilizam esse nome ao pé da letra ao agir sobre o mesmo item, e o verify escreve o seu veredito no registro de hardening com esse mesmo nome. O mapa de rastreamento guarda rastreamento e nada mais, uma entrada por item: ```json { "name": "File uploads", "paths": ["src/routes/upload.ts"] } ``` O mapa não registra texto, anotações, identificador separado nem fase. Os artefatos em texto carregam a redação, e o mapa carrega apenas a identidade e os caminhos. Os caminhos de arquivo são a única coisa volátil, e ficam apenas aqui. Uma renomeação ou um arquivo movido pode quebrar o vínculo em exatamente um lugar, nunca em duas cópias divergentes. ```mermaid flowchart TB detect["o mapa do detect"] --> name plan["o plano de defesa"] --> name harden["o registro de hardening
o verify escreve o veredito aqui"] --> name name["name = "File uploads"
o texto carrega o nome, nunca um caminho"] name -.-> tracking tracking["o mapa de rastreamento
{ name: "File uploads",
paths: ["src/routes/upload.ts"] }
o caminho fica só aqui, então uma renomeação corrige só esta entrada"] ``` **Figura 5.** A esteira da identidade. Um único nome de achado percorre todos os artefatos, enquanto o seu caminho fica apenas no mapa de rastreamento, então uma renomeação é corrigida em um só lugar. Dois atos mantêm o mapa no fluxo normal, e um terceiro fica à parte como manutenção. O **Track** é um registro aditivo: uma fase informa os achados que escreveu, e o engine registra os novos e acompanha um caminho renomeado para os demais, classificando cada um como novo, movido ou inalterado. Ele nunca remove nada que a fase não tenha informado. O **Untrack** encerra os achados que o verify fechou: em uma única passada determinística, ele condensa cada um na sua entrada de histórico, remove a seção inteira dele dos artefatos, apaga um artefato cujo último achado se foi e descarta a sua entrada de rastreamento, de modo que o agente não faz nada disso à mão. Onde a passada determinística não consegue ir com segurança, como um nome encerrado que ainda é citado no texto de outro achado, ele sinaliza o ponto para o agente em vez de arriscar uma edição. Esses dois são os que as fases chamam enquanto rodam. O **Repair** é o ato de manutenção: uma fase o aciona automaticamente quando a sua própria reconciliação encontra o rastreamento inconsistente (um caminho registrado que não existe mais) e, fora isso, ele é executado sob demanda. Ele realinha o mapa inteiro de uma vez, lendo todos os artefatos e o código atual, corrigindo os caminhos de cada item e expondo o que não consegue decidir sozinho: um órfão (um item rastreado que nenhum artefato menciona mais) ou um candidato a renomeação (um item cujos caminhos correspondem a outro nome informado). O Repair é manutenção, não uma sexta fase. Ele não toca no código do usuário nem nos artefatos em texto, apenas no rastreamento. Ele lê o código-fonte do usuário por um único motivo, descobrir o novo caminho de um arquivo renomeado, e nunca escreve conteúdo de segurança. A pessoa é a árbitra final na única decisão que o engine se recusa a adivinhar: se um item que sumiu foi resolvido ou apenas renomeado. É melhor perguntar do que adivinhar, porque um item descartado por engano quebra a cadeia. A metodologia aplica a si mesma a sua própria disciplina de defesa. Os engines determinísticos são invocados como programas de linha de comando, e cada entrada é passada como um argumento de processo separado, o que a mantém inerte, então um valor com aspas ou crases nunca consegue se injetar no comando. Uma verificação desconhecida falha em vez de responder, então uma verificação com o nome digitado errado nunca é lida como um resultado limpo. A SDH não isenta a sua própria infraestrutura do princípio seguro por padrão. --- ## XII. O veículo: uma arquitetura independente de agente como prova de portabilidade Para que a SDH seja uma convenção que outros adotem, ela não pode estar presa a um agente nem a uma stack, então o seu veículo mantém três responsabilidades separadas (Figura 6). O Lagune comprova que isso é possível. **O valor de segurança** é escrito uma única vez e não sabe nada sobre qual agente o executa: as instruções das fases e os templates que elas preenchem, o catálogo de conhecimento e os engines determinísticos. **A entrega** é enxuta: a sua única tarefa é levar esse valor a um agente na forma e no lugar que ele espera, e ela não carrega nenhuma lógica de segurança própria. **O estado do projeto** pertence ao projeto: o charter, os artefatos das fases, o mapa de rastreamento, as categorias que ele escolheu e as suas próprias especializações, versionados e revisáveis como qualquer outra parte do código. ```mermaid flowchart TB value["o valor de segurança, escrito uma única vez
instruções das fases · templates · catálogo de conhecimento · engines determinísticos
não sabe nada sobre qual agente o executa"] delivery["a entrega
leva esse valor a cada agente na forma que ele espera
não carrega lógica de segurança"] agent["o agente
executa as fases"] project["o estado do projeto
versionado com o código
charter · artefatos das fases · rastreamento · categorias · especializações próprias"] value --> delivery --> agent agent -->|"lê e escreve"| project ``` **Figura 6.** O veículo independente de agente. O valor de segurança é escrito uma única vez, uma entrega enxuta o leva a cada agente, e o estado continua sendo do projeto. Como a entrega não carrega lógica de segurança, a forma como ela é construída não muda nada na SDH. Um veículo pode construir a entrega por conta própria ou passá-la a um ecossistema que já distribui skills para agentes, como faz a implementação de referência, e as fases, os seus artefatos e as suas garantias continuam os mesmos. Nada disso é específico de uma linguagem ou de um runtime. A implementação de referência por acaso é escrita em uma stack, mas a metodologia é a fronteira entre essas responsabilidades, não o conjunto de ferramentas que as constrói. O mesmo design poderia ser reimplementado em outra linguagem sem mudar o que a SDH é. --- ## XIII. Caso prático: a SDH de ponta a ponta > **Caso prático** > > **Hardening defensivo de uma superfície de upload e de administração.** > **Contexto:** um app pequeno que aceita uploads de arquivos dos usuários e os lista em uma página de administração. > **Padrão:** charter → detect (com conhecimento sob demanda ativado pelo contexto) → plan → harden → verify, com um fechamento e uma falha real. > **Resultado (capacidade):** um risco verificado como fechado e encerrado em toda a cadeia, e um controle verificado como _não_ fechado e devolvido ao harden. O veredito reflete o código, não o registro. _Este é um exemplo ilustrativo do funcionamento da metodologia, não um estudo medido em campo, e não relata métricas de eficácia._ Um único passo a passo contínuo mostra a metodologia em funcionamento, e não apenas as suas partes. Estendemos o fio condutor do upload de arquivos da `§IV` com uma ativação de conhecimento sob demanda e um fechamento, e incluímos uma falha real. 1. O **charter** propõe o princípio "Toda entrada é não confiável até ser validada", com o seu risco em linguagem simples: uma entrada que não é verificada é a forma mais comum de um sistema ser invadido. 2. O **detect** analisa a rota de upload e a pequena página de administração que lista os arquivos enviados. Ele detecta o achado do upload (o handler confia no tipo MIME informado pelo cliente). A página de administração roda no navegador, um contexto que o prompt sob demanda (`§VII`) reconhece, então o detect carrega a especialização desse contexto e expõe um segundo achado: um ponto em que um nome de arquivo é escrito na página como markup, e não como texto, de modo que um nome manipulado pode rodar como script no navegador de quem visita. As especializações cujo contexto está ausente desse escopo nunca são carregadas, e cada uma que é ignorada fica registrada com a ausência constatada no código. 3. O **plan** atribui à correção do upload a prioridade crítica, vinculada ao princípio: verificar o tipo real e o tamanho do arquivo, renomeá-lo ao salvar e armazená-lo onde código não pode ser executado. Ele atribui à segunda correção a prioridade alta: renderizar o nome do arquivo como texto, não como markup. 4. O **harden** aplica primeiro a correção do upload (a de maior prioridade) e a registra como Applied, e depois a segunda, também como Applied. 5. O **verify** lê cada ponto e confronta o código com o registro. O controle do upload se sustenta: o handler detecta o tipo real pelo conteúdo, impõe um limite de tamanho e recusa o resto. Veredito: risco fechado. O verify encerra o achado do upload em toda a cadeia, e o seu resumo condensado vai para o histórico. Em seguida vem a falha real. Suponha que a segunda correção do harden tenha acrescentado um helper seguro de renderização de texto, mas deixado a antiga chamada que escreve markup ainda alcançável por outro caminho no código. O verify lê a página, vê o helper seguro e também vê que o caminho inseguro continua ativo. O controle está presente, mas o risco não está fechado. O verify se recusa a suavizar o veredito para coincidir com o registro. Ele devolve "risco não fechado", registra a lacuna e aponta de volta para o harden. Um controle que não trata o risco por completo não é uma aprovação. Este é o caráter da metodologia em um único exemplo: detecção sensível ao contexto, correções priorizadas e vinculadas a princípios, aplicação cuidadosa e uma verificação que relata o estado real do código, independentemente do registro. --- ## XIV. Quando usar a SDH, e os seus limites A SDH raramente é desproporcional como um processo pesado pode ser, porque é independente de estado e encerrável: ela se reduz a um único arquivo e a uma única preocupação, e chega a um estado de repouso em vez de deixar um fardo permanente. O seu limite não é o tamanho do projeto, e sim a **profundidade da garantia**. ```mermaid flowchart TB q1{"O código faz algo relevante para a segurança?
(entrada, autenticação, dados, segredos, chamadas externas)"} q1 -->|não| little["A SDH acrescenta pouco aqui."] q1 -->|sim| q2{"Rode a SDH. Existe uma exigência de compliance
ou uma função de segurança dedicada?"} q2 -->|não| baseline["A SDH é uma base defensável."] q2 -->|sim| carrier["A SDH é o veículo estruturado:
ela apoia a revisão e a auditoria especializadas,
não as substitui."] ``` **Figura 7.** Quando usar a SDH. A decisão passa primeiro pela relevância para a segurança e depois pela profundidade da garantia, nunca pelo tamanho do projeto. Onde a SDH chega ao seu limite: comportamentos que só aparecem quando o sistema está em execução (o verify lê o código, não executa o sistema), riscos que dependem de uma configuração ou de um ambiente que o agente não consegue ler e contextos de alto risco em que a revisão por especialistas é necessária de qualquer forma. Em cada um desses casos, a SDH ainda agrega valor como uma primeira passada estruturada, mas é um piso, não um teto. > **Ideia central** > > **O limite:** o limite da SDH é a profundidade da garantia, não o tamanho do projeto. Ela pode servir como uma base defensável em quase qualquer lugar e apoia a revisão por especialistas onde o que está em jogo exige, mas não substitui os testes de um sistema em execução nem o julgamento de um profissional de segurança. --- ## XV. Discussão: posicionamento, limites e o que a SDH não afirma A SDH é precisa sobre os seus limites. ### Ela amplia, não substitui A SDH não substitui profissionais de segurança nem ferramentas especializadas de Blue Team. Ela amplia o conhecimento do desenvolvedor (`§VI`). Uma afirmação comedida é a afirmação certa: bem aplicada, a SDH **pode** fechar riscos reais de forma eficaz, principalmente em projetos que de outro modo não receberiam nenhuma revisão de segurança. Ela não é uma garantia nem substitui a revisão por especialistas onde o que está em jogo a exige. ### Somente defesa, por construção A SDH audita, fortalece e verifica. Ela nunca produz ferramentas ofensivas, exploits nem técnicas de evasão de detecção para causar dano. Conteúdo de segurança de uso duplo só é aceitável em um enquadramento claramente defensivo e autorizado. Esse é um limite rígido, não uma preferência. ### A verificação é substantiva, não teatral O verify verifica lendo o código e confrontando-o com o registro, não executando o sistema. Essa é uma verificação estática: ela confirma que um controle está presente e correto no código, e não comprova que o controle resiste a um ataque em tempo de execução. Por isso, "não dá para saber pelo código" é um veredito legítimo, e não uma falha escondida atrás de um resultado aprovado. Quando a evidência não está no código (depende de configuração ou de um caminho que o agente não consegue ler), a SDH diz isso em vez de adivinhar. ### O determinismo é delimitado e nomeado A maior parte da SDH é raciocinada pelo agente, e é isso que viabiliza a sua sensibilidade ao contexto. O determinismo fica reservado aos engines determinísticos: os verificadores que uma especialização pode carregar (`§VII`) e o engine de rastreamento (`§XI`). O documento não borra essa linha. Onde um resultado é determinístico, ele é o resultado de um programa. Onde é raciocinado, ele é a leitura que o agente faz do código, com o usuário como árbitro final. ### Custo e escala Uma varredura completa consome muitos tokens. Os modos manuais (`§VI`, `§VIII`) existem em parte para manter o custo proporcional à preocupação. ### O usuário é o árbitro final A SDH pede à pessoa que decida entre renomeado e resolvido, e a aprovação das edições de código continua onde o usuário já governa o seu agente, no modo de permissão em que o executa. A metodologia propõe e verifica. Ela não passa por cima da pessoa. ### Objeções e respostas Um cético justo levantará várias objeções. As mais substantivas merecem ser apresentadas nas próprias palavras. **"Isso não é só um analisador estático com um LLM acoplado?"** Não. Um analisador estático executa por padrão todas as regras que tem. A SDH primeiro detecta o que o sistema é e só então recorre ao conhecimento relevante (`§II`, `§VII`), e ela _embute_ um verificador determinístico apenas onde uma classe de risco tem um procedimento de decisão bem definido. O raciocínio parte do contexto, e o determinismo é pontual. **"Isso não é só um checklist de segurança?"** Não. A SDH inverte o checklist: a detecção vem primeiro, e o conhecimento é carregado para o que o projeto realmente faz (`§II`, `§VII`). **"Isso não é só o SDD com um novo nome para segurança?"** Não. A SDH empresta a estrutura do SDD e inverte o seu contrato: a autoridade, o estado pressuposto, a condição de término e o público atendido são todos diferentes (`§X`). A mesma maquinaria, na direção oposta. **"Um método raciocinado por IA não acaba alucinando achados?"** O design restringe a invenção em vez de confiar que o modelo vai se comportar. O detect registra só o que o código sustenta ("detecção, não invenção", `§IV`), o verify confronta o código com o registro e pode responder "não dá para saber pelo código" (`§XV`), verificadores determinísticos fundamentam os casos decidíveis (`§VII`) e o usuário é o árbitro final. Isso não torna o agente infalível, torna as suas afirmações verificáveis. Uma nota sobre o posicionamento. A SDH é definida aqui de forma independente da sua implementação de referência. As cinco fases, o charter orientado ao risco, a reconciliação sem nunca só acrescentar e a sua encerrabilidade, o conhecimento por prompt sob demanda, o modo preventivo, o rastreamento por identidade pelo nome e o limite de somente defesa são a metodologia. Outra equipe poderia implementá-los em outra stack e em outro ecossistema de agentes, e o resultado continuaria sendo SDH. O Lagune é a sua prova, não a sua definição. --- ## XVI. Armadilhas, e como a SDH as evita pela estrutura As metodologias desta família compartilham um conjunto conhecido de falhas. A resposta da SDH à maioria delas é estrutural, embutida no fluxo em vez de deixada à disciplina. | Armadilha | A falha | A resposta estrutural da SDH | | -------------------------------------- | ----------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | | Spec apodrecida, backlog desatualizado | Os artefatos acumulam entradas mortas em que ninguém confia | Reconciliar, nunca só acrescentar (`§V`): cada execução revisa cada entrada e remove o que foi resolvido | | Falsa confiança, resultado aprovado | Presume-se que um controle presente fecha o risco | O verify confronta o código com o registro, então "risco não fechado" e "não dá para saber" são vereditos de primeira classe (`§IV`, `§XV`) | | Enxurrada de checklist | Itens genéricos encobrem o único risco que importa | Sensível ao contexto em vez de genérico, com o prompt sob demanda carregando só o que o escopo pede (`§VII`) | | Aprisionamento a ferramentas | O método fica soldado a um único fornecedor ou agente | Veículo independente de agente: o valor de segurança é escrito uma única vez, e a sua entrega a cada agente não carrega lógica de segurança (`§XII`) | | O ciclo sem fim | O backlog nunca fecha, o trabalho nunca descansa | A encerrabilidade e o estado de repouso (`§V`) | **Tabela 4.** Armadilhas conhecidas nesta família de metodologias e a resposta estrutural da SDH a cada uma. O que importa é nomear a armadilha e apontar o mecanismo: não são avisos para tomar cuidado, são propriedades do fluxo. --- ## XVII. Trabalhos futuros A metodologia e a sua implementação de referência têm próximos passos claros. - **Ampliar o catálogo de conhecimento:** Cada acréscimo mantém o formato da `§VII`: um arquivo de conhecimento e uma linha no catálogo, sem novo comando. O caminho do lado do usuário já existe ali: o usuário condensa as próprias especializações sob demanda. Mais linguagens, runtimes e classes de risco nativos, cada um entrando em uma categoria, são a direção do lado do mantenedor, e espera-se que as especializações evoluam. - **Mais verificadores determinísticos:** Quando uma classe de risco tem um procedimento de decisão bem definido, uma especialização pode carregar um verificador determinístico que ancora o raciocínio do agente em um veredito repetível. Estender isso a mais classes de risco é uma direção natural. - **Avaliação empírica:** A principal questão em aberto é a eficácia medida: a qualidade dos fechamentos e as taxas de vereditos falsos em bases de código reais. Um estudo dos resultados de segurança da SDH é trabalho futuro, e as afirmações aqui são delimitadas de acordo. --- ## XVIII. Conclusão O desenvolvimento assistido por IA abriu uma lacuna de segurança que checklists genéricos não conseguem preencher, porque o risco que importa é específico do que um sistema realmente faz, e quem o entrega talvez não saiba o que pedir. A SDH fecha essa lacuna com um fluxo sensível ao contexto, exclusivamente defensivo e encerrável, em que o conhecimento de segurança está na metodologia e nas suas especializações sob demanda, uma base sobre a qual todo usuário pode construir. Ela detecta o contexto real do sistema, faz a triagem dos riscos que esse contexto traz, aplica as correções com cuidado e verifica cada uma, e então encerra o que fechou, para que cada achado chegue a um estado final. A mesma defesa também roda de forma preventiva enquanto o trabalho novo é construído, então o que o fluxo fecha continua fechado. Ela se adapta a qualquer estado de desenvolvimento, em qualquer stack, e amplia o conhecimento do desenvolvedor em vez de substituir as pessoas e as ferramentas que já fazem esse trabalho. O Lagune é a prova, mas a contribuição é a convenção. A SDH é oferecida como o fluxo de segurança essencial para a era do desenvolvimento com IA, para que outros a adotem, a refinem e a implementem nas próprias stacks. --- ## Referências **[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. (Submetido ao AIWare 2026.) [Online]. Disponível em: https://arxiv.org/abs/2602.00180 **[2]** GitHub, "Spec Kit: Toolkit for Spec-Driven Development." [Online]. Disponível em: https://github.com/github/spec-kit. Acesso em: 2026. **[3]** Fission AI, "OpenSpec: Spec-Driven Development for AI Coding Assistants." [Online]. Disponível em: https://github.com/Fission-AI/OpenSpec. Acesso em: 2026. **[4]** B. Chess e 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]. Disponível em: https://owasp.org/www-community/Source_Code_Analysis_Tools. Acesso em: 2026. **[6]** OWASP Foundation, "OWASP Top 10:2021." [Online]. Disponível em: https://owasp.org/Top10/. Acesso em: 2026. **[7]** MITRE, "Common Weakness Enumeration (CWE)." [Online]. Disponível em: https://cwe.mitre.org/. Acesso em: 2026. **[8]** N. Perry, M. Srivastava, D. Kumar e 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]. Disponível em: https://arxiv.org/abs/2211.03622 **[9]** J. Davis e colaboradores, "safe-regex: Detect Possibly Catastrophic, Exponential-Time Regular Expressions." [Online]. Disponível em: https://github.com/davisjam/safe-regex. Acesso em: 2026. **[10]** D. Soshnikov, "regexp-tree: Regular Expressions Processor in JavaScript." [Online]. Disponível em: https://github.com/DmitrySoshnikov/regexp-tree. Acesso em: 2026. **[11]** T. Jenkinson, "redos-detector: A CLI and Library to Score How Vulnerable a Regex Pattern Is to ReDoS Attacks." [Online]. Disponível em: https://github.com/tjenkinson/redos-detector. Acesso em: 2026. --- ## Apêndice A: os princípios, na íntegra 1. **Seguro por padrão, em linguagem simples, para todos igualmente:** Todo padrão, mensagem e correção precisa ser seguro desde o início e compreensível para qualquer usuário, desenvolvedor ou não. Nenhum tipo de usuário é privilegiado em relação a outro. 2. **Sensível ao contexto em vez de genérico:** Toda fase precisa partir do contexto identificado no detect e agir sobre o que o sistema realmente faz. Prefira recomendações específicas desse contexto a checklists genéricos. O conhecimento de segurança está na spec e nas suas especializações sob demanda, ampliando o que o usuário traz. 3. **Flexível em vez de rígido:** A SDH se molda ao projeto e ao usuário. Princípios, requisitos e recomendações são pontos de partida, não um contrato fixo. Deixe o usuário reformular, descartar, acrescentar ou restringir o escopo de qualquer coisa. A flexibilidade nunca enfraquece a base segura por padrão, apenas permite que o usuário molde a forma como ela é aplicada. 4. **Reconciliar, nunca só acrescentar:** Os artefatos são documentos vivos, não logs. Quando uma fase roda de novo, reconcilie cada entrada existente com a verdade atual: mantenha o que ainda se sustenta, reescreva o que mudou e remova o que não se aplica mais. O fechamento é essa mesma reconciliação chegando à sua conclusão. 5. **Somente defesa:** A SDH audita, fortalece e verifica. Ela nunca produz ferramentas ofensivas, exploits para uso malicioso nem técnicas de evasão de detecção para causar dano. Conteúdo de segurança de uso duplo só é aceitável em um enquadramento claramente defensivo e autorizado. 6. **Spec-first, conduzido por agente, orientado para a segurança:** Construa o fluxo a partir de uma estrutura comprovada: templates, comandos, um charter regente e um agente que executa as fases. Reimplemente essa estrutura com um propósito defensivo. --- # Glossário do Lagune: SDH, charter, achados e controles > Definições em linguagem simples de cada termo do Lagune e do Security-Driven Hardening: SDH, charter, detect, achado, controle, harden, verify, encerramento, closability, especializações, categorias e o catálogo. Canônica: https://lagune.ai/pt-BR/docs/references/glossary Idioma: pt-BR Original: https://lagune.ai/docs/references/glossary Última atualização: 2026-11-03 Cada termo essencial do Lagune e da metodologia Security-Driven Hardening, definido uma única vez e em linguagem simples. ### Security-Driven Hardening (SDH) A metodologia que o Lagune implementa: uma convenção Blue Team e sensível ao contexto que detecta o contexto de um sistema, faz a triagem dos riscos que esse contexto traz e orienta as correções. O conhecimento de segurança fica na spec e nas especializações sob demanda dela, então quem desenvolve e quem não desenvolve são atendidos pelo mesmo fluxo. ### Lagune A implementação de referência do SDH: nove comandos de agente, cada um com o template que preenche, que um agente de IA executa para fortalecer a segurança de um código. Cada agente os instala pelo próprio instalador de plugins ou pelo [**skills.sh**](https://www.skills.sh/wellwelwel/lagune), como mostra a [página de instalação](https://lagune.ai/pt-BR/docs), e eles rodam o engine do Lagune em cada etapa determinística. ### Charter A camada que rege o Lagune: um conjunto de princípios de segurança, com a segurança em primeiro lugar, que todas as fases seguintes precisam respeitar. Pense nele como a verificação em tempo de compilação da postura de segurança de um projeto. Ele fica em `.lagune/memory/charter.md`. ### Fluxo de desenvolvimento O comando universal `/lagune`, que aplica hardening ao trabalho enquanto ele é escrito. Ele aceita qualquer prompt em qualquer etapa, constrói o que você pediu e o protege com padrões seguros antes de devolvê-lo, guiado pelo charter quando existe um. Ele não grava nada no rastreamento do Lagune, então o único produto dele é o código fortalecido. Junto com o charter (antes) e o fluxo Blue Team (depois), é assim que o Lagune protege durante o desenvolvimento. ### Fluxo Blue Team A auditoria de cinco fases no centro do Lagune: charter, detect, plan, harden e verify. Cada fase se apoia na anterior. "Blue Team" é a tradição de segurança dos defensores, em oposição ao Red Team, que é ofensivo. ### Achado Um risco detectado. Cada achado traz o que ele é, por que importa e a evidência no código. Um achado é a unidade rastreada que o plan, o harden e o verify levam adiante, identificada pelo nome em todos os artefatos. ### Controle Uma medida de segurança aplicada para eliminar um risco. O harden aplica controles, e o verify comprova que eles se sustentam. O Lagune nunca enfraquece um controle para atender a um prompt. ### Detect A fase que lê o código e mapeia o que o sistema faz e onde estão os riscos. A regra que a rege é detectar, não inventar: ela registra apenas o que o código sustenta. ### Harden A única fase que mexe no seu código. Ela aplica as correções do plano uma de cada vez e registra cada uma como Applied, Partial ou Blocked. Applied ainda não significa comprovada. ### Verify A fase que comprova que cada correção aplicada se sustenta, lendo o código e confrontando-o com o que o harden registrou. Ela devolve um de três vereditos: Risk closed, Risk not closed ou Cannot tell from the code. ### Encerramento (stand down) Quando o verify comprova que um risco foi eliminado, o achado é encerrado: removido da cadeia inteira, com a sua confirmação, para que deixe de ser reprocessado. ### Closability A propriedade de o trabalho de segurança ter um estado final. Como um achado comprovadamente resolvido é encerrado, o fluxo pode entrar em repouso e só é reaberto quando o código muda. O SDH é encerrável, e não um ciclo sem fim. ### Engine O pacote `lagune` no **npm**, que os comandos executam via `npx` em cada etapa determinística: os hooks, o catálogo e as categorias. ### Especialização Um módulo focado de conhecimento de segurança, independente de linguagem, que carrega apenas sob demanda, nunca por padrão. Uma especialização não é um comando. Carregue uma em qualquer prompt com o `read catalog ` do engine, por exemplo `npx lagune read catalog regex`. ### Categoria Um grupo nomeado de especializações nativas, do `owasp` às de cada linguagem, como `javascript`, `python`, `go` e `rust`. As categorias que um projeto usa, registradas em `.lagune/configs.json`, decidem quais especializações nativas entram no catálogo dele. Enquanto nenhuma estiver registrada, o projeto usa apenas o `owasp`. ### Catálogo O conjunto de especializações que um projeto usa: as nativas das categorias dele mais as próprias, escritas com o `/lagune-specialize`. O `read catalog` do engine lista o catálogo, e as fases o comparam com o código. ### Prompt-on-demand O princípio de que o conhecimento de segurança relevante é carregado para o que o projeto realmente é, em vez de todas as verificações rodarem por padrão. ### Identity-by-name O modelo de rastreamento do Lagune: o nome de cada achado, escrito de forma idêntica como título de seção em todos os artefatos, é a identidade dele em toda a cadeia. O mapa de rastreamento (`.lagune/tracking.json`) guarda apenas rastreamento, nunca texto. ## Perguntas frequentes ### O que é Security-Driven Hardening (SDH)? O SDH é uma metodologia de segurança Blue Team e sensível ao contexto. Ela detecta o contexto de um sistema, faz a triagem dos riscos que esse contexto traz e orienta as correções, mantendo cada achado em linguagem simples. O Lagune é a implementação de referência dela. ### O que é o charter no Lagune? O charter é a camada que rege o Lagune, um conjunto de princípios de segurança que todas as fases seguintes precisam respeitar. Ele fica em .lagune/memory/charter.md. ### O que significa encerrar um achado? Quando o verify comprova que um risco foi eliminado, o achado é encerrado: removido da cadeia inteira com a sua confirmação, para que deixe de ser reprocessado. --- # Schema de configuração > O JSON Schema das configurações de um projeto Lagune, para autocompletar e validar no seu editor, acompanhando a versão atual do Lagune ou fixado em uma versão. Canônica: https://lagune.ai/pt-BR/docs/references/configs-schema Idioma: pt-BR Original: https://lagune.ai/docs/references/configs-schema Última atualização: 2026-11-03 O `.lagune/configs.json` registra as [**categorias**](https://lagune.ai/pt-BR/docs/categories) que um projeto usa e indexa as [**especializações**](https://lagune.ai/pt-BR/docs/catalog) próprias dele. O JSON Schema desse arquivo permite que o seu editor autocomplete cada campo e aponte um erro de digitação ou uma categoria desconhecida enquanto você edita o arquivo. ## O schema atual Sempre que o **Lagune** grava o arquivo e não encontra um `$schema` nele, aponta o arquivo para o schema atual: ```json { "$schema": "https://lagune.ai/schemas/configs.json", "categories": ["owasp", "javascript"] } ``` Esse endereço sempre acompanha a versão atual do **Lagune**. Um arquivo gravado antes do **Lagune** 0.16.0 recebe o endereço na próxima alteração, e todas as fases avisam sobre isso até lá. ## Fixe uma versão Cada release do **Lagune** a partir da 0.16.0 traz o schema como ele era naquela versão, publicado no **npm** e servido pelo **jsDelivr**. Para fixar uma, troque o `$schema` pela versão depois de `lagune@`: ```json { "$schema": "https://cdn.jsdelivr.net/npm/lagune@0.16.0/schemas/configs.json" } ``` A versão aceita qualquer intervalo semver: | Versão | Schema | | ------------------ | ------------------------------ | | `0.16.0` | O da 0.16.0 | | `0.16.x` ou `0.16` | O da release 0.16 mais recente | | `0.x` ou `0` | O da release 0.x mais recente | | `latest` | O da release mais recente | ## Perguntas frequentes ### O Lagune precisa do schema? Não. O schema só ajuda o seu editor, e o Lagune lê o arquivo do mesmo jeito, com ou sem $schema. ### O Lagune sobrescreve um schema fixado? Não. O Lagune só grava o $schema quando o arquivo não tem nenhum, e mantém qualquer endereço que você definir. ### Quando devo fixar uma versão? Quando o projeto roda uma versão específica do Lagune, para que o seu editor valide o arquivo de acordo com o que essa versão aceita. --- # Lagune vs. Deepsec: duas abordagens de segurança com IA lado a lado > Uma referência que compara o Lagune e o Deepsec, da Vercel, em funcionamento, ciclo de vida, detecção, custo, achados e encerramento. Canônica: https://lagune.ai/pt-BR/docs/references/deepsec Idioma: pt-BR Original: https://lagune.ai/docs/references/deepsec Última atualização: 2026-11-03 O [Lagune](https://github.com/wellwelwel/lagune) e o [Deepsec](https://github.com/vercel-labs/deepsec) (`v2.2.1`) são duas respostas defensivas ao mesmo problema: a segurança na era do desenvolvimento assistido por IA. A premissa, o começo, o meio e o fim de cada um, e a forma como cada um se apresenta ao usuário, divergem de propósito, mesmo onde os mecanismos se sobrepõem. **Dica** O Lagune é inspirado no Deepsec? Não. O Lagune foi escrito do zero e se inspira em Spec-Driven Development e em Security Hardening. Os dois projetos foram desenvolvidos de forma independente, e a comparação aqui serve para ajudar os usuários a entender as diferenças entre eles. ## Visão geral | Aspecto | Lagune | Deepsec | | ------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- | | Tipo | Uma metodologia (SDH) com uma implementação de referência | Um produto: um scanner de vulnerabilidades movido a agentes | | Centro de gravidade | Um charter e conhecimento sob demanda conduzem o agente, com base em hooks determinísticos | Uma rede ampla de regex alimenta uma investigação obrigatória por IA | | O que produz | Código fortalecido, provas e uma cadeia rastreada de achados | Um relatório de achados triados e ordenados por severidade | | Mexe no seu código | Sim: o `harden` edita o seu código | Não: apenas análise estática, emite achados e texto de recomendação | | Execução | Roda no agente e no modelo que você já usa, de qualquer nível | Roda o próprio pipeline de modelos, um modelo de ponta por padrão | | Primeiros passos | Uma instalação de plugin ou `npx skills add`, e depois você o conduz em linguagem simples, sem nenhuma ferramenta nova para montar | Montar um workspace `.deepsec/`, instalar as dependências e adicionar uma chave de modelo | ## Como funciona O Lagune é agent-first: o agente conduz, carrega conhecimento sob demanda para o que o código é e delega uma parte decidível aos hooks determinísticos. O Deepsec é deterministic-first: uma varredura ampla sinaliza candidatos que direcionam um modelo obrigatório para o que investigar e julgar. | Aspecto | Lagune | Deepsec | | ------------------------ | ------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------- | | Ordem | O charter e o conhecimento correspondente orientam o agente, que delega aos hooks e julga o resto | Os matchers sinalizam candidatos, e o modelo investiga e julga cada um | | Papel determinístico | Hooks multilinguagem que devolvem um veredito ou direcionam o agente, combinados com o conhecimento das categorias | Matchers que sinalizam candidatos para o modelo obrigatório julgar | | Fluxo de desenvolvimento | O `/lagune` constrói com segurança, no próprio fluxo, enquanto você programa | Ele revisa código, não o escreve | | Fluxo de auditoria | `charter` → `detect` → `plan` → `harden` → `verify` | `scan` → `process` → `triage` → `revalidate` → `report` | | O papel da IA | Raciocinar a partir do conhecimento, aplicar a correção e comprovar que ela se sustenta | Investigar cada candidato e relatar os achados | ## Ciclo de vida O Lagune atua antes, durante e depois de o código ser escrito. O Deepsec revisa um repositório depois que o código existe. | Momento | Lagune | Deepsec | | ------------------------- | ------------------------------------------------------------------------------------ | ------------------------------------------------------------------------- | | Antes de o código existir | O `charter` cria uma política de segurança a partir da intenção declarada | Parte de código existente: o `init` precisa de um diretório | | Durante o desenvolvimento | O `/lagune` constrói com segurança por padrão, no próprio fluxo, sem deixar artefato | Revisa depois do desenvolvimento, não durante | | Em código existente | `detect` → `plan` → `harden` → `verify` | `scan` → `process`, o fluxo principal | | Revisão contínua | Reexecuta as fases por escopo, sem um gate de CI pronto | Nova varredura incremental, com `process --diff` como gate de saída no CI | ## Camada de detecção As duas camadas determinísticas são de naturezas opostas: uma decide, a outra sinaliza. | Aspecto | Lagune | Deepsec | | ---------------- | ------------------------------------------------------------------------------ | --------------------------------------------------------------------------- | | Agrupamento | Hooks e especializações, agrupados em categorias | Matchers por padrão ou framework | | Saída | Veredito literal (finding / review / advisory) mais um rótulo de classificação | Candidato sem veredito (slug, linhas, trecho, padrão correspondente) | | Ajuste | Precisão: ciente de comentários, com proteções contra placeholders e de janela | Recall: redes amplas, e a IA elimina os falsos positivos depois | | Profundidade | Mais profundo nas classes em comum | Mais amplo, menos profundo nas classes em comum | | Falsos positivos | Mantidos baixos na origem e depois julgados em contexto | Gerados em excesso de propósito e reduzidos por uma passada de `revalidate` | ## Conhecimento e julgamento Os dois carregam conhecimento de segurança que o regex não alcança. A diferença está em onde ele fica e em quem pode moldá-lo. | Aspecto | Lagune | Deepsec | | ---------------------- | ----------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- | | Formato | Módulos em markdown editáveis, vários deles apoiados por um hook determinístico | Um prompt curto e destaques por tecnologia, apoiados no conhecimento do próprio modelo | | Seleção | Combinado com o código, carregado apenas quando o contexto dele está presente | Injetado em todo lote de IA, mais os destaques para a tecnologia detectada | | Quem escreve | O usuário edita os módulos e adiciona novos com o `specialize` | O mantenedor é dono do prompt, e o usuário preenche um `INFO.md` | | Onde fica o julgamento | Os hooks decidem o patamar deles, e o agente julga o resto a partir do conhecimento | Centralizado: um único processador de IA julga todos os candidatos | | Reuso | Um único módulo orienta tanto o `detect` quanto o `verify` | Um único prompt conduz a etapa única de `process` | ## Achados e encerramento É no que um achado se torna depois de resolvido que eles mais divergem. | Aspecto | Lagune | Deepsec | | -------------------- | --------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- | | Severidade | Uma nota CVSS v4.0, ajustada pela exposição e pelo que está em jogo | Uma severidade dada pela IA, mais uma triagem P0 / P1 / P2 de explorabilidade e impacto | | Vereditos | Risk closed, Risk not closed ou Cannot tell from the code | true-positive, false-positive, fixed, uncertain, accepted-risk, duplicate | | Persistência | A cadeia de trabalho se reconcilia, e os achados encerrados viram um histórico resumido | Registros por arquivo, só acrescentados, sem nada removido | | Estado final | Encerrável: um achado comprovado é encerrado, e a cadeia pode entrar em repouso | Todo achado fica guardado para sempre, oculto das visões depois de resolvido | | Detalhe do histórico | Um resumo compacto do que era o risco | A trilha completa de vereditos, incluindo como foi corrigido | ## Custo | Aspecto | Lagune | Deepsec | | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Patamar determinístico | Grátis: os hooks rodam sem IA e sem chave e já emitem vereditos | Grátis: o `scan` roda sem IA, mas não emite vereditos sozinho | | Conta típica | Embutida em um agente que você já usa, chegando a $0 com um modelo local, ao preço do plano que você já tem ou por iteração no uso via API | [Aproximadamente de $25 a $1.200 por execução para 100 a 2.000 arquivos, e mais em escala](https://github.com/vercel-labs/deepsec/blob/f75a16803ec5250938bacfe41571d929e8564f45/docs/getting-started.md#run-the-ai-investigation) | | Caminho mais barato | Qualquer modelo, inclusive um local e gratuito, fecha o ciclo | Existem planos pagos mais baratos, mas os achados dependem da etapa paga de IA | ## Extensibilidade e governança Cada um abre a camada que o outro mantém fechada. | Aspecto | Lagune | Deepsec | | -------------------- | ------------------------------------------------ | ---------------------------------------------------------- | | O que você estende | Edita módulos ou adiciona novos via `specialize` | Adiciona matchers, agentes, notificadores e responsáveis | | Camada de política | O charter rege todas as fases e é versionado | A configuração é operacional (matchers, modelos, caminhos) | | Sobrescrita por nome | Um módulo refinado sobrepõe o nativo | Em uma colisão de slug de matcher, o seu matcher vence | ## Interfaces O Deepsec gera entregáveis para uma organização de segurança. O Lagune mostra uma visão ao vivo para quem o executa. | Aspecto | Lagune | Deepsec | | ------------------------ | -------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- | | Interface para pessoas | Um dashboard local e ao vivo da cadeia inteira, em linguagem simples | Arquivos de relatório, exportação, métricas e comentários de PR, mais um site de documentação | | Responsabilização | Mostra os arquivos e as especializações que se aplicaram | Sugere um responsável: plantonista, gestor ou autor do commit | | Prova reproduzível | O `prove` escreve testes executáveis e um aviso de divulgação | Permanece estático por design e nunca executa o alvo | | Autodefesa da ferramenta | Protege uma API local de escrita no dashboard | Protege a própria execução de IA contra código não confiável do alvo | ## Escala e implantação | Aspecto | Lagune | Deepsec | | ----------------- | ------------------------------------------------------------------------------------------- | ------------------------------------------------------------ | | Instalação | Nove comandos a partir do plugin do seu agente ou do skills CLI, sem nada gerado no projeto | Um workspace `.deepsec/` com pacote e dependências próprios | | Direção da escala | Restringe o escopo a qualquer parte, um contexto, de um arquivo ao projeto inteiro | Varre repositórios inteiros, até grandes monorepos | | Distribuição | Somente local, e o único servidor escuta apenas no loopback | Distribuição opcional entre VMs de workers do Vercel Sandbox | ## Experiência do usuário Como cada um recebe quem o executa: o que a primeira execução exige e como o operador o direciona. ### Primeiro uso O Lagune roda pelo agente que já está aberto. O Deepsec primeiro provisiona o próprio workspace e o acesso ao modelo. | Aspecto | Lagune | Deepsec | | ---------------------- | -------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- | | Primeiro comando | A instalação do plugin ou `npx skills add wellwelwel/lagune`, e depois `/lagune-*` no agente | `npx deepsec init`, depois `cd .deepsec`, `pnpm install`, `scan` e `process` | | Credenciais para rodar | Nenhuma chave à parte, ele usa o seu agente atual | Uma chave de modelo (por exemplo, AI Gateway, um token OIDC da Vercel de 12 horas ou um token da Anthropic) | ### Como conduzir Os dois aceitam direcionamento. O Lagune lê o formato da entrada em cada fase. O Deepsec restringe o conjunto de arquivos sobre o qual a mesma investigação roda. | Aspecto | Lagune | Deepsec | | ----------------------- | -------------------------------------------------------------------------------------- | ----------------------------------------------------------- | | Projeto inteiro | Uma fase sem entrada analisa o escopo inteiro | `scan` e `process` varrem o repositório | | Uma parte | Qualquer fase restringe o escopo a arquivos ou diretórios informados | `--files`, `--files-from` ou `--diff` restringem a execução | | Uma preocupação | Uma fase restringe o escopo a uma preocupação descrita | O prompt de investigação é fixo | | Uma faixa de prioridade | O `harden` e o `verify` restringem o escopo a severidade crítica, alta, média ou baixa | Os achados são rotulados depois da execução | | Um único valor | Um hook avalia diretamente um trecho, padrão ou URL (`--pattern`, `--url`) | A unidade de trabalho é um arquivo | ## Perguntas frequentes ### Qual é a diferença entre o Lagune e o Deepsec? O Lagune é agent-first e atua antes, durante e depois de o código ser escrito: define a política antes do código, aplica hardening no próprio fluxo durante o desenvolvimento e audita, fortalece e verifica o código já escrito. O Deepsec é deterministic-first: uma varredura ampla de regex alimenta uma investigação obrigatória por um modelo de ponta, que revisa o código existente e relata os achados, sem alterá-lo. ### Dá para usar algum deles de graça? O fluxo inteiro do Lagune pode rodar a $0 com um modelo local gratuito, e os hooks determinísticos dele emitem vereditos sem nenhuma IA. O scan do Deepsec é gratuito, mas não emite vereditos, então qualquer achado depende da etapa paga de IA. ### Algum deles altera o meu código? O Lagune altera: o harden aplica as correções no seu código. O Deepsec não altera: ele faz apenas análise estática e emite achados e texto de recomendação que uma pessoa ou um agente aplica à parte. --- # Fontes da OWASP > De onde vem o conhecimento das especializações nativas da categoria OWASP, mapeado para as páginas canônicas de ataques e Cheat Sheets da OWASP. Canônica: https://lagune.ai/pt-BR/docs/references/owasp-sources Idioma: pt-BR Original: https://lagune.ai/docs/references/owasp-sources Última atualização: 2026-11-03 Este documento mapeia cada **ataque** (`www-community`) e cada **Cheat Sheet** (`CheatSheetSeries`) da OWASP para uma categoria de segurança, cada um com o link para a página pública canônica dele. Dentro de uma categoria, itens equivalentes dividem uma única linha da lista: os ataques e as cheat sheets que tratam do mesmo risco aparecem juntos, separados por vírgula. Itens sem uma contrapartida direta ficam em uma linha própria. - O crédito é da OWASP. Os ataques ficam em `https://owasp.org/www-community/attacks/` e as cheat sheets em `https://cheatsheetseries.owasp.org/cheatsheets/.html`. --- ## 1. Injection (genérico) - [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. Injection em SQL e bancos de dados - [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. Injection de comandos do sistema operacional - [x] [Command Injection](https://owasp.org/www-community/attacks/Command_Injection), [OS Command Injection Defense](https://cheatsheetseries.owasp.org/cheatsheets/OS_Command_Injection_Defense_Cheat_Sheet.html) (interpreter) --- ## 4. Injection em LDAP, XPath e XML - [x] [LDAP Injection](https://owasp.org/www-community/attacks/LDAP_Injection), [LDAP Injection Prevention](https://cheatsheetseries.owasp.org/cheatsheets/LDAP_Injection_Prevention_Cheat_Sheet.html) (interpreter) - [x] [XPATH Injection](https://owasp.org/www-community/attacks/XPATH_Injection) (interpreter) - [x] [Blind XPath Injection](https://owasp.org/www-community/attacks/Blind_XPath_Injection) (interpreter) - [x] [XML External Entity (XXE) Prevention](https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html), [XML Security](https://cheatsheetseries.owasp.org/cheatsheets/XML_Security_Cheat_Sheet.html) (xml) --- ## 5. Cross-Site Scripting (XSS) - [x] [Cross Site Scripting (XSS)](https://owasp.org/www-community/attacks/Cross-site-Scripting-%28XSS%29), [Cross Site Scripting Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html), [XSS Filter Evasion](https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet.html) (browser) - [x] [DOM Based XSS](https://owasp.org/www-community/attacks/DOM_Based_XSS), [DOM based XSS Prevention](https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.html), [DOM Clobbering Prevention](https://cheatsheetseries.owasp.org/cheatsheets/DOM_Clobbering_Prevention_Cheat_Sheet.html) (browser) - [x] [Reflected DOM Injection](https://owasp.org/www-community/attacks/Reflected_DOM_Injection) (browser) - [x] [XSS in Converting File Content to Text](https://owasp.org/www-community/attacks/XSS_in_Converting_File_Content_to_Text) (browser) - [x] [XSS in subtitle](https://owasp.org/www-community/attacks/Xss_in_subtitle) (browser) - [x] [Cross Frame Scripting](https://owasp.org/www-community/attacks/Cross_Frame_Scripting) (browser) - [x] [Cross Site Tracing](https://owasp.org/www-community/attacks/Cross_Site_Tracing) (browser) - [x] [Content Security Policy](https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html) (browser) --- ## 6. Cross-Site Request Forgery (CSRF) e clickjacking - [x] [Cross Site Request Forgery (CSRF)](https://owasp.org/www-community/attacks/cross-site-request-forgery), [XSRF](https://owasp.org/www-community/attacks/XSRF), [Cross-Site Request Forgery Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html) (http-request) - [x] [Clickjacking](https://owasp.org/www-community/attacks/Clickjacking), [Clickjacking Defense](https://cheatsheetseries.owasp.org/cheatsheets/Clickjacking_Defense_Cheat_Sheet.html) (browser) - [x] [Cross Site History Manipulation (XSHM)](https://owasp.org/www-community/attacks/Cross_Site_History_Manipulation_%28XSHM%29) (browser) - [x] [Form action hijacking](https://owasp.org/www-community/attacks/Form_action_hijacking) (network) - [x] [Reverse Tabnabbing](https://owasp.org/www-community/attacks/Reverse_Tabnabbing) (browser) --- ## 7. Redirecionamentos e encaminhamentos - [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. Controle de acesso e autorização - [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. Autenticação e credenciais - [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. Gerenciamento de sessão - [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. Federação de identidade (OAuth, SAML e 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. Criptografia e segurança de 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. Path traversal e manipulação de arquivos - [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 do protocolo HTTP (headers, cache e 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) (dividido entre: browser, transport, http-request, 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. Encoding e content spoofing - [x] [Unicode Encoding](https://owasp.org/www-community/attacks/Unicode_Encoding) (interpreter) - [x] [Double Encoding](https://owasp.org/www-community/Double_Encoding) (interpreter) - [x] [Content Spoofing](https://owasp.org/www-community/attacks/Content_Spoofing) (browser) --- ## 17. Injection em CSV e planilhas - [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. Negação de serviço - [x] [Regular expression Denial of Service (ReDoS)](https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS) (regex) --- ## 20. Segurança de memória e 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óvel e execução de código não confiável - [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. Desserialização - [x] [Deserialization](https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html) (dividido entre: python, ruby, php, java, dotnet) --- ## 23. Malware e ameaças no lado do 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. Logging, repúdio e tratamento de erros - [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 negócio e abuso de funcionalidade Lógica de negócio e abuso de funcionalidade não têm uma superfície única no código que uma especialização por superfície defenda: a defesa é um design específico da aplicação, o mesmo raciocínio que conduz a modelagem de ameaças do projeto. Movido para "Fora do escopo". --- ## 26. Segurança de IA, LLMs e 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. Prototype pollution e 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 e plataformas de linguagem - [x] [Django Security](https://cheatsheetseries.owasp.org/cheatsheets/Django_Security_Cheat_Sheet.html), [Django REST Framework](https://cheatsheetseries.owasp.org/cheatsheets/Django_REST_Framework_Cheat_Sheet.html) (python) - [x] [Ruby on Rails](https://cheatsheetseries.owasp.org/cheatsheets/Ruby_on_Rails_Cheat_Sheet.html) (ruby) - [x] [Laravel](https://cheatsheetseries.owasp.org/cheatsheets/Laravel_Cheat_Sheet.html) (php) - [x] [Symfony](https://cheatsheetseries.owasp.org/cheatsheets/Symfony_Cheat_Sheet.html) (php) - [x] [Java Security](https://cheatsheetseries.owasp.org/cheatsheets/Java_Security_Cheat_Sheet.html) (java) - [x] [DotNet Security](https://cheatsheetseries.owasp.org/cheatsheets/DotNet_Security_Cheat_Sheet.html) (dotnet) - [x] [NodeJS Security](https://cheatsheetseries.owasp.org/cheatsheets/Nodejs_Security_Cheat_Sheet.html) (javascript) - [x] [PHP Configuration](https://cheatsheetseries.owasp.org/cheatsheets/PHP_Configuration_Cheat_Sheet.html) (php) --- ## 29. Front-end web e 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) (dividido entre: access-control, browser) --- ## 30. APIs e serviços - [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. Nuvem, contêineres e infraestrutura A configuração de contêineres e workloads é configuração como código que quem desenvolve entrega junto com o app (`Dockerfile`, Compose, `securityContext` do Pod), uma superfície real que o `harden` corrige e o `verify` comprova, então ela está no escopo. A administração do cluster (RBAC, etcd, API server, admission, segmentação de rede) é domínio de quem opera a infraestrutura e fica fora do escopo. - [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: a parte de workloads e Pods. A administração do cluster fica fora do escopo) - [x] [Serverless / FaaS Security](https://cheatsheetseries.owasp.org/cheatsheets/Serverless_FaaS_Security_Cheat_Sheet.html) (serverless) --- ## 32. Cadeia de suprimentos e CI/CD - [x] [NPM Security](https://cheatsheetseries.owasp.org/cheatsheets/NPM_Security_Cheat_Sheet.html) (interpreter) - [x] [Dependency Graph & SBOM Best Practices](https://cheatsheetseries.owasp.org/cheatsheets/Dependency_Graph_SBOM_Cheat_Sheet.html), [Vulnerable Dependency Management](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerable_Dependency_Management_Cheat_Sheet.html) (interpreter) --- ## 33. Segredos e configuração O gerenciamento de segredos é operacional: cofres, CI/CD, configuração de nuvem e rotação. A única faceta no nível do código (um segredo fixo no código-fonte) é uma varredura determinística, não uma especialização de risco. Movido para "Fora do escopo". --- ## 34. Processo, design e governança A proteção da privacidade do usuário é questão de política e de design (minimização de dados, transparência e retenção), não uma superfície no código que uma especialização defenda. Movido para "Fora do escopo". --- ## 35. Pagamentos e conformidade - [x] [Secure Integration of Third-Party Payment Gateways](https://cheatsheetseries.owasp.org/cheatsheets/Third_Party_Payment_Gateway_Integration_Cheat_Sheet.html) (payment) --- ## 36. Sistemas embarcados, IoT e domínios especializados A segurança automotiva e a de drones são domínios de sistemas embarcados (barramento CAN, firmware OTA, integridade de sensores e rádio, acesso físico), e não o código-fonte de aplicações web e APIs que o Lagune audita. Movido para "Fora do escopo". --- ## Fora do escopo (sem superfície no código) Estes itens não são terreno de especializações e não têm checkbox: são governança, processo, hardening operacional ou uso de frameworks, sem uma superfície única no código que uma especialização por superfície defenda. O valor deles para a segurança é real, mas está no processo e na arquitetura (ou, no caso de um framework, na skill da própria linguagem), e não em uma defesa que este catálogo entrega. Aparecem como referência, não como trabalho a fazer. - [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) (amplificação via SOAP e WS-Addressing, uma variante operacional de DoS sem superfície no 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 no usuário final, não uma superfície no código do projeto auditado. A faceta de entrega pelo navegador fica em `browser`) - [REST Security](https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html), [REST Assessment](https://cheatsheetseries.owasp.org/cheatsheets/REST_Assessment_Cheat_Sheet.html) - [Web Service Security](https://cheatsheetseries.owasp.org/cheatsheets/Web_Service_Security_Cheat_Sheet.html) - [Cloud Architecture Security](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Cloud_Architecture_Cheat_Sheet.html) (design e trade-offs: IAM versus URLs assinadas, VPCs públicas e privadas, fronteiras de confiança e responsabilidade compartilhada. Ao contrário de `container`, não tem uma configuração concreta que uma especialização verifique) - [Infrastructure as Code Security](https://cheatsheetseries.owasp.org/cheatsheets/Infrastructure_as_Code_Security_Cheat_Sheet.html) (apesar do nome, trata do processo de SDLC e das ferramentas para _gerenciar_ IaC: plugins de IDE, análise estática, varredura de imagens, CI/CD e assinatura. Não oferece um padrão inseguro a converter em forma segura dentro de um arquivo Terraform ou CloudFormation) - [Kubernetes Security](https://cheatsheetseries.owasp.org/cheatsheets/Kubernetes_Security_Cheat_Sheet.html) (_apenas a parte de administração do cluster_: RBAC, etcd, API server e admission. A parte de workloads e Pods está no escopo em `container`) - [Network Segmentation](https://cheatsheetseries.owasp.org/cheatsheets/Network_Segmentation_Cheat_Sheet.html) (arquitetura de rede e política de firewall) - [Subdomain Takeover Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Subdomain_Takeover_Prevention_Cheat_Sheet.html) (ciclo de vida e monitoramento de DNS, não código) - [Secrets Management](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html) (cofres, CI/CD e rotação. A faceta do segredo fixo no código é uma varredura determinística, não uma especialização de risco) - [C-Based Toolchain Hardening](https://cheatsheetseries.owasp.org/cheatsheets/C-Based_Toolchain_Hardening_Cheat_Sheet.html) (flags de compilador, linker e build, sem um sink no código-fonte) - [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) (configuração global do tratamento de erros em cada stack. O vazamento é a mesma exposição que o tratamento de erros já rege) - [Abuse of Functionality](https://owasp.org/www-community/attacks/Abuse_of_Functionality), [Business Logic Security](https://cheatsheetseries.owasp.org/cheatsheets/Business_Logic_Security_Cheat_Sheet.html), [Abuse Case _(historical)_](https://cheatsheetseries.owasp.org/cheatsheets/Abuse_Case_Cheat_Sheet.html) (design específico da aplicação, sem um sink único no código) - [User Privacy Protection](https://cheatsheetseries.owasp.org/cheatsheets/User_Privacy_Protection_Cheat_Sheet.html) (minimização de dados, transparência e política de retenção) - [Top 10 Automotive Security Vulnerabilities](https://cheatsheetseries.owasp.org/cheatsheets/Automotive_Security_Cheat_Sheet.html), [Drone Security](https://cheatsheetseries.owasp.org/cheatsheets/Drone_Security_Cheat_Sheet.html) (domínios de sistemas embarcados, como barramento CAN, firmware OTA e integridade de sensores e rádio, e não código-fonte web ou de APIs) - [Mobile Application Security](https://cheatsheetseries.owasp.org/cheatsheets/Mobile_Application_Security_Cheat_Sheet.html) (hardening das plataformas Android e iOS, como armazenamento, biometria, pinning e dados pessoais. Não tem uma superfície única no código, e a faceta de carregamento de código não confiável foi para `interpreter`) - [Threat Modeling](https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html), [Threat Modeling _(community page)_](https://owasp.org/www-community/Threat_Modeling) - [Attack Surface Analysis](https://cheatsheetseries.owasp.org/cheatsheets/Attack_Surface_Analysis_Cheat_Sheet.html) - [Secure Product Design](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Product_Design_Cheat_Sheet.html) - [Secure Code Review](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Code_Review_Cheat_Sheet.html) - [Virtual Patching](https://cheatsheetseries.owasp.org/cheatsheets/Virtual_Patching_Cheat_Sheet.html) - [Vulnerability Disclosure](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html) - [Legacy Application Management](https://cheatsheetseries.owasp.org/cheatsheets/Legacy_Application_Management_Cheat_Sheet.html) - [Security Terminology](https://cheatsheetseries.owasp.org/cheatsheets/Security_Terminology_Cheat_Sheet.html) --- # /lagune-repair: corrija o rastreamento quebrado dos achados > Repare a cadeia quando uma renomeação ou um arquivo movido confunde o rastreamento do Lagune. Canônica: https://lagune.ai/pt-BR/docs/commands/repair Idioma: pt-BR Original: https://lagune.ai/docs/commands/repair Última atualização: 2026-11-03 🧰 Repare a cadeia quando uma renomeação ou um arquivo movido a confunde. **Manutenção interna, não uma fase de segurança** O repair não é uma sexta fase do fluxo linear. A função dele é manter o rastreamento coerente. ```prompt # Não recebe nenhuma entrada: sempre repara a cadeia inteira /lagune-repair ``` ## Como funciona Cada achado do detect é um item rastreado que o plan, o harden e o verify levam adiante, cada um agindo sobre ele e voltando a relatá-lo pelo nome. Esse nome, escrito de forma idêntica como título da seção em todos os artefatos, é a identidade dele do começo ao fim. A única coisa volátil que o rastreamento guarda são os caminhos dos arquivos para os quais o item aponta. Esses caminhos não ficam em nenhum outro lugar, então uma renomeação ou um arquivo movido só pode quebrar o vínculo ali, nunca em duas cópias divergentes. Quando isso acontece, o repair corrige o mapa (`.lagune/tracking.json`) para que a identidade sobreviva à renomeação. Ele lê os artefatos e o mapa de rastreamento, lê o seu código-fonte só para descobrir o novo caminho de um arquivo renomeado e nunca escreve conteúdo de segurança. Na mesma passada, ele confere cada artefato de memória com o template correspondente e relata o que se desviou, indicando para cada desvio a fase que o corrige. **Dica** - Ele não mexe no seu código nem nos artefatos em prosa, só no rastreamento. - Raramente você o roda manualmente. Quando uma fase percebe que a cadeia está inconsistente, ela roda o repair para você e segue em frente. - O rastreamento que ele mantém fica em `.lagune/tracking.json`, um estado interno que você nunca edita manualmente. --- # Migrate: leve um projeto Lagune baseado em manifest para as skills e os plugins > Leve um projeto Lagune baseado em manifest para o Lagune baseado em skills, mantendo o seu charter, os artefatos, o rastreamento e as suas próprias especializações. Canônica: https://lagune.ai/pt-BR/docs/commands/migrate Idioma: pt-BR Original: https://lagune.ai/docs/commands/migrate Última atualização: 2026-11-03 🔀 Leve um projeto **Lagune** baseado em manifest para o **Lagune** baseado em skills, mantendo tudo o que você escreveu. **Aviso de descontinuação** Um projeto com manifest continua funcionando como está até a `v1.x`: o `npx lagune` repassa `init`, `pull`, `update`, `add`, `remove`, `list` e o dashboard para o `lagune@0.15.0`, a última versão baseada em manifest. ## Como migrar 1. Confirme que o seu trabalho atual está commitado e então rode o migrate a partir da raiz do projeto: ```bash npx lagune migrate ``` 2. Faça um commit só com o que ele alterou, para que a migração continue sendo uma única mudança revisável. 3. Instale os comandos do seu agente, como mostra a [página de instalação](https://lagune.ai/pt-BR/docs). 4. Se o projeto já tiver um artefato de detect, plan ou harden, peça ao [`/lagune-repair`](https://lagune.ai/pt-BR/docs/commands/repair) para reconciliar as referências antigas neles e nas suas próprias especializações: ```prompt /lagune-repair Reconcilie as especializações aplicadas (antes chamadas de sub-skills) nos artefatos em `.lagune/memory/` (`detect.md`, `plan.md` e `harden.md`) com os nomes que o novo catálogo lista, e reescreva cada chamada que as minhas próprias especializações em `.lagune/catalog/` fazem aos hooks antigos em `.lagune/hooks/` como uma chamada à ferramenta `lagune_read` ou `lagune_write`. ``` ## O que muda | Antes | Depois | | --------------------------------------------------------------------- | ------------------------------------------------------------------------------ | | `.lagune/templates/`, `.lagune/hooks/` e `.lagune/specializations.md` | Removidos: cada skill traz o próprio template, e o engine executa os hooks | | As cópias das especializações nativas em `.lagune/skills/` | Removidas: o engine serve as nativas | | As suas próprias especializações em `.lagune/skills/` | Movidas para `.lagune/catalog/` | | `.lagune/skills.json`, o índice das suas próprias especializações | Incorporado ao `.lagune/configs.json` | | As categorias do manifest | Registradas em `.lagune/configs.json` | | Os comandos antigos do agente, como `/lagune.detect` | Removidos: [instalar o **Lagune**](https://lagune.ai/pt-BR/docs) traz os novos, como `/lagune-detect` | | O bloco do **Lagune** no `.gitignore` | Removido, junto com o arquivo quando ele não tinha mais nada | | `.lagune/proofs/`, ignorado por aquele bloco | Mantido fora dos commits pelo próprio `.gitignore` | | `.lagune/manifest.json` | Apagado, por último | O seu trabalho de segurança continua como está: o charter, o artefato que cada fase produziu e o mapa de rastreamento com os caminhos para os quais cada achado aponta. ## Perguntas frequentes ### Sou obrigado a migrar? Sim. Os projetos baseados em manifest estão descontinuados e só continuam funcionando até a v1.x, então execute npx lagune migrate para migrar o seu. ### O que o migrate mantém? O seu charter, todos os artefatos das fases, o mapa de rastreamento, as suas categorias e as suas próprias especializações. As especializações vão para .lagune/catalog/, e o índice delas se junta às suas categorias em .lagune/configs.json. ### Quando devo instalar os novos comandos? Depois do migrate, como a página de instalação mostra para o seu agente. Instalar antes também funciona, já que o migrate mantém o novo /lagune. ### Alguém do time já migrou. O que eu rodo? Faça o pull da migração e então execute npx lagune migrate uma vez. Ele remove o que o Lagune baseado em manifest deixou no seu clone, que o controle de versão nunca carregou, e mantém as suas provas fora dos commits.