POSTURE DE SÉCURITÉ

Un outil de sécurité qui surestime sa protection est pire qu’un outil qui admet une lacune.

WinSight distingue le mode souhaité que vous avez enregistré de l’état d’exécution effectif qu’il peut réellement prouver auprès du moteur de filtrage actif. S’il ne peut pas vérifier l’application exactement, il rapporte Degraded, jamais Active.

Aucune télémétrie, aucune analytique, aucun compte

La seule connexion sortante est une recherche d’empreinte VirusTotal explicite et lancée par vous : une empreinte, jamais le contenu des fichiers. VirusTotal reste inactif tant que vous ne fournissez pas votre propre clé, et --no-network le refuse dans tous les cas.

La frontière privilégiée est un canal IPC authentifié, pas l’interface

Le tableau de bord est un client IPC non privilégié et ne peut pas modifier la politique de lui-même. Un administrateur non élevé est refusé exactement comme un utilisateur standard.

L’application est facultative et démarre en audit seul

Rien n’est filtré tant qu’un opérateur élevé ne l’a pas armé, et il n’existe aucun chemin en ligne de commande pour armer. C’est la propriété de sécurité, pas une fonctionnalité manquante. Les alias de mutation directe de WFP sont désactivés.

Intention souhaitée et état effectif ne sont jamais confondus

WinSight ne revendique un filtrage qu’à partir de l’état Active effectif et prouvé du service, revérifié à chaque lecture d’état plutôt que supposé à partir de ce qui a été enregistré.

L’application survit aux redémarrages

Grâce à la persistance du service au démarrage, et l’état est revérifié auprès du moteur de filtrage actif à chaque lecture.

Installation durcie contre les chemins non fiables

Le service refuse de s’installer depuis tout chemin qu’un principal non privilégié peut écrire, et revérifie l’identité NTFS 128 bits du fichier avant usage pour qu’il ne puisse pas être remplacé entre-temps.

Aucun pilote noyau

L’interception par pilote est reportée plutôt que faite à moitié, car un pilote de production exige une signature et un programme de sûreté distinct.

Ce contre quoi WinSight protège, et ce contre quoi il ne protège pas

Dans le périmètre

  • La visibilité sur la persistance, les connexions sortantes, le DNS, l’usage caméra/micro, les surfaces de détournement et les signatures.
  • Le blocage du trafic sortant d’une application choisie au niveau de la plateforme de filtrage Windows, une fois que vous l’avez armé.
  • Les alertes sur les nouveaux éléments de démarrage et sur l’activité de rançongiciel détectée par fichiers leurres.
  • Agir seulement quand vous le choisissez : bloquer un nouvel élément de démarrage dans une quarantaine restaurable, ou suspendre ou arrêter un processus avec --confirm. Chaque action est revalidée d’abord et consignée dans un journal.
  • Le rapport indiquant si les protections propres à Windows sont réellement actives, dont l’accès contrôlé aux dossiers de Microsoft Defender et l’inventaire antivirus indépendant de l’éditeur, lus sans élévation et jamais modifiés.

Hors périmètre

  • Ce n’est ni un antivirus ni un EDR, et il ne garantit pas la détection des rootkits noyau, des implants en mémoire seule ni de toutes les techniques de persistance.
  • Le blocage de persistance en temps réel et l’interception de rançongiciels (qui exigeraient un pilote noyau signé, non fourni).
  • Modifier un réglage Windows ou Defender à votre place. WinSight rapporte la posture et renvoie vers le réglage Windows.
  • Il complète Microsoft Defender et les sauvegardes ; il ne les remplace pas.

Savoir si le bloqueur de rançongiciels de Windows applique réellement sa protection est une vérification à part entière : comment WinSight lit cette posture →

Le modèle de menace complet, avec les frontières de confiance et les exclusions explicites : THREAT_MODEL.md →

Deux politiques de confidentialité, énoncées séparément

L’application WinSight

Aucune télémétrie, aucune analytique, aucun compte. Les résultats d’analyse restent sur votre appareil. La seule connexion sortante est la recherche d’empreinte VirusTotal, facultative et lancée par vous, désactivée par défaut, nécessitant votre propre clé d’API, envoyant une empreinte SHA-256 et jamais le contenu des fichiers. Les mises à jour sont manuelles : vous téléchargez une nouvelle version et la vérifiez vous-même.

Ce site web

Ce site vitrine utilise Vercel Web Analytics (sans cookie, uniquement agrégé) pour compter les pages vues et des événements de conversion anonymes comme les clics de téléchargement. Aucun pixel publicitaire, aucun suivi inter-sites, aucune empreinte numérique, aucun rejeu de session, et aucune tentative de vous identifier. Le site ne collecte jamais de chemins d’exécutables, de noms de processus ni quoi que ce soit venant de l’application WinSight. Ce sont deux systèmes entièrement distincts : l’analytique de ce site ne dit rien de ce qu’une analyse a trouvé sur votre machine.

Qualifié par des preuves, pas par des affirmations

Le code produit de la v0.14.0 a été qualifié sur des machines virtuelles Windows 11 x64 natives après l’audit de sécurité de septembre 2026, avec une machine de contrôle isolée. Le banc de test vérifie sa propre provenance, et chaque résultat est lié aux empreintes exactes des artefacts.

32

portes, 0 échec

Campagne x64 complète, dont le cycle de vie et la mise à niveau de l’installateur, Guardian, les verbes de réponse, Cloud Files, le cycle de vie ETW et le nettoyage

35

vérifications, 0 échec

Transitions WFP/SCM, restauration, connectivité et portée par application

13

vérifications, 0 échec

Confiance des chemins, ACL et scénarios TOCTOU hostiles

7

vérifications, 0 échec

IPC local avec jetons élevés et restreints

7 + 3

vérifications, 0 échec

Ouverture de session réseau distante et observateur indépendant

Les candidats qualifiés étaient des builds locaux non signés du code produit de la v0.14.0 ; les binaires publiés de la v0.14.0 sont le build CI de ce code et n’ont pas eux-mêmes tourné dans la VM. La compilation, les tests, les paquets et l’installateur Arm64 réussissent en CI native, mais l’exécution privilégiée Arm64 et l’exécution x64 sur Arm64 restent à qualifier sur matériel adapté. La revue humaine indépendante de la présentation en anglais, français et espagnol reste ouverte.

Sources : docs/validation/2026-09-26-x64-qualification-fe953fe.md · docs/PRODUCTION_READINESS.md · docs/AUDIT.md, vérifié le 2026-09-26

Vérification des versions et signature de code

  • Chaque version est livrée avec une empreinte SHA-256 par fichier, une SBOM au format SPDX et une attestation GitHub de provenance de compilation, vérifiable avec gh attestation verify.
  • Les binaires publiés ne sont pas encore signés par Authenticode : le projet ne dispose d’aucun certificat de signature de code, donc Windows avertit au premier lancement. La compilation des versions comporte une étape de signature, qui n’a jamais tourné de bout en bout : il n’y a aucun certificat avec lequel signer.
  • Le script de compilation vérifie à la fois l’empreinte SHA-256 officielle et la signature Authenticode du compilateur Inno Setup qu’il épingle, avant de l’utiliser.

Signaler une vulnérabilité

Les problèmes de sécurité passent par le signalement privé de vulnérabilité de GitHub, jamais par les tickets publics.

Signaler en privé →

Lire les documents complets

Modèle de menace, frontières de confiance, ce qui est explicitement hors périmètre, et chaque enregistrement de validation.

Modèle de menace →Enregistrements de validation →