1. CVEs & CVSS Scoring
A CVE (Common Vulnerabilities and Exposures) is a unique identifier
for one specific, publicly disclosed vulnerability — CVE-2024-3094, for
instance. CVSS (Common Vulnerability Scoring System) is a standardized
way of expressing how severe one is, from 0.0 to 10.0.
CVSS 9.8 (Critical) -- CVE-2024-XXXXX
Attack Vector: Network (exploitable remotely, no local access needed)
Attack Complexity: Low (no special conditions required)
Privileges Required: None (no authentication needed to exploit)
User Interaction: None (no victim action required)
Impact: High/High/High (confidentiality/integrity/availability all affected)
# Contrast with a 9.8 that requires LOCAL access, valid credentials, AND
# user interaction -- technically a high score for its raw impact, but
# with an attack path that's meaningfully harder to actually exploit
The score alone is a starting point, not the whole answer — Week 1's risk formula (likelihood × impact) still applies. A 9.8 CVE in a library you don't actually use in production, or one requiring an attack vector your architecture doesn't expose, is a lower real risk than the raw score suggests. This is exactly why Week 10's SBOM matters here too: you need to know whether a disclosed CVE even applies to you before scoring it against your own systems.
A vulnerability with active, widespread exploitation in the wild (check the CISA Known Exploited Vulnerabilities catalog, or similar feeds) deserves urgent attention even at a moderate CVSS score, because attackers are already using it right now. A theoretically severe CVE with no known exploit and a hard-to-reach attack path can reasonably wait behind it. Score and urgency are related, not identical.
2. Prioritizing What Actually Needs Fixing First
A real vulnerability scan against any non-trivial environment returns far more findings than can be fixed immediately — the actual skill is triage, using more than just the raw severity score.
Priority = Severity x Exploitability x Exposure x Business Impact
Severity: the CVSS score itself
Exploitability: is there a known, public exploit? Active exploitation in the wild?
Exposure: internet-facing vs. internal-only vs. air-gapped (Week 1's risk lens)
Business impact: what does this system actually do -- payment processing,
an internal wiki, a decommissioned service nobody uses?
# A 7.5 CVSS finding on an internet-facing payment system, with a known
# public exploit, likely outranks a 9.1 on an internal tool with no
# known exploit and no direct internet exposure
This is also where Week 10's SBOM becomes directly actionable: when a new critical CVE drops in a widely-used library, a searchable SBOM tells you within minutes exactly which of your systems are affected — rather than starting the prioritization process with "do we even use this?"
Not every finding has a patch ready — a zero-day, or a vendor still working on a fix. Prioritization in that case shifts to compensating controls: can you restrict network access to the affected service (Week 2's segmentation), disable the vulnerable feature entirely, or add detection specifically for exploitation attempts (Week 12) while waiting for a real fix?
3. Scanning a Host and Network with Nmap
Nmap is the standard tool for discovering what's actually running on a network — open ports, services, versions — the reconnaissance step every vulnerability assessment (and, in Week 14, every penetration test) starts with.
# Scan a single host's most common 1000 ports
$ nmap 192.168.1.10
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
443/tcp open https
3306/tcp open mysql # a database port exposed on this host at all
# is worth investigating -- should it be reachable here?
# Service/version detection -- specifically what's listening, not just the port
$ nmap -sV 192.168.1.10
22/tcp open ssh OpenSSH 8.2p1 Ubuntu
80/tcp open http Apache httpd 2.4.41 # a specific, checkable version
Version detection is what turns a port scan into something Section 4's vulnerability scanners can act on — knowing exactly which Apache version is running lets you check it against known CVEs for that specific version, rather than guessing.
# Discover every live host on a /24 network, then scan each
$ nmap -sn 192.168.1.0/24 # "ping scan" -- just discover what's alive
$ nmap -sV 192.168.1.0/24 # full scan across every discovered host
# On a real network, this is exactly how you'd find the forgotten test
# server nobody remembered was still running, still on the old OS version
A port scan against a system you don't control is, in many jurisdictions, itself a potential legal issue — this is the exact same authorization boundary Week 2 and Week 7 raised, and Week 14 covers formally. Scan your own lab network, your own home network, or an explicitly authorized target only.
4. Vulnerability Scanners
Where Nmap discovers what's running, a dedicated vulnerability scanner checks discovered services against a database of known CVEs and misconfigurations, producing an actionable report instead of a raw service list.
# Configure a scan target and task in OpenVAS's web UI, then review the report:
Host: 192.168.1.10
Finding: Apache httpd 2.4.41 -- CVE-2021-XXXXX (High, CVSS 8.1)
Description: [specific vulnerability details]
Solution: Upgrade to Apache httpd 2.4.52 or later
References: [CVE link, vendor advisory]
# This is the exact "which of my systems is affected, and what's the
# concrete fix" answer that raw port-scanning alone doesn't provide
A vulnerability scanner's report is the input to Section 2's prioritization process — a long list of findings, each with a CVSS score, that still needs to be triaged against exploitability, exposure, and business impact before deciding what gets fixed this week versus this quarter.
A vulnerability scanner often flags a service version as vulnerable based purely on its version string, without confirming the specific vulnerable code path is actually reachable or that a distro-specific backport hasn't already silently patched it. Treat scan output as a prioritized list to investigate, the same caution as Week 7's automated scanner findings — not a verified, final list.
5. Building a Patch Cadence That Doesn't Break Production
Patching perfectly and instantly sounds ideal and is rarely realistic — an update can break something, and rolling it out untested to production is its own availability risk (Week 1's CIA triad, cutting the other way).
Critical, actively-exploited (CISA KEV list, or equivalent):
-> patch within 24-72 hours, expedited testing, out-of-band if needed
High severity, no known active exploitation:
-> patch within the next scheduled maintenance window (e.g. weekly)
Medium/Low severity:
-> batch into the regular monthly patch cycle, full testing pipeline
Every tier: deploy to staging first, run the automated test suite
(Week 14/15 of the React course covers exactly this kind of gate),
THEN promote to production -- never patch production directly and first
The tiers exist because treating every patch with maximum urgency is unsustainable — teams that try eventually patch nothing carefully, while teams that batch everything into a slow quarterly cycle leave actively-exploited vulnerabilities open far too long. The tiered approach matches response speed to actual risk.
Auto-applying patches on a schedule reduces the human effort of staying current, but only safely if there's an equally automated way to detect a bad patch and roll back quickly — this is a direct preview of Week 22's release-safety discussion in the React course, and Week 13's incident-response process here, both of which assume "something we deployed made things worse" is a real, planned-for scenario, not a surprise.
6. Hands-on Exercise
Scan a lab network, triage the findings, and write a patch cadence
Run real scanning tools against a network you control, then apply this week's prioritization framework to the actual results.
Part 1 — Discover and scan:
- Set up a small lab: your own home network, or a couple of local VMs on a private virtual network (deliberately including at least one older/unpatched image, e.g. an older Ubuntu or a vulnerable-by-design VM like Metasploitable).
- Run
nmap -snagainst the lab subnet to discover every live host, thennmap -sVagainst each to identify open ports and service versions. - Install OpenVAS (or an equivalent open-source scanner) and run a full vulnerability scan against your lab hosts.
- Export or record the top 10 findings by CVSS score.
Only scan hosts on your own private network/lab — the exact authorization boundary from Section 3. Metasploitable and similar intentionally-vulnerable VMs exist specifically so you have safe, legal, realistic scan targets to practice against.
Part 2 — Triage using more than raw severity:
- Take your top 10 findings and re-rank them using Section 2's fuller framework (severity × exploitability × exposure × business impact), not just raw CVSS — write one sentence per finding justifying its new rank.
- Identify at least one finding whose priority changed meaningfully between "raw CVSS rank" and "full framework rank," and explain why.
- For your #1 priority finding, look up whether a patch is actually available, and if so, what it is specifically.
Part 3 — Write a patch cadence:
- Using Section 5's tiered structure, write a patch cadence policy for a hypothetical small company's fleet of servers — specific timeframes per tier, and where the CISA KEV list (or equivalent) fits into deciding tier assignment.
- Describe, concretely, what "testing before production" would look like for a critical patch that needs to go out in 24-72 hours — what's the minimum testing that's still responsible under that time pressure?
"Deploy straight to production with no testing" is never the right answer, even under 24-hour urgency — the minimum viable testing is usually a smoke test confirming the service starts and its core health check passes, deployed to one instance first (a canary) before the full fleet, not skipped entirely.
7. Knowledge Check
Four quick questions. Expand each to check your answer.
Q1
A CVE has a CVSS score of 9.8, but requires local access and valid credentials to exploit. Should it automatically be your #1 priority over a 7.5 that's remotely exploitable with no authentication?
A CVE has a CVSS score of 9.8, but requires local access and valid credentials to exploit. Should it automatically be your #1 priority over a 7.5 that's remotely exploitable with no authentication?
Not automatically. CVSS measures severity given successful exploitation, but the attack path matters for real-world risk — a vulnerability requiring local access and valid credentials has a meaningfully smaller pool of potential attackers than one exploitable remotely with no authentication at all. Priority should weigh exploitability and exposure alongside the raw score, not the score in isolation.
Q2
Why does knowing whether a CVE is on a list of actively, currently exploited vulnerabilities (like CISA's KEV catalog) change how urgently it should be patched?
Why does knowing whether a CVE is on a list of actively, currently exploited vulnerabilities (like CISA's KEV catalog) change how urgently it should be patched?
Active exploitation in the wild means real attackers are, right now, actively scanning for and exploiting this specific vulnerability — the theoretical risk has become a concrete, ongoing one. A high-severity vulnerability with no known exploit is still worth fixing, but doesn't carry the same immediate urgency as one attackers are demonstrably already using.
Q3
Why does nmap -sV (version detection) matter more for vulnerability management than a plain port scan?
Why does nmap -sV (version detection) matter more for vulnerability management than a plain port scan?
A plain port scan tells you a port is open and roughly what kind of service is likely running there. Version detection identifies the exact software and version — the specific piece of information needed to check against known CVEs for that exact version. "Port 80 is open" isn't actionable on its own; "Apache 2.4.41 is running on port 80" can be checked against a specific vulnerability database.
Q4
Why is a tiered patch cadence generally better than either "patch everything immediately" or "batch everything into one slow quarterly cycle"?
Why is a tiered patch cadence generally better than either "patch everything immediately" or "batch everything into one slow quarterly cycle"?
Patching everything immediately, with no testing time, risks breaking production and trades one availability risk for another. Batching everything into one slow cycle leaves genuinely critical, actively-exploited vulnerabilities open far longer than the risk justifies. A tiered cadence matches response speed to actual urgency — fast for critical/actively-exploited issues, more measured for lower-risk ones — balancing both risks instead of ignoring one.