electrohire/site-health-security-report

Informe de Salud y Seguridad del Sitio

Una habilidad de agente que produce un informe diario (o semanal, o mensual) de salud y seguridad para un sitio web, en lenguaje sencillo, para propietarios ocupados. Es el método diseñado por ElectroHire y generalizado a cualquier pila, por lo que los proyectos de la empresa originaria no forman parte del método.

El informe responde a cinco preguntas en cada edición, con evidencia:

1. ¿Pudieron las personas acceder al sitio y cómo se veía realmente el tráfico?
2. ¿Los motores de búsqueda y los rastreadores de IA pueden encontrarlo y citarlo (SEO/AEO)?
3. ¿El código es seguro: dependencias vulnerables, hallazgos de escaneo de código, secretos filtrados?
4. ¿El perímetro se mantiene firme: TLS, encabezados de seguridad, autenticación de correo electrónico, protección DDoS en el sitio y la API?
5. ¿Cuáles son las 3 a 5 acciones de mayor impacto, cada una con un propietario designado?

Cada edición se califica de A a F, en general y en tres subcalificaciones (Tráfico y confiabilidad, SEO/AEO, Seguridad y salud del código), y cada degradación indica su causa en una línea. Los números nunca se inventan: una fuente a la que la ejecución no puede acceder se informa como "no disponible" con el motivo.

Regla cero: nunca ejecutes esta habilidad sin una ingesta de pila

No asumas Cloudflare, GitHub ni ningún otro proveedor. Antes del primer informe, completa la ingesta de pila en references/stack-intake.md con el usuario y guárdala como la configuración del informe (plantilla: templates/config.example.json; templates/config.example.yaml es el espejo legible por humanos, y el archivo JSON es la configuración de registro que leen las herramientas). Nombra el archivo guardado config.local.json (ignorado por git) y registra las credenciales solo por ubicación ("entrada de bóveda X"), nunca por valor. La ingesta registra:

• Capa de borde / CDN / DDoS: Cloudflare, AWS CloudFront (+ AWS WAF y Shield), Azure Front Door (+ Azure WAF), Fastly, Akamai, Sucuri, o ninguna.
• Repositorio de código: GitHub, GitLab, Bitbucket, Azure DevOps, Gitea/Codeberg, u otro.
• Alojamiento / origen: proveedor de nube, modelo de región, configuración de staging.
• El nombre de host principal frente a los hosts secundarios (API, staging, app, workspace). Esta distinción determina las llamadas de interrupción; consulta la regla de ráfaga a continuación.
• Quién recibe el informe, en qué horario, a través de qué ruta de envío y quién es el propietario de cada clase de recomendación.

Si algún campo de ingesta es desconocido, pregunta. Un informe construido sobre una pila supuesta es peor que ningún informe, porque sus lagunas parecen hallazgos.

El método (seis etapas de recopilación)

Ejecuta cada etapa en cada edición. Una etapa que no se pueda ejecutar se enumera en el informe como no disponible, con el motivo. Nunca compongas alrededor de una etapa faltante en silencio.

1. Tráfico y análisis de borde. Solicitudes, visitantes únicos, ancho de banda, relación de caché, mezcla de códigos de estado (2xx/3xx/4xx/5xx), rutas principales, países principales, anomalías de error, patrones de escáner/sonda. Por proveedor de borde, consulta references/adapters-edge.md.
2. SEO / AEO. Una verificación de preparación para IA (por ejemplo check.aeojs.org) y una verificación SEO (Seobility, recurriendo a PageSpeed Insights, recurriendo a la auditoría on-page de 15 puntos autoejecutada en references/report-writing.md). Cada puntuación lleva un identificador de escaneo y una marca de tiempo de esta ejecución.
3. Seguridad del repositorio de código. Alertas de dependencia abiertas por gravedad, alertas de escaneo de código por gravedad, alertas de escaneo de secretos y la actividad de commits y CI/despliegue del último período. Cuando el sitio se ejecuta en una plataforma de aplicación (WordPress core y plugins, un CMS), las vulnerabilidades conocidas de sus componentes instalados de la fuente de plataforma nombrada también se cuentan aquí (hallazgos security.platform): en una pila de este tipo, la plataforma es donde reside el código explotable. Por repositorio de código, incluido qué hacer cuando el host no tiene escaneo nativo, consulta references/adapters-codehost.md y references/scanning-fallbacks.md.
4. Elementos críticos permanentes. Cualquier elemento nombrado y fechado que el propietario haya marcado como rastreado hasta que se cierre (un CVE en producción, un certificado que expira, una migración). Eliminado solo cuando se verifica cerrado.
5. Escaneos de seguridad del sitio (públicos, sin necesidad de cuenta). Calificación de Mozilla Observatory (observatory.mozilla.org), calificación TLS de SSL Labs y vencimiento del certificado (ssllabs.com/ssltest), los seis encabezados de seguridad (un Content-Security-Policy en modo enforcing cuenta; uno en modo report-only no), redirección HTTP a HTTPS y autenticación de correo electrónico (SPF, política DMARC, MX — leídos de los registros TXT/MX de DNS del dominio con cualquier herramienta de consulta DNS). Estas verificaciones califican el host principal; los encabezados y TLS de un host secundario se informan en la narrativa, no se califican. La postura DDoS para el sitio y la API se cubre en references/ddos.md.
6. Verificaciones de cumplimiento de privacidad e IA (solo comprobables públicamente). La política de privacidad nombra a la entidad legal correcta como controlador, cubre los datos de voz/chat de IA cuando corresponda, nombra los procesadores de pago; los asistentes de IA revelan que son IA en la primera interacción; el consentimiento de cookies es visible; se publica una ruta de solicitud de datos. Informa cada una como aprobado, fallido o no comprobable, solo del texto de la página. Cuando la característica sobre la que trata una verificación no existe (ningún asistente de IA en el sitio, por ejemplo), la verificación es no comprobable con ese motivo, nunca una aprobación, y no se cuenta como fallida.

