Capítulo 6: Shannon Pro — La Plataforma AppSec Completa

Shannon Lite es una herramienta de pentesting dinámico poderosa, pero Shannon Pro va un nivel más allá: antes de ejecutar un solo exploit, analiza el código fuente con técnicas de análisis estático avanzado que producen hallazgos que ningún escáner dinámico podría encontrar. Luego, esos hallazgos estáticos alimentan directamente al motor de explotación dinámico.

La diferencia fundamental: correlación estático-dinámica

En Shannon Lite, el análisis de código sirve para guiar la estrategia. En Shannon Pro, el análisis estático genera hallazgos reales que luego se validan dinámicamente:

flowchart LR
    subgraph "Shannon Lite"
        SA1["Análisis de código\n(orientación estratégica)"] --> DAST1["Pentesting dinámico\n(5 agentes)"]
        DAST1 --> R1["Reporte"]
    end

    subgraph "Shannon Pro"
        SAST["Análisis estático agéntico\nCPG + flujo de datos"] --> CORR["Correlación\nestático-dinámica"]
        SCA["SCA con alcanzabilidad"] --> CORR
        SECRETS["Detección de secretos\n+ validación en vivo"] --> CORR
        BLT["Pruebas de lógica\nde negocio"] --> CORR
        CORR --> DAST2["Pentesting dinámico\n(13 agentes + hallazgos SAST)"]
        DAST2 --> R2["Reporte unificado\nEstático + Dinámico"]
    end

Etapa 1: Análisis Estático Agéntico

Grafos de Propiedades de Código (CPG)

El corazón del SAST de Shannon Pro es el Code Property Graph (CPG), una representación unificada del código fuente que combina tres estructuras:

graph TD
    CPG["Code Property Graph (CPG)"]
    CPG --> AST["Abstract Syntax Tree (AST)\nEstructura sintáctica del código"]
    CPG --> CFG["Control Flow Graph (CFG)\nFlujo de ejecución posible"]
    CPG --> PDG["Program Dependence Graph (PDG)\nDependencias de datos y control"]

    AST --> QUERY["Queries de análisis\nde seguridad"]
    CFG --> QUERY
    PDG --> QUERY
    QUERY --> FINDINGS["Hallazgos con\njustificación de flujo"]

El CPG permite a Shannon Pro responder preguntas como:

• “¿Puede el valor de req.params.userId llegar a esta query SQL sin pasar por sanitización?”
• “¿Existe algún camino de ejecución donde este secreto queda expuesto en los logs?”
• “¿Hay alguna ruta de código donde el campo role puede ser modificado por un usuario sin privilegios?”

SAST: Análisis de Flujo de Datos

El análisis de flujo de datos de Shannon Pro opera en tres fases:

Fase A: Identificación de fuentes y sumideros

graph LR
    SRC1["req.params\nreq.query\nreq.body\nreq.headers"] -->|"Fuentes\n(datos no confiables)"| FLOW["Flujo de datos\na través del CPG"]
    FLOW --> SINK1["db.query()\nexec()\neval()\nres.send()"]
    FLOW --> SINK2["fs.writeFile()\nfetch()\nchild_process.exec()"]

    SINK1 -->|"Sumideros\n(puntos de daño potencial)"| VULN["Vulnerabilidad potencial"]
    SINK2 --> VULN

Fase B: Trazado de rutas con agentes LLM

Para cada par fuente→sumidero identificado, un agente LLM analiza cada nodo en la ruta para determinar si hay sanitización efectiva. Este análisis contextual es lo que distingue el SAST de Shannon Pro de herramientas basadas en reglas estáticas como Semgrep:

// Shannon Pro analiza esta ruta:
// req.query.search → sanitizeInput() → db.query()

function sanitizeInput(input) {
  // Shannon analiza: ¿esta sanitización es suficiente para SQL?
  return input.replace(/[<>]/g, '');  // Solo sanitiza para XSS, no para SQL
}

