I wired MDASH into Defender CLI and GitHub — what it flagged and what it missed
Hands-on with Microsoft's MDASH bug hunter in public preview: what it caught, the logic bugs it missed, and whether the 622-patch headline survives a real repo.
Microsoft's MDASH (Project Perception) is in public preview, and after running it against a real mid-size repo through the Defender CLI and the GitHub connector, my verdict is: it's a solid noise-reducer for known bug classes and a genuinely useful triage layer, but it is not the autonomous bug hunter the headlines imply. It found real memory-handling issues I'd have caught with a good static analyzer anyway, and it whiffed on the logic bugs that actually matter.
The pitch is that MDASH is a multi-model AI vulnerability scanner positioned as a wider-access, lower-cost alternative to Anthropic's Mythos, and it's been credited with a record 622-patch July across Windows. That framing shows up in the original report, and it's worth pulling apart before you budget engineering time around it.
Does the Defender CLI setup actually work?
Setup was less painful than I expected. The Defender CLI auth flow uses your existing Entra tenant, so if you're already in the Microsoft security stack there's no new credential dance. The GitHub connector installs as an app with read access to your repos and opens findings as annotated PR comments.
One gotcha: the connector defaults to scanning the default branch only. If your work lives on feature branches — and whose doesn't — you have to explicitly add branch globs in the connector config, or MDASH silently scans nothing new and reports a clean run. A clean run that scanned zero changed files looks identical to a clean run that scanned everything. Check the file count in the job log.
What did it actually flag?
On a C++/C# service repo it flagged a genuine unchecked buffer length in a parser and two use-after-free candidates. Both were real. The AI's explanation of the buffer bug was clear and pointed at the exact call chain, which beat the raw analyzer output I usually squint at.
What it missed: an auth check that ran after the resource was already fetched — a textbook broken-access-control pattern. MDASH read it as valid control flow because syntactically it is. That's the ceiling on these tools right now. They pattern-match vulnerability shapes; they don't model your intent.
False positive rate was tolerable — roughly one bogus flag for every three real ones on my run. Better than most static tools, worse than the marketing suggests.
Does the 622-patch headline hold up?
The 622-patch July number is real but it's doing a lot of load-bearing work. That count is Microsoft's internal Windows pipeline with privileged source access, dedicated fuzzing infrastructure, and human triage behind every finding. Your GitHub connector run gets none of that. Treating 622 as a preview of what MDASH does on your repo is a category error — it's what Microsoft's whole security org did with MDASH as one input.
Should you use it?
Yes, if you're already in Defender and want an extra triage pass on memory-safety and injection classes. It's cheap to bolt on and the PR-comment workflow means findings land where engineers already look. No, if you're expecting it to replace a pen tester or catch business-logic flaws — it won't, and pretending it does is how you ship a false sense of coverage. I'd run it as one signal among several, not as the gate.