Responsible vulnerability disclosure in Europe

There is a report out today from the European economics think-tank CEPS on how responsible vulnerability disclosure might be harmonised across Europe. I was one of the advisers to this effort which involved not just academics and NGOs but also industry.

It was inspired in part by earlier work reported here on standardisation and certification in the Internet of Things. What happens to car safety standards once cars get patched once a month, like phones and laptops? The answer is not just that safety becomes a moving target, rather than a matter of pre-market testing; we also need a regime whereby accidents, hazards, vulnerabilities and security breaches get reported. That will mean responsible disclosure not just to OEMs and component vendors, but also to safety regulators, standards bodies, traffic police, insurers and accident victims. If we get it right, we could have a learning system that becomes steadily safer and more secure. But we could also get it badly wrong.

Getting it might will involve significant organisational and legal changes, which we discussed in our earlier report and which we carry forward here. We didn’t get everything we wanted; for example, large software vendors wouldn’t support our recommendation to extend the EU Product Liability Directive to services. Nonetheless, we made some progress, so today’s report can be seen a second step on the road.

4 thoughts on “Responsible vulnerability disclosure in Europe

  1. I won’t comment on the CEPS paper because it is behind a very high paywall.

    However, with respect to the patching problem, I will say: we should forbid manufacturers to coercively bundle security/safety patches with unrelated feature changes, which are often unwanted by a product’s owner.

    Security/safety patches commonly produce positive externalities (for example, a patch to prevent a botnet from seizing control of an IoT device, thereby reducing harm from DDoS attacks). We should forbid manufacturers to reduce the value which product owners can internalize from such patches by poisoning them with feature changes.

    Mandatory or coercively-bundled feature changes imposed/delivered after the initial product sale represent a unilateral and retroactive change in the terms of the bargain between purchaser and seller. As such they are properly considered unlawful, and regulation to clarify and enforce the law would not be oppressive.

    1. OTOH smuggling security patches into desirable feature releases gets them installed more widely before they get reverse engineered and exploitation starts (assuming vendor moves first).

  2. You can pay for a paper copy of the report or download a pdf for free. I have also put the pdf here so you don’t have to navigate the CEPS interface.

Leave a Reply

Your email address will not be published. Required fields are marked *