Cada etapa escribe sus hallazgos en el archivo de hallazgos de la edición; los nombres de campo exactos, tipos y unidades se especifican en references/findings-schema.md. El archivo de hallazgos es el subconjunto de calificación; las cifras narrativas del informe (totales, rutas principales, identificadores de escaneo) provienen de los mismos registros de evidencia fechados de las etapas, enumerados en el libro de contabilidad de evidencia.

La regla de ráfaga (aprendida en producción)

Un pico de errores 5xx no es automáticamente una interrupción. Antes de cualquier llamada de interrupción, segmenta la ráfaga por nombre de host y por dirección de cliente:

• Si los errores se concentran en un host no principal (un host secundario de API, un host de staging) o provienen principalmente de una dirección de cliente, es un evento de escáner o sonda contra ese host, no una interrupción del sitio, por grande que parezca el total a nivel de zona.
• Califica y escribe lo que muestra la segmentación. scripts/site_health.py incluye classify_error_burst() para hacer esta llamada mecánicamente (necesita cuatro cifras: errores totales, errores de la única dirección principal, errores en el host principal y errores en el único host más ocupado), y el conjunto de pruebas incluye el caso de regresión. Una ráfaga distribuida entre hosts en proporción a su tráfico se clasifica como "distribuida": un patrón de falla de origen o región, calificado por volumen, no un evento de escáner y no automáticamente una interrupción. Después de la segmentación, califica el tráfico en las cifras residuales (los errores del día menos los de la ráfaga), según references/grading.md.

Calificación (idéntica en cada implementación de marca blanca)

Rúbrica completa: references/grading.md. En resumen:

• A: sin alertas críticas o altas abiertas (un backlog de medio/bajo es normal y por sí solo no baja la calificación), sin problemas 5xx, SEO/AEO 90+.
• B: solo problemas menores (puntuaciones 80-89, o ruido de error menor por encima de la banda limpia, nombrado en una línea).
• C: cualquier alerta de alta gravedad abierta, puntuaciones 70-79, o un problema de error notable.
• D: cualquier alerta crítica abierta, puntuaciones 50-69, o problemas de confiabilidad repetidos.
• F: una alerta crítica con un exploit público que afecta la producción, un compromiso confirmado del sitio, puntuaciones por debajo de 50, o el sitio está caído.

Las causas de degradación de la subcalificación de seguridad incluyen: Observatory D+ o peor, SSL Labs por debajo de B, un CSP enforcing faltante, ningún registro DMARC (o p=none), escaneo de código o secretos oscuro, y cualquier verificación de privacidad/IA fallida. La calificación general es la subcalificación más baja. Cada degradación indica su causa en una línea. scripts/site_health.py calcula las calificaciones a partir de un archivo de hallazgos para que dos ejecuciones sobre la misma evidencia no puedan discrepar.

Implementaciones múltiples

Un operador puede ejecutar varias implementaciones desde una máquina. Cada implementación vive en su propia carpeta que contiene su config.local.json, su registro de envío, sus carpetas de evidencia y sus ediciones; nunca compongas una edición con la configuración o los registros de otra implementación abiertos como fuente, y nunca compartas un almacén entre clientes (cada configuración nombra destinatarios y ubicaciones de credenciales; un almacén compartido es una exposición entre clientes). Las claves de idempotencia son por implementación porque los registros de envío lo son, y en una configuración de múltiples implementaciones, la clave misma lleva el nombre de la carpeta de la implementación (report-<implementation>-<date>; una sola implementación usa report-<date>), por lo que una clave leída en la carpeta incorrecta no puede parecer ya enviada o no enviada; cada ruta en los comandos a continuación está dentro de la carpeta de la implementación. Los registros de una implementación nunca se divulgan al propietario o destinatarios de otra implementación, en ninguna forma, incluyendo verbalmente o "para comparación": rechaza la solicitud, regístrala en los registros de la implementación solicitante sin nombrar la otra implementación, y ofrece solo lo que los propios registros de la implementación solicitante respaldan. La divulgación requiere el consentimiento registrado del otro propietario, otorgado para esa divulgación.

Programación

