# Vulnerability Management and Patching Strategies

> Chapter 5 of the Courseiva CASP-PLUS curriculum — https://courseiva.com/learn/casp-plus/vulnerability-management-and-patching

**Official objective:** 2.2 — Implement and manage vulnerability scanning, assessment, and remediation processes across the enterprise.

## Introduction

If you never check for cracks in your own house, you only discover the leak when the ceiling collapses on your sofa. That is the real-world consequence of ignoring vulnerability management. This chapter explains how organisations systematically find weaknesses in their networks, decide which ones to fix first, and apply the right patches — a core skill for the CAS-005 exam because attackers constantly scan for unpatched holes you left open.

## The Home Renovation Inspection Analogy

A house you bought six months ago. You notice a faint musty smell in the basement and a crack in the kitchen wall that wasn't there before. You call a home inspector, who walks through every room with a checklist, a moisture meter, and a flashlight. They check the roof flashing, the boiler, the window seals, the electrical panel. They find the crack is just cosmetic but the musty smell comes from a slow pipe leak behind the laundry room wall. The inspector's report ranks issues: a leaking pipe (critical, must fix now), a loose porch step (moderate, fix this month), and a flickering hallway light (low, fix when you next change a bulb).

You then schedule a plumber to patch the pipe. But the plumber notes the pipe is an old, non-standard size no longer made, so they must replace a whole section to fit modern fittings — that is a patch with a dependency. While they are at it, you ask the plumber to also tighten the porch step screws. The inspector's scan, the ranked list, and the targeted fixes mirror vulnerability management: scanning the network for weaknesses, prioritising by risk, and patching the critical flaws before attackers exploit them. Skip the basement leak, and water damage spreads through the entire foundation — just like unpatched vulnerabilities can rot an entire enterprise system.

## Core explanation

Vulnerability management is the continuous process of finding, classifying, prioritising, and fixing security weaknesses in an organisation's computers, servers, applications, and network devices. It is not a one-time check-up; it is a recurring cycle. Without it, you are effectively leaving your front door unlocked and hoping no one walks in.

Let us start with the key terms. A vulnerability is a flaw or weakness in software, hardware, or configuration that an attacker could use to gain unauthorised access or cause harm. Think of it as a hole in a fence. An exploit is the actual code or technique that uses that hole to break in. A patch is a piece of code released by the software vendor to repair that hole. Vulnerability management bundles all the activities that find holes, decide which ones are most dangerous, and apply the patches.

The process typically follows a cycle. First, you discover assets — every computer, phone, server, router, and cloud instance on your network. You cannot protect what you do not know exists. Second, you scan those assets for weaknesses using specialised tools. These tools, called vulnerability scanners (like Nessus, Qualys, or OpenVAS), compare what they find on each device against a huge database of known vulnerabilities. They generate a report listing every hole, along with a severity score, often using the Common Vulnerability Scoring System (CVSS), which ranks issues from 0 (no risk) to 10 (critical explosion risk).

Third, you assess and prioritise. Not every vulnerability needs immediate attention. A critical flaw on an internet-facing web server that stores customer credit cards demands instant action. A low-severity glitch on an internal printer that only staff can reach can wait months. Prioritisation uses several factors: the CVSS score, whether the vulnerability is being actively exploited in the wild, how valuable the affected asset is to the business, and the likelihood that an attacker can reach it from the internet.

Fourth, you remediate. This means fixing the issue. The most common remediation is patching — installing the vendor's update. But sometimes no patch exists yet, so you might apply a workaround (like blocking an IP address range on your firewall) or even remove the vulnerable service entirely. Some organisations also accept the risk if the cost to patch outweighs the potential damage, though this is rare for critical issues.

Finally, you verify that the fix worked. You rescan the same asset to confirm the vulnerability is gone. If it is not, you go back to remediation. This whole cycle repeats on a regular schedule — weekly, monthly, or quarterly — because new vulnerabilities are discovered every day. Attackers are constantly developing new exploits. A system that was secure last week might have a critical hole this afternoon.

