Ggtkuk

We are a vendor providing a product that is being used in enterprises. We know that those companies having periodic CVE scans on products they are using part of their vulnerability management process. My question is, do we have to raise a CVE if our own security researcher found a vulnerability in our product or we can just raise this vulnerability in the weekly security updates we publish in our official website?

You can do either, but I recommend applying for a CVE so that customers who get threat intelligence feeds are more likely to notice the issue and expedite a patch. Assigning a CVE also makes it easier to reference a specific vulnerability in general communications if you need to later. It's also a signal to your customers that you take security transparency seriously.

CVEs are assigned and managed by MITRE, and you can use the CVE application form to make a request.

It would be helpful to publish the CVE so that others know it's necessary to update: as you said, they can see it in threat intelligence feeds (or CVE scans) instead of having to read the changelog of every update to decide whether they need to update.

Additionally, as a pentester, it helps us a lot in our work. If we find SAPConnectorDeluxe 4.1.39, the first thing we do is check a CVE database for any vulnerabilities. Even if the software is proprietary and in use for only a few companies, it is useful for us to know the risks of running that software so that we can advise the customer correctly.

It also tells us how frequently and what kind of issues are being found: if we see that a small software component had 10 buffer overflow vulnerabilities in the past year, we know the developers don't get the time to include security in their development process. In such a case, it's very likely that more vulnerabilities will be found, or are already found by malicious parties.

Submitting CVEs is not common if the software is only used internally. If we find custom software, we do some analysis (depending on how much time we have) and advise to have someone review its security more thoroughly. Info about internal products would not help anyone outside the company, so there is no need to publish it to a central database like CVE.

You are not required to request a CVE, but you are free to do so when you think it will be benificial.

A CVE is just a central number that identifies a vulnerability, which can assist when communicating about vulnerabilities. CVE's are particularly helpful when there are multiple parties involved. Anyone can request a CVE in your product, but in my opinion it looks better if you do it yourself before somebody else does.

I think the most important question is if your product comes with an auto-updater. If it auto-updates by default, then a CVE can sometimes do more harm than good by putting your product into the realm of awareness for many hackers who may otherwise not know you even exist. They can see your CVE history, and get a good feeling about your security posture. If they see a lot of fixes for "amature" mistakes, then your product might easily come under the scrutiny of people who know how to find the more obscure stuff that you may have otherwise gotten luck enough to avoid.

Also, products that are unlikely to be patched even if you release a CVE can do more harm than good. Most IoT devices never get patched, so, CVEs just tell hackers which ones are easy prey.

In contrast, if your product typically requires a manual update that is likely to happen if you release a CVE, then you should probably do it.

If this is a really critical issue, then you might patch the issue and keep it secret for as long as possible.

Then the customers have a longer time frame for applying software updates.

Also make sure to use as much binary obfuscation as possible, in order to hinder "differential reverse engineering" after delivering the patch.

Few companies will apply patches immediately, most will have some quality control and evaluation before any update is put into their systems. The CVE definition allows them to know what vulnerabilities are in the current version of the software. Then can then evaluate that vulnerability and make an informed choice of when they will apply the update.