Software publishers: what procedure should you follow to report a vulnerability (CVE)?
The in-house development of software solutions enables companies to meet their own specific needs or those of their customers without purchasing or sub-licensing solutions from third parties. As such, software publishers are responsible for the development, maintenance and security of the software solutions they develop. In terms of security, software publishers must incorporate measures for the governance and technical management of the security of their information systems right from the design stage of their solutions. The implementation of an effective ISMS(i.e. Information Security Management System) means, among other things, keeping a close eye on potential security flaws or vulnerabilities in their software.
In addition to the secure development of software solutions, the monitoring of vulnerabilities and their technical resolution, it may be necessary to publicly declare a vulnerability. Assigning a CVE(i.e. Common Vulnerabilities and Exposure) number to the security flaw helps to ensure transparency for your customers by increasing their confidence in you, ensuring regulatory compliance, and preventing the vulnerability from being exploited by proposing and distributing appropriate patches or relevant security alternatives.
In order to be able to react effectively and provide the relevant authorities with all the information needed to publish a vulnerability in your software solution, you need to establish a vulnerability disclosure procedure which must be validated by management.
Which vulnerabilities need to be published?
CVE identifiers are only assigned to security vulnerabilities that meet a specific set of criteria. You must therefore ensure that you can offer a fix that is independent of any other vulnerability, and that there is no workaround for the said vulnerability. You must also publicly acknowledge that this vulnerability leads to a significant reduction in the security of your products.
Understanding how CVE numbering authorities (CNAs) work
CNAs(i.e. CVE Numbering Authorities) are the authorities responsible for assigning numbers to discovered CVEs. When a security flaw is detected by a publisher in its own software and meets all the above criteria, it is then necessary to submit a request to obtain a vulnerability identification number (CVE) from a numbering authority. The numbering authority will examine your request and publish the vulnerability if all the required information is submitted.
The CNAs are authorities of various kinds, responsible for detecting and publishing vulnerabilities. They are all coordinated by the MITRE Corporation, the root authority of last resort (CNA-LR). MITRE oversees the entire CVE programme and provides a comprehensive register of vulnerabilities published on an international scale.
It is therefore not possible to publish a CVE without first being assigned a CVE identifier by a CNA. The numbering of a CVE is made up of a very specific nomenclature starting with the acronym CVE, followed by the year of publication of the CVE, and finally the identifier (or number) of the vulnerability. CVEs are similar to a record and codification of vulnerabilities, enabling organisations to monitor vulnerabilities, implement preventive or corrective measures and, more generally, simplify the monitoring of vulnerabilities.
Choosing a CVE numbering authority
You cannot disclose vulnerabilities to just any CNA. They each have a specific scope, responsibility or competence. Some are dedicated to specific types of product, others to specific suppliers, or even to specific reporters.
Examples:
- The scope of the Apple Inc. CNA is limited to Apple vulnerabilities only.
- The scope of the AppCheck Ltd. CNA is limited to only those vulnerabilities discovered by AppCheck that do not fall within the scope of any other CNA.
- The scope of the CNA Indian Computer Emergency Response Team (CERT-In) is limited to vulnerabilities impacting all products designed, developed and manufactured in India.
In the list of MITRE partner CNAs, you should therefore find CNAs whose scope matches the context of your organisation and the nature of the vulnerability detected in your software.
If you are a software publisher, you must search the MITRE list of CNAs whose scope covers one or more of the following criteria:
- A CNA whose scope applies in your region;
- A CNA that allows you to report the vulnerability yourself;
- A CNA that does not relate to a particular type or brand of product.
As a last resort, if you can’t find a CNA whose scope allows you to submit a request, you can request a vulnerability identification number from the MITRE Corporation, whose remit covers “vulnerabilities in Open Source software products not already covered by a listed CNA”.
The key stages in the process of publishing a vulnerability
Throughout the vulnerability publication process, it is essential to ensure that all your regulatory obligations are met, whether in terms of protecting personal data or complying with cybersecurity reference standards. Always keep records of logs and other documents in accordance with your vulnerability management procedure or policy, as well as the history of your communications with the CNA.
Information required by the numbering authority
To report a vulnerability to a CNA or the MITRE Corporation, you must provide a set of documents and information concerning the vulnerability detected in your product. This includes, for example, details of your solution (type, name, versions, etc.), the cause and impact of the vulnerability on the security of your product and the types of attack that could occur if a patch is not implemented. You must also submit a link or a public reference summarising all your knowledge of the detected vulnerability, otherwise your vulnerability will not be published.
The different statuses of the vulnerability publication request
When you make a publication request to a relevant NAC for the vulnerability you have detected in your software solution, the authority assigns a CVE identification number. As long as you have not provided the authority with all the required information, your identifier is classified as “Assigned” and then “Reserved” by the CNA.
Once all the information has been submitted, if the vulnerability is not confirmed or if it does not concern a product covered by the CNA, the CVE identifier may be classified as “Rejected”.
On the other hand, if the CNA validates the information, the CVE identifier assigned to your vulnerability is published and classified as such.
Once published, if certain information needs to be revised or if other information needs to be added to the information initially published, you can submit a request to the relevant CNA (the one responsible for the initial publication of the vulnerability) to update the information relating to the vulnerability.
To conclude
The process of publishing vulnerabilities discovered in a software solution needs to be formalised in a vulnerability publication procedure. This will enable you to react quickly and effectively if a security flaw is discovered in your product. However, this procedure is part of a wider set of tools and documents needed to implement good governance of your ISMS. Policies and procedures for managing security events, incidents and vulnerabilities are all documents that need to be kept up to date if you are to manage security flaws in your products properly.
About CyberSecura
CyberSecura is a Grenoble-based company providing consultancy, services and support for professionals in cybersecurity and GDPR regulatory compliance.
Comprising experts in every facet of these fields, CyberSecura has been working since 2017 on securing infrastructures, software or mixed digital products, business processes, as well as the governance of the protection of personal data used.
CyberSecura’s customers range from large corporates to small organisations in both the private and public sectors, and it offers support solutions designed specifically to improve security and compliance for very small businesses, SMEs and small local authorities.