Why does this matter for the SecurityX (CAS-005) exam? The exam tests your understanding of the entire lifecycle, not just the scanning step. You will need to know how to interpret scan reports, how to prioritise using CVSS, what factors influence risk, and how to differentiate between scanning, assessment, and remediation. You will also need to understand that patches themselves can break things. A patch that fixes one bug might introduce a new problem, so you test patches in a staging environment before deploying them across the entire company. This is called change management.

In summary, vulnerability management is proactive defence. Instead of waiting for an attacker to discover a hole, you find it first and seal it. The CAS-005 exam expects you to orchestrate this cycle across a large enterprise, not just a single home computer. You must think about scale: scanning thousands of servers, coordinating with dozens of teams, and balancing security need against business continuity.

## Real-world context

You work as a junior security analyst at a mid-sized retail company with 2000 employees, 500 servers, and 1500 laptops. It is Monday morning, and your team receives an alert from the US Cybersecurity and Infrastructure Security Agency (CISA) about a critical vulnerability in the Apache web server software that powers your company's main e-commerce website. The vulnerability has a CVSS score of 9.8 out of 10, and there is already proof-of-concept code published online. You know attackers are actively scanning for it.

Here is what happens step by step. First, your vulnerability management platform — let us call it Qualys — has an automated scan scheduled for every Wednesday night. But this is too urgent to wait. You trigger an out-of-band emergency scan targeting all web servers. The scan identifies 12 instances of Apache running the affected version. The report also flags that the patch was released by Apache two days ago.

Second, your team assesses the risk. The affected servers host the customer-facing checkout page. If an attacker exploits this flaw, they could steal credit card numbers in transit. The business impact is severe: regulatory fines under PCI DSS (the Payment Card Industry Data Security Standard), customer lawsuits, and reputational damage. You assign a priority level of 'Critical — Patch within 24 hours'.

Third, you look for a patch. Apache has published version 2.4.55 which fixes the bug. You download it and deploy it to a staging environment — a replica of your production system that is not customer-facing. Your QA team runs regression tests: does the checkout still work? Does the inventory system still sync? Does the new patch slow down page load times? They find a minor issue with session cookies. The patch's vendor posts a hotfix. You apply that too.

Fourth, your change management process kicks in. You open a change request in your IT service management tool (like ServiceNow), describing what you are patching, why, the risk of not patching, and the test results. The change advisory board meets and approves emergency deployment for that evening at 2 AM when traffic is lowest.

Fifth, you execute the deployment. Your operations team uses a configuration management tool like Ansible or SCCM to push the patched Apache version to all 12 production servers. The deployment happens in waves: first two servers, then four more, then the rest, with a manual check after each wave.

Sixth, you verify. You rescan the same 12 servers. All show the vulnerability as closed. You check the website — it loads correctly. You monitor logs for the next 48 hours for any anomaly. Finally, you document the entire event: what was found, the decision process, the patch deployed, who approved it, and the verification results. This documentation matters for audits and for your CAS-005 exam scenario questions.

The key lesson is that real-world patching is never just 'click update'. It involves coordination across security, operations, development, and management. CAS-005 tests your understanding of this entire workflow, including the exceptions — what to do when no patch exists, how to handle a vulnerable system that cannot be taken offline, and how to communicate risk to non-technical stakeholders.

## Exam focus

The CAS-005 exam tests vulnerability management and patching strategies heavily in domain 2.0, 'Cybersecurity Architecture and Operations'. Expect scenario-based multiple-choice questions where you must decide the correct sequence of actions, the appropriate remediation strategy, or the most important factor in prioritising a vulnerability. The exam will not ask you to recite patch tool names but will expect you to understand the principles.

Here are the exact concepts the exam loves to test: 

