Vulnerabilities

A vulnerability item in Open-AudIT can be thought of as essentially a query against your database to determine your potential exposure to a given CVE report. A vulnerability is made up of the CVE report, along with enrichment data from FirstWave. These two items are combined to produce a suitable query that is automatically downloaded from FirstWave.

How do they work?

Our new feature called Vulnerabilities gives you the ability to quickly determine if any devices are affected by any CVE (Common Vulnerability Exposure) records - but how?

FirstWave constantly consumes the output from the Nist NVD feed. We take this and apply a few restrictions, then extract the affected programs and build a SQL query for reporting. Your Open-AudIT instance reaches out to FirstWave and requests any new vulnerabilities on a regular basis. When it receives a new vulnerability record, it is run against the database and the result stored. Each time a device is processed, all matching vulnerabilities are again executed and the result stored. This means when viewing a vulnerability list, we don't need to calculate all affected devices - we already have the result. When you view an individual vulnerability record, we do indeed recalculate the result for this singular vulnerability.

So, you're always up to date!

In addition to this, we also calculate the result of all vulnerabilities for all devices daily (usually at a quiet time, say 2am).

In your instance of Open-AudIT, we allow you to select which vendors you care about. i.e. there's no use retrieving vulnerability records from a vendor whose software you do not use or have installed. By default, our vendor list is Adobe, Apple, Cisco, Google, Microsoft, Mozilla, and Redhat.

This all sounds very simple, but behind the scenes a LOT is going on. For instance, the vulnerability record contains a list of affected software - but those software names do not match what we receive when we audit a computer. A good example is Apache. Typically, a vulnerability record will say the affected software is http_server. In reality, this appears as apache2 (Ubuntu), httpd (Redhat), Apache HTTP Server (Windows) - and others. So, we have to first determine what is the actual name of the program we receive when we ask a computer - which may be multiple. After that we must parse the NVD record and create a matching SQL statement. Allowing for multiple program names as above, and multiple versions, version ranges, and even multiple different pieces of software (an example is Thunderbird and Firefox in a single CVE). And your instance of Open-AudIT must take this and apply Orgs filtering as well. And that's just a single vulnerability record. What about determining which records you have and don't have? What about adding a vendor to the list later? So many things to consider!

As well as the usual reporting, we also have a few new widgets available for Dashboards, based on Vulnerabilities data.

Notes

A vulnerability can be editied and more specific package names provided where the enrichment data is insufficient or the generated SQL isn't quite correct.

Any attributes followed by a * indicate that CVSS data less than v4 was used to complete this field. By default, we attempt to use v4 fields, however if they are not populated we will fallback to the previous version(s) for attributes.

Open-AudIT does not provide vulnerability reports for the following:

• Libraries (ie, code that another program might include). These are typically items like Wordpress extensions, drupal extensions, node.js libraries, Android / iPhone / Windows libraries, python libraries, etc.

• A CVE item that does not contain a filter to determine the affected item(s).

• Vulnerabilities initially published before 1st January, 2025 (by default). We see no sense in returning vulnerabilities from years prior.

• CVEs with a status of received, awaiting analysis, undergoing analysis. These CVEs (mostly) do not contain sufficient information to enable us to generate a correct SQL query.

Vulnerability Status

Scope

Scope is known as Authorization Scope, representing whether a vulnerability affects resources beyond the original security authority of the vulnerable component.
The only two valid values for this attribute are:

• unchanged — The exploited vulnerability only impacts resources within the same security authority as the vulnerable component. In other words, the attacker’s actions stay within the original trust boundary.
  
  

• changed — The exploited vulnerability can affect resources beyond the security authority of the vulnerable component. This usually means a privilege or trust boundary is crossed (for example, escaping from a container to the host OS).