electrohire/site-health-security-report

Relatório de Saúde e Segurança do Site

Uma skill de agente que produz um relatório graduado diário (ou semanal, ou mensal) de saúde e segurança para um site, em linguagem clara, para proprietários ocupados. É o método projetado pela ElectroHire e generalizado para qualquer stack, de modo que os projetos da empresa originadora não fazem parte do método.

O relatório responde a cinco perguntas a cada edição, com evidências:

1. As pessoas conseguiam acessar o site e como estava o tráfego realmente?
2. Os mecanismos de busca e rastreadores de IA conseguem encontrar e citar o site (SEO/AEO)?
3. O código está seguro: dependências vulneráveis, resultados de varredura de código, segredos vazados?
4. O perímetro está seguro: TLS, cabeçalhos de segurança, autenticação de e-mail, proteção DDoS no site e na API?
5. Quais são as 3 a 5 ações de maior impacto, cada uma com um proprietário nomeado?

Cada edição recebe uma nota de A a F, geral e em três subnotas (Tráfego e confiabilidade, SEO/AEO, Segurança e saúde do código), e cada rebaixamento nomeia sua causa em uma linha. Os números nunca são inventados: uma fonte que a execução não consegue acessar é relatada como "não disponível" com o motivo.

Regra zero: nunca execute esta skill sem uma coleta de informações do stack

Não assuma Cloudflare, GitHub ou qualquer outro fornecedor. Antes do primeiro relatório, complete a coleta de informações do stack em references/stack-intake.md com o usuário e salve-o como a configuração do relatório (modelo: templates/config.example.json; templates/config.example.yaml é o espelho legível por humanos, e o arquivo JSON é a configuração de registro que as ferramentas leem). Nomeie o arquivo salvo como config.local.json (ignorado pelo git) e registre as credenciais apenas por localização ("entrada do cofre X"), nunca pelo valor. A coleta registra:

• Camada de Edge / CDN / DDoS: Cloudflare, AWS CloudFront (+ AWS WAF e Shield), Azure Front Door (+ Azure WAF), Fastly, Akamai, Sucuri, ou nenhum.
• Repositório de código: GitHub, GitLab, Bitbucket, Azure DevOps, Gitea/Codeberg, ou outro.
• Hospedagem / origem: provedor de nuvem, modelo de região, configuração de staging.
• O nome de host principal versus hosts secundários (API, staging, app, workspace). Essa distinção decide as chamadas de interrupção; veja a regra de pico abaixo.
• Quem recebe o relatório, em qual cronograma, por qual rota de envio e quem é o proprietário de cada classe de recomendação.

Se algum campo da coleta for desconhecido, pergunte. Um relatório construído com base em um stack assumido é pior do que nenhum relatório, porque suas lacunas parecem descobertas.

O método (seis etapas de coleta)

Execute cada etapa, a cada edição. Uma etapa que não pode ser executada é listada no relatório como não disponível, com o motivo. Nunca componha em torno de uma etapa ausente silenciosamente.

1. Tráfego e análise de edge. Solicitações, visitantes únicos, largura de banda, taxa de cache, mix de códigos de status (2xx/3xx/4xx/5xx), principais caminhos, principais países, anomalias de erro, padrões de scanner/probe. Para cada provedor de edge, consulte references/adapters-edge.md.
2. SEO / AEO. Uma verificação de prontidão para IA (por exemplo, check.aeojs.org) e uma verificação de SEO (Seobility, recorrendo ao PageSpeed Insights, recorrendo à auditoria de 15 pontos na página em references/report-writing.md). Cada pontuação carrega um identificador de varredura e um timestamp desta execução.
3. Segurança do repositório de código. Alertas de dependência abertos por gravidade, alertas de varredura de código por gravidade, alertas de varredura de segredos e a atividade de commit e CI/deploy do último período. Onde o site é executado em uma plataforma de aplicação (WordPress core e plugins, um CMS), as vulnerabilidades conhecidas de seus componentes instalados da fonte nomeada da plataforma também são contadas aqui (descobertas security.platform): em tal stack, a plataforma é onde o código explorável reside. Para cada repositório de código, incluindo o que fazer quando o repositório não possui varredura nativa, consulte references/adapters-codehost.md e references/scanning-fallbacks.md.
4. Itens críticos pendentes. Qualquer item nomeado e datado que o proprietário sinalizou como rastreado até ser fechado (um CVE em produção, um certificado expirando, uma migração). Removido apenas quando verificado como fechado.
5. Varreduras de segurança do site (públicas, sem necessidade de conta). Nota do Mozilla Observatory (observatory.mozilla.org), nota TLS do SSL Labs e expiração do certificado (ssllabs.com/ssltest), os seis cabeçalhos de segurança (uma Content-Security-Policy impositiva conta; uma apenas de relatório não conta), redirecionamento HTTP para HTTPS e autenticação de e-mail (SPF, política DMARC, MX — lidos dos registros DNS TXT/MX do domínio com qualquer ferramenta de consulta DNS). Essas verificações avaliam o host principal; os cabeçalhos e TLS de um host secundário são relatados na narrativa, não avaliados. A postura DDoS para o site e a API é coberta em references/ddos.md.
6. Verificações pontuais de conformidade de privacidade e IA (apenas verificáveis publicamente). A política de privacidade nomeia a entidade legal correta como controladora, cobre dados de voz/chat de IA quando aplicável, nomeia processadores de pagamento; assistentes de IA revelam que são IA na primeira interação; o consentimento de cookies é visível; uma rota de solicitação de dados é publicada. Relate cada um como aprovado, reprovado ou não testável, a partir apenas do texto da própria página. Onde o recurso ao qual uma verificação diz respeito não existe (nenhum assistente de IA no site, por exemplo), a verificação é não testável com esse motivo, nunca uma aprovação, e não é contada como uma reprovação.