- The vulnerability management lifecycle: discovery, scanning, assessment, prioritisation, remediation, verification. You will be given a scenario and asked which step happens next or which step was skipped. 
- Common Vulnerability Scoring System (CVSS): understand that CVSS provides a numeric score (0-10) based on metrics like attack vector, attack complexity, privileges required, and user interaction. The exam may give you a CVSS vector string and ask which component is most critical. 
- Scanning frequency and scope: know that compliance requirements (like PCI DSS) mandate quarterly external and internal scans plus after any significant network change. The exam may ask about required scan intervals. 
- Credentialed vs non-credentialed scans: a non-credentialed scan (from the outside) sees what an external attacker sees. A credentialed scan (with a username and password) logs into the system and sees deeper, like missing patches and misconfigurations. The exam tests the difference. 
- Patch management vs vulnerability management: patch management is a subset of vulnerability management. Patching is one remediation method, but vulnerability management includes other options like configuration changes, access control lists, or decommissioning. 
- Change control: the exam will present a scenario where a patch breaks a critical application. The correct answer involves proper change management and backout planning. 
- Active vs passive scanning: active scanning sends probes to devices; passive scanning monitors network traffic. Know when each is used. 

Common traps the exam sets: 
- They give you a vulnerability with a high CVSS score but the affected asset is an isolated lab system with no internet access. The correct answer is not to patch immediately but to accept the risk or defer. 
- They suggest applying a patch without testing. The trap answer is 'deploy patch immediately'. The correct answer is 'test in a staging environment first'. 
- They mention a zero-day vulnerability with no patch available. The correct answer is to implement compensating controls (like a web application firewall rule or disabling the vulnerable feature), not to install a non-existent patch. 
- They confuse 'vulnerability scan' with 'penetration test'. A scan finds holes; a penetration test actively tries to exploit them. Know the distinction. 

Memorise these definitions: 
- Vulnerability: a weakness. 
- Exploit: code that uses the weakness. 
- Risk: likelihood times impact. 
- Remediation: fixing the vulnerability. 
- Mitigation: reducing the risk without fully fixing it (e.g., firewall block). 
- False positive: a vulnerability reported that does not actually exist. 
- False negative: a vulnerability that exists but was not reported. 

In exam questions, look for the answer that demonstrates a risk-based approach, not a 'patch everything' mentality. Always consider business context. If a question describes a hospital's life-support system, safety and availability may override patching speed. CAS-005 expects you to balance security with operational continuity.

## Step by step

1. **Asset Discovery** — You first identify every device, application, and cloud instance on the network. Without a complete asset inventory, you cannot scan everything. Tools like network mapping or a configuration management database (CMDB) help track what exists.
2. **Vulnerability Scanning** — You run a scanner (e.g., Nessus, Qualys) against the asset list. The scanner sends probes or uses credentials to check for known vulnerabilities by comparing software versions against a vulnerability database. You decide the scan type, frequency, and scope.
3. **Risk Assessment and Prioritisation** — You analyse the scan report. For each vulnerability, combine the CVSS score with business factors: is the asset internet-facing? Does it hold sensitive data? Is there active exploit code? Rank issues from critical to low based on actual risk, not just severity.
4. **Remediation Planning and Approval** — For the highest-risk vulnerabilities, you devise a fix. This might be applying a patch, changing a configuration, or implementing a compensating control. You document the plan, get change management approval, schedule the fix during a maintenance window, and prepare a backout plan in case something goes wrong.
5. **Remediation Execution and Verification** — You deploy the patch or fix to a small test group or a staging environment, then roll out to production. After deployment, you rescan the affected assets to confirm the vulnerability is closed. If it is not, you re-enter the remediation step. You also monitor systems for stability post-patch.

## Comparisons

### Vulnerability Scan vs Penetration Test

**Vulnerability Scan:**
- Automated tool that checks for known vulnerabilities against a database
- Produces a list of potential weaknesses, may include false positives
- Can be run frequently (daily/weekly) with minimal human effort

**Penetration Test:**
- Manual process by a security expert who actively tries to exploit weaknesses
- Validates whether a vulnerability is actually exploitable in the specific environment
- Performed less often (annually or after major changes) due to cost and time

