VulNow and security before CVEs

There is a product devised by two cybersecurity experts that deserves attention because of the impact it could have on the use and integration of programming code; it is an innovative and very promising idea.

The project

This is VulNow, developed through a collaboration between Cassie Crossley and Valerio Mulas; it is a service capable of identifying vulnerabilities in production code after a maintainer has released a patch, but before a CVE or an official advisory is registered. The service operates precisely within this time window, buying valuable time to remedy the issue. Indeed, the publication of a CVE can often take weeks or even months.

As the vulnerability has not yet been catalogued and officially recognised within a CVE, it will remain undetectable by standard vulnerability scanners but can be widely exploited by cybercriminals through reverse-engineering of the patch. Consequently, VulNow operates in a highly dangerous ‘grey area’, ensuring a tangible response in terms of cybersecurity. The system therefore proactively identifies the presence of a vulnerability in the code and enables the necessary security measures to be put in place even before official tools become available.

Interactions with the regulatory framework

This solution offers a practical response to the regulatory compliance requirements set out in the CRA (Cyber Resilience Act) as well as in NIS2.

Cyber Resilience Act

VulNow is correctly incorporated into the CRA (Cyber Resilience Act), as the legislation stipulates that products must be free from known exploitable vulnerabilities before being placed on the market – but that is not all; once on the market, it must be ensured that vulnerabilities can be resolved through security updates. If this were not sufficient, the CRA requires manufacturers to identify and document all software components and dependencies (at least at the first level) in a structured, machine-readable format, to enable vulnerabilities to be resolved promptly via free security updates, provided separately from feature updates (where technically feasible).

NIS2

In terms of compliance with NIS2, VulNow also meets the requirements set out in Article 25(4)(a) and (b) of the regulation very well. The tool is, in fact, based on the ability to proactively detect vulnerabilities, which is precisely what the regulation requires when referring to significant incidents:

An incident is considered significant if:
a) it has caused, or is capable of causing, a serious operational disruption to services or financial losses for the entity concerned;
b) it has had, or is likely to have, repercussions on other natural or legal persons, causing considerable material or non-material losses.

As can be seen, the legislation does not treat hazardous events as having occurred in the past, but rather regards them as plausible and requires proactive measures to prevent disruption to services and/or financial losses. It is worth noting, in particular, that measure PR.PS-06, relating to ‘secure software development practices being integrated and their performance monitored throughout the entire software lifecycle’, requires NIS entities to endeavour to adopt and document‘secure code development practices in software development’. Furthermore, rule ID.RA-08 requires that vulnerabilitiesbe “promptly addressed through security updates or mitigation measures, where available, or by accepting and documenting the risk in accordance with the risk treatment plan”. NIS2 entities may therefore find VulNow to be a viable solution for resolving vulnerabilities without having to wait for the official publication of CVEs.

Results and performance

The results obtained by VulNow were compared with those published in the official CVE list (sourced from GitHub, the NVD and the CVE database) for 70 reproduced findings that were subsequently assigned a published CVE. Two types of matches were assessed:

• an exact match (same severity).
• a group match (identical or adjacent severity levels, for example ‘High’ where the CVE indicates ‘Critical’).

At the time of detection: the severity of VulNow is:

• An exact match in 43 per cent of cases.
• A group match in 87 per cent of cases.
• Only 13 per cent show a greater deviation.

After the screening

Once a survey has been reproduced and the score recalculated on the basis of the evidence gathered, the results are as follows:

• the exact match rises to 56 per cent.
• Group concordance at 94 per cent.
• Only 6 per cent show a larger discrepancy, whilst the remaining differences are evenly split between higher and lower ratings.

When examining 67 vulnerabilities using the CVSS version 3.1 rating standard, the reproduced score indicates the same severity as the official score: 3.1 in 57 per cent of cases. Furthermore, it yields the same severity rating or an adjacent one in 97 per cent of cases: 8 out of 8 ‘Critical’, 32 out of 33 ‘High’ and 25 out of 26 ‘Medium’.

For reproduced vulnerabilities that feature in MITRE’s Top 25 most dangerous software weaknesses (CWE Top 25), the severity rating estimated by VulNow matches the official CVE rating in 50 per cent of cases, and is the same or very close in 95 per cent of cases. Furthermore, VulNow’s classification of the vulnerability type (CWE) matches the official classification in 79 per cent of cases at the time of initial detection and in 84 per cent of cases following the reproduction phase.

False positives

Of the 54,831 records collected to date, 5,409 have been analysed, meaning that they have been confirmed by a subsequent official notice or verified directly through a change of code. Of these:

• 5,138 turned out to be genuine vulnerabilities.
• 231 did not turn out to be vulnerabilities (false positives).
• 40 are still under discussion.

This results in a false positive rate of 4.3 per cent across all the observations analysed.

The authors

Cassie Crossley

Valerio Mulas

Conclusions

The interesting thing about this solution is that it allows solutions to remain secure even when the CVE has not been published: in itself, this situation would risk leaving the code exposed to vulnerabilities for months, if not longer. On the other hand, regulations require these vulnerabilities to be patched as soon as possible; however, there is a risk of these going unnoticed because, as mentioned, scanners cannot detect vulnerabilities without the CVE. It is an important step towards a proactive approach that is practical rather than merely theoretical, and which could, objectively speaking, change the way code is used and implemented compared to how it has been done up to now.