CVEs: Identify, Prioritise, and Manage Security Vulnerabilities

Every week brings headlines about data breaches, ransomware, or zero-day exploits. Behind many of these incidents lies a common root cause: a known vulnerability that was never patched.

These known vulnerabilities are catalogued as CVEs, identifiers that help the global community track and respond to security flaws. Yet many teams still overlook them, treat them as obscure technical details, or fail to act in time.

This article explains why CVEs matter, how they work, and how to manage them effectively. Whether you are a system administrator, developer, security engineer, or auditor, understanding CVEs is critical to protecting your systems and staying ahead of attackers.

Introduction #

What is a CVE? #

A CVE (Common Vulnerabilities and Exposures) is a publicly published security vulnerability with a unique identifier. It enables the global security community to track, share, and remediate vulnerabilities using a consistent reference.

CVEs are:

• Assigned and managed by the MITRE Corporation, working together with authorised organisations called CNAs (CVE Numbering Authorities).
• Used everywhere in security advisories, vulnerability scanning tools, patch management systems, and threat intelligence platforms to consistently identify and track vulnerabilities.

Why CVEs Exist #

Before CVEs, different tools and vendors used different names for the same security vulnerabilities, causing confusion and inefficiency. CVEs were created to:

• Provide a standard way to name and reference vulnerabilities
• Help automate finding, fixing, and reporting security issues
• Improve communication and coordination between software vendors, security researchers, and defenders

This standardisation makes vulnerability management clearer, faster, and more reliable for everyone involved.

CVE Lifecycle #

1. Discovery
   A security flaw is found by someone. This could be a researcher, software vendor, or an internal team.
2. Reporting
   The vulnerability is reported to a CVE Numbering Authority (CNA), such as MITRE or the software vendor.
3. Assignment
   The CNA assigns a unique CVE ID and writes a brief description of the issue.
4. Publication
   The CVE entry is made public on CVE.org and shared with databases like the National Vulnerability Database (NVD).
5. Enrichment
   Over time, additional details are added, including severity scores (like CVSS), available patches, and links to related information.

CVE Identifier Format #

A CVE ID looks like this:

CVE-YYYY-NNNNN

• YYYY: The year the CVE was assigned or reserved
• NNNNN: A unique identifier (at least four digits, variable length)

Example:

CVE-2024-12345

Breakdown:

• CVE: Common prefix for all CVE identifiers
• 2024: Year the CVE was assigned
• 12345: Unique sequence number (not necessarily in order of discovery)

What a CVE Entry Includes #

Each CVE record usually contains:

• CVE ID (e.g. CVE-2024-12345)
• A brief description of the vulnerability
• References, such as:
  • Vendor advisories
  • Research articles
  • Public proof-of-concept (PoC) exploits
  • Patches or fixes

What CVEs do not include:

• Full technical details
• PoC exploit code itself (only links to it, if available)
• Severity ratings like CVSS scores (these come from other sources, such as the National Vulnerability Database)

Example: CVE in Practice

CVE-2021-44228 (Log4Shell)

• Description: A critical vulnerability in Apache Log4j 2 versions 2.0-beta9 through 2.14.1. It allows remote code execution by logging a specially crafted string that triggers JNDI lookups, leading to the loading of arbitrary code from attacker-controlled servers.
• Severity: Rated 10.0 (Critical) using the CVSS v3.1 scoring system.
• Impact:
  • Remote code execution (RCE)
  • Full system compromise
  • Possible lateral movement within the network
• Fix: Resolved in Log4j 2.15.0 by disabling JNDI lookups by default. Further hardening was applied in 2.16.0 and 2.17.0.
• Exploit: Public proof-of-concept exploits are widely available. The vulnerability was actively exploited in the wild shortly after disclosure.

Terminology #

Attack Vector

The attack vector describes the method or path an attacker uses to exploit a vulnerability, such as through the network, local access, physical interaction, or adjacent systems.

CNA (CVE Numbering Authority)

A CNA is an organisation authorised to assign CVE IDs to security vulnerabilities. Examples include Microsoft, Red Hat, Google, and MITRE.

CVE (Common Vulnerabilities and Exposures)

A unique identifier assigned to a known security vulnerability. It is maintained by MITRE.
The format is: CVE-YYYY-NNNNN, where YYYY is the year assigned and NNNNN is a unique number.

