CVE Reference

The Common Vulnerabilities and Exposures (CVE) system provides a standardized identifier for publicly known security vulnerabilities. Every SCA finding in ByteHide Radar includes a CVE identifier that links to the full vulnerability report, enabling teams to research, track, and communicate about specific issues using a common language.

CVE Identifier Format

Each CVE has a unique identifier following the format CVE-YEAR-NUMBER:

CVE	Description
CVE-2021-44228	Log4Shell. Remote code execution in Apache Log4j via JNDI lookups. CVSS 10.0 Critical. Affected millions of Java applications
CVE-2024-38816	Path traversal in Spring Framework. Allowed reading arbitrary files from the server. CVSS 7.5 High
CVE-2023-44270	PostCSS parsing error. Line return characters in CSS could bypass security checks. CVSS 5.3 Medium

The year indicates when the CVE ID was assigned, not necessarily when the vulnerability was discovered or patched. The CVE Program is sponsored by CISA and operated by the MITRE Corporation.

Each CVE entry contains a technical description, affected software and version ranges, a CVSS severity score, and references to advisories, patches, and related documentation.

Reading a CVE in Radar

When you open an SCA finding, the detail panel shows everything you need to assess the vulnerability:

Field	What to Look At
CVE ID	Click to open the full NVD entry. Check the publication date to understand how long the vulnerability has been known
CVSS Score	The numerical severity (0.0 to 10.0). Radar maps this to Critical, High, Medium, or Low
Affected Version	The exact version installed in your project. Compare against the fixed version to determine the upgrade path
Fixed Version	The minimum version that resolves the vulnerability. Radar recommends this as the upgrade target
Dependency Path	Whether the vulnerable package is a direct or transitive dependency. Direct dependencies are straightforward to upgrade; transitive dependencies require upgrading the parent or using resolution overrides
CVSS Vector	Breaks down exploitability and impact. See the CVSS section below for how to read this

CVSS Scoring

The Common Vulnerability Scoring System (CVSS) provides a numerical score from 0.0 to 10.0. Radar uses CVSS v3.1 scores from the NVD.

Score Ranges

Score	Severity	What It Means in Practice
9.0 - 10.0	Critical	Actively exploitable with public exploit code. Prioritize immediately. These often allow remote code execution or full data access with no authentication
7.0 - 8.9	High	Significant risk. May require specific conditions (authentication, particular configurations) but impact is severe once exploited
4.0 - 6.9	Medium	Exploitable under specific conditions. Assess whether those conditions apply to your deployment before prioritizing
0.1 - 3.9	Low	Limited impact and difficult to exploit. Address during scheduled maintenance or dependency upgrade cycles

Base Metrics

The CVSS Base Score is calculated from 8 metrics across two dimensions:

Exploitability (how easy is it to attack):

Metric	Values	What to Ask
Attack Vector	Network, Adjacent, Local, Physical	Can this be exploited remotely over the internet?
Attack Complexity	Low, High	Does the attacker need special conditions or preparation?
Privileges Required	None, Low, High	Does the attacker need credentials?
User Interaction	None, Required	Does a user need to click something or take an action?

Impact (what happens if exploited):

Metric	Values	What to Ask
Scope	Unchanged, Changed	Does the impact extend beyond the vulnerable component?
Confidentiality	None, Low, High	Can the attacker read your data?
Integrity	None, Low, High	Can the attacker modify your data?
Availability	None, Low, High	Can the attacker take your service down?

Reading a CVSS Vector

Worst case: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (Score: 9.8 Critical)

Network-accessible, low complexity, no privileges, no user interaction, high impact on all three dimensions. This is a vulnerability that anyone on the internet can exploit trivially with maximum damage.

Low risk: CVSS:3.1/AV:L/AC:H/PR:H/UI:R/S:U/C:L/I:N/A:N (Score: 1.8 Low)

Requires local access, high complexity, admin privileges, and user interaction. Only leaks limited information. Unlikely to be exploited in practice.

Assessing Real-World Risk

CVSS provides a standardized severity score, but real-world risk depends on your specific context. Use these factors alongside the CVSS score when prioritizing:

Factor	Higher Risk	Lower Risk
Exposure	Public-facing web server, internet-accessible API	Internal batch tool, no network exposure
Reachability	Your code calls the vulnerable function directly	The vulnerable code path is never executed by your application
Data sensitivity	Application handles PII, payment data, or credentials	Application processes non-sensitive public data
Exploit availability	Public exploit code exists, actively exploited in the wild	Theoretical vulnerability with no known exploit
Environment	Production with real user data	Development or staging with synthetic data

Check Exploit Availability

The NVD entry and the CVE references section link to exploit databases and security advisories. A Critical CVE with no known exploit is less urgent than a High CVE with a public Metasploit module being actively used in attacks.

Common CVE Patterns by Ecosystem

Ecosystem	Common Vulnerability Types	Notable Examples
npm	Prototype pollution, ReDoS, command injection in build tools, typosquatting and dependency confusion	minimist, lodash, ua-parser-js
NuGet	Insecure deserialization (BinaryFormatter), XXE in XML processing, deprecated cryptographic algorithms	System.Text.Json, Newtonsoft.Json
Maven	Logging framework RCE, XXE/SSRF in XML processing, Java native serialization, expression language injection (OGNL, SpEL)	Log4j (Log4Shell), Spring (Spring4Shell)
pip	Code execution during `setup.py` install, server-side template injection (Jinja2, Mako), path traversal, pickle deserialization	Jinja2, Django, Pillow

Tracking Remediation

Use the SCA tab filters to track progress:

Status	Meaning
Open	Vulnerabilities still requiring action
Fixed	Remediated, no longer detected in subsequent scans
Ignored	Accepted risks (review periodically to ensure conditions haven't changed)

For compliance reporting (SOC 2, ISO 27001, PCI DSS), Radar provides evidence of continuous vulnerability monitoring with all detected CVEs, severity levels, remediation status, and historical trend data.

Continuous Monitoring

New CVEs are published daily. Radar scans detect newly published vulnerabilities in your existing dependencies even without code changes. Automatic scanning on every push ensures continuous coverage, and manual scans via "Scan Project" catch newly disclosed CVEs between pushes.