[IDEA] Auditoría y endurecimiento para producción de Forja

[LeonardoDevOps]

Informe de auditoría y endurecimiento para producción de Forja

Fecha de corte: 30 de julio de 2026
Destinatario: Creador y mantenedores del repositorio original santmun/forja
Fork auditado: LeonardoDevOps/forja_leonardoAI
Objetivo: Resumir análisis realizado respecto del código original, la evolución de las
vulnerabilidades y los pendientes antes de considerar una adopción en producción.

1. Resumen ejecutivo

El trabajo de endurecimiento partió del commit original
ffe32d8
y terminó integrado en el fork mediante el commit
17098bc.

Resultados principales:

• autenticación fail-closed para Telegram, Twilio, ManyChat, Meta y WhatsApp Cloud;
• cierre de rutas directas de SSRF en medios y allowlist exacta por canal;
• validación de redirects, límites de tamaño, timeout y rechazo de destinos privados;
• eliminación de filtración de errores y escape seguro de contenido controlado por usuarios/LLM;
• panel administrativo siempre autenticado, sin bypass público, con credenciales mínimas y
  cabeceras de seguridad;
• migración de agents 0.1.6 a 0.3.10 y sustitución del acceso a internals por la API pública;
• reducción del lockfile de 739 a 444 dependencias auditadas;
• reducción de 47 rutas vulnerables en el lock original a 1 ruta moderada residual;
• ESLint con cero warnings, tipos explícitos en fronteras externas y CI que bloquea regresiones;
• 526 pruebas, 83,35 % de cobertura de líneas y un gate administrativo por archivo;
• CI en Node 22 y 24, CodeQL, Dependabot configurado, Actions fijadas por SHA y permisos mínimos.

La conclusión no es una certificación de “cero riesgo”. Persisten:

1. 14 alertas CodeQL abiertas: 5 HIGH y 9 MEDIUM, todas en código preexistente del CLI o en
   una aserción de test;
2. 1 advisory npm MODERATE no alcanzable en el runtime workerd;
3. riesgo residual de DNS rebinding si se compromete un hostname autorizado;
4. ausencia de rate limiting distribuido dentro del Worker;
5. Dependabot Alerts deshabilitado en la configuración del fork;
6. configuración operativa y secretos que deben aplicarse en Cloudflare antes del despliegue.

Por tanto, el Worker/chatbot estaría significativamente más preparado para ir a producción con estas mejoras, pero el
CLI requiere una revisión de seguridad dedicada antes de usarlo como canal confiable de
instalación o actualización.

2. Alcance y línea base

Elemento	Referencia
Base común auditada	ffe32d87c9615945079eb9d073e6c6a51a71c8e9
origin/main endurecido	17098bc62c016f576a5e2aa2d20fafe5207b4cdf
upstream/main actual	3fd4142abfac537e64ff275651d37293b47ce609
Divergencia actual	upstream: 1 commit propio; fork: 40 commits propios
Comparación completa	[ffe32d8...17098bc](Por Definir)

La auditoría incluyó:

• comparación Git entre la base original y el fork fusionado;
• revisión de los siete PR y de los once planes de implementación;
• pnpm audit --audit-level low sobre el lockfile original y el actual;
• grafo efectivo de dependencias mediante pnpm;
• estado de CodeQL y Dependabot mediante la API de GitHub;
• validaciones de CI, pruebas, cobertura, lint, tipos y formato;
• revisión de restricciones: member/, wrangler.toml, secretos, despliegues y publicación npm.

3. Entregas fusionadas

PR	Alcance	Evidencia principal
#1	Calidad reproducible, SSRF/medios, escape HTML, errores, CI y política de seguridad	452 tests; 72,56 % líneas; 0 HIGH/CRITICAL en la auditoría de aquel momento
#2	agents 0.3.10, API pública de scheduling, supply chain y egress exacto	469 tests; 72,90 % líneas; cierre de 3 GHSA directos de agents
#3	Eliminación de 33 warnings ESLint y tipado de fronteras externas	482 tests; 73,81 % líneas; --max-warnings 0
#4	Cobertura administrativa y gate por archivo	507 tests; 82,62 % líneas; 32 controles de cobertura
#5	Autenticación de webhooks	520 tests; 83,31 % líneas
#6	Panel y control-plane fail-closed	526 tests; 83,35 % líneas
#7	EOL reproducible y SDK MCP parcheado	CI Node 22/24 y CodeQL ejecutados; auditoría sin HIGH

4. Cambios a realizar para producción

4.1 Seguridad del runtime y de las entradas

