Common Vulnerabilities and Exposures (CVE)

A CVE, short for Common Vulnerabilities and Exposures, is a known security vulnerability in software and hardware that is part of a publicly disclosed list of vulnerabilities. Understanding CVEs and their impact on your projects is essential for maintaining secure runtime environments.

In this document:

What is a CVE?

When a vulnerability is discovered in a software system, a Common Vulnerabilities and Exposures (CVE) identification number is created by the National Institute of Standards and Technology (NIST) and stored in the National Vulnerability Database (NVD). Each suspected vulnerability is reviewed by a CVE Numbering Authority (CNA), and if it contains a valid threat to the affected software, it is published under a unique identifier.

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 most often the result of flaws or weaknesses in software that can be exploited to gain unauthorized access, steal data, or otherwise compromise the integrity of a system. In most cases, these vulnerabilities are not intentional. For specific examples of common vulnerability causes, OWASP maintains an annual top 10 causes of vulnerabilities in web applications.

Common reasons why CVEs occur include:

  1. Lack of updates and maintenance to the underlying software. As software systems age, they may become more vulnerable to attack if they are not updated and maintained.
  2. Programming errors or oversights made when writing software. This can include errors in configuring software or implementing weak security measures.
  3. Design flaws due to poor planning, inadequate testing, or lack of consideration for potential security risks.
  4. Third-party components that introduce vulnerabilities to the affected software if they are not kept up to date.

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’s important to note that the CVSS is NOT a risk assessment. The severity rating indicates the potential impact of a vulnerability, but the actual risk to your specific project depends on factors such as:

  • Whether the vulnerable code is actually used in your application
  • The environment in which your software runs (e.g., is this a Windows-only flaw when all your software runs on macOS?)
  • Existing security controls and mitigations you have in place (such as a WAF or 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, or view, the CVEs in your current project. This should be done on a recurring basis (weekly, monthly, quarterly, etc.). Due to the evolving nature of software development, older packages and language versions may develop new vulnerabilities even if no changes have been made. Once a vulnerability is reported and assigned a CVE-ID, a previously secure package or language will now have a listed vulnerability.

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: Is this a Windows-only flaw when all your software runs on macOS?
  • 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?

After triaging the risk, you can make a more informed decision about whether remediation is necessary.

3. Decide: Remediate or Acknowledge

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

  • Acknowledgment means that the risk is low and can be accepted as part of the project. No further action is taken.
  • Remediation means taking steps to address the vulnerability, such as updating the language version, updating packages, removing unused dependencies, or implementing additional security controls in your environment.

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 Organization Security Dashboard.