const results = await db.query(
  `SELECT * FROM products WHERE name LIKE '%${sanitizeInput(req.query.search)}%'`
);
// Resultado: Shannon Pro reporta SQLi porque la sanitización es insuficiente para este sumidero

Un SAST basado en reglas vería sanitizeInput() y podría asumir que es seguro. Shannon Pro entiende que replace(/[<>]/g, '') no previene SQL injection.

Fase C: Validación de rutas

El agente confirma que el flujo de control realmente permite que los datos lleguen al sumidero en al menos un escenario de ejecución, eliminando falsos positivos donde la vulnerabilidad está protegida por condiciones que siempre son falsas.

SAST: Detección de Problemas Puntuales

Además del análisis de flujo de datos, Shannon Pro detecta vulnerabilidades que no dependen de un flujo:

Categoría	Ejemplos detectados
Cifrado débil	MD5/SHA1 para contraseñas, DES, RC4
Credenciales hardcodeadas	API keys, tokens, contraseñas en código
Configuraciones inseguras	TLS 1.0 habilitado, CORS *, cookies sin HttpOnly
Headers de seguridad	Ausencia de CSP, HSTS, X-Frame-Options
PRNG débil	Math.random() para tokens de seguridad
Serialización insegura	JSON.parse de datos no confiables con eval

// ❌ Shannon Pro detecta: PRNG débil para token de reset
const resetToken = Math.random().toString(36).substring(7);  // Predecible

// ❌ Shannon Pro detecta: MD5 para contraseñas
const hash = md5(password);  // MD5 no es apropiado para contraseñas

// ❌ Shannon Pro detecta: CORS permisivo
app.use(cors({ origin: '*' }));  // Permite cualquier origen

// ❌ Shannon Pro detecta: Cookie sin flags de seguridad
res.cookie('session', token);  // Falta: httpOnly, secure, sameSite

SAST: Pruebas de Lógica de Negocio

Esta es la capacidad más diferenciadora de Shannon Pro y la que más asombra a los equipos de seguridad.

Los agentes LLM leen el código y descubren automáticamente los invariantes de negocio: reglas que deben cumplirse para que la aplicación sea segura. Luego generan escenarios de prueba adversarios para intentar violar esos invariantes.

Ejemplo real del equipo de Keygraph:

En una plataforma multi-tenant de gestión de documentos, Shannon Pro analizó el código y dedujo el invariante:

“Un documento solo debe ser accesible por usuarios de la misma organización que lo creó. El campo organization_id en la tabla documents debe siempre coincidir con el organization_id del usuario autenticado.”

Luego intentó violar ese invariante y confirmó que era posible acceder a documentos de la Organización B desde la Organización A sin verificación adicional, a través de un endpoint de búsqueda que no filtraba por organization_id.

Este tipo de hallazgo es imposible de encontrar con un escáner DAST convencional o con reglas SAST estáticas. Requiere entender la semántica del negocio, algo que solo un agente LLM con acceso al código puede hacer.

flowchart TD
    CODE["Código fuente completo"] --> AGENT["Agente LLM\nAnálisis de lógica de negocio"]
    AGENT --> INV1["Invariante 1:\nDocumento pertenece a organización"]
    AGENT --> INV2["Invariante 2:\nUsuario solo ve sus propios pedidos"]
    AGENT --> INV3["Invariante 3:\nPrecio no puede ser negativo"]

    INV1 --> TEST1["Escenario adversario:\nAcceder doc de Org B desde Org A"]
    INV2 --> TEST2["Escenario adversario:\nVer pedidos de otro usuario"]
    INV3 --> TEST3["Escenario adversario:\nEnviar precio -100 en el body"]

    TEST1 --> RESULT1["VULNERABILIDAD: IDOR cross-tenant [HIGH]"]
    TEST2 --> RESULT2["SEGURO: filtrado por userId correcto"]
    TEST3 --> RESULT3["VULNERABILIDAD: Precio negativo aceptado [MEDIUM]"]

