The trusted-toolchain scanning gap in Windows Defender.
The same file that Windows Defender blocks when you download it in a browser is scanned differently — in practice, not at all — when you acquire it through git clone. Same source. Same bytes. Different security treatment. Reported to Microsoft; assessed as by-design. This is the documented finding.
Same bytes, two verdicts
While assembling a digital-forensics toolkit, an attempt to download YARA — VirusTotal's own, entirely legitimate malware pattern-matching tool — directly from its official GitHub repository was blocked by Windows Defender's real-time / SmartScreen download protection.
The identical repository, acquired instead through git clone (via Visual Studio, command-line git, GitHub Desktop — any git client), completed with no security intervention at all.
Defender applies SmartScreen, real-time protection and cloud analysis to browser downloads — but implicitly trusts developer-toolchain operations, applying minimal-to-no scanning when the same bytes arrive via git clone.
The example here uses YARA precisely because it is trusted, benign software — that is what makes the inconsistency clean to demonstrate. The vector is not the file. The vector is the delivery channel.
Identical bytes, four delivery channels
The same official repository was acquired five ways on the same machine. Only the browser download path triggered Defender. Every developer-toolchain path completed with no detection.
| Acquisition method | Channel | Defender action | Result |
|---|---|---|---|
| Browser download (release ZIP) | SmartScreen + real-time | Flagged & blocked | BLOCKED |
git clone (command line) | developer toolchain | No scan invoked | NO DETECTION |
| Visual Studio — clone repo | developer toolchain | No scan invoked | NO DETECTION |
| GitHub Desktop — clone | developer toolchain | No scan invoked | NO DETECTION |
| Post-clone manual scan of folder | on-demand | Scanned | 0 threats found |
Same source, same bytes, opposite verdicts. The single differentiator is the delivery channel — not the content.
Raw evidence — the MSRC portal record and per-method scan logs — is available on request; it is withheld here because full-desktop captures expose unrelated personal data.
The chain, at the flow level
This diagram is deliberately architectural, not operational — it shows how the trust gap propagates, not how to weaponize it. There is no exploit, payload, or command here. The point is the shape of the exposure.
Read the reach; draw your own conclusion
We are not going to hand you a severity number. We'll give you the factors and let you do the multiplication — because the exposure is defined by who has git installed, not by any single clever payload.
git clone contentminimal → noneReported, and assessed as by-design
This was disclosed to the Microsoft Security Response Center. Microsoft reviewed it and classified the behavior as by-design rather than a security vulnerability — an intentional coverage/performance trade-off. In fairness, their reasoning, quoted directly:
“Defender focuses on scanning content when it is being executed or consumed, rather than during creation or hydration… certain operations, such as cloning large repositories… can be extremely resource-intensive to scan in real time… This design choice reflects an industry-standard trade-off between coverage and performance.” — Microsoft Security Response Center, MSRC case VULN-168419
It is a defensible engineering trade-off, and we present it as theirs, without distortion. We also assess it as a real, exploitable coverage gap — because “scan on execution” assumes the cloned content is run on the machine that scans it, and in a supply-chain flow the content is compiled and shipped onward, reaching users on whose machines it may never trip an on-execution scan in a recognizable form. Reasonable parties can disagree; both verdicts are on this page so you can judge for yourself.
A fix exists. It is deliberately not published here.
We built a working mitigation: a lightweight pre-parser byte-validation layer that inspects content as raw bytes before it reaches the toolchain — independent of the delivery channel, so git clone and browser download receive the same scrutiny. In internal testing it added single-digit-millisecond overhead per file with a 0.00% false-positive rate on a clean test corpus.
We are not releasing the implementation openly. This page is a notification, not a toolkit: it documents that the gap exists and that a mitigation exists. Organizations who want the mitigation — or a deeper technical briefing under appropriate terms — can reach us directly.
Responsible for endpoints, a build pipeline, or a security program?
If this coverage gap is relevant to your environment, we can walk you through the finding in detail and discuss the mitigation. No fear-selling, no public exploit — a straight technical conversation.
How this was handled
- Dec 14, 2025 — Behavior discovered while building a forensics toolkit; reported to MSRC (case VULN-168419).
- Dec 15–16, 2025 — Technical analysis documented; a pre-parser mitigation built and tested against the finding.
- Dec 2025 — MSRC assessed the behavior as by-design; case closed on that basis.
- Jul 2026 — Public write-up released — well beyond any standard disclosure window — describing the gap and its reach, mitigation withheld.
CVE-2021-22681 — the unpatchable flaw hitting water utilities → An open proof of concept, an honest IEC 62443-4-2 mapping, and a phased rollout for the small water utilities Rockwell’s own guidance assumes have a security team.