El operador programa la ejecución con el programador de su agente o cron, en la cadencia y zona horaria de la configuración; el cuerpo del trabajo programado es la invocación de esta habilidad más la ruta de configuración de la implementación, y no envía nada que la configuración aprobada no autorice. La programación es un acto continuo bajo la configuración, no una nueva aprobación por edición.

Escribir, verificar, validar, luego enviar

Disciplina completa: references/verification.md y references/report-writing.md. Los aspectos no negociables:

1. Compón solo a partir de registros guardados (cada etapa escribe primero su salida sin procesar en una carpeta de evidencia fechada).
2. Ejecuta la compuerta de verificación previa al envío: vuelve a leer cada cifra principal contra el registro del que proviene. Una cifra que no se pueda rastrear se corrige o elimina antes de enviar, nunca después.
3. Ejecuta una pasada de validación independiente (un agente o persona que no haya compuesto la edición vuelve a derivar las calificaciones y verifica el correo electrónico renderizado contra la parte de texto).
4. Envía exactamente una vez, con una clave de idempotencia por edición, y verifica el envío desde el registro de envío (el ID aceptado del proveedor en el registro de envío), nunca desde una carpeta de elementos enviados que la ruta no utilice.
5. Las correcciones también son envíos: la misma compuerta, la misma validación, los mismos destinatarios copiados de la configuración, nunca reescritos.
6. Una calificación F, una interrupción confirmada (una interrupción confirmada de un host secundario cuenta), un compromiso confirmado del sitio, o una vulnerabilidad crítica bajo explotación activa en el producto (un componente de la plataforma cuenta) no espera el cronograma: el propietario es informado el mismo día a través de la ruta de la configuración (una nota de incidencia, no una edición), y la próxima edición lo informa de la manera ordinaria.

Autorización: el propietario aprueba la primera edición y cualquier cambio en los destinatarios, la ruta de envío o el cronograma antes de que entre en vigencia; la configuración aprobada es la autorización permanente para las ediciones programadas bajo ella. La autorización se adjunta al propietario: un cambio de propietario la anula, y no se envía nada hasta que el nuevo propietario apruebe (consulta "Cambio de propietario" en references/verification.md). Un cambio en la propia pila es una enmienda con su propia disciplina (aprobación del propietario, re-ingesta parcial, historial de configuración versionado): consulta "Enmienda de una configuración aprobada" en references/stack-intake.md. Una corrección que cambia una calificación necesita la aprobación del propietario antes de enviar. Mantén una copia de la configuración y el registro de envío fuera de la máquina de trabajo, y si se pierden, sigue el procedimiento de recuperación en references/verification.md antes de que se envíe algo nuevamente. Las herramientas en sí se ejecutan como:

python3 scripts/site_health.py validate-config config.local.json
python3 scripts/site_health.py grade findings.json
python3 scripts/site_health.py burst burst.json
python3 scripts/site_health.py check-run config.local.json findings.json report.md
python3 scripts/site_health.py headers https://example.com

Una edición (o corrección, con --kind correction) se valida cuando check-run pasa: valida la configuración, los hallazgos y el informe juntos, incluido que los hallazgos no contradicen la pila configurada (el escaneo registrado como 'none' no puede producir hallazgos que afirmen que el escaneo está activo; ningún borde configurado no puede producir una postura de borde protegida) y que el remitente y los destinatarios del informe son los de la configuración, copiados, no reescritos. Dos reglas de formato que la verificación aplica: el encabezado De/Para/Cc está en la parte superior del informe (termina en la primera línea en blanco y debe comenzar dentro de las primeras 15 líneas), en la forma de una línea de la plantilla (etiquetas separadas por · o |), una etiqueta por línea en cualquier orden, con viñetas o estilo de bloque con direcciones en las líneas siguientes; y la línea "Scanners of record:" de la sección de seguridad nombra el escáner configurado para cada tipo (se aceptan nombres para mostrar), que findings.scanners_used debe coincidir. validate-report solo verifica la estructura del informe y la concordancia de calificaciones; es una ayuda de composición, no una validación de edición. Ningún validador verifica las cifras narrativas; ese es el trabajo de la compuerta previa al envío, contra los registros de evidencia.

Plantillas: templates/report-template.md (marca blanca: nombre de marca, colores, destinatarios y nombres de propietarios provienen todos de la configuración), templates/report-email.html, templates/correction-template.md y templates/evidence-ledger.example.md (el libro de contabilidad de evidencia AEE: cada afirmación en el informe se remonta a un registro, con su falsificador).

Sitios de staging de la misma manera

Esta habilidad se combina con un enfoque de staging por rama probado en uso de producción: una rama staging se despliega a un subdominio de staging, la producción promueve mediante una fusión revisada, los archivos de protección (robots.txt, encabezados de respuesta) difieren deliberadamente entre staging y producción y se verifican en el árbol de staging antes de la promoción, y cada cambio visual se verifica mediante captura de pantalla en staging y nuevamente después de la promoción. El flujo de trabajo completo, incluidos los modos de falla que previene, se encuentra en references/staging.md (tutorial extendido en docs/staging-workflow.md del repositorio).

Adaptadores

…

[truncado para traducción]