CVSS (Common Vulnerability Scoring System)

CVSS is a standard system that gives each CVE a numerical score from 0.0 to 10.0. This score shows how severe the vulnerability is, helping teams understand its risk level quickly and prioritise fixes.

The score of a vulnerability is based on several key factors:

• Attack vector: How an attacker can reach the vulnerability, such as over a network or only locally.
• Attack complexity: How difficult it is to successfully exploit the vulnerability.
• Privileges required: Whether the attacker needs special access or permissions to exploit it.
• User interaction: Whether the attack requires the user to take action, like clicking a link.
• Impact: How the vulnerability affects confidentiality (data privacy), integrity (data accuracy), and availability (system uptime).

CWE (Common Weakness Enumeration)

CWE is a system that categorises software weaknesses or types of vulnerabilities. It helps describe what kind of flaw exists, such as buffer overflow, race condition, or improper input validation.

Example:

• CWE-89: SQL Injection
• CWE-787: Out-of-bounds Write

Exploit

An exploit is a working tool or code that uses a vulnerability to carry out an attack, such as gaining unauthorised access or running code remotely.

Patch

A patch is a code update that fixes a security vulnerability. It is often included in regular security or software updates.

PoC (Proof of Concept)

PoC is demonstration code or a technique that shows how a vulnerability can be exploited. When publicly available, it signals a higher risk of attacks.

Privilege Escalation

Privilege escalation is a vulnerability that lets an attacker gain higher access rights or permissions than they should have, allowing greater control over the system.

RCE (Remote Code Execution)

RCE is a type of vulnerability that lets an attacker run any code they choose on a remote computer. It is often considered critical due to its severity.

Vulnerability Scanner

A vulnerability scanner is a tool that automatically finds known security weaknesses (CVEs) in systems and applications. Examples include Nessus, OpenVAS, and Nmap (with Vulners).

Zero-Day

A zero-day is a security vulnerability that attackers are actively exploiting before a fix is released or even before the vendor knows about it.

Practical Use of CVEs #

How CVEs Are Used #

CVEs serve different purposes for various stakeholders:

• System Administrators: Monitor vulnerabilities in operating systems, software, and firmware to keep systems secure.
• Security Teams: Prioritise patching and mitigation efforts based on how severe and exploitable vulnerabilities are.
• Developers: Study CVEs to learn from common coding errors and improve secure coding practices.
• Auditors and Compliance Teams: Use CVE information for security audits and to meet regulatory requirements.

Think of a CVE as a unique serial number for a security flaw. It ensures everyone (vendors, researchers, and defenders) communicates clearly and consistently about the same issue.

Why Should I Care? #

Ignoring CVEs can expose your systems to known, preventable security risks. Understanding and responding to CVEs is essential for maintaining a secure and resilient infrastructure.

Key Reasons

• Known exploits exist
  Many CVEs have public proof-of-concept exploits or are actively used by attackers. These vulnerabilities are easy targets for cybercriminals.
• Attack surface reduction
  Unpatched vulnerabilities increase the number of ways attackers can access your systems. Regularly fixing CVEs reduces your exposure.
• Compliance and audit requirements
  Regulations like ISO 27001, PCI-DSS, and NIST 800-53 require managing vulnerabilities and promptly fixing critical CVEs.
• Incident prevention
  Major security breaches often result from unpatched known CVEs. Addressing them lowers the risk of costly incidents.
• Trust and reputation
  Systems compromised by neglected vulnerabilities damage organisational trust, especially in sensitive sectors like finance, healthcare, and government.
• Automated attacks
  Bots and malware constantly scan for systems vulnerable to widely known CVEs. Being exposed makes you an easy target.
• Software supply chain risk
  CVEs impact not only your own software but also third-party libraries, packages, and hardware. Tracking them is essential for complete security.

Practical Outcomes of Ignoring CVEs

If you don’t address CVEs, your systems become vulnerable to serious problems, including:

• Data breaches: Sensitive information can be stolen or exposed.
• Ransomware infections: Attackers can lock your data and demand payment for its release.
• Privilege escalation: Attackers may gain higher access rights, allowing them to control your system.
• Service downtime: Systems can crash or be taken offline, disrupting business operations.
• Legal and financial penalties: Failure to secure systems may lead to fines, lawsuits, or regulatory actions.

