Software artifacts typically have a very high number of CVEs, in some cases, security reviews have found over 1K CVEs, but handling all of these CVEs is practically impossible. Usually, the common way of deciding which CVEs to resolve is based on CVSS scoring, as well as published technical information on the relevant security advisories. This can be very challenging and an insufficient method for understanding the actual risk raised by a vulnerability for the following reasons:
CVSS scoring provides very limited insight into the actual risk that the CVE poses.
CVSS scoring does not contain a deep analysis on the chances of real-world exploitation.
The values inserted into the CVSS formula do not represent either the common case or the preconditions that are needed for successful exploitation.
The fixed weights of the CVSS formula do not reflect the actual risk in some cases.
For example, take a CVE that is a very severe, easily-exploitable, remote code execution vulnerability (RCE) in a librarylib. It will probably have a very high CVSS score, but there is only a rare scenario that allows remote access. It can be a vulnerability in a function that is not used in the real-world, or rare conditions that should be met, like using the vulnerable librarylibin a “debug” mode for example.
In addition, the published technical information of CVEs in security advisories, is sometimes very limited. It would be very hard to understand these specific conditions that need to be met for the CVE to be applicable, as well as fixing solutions, which are not necessarily a software upgrade, but also code patches or any deployment or code mitigations.
This is where JFrog Security CVE Research and Enrichment comes into play. JFrog security research and threat intelligence teams continuously review and analyze CVEs, existing and new ones, to determine if they are likely to be exploited by real-world attackers. Based on the analysis, the research team set a JFrog Research Severity score for CVEs, and provides detailed technical information on the specific conditions for the CVE to be applicable, as well as detailed fixing and mitigation options.
CVEs analyzed by the JFrog security research team are determined by the following criteria:
The number of existing exploits (or creating an exploit is trivial).
The number of documented real-world attacks.
The potential impact of the exploitation.
Having a high CVSS score.
After the deep analysis, CVEs are enriched with the following research information:
What is the vulnerable function and what is considered as a vulnerable call, that makes the exploitation possible and puts the software artifact at risk?
What are the cases where the function is disabled or not compiled?
What are the configurations that make the vulnerability hard to exploit?
Affected software components and versions.
Existing patches to fix the vulnerability with or without upgrading the component.
Deployment or development mitigations to mitigate or eliminate the riskof the vulnerability.
Which CPU architecture is relevant to the vulnerability if only specific ones are exploitable.
What should you do with JFrog research enriched CVEs?
CVEs with the highest JFrog security severity are the most likely to be used by real-world attackers. This means that you should put effort into fixing them as soon as possible. After fixing those CVEs, the risk of the software artifact being exploited by a CVE becomes much lower.
To help you fix the issues, the JFrog security team provides you with detailed fix and mitigation options for the CVEs. In some cases, there are easier and harder ways to fix an issue.
For example, it may be possible to fix a CVE in the Linux kernel in several ways:
Upgrading the kernel, which is usually considered hard
Applying a dedicated patch, which is much easier
Mitigating by an almost trivial configuration change
By providing all the different mitigation options, Xray empowers you to make smart choices when creating the mitigation plan and choosing the paths with the highest return on investment.
CVEs with low JFrog security severity are considered less risky, as it would be very unlikely to exploit them in the real world, or the impact of the exploitation is low.