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.
Jump to a section
A simple way to picture Vulnerability Management and Patching Strategies
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
These come up on the exam all the time. Here's how to tell them apart.
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
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
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)
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
Mistake
All vulnerabilities have a patch available, so you just install it.
Correct
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.
Mistake
A vulnerability scanner finds every single security problem on a network.
Correct
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.
Mistake
If the patch breaks something, the best solution is to roll back the patch and not apply it again.
Correct
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.
Mistake
The higher the CVSS score, the more urgent the patch — always patch CVSS 9-10 first.
Correct
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.
Mistake
Once you patch a vulnerability, you can forget about it forever.
Correct
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.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
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.
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.
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.
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.
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.
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.
You've finished Vulnerability Management and Patching Strategies. Continue through the CAS-005 study guide to build a complete picture of the exam.
Done with this chapter?