# Auditoría de la primera entrega

Fecha: 2026-09-19. Base: ZIP del módulo facilitado por el titular. Se extrajo en un
área de trabajo separada y se construyó este árbol sin copiar ningún historial Git.

## Revisión de secretos

No se encontraron credenciales reales literales en el código aportado: las contraseñas
se leían de los custom fields en ejecución. Sí se encontraron URLs de infraestructura
hardcodeadas y un flujo que introducía credenciales de panel en HTML/JavaScript.

- Se eliminaron las URLs de producción del módulo y de `lib/VPSManager.php`.
- Se extrajeron API, Graphite y vista completa de gráficas a configuración externa.
- Los dos bloques de autologin (cliente/administración) desaparecieron.
- Se eliminaron siete bloques `try/catch` vacíos cuyo `logModuleCall` habría registrado
  `$params`, mensajes y trazas completos. No se conserva un logger de credenciales.
- Se habilitó `CURLOPT_RETURNTRANSFER` en las llamadas heredadas que volcaban respuestas
  al navegador. No se expone el cuerpo de la API a HTML.
- El ejemplo de configuración está vacío; no existe configuración real en el árbol.
- `.gitignore` excluye configuración, entornos, backups, logs, dumps y archivos comprimidos.

`gitleaks` no estaba instalado. Se utilizó `tools/audit.py`, revisión manual de coincidencias
y comparación del módulo saneado con el original, además de inventario de archivos.
El análisis cubre:

1. `password`, `passwd`, `secret`, `token`, `api_key`, `apikey`, `Authorization:`, cookies y
   marcadores `BEGIN PRIVATE KEY` / `BEGIN RSA PRIVATE KEY`.
2. Valores de credencial literales, formatos conocidos de tokens, claves privadas y
   credenciales embebidas en URLs.
3. IPs privadas y literales de alta entropía, revisados con contexto.
4. `.env`, configuración privada, claves SSH, certificados privados, SQL, logs, backups,
   swap, ZIP/tar y binarios no revisados.
5. Dependencias locales contrastadas por SHA-256; la descarga original Chart.js 4.4.8 se
   verificó contra el SHA-512 de integridad publicado en el registro NPM y se conserva
   su licencia MIT. El wrapper de aislamiento se genera mediante un script legible.
6. Mismo análisis antes de `git init`, sobre el índice y sobre los blobs de `HEAD`.

Las coincidencias legítimas son nombres de opciones/variables, documentación de seguridad,
el token CSRF de WHMCS, patrones del propio escáner y sentinelas ficticios `FAKE_` del test.
Las URLs `user:pass@…example.invalid` son fixtures negativos que deben rechazarse.
No se detectaron secretos reales en el árbol auditado. Esto describe los resultados de
las comprobaciones realizadas, no una garantía matemática del escáner.

## Pruebas realizadas

- PHP 8.1.2 (paquete Ubuntu con actualizaciones): `php -n -l` en todos los PHP, sin errores.
- `php -n tests/run.php`: 158 aserciones PASS, HTTP simulado, sin acceso a producción.
- `node tests/frontend.cjs`: 24 aserciones PASS.
- `node --check assets/metrics.js`: PASS.
- Revisión visual en navegador local: las tres gráficas, unidades y cortes en los huecos.
- Configuración: fichero válido, inexistente, sintaxis errónea, tipo erróneo, clave ausente
  y URL inválida; rechazos de esquemas inseguros y credenciales en URL.
- Graphite: HTTP 500, timeout, JSON inválido, respuesta demasiado grande, series ausentes,
  respuesta parcial, puntos inválidos, timestamps duplicados/desalineados y `null`.
- Validación: UUID válido y malicioso, tipos no LX y whitelist de cinco rangos.
- Memoria del fixture: 8589934592 bytes = 8 GiB, usada 4365361152 bytes,
  porcentaje 50.81949234008789 %. No se presupone una capacidad fija.
- Red: tasas mantenidas en bytes/s en PHP y multiplicadas por 8 solo al presentar.
- Autorización en el límite del módulo: GET/POST hostiles no cambian el UUID/tipo del
  servicio resuelto por WHMCS; los enlaces usan su `serviceid`, no el `id` solicitado.
- Regresión con dobles: reinicio/parada/arranque, firewall, lista/restauración de snapshots,
  suspensión/reactivación, cancelación y selectores conservan rutas/payloads esperados.

## Límites y decisiones de despliegue

No se ha accedido a una instalación WHMCS ni a un servicio VPS de producción. La
regresión anterior prueba contratos mediante mocks, no efectos reales de provisioning.
Quedan por verificar en staging la versión/plantilla instalada, autorización efectiva
entre dos clientes, campos solo de administrador, CSRF del dispatcher y política CSP.

La vista completa Graphs conserva el botón, pero requiere configuración y confirmación
de que su servicio externo autentica/autoriza; no se ha validado su seguridad real.
El autologin ISPConfig se sustituye por login manual. SSO seguro y licencia global siguen
pendientes. Los avisos de copyright y licencia de componentes ajenos se conservan.

No se ha modificado la semántica heredada de éxito/error de suspensión/reactivación.
La API heredada puede anunciar éxito sin comprobar HTTP; la mejora de ese contrato queda
fuera de esta intervención para evitar una reescritura del provisioning.