Vulnerabilities, CVSS and Exploit Basics

• Distinguish vulnerability, exploit, CVE, CVSS and CWE
• Read a CVSS vector and explain how severity is scored
• Make patching decisions using severity, exposure and exploit predictions

• Every vulnerability management program's numbers come from this ecosystem — you must read them critically.
• CVSS 10 doesn't mean 'patch this first', it means 'this flaw is severe'; a reachable CVSS 6 can outrank an isolated CVSS 9.
• CVE/CWE language unifies vendors, scanners and advisories so analysts can correlate.
• EPSS and threat intel make scoring dynamic: attackers don't spread evenly over scores.

A pothole gets an ID (CVE), a severity label (CVSS), a map location (CWE: 'drainage flaw'), and an actual 'has someone driven into it' rate (EPSS). City crews fix by ID and severity — but the busiest route with a moderate pothole outranks a quiet street's big one.

• Disclosure: researchers/founders report; a CVE is assigned with a description, references and often a crafted CVSS vector.
• CVSS v3/v4 computes Base (attack vector, complexity, privileges, scope, C/I/A impact) then Temporal/Environmental modifiers.
• CWE categorizes the flaw class (e.g., CWE-89 SQL injection), which searchable indexes use.
• Frameworks publish feeds (NVD/OSV/OSV-scanner), scanners match installed versions against them.
• EPSS scores 'probability of exploitation in the wild' per CVE using observed data.
• Patching pipeline: severity + reachability + exploit-in-wild → priority and deadline.

• A scanner flags 'Log4Shell-related CVE in a library'; the team checks whether the vulnerable path is reachable from the internet before patching everywhere.
• Threat intel shows active exploitation of an ESXi CVE; the team force-schedules a reboot window despite the CVSS being 'only' 8.
• A monthly remediation report ranks CVEs by EPSS+exploitation, not raw CVSS, so the patchiest bugs get fixed first.

• Treat severity and risk as separate: severity (CVSS) × exposure × exploit-prediction → priority.
• Automate inventory→feed matching; manual CVE-browsing misses the point.
• Confirm reachability: a CVSS 9 behind a hard boundary may be lower priority than a CVSS 7 in the DMZ.
• Maintain a patch baseline and a documented risk-acceptance process for unpatchable systems.

• Patching purely by CVSS and letting high-EPSS low-CVSS bugs sit — attackers score differently than NVD.
• Ignoring library/transitive deps because the scanner report 'had no criticals' (transitive bugs still execute).
• Assuming 'mitigated by config' — untested, undocumented mitigations are the classic false comfort.
• Waiting for a CVE to exist to care: a zero-day against your stack is worse than a patched-feature bug.

• For weird scanner results, query the CVE's own advisory/references — scanners paraphrase and often lag.
• When two scanners disagree on a version, check package managers' lock files, not the deployed binary name.
• For 'we're fine because not reachable', prove it: firewall/test the path, and write the decision with an owner.

• Legitimate intel channels (NVD, vendor advisories, OSV) are the place to learn about flaws; never probe other systems.
• Practicing 'exploit basics' belongs only in your own lab against DVWA/your targets — never real-world hosts.