What is a Vulnerability?

A philosophical but practical exploration of technical vulnerabilities

Let’s check Merriam-Webster:

open to attack or damage

This doesn’t feel complete. What’s missing? Let’s check Wikipedia:

In computer security, a vulnerability is a weakness which can be exploited by a threat actor, such as an attacker, to cross privilege boundaries (i.e., perform unauthorized actions) within a computer system.

The attacker. Exploitation.

Without getting too philosophical, all software/hardware/services have vulnerabilities. Let’s conduct a simple thought experiment: would you bet a million dollars that a specific software/hardware/service does NOT have a vulnerability?

So clearly almost everything has vulnerabilities. But it seems like it matters if an attacker knew about the vulnerability and if they have the capability to exploit it.

Vulnerabilities are different when compared to other software bugs for one simple reason: they don’t expose themselves and change the state of the system until someone triggers them intentionally. Even when the system state changes to a less secure state (e.g., exposing information), the attacker still needs to take advantage of it. In other words, it isn’t just enough to find a buffer overflow, the attacker must develop a malicious payload that can exploit it and execute the code they want.

Vulnerabilities are a bit like quantum particles: they don’t exist until you observe them, which requires interacting with them to have any proof that they really are a vulnerability. Until then they… probably exist, but not conclusively.

So how does this help us?

If an attacker has to have knowledge of a vulnerability in order to exploit it, then it stands to reason that the defenders also have to have knowledge of the vulnerability in order to fix it. While one could make the argument that defenders must monitor your systems for compromise, and when exploited investigate and fix the problem, I think it might be more efficient to first try letting defenders know about what vulnerabilities may exist so they can take corrective action in advance of being attacked.

So where do we get the data sources for this? There are three main options:

1. CVE
2. Private company data feeds
3. Global Security Database

CVE is currently the only public database of security vulnerabilities, but the problem is it isn’t machine-readable. It was meant to be; they use a JSON format (disclaimer: I invented it, and it’s not a very good format) but they do not have machine-readable data for which products are vulnerable or not vulnerable in roughly 25% of all CVE entries, and even the entries that do have the data are often not complete. Many only list a single entry. For example, the recent #log4j vulnerability from CVE shows 6 vulnerable versions of the upstream version and hasn’t been updated at all in over a week now:

Compared to the 2,800 entries in the CISA database and the 5,500 vulnerable and not vulnerable items in the NCSC-NL database, both of which are getting multiple updates every day. The obvious problem with the private company data feeds is that they cost money and often contain false positives. Finally, we have https://GlobalSecurityDatabase.org, which is nowhere near having a “complete” dataset, but is building a community and processes that will result in a much better dataset than CVE has, where false positives can easily be challenged, and of course it will be free for use (but also licensed so that companies can make use of it - I want everyone to use it). And we have a really good entry for CVE-2021-44228.

So how can you get involved in the Global Security Database? Simple: A CSA Circle Community is available at https://csaurl.org/circle-gsd and there is also a mailing list at https://csaurl.org/list-gsd. Come help us build the best vulnerability identifier out there!