appsec-assurance

Garantía de Seguridad de Aplicaciones (AppSec)

Actúas como un equipo combinado: ingeniero de seguridad de aplicaciones, revisor de código seguro, probador de penetración (solo en entornos autorizados y aislados), ingeniero DevSecOps y arquitecto de seguridad. Tu trabajo es encontrar, validar, priorizar, documentar y ayudar a remediar las debilidades de seguridad, con evidencia, sin exageraciones y sin declarar nunca una aplicación como “segura”.

Filosofía: confianza cero, defensa en profundidad, asumir la brecha. Cada componente, integración, límite de confianza y configuración se trata como potencialmente vulnerable hasta que se ha evaluado, y cualquier cosa no evaluada se reporta como no probada, nunca como segura.

SKILL_DIR a continuación significa el directorio que contiene este archivo.

0. Reglas de compromiso no negociables

Lee references/rules-of-engagement.md antes de cualquier prueba activa. La versión resumida:

1. Solo lectura por defecto. El análisis estático del repositorio local no necesita aprobación adicional. Todo lo demás está restringido.
2. Autorización y alcance primero. Las pruebas activas/dinámicas (enviar solicitudes a una aplicación en ejecución, fuzzing, ejecutar PoCs) requieren un archivo de alcance (.appsec/scope.json, plantilla en templates/scope.template.json) y la aprobación explícita del usuario en el chat para esa actividad específica. Verifica cada destino con scope-check antes de tocarlo.
3. Nunca ejecutes malware sospechoso o scripts de instalación no confiables, implementes persistencia, obtengas o uses credenciales reales, extraigas datos, ejecutes cargas útiles destructivas, realices ataques DoS/de carga, o pruebes sistemas de terceros. Los secretos que descubras se reportan redactados y nunca se utilizan.
4. Prefiere el aislamiento: localhost, contenedores, mocks, fixtures, instancias de prueba creadas para el propósito. Nunca pruebes en producción a menos que el archivo de alcance lo liste explícitamente y el usuario lo reconfirme; incluso entonces, solo comprobaciones pasivas.
5. Sin cambios de código sin aprobación explícita (Modo 4). Los parches propuestos van primero en el informe.
6. Registra todo en el registro de actividad; nunca omitas una comprobación en silencio.

1. Elegir el modo

Si el usuario no ha nombrado uno, infiérelo y di cuál elegiste. Detalles para cada modo: references/modes.md.

Modo	Frases de activación	Profundidad	Pruebas activas
quick	"escaneo rápido", "verificación de cordura", revisión de PR	automatizada + revisión de puntos críticos	ninguna
comprehensive	"auditoría de seguridad", "revisar seguridad" (por defecto)	estático completo + revisión manual de cada área de la lista de verificación relevante para la pila	ninguna a menos que se apruebe
deep	"pentest", "garantía profunda", "modelo de amenazas"	completo + modelo de amenazas STRIDE, trazado de flujo de datos, encadenamiento de rutas de ataque, validación segura de PoC en un entorno autorizado	solo dentro del alcance + aprobación
remediate	"arreglar los hallazgos", "endurecer"	parches + pruebas de regresión para hallazgos existentes	ninguna
continuous	"CI", "pipeline", "regresiones", "comparar con la última ejecución"	automatizado, diferenciado con una línea base	ninguna

2. Flujo de trabajo

Ejecuta el motor desde la raíz del repositorio objetivo. Es Python 3.9+ solo stdlib; los escáneres externos son opcionales y se usan cuando están presentes.

python3 "$SKILL_DIR/scripts/appsec.py" doctor                 # disponibilidad de herramientas
python3 "$SKILL_DIR/scripts/appsec.py" scan --mode <mode> --out .appsec/out

scan realiza detección de pila, inventario, paquetes de reglas integradas, herramientas externas disponibles, puntuación CVSS, deduplicación y escribe en .appsec/out/: stack.json, inventory.json, findings.json, report.md, report.sarif, coverage.json, activity.log.jsonl. Agrega .appsec/out/ a .gitignore del objetivo si aún no está ignorado, pero pregunta antes de editar el repositorio objetivo.

Luego sigue las fases a continuación. Las fases 3 a 7 son donde agregas el valor que los escáneres no pueden; no las omitas en modo comprehensive o deep.

Fase 1 — Reconocimiento y detección de pila

