Microsoft’s Request for a Video POC: A Rigid Process Under Scrutiny
A recent incident has spotlighted a curious practice at the Microsoft Security Response Center (MSRC) that may be prompting questions about the balance between thoroughness and red tape in vulnerability disclosure. Senior Principal Vulnerability Analyst Will Dormann, a well-respected figure in the infosec community, recently submitted a detailed bug report to MSRC complete with clear screenshots and a comprehensive written explanation. Instead of proceeding with the information provided, MSRC insisted on receiving a “clear video proof-of-concept” that captured every keystroke and command execution, arguing that without it there could be “no progress” in assessing the vulnerability.
The Request Unpacked
MSRC’s email to Dormann was unambiguous: to further evaluate the reported bug, they required a video demonstration—a requirement that Dormann found both unnecessary and excessive. His original report contained all the critical information developers typically need, including screenshots that meticulously documented the issue, yet the additional demand for video evidence implied that the process was more about ticking procedural boxes than understanding the technical nuance of the report.
Dormann’s Response: Malicious Compliance in Action
Frustrated by what he viewed as a bureaucratic hurdle, Dormann decided to comply—but not without injecting his own brand of satire into the process. He produced a 15-minute video that humorously underscored the absurdity of the request. Notably, at the four-second mark, the video flashes a screenshot from the film Zoolander, featuring the infamous “Center for Kids Who Can't Read Good.” This clever twist is paired with a techno backing track and approximately 14 minutes of inactivity, visually emphasizing that the additional “evidence” did little more than reiterate what was already clear from his screenshots.
This act of “malicious compliance” wasn’t simply a means to vent frustration; it was an intentional demonstration of how a rigid, process-driven approach can sometimes miss the forest for the trees. Dormann argued that when a researcher has gone to the trouble of producing a detailed report, forcing them to spend extra effort on a video that adds no valuable insight reflects poorly on the vulnerability management process itself.
Industry Practices: A Comparison
While Microsoft’s insistence on video evidence might appear unorthodox at first glance, it is not entirely alien to many modern bug bounty and security platforms. Numerous organizations and platforms, such as HackerOne and Bugcrowd, sometimes request additional proof-of-concept files or supporting videos. However, the standard in many public sector organizations and cybersecurity authorities remains a detailed written disclosure supplemented by relevant screenshots.
For instance, the Cybersecurity and Infrastructure Security Agency (CISA) leverages the Vulnerability Information and Coordination Environment (VINCE) system, allowing a concise 10 MB file upload with subsequent files being optional on request. Similarly, the UK’s National Cyber Security Centre (NCSC) generally advises a straightforward description coupled with instructions to reproduce the issue, without mandating an elaborate video demonstration.
The Divergence in Approach: Is It Justifiable?
Dormann’s experience raises broader questions about what constitutes sufficient evidence in vulnerability reporting. On one hand, video proofs-of-concept might help illustrate complex exploit paths or dynamic interactions that aren’t easily captured in static images. On the other, when a vulnerability is self-evident through a well-documented sequence of screenshots and concise textual explanations, demanding additional video evidence might seem redundant.
Key points to consider include:
• Clarity Over Complexity: Not every vulnerability benefits from a video demonstration, especially if the reproduction steps are relatively straightforward.
• Process vs. Understanding: A review process that focuses more on fulfilling a checklist than genuinely digesting the technical matter can undermine trust between security researchers and vendors.
• Incentive Structures: Excessive procedural demands could deter well-intentioned researchers from reporting vulnerabilities, potentially leaving critical issues unaddressed.
Dormann’s Frustrated Voice
In his communication via Mastodon and subsequent public commentary, Dormann did not mince words. He expressed disappointment not only in the extra workload forced upon him but also in what he perceived as a lack of genuine engagement from the MSRC team. Out of three vulnerability reports submitted recently, two were met with demands for video evidence, while the third was dismissed outright for lacking what Dormann described as “clear evidence” of a vulnerability—despite his report containing detailed information.
This pattern sends a worrying signal: a process oriented strictly around form over substance might lead to missed opportunities in identifying and mitigating actual security risks. Researchers like Dormann are on the front lines, striving to enhance the security of platforms used by millions. Their reports, when acknowledged, contribute significantly to improving the integrity of complex systems like Windows. Yet, a mechanical focus on meeting procedural requirements can foster feelings of underappreciation and might even slow down the chain of critical security communications.
Implications for the Future of Vulnerability Reporting
At the heart of this debacle lies an important conversation about the nature of vulnerability disclosure. Should security teams prioritize rigid procedural steps over a flexible, human-centric approach? Dormann’s actions clearly suggest that when the process becomes a hurdle rather than a help, it may require re-evaluation.
For vendors like Microsoft, maintaining robust security means not only investing in cutting-edge defense mechanisms but also nurturing healthy interactions with the research community. When knowledgeable experts are met with inflexible demands, it risks signaling that the process is more about bureaucratic box-ticking than about truly understanding and acting on the vulnerabilities reported.
The Road Ahead
Microsoft has yet to provide a public comment on Dormann’s video or his overall experience with the video POC requirement. Their recent publication on the strengths and key features of the coordinated vulnerability disclosure program indicates confidence in their process, yet the incident raises valid questions about procedural effectiveness. Dormann’s experience could well serve as an impetus for Microsoft and similar organizations to rethink their vulnerability review protocols, ensuring they strike a balance between comprehensive assessments and practical efficiency.
In Conclusion
This episode is a striking reminder that vulnerability disclosure should serve as a collaborative, constructive exchange rather than a ritualistic exercise in compliance. Dormann’s satirical yet pointed response underscores the need for security procedures that are as dynamic and nuanced as the threats they aim to mitigate. As the debate continues, one thing remains clear: keeping systems like Windows secure isn’t just about patch management and updates—it’s also about fostering a process that respects and values the insight of the experts on the front lines.
Source: The Register Researcher trolls Microsoft over bug disclosure annoyance
Last edited:
