Windows Backup Cluster
    Transparency notice — Windows agent

    Windows warning about NimbusBackup?
    It's a false positive.

    A browser or antivirus product may show a "Virus detected" or SmartScreen warning when you download our agent. Nimbus Backup is safe: this is not a virus. The code is open source, the build is public, and the VirusTotal scan is clean. Here's exactly why it happens and how you can verify it yourself.

    Last updated:

    Nimbus Backup is not a virus

    The warning is heuristic: a statistical guess, not a match against a known virus. Two facts you can verify yourself.

    Clean on VirusTotal

    Our installer scans clean across the industry's antivirus engines: 0 detections. The up-to-date report is published, per release, in the release notes.

    Example: v0.2.105 - v0.2.106 - v0.2.107 - v0.2.108 - v0.2.109

    Fully open source

    Every line of code and the exact build pipeline are public (GPL-3.0). Read it, audit it, or build it yourself.

    VirusTotal analysis of the NimbusBackup installer — 0 antivirus engines detect it as malicious
    VirusTotal scan of the installer — no threat detected (dated example)VirusTotal report (latest version)

    Why does this happen?

    NimbusBackup is written in Go with a Wails desktop interface. This is a well-known, documented issue across the whole Go ecosystem — Syncthing, rclone and many other reputable projects have hit it. Five factors combine.

    1. Go binaries look unusual to antivirus engines

    Go produces large, statically-linked executables with no external DLLs and their own runtime. Machine-learning scanners are trained mostly on "traditional" binaries (MSVC, dynamically linked), so a Go binary stands out as atypical. And because much modern malware is also written in Go, engines weight that profile negatively.

    2. Stripping + PIE = high entropy

    Build flags -s -w strip symbols and -buildmode=pie randomizes addressing. The binary then looks packed or obfuscated — a classic malware signal — when these are in fact sound compilation practices.

    3. Wails loads WebView2 in memory

    Startup loads a loader (go-winloader) to initialize the WebView2 rendering engine. This in-memory DLL loading is also a technique used by some malware: the heuristic fires, even though it's the normal way Wails works.

    4. A backup tool "looks like" ransomware

    Each step is legitimate in isolation, but together they statistically resemble the profile of ransomware — exactly what behavioural detection (generic Wacatac / Sabsik families) is built to catch:

    • • requesting administrator rights (UAC);
    • • creating VSS shadow copies;
    • • reading entire drives recursively;
    • • compressing + encrypting data;
    • • uploading over the network (TLS) to a remote server;
    • • installing a LocalSystem service.

    5. No reputation yet + retroactive re-flagging

    A recent, unsigned binary starts with zero SmartScreen/Defender reputation. And because definitions update continuously, a file that was clean yesterday can be flagged today with no code change — which is why the alert is intermittent.

    Key point: a heuristic false positive is not the detection of a known virus. The code is open source and auditable, the build is public on GitHub Actions, and the multi-engine VirusTotal scan is clean.

    References and similar cases

    NimbusBackup is not an isolated case. False positives on Go/Wails binaries and backup tools are a documented problem, reported by the Go and Wails maintainers and several established open-source projects. These references explain why our response is verification-based: public source code, checksums, build attestations, VirusTotal reports and Microsoft submission.

    Official sources

    Similar cases (open-source projects)

    What we are doing about it

    Our goal: the agent should download and install with no alert at all. Three levels of action — permanent measures, a one-off per-release gesture, and the real fix in progress.

    Permanent measures

    Automatic: every future release benefits with no extra work.

    Code 100% open source (GPL-3.0), auditablePermanent
    Public, reproducible build — pinned versions (Wails v2 / library v2.8.0, goversioninfo 1.4.0)Permanent
    Windows publisher metadata (RDEM Systems) on the NimbusBackupSVC.exe servicePermanent
    SHA-256 hashes (SHA256SUMS.txt) published with every releasePermanent
    Build provenance attestation on the binaries — verifiable build down to the commit (GitHub Actions)Permanent
    Automatic VirusTotal submission — link published only if the report is clean (CI gate)Permanent
    Bilingual explanation page linked from the README and release notesPermanent

    One-off per-release gesture

    Manual, only if Defender re-flags a new release.

    Re-submitting the false positive to Microsoft

    If a release gets re-flagged, we re-submit it through the Microsoft portal. Resolution typically takes 24-72 hours; once the binary is reviewed and added to the allow-lists, the alert disappears for the version concerned.

    The real fix (pending)

    Code signing will remove these warnings at the root — for good.

    Application submitted

    Authenticode signing via SignPath

    We are obtaining an Authenticode code-signing certificate through the SignPath Foundation , its free program for open-source projects — application submitted. Once signed, the binary carries a verifiable publisher identity, the most effective signal to build the reputation Windows expects and make these warnings go away.

    When signing lands: restructuring the MSI signing order (deep-signing the embedded executables) so the whole installer is covered.

    Fallback

    Signing via Azure Trusted Signing

    If SignPath refuses or is slow, we'll switch to Azure Trusted Signing (Microsoft's managed code-signing service). Backed by the Microsoft ecosystem, it speeds up reputation building with Defender and SmartScreen. It's our safety net.

    How to verify and install safely

    Until signing is active, here's how to install the agent with confidence.

    1

    Check file integrity

    Compare the SHA-256 of your download with the value published in SHA256SUMS.txt on the releases page.

    2

    Review VirusTotal

    Open the VirusTotal report and confirm there are no detections across the engines.

    3

    Proceed past the warning

    On the browser warning choose Keep. On the SmartScreen dialog click More info → Run anyway.

    # Verify the hash on Windows (PowerShell)
    Get-FileHash .\NimbusBackup.msi -Algorithm SHA256

    # Verify the build provenance (GitHub CLI)
    gh attestation verify .\NimbusBackup.msi --repo rdemsystems/NimbusBackupClient

    Got a better way to clear these alerts? We're listening.

    The project is open source, and we believe it's better built together. Have you already handled false positives on a Go binary, got feedback on SignPath or Azure Trusted Signing, a build trick that lowers entropy, or a contact on the antivirus-vendor side? Send us your solution.

    Transparency is part of backup

    Open code, public build, SHA-256 hashes, a VirusTotal analysis, a documented signing plan: you know exactly what you're installing. Still unsure? Email us, or build it yourself from source.