Utilitaire de bureau pour surveiller l'intégrité et la chaîne de contrôle du SDK sous Windows (vérifier les hachages, Authenticode, SBOM)

Situation initiale
L'équipe de développement Windows utilise un ensemble interne de SDK et d'utilitaires CLI, distribués au format ZIP/MSI et mis à jour fréquemment. Actuellement, les contrôles d'intégrité sont effectués manuellement à l'aide de notes Wiki, c'est pourquoi les binaires non signés ou modifiés, ainsi que les versions « perdues » sans contenu transparent, se retrouvent périodiquement dans la build.

Environnement technique et domaine
- Windows 10/11 x64
- .NET 8 Desktop (WPF ou WinUI 3) ou C++/Qt - au choix, mais le résultat doit être un programme de bureau prêt à l'emploi avec un programme d'installation
- Dépôts/artefacts : dossier local, partage réseau (UNC), ainsi que ZIP/MSI téléchargé
- Validations : SHA-256/SHA-512, Authenticode (WinVerifyTrust), validation de base de la chaîne de certificats, collection SBOM (CycloneDX ou SPDX) basée sur le contenu du package

Ce qu'il faut faire (plusieurs étapes)
1) Analyse du format et des règles de livraison
- L'entrée comprend 10 à 15 packages standards (ZIP/MSI) et un exemple des règles actuelles sous forme de tableau (fichiers attendus, masques, versions, exigences de signature)
- Il est nécessaire de clarifier et de corriger le schéma de règles dans la configuration de l'application : noms/masques valides, fichiers requis, émetteurs de certificats valides, versions minimales, exceptions.

2) Développement d'une application bureautique
- L'application sélectionne la source (dossier/UNC/ZIP/fichier MSI), la décompresse dans une zone temporaire, construit une arborescence de fichiers et effectue des vérifications
- Génère un rapport en deux types : lisible par l'homme (fichier PDF ou HTML) et lisible par machine (JSON)
- Prend en charge les profils de règles (par exemple Dev/CI/Release) avec commutation
- Dispose d'un mode "comparer deux packages" - affiche la différence entre les fichiers, les hachages, les signatures et les versions

3) Mise en œuvre des contrôles
- Hachage de chaque fichier et comparaison avec le standard, si celui-ci est précisé
- Vérification de l'authenticité des fichiers PE : statut de la signature, émetteur, durée de validité du certificat au moment de la signature, horodatage le cas échéant
- Pour les fichiers non signés ou avec une erreur de signature - une liste séparée avec la raison
- Vérification de version pour EXE/DLL via FileVersionInfo et comparaison avec les règles
- SBOM : générer une liste de fichiers avec des métadonnées (chemin, taille, hachage, version le cas échéant), les intégrer dans CycloneDX/SPDX JSON ; une version simplifiée est autorisée sans analyse de dépendances, mais avec les identifiants de schéma et de composant corrects au niveau du fichier/package

4) Emballage et livraison
- Créez un programme d'installation prêt à l'emploi (MSIX ou MSI/WiX, ou Squirrel - votre choix) et une version portable
- Journaux de diagnostic (fichier journal) et messages d'erreur clairs
- De brèves instructions (README en russe) sur la façon d'ajouter/modifier des règles et d'exécuter le contrôle

Restrictions
- Tout devrait fonctionner hors ligne, sans services cloud externes
- Vous ne pouvez pas demander à l'utilisateur d'installer de lourdes dépendances (sauf pour le .NET Desktop Runtime standard, si .NET est sélectionné)
- Sur une taille de package allant jusqu'à 3 Go et 50 000 fichiers, la vérification devrait prendre 7 minutes sur un PC i7/16 Go/SSD, la progression devrait être affichée
- Les fichiers temporaires doivent être effacés automatiquement même s'il y a des erreurs

Critères d'acceptation mesurables
- Sur les packages de tests fournis, l'application produit les mêmes résultats lors d'exécutions répétées, le rapport JSON est valide et correspond au schéma convenu
- Pour 5 cas préparés à l'avance (fichier signé, non signé, signature avec certificat expiré sans horodatage, signature avec horodatage, fichier avec mauvaise version), l'application classe correctement le statut et reflète le motif dans le rapport
- Le mode de comparaison de deux packages affiche le minimum : fichiers ajoutés/supprimés/modifiés, changements de hachage, changements d'état de signature, changements de version
- Le programme d'installation installe et supprime l'application sans déchets, la version portable s'exécute sans installation

Ce qui sera fourni
- Un ensemble de tests ZIP/MSI (via lien/archive), tableau de règles actuel, liste des éditeurs de confiance, exemples de rapports attendus (sous n'importe quelle forme)

Résultat attendu
Un programme de bureau prêt à l'emploi pour Windows, code source, configurations de règles, programme d'installation et assemblage portable, ainsi qu'un ensemble minimum de tests automatiques pour la logique de vérification (au moins des tests unitaires pour l'analyse des règles et la classification des statuts de signature).