Confianza y seguridad
Los controles que SiteGuardia implementa de verdad, y las afirmaciones que no hace.
Versión 1.0.0Actualizado 2026-09-22
Qué es esta página
Una declaración de controles que existen, en un producto que todavía no opera comercialmente. Todo lo de abajo está implementado. Nada de lo de abajo es aspiracional, y donde algo está previsto en lugar de construido, se dice.
Afirmaciones que no hacemos
No estamos certificados en ISO 27001. No estamos auditados en SOC 2. SiteGuardia no dispone actualmente de certificaciones de protección de datos.
Esa última frase decía antes que estar "certificado en RGPD" es algo que no existe, y era falso. El artículo 42 del RGPD contempla mecanismos de certificación, sellos y marcas de protección de datos, y existen esquemas aprobados a su amparo. Lo cierto es más estrecho y es lo que dice la frase ahora: no tenemos ninguno. Corregirlo aquí en lugar de en silencio es justamente para lo que sirve esta página.
No tenemos logos de clientes, ni recuentos de usuarios, ni valoraciones, ni testimonios, porque el producto todavía no tiene clientes. Si ves alguna de esas afirmaciones asociada a SiteGuardia, no viene de nosotros.
Arquitectura
El plano de control y el plano de análisis están separados.
El plano de control contiene la aplicación web, la API, PostgreSQL y Redis. Nunca ejecuta una herramienta de análisis y nunca se conecta a un objetivo.
El plano de análisis contiene los workers. No aceptan conexiones entrantes, no tienen credenciales de base de datos, no tienen ruta a la red de datos, no montan el socket de Docker, se ejecutan como usuario sin privilegios sobre un sistema de ficheros de solo lectura con un directorio de trabajo respaldado por memoria, descartan todas las capacidades de Linux, se ejecutan con no-new-privileges y tienen límites de CPU, memoria y procesos.
Solo se publican los puertos 80 y 443. PostgreSQL, Redis, la API y los workers no publican nada al host.
Seguridad de las peticiones
La visita controla el objetivo, lo que convierte la falsificación de peticiones del lado del servidor en el riesgo principal. La defensa está en capas:
- Un analizador de objetivos estricto: solo HTTP y HTTPS, sin credenciales en la URL, sin literales IP, sin puertos, sin nombres de uso especial, con sufijo público válido obligatorio.
- Cada dirección resuelta se contrasta con una política de redes bloqueadas basada en los registros de direcciones de propósito especial de la IANA. Una sola respuesta privada rechaza el nombre entero.
- Nueva resolución inmediatamente antes de conectar, con el conjunto de direcciones validado fijado, de modo que un nombre que cambia entre la admisión y la conexión se rechaza.
- Cada redirección se vuelve a validar por la ruta completa antes de seguirla.
- Un firewall de host que bloquea los mismos destinos de forma independiente, para que un error en el analizador no se convierta en una exposición.
Cuáles de estos viajan con el software
Los controles de arriba son dos cosas distintas y esta página no lo decía.
Propiedades del producto. Están en el código, en el esquema y en las definiciones de los contenedores, y se cumplen allá donde se ejecute SiteGuardia. El plano de análisis no tiene credenciales de base de datos ni ruta de red hacia ella. Un hallazgo clasificado como sensible en un objetivo no verificado no tiene ningún campo en el esquema que pueda llevar su evidencia, y la base de datos se niega a guardar uno que la lleve. Los informes se direccionan con hashes con clave. Cada dirección resuelta se comprueba contra la política de redes bloqueadas, y cada redirección se vuelve a validar. El renderizador que produce un PDF ejecuta un navegador que no puede alcanzar la red en absoluto.
Propiedades de un despliegue. Son configuración de la máquina donde el servicio se ejecuta, y otro despliegue tiene que reproducirlas a propósito. El cortafuegos del anfitrión que bloquea los mismos destinos por segunda vez. El almacenamiento en memoria para los espacios de trabajo del escáner. El cifrado en reposo que ofrezca el anfitrión. La retención de registros, el tratamiento de copias de seguridad y dónde están esas copias.
Hoy hay un despliegue y es una máquina de desarrollo. Nada de la segunda lista se ha verificado en un anfitrión de producción, porque no lo hay. Cuando lo haya, esta página dirá cuál y qué se comprobó.
Tratamiento de datos
La salida bruta del escáner vive en almacenamiento respaldado por memoria y se borra en minutos, incluso si un trabajo falla. Los informes saneados caducan a las 48 horas y se purgan. Los tokens de informe son 256 bits de salida de un generador criptográfico y se guardan como hashes con clave, nunca en texto claro. Las direcciones IP no se almacenan para la cuota; en su lugar se deriva una clave seudónima rotatoria.
Hallazgos sensibles
Un hallazgo clasificado como sensible en un objetivo no verificado se reduce a metadatos antes de persistirlo. La evidencia no se oculta en la interfaz: nunca se escribe. La base de datos tiene una restricción que rechaza guardar un hallazgo bloqueado que lleve evidencia, y el modelo de respuesta de la API no tiene ningún campo que pudiera llevarla.
Sin IA en el plan gratuito
Cada explicación que lee una visita viene de un catálogo editorial versionado. Ningún modelo genera hallazgos de seguridad, severidades ni recomendaciones. El mismo hallazgo produce las mismas palabras siempre, en los dos idiomas.
Ahí hay dos cosas, y se evidencian de forma distinta. Que esté versionado es comprobable: cada entrada lleva una versión, el texto publicado se genera desde la fuente y la construcción falla si los dos difieren. Cada entrada registra además un revisor y una fecha de revisión. Eso es constancia de que una revisión quedó anotada, que no es lo mismo que la garantía de que ocurrió, y esta página decía "revisado por personas" como si lo fuera. Volverá a decirlo cuando exista un proceso de revisión que alguien de fuera del equipo pueda inspeccionar.
No entrenamos ningún modelo con los resultados de los análisis.
Cadena de suministro
Las versiones de las herramientas y las imágenes de contenedor están fijadas por digest. La lista permitida de plantillas Nuclei es explícita, versionada y revisada una a una; que upstream publique una plantilla nueva no la añade. El análisis de dependencias, contenedores y secretos se ejecuta en CI. Las actualizaciones se preparan y se prueban antes de producción.
Nuestra propia política de divulgación
SiteGuardia publica /.well-known/security.txt y acepta informes de vulnerabilidad. Respondemos, no amenazamos a quien investiga de buena fe, y damos crédito a quien lo desea.
Previsto, no construido
La verificación de propiedad del dominio, que liberará los hallazgos retenidos a un propietario verificado, está prevista. Las cuentas, el historial y la monitorización están previstos. Ninguno existe hoy, y esta página cambiará cuando existan.