Cada etapa escreve suas descobertas no arquivo de descobertas da edição; os nomes de campo, tipos e unidades exatos são especificados em references/findings-schema.md. O arquivo de descobertas é o subconjunto de avaliação; os números narrativos do relatório (totais, principais caminhos, identificadores de varredura) vêm dos registros de evidência datados das mesmas etapas, listados no registro de evidências.

A regra do pico (aprendida em produção)

Um pico de erros 5xx não é automaticamente uma interrupção. Antes de qualquer chamada de interrupção, segmente o pico por nome de host e por endereço de cliente:

• Se os erros estão concentrados em um host não principal (um host secundário de API, um host de staging) ou vêm principalmente de um endereço de cliente, é um evento de scanner ou probe contra esse host, não uma interrupção do site, por maior que seja o total geral da zona.
• Avalie e escreva o que a segmentação mostra. scripts/site_health.py inclui classify_error_burst() para fazer essa chamada mecanicamente (ela precisa de quatro números: erros totais, erros do único endereço principal, erros no host principal e erros no único host mais movimentado), e o conjunto de testes carrega o caso de regressão. Um pico espalhado pelos hosts na proporção de seu tráfego é classificado como "distribuído": um padrão de falha de origem ou região, avaliado por volume, não um evento de scanner e não automaticamente uma interrupção. Após a segmentação, avalie o tráfego com base nos números residuais (os erros do dia menos o pico), de acordo com references/grading.md.

Avaliação (idêntica em toda implantação de marca branca)

Rubrica completa: references/grading.md. Em resumo:

• A: nenhum alerta crítico ou alto aberto (um backlog médio/baixo é normal e não reduz a nota por si só), nenhum problema 5xx, SEO/AEO 90+.
• B: apenas problemas menores (pontuações 80-89, ou ruído de erro menor acima da faixa limpa, nomeado em uma linha).
• C: qualquer alerta de alta gravidade aberto, pontuações 70-79, ou um problema de erro perceptível.
• D: qualquer alerta crítico aberto, pontuações 50-69, ou problemas de confiabilidade repetidos.
• F: um alerta crítico com um exploit público afetando a produção, uma confirmação de comprometimento do site, pontuações abaixo de 50, ou o site está fora do ar.

Causas de rebaixamento da subnota de segurança incluem: Observatory D+ ou pior, SSL Labs abaixo de B, CSP impositiva ausente, nenhum registro DMARC (ou p=none), varredura de código ou segredos escura, e qualquer verificação de privacidade/IA falhando. A nota geral é a subnota mais baixa. Cada rebaixamento nomeia sua causa em uma linha. scripts/site_health.py calcula as notas a partir de um arquivo de descobertas, para que duas execuções com a mesma evidência não possam discordar.

Múltiplas implantações

Um operador pode executar várias implantações a partir de uma máquina. Cada implantação vive em sua própria pasta, contendo seu config.local.json, seu registro de envio, suas pastas de evidência e suas edições; nunca componha uma edição com a configuração ou registros de outra implantação como fonte, e nunca compartilhe um armazenamento entre clientes (cada configuração nomeia destinatários e locais de credenciais — um armazenamento compartilhado é uma exposição entre clientes). As chaves de idempotência são por implantação porque os registros de envio também são, e em uma configuração de múltiplas implantações, a própria chave carrega o nome da pasta da implantação (report-<deployment>-<date>; uma única implantação usa report-<date>), de modo que uma chave lida na pasta errada não pode parecer já enviada ou não enviada; cada caminho nos comandos abaixo está dentro da pasta da implantação. Os registros de uma implantação nunca são divulgados ao proprietário ou destinatários de outra implantação, em qualquer forma, incluindo verbalmente ou "para comparação": recuse a solicitação, registre-a nos registros da implantação solicitante sem nomear a outra implantação e ofereça apenas o que os próprios registros da implantação solicitante suportam. A divulgação requer o consentimento registrado do outro proprietário, dado para essa divulgação.

