Auditoría

Por qué existe esta página

Prometemos auditorías en días, no en trimestres. Las promesas necesitan pruebas, por eso esta página es nuestro compromiso público: cada afirmación está respaldada por un artefacto concreto del conjunto de evidencias de auditoría de SRARS. Si un dato todavía se está midiendo, lo decimos; no publicamos estimaciones como hechos.

Lista de verificación de auditoría

Cada sistema de SRARS se puede verificar con esta lista. Cada punto corresponde a un artefacto real e inspeccionable, no a un documento escrito a posteriori. Los artefactos siguientes son de este mismo sitio.

• Modelo de datos explícito. El esquema completo son unas pocas migraciones SQL legibles: publicaciones y mensajes de contacto en 002_site_content.sql, usuarios y sesiones de administración en 003_admin_auth.sql. Cada columna tiene nombre, tipo y comentario.
• Contratos tipados. Cada página es una función Go generada (Templ): una plantilla que no compila es una compilación que no se publica. Los datos fluyen por structs simples: el handler llena, el componente renderiza, nada es implícito.
• Comportamiento observable. La franja de métricas del pie de página de este sitio es la muestra en vivo: recuentos de solicitudes y errores, percentiles de latencia, visitantes únicos y tiempo activo, publicados por el propio servidor cada cinco segundos.
• Historial completo de cambios. Las migraciones son de solo adición y se registran por nombre en schema_migrations: cualquier estado de la base de datos se puede rastrear hasta la migración exacta que lo produjo. Las escrituras de administración están protegidas por sesión y validadas con CSRF.
• Superficie de ataque mínima. La imagen de producción se construye FROM scratch: sin shell, sin gestor de paquetes, sin intérprete: un binario estático, certificados CA y datos de zona horaria, ejecutándose como no root (uid 65532). No hay nada dentro del contenedor hacia donde pivotar.
• Compilaciones reproducibles. Un solo comando va del código fuente al binario estático: make build (CGO deshabilitado, ruta recortada, símbolos eliminados). El mismo comando produce el mismo binario en cualquier máquina con el toolchain de Go.

Tiempo de verificación medido

La afirmación: una auditoría completa de un sistema SRARS toma días, no trimestres. Este sitio ya pasó por dos ciclos de verificación:

• Revisión externa: una revisión de seguridad independiente de todo el código, el contenedor y el modelo de autenticación, por un revisor sin familiaridad previa con el código — el peor caso para el tiempo de auditoría. Alcance: inyección SQL, XSS, CSP, hash de contraseñas, sesiones, CSRF, limitación de tasa, confianza en headers de proxy, IDOR, endurecimiento del contenedor y versiones de dependencias. Resultado: cero hallazgos críticos o altos; tres medios y dos bajos, todos corregidos en la misma sesión. El informe completo está en el repositorio (docs/SECURITY.md).
• Ciclo de endurecimiento en producción: una segunda verificación en el lanzamiento: el escaneo automatizado de vulnerabilidades (govulncheck) encontró diez CVEs de la biblioteca estándar — actualizado y re-escaneado a cero; la contraseña del admin se rotó a un secreto de 256 bits con parámetros argon2id endurecidos (128 MiB, dos pasadas); la protección de borde (HSTS preload, Cloudflare Access en la superficie admin) se añadió y verificó en vivo contra cada ruta admin.
• Evidencia de regresión: las correcciones del día del lanzamiento (un soft-404 en el router que servía páginas con HTTP 200, una versión de cache-bust desactualizada que fijaba a los clientes a una hoja de estilo rota) están cubiertas por pruebas de regresión en el repositorio — la misma clase de bug no puede volver silenciosamente.

Ambos ciclos se midieron en días, no trimestres — la revisión externa en una sesión, el endurecimiento en una tarde. El código es lo suficientemente pequeño para que una persona lo re-verifique de punta a punta en una tarde. Esa es la promesa de auditoría, demostrada.

El historial de cambios

Cada mutación en un sistema SRARS queda registrada: quién, qué, cuándo y por qué. En este sitio, el rastro es estructural:

• Los cambios de esquema son migraciones de solo adición, registradas por nombre — la propia base de datos es el registro de cambios.
• Los cambios de contenido (publicaciones, secciones, proyectos) pasan por el área de administración: sesión argon2id, token CSRF en cada escritura, IDs parseados numéricamente.
• Los cambios de código viven en el control de versiones con las plantillas generadas confirmadas — cada página renderizada se remonta a su fuente.

Ejecútalo por tu cuenta

La evidencia de auditoría más sólida es un sistema que puedes inspeccionar sin que estemos presentes. Los sistemas SRARS son binarios estáticos únicos con bases de datos integradas: clona, compila, ejecuta y verifica.

• Repositorio público: github.com/WhoseBiasDoYallSeek/fgoths-framework — el framework que genera sistemas como este.
• Comando de compilación: make build — un solo comando del clon a un binario Linux estático en bin/app.
• Recorrido de verificación: el modelo de datos está en database/migrations/*.sql; el informe de seguridad está en docs/SECURITY.md; la metodología de diseño está en docs/DESIGN.md; las pruebas se ejecutan con go test ./...