Common Vulnerabilities and Exposures (CVE)

A CVE (Common Vulnerabilities and Exposures) is a unique identifier assigned to a specific security vulnerability in software or hardware. It allows security professionals, tool vendors, and researchers to share information using a common name. Understanding CVEs and their impact on your projects is essential for maintaining secure runtime environments.

In this document:

What is a CVE?

The CVE program is overseen by the MITRE Corporation, with funding from the U.S. Department of Homeland Security. When a vulnerability is discovered, a CVE Numbering Authority (CNA)—often the software vendor themselves or a security research firm—assigns a unique ID to the flaw.

Once assigned, the vulnerability is listed in the MITRE CVE List. Subsequently, the National Institute of Standards and Technology (NIST) analyzes the CVE and adds it to the National Vulnerability Database (NVD), where it is enriched with metrics like severity scores.

CVE identifiers are composed of the prefix “CVE” followed by an ID number (e.g., CVE-2024-12345). This identifier is used consistently across public databases, security advisories, and documentation to refer to the same vulnerability. Note that not all vulnerabilities are reported to a CNA, so some vulnerabilities may not have a CVE-ID.

Why do CVEs Occur?

CVEs are the result of flaws or weaknesses in software design or implementation that can be exploited to compromise a system. In most cases, these vulnerabilities are not intentional, but rather the result of human error or complexity. For specific examples of common vulnerability causes, OWASP maintains a periodic report on the top 10 critical security risks to web applications.

Common reasons why CVEs occur include:

  • Programming Errors: Oversights in code, such as failing to validate user input (leading to SQL Injection) or mismanaging memory (leading to Buffer Overflows).
  • Design Flaws: Logical errors in the architecture of the system, such as weak authentication mechanisms or inadequate encryption planning.
  • Dependency Chains: Modern software relies heavily on third-party open-source components. If a popular library has a vulnerability, every application using it inherits that CVE.

Understanding CVE Severity

Each CVE is associated with a severity rating that indicates the level of threat it poses. In the ActiveState Platform, CVEs are color-coded for easy identification: gray/purple for “low”, yellow for “medium”, orange for “high”, and red for “critical”.

The severity of each threat is assessed using the Common Vulnerability Scoring System (CVSS), which categorizes vulnerabilities as:

  • Critical: Severe vulnerabilities that require immediate attention (red)
  • High: Significant vulnerabilities that should be addressed promptly (orange)
  • Medium: Moderate vulnerabilities that should be reviewed and prioritized (yellow)
  • Low: Minor vulnerabilities with limited impact (gray/purple)
  • Unscored: Vulnerabilities without an assigned CVSS score

It is critical to distinguish between Severity (how bad the vulnerability could be) and Risk (how likely it is to damage your specific system). High-severity CVEs might carry low risk for you if:

  • Whether the vulnerable code is actually used in your application
  • The environment differs (e.g., the CVE is a Windows-only flaw, but your software runs on Linux)
  • You have compensating controls in place (such as a Firewalls or strict input sanitization)

The Vulnerability Management Process

Managing CVEs effectively requires a systematic approach with three key steps. Creating a successful project may involve managing some risks, as not every listed vulnerability means your project is insecure. A thoughtful triage process helps you focus resources on the vulnerabilities that pose genuine risks to your specific environment.

1. Assess

The first step is to assess the CVEs in your current project. This must be done on a recurring basis. It is important to remember that while your code may not change, the threat landscape does. Security researchers constantly discover “new” vulnerabilities in “old” versions of packages. A package that was considered secure yesterday may be assigned a CVE-ID today.

2. Triage

After assessing the vulnerabilities, you need to triage the risk. We recommend starting with “Critical” severity vulnerabilities. Your triage group (or person) should:

  1. Read the CVE description thoroughly
  2. Research each CVE by clicking the link on the colored CVE tiles and reviewing it on the NIST Vulnerability Database
  3. Determine if the severity is relevant to your specific use case

Relevancy considerations include:

  • Applicability: Does the vulnerability apply to your operating system or architecture?
  • Existing mitigations: Do you have security controls in place (such as a WAF or input sanitization) that reduce the risk?
  • Usage context: Does your application actually use the vulnerable functionality?

By triaging, you convert a raw list of “Severities” into a prioritized list of “Risks.”

3. Decide: Remediate or Acknowledge

The final step is deciding whether to remediate or acknowledge the vulnerability:

  • Acknowledgment (Risk Acceptance): You determine the risk is low enough to accept, or that the cost of fixing it outweighs the benefit.
  • Remediation (Risk Mitigation): You take steps to remove or neutralize the vulnerability. This usually involves updating the affected package, removing an unused dependency, or applying a patch.

How the ActiveState Platform Helps

The ActiveState Platform can shorten the lengthy vulnerability remediation process of investigating, rebuilding, retesting, and updating runtime environments. The Platform lets you find, fix, and automatically rebuild secure runtimes in minutes by easily updating your project language version or packages, decreasing the Mean Time To Remediation (MTTR) from days to hours.

For detailed instructions on how to view and remediate CVEs in your ActiveState projects, see the documentation on viewing vulnerabilities and using the Vulnerability Dashboard.