Etapa 2: SCA con Análisis de Alcanzabilidad

Los escáneres de dependencias tradicionales (Dependabot, Snyk) alertan sobre cada CVE en cada dependencia, independientemente de si el código vulnerable es realmente usado. Esto genera mucho ruido.

Shannon Pro elimina los falsos positivos con un proceso de cuatro pasos:

flowchart TD
    CVE["CVE en dependencia\nejemplo: lodash 4.17.15\nprototype pollution"] --> F1
    F1["Paso 1: Identificar\nla función vulnerable exacta\nlodash.merge()"] --> F2
    F2["Paso 2: Verificar que\nel framework afectado se usa\n¿lodash está en el código?"] --> F3
    F3["Paso 3: Consultar el CPG\n¿lodash.merge() es llamada\ndesde algún punto de entrada?"] --> F4
    F4["Paso 4: Trazar el flujo\n¿Los datos que llegan a merge()\nvienen de fuentes no confiables?"] --> OUT

    OUT --> YES["REPORTAR:\nVulnerabilidad alcanzable\n+ explotable"]
    OUT --> NO["DESCARTAR:\nDependencia vulnerable\npero no alcanzable"]

El resultado: Shannon Pro solo reporta dependencias vulnerables donde hay una ruta real de explotación desde datos externos del atacante. Los falsos positivos se eliminan estructuralmente.

Detección de Secretos con Validación en Vivo

Shannon Pro combina tres técnicas para encontrar secretos expuestos en el código:

1. Regex patterns: Detecta formatos conocidos de API keys, tokens y contraseñas:

# Patrones que Shannon Pro detecta automáticamente:
sk-ant-api03-[a-zA-Z0-9]{90}  # Anthropic API key
AKIA[0-9A-Z]{16}              # AWS Access Key ID
ghp_[a-zA-Z0-9]{36}          # GitHub Personal Access Token
eyJ[a-zA-Z0-9_-]+             # JWT token (si está hardcodeado)

2. Detección semántica con LLM: Los agentes LLM identifican secretos que no siguen patrones conocidos:

// Shannon Pro detecta esto aunque no hay regex para ello:
const DB_PASS = "MyD4tab4s3P@ss!";  // Contexto indica que es una contraseña
const INTERNAL_KEY = "prod-secret-42-xK9";  // Semánticamente es un secreto

3. Validación de disponibilidad: Para los secretos encontrados, Shannon Pro intenta usarlos para autenticarse en los servicios correspondientes:

# Shannon Pro encontró en el código:
STRIPE_SECRET_KEY = "sk_live_4eC39HqLyjWDarjtT1zdp7dc"

# Intenta autenticarse con la key contra la API de Stripe:
curl https://api.stripe.com/v1/charges \
  -u "sk_live_4eC39HqLyjWDarjtT1zdp7dc:"

# Si responde 200: SECRET ACTIVO [CRITICAL]
# Si responde 401: Secret inválido o revocado [LOW]

Esta validación en vivo elimina falsos positivos de secrets que ya fueron rotados o que solo existen en ejemplos de documentación.

Comparativa: Shannon Lite vs Shannon Pro

Capacidad	Lite (AGPL-3.0)	Pro (Comercial)
Pentesting dinámico (DAST)	✅ 5 agentes	✅ 13 agentes
Análisis de código (orientación)	✅ Básico	✅ CPG completo
SAST con flujo de datos	❌	✅
Pruebas de lógica de negocio	❌	✅
SCA con alcanzabilidad	❌	✅
Detección de secretos	❌	✅ + validación en vivo
Correlación estático-dinámica	❌	✅
Despliegue	CLI local	Cloud gestionado o self-hosted
Runner autohospedado	N/A	✅ Tu infraestructura
Encriptación de código en reposo	N/A	✅

