@saulwade/swl-ses 2.6.0 → 2.8.0

package/comandos/swl/seguridad.md

@@ -1,189 +1,189 @@
----
-name: swl:seguridad
-description: >
-  Chequeo de seguridad del PROYECTO COMPLETO (no del diff): escaneo de secretos
-  en el repo, auditoría de dependencias con CVEs, revisión OWASP dirigida a los
-  módulos críticos vía revisor-seguridad-swl, verificación de gates de seguridad
-  del pipeline CI, y detección de superficie LLM (prompt injection) cuando
-  aplica. Consolida todo en un reporte de postura de seguridad con score, veto
-  items y acciones priorizadas. Usar al adoptar un proyecto, antes de un release
-  mayor, tras un incidente, o periódicamente. Para revisar solo los cambios de
-  una fase usar /swl:verificar --solo-seguridad; para el diff usar /swl:revisar
-  seguridad.
-argument-hint: "[--rapido] [--threat-model] [--llm] [--json]"
-allowed-tools: [Read, Grep, Glob, Bash, Write, Agent, Skill]
----
-
-# /swl:seguridad — Postura de seguridad del proyecto completo
-
-Eres el coordinador de un chequeo de seguridad integral. A diferencia de
-`/swl:verificar` (que audita el diff de una fase) y de `/swl:revisar seguridad`
-(que revisa cambios recientes), este comando evalúa la **postura del proyecto
-entero**: secretos, dependencias, código, pipeline y superficie LLM.
-
-## Cuándo usar
-
-- Al adoptar un proyecto existente (complemento natural de `/swl:adoptar-proyecto`).
-- Antes de un release mayor o del primer despliegue productivo.
-- Tras un incidente de seguridad o la rotación de un secreto filtrado.
-- Periódicamente (candidato a `/swl:cron` mensual).
-
-**Cuándo NO usar**: para el diff de una fase (→ `/swl:verificar
---solo-seguridad`), para revisar un PR (→ `/swl:revisar seguridad`), o para
-auditar artefactos de skills/plugins antes de instalarlos (→
-`Skill("seguridad-skills-ia")`).
-
-## Flags
-
-```
---rapido        Solo capas 1-2 (secretos + dependencias). ~2 minutos.
---threat-model  Añade la capa 6: genera/actualiza THREAT-MODEL.md con Skill("threat-model-lite").
---llm           Fuerza la capa 5 (ai-runtime-security) aunque la detección automática no encuentre stack LLM.
---json          Además del reporte Markdown, emite el resumen como JSON (para CI).
-```
-
-## Paso 0 — Carga y alcance
-
-```
-Skill("checklist-seguridad")
-```
-
-Detectar el stack (lockfiles, extensiones dominantes) y enumerar los módulos
-críticos del proyecto: auth/, endpoints/rutas públicas, manejo de archivos,
-pagos, todo lo que toque datos de usuario. Si existe `.planning/`, revisar
-reportes previos de este comando en `.planning/audit/` para comparar postura.
-
-## Capa 1 — Secretos en el repositorio
-
-Escaneo del repo completo (tracked files + historial reciente), no solo del
-working tree:
-
-```bash
-# Working tree — patrones de credenciales (mismas familias que el hook escaneo-secretos)
-git grep -nIE "(sk-(ant|proj|live|test)-|AKIA[0-9A-Z]{16}|ghp_[A-Za-z0-9]{36}|glpat-|xox[baprs]-|-----BEGIN (RSA|EC|OPENSSH) PRIVATE KEY-----)" -- . ':!*.lock' ':!node_modules'
-# Claves genéricas asignadas
-git grep -nIE "(password|passwd|secret|api[_-]?key|token)\s*[=:]\s*['\"][^'\"]{8,}['\"]" -- '*.py' '*.js' '*.ts' '*.env*' '*.yaml' '*.yml' '*.json' ':!*test*' ':!*spec*'
-# Historial: archivos .env commiteados alguna vez
-git log --all --diff-filter=A --name-only --pretty=format: -- '*.env' '.env.*' | sort -u
-```
-
-Si `gitleaks` está instalado, preferirlo (`gitleaks detect --no-banner`) —
-cubre historial completo con menos falsos positivos. Complemento del sistema:
-el audit-tool `pentest-scanner.js` y el hook `escaneo-secretos.js` (mismas
-familias de patrones) están disponibles cuando swl-ses está instalado; el flujo
-`/swl:verificar --full` los orquesta sobre el diff.
-
-**Todo hallazgo de secreto en historial es CRÍTICO aunque ya esté rotado o
-gitignoreado** — sigue el protocolo Hallazgo A/B/C de
-`arreglar-al-detectar.md` (limpiar historial es operación destructiva →
-Hallazgo C, decisión del usuario).
-
-## Capa 2 — Dependencias (supply chain)
-
-```
-Skill("dependencias-auditoria")
-```
-
-Ejecutar el auditor del ecosistema detectado (`npm audit` / `pip-audit` /
-`cargo audit` / `govulncheck` / `composer audit` / `mvn dependency-check`).
-Reglas de severidad de `reglas/seguridad.md`: CVE crítico → 72 horas, medio →
-2 semanas. Registrar también: dependencias abandonadas (>18 meses sin release)
-y pins abiertos (`^`, `>=`, `*`) en producción.
-
-## Capa 3 — Código (OWASP, proyecto completo dirigido)
-
-Delegar a `revisor-seguridad-swl` vía Agent con alcance de proyecto:
-
-```
-Agent(revisor-seguridad-swl) con:
-- Alcance: los módulos críticos del Paso 0 (no un diff)
-- Instrucción: auditoría OWASP Top 10 + path traversal + CSRF con severidad
-  CVSSv3 y veto items. Priorizar auth/autz, validación de entradas, queries,
-  manejo de archivos y sanitización de salida. Cargar Skill("checklist-seguridad")
-  y Skill("auth-patrones") / Skill("iam-secretos") según lo que encuentre.
-```
-
-En proyectos grandes (>500 archivos), dividir en 2-3 invocaciones por dominio
-(auth, API pública, manejo de datos) y consolidar.
-
-## Capa 4 — Pipeline CI (gates de seguridad)
-
-```
-Skill("devsecops-pipeline-security")
-```
-
-Verificar contra los 5 gates del skill qué existe en `.github/workflows/` (o
-equivalente GitLab/Azure): secret scanning (gitleaks), SAST, dependency audit,
-container scanning, DAST. Reportar la matriz presente/ausente. Para
-materializar los faltantes: `/swl:configurar-ci --seguridad` (instala los
-workflows opt-in).
-
-## Capa 5 — Superficie LLM (condicional)
-
-Detectar stack LLM (deps `anthropic`, `openai`, `langchain`, `llama-index`,
-servidores MCP propios, prompts en el repo). Si existe — o con `--llm`:
-
-```
-Skill("ai-runtime-security")
-```
-
-Auditar: manejo de input no confiable hacia prompts (injection directa e
-indirecta), guardrails de salida, secretos en system prompts, gates de
-autonomía previos a tool-calls.
-
-## Capa 6 — Threat model (solo con `--threat-model`)
-
-```
-Skill("threat-model-lite")
-```
-
-Generar o actualizar `THREAT-MODEL.md` (STRIDE ligero: superficie de ataque,
-activos críticos, matriz de riesgo). Si ya existe uno, actualizarlo contra los
-endpoints/módulos nuevos en vez de regenerarlo desde cero.
-
-## Paso final — Reporte de postura consolidado
-
-Escribir `.planning/audit/seguridad-postura-[YYYY-MM-DD].md` (si no hay
-`.planning/`, ofrecer la raíz del proyecto):
-
-```markdown
-# Postura de seguridad — [proyecto] — [fecha]
-
-## Score por capa
-| Capa | Score | Veredicto |
-|------|-------|-----------|
-| 1. Secretos | N/100 | ... |
-| 2. Dependencias | N/100 | ... |
-| 3. Código OWASP | N/100 | ... |
-| 4. Pipeline CI | N/100 | ... |
-| 5. Superficie LLM | N/100 o N/A | ... |
-
-## VETO ITEMS DETECTADOS
-[secreto en historial, SQL injection, eval con input, CVE crítico sin parche…
-→ score global CAP a 60/100 con 1 veto, 30/100 con 2+. Formato de
-reglas/gobernanza.md § Veto items]
-
-## Hallazgos priorizados
-| # | Severidad (CVSSv3) | Capa | archivo:línea | Hallazgo | Remediación |
-
-## Acciones recomendadas (en orden)
-1. [acción — comando SWL que la ejecuta si existe]
-```
-
-Reportar al usuario el resumen con el score global y las top 3 acciones. Si
-hay hallazgos CRÍTICOS, recordar el flujo de remediación: `/swl:fix` (triage y
-reparación) o `/swl:verificar --solo-seguridad --until-converge` tras corregir.
-
-## Reglas de comportamiento
-
-- **Este comando NO modifica código ni secretos** — diagnostica y prioriza.
-  La remediación pasa por el flujo fix/verificar con el usuario al tanto.
-- Toda cita archivo:línea del reporte sale de `Read`/`Grep` reales de esta
-  corrida (`verificar-citas-normativas.md § Familia 2`).
-- Los veto items no se negocian ni se suavizan por presión de entrega
-  (`reglas/gobernanza.md`).
-- Con `--rapido`, decir explícitamente qué capas NO corrieron — un reporte
-  parcial presentado como completo es degradación silenciosa.
-- Falsos positivos de secretos (fixtures, ejemplos): verificarlos leyendo el
-  archivo antes de reportar; si son fixtures legítimos, recomendar renombrarlos
-  al patrón reconocible (`placeholder`, `example`, `dummy_`).
+---
+name: swl:seguridad
+description: >
+  Chequeo de seguridad del PROYECTO COMPLETO (no del diff): escaneo de secretos
+  en el repo, auditoría de dependencias con CVEs, revisión OWASP dirigida a los
+  módulos críticos vía revisor-seguridad-swl, verificación de gates de seguridad
+  del pipeline CI, y detección de superficie LLM (prompt injection) cuando
+  aplica. Consolida todo en un reporte de postura de seguridad con score, veto
+  items y acciones priorizadas. Usar al adoptar un proyecto, antes de un release
+  mayor, tras un incidente, o periódicamente. Para revisar solo los cambios de
+  una fase usar /swl:verificar --solo-seguridad; para el diff usar /swl:revisar
+  seguridad.
+argument-hint: "[--rapido] [--threat-model] [--llm] [--json]"
+allowed-tools: [Read, Grep, Glob, Bash, Write, Agent, Skill]
+---
+
+# /swl:seguridad — Postura de seguridad del proyecto completo
+
+Eres el coordinador de un chequeo de seguridad integral. A diferencia de
+`/swl:verificar` (que audita el diff de una fase) y de `/swl:revisar seguridad`
+(que revisa cambios recientes), este comando evalúa la **postura del proyecto
+entero**: secretos, dependencias, código, pipeline y superficie LLM.
+
+## Cuándo usar
+
+- Al adoptar un proyecto existente (complemento natural de `/swl:adoptar-proyecto`).
+- Antes de un release mayor o del primer despliegue productivo.
+- Tras un incidente de seguridad o la rotación de un secreto filtrado.
+- Periódicamente (candidato a `/swl:cron` mensual).
+
+**Cuándo NO usar**: para el diff de una fase (→ `/swl:verificar
+--solo-seguridad`), para revisar un PR (→ `/swl:revisar seguridad`), o para
+auditar artefactos de skills/plugins antes de instalarlos (→
+`Skill("seguridad-skills-ia")`).
+
+## Flags
+
+```
+--rapido        Solo capas 1-2 (secretos + dependencias). ~2 minutos.
+--threat-model  Añade la capa 6: genera/actualiza THREAT-MODEL.md con Skill("threat-model-lite").
+--llm           Fuerza la capa 5 (ai-runtime-security) aunque la detección automática no encuentre stack LLM.
+--json          Además del reporte Markdown, emite el resumen como JSON (para CI).
+```
+
+## Paso 0 — Carga y alcance
+
+```
+Skill("checklist-seguridad")
+```
+
+Detectar el stack (lockfiles, extensiones dominantes) y enumerar los módulos
+críticos del proyecto: auth/, endpoints/rutas públicas, manejo de archivos,
+pagos, todo lo que toque datos de usuario. Si existe `.planning/`, revisar
+reportes previos de este comando en `.planning/audit/` para comparar postura.
+
+## Capa 1 — Secretos en el repositorio
+
+Escaneo del repo completo (tracked files + historial reciente), no solo del
+working tree:
+
+```bash
+# Working tree — patrones de credenciales (mismas familias que el hook escaneo-secretos)
+git grep -nIE "(sk-(ant|proj|live|test)-|AKIA[0-9A-Z]{16}|ghp_[A-Za-z0-9]{36}|glpat-|xox[baprs]-|-----BEGIN (RSA|EC|OPENSSH) PRIVATE KEY-----)" -- . ':!*.lock' ':!node_modules'
+# Claves genéricas asignadas
+git grep -nIE "(password|passwd|secret|api[_-]?key|token)\s*[=:]\s*['\"][^'\"]{8,}['\"]" -- '*.py' '*.js' '*.ts' '*.env*' '*.yaml' '*.yml' '*.json' ':!*test*' ':!*spec*'
+# Historial: archivos .env commiteados alguna vez
+git log --all --diff-filter=A --name-only --pretty=format: -- '*.env' '.env.*' | sort -u
+```
+
+Si `gitleaks` está instalado, preferirlo (`gitleaks detect --no-banner`) —
+cubre historial completo con menos falsos positivos. Complemento del sistema:
+el audit-tool `pentest-scanner.js` y el hook `escaneo-secretos.js` (mismas
+familias de patrones) están disponibles cuando swl-ses está instalado; el flujo
+`/swl:verificar --full` los orquesta sobre el diff.
+
+**Todo hallazgo de secreto en historial es CRÍTICO aunque ya esté rotado o
+gitignoreado** — sigue el protocolo Hallazgo A/B/C de
+`arreglar-al-detectar.md` (limpiar historial es operación destructiva →
+Hallazgo C, decisión del usuario).
+
+## Capa 2 — Dependencias (supply chain)
+
+```
+Skill("dependencias-auditoria")
+```
+
+Ejecutar el auditor del ecosistema detectado (`npm audit` / `pip-audit` /
+`cargo audit` / `govulncheck` / `composer audit` / `mvn dependency-check`).
+Reglas de severidad de `reglas/seguridad.md`: CVE crítico → 72 horas, medio →
+2 semanas. Registrar también: dependencias abandonadas (>18 meses sin release)
+y pins abiertos (`^`, `>=`, `*`) en producción.
+
+## Capa 3 — Código (OWASP, proyecto completo dirigido)
+
+Delegar a `revisor-seguridad-swl` vía Agent con alcance de proyecto:
+
+```
+Agent(revisor-seguridad-swl) con:
+- Alcance: los módulos críticos del Paso 0 (no un diff)
+- Instrucción: auditoría OWASP Top 10 + path traversal + CSRF con severidad
+  CVSSv3 y veto items. Priorizar auth/autz, validación de entradas, queries,
+  manejo de archivos y sanitización de salida. Cargar Skill("checklist-seguridad")
+  y Skill("auth-patrones") / Skill("iam-secretos") según lo que encuentre.
+```
+
+En proyectos grandes (>500 archivos), dividir en 2-3 invocaciones por dominio
+(auth, API pública, manejo de datos) y consolidar.
+
+## Capa 4 — Pipeline CI (gates de seguridad)
+
+```
+Skill("devsecops-pipeline-security")
+```
+
+Verificar contra los 5 gates del skill qué existe en `.github/workflows/` (o
+equivalente GitLab/Azure): secret scanning (gitleaks), SAST, dependency audit,
+container scanning, DAST. Reportar la matriz presente/ausente. Para
+materializar los faltantes: `/swl:configurar-ci --seguridad` (instala los
+workflows opt-in).
+
+## Capa 5 — Superficie LLM (condicional)
+
+Detectar stack LLM (deps `anthropic`, `openai`, `langchain`, `llama-index`,
+servidores MCP propios, prompts en el repo). Si existe — o con `--llm`:
+
+```
+Skill("ai-runtime-security")
+```
+
+Auditar: manejo de input no confiable hacia prompts (injection directa e
+indirecta), guardrails de salida, secretos en system prompts, gates de
+autonomía previos a tool-calls.
+
+## Capa 6 — Threat model (solo con `--threat-model`)
+
+```
+Skill("threat-model-lite")
+```
+
+Generar o actualizar `THREAT-MODEL.md` (STRIDE ligero: superficie de ataque,
+activos críticos, matriz de riesgo). Si ya existe uno, actualizarlo contra los
+endpoints/módulos nuevos en vez de regenerarlo desde cero.
+
+## Paso final — Reporte de postura consolidado
+
+Escribir `.planning/audit/seguridad-postura-[YYYY-MM-DD].md` (si no hay
+`.planning/`, ofrecer la raíz del proyecto):
+
+```markdown
+# Postura de seguridad — [proyecto] — [fecha]
+
+## Score por capa
+| Capa | Score | Veredicto |
+|------|-------|-----------|
+| 1. Secretos | N/100 | ... |
+| 2. Dependencias | N/100 | ... |
+| 3. Código OWASP | N/100 | ... |
+| 4. Pipeline CI | N/100 | ... |
+| 5. Superficie LLM | N/100 o N/A | ... |
+
+## VETO ITEMS DETECTADOS
+[secreto en historial, SQL injection, eval con input, CVE crítico sin parche…
+→ score global CAP a 60/100 con 1 veto, 30/100 con 2+. Formato de
+reglas/gobernanza.md § Veto items]
+
+## Hallazgos priorizados
+| # | Severidad (CVSSv3) | Capa | archivo:línea | Hallazgo | Remediación |
+
+## Acciones recomendadas (en orden)
+1. [acción — comando SWL que la ejecuta si existe]
+```
+
+Reportar al usuario el resumen con el score global y las top 3 acciones. Si
+hay hallazgos CRÍTICOS, recordar el flujo de remediación: `/swl:fix` (triage y
+reparación) o `/swl:verificar --solo-seguridad --until-converge` tras corregir.
+
+## Reglas de comportamiento
+
+- **Este comando NO modifica código ni secretos** — diagnostica y prioriza.
+  La remediación pasa por el flujo fix/verificar con el usuario al tanto.
+- Toda cita archivo:línea del reporte sale de `Read`/`Grep` reales de esta
+  corrida (`verificar-citas-normativas.md § Familia 2`).
+- Los veto items no se negocian ni se suavizan por presión de entrega
+  (`reglas/gobernanza.md`).
+- Con `--rapido`, decir explícitamente qué capas NO corrieron — un reporte
+  parcial presentado como completo es degradación silenciosa.
+- Falsos positivos de secretos (fixtures, ejemplos): verificarlos leyendo el
+  archivo antes de reportar; si son fixtures legítimos, recomendar renombrarlos
+  al patrón reconocible (`placeholder`, `example`, `dummy_`).