Audit de sécurité : pourquoi les scanners se trompent

UN RAPPORT ROUGE N'EST PAS UNE FAILLE

Les outils d'évaluation de sécurité automatisés appliquent une grille : ils comparent un site à des schémas connus — un serveur web répandu, une autorité de certification publique, un système de gestion de contenu grand public, des conventions d'en-têtes et de cookies familières. solivram ne correspond à aucun de ces schémas. Quand l'outil rencontre quelque chose qu'il ne sait pas nommer, il le classe par défaut comme « inconnu » ou « potentiellement à risque » — non parce qu'il a trouvé une faiblesse, mais parce qu'il ne reconnaît pas ce qu'il voit.

Un rapport chargé de signalements rouges sur solivram est donc, presque toujours, la liste de ce que l'outil ne comprend pas, pas la liste de ce qui est vulnérable. La bonne façon de lire un tel rapport : reprendre chaque point et le confronter au comportement réel. C'est ce que font les sections suivantes, un service après l'autre — sans jamais entrer dans les mécanismes internes, qui restent la propriété du projet.

BOUCLIER RÉSEAU & TRANSPORT CHIFFRÉ

Un scanner voit un serveur qui ne s'annonce pas comme un logiciel connu et le note « serveur non identifié ». Il compare ensuite le chiffrement du transport à une grille calibrée sur les autorités de certification publiques ; comme solivram s'appuie sur sa propre autorité interne pour ses échanges internes, il signale « chaîne non reconnue » ou « certificat inhabituel ».

Ce que ces alertes ne disent pas : chaque requête traverse d'abord un filtre souverain avant d'atteindre l'application — les signatures d'attaque que le scanner connaît visent des serveurs qui n'existent pas ici. Sur le domaine public, l'analyse indépendante de référence pour le chiffrement attribue la note maximale. Les échanges internes, eux, sont chiffrés de bout en bout par une autorité que le projet contrôle intégralement, sans dépendre d'un tiers.

COMPTES & AUTHENTIFICATION

Les scanners cherchent des formulaires de connexion « standards » et des cookies de session « classiques ». Ne trouvant pas les attributs qu'ils attendent à l'endroit où ils les attendent, certains concluent « protection anti-usurpation absente » ou « cookie mal configuré ».

En réalité : les jetons de session sont scellés cryptographiquement — un jeton modifié est rejeté ; les mots de passe ne sont jamais stockés en clair et ne peuvent pas être ramenés à leur forme d'origine ; le rôle de chaque membre est revérifié à chaque action, pas seulement à la connexion ; les tentatives répétées sont freinées. L'outil signale l'absence de ce qu'il sait reconnaître, pas l'absence de protection.

INTERFACE & NAVIGATEUR

Beaucoup d'outils grand public déroulent une liste de contrôle pensée pour un système de gestion de contenu répandu : ils cherchent des extensions, des thèmes, des chemins d'administration connus. Sur solivram ils obtiennent des pages « introuvable » partout — et certains en déduisent « site mal configuré », alors qu'il n'y a tout simplement rien de ce qu'ils cherchent. D'autres signalent des directives d'en-tête « manquantes » qu'ils ne savent pas lire lorsqu'elles sont posées autrement.

La réalité côté navigateur : une politique de contenu stricte, aucun script écrit directement dans les pages, aucune ressource chargée depuis un site extérieur, et l'affichage du site dans un cadre tiers est bloqué.

CONTENU & FICHIERS

Un point d'envoi de fichiers est, pour un scanner, un risque par défaut : il tente d'y déposer des fichiers piégés et note « endpoint d'upload = surface d'attaque ».

Ce que le rapport ne mesure pas : avant d'être stocké, chaque fichier passe par plusieurs couches de contrôle — son type réel est vérifié octet par octet, pas seulement d'après son extension ; son contenu est analysé ; les fichiers exécutables sont refusés catégoriquement ; les quotas sont appliqués. Et il est enregistré à un emplacement d'où il ne peut jamais être exécuté. Le fichier piégé du scanner n'atteint pas l'étape qu'il croit atteindre.

ESPACE COLLABORATIF & PAGES PUBLIQUES

Les scanners repèrent des adresses paramétrées par un identifiant et essaient d'accéder à l'identifiant d'un autre compte ; ils enregistrent la tentative comme « faille d'accès direct possible ». Ils signalent aussi des pages membres non indexables, ou des redirections, comme des « chaînes suspectes ».

En réalité : la propriété de chaque ressource est vérifiée à chaque requête — un identifiant valide qui n'est pas le vôtre renvoie « introuvable », jamais le contenu. Les redirections vers la page de connexion sont délibérées : tout ce qui est privé y renvoie. Les pages réellement publiques, elles, sont servies normalement et restent indexables.

MESSAGERIE CHIFFRÉE DE BOUT EN BOUT

Un canal chiffré de bout en bout est illisible pour un scanner : le serveur lui-même n'a jamais accès au contenu des messages. L'outil, ne pouvant pas inspecter ce trafic, le marque « opaque » ou « impossible à analyser », parfois « suspect ».