In short, if you run or develop software or maintain infrastructure, paying attention to CVEs is essential to protect your systems, your users, and your organisation from harm.

Managing CVEs Effectively #

1. Document What You Have #

Keep a current and detailed list of all your assets, including:

• Systems: Servers, workstations, virtual machines, and containers
• Applications and Services: All running software and open network ports
• Installed Packages: Operating system software and updates
• Dependencies: Libraries and packages used by your applications, specific to programming languages

This helps ensure you know exactly what needs to be monitored for vulnerabilities.

2. Stay Informed About CVEs #

• Follow Trusted Sources: Subscribe to security mailing lists, advisories, and blogs such as:
  • Ubuntu Security Notices (USN)
  • National Vulnerability Database (NVD)
  • MITRE CVE database
  • Security blogs from trusted researchers and teams
• Make it a Daily Routine: System administrators should start each day by reviewing CVE updates and security news. This keeps you aware of new threats and ready to act promptly.
• Automate CVE Monitoring: Use tools or services that automatically alert you when CVEs affecting your systems are published.

3. Keep Your System Up-to-Date #

• Apply Updates Daily: Regularly update your system to fix known vulnerabilities.
• Enable Automatic Security Updates: Set up unattended upgrades to automatically install security patches.
• Reboot When Needed: Restart your system regularly, especially after kernel or critical updates, to ensure all patches take effect.

4. Reduce Attack Surface #

• Remove Unnecessary Software: Uninstall packages and applications you don’t need to lower security risks and system complexity.
• Disable Unused Services and Ports: Turn off services and close network ports that are not in use to reduce potential entry points for attackers.
• Regular Audits: Periodically review installed software and running services to ensure only essential components remain active.

5. Harden Your System #

• Use Mandatory Access Controls: Enable security tools like AppArmor, which is on by default in Ubuntu, to restrict what programs can do.
• Configure the Firewall with UFW: Set strict firewall rules:

sudo ufw enable
sudo ufw default deny incoming
sudo ufw default deny outgoing
sudo ufw limit ssh

• Explanation: This blocks all incoming and outgoing traffic by default. Only allow specific ports and services, such as SSH, to reduce attack opportunities.
• Apply Strict Permissions: Set tight file permissions and limit user privileges to prevent unauthorised access.
• Secure SSH Access: Disable root login over SSH and require strong authentication methods to protect remote access.

6. Monitor and Audit Your System #

• Use Log Monitoring Tools: Implement tools like logwatch to automatically detect and summarise suspicious activity.
• Review System Logs Regularly: Check logs frequently to spot anomalies or signs of security incidents.
• Deploy Intrusion Detection Systems (IDS): Use IDS solutions to monitor network and host activity for malicious behaviour in real time.

7. Manage CVEs Effectively #

• Prioritise by Severity and Relevance: Focus on vulnerabilities that pose the greatest risk to your environment.
• Apply Patches Promptly: Address critical and high-severity CVEs quickly to minimise exposure.
• Test Patches in Staging: Verify updates in a controlled environment before deploying to production to avoid disruptions.
• Document and Track: Keep detailed records of all CVE management activities for accountability and future reference.

Tools and Resources #

Managing CVEs is easier with the right tools and trusted information sources. These help you find vulnerability details, scan systems, and apply fixes efficiently.

Where to Find CVE Information

• CVE.org: Official CVE list managed by MITRE with unique identifiers.
• National Vulnerability Database (NVD): Detailed CVE data including severity scores for prioritisation.
• CVE Details: User-friendly site to search and filter CVEs.
• GitHub Security Advisories: Vulnerabilities in open-source projects on GitHub.

Tools to Scan for Vulnerabilities

• Nessus and OpenVAS: Network and system vulnerability scanners.
• Nmap with vulners script: Network scanner detecting vulnerable services.
• Qualys: Cloud platform for continuous vulnerability management.

Tools for Checking Software Dependencies

Third-party libraries often introduce risks. Use these tools to identify them:

• OWASP Dependency-Check: Scans code libraries for known vulnerabilities.
• Snyk and WhiteSource: Detailed reports on insecure open-source components.

