electrohire/site-health-security-report

Rapport de Santé & Sécurité du Site

Une compétence d'agent qui produit un rapport gradué quotidien (ou hebdomadaire, ou mensuel) de santé et de sécurité pour un site web, en langage clair, destiné aux propriétaires occupés. Il s'agit de la méthode conçue par ElectroHire et généralisée à toute pile technique, de sorte que les projets de la société d'origine ne font pas partie de la méthode.

Le rapport répond à cinq questions à chaque édition, avec des preuves :

1. Les personnes pouvaient-elles atteindre le site, et à quoi ressemblait réellement le trafic ?
2. Les moteurs de recherche et les robots d'IA peuvent-ils trouver et citer le site (SEO/AEO) ?
3. Le code est-il sûr : dépendances vulnérables, résultats d'analyse de code, secrets divulgués ?
4. Le périmètre tient-il : TLS, en-têtes de sécurité, authentification des e-mails, protection DDoS sur le site et l'API ?
5. Quelles sont les 3 à 5 actions ayant le plus d'impact, chacune avec un propriétaire désigné ?

Chaque édition est notée de A à F, globalement et dans trois sous-catégories (Trafic & fiabilité, SEO/AEO, Sécurité & santé du code), et chaque dégradation indique sa cause en une ligne. Les chiffres ne sont jamais inventés : une source que l'exécution ne peut pas atteindre est signalée comme « non disponible » avec la raison.

Règle zéro : ne jamais exécuter cette compétence sans une prise de connaissance de la pile

Ne supposez pas Cloudflare, GitHub ou tout autre fournisseur. Avant le premier rapport, complétez la prise de connaissance de la pile dans references/stack-intake.md avec l'utilisateur et enregistrez-la en tant que configuration du rapport (modèle : templates/config.example.json ; templates/config.example.yaml est le miroir lisible par l'humain, et le fichier JSON est la configuration de référence lue par les outils). Nommez le fichier sauvegardé config.local.json (ignoré par git), et enregistrez les identifiants uniquement par emplacement (« entrée du coffre X »), jamais par valeur. La prise de connaissance enregistre :

• Couche Edge / CDN / DDoS : Cloudflare, AWS CloudFront (+ AWS WAF et Shield), Azure Front Door (+ Azure WAF), Fastly, Akamai, Sucuri, ou aucun.
• Hébergeur de code : GitHub, GitLab, Bitbucket, Azure DevOps, Gitea/Codeberg, ou autre.
• Hébergement / origine : fournisseur cloud, modèle de région, configuration de préproduction.
• Le nom d'hôte principal par rapport aux hôtes secondaires (API, préproduction, application, espace de travail). Cette distinction détermine les appels d'indisponibilité ; voir la règle de sursaturation ci-dessous.
• Qui reçoit le rapport, selon quel calendrier, via quel canal d'envoi, et qui possède chaque classe de recommandation.

Si un champ de la prise de connaissance est inconnu, demandez. Un rapport construit sur une pile supposée est pire qu'aucun rapport, car ses lacunes ressemblent à des résultats.

La méthode (six étapes de collecte)

Exécutez chaque étape à chaque édition. Une étape qui ne peut pas être exécutée est listée dans le rapport comme non disponible, avec la raison. Ne composez jamais autour d'une étape manquante en silence.