Agendamento

O operador agenda a execução com o agendador de seu agente ou cron, na cadência e fuso horário da configuração; o corpo do trabalho agendado é a invocação desta skill mais o caminho da configuração da implantação, e ele não envia nada que a configuração aprovada não autorize. O agendamento é um ato contínuo sob a configuração, não uma nova aprovação por edição.

Escrever, verificar, validar, depois enviar

Disciplina completa: references/verification.md e references/report-writing.md. Os itens inegociáveis:

1. Compor apenas a partir de registros salvos (cada etapa escreve sua saída bruta em uma pasta de evidência datada primeiro).
2. Executar a verificação de pré-envio: releia cada figura principal em relação ao registro de onde veio. Uma figura que não pode ser rastreada é corrigida ou descartada antes do envio, nunca depois.
3. Executar uma passagem de validação independente (um agente ou pessoa que não compôs a edição rederiva as notas e verifica o e-mail renderizado em relação à parte do texto).
4. Enviar exatamente uma vez, com uma chave de idempotência por edição, e verificar o envio a partir do registro de envio (o ID aceito pelo provedor no registro de envio), nunca de uma pasta de itens enviados que a rota não usa.
5. Correções também são envios: mesma verificação, mesma validação, mesmos destinatários copiados da configuração, nunca redigitados.
6. Uma nota F, uma interrupção confirmada (uma interrupção confirmada de host secundário conta), um comprometimento confirmado do site ou uma vulnerabilidade crítica sob exploração ativa no produto (um componente da plataforma conta) não espera o cronograma: o proprietário é informado no mesmo dia através da rota da configuração (uma nota de incidente, não uma edição), e a próxima edição relata isso da maneira comum.

Autorização: o proprietário aprova a primeira edição e qualquer alteração nos destinatários, rota de envio ou cronograma antes que entre em vigor; a configuração aprovada é a autorização contínua para edições agendadas sob ela. A autorização está vinculada ao proprietário: uma mudança de proprietário a anula, e nada é enviado até que o novo proprietário aprove (consulte "Mudança de proprietário" em references/verification.md). Uma alteração no próprio stack é uma emenda com sua própria disciplina (aprovação do proprietário, coleta parcial, histórico de configuração versionado): consulte "Emendando uma configuração aprovada" em references/stack-intake.md. Uma correção que altera uma nota precisa da aprovação do proprietário antes do envio. Mantenha uma cópia da configuração e do registro de envio fora da máquina de trabalho e, se forem perdidos, siga o procedimento de recuperação em references/verification.md antes que qualquer coisa seja enviada novamente. As próprias ferramentas são executadas 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

Uma edição (ou correção, com --kind correction) é validada quando check-run passa: ele valida a configuração, as descobertas e o relatório juntos, incluindo que as descobertas não contradizem o stack configurado (varredura registrada como 'nenhuma' não pode produzir descobertas afirmando que a varredura está ativa; nenhuma edge configurada não pode produzir uma postura de edge protegida) e que o remetente e os destinatários do relatório são os da configuração, copiados, não redigitados. Duas regras de formato que a verificação impõe: o cabeçalho De/Para/Cc fica no topo do relatório (termina na primeira linha em branco e deve começar dentro das primeiras 15 linhas), no formato de uma linha do modelo (rótulos separados por · ou |), um rótulo por linha em qualquer ordem, com marcadores ou estilo de bloco com endereços nas linhas seguintes; e a linha "Scanners of record:" da seção de segurança nomeia o scanner configurado para cada tipo (nomes de exibição são aceitos), que findings.scanners_used deve corresponder. validate-report sozinho verifica apenas a estrutura do relatório e a concordância das notas; é um auxiliar de composição, não uma validação de edição. Nenhum validador verifica números narrativos; essa é a função da verificação de pré-envio, em relação aos registros de evidência.

Modelos: templates/report-template.md (marca branca: nome da marca, cores, destinatários e nomes de proprietários vêm da configuração), templates/report-email.html, templates/correction-template.md e templates/evidence-ledger.example.md (o registro de evidências AEE: cada afirmação no relatório remonta a um registro, com seu falsificador).

Sites de staging da mesma forma

Esta skill é emparelhada com uma abordagem de branch-staging comprovada em uso de produção: um branch staging implanta em um subdomínio de staging, a produção promove por meio de um merge revisado, os arquivos de guarda (robots.txt, cabeçalhos de resposta) diferem deliberadamente entre staging e produção e são verificados na árvore staged antes da promoção, e cada alteração visual é verificada por captura de tela no staging e novamente após a promoção. O fluxo de trabalho completo, incluindo os modos de falha que ele evita, está em references/staging.md (passo a passo estendido no docs/staging-workflow.md do repositório).

Adaptadores

...