Security Standards and Scores

CyStack VulnScan enriches findings with common vulnerability identifiers, weakness categories, scoring systems, exploitation signals, and application-security mappings. These fields help security teams speak the same language when triaging, assigning, fixing, and reporting vulnerabilities. No single field should be used alone. A finding is usually prioritized by combining technical severity, exploit likelihood, active exploitation evidence, exposure, business context, confidence, and remediation effort.

Quick Reference

Field	What It Answers	Example	Use It For
Severity	How serious is the technical impact?	Critical, High, Medium	First-pass triage and dashboards.
CVE	Which publicly disclosed vulnerability is this?	`CVE-2024-3094`	Vendor advisories, patches, threat intelligence, and reporting.
CWE	What weakness category caused this?	`CWE-89` SQL Injection	Root-cause analysis, secure coding, and prevention.
CVSS	How severe is the vulnerability under a standard scoring model?	`9.8 Critical`	Comparing technical severity across tools and vendors.
EPSS	How likely is this CVE to be exploited in the wild soon?	`0.87`, 97th percentile	Prioritizing vulnerabilities that attackers are more likely to use.
CISA KEV	Is there evidence of active exploitation?	Listed / Not listed	Urgent remediation and executive escalation.
Risk score	What should we fix first?	`92.7` (0–100)	A composite ranking score that blends several signals.
Priority	How soon should we act?	Emergency (24h), High (7d)	Setting remediation targets and SLAs.
Confidence	How sure is the detection?	`0.90` (90%)	Weighing weakly-evidenced vs confirmed findings.
OWASP Top 10	Which broad web application risk category is this?	A03 Injection	Awareness, reporting, and program-level risk grouping.
OWASP WSTG	Which testing-guide area maps to this issue?	WSTG-INPV-05	Manual validation and test planning.

Severity

Severity is VulnScan’s categorical view of technical impact and exploitability. It helps users quickly filter and sort findings.

Level	Meaning	Typical Response
Critical	A serious issue that can commonly lead to system compromise, major data exposure, authentication bypass, or remote code execution.	Review immediately and assign an owner.
High	A high-impact weakness or exposed vulnerable component that is likely to matter in real environments.	Prioritize in the next remediation cycle.
Medium	A meaningful security weakness that usually needs context, chaining, or additional conditions.	Track and fix according to risk and ownership.
Low	A lower-impact issue or hardening gap.	Fix as part of hygiene or planned maintenance.
Info	Useful security context rather than a confirmed vulnerability.	Use for investigation and scope understanding.

Severity is not the same as business risk. A High issue on an Internet-facing customer portal may be more urgent than a Critical issue on an isolated lab host.

CVE

CVE stands for Common Vulnerabilities and Exposures. It is a globally used identifier for publicly disclosed cybersecurity vulnerabilities. A CVE ID gives teams a stable name for the same vulnerability across vendors, advisories, scanners, ticketing systems, and threat-intelligence feeds. For example, a vendor advisory, a patch note, and a VulnScan finding can all refer to the same CVE-YYYY-NNNN identifier. How to read it:

A CVE identifies a disclosed vulnerability, not a weakness pattern.
A CVE does not automatically prove that your exact system is exploitable.
A CVE may affect multiple products, versions, platforms, or deployment modes differently.
A CVE may exist before all scores, patches, or exploit intelligence are complete.

How VulnScan uses it:

Maps detected products and versions to known CVEs when there is enough concrete evidence.
Adds references, severity scores, exploit intelligence, and remediation context where available.
Avoids noisy wildcard-only matches when product/version evidence is too weak.

CWE

CWE stands for Common Weakness Enumeration. It classifies the underlying type of weakness that can lead to vulnerabilities. CWE is about the root cause or weakness category. For example, SQL injection is commonly mapped to CWE-89; path traversal is commonly mapped to CWE-22. How to read it:

CWE describes the type of mistake, design weakness, or implementation flaw.
CWE is not a specific vulnerability instance.
Many different CVEs can map to the same CWE.
A finding without a CVE can still have a CWE because the issue may be a custom application weakness rather than a known vulnerable product.

How VulnScan uses it:

Groups findings by weakness type.
Helps engineering teams understand why the issue exists.
Supports OWASP Top 10 and reporting mappings.
Helps teams identify recurring secure-development problems.

CVSS

CVSS stands for Common Vulnerability Scoring System. It provides a standard way to describe and score the technical severity of a vulnerability, usually on a 0.0 to 10.0 scale. How to read it:

Range	Common Rating
9.0-10.0	Critical
7.0-8.9	High
4.0-6.9	Medium
0.1-3.9	Low
0.0	None

CVSS can include a vector string such as CVSS:3.1/AV:N/AC:L/.... The vector explains why the score was assigned, including factors such as network accessibility, attack complexity, required privileges, user interaction, and impact. How VulnScan uses it:

