2026-08-25 · Security · 9 min read
A Security Scanner Gave My Open Source Project a Trust Score of 1
Mouzi was open source, local-only and still labelled malicious by several reputation services. Here is how I investigated the warnings, appealed them and watched the score climb from 1 to 80.
I found out that Mouzi had a reputation problem through a Reddit comment.
The comment was only two words: "Malicious webpage."
Mouzi is an open-source desktop application that organizes downloaded files. Its website has no accounts, no payment form and no server-side application. The program works locally, and the source, build workflows and release files are public on GitHub.
None of that stopped mouzi.cc from receiving a trust score of 1 out of 100.
The first report I opened showed warnings from a long list of security providers. Some called the domain malicious. Others used labels such as malware, suspicious or scam. VirusTotal also displayed an alarming community score beside the URL report.
From a user's perspective, the distinction between those numbers hardly matters. If a security page places a red warning next to a download site, most people will close the tab. I would probably do the same.
The problem was no longer whether I knew the project was safe. I had to find out what the scanners had actually detected, whether any warning could be reproduced, and how to correct a reputation record that had already spread between providers.
The warning looked more precise than it was
Security reports combine several different kinds of evidence.
A scanner may inspect the current page, follow redirects, download linked files and run them in a sandbox. It may also use domain age, hosting history, user votes, external blacklists and data received from other security companies.
Those signals are not equivalent.
VirusTotal's community score, for example, is based on user votes weighted by the reputation of the people casting them. It is not the number of antivirus engines that detected a threat.[1]
The Gridinsoft report was more useful because it showed the factors behind its score. At the time, mouzi.cc was a young domain with little public reputation history. It distributed software, linked to executable files and had been labelled by several external providers. Those warnings then became evidence for another warning.
This creates an awkward loop:
- One provider classifies a young domain as risky.
- Other services ingest that classification.
- The growing number of warnings lowers the domain's reputation elsewhere.
- The low reputation becomes another reason to keep the warning.
The report looked like several independent discoveries. In practice, some of the verdicts appeared to be the same broad reputation signal travelling through different systems.
Was GitHub the problem?
My first suspicion was GitHub.
Mouzi's source is hosted there, and the download buttons point to GitHub Releases. The domain had also previously been served through GitHub Pages before I moved the website to Vercel.
Shared hosting platforms inevitably attract abuse. A service that lets anyone publish a page or upload a file will be used by legitimate developers, but also by spammers, phishing campaigns and malware distributors. That can make automated reputation systems more cautious around new projects with little history.
It would still be wrong to conclude that GitHub itself caused Mouzi's classification.
The reports did not identify a malicious GitHub repository, release URL or commit. Gridinsoft actually treated the linked public GitHub profile as a positive transparency signal. During its later manual review, the team downloaded all six release files and confirmed that they matched the published release records.
GitHub was part of the hosting and release context. It was not evidence of malicious behaviour.
That distinction matters. A plausible explanation is not the same thing as a reproduced cause.
I started asking every provider for evidence
The external warning list included ADMINUSLabs, alphaMountain.ai, Bitdefender, Chong Lua Dao, CRDF, CyRadar, Forcepoint ThreatSeeker, Fortinet, G Data, Lionic, Sophos, VIPRE, ESET, Avira and Norton Safe Web.
There was no single appeal form that could correct all of them.
I sent ten direct emails and completed separate web forms for the providers that did not accept email reports. Each message included the exact domain, a short description of Mouzi, the public repository, the current release and a request for the specific URL or behaviour that caused the classification.
I deliberately did not write, "This is safe, please remove it."
The useful question was: what did you detect?
If a provider had found a compromised page, altered download or unexpected network request, I needed to know. A false positive was the likely explanation, but treating it as certain before checking would have been careless.
The first replies arrived quickly.
alphaMountain rescanned the site and changed its classification. VIPRE said the domain had been unblocked and that updated definitions would propagate within hours. Sophos opened a case for manual review.
Gridinsoft initially kept its own classification because the external labels were still present. I replied with the exact current URL, the public source, release links and the evidence available for the current deployment. The team then performed a fresh independent review instead of relying only on the aggregated reputation record.
The manual review checked the actual project
This was the part I wanted from the beginning.
Gridinsoft requested every URL in the current sitemap. All 35 pages returned HTTP 200 from mouzi.cc. The review found no password field, iframe, meta refresh, scripted external navigation, automatic download or response that changed according to the browser's user agent.
It followed the six download links for the Windows installer, MSI package, portable executable, AppImage, Debian package and RPM package. All led to the disclosed Mouzi 0.1.5 release on GitHub, and the downloaded files matched the published release records.[2]
The reviewers also inspected the Rust and Tauri application source, the Astro website, the release tag and the successful build workflows. They did not find a credential receiver, remote-control endpoint, downloader, persistence mechanism or application telemetry sender.
There was one result worth investigating rather than dismissing.
Hybrid Analysis gave the MSI installer a malicious score. Its visible trace showed the installer downloading the Microsoft Edge WebView2 bootstrapper and installing that prerequisite silently. This is expected behaviour for a Tauri application on a Windows system without the required runtime. Microsoft documents this deployment method, including downloading the Evergreen Bootstrapper from Microsoft's link.[3]
The child file recorded in the sandbox matched the file served by Microsoft. The report named no Mouzi malware family, and the same sample had zero detections from the 24 MetaDefender engines shown in the review.
An installer starting another installer can look suspicious to a behavioural model. In this case, the trace also explained exactly why it happened.
The score moved from 1 to 80
After the independent review, Gridinsoft removed its detection and marked the current deployment and Mouzi 0.1.5 release links as safe.
The trust score did not jump to its final value at once. I watched it move from 1 to 64, then 70, and finally 80 out of 100 as the report and connected reputation signals refreshed.
The remaining deductions were understandable. The domain was only four months old, and several external providers had not yet processed their appeals. The Windows executables were also not Authenticode-signed because the production certificate was still being prepared through the SignPath Foundation program.
Unsigned software is not malware. It does, however, give both users and automated systems less publisher identity to verify.
That is now part of the release work, together with publishing checksums and keeping the website's download links tied to exact GitHub release artifacts.
What I learned from the appeals
The most frustrating part was not one incorrect result. It was the absence of a shared correction path.
Security providers exchange intelligence, but a developer still has to contact many of them separately. Some offer a clear false-positive form. Others provide an email address. A few send an automated case number and no useful status until a human reviews it.
If your own project lands in the same situation, I would do the following.
Record the exact object
Save the full URL, file hash, release version, timestamp and screenshot. "My site is flagged" is not precise enough when the website and six downloadable packages are separate objects.
Ask for reproducible evidence
Request the exact path, payload, redirect or behaviour behind the verdict. Broad labels are difficult to investigate. A sandbox trace can be checked.
Verify the release chain yourself
Download the files through the public website and compare them with the published release. Check redirects, hashes, build logs and the deployed site. Do this before assuming the provider is wrong.
Keep the public project easy to inspect
A visible repository, readable source, tagged releases, build workflows, checksums, privacy documentation and a stable domain do not prevent false positives. They make a manual review much easier.
Appeal every original provider
Removing one downstream warning may not last if the same service later imports the old verdict again. Follow the chain back to the providers named in the report.
Do not tell users to ignore security warnings
Explain the false positive, link to the evidence and keep working through the review process. Asking people to disable protection or add a permanent exclusion is the worst possible way to build trust.
Reputation is not the same as a security verdict
The original score was not invented from nothing. A new domain offering unsigned Windows downloads is a reasonable target for additional scrutiny.
The mistake was allowing broad, non-reproducible labels to look like proof of a current malicious object.
Automated reputation systems have to make decisions at a scale where manual review is impossible. False positives are part of that tradeoff. The useful test is what happens after a developer provides a stable URL, matching artifacts, public source and a request for evidence.
In Mouzi's case, the detailed review found no harmful site behaviour and no malicious release payload. The score changed because someone finally inspected the thing being classified instead of only counting the classifications around it.
The site did not become safer between a score of 1 and a score of 80.
The reputation data became more accurate.