Vulnerability reporting in the Cyber Resilience Act: not such a good idea?
This European regulation aims to improve the security of products and services that have digital components, by imposing requirements on their manufacturers and distributors. This is a commendable endeavor. However, it would be wrong if such an ambitious regulation were not open to improvement. Let’s take a closer look at this process.
The time for reporting vulnerabilities and incidents has arrived. Among the requirements of this regulation about to be adopted are those related to disclosing vulnerabilities. Article 11 of the Cyber Resilience Act (CRA) requires software publishers and manufacturers to report actively exploited vulnerabilities to the European Cybersecurity Agency (ENISA) and to the national Computer Security Incident Response Team (CSIRT), designated as coordinator.
These companies will be able to submit their reports via a “one-stop portal” developed and operated by ENISA, and must do so within 24 hours of becoming aware of the issue. They can provide additional information within 72 hours, followed by a final report no later than two weeks after they’ve released a patch or corrective action.
An almost identical procedure applies to any security incident whose impact is assessed as “severe,” meaning that it has a significant impact on the targeted product or service. The deadline for the final report is slightly longer in this case: one month after the incident has been closed.
One major difficulty likely to arise is the (operational) confusion between reporting a vulnerability that is actively exploited and causing problems, and reporting a security incident resulting from the exploitation of a vulnerability. This may be a case of “you say tomayto, I say tomahto,” but it’s likely to lead to double reporting. And when the two overlap, how do they fit in with the security incident reporting requirements of the NIS2 directive?
Designed as an accountability measure, the vulnerability reporting requirement is intended to encourage companies behind digital products and services with questionable security records to actively seek out vulnerabilities and patch them to mitigate the impact. While well-intentioned, this requirement is likely to have unintended negative consequences for the product manufacturers, the authorities and users alike.
Artificial emergencies in search of real benefits
Article 11 of the CRA therefore requires software publishers and manufacturers to report unpatched and exploited vulnerabilities to the authorities within 24 hours. This means that dozens of government agencies would have access to a real-time database of unpatched vulnerabilities, without the ability to leverage them to protect the online environment.
There are several risks associated with rushing the reporting process and having widespread knowledge of unpatched vulnerabilities. Vulnerabilities that could have serious consequences for user security are often kept confidential until patches are available or even properly applied. These vulnerabilities may take weeks or months to correct, or may never have a realistic chance of being patched.
The CRA also sets out what must be included in the detailed report. However, there is no mandatory requirement for corrective actions and their consequences to appear in this report. Corrective actions that address the root cause are time-consuming and can be difficult to roll out, particularly when they involve a large number of components or affect complex products and services that are not readily accessible. This is a shame, as the real benefit — especially with such a centralized system designed to demonstrate resilience at European level — comes from the visibility of the patched environment.
Do as I say, not as I do?
A reporting requirement with such short deadlines is bound to create bottlenecks and overwhelm many national CSIRTs lacking operational maturity. This fear is even more acute given that there is no criticality threshold for reporting vulnerabilities. It seems that software publishers and manufacturers will have to report any vulnerability as soon as it is actively exploited, regardless of its CVSS score.
Added to this catalog of shortcomings is the fact that ENISA and national CSIRTs collect and accumulate exploited vulnerabilities. Knowledge of a series of vulnerabilities by government agencies is by no means unanimously endorsed, especially as these agencies will be exclusively European. However, software publishers and manufacturers subject to this requirement are international.
The rationale behind the criticized approach is reminiscent of China’s Regulations on the Management of Network Product Security Vulnerabilities, published in July 2021 and effective as of September 2021. Under these regulations, vulnerabilities affecting products and services must be reported to the Chinese Ministry for Industry and Information Technology within 48 hours of discovery by the software publisher or manufacturer.
Similarly, the regulations forbid publishing information about vulnerabilities before a patch is available, unless the publisher or manufacturer and the Ministry agree otherwise. They also forbid publishing an exploit PoC showing how to exploit a vulnerability. In practice, the Chinese framework funnels all reports of unpatched vulnerabilities to the authorities, creating a hotbed of vulnerabilities that could be exploited for offensive purposes, and preventing coordinated action within the ecosystem.
There is a real concern that a similar approach will be adopted in Article 11 of the CRA, given that its current wording focuses on reporting to a set of government agencies operating through a centralized platform. Apart from channeling reporting to agencies, Article 11 fails to provide clear information on the public disclosure of reported vulnerabilities.
No deadline is specified, and the software publisher or manufacturer only has to notify affected users. The national CSIRT may take responsibility for informing and distributing any corrective measures to those affected if the publisher or manufacturer fails to make a public announcement. Deadlines and criteria for deciding whether or not to inform the public are left to the discretion of the CSIRT, with no time limit mentioned. This kind of approach is vague enough to complicate or render useless any information provided to users. Communication is essential to keep the products and services in question secure.