Tools for Applying Patches and Configurations

Automate patching and configuration updates using:

• Ansible and Puppet: Tools for automating software updates across multiple systems.

Where to Get Security Updates and Alerts

• Vendor security bulletins (e.g., Ubuntu security notices)
• Security mailing lists and advisories
• Security news sites and forums for emerging threat information

Using these resources regularly helps you stay informed, detect vulnerabilities early, and maintain a secure environment.

Frequently Asked Questions (FAQ) #

Is daily Ubuntu updating enough to stay secure?

Daily updates are important but not sufficient by themselves. Maintaining strong security requires multiple layers, including:

• Enabling automatic security updates for critical packages
• Minimising installed software to reduce potential attack points
• Using strong authentication and enforcing strict file and user permissions
• Configuring a firewall to control incoming and outgoing network traffic
• Monitoring system logs and conducting regular security audits
• Applying system hardening tools like AppArmor

Why follow CVE blogs?

Even with automatic updates, CVE blogs add valuable context by helping you:

• Identify which vulnerabilities are actively exploited by attackers
• Detect issues that might not yet be patched or are specific to your environment
• Stay informed about zero-day threats, misconfigurations, and vendor-specific risks

Can I ignore low-severity CVEs?

In some cases, low-severity CVEs may be safely ignored if:

• The vulnerability is not exploitable in your environment
• The affected component is unused, isolated, or protected by strict controls
• Applying the patch risks system instability or disrupts critical functions

Important: Always document any risk acceptance decisions and review them regularly.

Are all CVEs dangerous?

No. Many CVEs pose a risk only under certain conditions, such as:

• Specific system configurations
• An attacker having high-level privileges
• Physical access or other rare circumstances

To determine the real threat, consider the CVSS score, exploitability, and how exposed your system is within its environment.

What does “public exploit available” mean?

It means that functional exploit code for a vulnerability is openly accessible to anyone. This raises the risk significantly, as attackers (including those with limited skills) can easily use it to attack and compromise your systems.

How often should I check for new CVEs?

• Critical systems: Check daily to respond quickly to urgent risks.
• Most environments: Weekly checks are usually sufficient for regular maintenance.
• Before software releases or deployments: Always review all dependencies for known vulnerabilities to avoid introducing risks.

To reduce manual work, use automated monitoring tools and subscribe to security advisories for timely alerts.

What’s the difference between a CVE and a CVSS score?

• CVE: A unique identifier assigned to a specific security vulnerability. It names and tracks the flaw.
• CVSS: A numerical score from 0.0 to 10.0 that measures the severity of the vulnerability, helping prioritise responses.

What’s the difference between a CVE and a zero-day?

• Zero-Day: A vulnerability actively exploited before a fix or public disclosure exists. It is unknown or unpatched when attacks begin.
• CVE: A unique identifier assigned to a vulnerability once it is publicly disclosed and tracked. Disclosure means details about the flaw are shared so vendors and users can respond.

All zero-days become CVEs after disclosure, but not all CVEs are zero-days. Zero-day refers to undisclosed, active threats. CVE refers to tracked, known vulnerabilities.

Are CVEs Limited to Specific Platforms or Software?

No. CVEs cover vulnerabilities across a broad range of technologies, including:

• Operating systems (Windows, macOS, Linux)
• Applications (web browsers, servers, databases, etc.)
• Libraries, frameworks, and software development kits
• Network devices, appliances, and firmware
• Hardware components, such as CPUs and other chip-level vulnerabilities

CVEs provide a universal way to track security issues regardless of platform or software type.

Next Steps #

• Set up CVE monitoring
  Subscribe to trusted CVE feeds and alerts relevant to your environment to stay updated on new vulnerabilities.
• Establish a patch management process
  Define clear timelines and assign responsibilities for testing and applying patches promptly.
• Integrate automation tools
  Use vulnerability scanners and patch management solutions to detect and remediate CVEs efficiently.
• Train your team
  Ensure staff understand CVE risks and their roles in prevention and response.
• Review and update policies
  Keep security policies aligned with current CVE management best practices.
• Conduct regular audits
  Verify patch status and document remediation efforts to maintain compliance and readiness.

Implementing these steps will help transform CVE awareness into effective, proactive security management.