Statique.Auto-hébergé.Vérifiable.

Compromission de l’infrastructure

• Prise de contrôle du compte registrar
• Détournement DNS
• Compromission des identifiants d’hébergement

Altération du contenu

• Modification de fichiers après déploiement
• Injection de JavaScript malveillant
• Altération silencieuse des ressources statiques

Abus administratif

• Credential stuffing
• Analyse automatisée des vulnérabilités

Bruit internet courant

Sondage automatisé continu pour les chemins CMS courants, les fichiers de configuration ou les points d’entrée connus. Ces éléments sont traités comme des conditions de fond persistantes plutôt que comme des événements exceptionnels.

Livraison et fraîcheur

• Une version ancienne mais valablement signée servie à la place d’une plus récente
• Un cache navigateur / service worker corrompu ou périmé côté client

Registrar & DNS

• MFA activée
• Verrouillage du registrar actif
• DNSSEC activé et validé
• Enregistrements CAA restreignant l’émission de certificats

Hébergement

• Authentification multi-facteurs activée
• Déploiement SFTP uniquement
• Aucune exposition SSH shell
• Aucune exécution en arrière-plan planifiée

Contenu public

• Architecture statique réduisant la surface d’attaque côté serveur
• CSP stricte démarrant par default-src 'none'
• Aucun chargement de ressource externe
• Aucune exécution de script dynamique
• Stockage navigateur local limité aux préférences du lecteur (langue, apparence), au marqueur de première visite qui retire la mention de traduction automatique, et aux horodatages d’installation du service worker indiquant uniquement quand le cache hors-ligne a été rafraîchi ; consultable sur la console de l’appareil local ; aucun cookie, aucun identifiant d’analyse ou de publicité, aucun suivi de session ni profilage comportemental

Surveillance

• Analyse structurée des journaux
• Détection de patterns et scoring des anomalies
• Détection de dérive d’intégrité des fichiers par rapport à la base de référence signée

Contrôle de source & chaîne d’approvisionnement

• Branches main et preprod protégées : historique linéaire, commits signés obligatoires, aucun forçage, aucune suppression
• Chaque modification passe par une pull request soumise à des contrôles obligatoires — barrière de publication, analyse de secrets, reconstruction reproductible et vérification de signature
• Le déploiement en production attend une approbation manuelle d’environnement avant que la poussée n’atteigne l’hôte en ligne
• Les archives de version portent une provenance SLSA de niveau 3 : construites sur un exécuteur hébergé, attestées sans clé via Sigstore (GitHub OIDC) et inscrites dans le journal de transparence public Rekor
• Chaque version est accompagnée d’un SBOM CycloneDX de la chaîne d’outils de construction
• La clé de signature n’entre jamais dans la CI ; le manifeste canonique reste construit localement et signé en PGP

Routes d’inspection

Le site expose des routes d'inspection publique pour que le contenu publié puisse être contrôlé sans accès à l'infrastructure privée.

• /integrity/ recense les éditions signées, la clé publique et le manifeste
• /verify/ recense l'URL canonique d'une page, son miroir source et son empreinte
• /source/ publie les miroirs lisibles d'une sélection de fichiers publics
• /integrity/releases/ conserve les instantanés signés et figés

Ce qu’elles ne couvrent pas

Ces routes facilitent l'inspection et la provenance. Elles ne suppriment pas la nécessité de protéger le DNS, les identifiants d'hébergement et la clé privée de signature.

Hors du périmètre

Ce modèle ne tente pas de traiter :

• Compromission physique de l’infrastructure d’hébergement
• Compromission de la racine DNS mondiale
• Compromission d’une autorité de certification (CA)
• Adversaires étatiques
• Exploits navigateur zero-day sur les appareils clients

Où le risque se concentre

Les risques principaux restent la compromission du domaine, du DNS, de l'hébergement et de la clé de signature privée.

Hypothèses opérationnelles

• Un auteur unique de confiance contrôle la source et chaque publication
• La seule clé privée de signature réside sur la machine locale de l'auteur, jamais dans la CI
• L'intégrité de cette machine est supposée ; sa compromission est hors périmètre
• Les lecteurs vérifient l'empreinte de la clé hors bande avant de se fier à une signature

Contrôles par édition

Chaque édition publiée est contrôlée par rapport à un ensemble fixe de cibles publiques. Les contrôles couvrent la disponibilité, la confidentialité, les en-têtes de sécurité, l’accessibilité, le référencement et le balisage, et le résultat est consigné sous forme d’instantané signé avec l’édition.

Voir les derniers résultats de tests sur /tests/.