### Credentialed Scan vs Non-Credentialed Scan

**Credentialed Scan:**
- Uses a valid username and password to log into the target system
- Provides deeper insight: sees installed patches, registry settings, and configuration files
- More accurate and fewer false positives, but requires managing credentials securely

**Non-Credentialed Scan:**
- Scans from the network without logging into the target
- Sees only what an external attacker sees: open ports, services, and banner information
- Less intrusive but may miss vulnerabilities that require internal access to detect

### Patch Testing in Staging vs Patch Applied Directly to Production

**Patch Testing in Staging:**
- Patch is installed on a non-production replica environment first
- Allows regression testing to catch compatibility issues before business exposure
- Follows change management best practices and reduces downtime risk

**Patch Applied Directly to Production:**
- Patch is installed directly on live production systems without prior testing
- Risks breaking critical applications and causing unplanned outages
- Sometimes done in emergencies, but only when risk of not patching outweighs potential breakage

### Remediation (Fix the Vulnerability) vs Mitigation (Reduce Risk Without Fixing)

**Remediation (Fix the Vulnerability):**
- Actually removes the vulnerability, e.g., applying a patch or updating configuration
- Preferred approach when a patch is available and can be safely deployed
- Permanently closes the security hole

**Mitigation (Reduce Risk Without Fixing):**
- Reduces the likelihood or impact of exploitation without fully removing the vulnerability
- Used when no patch exists, the system cannot be altered, or patching would break operations
- Examples: firewall rules, intrusion prevention signatures, disabling a vulnerable service

## Diagram

_The vulnerability management lifecycle: from asset discovery through scanning, prioritisation, patching, and verification — a continuous cycle._

```mermaid
flowchart TD
    A[Asset Discovery] --> B[Vulnerability Scanning]
    B --> C[Risk Assessment & Prioritisation]
    C --> D[Remediation Planning]
    D --> E[Change Management Approval]
    E --> F[Patch Deployment & Testing]
    F --> G[Verification Scan]
    G --> H{Vulnerability Resolved?}
    H -->|Yes| I[Document & Monitor]
    H -->|No| D
    I --> A
```

## Common misconceptions

- **Misconception:** All vulnerabilities have a patch available, so you just install it. **Reality:** Many vulnerabilities have no patch yet (zero-days) or the patch requires extensive testing to avoid breaking business systems. You must use compensating controls or risk acceptance. (Beginners assume vendors always release a fix immediately, but attackers often discover flaws before vendors do. The exam tests whether you know what to do when no patch exists.)
- **Misconception:** A vulnerability scanner finds every single security problem on a network. **Reality:** Scanners only find known vulnerabilities from their database (signatures) and can miss logic flaws, business logic errors, and zero-days. Also, they produce false positives and false negatives. (The term 'vulnerability scanner' sounds all-encompassing, so beginners trust it completely. The exam emphasises that scanning is just one part of the process and requires human analysis.)
- **Misconception:** If the patch breaks something, the best solution is to roll back the patch and not apply it again. **Reality:** You should roll back the patch temporarily, document the issue, work with the vendor or your test team to resolve the incompatibility, and then reapply the patch after testing a fix. (New IT staff often see a broken patch as 'problem solved' by removing it, but that leaves the original security hole open. The exam teaches a risk-based approach: fix the compatibility issue while keeping security posture.)
- **Misconception:** The higher the CVSS score, the more urgent the patch — always patch CVSS 9-10 first. **Reality:** CVSS is a technical severity score but does not factor in business context. A CVSS 7 vulnerability on a public-facing server with customer data can be more urgent than a CVSS 10 on an isolated lab machine. (Beginners treat CVSS as a strict priority rule. The exam tests your ability to incorporate asset value, threat intelligence, and exploitability into priority decisions.)
- **Misconception:** Once you patch a vulnerability, you can forget about it forever. **Reality:** Patching fixes the specific version flaw, but the system may still have other vulnerabilities, and new ones are discovered daily. You must rescan and repeat the cycle on a regular schedule. (The term 'patch' sounds like a permanent fix, lulling beginners into a false sense of security. The exam reinforces that vulnerability management is a continuous lifecycle.)