1. Trafic & analytique edge. Requêtes, visiteurs uniques, bande passante, taux de cache, répartition des codes de statut (2xx/3xx/4xx/5xx), principaux chemins, principaux pays, anomalies d'erreur, motifs de scanner/probe. Par fournisseur edge, voir references/adapters-edge.md.
2. SEO / AEO. Une vérification de la préparation à l'IA (par exemple check.aeojs.org) et une vérification SEO (Seobility, en recourant à PageSpeed Insights, en recourant à l'audit sur page en 15 points auto-exécuté dans references/report-writing.md). Chaque score porte un identifiant de scan et un horodatage de cette exécution.
3. Sécurité de l'hébergeur de code. Alertes de dépendances ouvertes par sévérité, alertes d'analyse de code par sévérité, alertes de détection de secrets, et activité de commit et CI/déploiement de la dernière période. Lorsque le site fonctionne sur une plateforme applicative (WordPress core et plugins, un CMS), les vulnérabilités connues de ses composants installés issues de la source nommée de la plateforme sont également comptées ici (résultats security.platform) : sur une telle pile, la plateforme est l'endroit où vit le code exploitable. Par hébergeur de code, y compris quoi faire lorsque l'hébergeur n'a pas d'analyse native, voir references/adapters-codehost.md et references/scanning-fallbacks.md.
4. Éléments critiques permanents. Tout élément nommé et daté que le propriétaire a signalé comme suivi jusqu'à sa clôture (une CVE en production, un certificat qui expire, une migration). Supprimé uniquement lorsque vérifié comme clos.
5. Analyses de sécurité du site web (publiques, sans compte requis). Note Mozilla Observatory (observatory.mozilla.org), note TLS SSL Labs et date d'expiration du certificat (ssllabs.com/ssltest), les six en-têtes de sécurité (une Content-Security-Policy qui s'applique compte ; une policy en mode rapport uniquement ne compte pas), la redirection HTTP vers HTTPS, et l'authentification des e-mails (SPF, politique DMARC, MX — lus à partir des enregistrements DNS TXT/MX du domaine avec n'importe quel outil de requête DNS). Ces vérifications notent l'hôte principal ; les en-têtes et TLS d'un hôte secondaire sont rapportés dans le récit, non notés. La posture DDoS pour le site et l'API est couverte dans references/ddos.md.
6. Vérifications ponctuelles de conformité à l'IA et à la vie privée (vérifiables publiquement uniquement). La politique de confidentialité nomme la personne morale correcte en tant que responsable du traitement, couvre les données vocales/de chat IA le cas échéant, nomme les processeurs de paiement ; les assistants IA indiquent qu'ils sont une IA lors de la première interaction ; le consentement aux cookies est visible ; une voie de demande de données est publiée. Signalez chaque élément comme réussi, échoué ou non testable, à partir du seul texte de la page. Lorsque la fonctionnalité concernée par une vérification n'existe pas (pas d'assistant IA sur le site, par exemple), la vérification est non testable avec cette raison, jamais un succès, et n'est pas comptée comme un échec.

Chaque étape écrit ses résultats dans le fichier de résultats de l'édition ; les noms de champs, types et unités exacts sont spécifiés dans references/findings-schema.md. Le fichier de résultats est le sous-ensemble de notation ; les chiffres du récit du rapport (totaux, principaux chemins, identifiants de scan) proviennent des enregistrements de preuves datés des mêmes étapes, listés dans le registre des preuves.

La règle de sursaturation (apprise en production)

Un pic d'erreurs 5xx n'est pas automatiquement une indisponibilité. Avant tout appel d'indisponibilité, segmentez le pic par nom d'hôte et par adresse client :

• Si les erreurs sont concentrées sur un hôte non principal (un hôte API secondaire, un hôte de préproduction) ou proviennent principalement d'une seule adresse client, il s'agit d'un événement de scanner ou de probe contre cet hôte, pas d'une indisponibilité du site, quelle que soit l'apparence du total au niveau de la zone.
• Notez et rédigez ce que montre la segmentation. scripts/site_health.py fournit classify_error_burst() pour prendre cette décision de manière mécanique (elle nécessite quatre chiffres : erreurs totales, erreurs provenant de la première adresse unique, erreurs sur l'hôte principal, et erreurs sur l'hôte le plus sollicité), et la suite de tests comporte le cas de régression. Un pic réparti entre les hôtes en proportion de leur trafic est classé comme « distribué » : un modèle de défaillance d'origine ou de région, noté sur le volume, pas un événement de scanner et pas automatiquement une indisponibilité. Après la segmentation, notez le trafic sur les chiffres résiduels (les erreurs du jour moins celles du pic), selon references/grading.md.

Notation (identique dans chaque déploiement en marque blanche)

