The theory
The IT (CIO) and security (CISO) managers have everything under control. Their organization keeps up to date on an hourly basis whether new CVEs have been released for IT products that are in use. If patches are available, they are installed as promptly as possible. This ensures that existing vulnerabilities are fixed. This is the world of ISO 27001/27002. And also the theory.
The reality
At least 99% of IT products are buggy. Both in terms of functionality and security. While functional problems manifest themselves independently, security gaps (vulnerabilities) remain hidden. Until they are discovered and patched. Only this is not quite as easy and not as efficient as one would expect.
Vulnerabilities allow direct or indirect access to data and have a negative impact on stability, confidentiality, integrity and availability. No customer wants security holes. They are a freebies provided by vendors. And there are very few who are stingy with them.
What kind of products are affected?
Virtually all of them. Security products and products with security features are also affected. It also doesn't matter much who they buy the products from. Even purchasing through a partner that specializes in cybersecurity does not mean that partner has tested the products for security or knows the security provided by the product (https://i.blackhat.com/USA-19/Wednesday/us-19-Tsai-Infiltrating-Corporate-Intranet-Like-NSA.pdf). This is also true of most companies that offer security audits.
Vulnerability management: plugging known holes
Looking at the framework, it quickly becomes clear that Vulnerability Management is limited to vulnerabilities that have already been published. The only difference is that published vulnerabilities already exist before they are published and are also known to the vendor of the affected product before they are published. And this has usually been the case for months. If someone finds a vulnerability and reports it to the vendor, chances are that it has also been found by someone else. Vulnerability management does not cover vulnerabilities, it only covers the processes regarding plugging vulnerabilities that have been published and for which there is either a patch or mitigation.
The CVE system
CVE stands for "Common Vulnerabilities and Exposures." The goal is to identify, define and publicly catalog vulnerabilities. The organization is through the MITRE controlled U.S. National Cybersecurity Research Institute, which is government funded. It has a hierarchical structure: There are Roots and CNAs (Certificate Numbering Authorities). Most IT vendors are registered as CNAs and can issue CVEs. The majority of security vulnerabilities are not found by the vendors themselves, but by outsiders. These can report the security vulnerabilities to the vendor. The vendor then decides on the course of action. There is a code of honor among security researchers that security vulnerabilities found are not made public until 90 days after they have been reported to the vendor. This is called "Responsible Disclosure" and gives the vendor time to develop a patch for the vulnerability. Only 90 days after notification is a CVE then usually published along with a patch or recommended mitigation measure. Most vendors prefer what is known as "coordinated disclosure," which is also known as "managed disclosure". Here, the vendor takes over the coordination and can thus determine whether, when and how the existing security vulnerability is published. And it is also the vendor itself that can largely determine the severity of the vulnerability.
The CVE system is well-intentioned, but invites abuse by the vendors who themselves act as CNAs. It is the very same vendor whose products have security vulnerabilities that has the power to determine when the vulnerability is published and what severity level is assigned to it. In this system, the originator and thus the person responsible for the vulnerability can partially determine what is published and when, even though he is aware of the vulnerability and there is a security risk with his customers.
There is of course also an ISO standard for the publication of security vulnerabilities by vendors.
The market for security vulnerabilities
Many vendors do not treat security researchers very nicely when they report security vulnerabilities they have found. After all, they have found security vulnerabilities in the vendor's products and that does not put the vendor in a good light. And they are security holes that the vendor itself should have found during quality assurance and its own testing. Security gaps not only reveal problems in a product, but also deficits in the internal processes at the vendor.
Previously unknown security vulnerabilities are of interest to organizations engaged in information gathering. On the one hand, such organizations search for vulnerabilities themselves that they can exploit, and on the other hand they obtain exploits for previously unknown vulnerabilities from vendors of exploits for unknown vulnerabilities. There is a market for this. For purely money-oriented security researchers, this market can be very lucrative.
What is the benefit of good vulnerability management?
Good vulnerability management is better than nothing, but it is limited to known vulnerabilities. The best vulnerability management is of little use if the products are full of previously undiscovered vulnerabilities or if the vendor does not fix vulnerabilities known to him.
Insurance against cyber risks
An insurance company should actually know the risks it is insuring. In IT, much depends on the products used, their configuration and their inherent security. That in addition to the organization and processes. Currently, the insurance companies that insure cyber risks know the risks only rudimentarily. The fact that the risks have been underestimated is evident from the continuously rising premiums for corporate customers. And the risks are individual for each customer and should be determined individually accordingly.