CVE Monitoring Demystified: Why It’s Essential for Cybersecurity

A vulnerability is a weakness in a system that can be exploited, compromising an asset’s confidentiality, integrity, or availability. As software complexity has increased and its use has proliferated, the number of vulnerabilities has increased, making it increasingly important for companies to secure their software.

The main way of finding vulnerabilities is through CVE (Common Vulnerabilities and Exposures) monitoring. A CVE is just a known vulnerability that has been made public in a CVE list. The number of CVEs reported each year has been increasing, growing from around 16,000 new reports in 2018 to 40,000 in 2024. This is making it increasingly important for companies to have an effective strategy for dealing with these vulnerabilities so that their software remains secure. This is where CVE monitoring comes in.

What is a CVE?

A CVE (common vulnerabilities and exposures) is a way of formalising known vulnerabilities so that they can be resolved by everyone who has the affected software. CVEs are added to a list managed by the MITRE corporation. MITRE is responsible for giving CVEs a unique identifier and maintaining this list. A CVE unique identifier enables the standardisation of the list, ensures effective communication and allows for effective tracking/searching of the vulnerability.

Where can CVEs be found?

As mentioned above, the main CVE list maintained by MITRE contains all the CVEs with CVE identifiers. NVD is another database of CVEs managed by NIST (National Institute of Standards and Technology). This database also has additional fields like a CVSS (Common Vulnerability Scoring System), which adds a severity score based on how easy it is to exploit. The CVE entry also contains information about affected domains, estimated impact, attack vector and a description of how the vulnerability can be patched.

Not all vulnerabilities are issued with unique identifiers and, as a result, won’t be added to the CVE list but can still be found elsewhere. For example, vulnerabilities for open-source projects can often be found in the GitHub advisory database.

CVE Lifecycle

Once the vulnerability has been discovered by a vendor or third party, the vendor will either create a CVE or work on a patch before disclosing the vulnerability publicly. This can reduce the likelihood of exploitation; however, in some cases, it may be necessary to disclose the vulnerability before a patch is ready. After the CVE has been reported and a patch is ready, vendors whose software is affected by the vulnerability can apply the patch. This period between disclosure and patching is where we need to apply our strategy, reducing the attack surface by as much as possible.

How are vulnerabilities exploited?

An exploit is a method that a malicious actor uses to gain access to an asset using a vulnerability. After the exploit has been used, the attacker deploys a payload that compromises the confidentiality, integrity, or availability of an asset. Cryptocurrency miners and ransomware are both examples of payloads that have been increasing in frequency. Exploits are often bundled with known vulnerabilities in exploit kits that malicious actors can deploy.

Some examples of real-world attacks that took advantage to vulnerabilities include:

• Equifax breach (2017) – In July 2017, the American credit bureau Equifax was breached, leaking the sensitive information of 147 million people. The attacker exploited a vulnerability in the Content-Type header of an HTTP request in Apache Struts. The Apache Software Foundation released a patch for the vulnerability (CVE-2017-5638) in March, but Equifax didn’t apply this patch in a timely manner, resulting in the breach.
• WannaCry Ransomware (2017) – In 2017, a vulnerability in Microsoft’s Server Message Block (SMB) protocol was exploited. The payload was ransomware that infected 200,000 Windows machines. Microsoft did release a patch for the CVE (CVE-2017-0144) before the exploit was used; however, many users didn’t apply the security patch in time. Cl0p, the ransomware group responsible for the attack, made off with between $75 and $100 million. Economic losses were estimated to be $4 billion.
• The MOVEit breach (2023) – An SQL injection flaw (CVE-2023-34362) in the MOVEit Transfer app was exploited, giving the attackers access to MOVEit’s back-end database, which was used by thousands of organisations around the world. The attackers made off with the personally identifiable information of 17 million individuals. It was exploited as a zero-day vulnerability, meaning that the vendor was unaware of the vulnerability when it was exploited. A more proactive approach to testing software for vulnerabilities could have prevented this breach.

Monitoring CVEs

Software often incorporates numerous packages, each with its own potential vulnerabilities. CVE monitoring involves checking the CVE lists and databases to determine which CVEs are pertinent to a given software stack or product and patching these vulnerabilities to reduce the attack surface area. This can be done manually and with help from commercial and open-source tools. Often, a combined approach will be most effective. However, the exact strategy used will be dependent on the project structure and specific needs of the project team.

Managing Software BOM

A BOM (bill of materials) is an inventory of all software components, modules, libraries and dependencies and provides the following functions:

• Identification of third-party and open-source components.
• Maintenance of updates and end-of-life for components.
• Version tracking and identification of associated vulnerabilities.

The software version is what is compared to the CVE list. If the version matches the affected version information on the CVE, it needs to be patched.

Obtaining a list of CVEs

The NVD database provides a list of CVEs, which can then be mapped to the BOM.

Prioritisation and triage of CVEs

CVEs have varying levels of risk associated with them. We want to be able to address the most serious vulnerabilities first. This is where the prioritisation of CVEs comes in. CVEs can be prioritised based on several factors:

• Severity score (CVSS) – Some vulnerabilities are easier for attackers to exploit than others. Prioritising CVEs with a higher severity ensures that the attack surface area is reduced as much as possible.
• Attack Vector – This indicates how the vulnerability can be exploited, i.e., does the attacker need to be physically present to deploy the payload, or can it be deployed over a network? If our software is deployed on an IoT device that can only be accessed locally, we may want to filter out CVEs that have a network attack vector.
• Exploit availability – Is the exploit publicly available? CVEs with publicly available exploits could be prioritised over those without.
• Patch availability – Is there an available patch? If a patch is available, it can be deployed right away.
• Applicability – CVEs that aren’t applicable to the software (unused kernel drivers, for example) can be filtered out.

The prioritised list of CVEs can then be used to patch vulnerabilities in order of priority.

Tools and automation

Tools are available that can be used in conjunction with manual methods to make a strategy more effective.

• Build pipeline integrations, such as Yocto’s CVE class, can automatically generate CVE lists and reduce false negatives caused by inconsistent naming, though manual evaluation and triaging are still necessary.
• Vulnerability scanners compare package versions against CVE databases, simplifying vulnerability detection but often producing false positives and lacking the same depth of manual analysis.
• Additionally, security bulletins and mailing lists from vendors and organisations can provide early awareness of vulnerabilities and potential workarounds but require the identification of information that is relevant to the scenario and software stack.

A comprehensive strategy often combines both the paper method and the use of tools. The approach that is taken depends on the available infrastructure and capacities of the project. For example, Canonical takes a very thorough approach by monitoring CVEs in the field to determine which CVEs are applicable to their Ubuntu operating system. They also monitor release notes and subscribe to relevant security mailing lists. This approach is great, but it requires a dedicated security team.

Conclusion

CVE monitoring is an indispensable tool in modern cybersecurity. By leveraging automation, manual analysis, and prioritisation, organisations can effectively mitigate vulnerabilities, ensure device resilience, and protect users and vendors.

As the number of packages used in software grows, so does the number of vulnerabilities. We have seen the number of reported CVEs growing each year.

As a result, a formalised strategy to deal with them is needed. Consult Red has successfully integrated CVE monitoring and Software BOM management into client projects, enabling proactive vulnerability mitigation and ensuring compliance with cybersecurity standards.