Aislamiento de datos en Shannon Pro

Para equipos que trabajan con código propietario sensible, Shannon Pro ofrece un modelo de runner autohospedado:

graph TD
    subgraph "Infraestructura del Cliente"
        RUNNER["Shannon Runner\n(Docker en tu infra)"]
        REPO["Repositorio\n(clon temporal efímero)"]
        LLM["Llamadas LLM\n(tus propias API keys)"]
        RUNNER --> REPO
        RUNNER --> LLM
    end

    subgraph "Keygraph Cloud"
        DASH["Dashboard\nHallazgos agregados"]
        MGMT["Gestión de\nworkspaces"]
    end

    RUNNER -->|"Solo hallazgos\nagregados (sin código)"| DASH

Con este modelo:

• El código fuente nunca sale de tu infraestructura
• Las llamadas a la API de IA se hacen con tus credenciales directamente
• Keygraph solo recibe los hallazgos agregados (vulnerabilidades encontradas, sin fragmentos de código)
• El repositorio se clona a un espacio temporal y se elimina completamente después del análisis

Integración con CI/CD

Shannon Pro puede integrarse como un step en el pipeline de CI/CD para bloquear deploys que introduzcan vulnerabilidades críticas:

# .github/workflows/security.yml (ejemplo conceptual)
name: Shannon Security Scan

on:
  pull_request:
    branches: [main]

jobs:
  security-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Run Shannon Pro
        uses: keygraph/shannon-action@v1
        with:
          url: ${{ secrets.STAGING_URL }}
          api-key: ${{ secrets.SHANNON_PRO_KEY }}
          fail-on: critical,high

      - name: Upload report
        uses: actions/upload-artifact@v4
        with:
          name: security-report
          path: shannon-report.html

Este flujo garantiza que ningún PR con vulnerabilidades críticas confirmadas llega a la rama principal.

Cuándo elegir cada edición

Shannon Lite es suficiente cuando:

• Quieres auditar tus propias aplicaciones periódicamente
• Tu equipo tiene algunos conocimientos de seguridad y puede interpretar el reporte
• El presupuesto es limitado (solo pagas los tokens de IA)
• Trabajas en proyectos personales o startups en etapa temprana

Shannon Pro vale la pena cuando:

• Manejas datos sensibles de usuarios y la seguridad es crítica
• Necesitas reportes de cumplimiento (SOC 2, ISO 27001, PCI DSS)
• Quieres integrar el pentesting en el CI/CD
• El código es propietario y no puede salir de tu infraestructura
• Necesitas auditoría continua en cada ciclo de desarrollo

Recursos y comunidad

• Repositorio oficial: github.com/KeygraphHQ/shannon
• Discord: Comunidad de usuarios, preguntas y feedback
• Office Hours: Sesiones de 15 minutos gratis los jueves (US/EU: 10 AM PT, Asia: 2 PM IST)
• GitHub Issues: Reporte de bugs y feature requests
• Email: [email protected] (consultas sobre Shannon Pro)

Resumen del tutorial

Has completado el tutorial completo de Shannon. A lo largo de los seis capítulos cubriste:

• La filosofía No Exploit, No Report y por qué importa
• Instalación con npx y configuración de proveedores de IA
• Las 5 fases del pentesting autónomo y los 13 agentes especializados
• El flujo completo de una auditoría con autenticación TOTP y workspaces reanudables
• Las 4 categorías de vulnerabilidades OWASP y cómo Shannon las detecta y explota
• Shannon Pro: CPG, SAST, SCA, lógica de negocio y correlación estático-dinámica

Shannon representa una nueva generación de herramientas de seguridad que combinan el razonamiento de los LLMs con la ejecución real de exploits, democratizando el pentesting de calidad profesional para equipos de todos los tamaños.

---

Usa Shannon responsablemente, siempre con autorización explícita del propietario del sistema auditado.

← Volver al índice