Displays CVSS when available from vulnerability intelligence.
Uses CVSS as one input to severity and risk prioritization.
Keeps CVSS separate from EPSS and KEV because technical impact is different from real-world exploitation likelihood.

Common misunderstanding:

CVSS is not a probability score.
CVSS is not specific to your business environment unless environmental scoring is available.
A lower CVSS vulnerability can still be urgent if it is actively exploited, exposed to the Internet, or easy to chain.

EPSS

EPSS stands for Exploit Prediction Scoring System. It estimates the probability that exploitation activity for a vulnerability will be observed in the wild over the next 30 days. How to read it:

EPSS score is usually shown from 0 to 1, or as a percentage.
Higher means exploitation is statistically more likely.
Percentile shows how the CVE ranks compared with other scored vulnerabilities.
EPSS changes over time as exploitation signals and vulnerability data change.

How VulnScan uses it:

Helps distinguish “severe but rarely exploited” from “likely to be exploited soon.”
Raises prioritization when a finding has both meaningful impact and high exploitation probability.
Supports remediation ordering when teams cannot fix everything at once.

Common misunderstanding:

EPSS does not measure technical impact.
EPSS does not know whether your exact asset is reachable or important.
EPSS complements CVSS; it does not replace it.

CISA KEV

CISA KEV refers to the Known Exploited Vulnerabilities Catalog maintained by the U.S. Cybersecurity and Infrastructure Security Agency. A CVE appears in KEV when there is evidence that it has been exploited. KEV is one of the strongest signals that a vulnerability should be treated as urgent, especially when the affected asset is exposed or important. How VulnScan uses it:

Flags findings whose CVE appears in the KEV catalog.
Uses KEV as a prioritization signal in risk scoring.
Helps teams escalate vulnerabilities that are known to be used by attackers.

Common misunderstanding:

Not being in KEV does not mean a vulnerability is safe.
KEV is about known exploitation evidence, not every possible exploit.
KEV should be combined with exposure, asset criticality, compensating controls, and patch availability.

Public PoC

Public PoC indicates that a public proof-of-concept or exploit for the vulnerability is known to exist (for example, in exploit databases, security advisories, or scan templates). How to read it:

A public PoC lowers the skill and effort an attacker needs, so it raises urgency.
“No public PoC” is not proof of safety — private or unpublished exploits may still exist.
VulnScan uses it as one prioritization signal (it adds to the risk score) alongside KEV, EPSS, and CVSS.

Template Verification

Template verification indicates whether a scan template exists and matched this finding, actively confirming the issue rather than inferring it from a version or banner. How to read it:

“Yes” means the finding was confirmed by an active check, which increases detection confidence.
“No” means the finding was inferred (e.g. from a product/version match) and may warrant manual validation.
Template verification is about detection certainty, not severity — a verified Low is still Low.

Risk Score

Risk score is a composite priority score from 0 to 100 that VulnScan computes for every finding to answer the question “what should we fix first.” Unlike CVSS, which measures only technical impact, the risk score blends several signals into a single number for ranking. It is built from the following components:

Component	Contribution	Meaning
Technical severity (CVSS)	CVSS × 8 (up to 80 points)	The base of the score. When a finding has no CVSS (common for native DAST findings), a severity floor is used instead: Critical 75, High 55, Medium 35, Low 15, otherwise 5.
Exploit likelihood (EPSS)	EPSS × 15 (up to 15 points)	Probability of real-world exploitation within the next 30 days.
CISA KEV	+10 points	Evidence of active exploitation in the wild.
Public PoC	+3 points	A public proof-of-concept / exploit exists.
Detection confidence	multiplies the whole score by 0.5–1.0	Low-confidence findings are scaled down so they do not drown out high-confidence ones (`0.5 + 0.5 × confidence`).
AI verification	× 0.85 when NOT verified	Findings not yet confirmed by an AI verification agent are reduced by 15%.

Formula:

score = (CVSS × 8 + EPSS × 15 + KEV(+10) + PoC(+3))
        × (0.5 + 0.5 × confidence)
        × (1.0 if verified, otherwise 0.85)

The result is clamped to 0–100 and is commonly read as a priority band: 75–100 (P1, fix now), 50–74 (P2), 25–49 (P3), below 25 (P4). Common misunderstanding:

The risk score is not EPSS. EPSS is only one component (exploit likelihood); the risk score combines CVSS, EPSS, KEV, PoC, and confidence.
The risk score does not automatically include asset exposure or business criticality (Internet-facing vs internal). Those remain factors you weigh manually when prioritizing.
It is a relative ranking score, not an absolute probability.

Priority