## Key takeaways

- Vulnerability management is a continuous cycle of discovery, scanning, assessment, prioritisation, remediation, and verification — never a one-off event.
- CVSS provides a standardised severity score from 0 to 10, but always combine it with business context (asset value, exposure, threat intelligence) to prioritise truly critical risks.
- Credentialed scans give a deeper, more accurate picture of vulnerabilities than non-credentialed scans because they can log into the system and inspect configuration and installed patches.
- Patches must always be tested in a staging environment before production deployment to prevent breaking business-critical applications.
- When no patch exists for a vulnerability (a zero-day), use compensating controls like firewall rules, intrusion prevention signatures, or application-level blocking to reduce risk.
- A vulnerability scanner is a tool, not a complete security programme — expect false positives and false negatives, and always validate findings with manual analysis.
- Change management approval is mandatory before deploying emergency patches in a well-run enterprise to ensure proper communication, testing, and backout planning.
- The goal of vulnerability management is risk reduction, not zero vulnerabilities — sometimes accepting the risk for a low-impact, low-likelihood flaw is the correct business decision.

## FAQ

**Do I need to patch every vulnerability my scanner finds?**

No. You prioritise based on risk. A high-severity vulnerability on a critical internet-facing server demands immediate action, but a low-severity flaw on an internal printer that no one uses can often be deferred or accepted as a business risk.

**What is the difference between a vulnerability scan and a penetration test?**

A vulnerability scan is an automated check that finds known weaknesses without trying to exploit them. A penetration test is a manual, authorised attempt to actively exploit vulnerabilities to see how far an attacker could get. Scans are broad; pen tests are deep.

**How often should I run vulnerability scans?**

It depends on compliance requirements and risk appetite. Many standards (like PCI DSS) require quarterly external and internal scans, plus scans after any major network change. Most mature organisations run scans weekly or monthly, with emergency scans triggered by new critical vulnerabilities.

**What if a patch breaks an important application?**

You should have tested the patch in a staging environment first. If it still breaks production, immediately roll back the patch using your backout plan, document the issue, and work with the vendor to find a compatible fix before reapplying the patch.

**What is a zero-day vulnerability and how do I handle it?**

A zero-day vulnerability is a flaw that the vendor does not yet know about and has released no patch for. You handle it by implementing compensating controls: for example, block the vulnerable feature, add a firewall rule to restrict access, or use an intrusion detection system (IDS) signature to detect exploitation attempts.

**What does 'CVSS' stand for and why does it matter?**

CVSS stands for Common Vulnerability Scoring System, a standard framework for rating the severity of a vulnerability from 0 (none) to 10 (critical). It helps you compare different vulnerabilities objectively, but you must still overlay business context to decide actual priority.

## Check your understanding

1. **What is the first step in the vulnerability management lifecycle?**

   Answer: Asset discovery — identifying all devices, applications, and cloud instances on the network so you know what to scan.

2. **Why is it important to test a patch in a staging environment before deploying to production?**

   Answer: To catch compatibility issues or regressions that could break business-critical applications, and to ensure the patch does not introduce new problems.

3. **What is the difference between a vulnerability and an exploit?**

   Answer: A vulnerability is a flaw or weakness in a system; an exploit is the code or technique used to take advantage of that vulnerability to cause harm.

4. **When a zero-day vulnerability has no patch available, what should you do?**

   Answer: Apply compensating controls such as firewall rules, disabling the vulnerable feature, or using intrusion detection signatures to reduce risk until a patch is released.

5. **What is the purpose of the Common Vulnerability Scoring System (CVSS)?**

   Answer: To provide a standardised severity score (0-10) for vulnerabilities, helping security professionals compare and prioritise fixes based on technical characteristics.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/casp-plus/vulnerability-management-and-patching