Skip to main content
Findings are the primary remediation objects in CyStack VulnScan. Each finding connects a weakness to an affected asset, evidence, severity, standards mapping, risk signals, and remediation guidance. For detailed explanations of CVE, CWE, CVSS, EPSS, CISA KEV, OWASP Top 10, OWASP WSTG, and severity, see Security Standards and Scores. Finding detail

​
Finding Fields

FieldMeaning
TitleHuman-readable vulnerability or weakness name.
SeverityCritical, High, Medium, Low, or Informational based on technical impact and exploitability.
Risk score0-100 score that combines severity, exploitability, intelligence, confidence, and verification signals.
ConfidenceHow strongly VulnScan believes the evidence supports the finding.
Affected assetDomain, subdomain, URL, IP, port, service, or component where the issue was observed.
EvidenceRequest/response snippet, banner, version match, service behavior, TLS detail, or verification result.
Detection sourceProduct-level source label that helps users understand the type of check.
CVE/CWEKnown vulnerability identifier and weakness category where available.
CVSSStandard severity scoring where available.
EPSSExploit prediction probability where available.
CISA KEVIndicates whether the vulnerability appears in the Known Exploited Vulnerabilities catalog.
OWASP Top 10Application risk category mapped from detector, CWE, or vulnerability class.
OWASP WSTGWeb Security Testing Guide mapping for testing and audit context.
RemediationPractical fix guidance for engineering, IT, or platform owners.
ReferencesVendor advisories, standards pages, or vulnerability intelligence references.

​
Severity and Risk Score

Severity is a categorical view of technical impact. Risk score is a prioritization signal. A High finding can receive a higher risk score when it has strong exploitability signals, public exploitation, high confidence, or verified evidence. A Critical finding can receive a lower risk score when confidence is limited or the affected component is not externally exploitable in the observed context. VulnScan uses the following signals when calculating risk:
  • CVSS base score where available.
  • EPSS probability where available.
  • CISA KEV presence.
  • Public exploit or proof-of-concept indicators.
  • Detection confidence.
  • Whether the issue was actively verified.
  • Asset and service context collected during discovery.

​
Evidence Types

Evidence depends on the vulnerability class:
  • HTTP request and response behavior.
  • Reflected or stored payload confirmation.
  • Service banner and protocol response.
  • Product and version evidence.
  • Exact or range version match against CPE/CVE intelligence.
  • TLS certificate and protocol details.
  • Exposed file, directory, panel, endpoint, or metadata.
  • Cloud storage or subdomain takeover indicators.
  • Authentication or authorization behavior.
VulnScan prefers concrete evidence and suppresses generic wildcard-only matches where they would create noisy known-CVE findings.

​
Triage Workflow

Use a consistent status workflow:
  1. Review Critical and High findings first.
  2. Confirm the affected asset and owner.
  3. Read evidence and remediation.
  4. Create an internal remediation ticket.
  5. Mark the finding as in progress if your workflow tracks ownership.
  6. Re-scan after the owner reports a fix.
  7. Close the finding only after scan evidence confirms remediation.
  8. Mark as accepted risk or false positive only with reviewer notes.

​
Standards Mapping

VulnScan maps findings to security standards so teams can connect technical issues to audit and remediation programs:
  • OWASP Top 10 2021: all ten categories are covered by mapping from detectors, CWE, and vulnerability classes.
  • OWASP WSTG: 70+ testing-guide mappings help analysts understand how the issue would be tested manually.
  • CWE: 196 CWE mappings connect findings to standardized weakness categories.
  • CVE: known vulnerable components are mapped through local vulnerability intelligence.

​
Common Finding Categories

VulnScan focuses on high-impact externally reachable risks, including:
  • Injection: SQL, command, code, NoSQL, template, and client-side template injection.
  • Cross-site scripting: reflected, stored, and DOM-based XSS.
  • Access control and authentication weaknesses.
  • SSRF, open redirect, CSRF, and insecure file upload.
  • LFI/RFI, path traversal, and sensitive file exposure.
  • HTTP request smuggling and cache poisoning.
  • Insecure headers, CORS, CSP, and clickjacking.
  • Exposed admin panels, debug endpoints, Swagger/OpenAPI, GraphQL, and actuator endpoints.
  • Cloud storage exposure and subdomain takeover.
  • Weak TLS, expired certificates, and unsafe protocol support.
  • Default credentials and unauthenticated network services.
  • Known CVEs in web, network, CMS, plugin, framework, and server components.

​
Reducing False Positives

False-positive reduction is built into multiple stages:
  • Version matches prefer exact or bounded version ranges.
  • Generic CPE matches are suppressed when they do not prove product/version exposure.
  • Duplicate findings are merged by vulnerability, host, port, and title.
  • Verified evidence is preferred over weaker duplicate evidence.
  • Confidence is shown so analysts can decide what needs manual review.
  • Re-scans can confirm whether a fix actually changed observed behavior.