Priority is VulnScan’s recommended action ordering for a finding, expressed as a band with a suggested remediation target (SLA). It is derived from the risk score together with the strongest urgency signals — active exploitation (CISA KEV), technical severity (CVSS), and exploit likelihood (EPSS) — so teams can answer “how fast” rather than only “how bad.”

Priority	Trigger (any of)	Suggested target
Emergency	Listed in CISA KEV (known exploited)	24h
Critical	Risk score ≥ 80, or CVSS ≥ 9.0, or EPSS ≥ 0.5	72h
High	Risk score ≥ 60, or CVSS ≥ 7.0, or EPSS ≥ 0.1	7 days
Normal	Risk score ≥ 30, or CVSS ≥ 4.0	30 days
Low	Everything else	Planned / hygiene

How to read it:

Priority answers urgency (how soon to act); severity answers technical impact; risk score answers relative ranking.
The highest matching condition wins — a KEV-listed finding is always Emergency even if its CVSS is only moderate.
Targets (SLAs) are recommendations; adjust them to your asset exposure and business context.

Confidence

Confidence (detection confidence) is how sure VulnScan is that a finding is real, on a 0.0–1.0 scale (shown as a percentage). It reflects the strength of the evidence behind the detection, not the severity of the issue. VulnScan assigns confidence by detection method:

Evidence	Confidence
CPE exact-version match (CVE inferred from product + version)	0.40
CPE version-range match	0.50
CPE match plus KEV or high EPSS	0.60
TLS/SSL audit detection (testssl.sh)	0.70
Unauthenticated service access confirmed	0.85
Scan template match	0.85
Default-credential login succeeded	0.90
Scan template match with extracted data	0.95

How VulnScan uses it:

Confidence scales the risk score down for weakly-evidenced findings (0.5 + 0.5 × confidence), so version-inferred findings do not outrank confirmed ones.
A separate AI verification step can confirm a finding; unverified findings are additionally reduced by 15% in the risk score.

Common misunderstanding:

Low confidence does not mean the finding is false — it means the evidence is indirect (for example, inferred from a banner or version string rather than actively confirmed).
High confidence does not raise severity; a confidently-detected Low is still Low.

OWASP Top 10

OWASP Top 10 is a widely used awareness document for web application security risks. It groups common and high-impact web application risk areas into ten broad categories. Examples of categories include broken access control, cryptographic failures, injection, security misconfiguration, vulnerable components, authentication failures, and SSRF. How VulnScan uses it:

Maps findings to the closest OWASP Top 10 category where evidence is available.
Helps security teams communicate web application risk to developers and management.
Supports program reporting, dashboards, and trend analysis.

Common misunderstanding:

OWASP Top 10 is not a complete vulnerability list.
It is a category model, not a scanner test name.
A finding can be important even if it does not map cleanly to one OWASP Top 10 category.

OWASP WSTG

OWASP WSTG stands for Web Security Testing Guide. It is a testing methodology and reference for evaluating web application security controls. WSTG mappings help analysts understand how a finding relates to manual testing areas, such as input validation, authentication testing, session management, authorization testing, configuration testing, and business-logic testing. How VulnScan uses it:

Adds WSTG references when a finding maps to a recognized testing area.
Helps analysts validate issues manually when needed.
Helps teams align automated scan results with security testing programs.

Common misunderstanding:

WSTG is not a severity score.
WSTG mapping does not mean VulnScan ran every manual test in the guide.
It is a reference that helps explain and reproduce the testing approach.

How to Prioritize Findings

Use these signals together:

Start with Critical and High severity.
Escalate findings that are listed in CISA KEV.
Prioritize high EPSS findings when they affect exposed systems.
Use CVSS to compare technical severity across products.
Use CWE and OWASP mappings to route issues to the right engineering owners.
Use WSTG references for manual validation or deeper testing.
Confirm business impact, exposure, authentication requirements, and compensating controls.

Introduction

Getting started

Vulnerability scanning

WAF — Web Application Firewall

Automation & CLI

Security reference

Administration & operations

Quick Reference

Severity

CVE

CWE

CVSS

EPSS

CISA KEV

Public PoC

Template Verification

Risk Score

Priority

Confidence

OWASP Top 10

OWASP WSTG

How to Prioritize Findings

Official References

​Quick Reference

​Severity

​CVE

​CWE

​CVSS

​EPSS

​CISA KEV

​Public PoC

​Template Verification

​Risk Score

​Priority

​Confidence

​OWASP Top 10

​OWASP WSTG

​How to Prioritize Findings

​Official References

Quick Reference

Severity

CVE

CWE

CVSS

EPSS

CISA KEV

Public PoC

Template Verification

Risk Score

Priority

Confidence

OWASP Top 10

OWASP WSTG

How to Prioritize Findings

Official References