Windows signale NimbusBackup ?
C'est un faux positif.
Un navigateur ou un antivirus peut afficher « Virus détecté » ou une alerte SmartScreen au téléchargement de notre agent. Nimbus Backup est sûr et sans danger : ce n'est pas un virus. Le code est open source, le build est public, et le scan VirusTotal est propre. Voici précisément pourquoi ça arrive et comment le vérifier vous-même.
Dernière mise à jour :
Nimbus Backup n'est pas un virus
L'alerte est heuristique : une estimation statistique, pas la correspondance avec un virus connu. Deux faits que vous pouvez vérifier par vous-même.
Propre sur VirusTotal
Notre installeur est analysé par l'ensemble des moteurs antivirus du marché : 0 détection. Le rapport à jour est publié, par version, dans les notes de release.
Exemple : v0.2.105 - v0.2.106 - v0.2.107 - v0.2.108 - v0.2.109 - v0.2.110 - v0.2.111 - v0.2.112 - v0.2.113 - v0.2.114 - v0.2.115 - v0.2.118 - v0.2.119 - v0.3.0 - v0.4.0 - v0.4.1
100 % open source
Chaque ligne de code et la chaîne de build exacte sont publiques (GPL-3.0). Lisez-le, auditez-le, ou compilez-le vous-même.
Pourquoi ça arrive ?
NimbusBackup est écrit en Go avec une interface desktop Wails. C'est un problème connu et documenté de tout l'écosystème Go — Syncthing, rclone et bien d'autres projets réputés l'ont subi. Cinq facteurs se cumulent.
1. Le profil des binaires Go paraît atypique
Go produit des exécutables volumineux, statiquement liés, sans DLL externes et avec leur propre runtime. Les classifieurs antivirus à base de machine learning sont entraînés sur des binaires « classiques » (MSVC, liés dynamiquement) — un binaire Go ressort donc comme anormal. Et comme de nombreux malwares modernes sont écrits en Go, les éditeurs pondèrent négativement ce profil.
2. Stripping + PIE = forte entropie
Les options de build -s -w retirent les symboles et -buildmode=pie randomise l'adressage. Le binaire ressemble alors à du code packé ou obfusqué — un signal classique de malware, alors qu'il s'agit ici de bonnes pratiques de compilation.
3. Wails charge la WebView2 en mémoire
Le démarrage charge un loader (go-winloader) pour initialiser le moteur de rendu WebView2. Ce chargement de DLL en mémoire est une technique aussi employée par certains malwares : l'heuristique se déclenche, alors que c'est le fonctionnement normal de Wails.
4. Un outil de sauvegarde « ressemble » à un ransomware
Pris isolément chaque point est légitime, mais ensemble ils dessinent statistiquement le profil d'un rançongiciel — exactement ce que la détection comportementale (familles génériques Wacatac / Sabsik) cible :
- • demande de privilèges administrateur (UAC) ;
- • création de clichés VSS ;
- • lecture récursive de disques entiers ;
- • compression et découpage des données en blocs ;
- • upload réseau (TLS) vers un serveur distant ;
- • installation d'un service LocalSystem.
5. Réputation nulle + re-flag rétroactif
Un binaire récent démarre avec une réputation SmartScreen/Defender de zéro. Jusqu'à la 0.4.0, nos binaires n'étaient pas signés : chaque version repartait de zéro. Depuis la 0.4.1, ils sont signés, et la réputation peut s'accumuler sur la même identité d'une version à l'autre. Et comme les définitions se mettent à jour en continu, un fichier propre hier peut être signalé aujourd'hui sans aucun changement de code — d'où le caractère intermittent de l'alerte.
Point clé : un faux positif heuristique n'est pas la détection d'un virus connu. Le code est open source et auditable, le build est public sur GitHub Actions, et le scan multi-moteurs VirusTotal est propre.
Références et cas similaires
Le cas NimbusBackup n'est pas isolé. Les faux positifs sur binaires Go/Wails et outils de sauvegarde sont un problème documenté par les mainteneurs de Go, Wails et plusieurs projets open source reconnus. Ces références expliquent pourquoi nous privilégions une réponse vérifiable : code source public, checksums, attestations de build, rapports VirusTotal et soumission à Microsoft.
Sources officielles
- Go — FAQ : antivirus et binaires Go
La FAQ officielle Go reconnaît que ses binaires sont parfois signalés à tort.
- Microsoft — Réputation SmartScreen
Comment SmartScreen évalue un binaire : hash, signature, éditeur, ancienneté.
- Microsoft — Soumettre un faux positif
Le canal officiel de signalement à Microsoft Defender — celui que nous utilisons.
- GitHub — Attestations d'artefacts
Le mécanisme de provenance derrière notre
gh attestation verify. - SignPath Foundation
Le programme gratuit qui fournit la signature Authenticode aux projets open source.
Cas similaires (projets open source)
- Wails #3308 — Defender sur un projet Wails vide
Notre GUI est en Wails : le faux positif touche le framework lui-même.
- Wails #2004 — WebView2Loader et score antivirus
Le chargeur WebView2 contribue au score heuristique des moteurs.
- Syncthing signalé par Windows Defender
Outil Go open source réputé, même symptôme sur l'exécutable.
- rclone — faux positif Windows Defender
Outil Go réseau/stockage, fréquemment mal classé selon les définitions.
- Duplicati — faux positif Bitdefender en sauvegarde
Cas côté logiciel de sauvegarde : antivirus, fichiers temporaires et backup.
Ce que nous faisons
Notre objectif : que l'agent se télécharge et s'installe sans aucune alerte. Trois niveaux d'action — des mesures permanentes, un geste ponctuel par release, et la signature des binaires, active depuis la 0.4.1.
Mesures permanentes
Automatiques : chaque future version en bénéficie sans intervention.
Geste ponctuel par release
Manuel, uniquement si Defender re-signale une nouvelle version.
Re-soumission du faux positif à Microsoft
Si une version est re-signalée, nous la re-soumettons via le portail Microsoft. La résolution prend typiquement 24 à 72 h ; une fois le binaire revu et ajouté aux listes blanches, l'alerte disparaît pour la version concernée.
Signer le binaire (actif depuis la 0.4.1)
La signature remplace « éditeur inconnu » par un éditeur vérifié, RDEM SYSTEMS. Elle ne fait pas taire SmartScreen du jour au lendemain : selon Microsoft, un binaire signé peut encore afficher l'avertissement tant que sa réputation, ou celle du certificat, n'est pas établie par les téléchargements. Ce qu'elle change durablement : signées avec la même identité, les versions suivantes peuvent hériter de cette réputation, alors qu'un binaire non signé repart de zéro à chaque version.
Signature via Azure Artifact Signing
Depuis la version 0.4.1, nos binaires Windows sont signés avec Azure Artifact Signing (anciennement Trusted Signing), le service de signature de Microsoft, avec un certificat au nom de RDEM SYSTEMS (Pontoise, FR). Prévue pour la 0.4.0, la signature a été retardée par l'ouverture du compte, bloquée côté Microsoft : la 0.4.0 est sortie sans signature. RDEM SYSTEMS s'affiche comme éditeur vérifié ; l'avertissement SmartScreen peut subsister tant que la réputation n'est pas établie. Aucun certificat ne permet plus de contourner SmartScreen, pas même un certificat EV.
Les exécutables sont signés avant d'être empaquetés dans le MSI, puis le MSI lui-même : l'installeur entier est couvert. Les outils en ligne de commande (archive nimbus-backup-cli) ne sont pas signés.
SignPath Foundation
Nous avions candidaté en mai 2026 au programme gratuit de la SignPath Foundation pour les projets open source. La candidature est restée sans réponse ; nous ne comptons plus dessus.
Vérifier et installer en toute sécurité
Signature, empreinte, rapport VirusTotal : trois vérifications indépendantes, puis l'installation.
Vérifiez la signature
Depuis la 0.4.1 : clic droit sur le fichier → Propriétés → Signatures numériques, ou Get-AuthenticodeSignature en PowerShell. Attendu : statut Valid, signataire CN=RDEM SYSTEMS.
Vérifiez l'intégrité
Comparez le SHA-256 de votre téléchargement avec la valeur publiée dans SHA256SUMS.txt sur la page des releases.
Consultez VirusTotal
Ouvrez les rapports VirusTotal et constatez l'absence de détection sur l'ensemble des moteurs.
Passez l'avertissement
Dans le navigateur, choisissez Conserver. Si SmartScreen s'affiche encore, vérifiez que l'éditeur est bien RDEM SYSTEMS, puis cliquez sur Informations complémentaires, puis Exécuter quand même.
Get-AuthenticodeSignature .\NimbusBackup.msi | Format-List Status, SignerCertificate
# Vérifier l'empreinte sous Windows (PowerShell)
Get-FileHash .\NimbusBackup.msi -Algorithm SHA256
# Vérifier la provenance du build (GitHub CLI)
gh attestation verify .\NimbusBackup.msi --repo rdemsystems/NimbusBackupClient
À lire aussi
Cette page fait partie de notre dossier sur la sauvegarde des serveurs Windows vers Proxmox Backup Server.
Sauvegarder Windows avec PBS — le tutoriel
Client GUI open source, token API, premier scheduler, snapshots VSS pas à pas.
Lire le guideRetour d'expérience : premier backup Windows 1 To
Chiffres bruts d'un run prod : 20 h 30 de transfert, 75 % de chunks dédupliqués.
Lire le retexChoisir son modèle de tarification backup
Au volume, au poste, au forfait : quel modèle pour sauvegarder votre parc Windows.
Lire le guideUne meilleure idée pour lever ces alertes ? On est preneurs.
Le projet est open source, et nous le pensons mieux à plusieurs. Vous avez déjà géré des faux positifs sur un binaire Go, un retour d'expérience sur SignPath ou Azure Trusted Signing, une astuce de build qui réduit l'entropie, un contact côté éditeur antivirus ? Proposez-nous votre solution.
Questions fréquentes
Faux positif antivirus sur l'agent NimbusBackup
La transparence fait partie de la sauvegarde
Code ouvert, build public, binaires signés, empreintes SHA-256, analyse VirusTotal : vous savez exactement ce que vous installez. Un doute subsiste ? Écrivez-nous, ou compilez depuis les sources.