From Coordinated Disclosure to Cooperative Vulnerability Research When Dealing with Critical Software Stacks

Improving vulnerability disclosure process for critical software stacks

• Traditional vulnerability disclosure process for critical software stacks is less effective and needs improvement
• There is a need for closer collaboration between researchers and vendors to accumulate learnings and produce better software
• A global wall of fame for vendors who are willing to be collaborative can be created
• Positive aspects of software architecture should be highlighted in vulnerability reports
• Open source groups can be helped with vulnerability disclosure process
• Cultural divide between security researchers and vendors needs to be bridged
• Poor handling of critical software vulnerabilities can lead to dangerous consequences for asset owners

The psychological aspect of reporting bugs can be challenging as companies may see it as a threat rather than a helpful contribution. This can lead to poor handling of vulnerabilities and dangerous consequences for asset owners.

When it comes to critical software stacks (like embedded network libraries or real-time OSs), is it time to change the way we, as researchers, approach vendors when disclosing vulnerabilities? Shouldn't we start cooperating with them before disclosing vulnerabilities, as early as when the research begins, so that they have both a chance to learn and to help security researchers in finding more vulnerabilities?What is needed is more of a relationship between the security research industry and those developing and deploying critical software components. The current status quo is that of conflicting parties trying to become friends, often during the disclosure phase by means of an intermediary broker. Unlike more traditional vulnerabilities reported in Operating Systems or Application stacks, mitigation of vulnerabilities found in critical software components often means the chance of easily patching is a task many shy away from. This is where adopting a shifting left approach might be the right path to take. Patching equipment with a lifespan of between 10-20 years is not possible. Currently, we have seen from experience where responsible disclosure is often delayed, or in a worst-case scenario cancelled, due to the impact that it might have.While this approach doesn't scale for mainstream software, for which continuous security testing (e.g., fuzzing) and auto-updates work very well, recent researches have showed that the most impactful vulnerabilities found in critical software components require custom tooling and substantial research effort. This cannot simply be streamlined and should not be streamlined (or the most interesting bugs will remain undetected). This implies that we as researchers should focus on a few, but very high-impact targets, as early as possible in the SDLC, secure good communication with the developers, to the extent that the developers will disclose to the security researchers where they think the weakest spots of their software is. In other words, the attacker model of a vulnerability research should consider a better-informed, and thus more powerful, attacker than the real one.