All guides
Guide

What is a CVE and do I need to care?

A Common Vulnerabilities and Exposures ID identifies a security flaw in software so you can track, assess, and fix risks in your application dependencies.

Short answer

A CVE is a unique ID for a software flaw, and you must care when it affects a package you use in production.

Understanding vulnerability identifiers

A Common Vulnerabilities and Exposures ID, or CVE, is a unique label assigned to a security flaw found in public software. GitHub also issues identifiers known as GHSA IDs, which often link back to the same underlying issue. These records provide a shared language for developers and security tools to discuss a bug, because they ensure everyone is looking at the same technical problem. You will see these codes in your terminal when a package you use has a known weakness.

Assessing the risk to your app

Most vulnerabilities receive a Common Vulnerability Scoring System score, which ranks the severity from zero to ten. While a high score suggests a serious flaw, you only need to take action if the affected package and version are running in your environment. You can check your lockfiles to see if you use a vulnerable version, because a flaw in a tool you do not use poses no direct threat. Focus your energy on the packages that handle sensitive data.

Prioritising with the KEV catalogue

The Cybersecurity and Infrastructure Security Agency maintains a Known Exploited Vulnerabilities catalogue to highlight flaws that attackers are currently using. If a CVE appears on this list, the risk is real and you should apply the fix immediately. Most advisories tell you which versions are affected and which version contains the patch, so you can update your dependencies with confidence. Following these lists helps you ignore the noise and focus on the bugs that matter.

Reading a security advisory

An advisory typically lists the software name, the range of affected versions, and the first safe version available for download. You should look for the fixed version number in the report, then update your package manager to use that release or a later one. Semantic versioning makes this easier, because a patch update usually fixes the bug without changing how the software works. Once you update your lockfile and deploy the change, the vulnerability is no longer a threat.

What to do

  • Identify the CVE ID in your security scan
  • Check your lockfile for the affected package version
  • Review the CVSS score and KEV status to determine urgency
  • Update to the recommended fixed version.

We monitor official advisories and notify you when a package you use needs an urgent update.

Get alerts

More guides