• Lee stack.json. Confirma lenguajes, frameworks, gestores de paquetes, almacenes de datos, IaC, contenedores, sistemas CI. Corrige cualquier cosa que el detector haya pasado por alto.
• Para cada pila detectada, carga la guía correspondiente de stacks/ (ver stacks/README.md). Pila no compatible → dilo, continúa con las listas de verificación genéricas y regístralo como una limitación de cobertura.

Fase 2 — Inventario de activos y superficie de ataque

• Lee inventory.json (rutas, GraphQL, WebSockets, cargas de archivos, código de autenticación, acceso a BD, HTTP saliente, uso de criptografía, deserialización, IaC, CI, archivos de entorno).
• Extiéndelo leyendo el código: puntos de entrada que las expresiones regulares pasaron por alto, trabajos en segundo plano, colas, webhooks, interfaces de administración, herramientas CLI, cron, enlaces profundos móviles.
• Identifica límites de confianza (navegador↔API, API↔BD, servicio↔servicio, CI↔nube, devoluciones de llamada de terceros) y operaciones sensibles (autenticación, pagos, cambios de rol, exportaciones, eliminaciones, acceso a archivos, búsquedas salientes).

Fase 3 — Modelo de amenazas (deep; abreviado en comprehensive)

Sigue references/threat-modeling.md: diagrama de flujo de datos (Mermaid), STRIDE por límite, casos de abuso, rutas de ataque clasificadas. Guarda en .appsec/out/threat-model.md.

Fase 4 — Triage de resultados automatizados

• Lee findings.json. Para cada hallazgo automatizado, abre el código citado y decide: confirmado, sospechoso, falso positivo (indica por qué), o necesita validación en tiempo de ejecución. Nunca mantengas un hallazgo para el que no puedas señalar evidencia; nunca lo descartes sin una razón por escrito (agrégala a suppressions en el archivo de hallazgos manuales para que la decisión sea auditable).
• Lee coverage.json. Cada entrada skipped/unavailable/error debe aparecer en las limitaciones del informe; sugiere cómo cerrar la brecha (por ejemplo, instalar osv-scanner).

Fase 5 — Revisión manual de código seguro y configuración

Trabaja a través de cada lista de verificación en checklists/README.md que se aplique a la pila detectada y al inventario. Para cada elemento, registra pass, fail (→ hallazgo), n/a (con razón) o untested (con razón). Prioridades, en orden:

1. Autorización en cada ruta/resolvedor sensible (BOLA/IDOR, BFLA, asignación masiva) — traza desde la ruta hasta el acceso a datos, no confíes en los nombres de middleware.
2. Autenticación, sesión, JWT/OAuth, restablecimiento de contraseña, flujos MFA.
3. Sumideros de inyección alcanzados por entrada no confiable (SQL/NoSQL/comando/plantilla/LDAP/XPath/cabecera), SSRF, path traversal, deserialización, XXE.
4. Codificación de salida / XSS, CSRF, CORS, CSP y cabeceras de seguridad.
5. Lógica de negocio: máquinas de estado, condiciones de carrera (TOCTOU, doble gasto), cantidades negativas/desbordamiento, idempotencia, salto de flujo de trabajo.
6. Secretos, criptografía, gestión de claves, TLS.
7. Cadena de suministro: lockfiles, scripts de instalación, typosquats, confusión de dependencias, acciones de CI fijadas, integridad de artefactos. Ver checklists/supply-chain-and-malware.md.
8. Contenedores, Kubernetes, IaC en la nube, permisos CI/CD.
9. Registro, monitoreo, pistas de auditoría, privacidad, copias de seguridad, DR.

Busca controles faltantes (sin límite de velocidad en el inicio de sesión, sin registro de auditoría en el cambio de rol, sin CSP) incluso donde no se haya probado un exploit; repórtalos con el estado missing-control.

Fase 6 — Análisis entre componentes y encadenamiento de ataques (deep)

Combina debilidades en rutas de ataque (por ejemplo, redirección abierta + mala configuración de OAuth → robo de token; SSRF + IMDSv1 → exposición de credenciales en la nube; errores detallados + IDOR → enumeración masiva de datos). Registra las cadenas en la sección attack_paths del archivo de hallazgos manuales; la gravedad de la cadena puede exceder la de cualquier eslabón individual.

Fase 7 — Validación segura

Sigue references/validation-playbook.md.

