Future Vision

After we have achieved a certain level of efficiency with our core projects. There are certain expansions that we can do, to bring out the best of our product. One of which, can be, A Cloud Based Vulnerability Management System. Wherein, if someone uses our product to scan for vulnerabilities in a software and there are several vulnerabilities found. Instead of them having to update their database and scanning the software again, to know if the vulnerabilities have been patched or not. We can notify the developer, indicating as and when, the vulnerability is patched and vice-versa, i.e. If no vulnerability was found earlier and a new vulnerability is found now. A similar notification can be issued. On a commercial level, orgs have a lot of use for such kind of system. They won’t have to constantly monitor their systems and third party softwares for vulnerabilities. There is a system, on cloud, monitoring it for them.

Additional Benefits: Delivery of zero-day exploit notification, in their product, will be quicker. An immediate intimation on the availability of a patch/update.

This is something that very few proprietary softwares are doing, today and even fewer with an efficient system in place. Our USP (Unique Selling product), though, is not limited to this. It will actually be an automated system, which will eradicate the need of human intervention to patch vulnerabilities. This approach is based on a research paper, published in 2009, by Minzhe Guo & Ju An Wang ¹. Which defines an ontology based method, to model CVEs. Which in layman terms means, making a computer understand what the semantics of a vulnerability are. A slight drawback, if we may call it, of the CVE dataset, is it’s syntactic description format.

While present day vulnerability management systems might understand that a vulnerability exists, they don’t understand the underlying semantics of that vulnerability and how to patch it, themselves. For ex: Vulnerability management systems, today, know that there is a vulnerability, but they don’t know what part of the software is affected by it or how serious can the impact of that vulnerability be.Today, we need human intervention, to detect vulnerabilities and patch them. But, because of human error. There are times, when the maintainers aren’t even aware about a reported vulnerability in their system and other times, they aren’t aware of a patch/update that was released. Because of which, systems stay vulnerable to exploits, longer than they should be.

National Institute Of Standards & Technology (NIST), USA. Came up with, Security Content Automation Protocol (SCAP), which it defines as a “synthesis of interoperable specifications, derived from community ideas” (sic). SCAP is basically a community of people from industry, research, educational institutions, and government “that are working to advance automation and standardization of technical security operations.” (sic)

In 2016. NIST, taking a step further towards the automation process has come up with DRAFT 8138², “Vulnerability Description Ontology”. Which it defines, as “a framework for characterizing vulnerabilities” (sic). Which is based on similar lines as the research paper, earlier mentioned. Since, no better approach towards automation of vulnerability management systems, has come into light, yet. This might be the defacto of how we deal with vulnerabilities, few years down the line.

After we are able to deliver efficiency in our core project. We will walk on to develop it further on the lines of an automated vulnerability management system, if success is achieved. We will be the very first Open Source and even general organisation to lay the foundation stone, of a one of it’s kind system.