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

​

Severity

Severity is VulnScan’s categorical view of technical impact and exploitability. It helps users quickly filter and sort findings. 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: 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.

​

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:

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

​

Official References

• CVE Program
• MITRE CWE
• FIRST CVSS v4.0
• FIRST EPSS Model
• CISA Known Exploited Vulnerabilities Catalog
• OWASP Top 10
• OWASP Web Security Testing Guide