Transparence totale : voici exactement comment chaque score est calculé, quelles sources nous utilisons, et quelles sont nos limites.
Le scanner collecte les preuves sans aucune intrusion réseau. Aucune tentative d'exploitation, aucun fuzzing, aucun bruteforce. Conformité légale française et européenne assurée.
https://target/ avec timeout 10s, redirect=follow. Capture : status code, headers, server banner.node:tls. Capture : protocole (TLSv1.2/1.3), cipher suite, certificat (issuer, subject, validity, jours restants, SAN).node:dns/promises : NS, MX, TXT (SPF), TXT _dmarc, CAA./.well-known/security.txt (RFC 9116), GET /robots.txt.Méthodologie ouverte : code source de l'algorithme de scoring disponible sur demande à najib@securit-e.com.
Le score global ProofOps va de 0 à 100, où 100 = posture cyber excellente. Il est calculé comme l'inverse du score de risque interne.
| Axe | Poids | Justification (référence) |
|---|---|---|
| Surface (HTTPS joignable, validation de base) | 40 pts | ANSSI Guide d'hygiène 2023 - Mesure 1 |
| Headers HTTP de sécurité | 35 pts | OWASP Secure Headers Project |
| TLS / certificat | 20 pts | NIST SP 800-52 Rev. 2 |
| Email (SPF/DMARC) | 15 pts | RFC 7208 / RFC 7489 |
| Exposition / bannières | 10 pts | ANSSI Mesure 8 (configuration management) |
Le score ProofOps publié est l'inverse de ce score interne : 100 - risk_score. Plus le score est haut, mieux c'est.
Pour la lecture par axe, le score est décomposé en 10 catégories indépendantes, chacune notée sur 100.
| Catégorie | Critère principal | Source |
|---|---|---|
| Site web | HTTPS joignable + headers manquants | OWASP / ANSSI |
| Email (SPF/DMARC/DKIM) | Présence + politique stricte | RFC 7489 |
| DNS | CAA configuré | RFC 8659 (CAA) |
| TLS / certificat | TLSv1.2/1.3 + jours restants | NIST SP 800-52 |
| Headers HTTP | HSTS+CSP+XFO+XCTO+RP+PP | OWASP Secure Headers |
| Cookies | Secure+HttpOnly+SameSite | OWASP Application Security |
| Exposition | Server banner + X-Powered-By masqués | ANSSI Mesure 8 |
| Réputation | Cross-check ransomware.live + CISA KEV | Public threat intel |
| Capacité de preuve | Logs HTTP + DNS + TLS capturables | ISO 27001:2022 A.8.15 |
| Configuration & hygiène | security.txt + robots.txt safe + COOP | RFC 9116 / Mozilla Web Security |
Chaque finding porte un effort_hours et un risk_reduction_pts. Ces valeurs sont issues de notre observation terrain (estimation expert basée sur ~50 audits PME) et de la documentation ANSSI/CIS Controls.
Chaque finding mappé à : NIS2 Article (21.2.x), RGPD Article (32, 33, 34), ISO 27001:2022 (A.x.x), MITRE ATT&CK (Tx).
Le responsable est inféré par catégorie de finding selon une grille déterministe :
| Catégorie finding | Responsable inféré |
|---|---|
| email, dns | Admin domaine / IT (registrar + admin Microsoft 365 ou Google Workspace) |
| tls | Hébergeur ou prestataire infrastructure |
| cookie | Développeur web / Prestataire site |
| header | Développeur web ou DSI |
| exposure | DSI / Prestataire infrastructure |
| config | DSI / Hébergeur |
| tech | DSI |
La priorité (P0/P1/P2) est dérivée directement de la severity : critical→P0, high→P1, medium/low/info→P2.
Le score projeté est calculé comme : min(100, score_actuel + somme(risk_reduction_pts des findings)).
Le Coffre Merkle de SECURIT-E est un arbre Merkle SHA-256 déterministe :
sha256(min(a,b) || max(a,b)) — ordering lexicographique pour éviter chosen-plaintext attacksEndpoint public : POST /api/proofops/merkle avec actions build / verify / hash.
Toutes nos analyses citent leurs sources publiquement. Voici les 28 références principales :
Si une partie de cette méthodologie n'est pas claire ou si vous identifiez une faiblesse, écrivez à najib@securit-e.com. Nous publions et corrigeons.
Voir aussi : page Limites — ce que SECURIT-E ne fait PAS.