I'm not in any way involved with this specific program, but I do work on VisualStudio.
It's pretty common for all kinds of software projects to take bug reports - even very detailed and thorough ones - from people who ultimately don't end up fixing the bug.
The interesting thing about finding a security bug - especially with the constraints described here - a working exploit and a white paper - it's pretty unambiguous that you've found one. You either have or you haven't.
Now, how to actually fix that bug might be a lot more nuanced.
This statement isn't made to in any way imply that a researcher who could find such a bug _couldn't_ also fix it.
Rather, some bug fixes may be preferable to others, from Microsoft's point of view. And so, my impression is - we're not looking for patches that we'd end up re-writing. We're looking for the really nasty bugs, and then we'll go off and come up with fixes that satisfy the big pile of requirements that we have [for example, performance impact]
A valid observation would be, "if these were really open source projects, anyone in the community would be able to run the same regression and performance tests that Microsoft would run, and thus be able to make perfectly valid fixes themselves"
Well, to a point. Long long ago, I found an IDE driver bug in OpenBSD and submitted a fix for it. The fix was substantially re-written by the maintainer, and, ultimately the whole subsystem was replaced in the next version anyhow.
My fix met the functional requirements, so near as I can tell. But there are things like coding style, or maybe even the personal preferences by the project maintainer(s), that can still impact how a particular patch gets rejected or modified prior to being committed.
Furthermore, I think we would hate for there to be a vuln out there that somebody knows about, but is sitting on until they can come up with a fix that they like.
So, yes, I think we really just want the vulnerability reports, well substantiated and with demonstrated exploits. Finding those things is still very much a niche skill.
Fixing them, once they are understood, and balancing those fixes with the other requirements in the system, is more bread-and-butter Microsoft engineer stuff.
fwiw, I've been at Microsoft 15 years, much of it in VisualStudio. Before that, I worked only with UNIX systems, and I've stayed up to date as a hobby.
The way we are trying to engage with Apple, Linux, and F/OSS in general is completely unlike anything we did up until just the last year or so. People I've worked with for years are suddenly diving headlong into Linux development. Arguments that I tried to make a decade ago are now being made by other people.
It's a really interesting time at the company.