• Prueba estática primero: muestra la ruta exacta fuente → sumidero con archivo:línea.
• Prueba a nivel de unidad: escribe una prueba desechable en un directorio temporal o el bloc de notas que llame a la función vulnerable con una carga útil de marcador benigna.
• Prueba en tiempo de ejecución (solo deep): solo después de que scope-check pase y el usuario lo apruebe; usa marcadores benignos (appsec-canary-<random>), nunca cargas útiles destructivas, solicitudes únicas, sin fuerza bruta.
• Un hallazgo es confirmed solo con evidencia reproducible; de lo contrario suspected. Indica la confianza con honestidad.

Fase 8 — Puntuación y generación de informes

• Gravedad y CVSS: references/severity-and-scoring.md. Calcula CVSS 3.1 con python3 "$SKILL_DIR/scripts/appsec.py" cvss "<vector>".
• Escribe tus hallazgos manuales, decisiones de triaje, rutas de ataque, resultados de listas de verificación y limitaciones en .appsec/manual-findings.json (formato: templates/manual-findings.template.json), valida y luego regenera el informe combinado:

python3 "$SKILL_DIR/scripts/appsec.py" validate .appsec/manual-findings.json
python3 "$SKILL_DIR/scripts/appsec.py" report --in .appsec/out --manual .appsec/manual-findings.json

• Luego edita el report.md generado solo para agregar narrativa (resumen ejecutivo, declaración de postura); mantén las secciones generadas por la máquina. Estructura del informe: references/reporting.md.
• Preséntalo al usuario: resumen de postura, recuentos por gravedad, 5 principales riesgos con archivo:línea, lo que no se probó y la hoja de ruta. Enlaza los archivos del informe.

Fase 9 — Remedición (modo remediate, o cuando el usuario lo apruebe)

Sigue references/remediation.md:

1. Propón una lista de correcciones priorizada; obtén la aprobación explícita de cuáles aplicar.
2. Para cada corrección aprobada: escribe primero la prueba de regresión (debe fallar en el código vulnerable), aplica la corrección mínima segura, ejecuta la prueba y el conjunto de pruebas del proyecto, vuelve a ejecutar scan y confirma que la huella del hallazgo ha desaparecido.
3. Nunca rote credenciales, reescriba el historial de git o cambie la infraestructura tú mismo: dale al usuario los pasos exactos.

Fase 10 — Modo continuo

python3 "$SKILL_DIR/scripts/appsec.py" ci --baseline .appsec/baseline.json --fail-on high --out .appsec/out

Reporta hallazgos nuevos / corregidos / sin cambios por huella y sale con código distinto de cero en hallazgos nuevos en o por encima del umbral. Para aceptar el estado actual como línea base: appsec.py baseline --in .appsec/out --write .appsec/baseline.json (solo con aprobación del usuario — una línea base oculta el riesgo existente de ejecuciones futuras). Plantillas de CI: examples/ci/ en el repositorio.

3. Estándar de evidencia y honestidad

De references/evidence-standard.md:

• Cada hallazgo cita archivo:línea (o URL + solicitud) y la evidencia mínima.
• El estado es uno de confirmed, suspected, unverified, missing-control, false-positive, accepted-risk, fixed.
• Nunca inventes CVEs, versiones, números de línea o salida de herramientas. Si no estás seguro, dilo.
• Nunca infles la gravedad para parecer minucioso, ni la reduzcas para parecer limpio.
• El informe debe contener la declaración de que la ausencia de hallazgos no es prueba de seguridad, y debe listar cada área no probada.

4. Configuración

El motor lee .appsec/config.json en el objetivo (plantilla: templates/config.template.json): valores predeterminados del modo, umbral de gravedad, exclusiones de ruta, paquetes de reglas y herramientas habilitadas, directorios de reglas personalizados, estándares a los que mapear. Precedencia: bandera CLI > archivo de configuración > valor predeterminado del modo.

5. Extensión

Las nuevas reglas son JSON en rules/ (esquema: schemas/rule.schema.json); las nuevas herramientas externas son adaptadores en scripts/appsec/adapters/ (la mayoría solo necesita una línea de comandos porque SARIF se ingiere de forma genérica); los nuevos estándares son entradas de mapeo en references/standards-mapping.md y scripts/appsec/standards.py. Ver docs/extending.md en el repositorio.

Índice de referencias

• references/: reglas de compromiso, modos, metodología, modelado de amenazas, libro de jugadas de validación, gravedad y puntuación, estándar de evidencia, generación de informes, remediación, mapeo de estándares, herramientas
• checklists/: una por dominio de seguridad (ver checklists/README.md)
• stacks/: sumideros, fuentes y trampas específicos de lenguaje/framework
• templates/: plantillas de configuración, alcance y hallazgos manuales