CNA Story
Our story as a CNA is a bit different than others. But let us start at the true beginning: VulDB launched in 1997. It was a different time back then. When people were talking about vulnerabilities or exploits, they were talking about products: "Did you hear about the new wu-ftpd exploit?" Identifying issues was somehow easier because there were not that many of them. Especially not the ones that really drew interest by attackers. And if there was a potential confusion, people were referring to version numbers of affected products or mentioned technical details like vulnerable filenames or exploited functions.
When CVE was introduced in 1999, I was personally very skeptical. It sounded like a good idea, but I was doubtful that the program would be able to reach the level of technical flexibility and professionalism that would be required to add sustainable benefit to the industry. I must admit, I was wrong to a large degree. But I am okay with that.
Extended Coverage
Over the years CVE made a lot of things easier for us. We are a vulnerability database without a scope like vendor CNAs or vulnerability catalogs covering specific product types. We add "everything" that can be exploited in software or hardware. We are very close from hosting more than 200.000 entries in our database.
Even though we share a very similar philosophy like the CVE program our approach slightly differs. For example, we do also accept submissions for vulnerabilities in malware. That is because we think that on top of the malicious code additional attack surfaces are introduced which increase the risk. And people should know about this. You would be surprised how many malware comes with buffer overflows, directory traversal possibilities, and permission issues. Professional goals and quality control in that business decreased over the years.
Duplicate Handling
Due to our extended coverage our main challenge is handling and preventing duplicates. We are very proud to have had just a hand full of such in the last 25 years. In these rare cases we use merge and forward capabilities to redirect users to the right entries. All edits are documented in a commit history which makes changes very transparent.
Dealing with potential duplicates requires a lot of effort to verify, synchronize, and align vulnerability details. This would be much easier if it is not for speed for which most customers prefer our services. We want to be fast and due to established SLAs we have to be. Our data team monitors thousands of sources 24/7. And as soon as a new vulnerability disclosure is suspected, it is analyzed for eligibility.
At the beginning CVE used the obsolete CAN tag (candidate) to deal with new entries. We do not use such a tagging. But we add a confidence level to every commit to help users to put data into quality context. Duplicate detection became harder again because there are a lot of new vulnerabilities published nowadays (approx. 76 per day in 2022 compared to 40 in 2016) and many more communication channels available. In earlier days reading mailing lists and collecting vendor advisories was enough. But today monitoring code repositories, social media, and darknet marketplaces is even more important. Especially if you want to cover 0day vulnerabilities.
Why we joined the CVE Program
For many years colleagues and customers were approaching us and asked why we are not supporting the CVE program or even become a CNA ourselves. We are working with CVE data daily and are well aware of the importance of the program for the cyber security industry. And the demanding requirements that come with such importance.
In 2021 we decided to contact the CVE program to discuss possibilities of a collaboration. It was very important for us to not become dependent of external partners and being a pawn in political gambits. We want to be quick and accurate. CVE demands in Rule 7.3 the declaration of a scope for every CNA. Our scope is even broader than the CNA rules define and therefore narrowing down to something not in our interest. We were able to agree upon a rather broad and product-independent scope. Primarily we shall assign CVEs for products not covered by other CNAs. But we are also allowed to negotiate vulnerability processing with other CNAs. If a vendor does not want to handle a vulnerability but it is one by the CNA rules, we may cover it. Security researchers appreciate this possibility.
Importance of Vulnerability Management
CNA Rule 7.2 defines a clear requirement for splitting and merging entries. Our own philosophy differs slightly. Not much but enough to add another level of complexity for our data team. If there is one CVE, we might have split it into multiple entries. Or there are several CVEs available for a single entry.
Occasionally customers want to understand why this is. One might expect us from being tired of this kind of discussions. But quite the contrary as we enjoy the exchange of the philosophical nature of vulnerabilities. There is a lot of room for ideas which can enrich and improve our industry. Product assignments, version handling, risk ratings, and vulnerability class definitions to just name a few. Projects like CPE, CVSS, CWE, and ATT&CK took the role like CVE in their respective field. They are often not perfect but help to introduce a common language.
Unfortunately, it is often forgotten that vulnerability management is one of the main pillars of cyber security. Perhaps because for some it might not spark the sexy appeal of new topics like artificial intelligence and blockchain. But for us it does. Because without vulnerability management, there will be no new secure technologies.
Conclusion
Our dedicated CNA team supports the data team in processing new submissions and coordinating CVE disclosures. This re-introduced the early challenges of duplicate detection before the CVE era. But we can profit from a lot of experience and optimized processes that were compiled over decades. We are very confident and happy to be a part of something important like the CVE program.
This article was also published in the official blog of the CVE program.