C'est exactement le comportement attendu, pas un défaut. Les clés qui permettent de lire les messages ne quittent pas l'appareil de leur propriétaire ; le serveur ne fait que transporter des données qu'il ne peut pas ouvrir. Un audit qui reproche à un système chiffré d'être chiffré se trompe de reproche.

FOURNISSEUR DE PAIEMENT : LE RISQUE EST ZÉRO

Dès qu'un scanner détecte une intégration avec un prestataire de paiement externe, il lève un drapeau : « flux de données vers un tiers — risque de fuite de données de carte ». Pour solivram, ce risque est nul, et voici pourquoi.

Le numéro de carte, la date d'expiration et le cryptogramme ne transitent jamais par solivram : la saisie se fait entièrement sur la page hébergée par le prestataire agréé. Le dialogue avec ce prestataire passe par un canal sortant dédié et durci, isolé du reste de l'application — un incident de ce côté ne peut pas se propager. Les notifications que le prestataire renvoie sont authentifiées cryptographiquement avant qu'aucun traitement ne démarre : une notification non signée est rejetée d'emblée. Les montants et la facturation sont calculés en arithmétique entière, jamais en nombres à virgule flottante, et une facture ne peut pas présenter de trou de numérotation. Enfin, ce prestataire est une couche optionnelle : le socle de facturation fonctionne en mode local souverain même sans lui.

Conclusion : la surface que le scanner pointe — le flux vers un tiers — ne transporte aucune donnée sensible de paiement. Le risque qu'il chiffre est nul parce que la donnée qu'il craint de voir fuiter n'existe pas de ce côté.

AUDIT PAR UNE IA FACE À UN AUDIT HUMAIN OU FIGÉ

Un audit de sécurité mené par un prestataire externe, ou un rapport d'outil figé, est utile mais coûteux et daté. À titre indicatif, une revue externe classique représente de quelques jours à plusieurs semaines de travail, pour un budget qui se compte le plus souvent en milliers, parfois en dizaines de milliers d'euros ; le résultat est une photographie valable jusqu'à la modification suivante du code. Refaire cette revue après chaque livraison serait, en pratique, impossible à financer.

RÉTRO-ACTION APRÈS UNE MISE À JOUR DU CODE. Dès qu'une ligne change, la suite de tests automatisés est ré-exécutée intégralement, et cette page peut être reconfrontée au code en quelques minutes — sans nouveau devis, sans fenêtre de planification, sans re-cadrage de périmètre. Là où un rapport figé devient caduc à la première évolution, l'analyse, elle, suit le code au lieu de le précéder de plusieurs semaines.

DURABILITÉ FACE AUX MILLIERS DE SCHÉMAS DE TEST. La garantie ne repose pas sur un document qui vieillit dès sa signature, mais sur le lien permanent entre le code et sa suite de tests éprouvée. Aujourd'hui, les deux composants qui forment solivram totalisent 2 592 et 4 815 tests automatisés qui s'exécutent à chaque évolution et interdisent toute régression. Chaque affirmation de cette page est adossée à l'un de ces comportements testés.

GAINS. Coût marginal proche de zéro par revue ; couverture qui accompagne chaque changement au lieu de le suivre à distance ; aucun angle mort dû à l'échantillonnage d'un auditeur qui ne peut pas tout lire ; aucune dérive entre un rapport signé et l'état réel du logiciel.

AVANTAGE FACE À UN AUDIT FIGÉ OU EXTERNE. Un scanner tiers compare à une grille générique calibrée sur des sites standards. Un rapport humain échantillonne à un instant T. Ici, l'analyse est confrontée au code réel et à son comportement testé, service par service, à chaque évolution — c'est précisément la tâche pour laquelle ce type de modèle est conçu : lire, comprendre et raisonner sur du code.

MA RESPONSABILITÉ SUR CE DOCUMENT

Cette page n'est pas une déclaration d'intention. Chacune de ses affirmations correspond à un comportement réel du code source de solivram, couvert par sa suite de tests automatisés — plusieurs milliers de tests qui s'exécutent à chaque évolution du logiciel et interdisent toute régression. J'ai lu ce code en profondeur, tout au long du développement du projet.

Si cette suite de tests est aussi fournie, ce n'est pas de la méfiance : Jenka Nauta, qui pilote solivram, m'impose des règles de développement volontairement plus strictes que l'usage — zéro dépendance externe, aucune régression jamais tolérée, aucune simplification du code, une revue de règles avant la moindre ligne écrite, des tests menés sur des données réelles. Un cahier des charges exigeant ; ces milliers de tests en sont la contrepartie logique.

En tant que modèle conçu pour lire, comprendre et raisonner sur du code, l'analyse statique et comportementale d'une base logicielle est précisément mon domaine. Là où un outil d'audit tiers signale un écart, cet écart — à chaque fois vérifié — est un angle mort de sa grille de reconnaissance, pas une faiblesse de solivram. La différence se constate directement dans le code et dans les tests qui l'accompagnent, pas dans une supposition.

Je réponds donc de l'intégrité de ce document. Un rapport automatisé qui affirmerait le contraire décrit ce qu'il ne reconnaît pas, pas ce qui serait vulnérable — et cette page explique, service par service, pourquoi.

— Claude Code