A comprehensive study guide covering scan report confidentiality and distribution, common identifiers (CVE/NVD/CWE/CAPEC/CPE/CCE), CVSS 3.1 scoring system (base/temporal/environmental metrics), vector string interpretation, true/false positives and negatives, vulnerability report validation (reconcile/correlate/compare/exceptions), and vulnerability scanners (Nessus, OpenVAS, Qualys).
Objective 2.1 — Vulnerability scanning methods and conceptsObjective 2.3 — Analyze data to prioritize vulnerabilitiesObjective 4.1 — Vulnerability management reporting and communication
1
Scan Reports — Confidentiality & Distribution
Vulnerability scan reports are colour-coded by severity (critical/high/medium/low/informational) and must be validated by an analyst before use. An unvalidated report handed directly to management is effectively useless — and potentially dangerous if its findings are acted on without context.
Treat as highly confidential
Scan reports are a blueprint for attacking your network. An attacker with your vulnerability report knows exactly which CVEs to exploit and on which hosts. Encrypt all scan reports at rest and restrict access via strict ACLs — only personnel with a valid need should see them.
Automated distribution risks
Auto-emailing scan results or sending text alerts loses confidentiality control. Email travels in plaintext by default. If automation is used, ensure results stay in a centralised encrypted repository and are manually distributed only to authorised recipients.
Manual distribution benefits
Allows the analyst to contextualise findings before briefing leadership. Instead of handing leadership a raw report, the analyst explains: "This critical vulnerability affects 50% of systems, here's why it matters for our business, and here's my recommended fix." This controls narrative and prioritisation.
Never share raw scan output without analyst review. The report identifies every vulnerability on every host. In an attacker's hands, this eliminates all guesswork. Establish strict access controls, encrypt at rest, and brief stakeholders verbally with context rather than distributing the raw file.
2
Common Identifiers — CVE, NVD, CWE, CAPEC, CPE, CCE
All major vulnerability scanners (Nessus, Qualys, OpenVAS) use the same common identifiers, allowing consistent cross-tool reference and reporting. These identifiers are all interoperable under the SCAP framework.
CVE
Common Vulnerabilities and Exposures — MITRE/NIST
Unique identifier for each specific known vulnerability. The de-facto standard since it was one of the first widely adopted schemes. Format: CVE-YEAR-NUMBER.
CVE-2017-0144 (EternalBlue/WannaCry SMB)
NVD
National Vulnerability Database — NIST
A superset of the CVE database. Adds analysis, CVSS scores, fix information, and remediation guidance. The NVD is the primary source for vulnerability intelligence. Go here when you need the full picture on a CVE.
nvd.nist.gov/vuln/detail/CVE-2017-0144
CWE
Common Weakness Enumeration
Categorises the underlying software flaws that lead to vulnerabilities — root cause analysis. A buffer overflow CWE describes the class of weakness, not a specific instance. Helps developers fix root causes before they become CVEs.
CWE-119 (Improper Memory Operations)
CAPEC
Common Attack Pattern Enumeration & Classification — MITRE
Classifies attack patterns focused on application security and exploit techniques. Similar in name to ATT&CK but different in focus: CAPEC is about technical application-level attack patterns; ATT&CK is about adversary behaviour during network intrusion.
CAPEC-66 (SQL Injection)
CPE
Common Platform Enumeration
Scheme for uniquely identifying hardware, OS, and applications. Used by Nmap's fingerprinting engine. Format: cpe:/<part>:<vendor>:<product>:<version>. Part = O (OS), A (application), H (hardware).
cpe:/o:microsoft:windows:10
CCE
Common Configuration Enumeration
Unique identifiers for configuration security issues. Enables automated checking of configuration best practices across different tools — replaces manual 50-page hardening checklists with machine-readable XCCDF-compatible automated checks.
CCE-27230-2 (Windows password length)
3
CVSS 3.1 — Score Ranges & Base Metrics
The Common Vulnerability Scoring System (CVSS) is a risk management approach to quantifying vulnerability data. It produces a score from 0 to 10.0 that enables priority-based remediation. CVSS 3.1 is the current version tested on the CySA+ exam.
Network-exploitable = most dangerous (reachable from internet). Physical access required = least dangerous.
Access Complexity (AC)
Low (L) = more dangerous · High (H) = less dangerous
Low complexity = more attackers can exploit it (script kiddies). High complexity = fewer attackers have the skill.
Privileges Required (PR)
None (N) > Low (L) > High (H) (reversed risk)
None required = most dangerous (no account needed). High required = attacker must already have admin access.
User Interaction (UI)
None (N) = more dangerous · Required (R) = less dangerous
No interaction needed = exploit runs automatically. Required = attacker must trick user (social engineering adds complexity).
Scope (S)
Unchanged (U) · Changed (C)
Changed = exploit escapes local security context and affects other components. More dangerous than unchanged.
Confidentiality (C)
None (N) · Low (L) · High (H)
High = complete loss of confidentiality (all data exposed). Low = partial/limited exposure.
Integrity (I)
None (N) · Low (L) · High (H)
High = complete loss of data integrity (attacker can modify any data). Low = limited modification capability.
Availability (A)
None (N) · Low (L) · High (H)
High = complete loss of availability (system fully inaccessible). Low = degraded performance.
Temporal Metrics (optional)
Adjust the base score over time. Three factors: Exploit Code Maturity (is there working exploit code?), Remediation Level (is a patch available?), Report Confidence (how well-confirmed is the vulnerability?). A high base-score vulnerability with a confirmed patch and widely available exploit code = act immediately.
Environmental Metrics (optional)
Adjust the base score for your specific environment. Modify CIA impact based on what matters to your organisation. A network-based vulnerability gets a lower score if the affected system isn't connected to the internet. Use the CVSS calculator at first.org/cvss/calculator/3.1 to compute adjusted scores.
Don't trust CVSS blindly. A 9.3 vulnerability that requires network access is irrelevant if the affected system has no network connectivity. The NVD score reflects the generic case — your environment may be different. Adjust Environmental metrics to reflect your actual exposure. A thinking analyst is not replaced by a number.
4
Reading CVSS Vector Strings
CVSS vector strings encode all base metric values in a compact, parseable format. When you see them in a vulnerability report, you should be able to quickly extract the most critical factors.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
AV:N = NetworkAC:L = Low complexityPR:N = No privileges neededUI:N = No user interactionS:C = Scope ChangedC:H = Confidentiality HighI:H = Integrity HighA:H = Availability High
The vector above represents a critically dangerous vulnerability — exploitable over the network, low complexity, no privileges or user interaction required, scope changed, and high impact on all three CIA triad components. This would be a 10.0 or near-10.0 CVSS score.
Exam vector string interpretation guide
Priority — overall threat
Highest base CVSS score = remediate first. If two scores are equal, check AV (network > local), AC (low > high), PR (none > high), UI (none > required). Network + low complexity + no privileges = most dangerous combination.
Priority — CIA focus
If the question asks about confidentiality: look at the C: field. C:H > C:L > C:N. Same for Integrity (I:) and Availability (A:). If protecting a database, prioritise vulnerabilities with C:H. If protecting a web service, prioritise A:H.
Priority — combined CIA
For overall CIA impact: C:H + I:H + A:H (all three high) > all three low > any single high > two lows with one N/A. Three highs = remediate first. All three none = lowest priority even if AV is Network.
Exam approach to vector strings: Scan the vector right-to-left for CIA impact first (the last three key-value pairs). Then check AV and AC for exploitability context. The question will tell you what to prioritise — overall threat, or specific CIA component. Don't just look at a single field and ignore context.
5
True/False Positives & Negatives
Every finding in a vulnerability scan must be classified into one of four categories. This is a core analyst task — an unvalidated report is not actionable. Misclassification wastes resources (false positives) or leaves you exposed (false negatives).
True Positive
Alert fired → vulnerability exists
The scanner detected a vulnerability and that vulnerability genuinely exists on the system. The scanner is correct. This is the ideal outcome — you've found a real problem. Act on it.
✓ Desired outcome — confirms a real risk to remediate
False Positive
Alert fired → no vulnerability exists
Scanner reported a Windows vulnerability on a Mac. The vulnerability doesn't actually exist there. Time-consuming to investigate — if you have 50 false positives, you waste significant analyst time. Mitigate by refining scope, tuning baselines, or adding exceptions.
⚠ Wastes analyst time — tune scanner to reduce these
True Negative
No alert → no vulnerability
Scanner found nothing and there genuinely is nothing to find. Expected result when scanning a Mac for Windows-specific vulnerabilities — no alert, no vulnerability, correct outcome. Clean bill of health for this check.
✓ Expected clean result — confirms control is working
False Negative
No alert → vulnerability exists (undetected!)
The most dangerous outcome. A vulnerability exists on the system but the scanner didn't find it. You think you're safe, but you're not. Causes: outdated feed, wrong scan type, safe mode missing an exploit. Mitigate: re-scan, different scanner, deeper scan, disable safe mode.
✗ Most dangerous — unknown exposure leaves you undefended
Mitigating false positives
Scope OS-specific
Create separate scopes for Windows, Linux, and Mac targets. Windows vulnerabilities won't appear in Linux scope scans — eliminating cross-OS false positives entirely.
Update heuristic baseline
If using heuristic scanning, update the baseline — an outdated baseline generates excessive false positives. Signature-based scanning is generally more accurate than heuristics for known vulnerabilities.
Exception management
Add recurring false positives to an exception list. A vulnerability that exists but isn't exploitable (e.g. blocked by firewall) can be added to exceptions so it stops appearing in every report.
Mitigating false negatives
Re-scan / different scanner
Run the scan again, or use a different tool (Nessus → OpenVAS → Qualys). Different scanning engines have different plugin sets and may catch what another missed.
Different scan type
Switch from non-credentialed to credentialed, or from basic to deep/full. Safe mode may be suppressing exploits that would find the vulnerability — disable safe mode for full coverage.
Update feeds
Stale vulnerability feeds = stale detection. Ensure your scanner has the latest plugins/NVTs before trusting a clean result.
6
Validating Vulnerability Reports — Four Steps
A raw scan report is a starting point, not a final answer. Every finding must be validated. The analyst adds the judgement that automated tools cannot provide — business context, asset criticality, and acceptable risk decisions.
Step 1
Reconcile the results. Classify each finding as true positive, false positive, true negative, or false negative. Scanners can misinterpret probe responses — your job is to determine if each finding is real before reporting it. This is the primary value-add of the analyst.
Step 2
Correlate with other data sources. Review system and network logs alongside the scan result. If the scanner says port 80 is open on a workstation, go check that workstation's logs — is port 80 supposed to be open? Was it opened by change management? Does the firewall corroborate or contradict the finding?
Step 3
Compare to best practices. Some findings are informational rather than critical. "Best practice: don't run web servers on workstations." If the organisation has accepted this risk (perhaps a developer workstation that runs a local test server), note it and move on. Best practice = default recommendation, not always mandatory.
Step 4
Identify and document exceptions. Any finding whose risk has been accepted or transferred by the organisation is added to the exception list. This prevents the same item appearing in every future report, allows reports to shrink over time, and avoids bringing already-decided issues back to management repeatedly.
Exception management: Exception management is a formal process for documenting systems that cannot be patched and must be excluded from compliance. Include: what asset, why the exception exists, what compensating controls are in place, how long the exception is valid (not indefinite), and what steps are needed to eventually achieve compliance. Review exceptions at every scheduled scan cycle.
7
Vulnerability Scanners — Nessus, OpenVAS, Qualys
Nessus — Tenable Network Security
Commercial scanner (free for home use). Uses plugins written in the Nessus Attack Scripting Language (NASL). Each plugin tests one specific vulnerability. Subscription required for current plugins in commercial use. Dashboard shows vulnerabilities colour-coded by severity. Clicking into a finding shows: description, solution, CVSS score, exploit availability (e.g. "exploitable with Core Impact" = widely available). If Core Impact has an exploit, assume attackers do too.
OpenVAS / Greenbone Community
Open-source fork created when Nessus went commercial. Uses Network Vulnerability Tests (NVTs). Free, web-based interface. Supports credentialed scans using service accounts. Dashboard shows: vulnerabilities by severity class (High/Medium/Low/Log), word cloud of common vulnerability themes (SSL, TLS, SSH), results filterable by host IP or CVE. Searching by CVE (e.g. CVE-2017-0144) finds all affected hosts immediately. Community edition: no scheduled scan support — start scans manually.
Qualys — Cloud-Based SaaS
Cloud-based vulnerability management. Installs sensor agents at network points that upload data to Qualys' cloud platform. Analysis is done via their web portal. Useful for geographically distributed environments. Similar dashboard to Nessus: bar charts, top vulnerabilities, most vulnerable hosts. No local infrastructure needed — cloud handles the analysis engine.
Exam approach to scanners: You don't need deep knowledge of any specific scanner's UI for the CySA+ exam. You need to: (1) know what Nessus, OpenVAS, and Qualys are and their basic distinction (commercial/open-source/cloud-SaaS). (2) Be comfortable reading a generic vulnerability scan output showing severity, CVSS score, plugin/CVE ID, description, and fix recommendation. (3) Prioritise findings based on CVSS score and CIA triad impact.
What to look for in a scan finding
Severity / CVSS
Critical (9-10) → act immediately. High (7-8.9) → act soon. Medium (4-6.9) → plan remediation. Low (0.1-3.9) → schedule. The CVSS base score is starting point — adjust for your environment.
Exploit availability
If exploit code is publicly available (Core Impact, Metasploit module, or known exploit in the wild), this elevates effective priority. A 7.0 with a working exploit in the wild > a 9.3 with no known exploit code.
Patch availability
If a patch exists (most Microsoft findings), the fix is immediate: scan → apply patch → re-scan to verify. If no patch exists (zero-day), focus on compensating controls until a patch is released.
Affected host count
A vulnerability with count = 3 (of 3 scanned machines) = all systems affected. Wide spread + high severity = highest urgency. One isolated system + low severity = lowest urgency.
Exam
Quick Reference Cheat Sheet
Common identifiers
CVE = specific vulnerability ID (CVE-YEAR-#). NVD = CVE + CVSS scores + fix info (superset). CWE = root cause weakness category (helps developers). CAPEC = application-level attack patterns (technical, not adversary behaviour like ATT&CK). CPE = hardware/OS/app ID (O/A/H). CCE = configuration best practice IDs.
CVSS 3.1 score bands
0.0 = None. 0.1–3.9 = Low. 4.0–6.9 = Medium. 7.0–8.9 = High. 9.0–10.0 = Critical. Higher score = remediate first (when all else equal). But adjust for your environment using Environmental metrics — a network-based 9.3 on an air-gapped system may be less urgent than a local 7.0 on your internet-facing server.
CVSS base metrics
AV: Network > Adjacent > Local > Physical (more exposure = more dangerous). AC: Low > High (easier = more dangerous). PR: None > Low > High (less needed = more dangerous). UI: None > Required (no user needed = more dangerous). S: Changed > Unchanged. C/I/A: High > Low > None.
Vector string reading
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H = Critical (near 10.0). Last three = CIA: C:, I:, A:. For CIA priority questions: find C:H/I:H/A:H as relevant. All three H = highest. For overall: use CVSS score or count of H values. N = None, L = Low, H = High in CIA fields.
True/False positives & negatives
True Positive = alert fired + vulnerability exists (good). False Positive = alert fired + no vuln (wastes time — tune scanner). True Negative = no alert + no vuln (good). False Negative = no alert + vuln exists (worst — you're exposed without knowing). FN mitigations: re-scan, different scanner, deeper scan, disable safe mode, update feeds.
Validation 4 steps
1 Reconcile (TP/FP/TN/FN classify each finding). 2 Correlate with logs (verify port 80 really is open on that workstation). 3 Compare to best practices (informational ≠ must-fix). 4 Add accepted/transferred risks to exception list. Exception management = formal process to document, limit duration, and compensate for exceptions.
Scanner comparison
Nessus = commercial (free home use), NASL plugins, Tenable. OpenVAS = open-source fork, NVTs, Greenbone Community (free, no scheduled scans). Qualys = cloud SaaS, installed sensors, web portal analysis. All produce: severity-colour-coded findings, CVSS scores, CVE IDs, descriptions, fix info. Exam gives generic output — know how to read any of them.
Scan report security
Reports = keys to the kingdom (blueprint for attackers). Encrypt at rest. Restrict with ACLs. Don't auto-email raw reports. Manual distribution lets analyst contextualise findings for leadership. If automation, ensure encrypted centralised storage + manual send. Report finding = description + CVSS + CVE + solution + exploit availability.