Superficie original	Cambio aplicado	Estado
Telegram, Twilio y ManyChat aceptaban eventos sin autenticidad	Telegram exige secret token; Twilio valida HMAC-SHA1/base64 sobre URL y parámetros exactos; ManyChat exige secreto compartido	Pendiente
Meta/WhatsApp Cloud	Se conserva y prueba HMAC-SHA256 sobre el cuerpo crudo	Pendiente
Eventos falsos podían disparar LLM, costes, spam o aprendizaje	Verificación anterior al parseo y a la ingestión; fallo cerrado si falta configuración	Pendiente
URLs de medios externas controladas por payload	Solo HTTPS, puerto estándar, sin credenciales, sin hosts locales/IP privadas	Pendiente
Redirects de medios	Cada destino se valida de nuevo, con máximo de redirects	Pendiente
Descargas sin límites operativos suficientes	Timeout de 15 s y máximo de 25 MiB, incluso sin Content-Length	Pendiente
Host público arbitrario	Allowlist exacta por canal; sin comodines ni coincidencias por sufijo	Pendiente
Posible DNS rebinding de un hostname aprobado	Documentado; requiere proxy/Service Binding de egress para eliminarlo	Pendiente
Excepciones de webhook devueltas al cliente	Respuesta genérica; detalle solo en logs	Pendiente
Texto de usuario/LLM interpolado en email de handoff	Escape HTML, saneado de subject, límites Zod y URL construida con URL	Pendiente
Panel cacheable o embebible	no-store, DENY, nosniff y no-referrer, incluidos rechazos	Pendiente

4.2 Autenticación administrativa

• /admin/* siempre exige Basic Auth; se eliminó el bypass DASHBOARD_PUBLIC.
• DASHBOARD_PASSWORD debe tener al menos 16 caracteres; si falta o es débil devuelve 503.
• /api/* exige CONTROL_PLANE_TOKEN de al menos 32 caracteres.
• Las comparaciones sensibles son timing-safe.
• La rotación de credenciales quedó documentada.
• No se añadió un contador local engañoso: un isolate de Workers no proporciona rate limiting
  distribuido. Para producción se recomienda Cloudflare Access, WAF o Rate Limiting.

4.3 Dependencias y supply chain

• agents: 0.1.6 → 0.3.10.
• Scheduling: se retiró la escritura en cf_agents_schedules y el uso directo de alarmas; ahora
  se usan getSchedules, cancelSchedule y schedule.
• React 19 se declaró como peer requerido por agents.
• Hono, Wrangler, Miniflare, TypeScript, Vitest y herramientas quedaron fijados.
• @anthropic-ai/sdk directo se retiró al no ser necesario.
• Se añadieron overrides compatibles para paquetes con parches de seguridad.
• @modelcontextprotocol/sdk se fuerza a 1.26.0, que corrige
  GHSA-345p-7cg4-v4c7.
• Se evitó forzar @hono/node-server 2.x porque es una major transitiva y el adaptador Node no
  se ejecuta en workerd.
• Instalación reproducible con pnpm 10.34.5 y --frozen-lockfile.

4.4 Calidad y pruebas

• ESLint 9 y TypeScript ESLint fijados.
• Los 33 warnings no-explicit-any fueron eliminados mediante tipos y validación de unknown.
• Cualquier warning nuevo hace fallar CI.
• Prettier y .gitattributes normalizan LF en código y documentación.
• member/** y wrangler.toml quedan fuera de la conversión forzada.
• Suite final: 73 archivos / 526 pruebas.
• Cobertura final:

Métrica	Resultado
Statements	80,42 %
Branches	69,64 %
Functions	84,51 %
Lines	83,35 %

• Gate administrativo para ocho módulos: mínimo 70 % en líneas/statements/functions y 50 % en
  branches, con 32/32 comparaciones PASS.

4.5 CI y mantenimiento

• Matriz CI en Node 22 y 24.
• Instalación congelada, formato, ESLint, tipos y cobertura en cada PR.
• Actions fijadas a SHA, permisos mínimos, concurrencia y timeouts.
• CodeQL security-extended en PR, push, ejecución manual y semanal.
• Dependency Review configurado para bloquear nuevas dependencias HIGH en repositorios donde la
  API esté disponible.
• Dependabot configurado semanalmente para npm y GitHub Actions.
• Workflow de publicación npm endurecido, pero nunca ejecutado durante esta auditoría.
• Política SECURITY.md para reporte privado y divulgación coordinada.

5. Registro de vulnerabilidades por severidad

5.1 Interpretación de los conteos

La base de advisories cambia con el tiempo. La reauditoría realizada en la fecha de este informe
sobre el lockfile original encontró 47 rutas vulnerables, correspondientes a 44 advisories
únicos:

Severidad npm	Rutas vulnerables	Advisories únicos
CRITICAL	0	0
HIGH	13	12
MODERATE	27	26
LOW	7	6
Total	47	44

Algunos advisories cuentan más de una vez porque el mismo paquete aparece por varias cadenas.
Este reanálisis no sustituye la evidencia histórica.

Saludos cordiales, Santi

Atentamente,
Leonardo Jimenez
DevOps Team, Applications Migration Project