Rubrique complète : references/grading.md. En résumé :

• A : aucune alerte critique ou haute ouverte (un backlog moyen/faible est normal et n'abaisse pas à lui seul la note), aucun problème 5xx, SEO/AEO 90+.
• B : problèmes mineurs uniquement (scores 80-89, ou bruit d'erreur mineur au-dessus de la bande propre, nommé en une ligne).
• C : toute alerte de sévérité haute ouverte, scores 70-79, ou un problème d'erreur notable.
• D : toute alerte critique ouverte, scores 50-69, ou problèmes de fiabilité répétés.
• F : une alerte critique avec un exploit public affectant la production, une compromission confirmée du site, scores inférieurs à 50, ou le site est hors service.

Les causes de dégradation de la sous-note de sécurité incluent : Observatory D+ ou pire, SSL Labs en dessous de B, une CSP qui s'applique manquante, aucun enregistrement DMARC (ou p=none), analyse de code ou de secrets absente, et tout échec de vérification de la vie privée/IA. La note globale est la sous-note la plus basse. Chaque dégradation indique sa cause en une ligne. scripts/site_health.py calcule les notes à partir d'un fichier de résultats afin que deux exécutions sur les mêmes preuves ne puissent pas être en désaccord.

Déploiements multiples

Un opérateur peut gérer plusieurs déploiements à partir d'une seule machine. Chaque déploiement vit dans son propre dossier contenant son config.local.json, son journal d'envoi, ses dossiers de preuves et ses éditions ; ne composez jamais une édition avec la configuration ou les enregistrements d'un autre déploiement comme source, et ne partagez jamais un magasin de données entre clients (chaque configuration nomme les destinataires et les emplacements des identifiants — un magasin partagé est une exposition entre clients). Les clés d'idempotence sont propres à chaque déploiement car les journaux d'envoi le sont, et dans une configuration multi-déploiement, la clé elle-même porte le nom du dossier du déploiement (report-<deployment>-<date> ; un déploiement unique utilise report-<date>), de sorte qu'une clé lue dans le mauvais dossier ne peut pas sembler déjà envoyée ou non envoyée ; chaque chemin dans les commandes ci-dessous se trouve à l'intérieur du dossier du déploiement. Les enregistrements d'un déploiement ne sont jamais divulgués au propriétaire ou aux destinataires d'un autre déploiement, sous quelque forme que ce soit, y compris verbalement ou « pour comparaison » : refusez la demande, enregistrez-la dans les enregistrements du déploiement demandeur sans nommer l'autre déploiement, et offrez uniquement ce que les propres enregistrements du déploiement demandeur soutiennent. La divulgation nécessite le consentement enregistré de l'autre propriétaire, donné pour cette divulgation.

Planification

L'opérateur planifie l'exécution avec le planificateur de son agent ou cron, à la cadence et dans le fuseau horaire de la configuration ; le corps de la tâche planifiée est l'invocation de cette compétence plus le chemin de la configuration du déploiement, et elle n'envoie rien que la configuration approuvée n'autorise pas. La planification est un acte permanent relevant de la configuration, pas une nouvelle approbation par édition.

Écrire, vérifier, valider, puis envoyer

Discipline complète : references/verification.md et references/report-writing.md. Les incontournables :

1. Composez à partir des enregistrements sauvegardés uniquement (chaque étape écrit d'abord sa sortie brute dans un dossier de preuves daté).
2. Exécutez la porte de vérification pré-envoi : relisez chaque chiffre principal par rapport à l'enregistrement dont il provient. Un chiffre qui ne peut pas être retracé est corrigé ou supprimé avant l'envoi, jamais après.
3. Exécutez une passe de validation indépendante (un agent ou une personne qui n'a pas composé l'édition recalcule les notes et vérifie l'e-mail rendu par rapport à la partie texte).
4. Envoyez exactement une fois, avec une clé d'idempotence par édition, et vérifiez l'envoi à partir de l'enregistrement d'envoi (l'identifiant accepté du fournisseur dans le journal d'envoi), jamais à partir d'un dossier d'éléments envoyés que la route n'utilise pas.
5. Les corrections sont aussi des envois : même porte, même validation, mêmes destinataires copiés depuis la configuration, jamais retapés.
6. Une note F, une indisponibilité confirmée (une indisponibilité confirmée d'un hôte secondaire compte), une compromission confirmée du site, ou une vulnérabilité critique sous exploitation active dans le produit (un composant de plateforme compte) n'attend pas le calendrier : le propriétaire est informé le jour même via la route de la configuration (une note d'incident, pas une édition), et l'édition suivante le rapporte de manière ordinaire.

Autorisation : le propriétaire approuve la première édition et tout changement de destinataires, de route d'envoi ou de calendrier avant qu'il ne prenne effet ; la configuration approuvée est l'autorisation permanente pour les éditions planifiées en vertu de celle-ci. L'autorisation est attachée au propriétaire : un changement de propriétaire l'annule, et rien n'est envoyé tant que le nouveau propriétaire n'a pas approuvé (voir « Changement de propriétaire » dans references/verification.md). Un changement de la pile elle-même est un amendement avec sa propre discipline (approbation du propriétaire, nouvelle prise de connaissance partielle, historique de configuration versionné) : voir « Amendement d'une configuration approuvée » dans references/stack-intake.md. Une correction qui modifie une note nécessite l'approbation du propriétaire avant l'envoi. Conservez une copie de la configuration et du journal d'envoi hors de la machine de travail, et s'ils sont perdus, suivez la procédure de récupération dans references/verification.md avant tout nouvel envoi. Les outils eux-mêmes sont exécutés comme suit :

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

Une édition (ou correction, avec --kind correction) est validée lorsque check-run réussit : elle valide la configuration, les résultats et le rapport ensemble, y compris que les résultats ne contredisent pas la pile configurée (une analyse enregistrée comme « aucune » ne peut pas produire de résultats prétendant que l'analyse est active ; aucun edge configuré ne peut pas produire une posture edge protégée) et que l'expéditeur et les destinataires du rapport sont ceux de la configuration, copiés, non retapés. Deux règles de format que la vérification applique : l'en-tête De/À/Cc se trouve en haut du rapport (il se termine à la première ligne vide et doit commencer dans les 15 premières lignes), sous la forme à une ligne du modèle (étiquettes séparées par · ou |), une étiquette par ligne dans n'importe quel ordre, en liste à puces, ou en style bloc avec les adresses sur les lignes suivantes ; et la ligne « Scanners of record : » de la section sécurité nomme le scanner configuré pour chaque type (les noms d'affichage sont acceptés), ce que findings.scanners_used doit correspondre. validate-report seul vérifie uniquement la structure du rapport et la cohérence de la note ; c'est un outil de composition, pas une validation d'édition. Aucun validateur ne vérifie les chiffres du récit ; c'est le travail de la porte pré-envoi, par rapport aux enregistrements de preuves.

Modèles : templates/report-template.md (marque blanche : nom de la marque, couleurs, destinataires et noms des propriétaires proviennent tous de la configuration), templates/report-email.html, templates/correction-template.md, et templates/evidence-ledger.example.md (le registre de preuves AEE : chaque affirmation dans le rapport remonte à un enregistrement, avec son falsificateur).

Sites de préproduction de la même manière

Cette compétence s'associe à une approche de préproduction par branche éprouvée en production : une branche staging déploie vers un sous-domaine de préproduction, la production promeut par une fusion révisée, les fichiers de garde (robots.txt, en-têtes de réponse) diffèrent délibérément entre la préproduction et la production et sont vérifiés dans l'arborescence de préproduction avant la promotion, et chaque modification visuelle est vérifiée par capture d'écran sur la préproduction et à nouveau après la promotion. Le flux de travail complet, y compris les modes de défaillance qu'il prévient, est references/staging.md (procédure pas à pas étendue dans docs/staging-workflow.md du dépôt).

Adaptateurs

…

[tronqué pour la traduction]