Chapter 25: Vulnerability, Patch and Exposure Management

25.1 Why.

Welcome to Chapter 25.

I am Ravindra Bagale.

Raju had no engineering degree. He had a spreadsheet that screamed red. Four hundred rows. Every row was a CVE. Every score was high. He was ready to stop the lab and patch nothing, because patching everything by Friday was a fantasy. Guru-ji took the mouse, hid the score column, and added three new columns: who owns the asset, is it reachable, and is this weakness on a known-exploited list.

"Severity is a weather report," Guru-ji said. "Exposure is whether the door faces the street. A critical bug in a library you do not run is a story about someone else. A medium bug on a payment worker that the internet can call is your week."

Raju still wanted a single number. Guru-ji refused. "Suppose we are Paytm and a dependency in the checkout service is on a known-exploited list, and the same CVE also appears in an internal design tool nobody can route to. Those are not the same ticket. Suppose we are Swiggy and a container image in the rider app is old, but the host kernel under it is older and the reboot was postponed because lunch traffic looks like Netflix. Suppose we are Amazon and the inventory says the package is patched, and a second account still runs the old image because nobody owns that account. Suppose we are Infosys and the client asks which findings you accepted, who accepted them, and when the acceptance dies. Suppose we are BHIM UPI, WhatsApp, Zomato, or PayFast and a scanner export is treated as the risk register. A scanner names candidates. A human with an inventory decides."

Volume 1 and Volume 2 gave you design, hosts, pipelines, identity, detection, response, and evidence. This chapter is the clock. Findings age. Exposure changes. End-of-life software does not get healthier by waiting.

25.2 What.

Asset inventory and ownership. You cannot patch what you cannot name. An asset is a running thing with an owner: a host, a function, a container image, a repository, a cloud account, a mobile build, a storage bucket, a vendor appliance. The inventory row needs a name, an environment, a data class, an exposure note, and a team. Unknown owner means the finding will sit. In a lab you own, make the inventory a file in Git. In a company, the catalog from the platform team should be the same list the vulnerability team reads. Two lists that disagree are how a patched fleet still has one forgotten box. Paytm-shaped payment services and Swiggy-shaped order services belong on that list before the scanner does.

CVE, CWE, CVSS, and EPSS. A CVE is a name for a publicly tracked vulnerability. A CWE is the weakness class, such as injection or broken authentication. CVSS is a score of technical severity with a version and a vector string. Read the vector, not only the number. A network-reachable, unauthenticated weakness is a different story from a local weakness that needs a person already on the box. EPSS is a probability estimate that a vulnerability will be exploited in the wild in the near term. It is not a moral judgment and it is not a substitute for your own exposure. Use it as one input. A low EPSS on an internet-facing payment component you cannot take offline still deserves a human look. A high EPSS on a build tool that never leaves the CI network is still real, and it is still not the same emergency.

Known exploited vulnerabilities. Some catalogs, notably the known-exploited list published by defenders, mark weaknesses that have been used against real organizations. That mark outranks a theoretical score. When a finding is on that list and the asset is exposed, the SLA is the emergency lane, not the quarterly lane. You do not need a recipe for the exploit to respect the list. You need a package version, an owner, and a change window.

Dependency vulnerabilities. Chapter 12 and Chapter 13 taught scanners and SBOMs. Here the question is priority. A direct dependency you call is usually more urgent than a transitive test dependency. A vulnerability that is not reachable from your code may still be fixed, and it may wait behind one that is reachable. Record the reachability decision. Do not hide the row. Lockfiles tell you the version you actually build. A scanner that reads a wishful manifest and not the lockfile will lie. Container base images are dependencies too. Pin them. Rebuild them when the base ships a fix. An image that has not been rebuilt in a year is an inventory lie even if the application code is quiet.

Container and host packages. The same CVE can exist in the image and on the host kernel. Patching the image does not reboot the node. Patching the node does not rebuild the image. Write both down. Amazon-shaped accounts with many clusters need a rollout, not a shell loop typed at midnight. Minimal images reduce the count. They do not end the clock.

Cloud misconfiguration and exposure. A vulnerability is a weakness in software. An exposure is a reachability fact: a storage bucket open to the world, a security group that allows the internet, an admin panel without a second factor, a snapshot shared to every account. Attack-surface management is the habit of looking at yourself from the outside on systems you own: which names resolve, which ports answer, which buckets list. Do that with permission, from an account you control, against hosts you own. A misconfiguration with no CVE can still be the incident. Treat exposure findings in the same queue as CVEs, with the same owner and the same expiry.

SLAs. A service level for remediation is a promise with a number of days and a start clock. The clock should start when the finding is confirmed on an asset you run, not when a mailing list first whispered. Example bands you can adopt in a lab and argue about at work: known-exploited and internet-facing in days, not months; critical and exposed inside a short sprint; high and internal on a scheduled train; low and unreachable in a backlog that is still visible. Write the bands down. A band you do not measure is a slogan. Netflix-shaped teams already live by error budgets. A patch SLA is the security cousin. It can share the calendar with reliability. It cannot be silently dropped because the calendar looks full.

Risk-based priority. Sort with a sentence, not a sort button only. Asset criticality times exposure times exploit evidence times compensating control. Criticality is the blast: payment for Paytm or PayFast, orders for Swiggy or Zomato, messages for a WhatsApp-shaped product, identity for everything. Exposure is internet, partner, or internal. Exploit evidence is the known-exploited mark, a credible public report of use, or neither. A compensating control is a real second brake, such as a network path that is already closed, while the patch is tested. If the compensating control is "we hope," it does not change the sort.

Exceptions and acceptance. Acceptance is a decision with an owner, a reason, a compensating control, and an end date. It is not a status called "won't fix" with a blank date. Expired acceptances return to the open queue by automation. Infosys-shaped audits will ask for this list. Keep it in the same system as the findings so you cannot accept a risk the inventory forgot. Separating duties matters: the person who accepts a production payment finding should not be the only person who can deploy the vulnerable build.

Patch testing and rollout. A patch is a change. Treat it like one. Build the new image or package in the pipeline. Run the smoke tests you already trust. Ship to a slice. Watch the error budget. Then the rest. Emergency patching shortens the slice. It does not skip identity, backups, or a rollback image. Kernel and runtime patches often need a restart. A restart plan is part of the patch. Postponing every restart until a mythical quiet Tuesday is how fleets stay vulnerable while dashboards look green. Document who may call an emergency and how the next train picks up the stragglers.

End-of-life software. When the vendor stops shipping fixes, your SLA becomes "replace," not "wait for a CVE email." End-of-life operating systems, languages, and mobile OS versions are exposure even on a quiet week. Track the date the way you track a certificate expiry. A runtime you cannot upgrade is a risk acceptance with a migration project, not a permanent exception.

Metrics that matter. Count what changes decisions. Open findings by owner and by exposure. Age past SLA. Recurrence of the same CVE after you claimed it was gone. Time from vendor fix to your production deploy. Percentage of assets with an owner. Percentage of internet-facing assets scanned this week. Do not celebrate a drop in raw CVE count that you achieved by deleting the scanner job. BHIM UPI-shaped and PayFast-shaped duties care about the payment path first. Show that path as its own line so it cannot hide inside an average.

Emergency versus the train. Not every red cell is an outage you cause yourself. Emergency means: known exploited, or actively being used against assets you own, or internet-facing with no compensating control. The train means: a weekly or fortnightly rebuild where the base image, the language runtime, and the boring dependency bumps ride together. Teams that emergency-patch everything burn the error budget and then ignore the queue. Teams that have only a train will miss the week a catalog lights up. Write both paths. Name who can pull the emergency brake. Name who checks that the brake was not a pretext to skip tests. Zomato-shaped order peaks and Netflix-shaped evenings are reasons to canary a patch, not reasons to skip the year.

What "fixed" means. Fixed means the asset that serves users runs the new version. A merged pull request is a start. A green scanner on a branch nobody deployed is a rumor. A container tag that still points at the old digest is the old bug. Record the digest or the package version you observed in runtime, the way Chapter 21 taught you to trust what is running. If two regions exist, both regions count. A lab with one virtual machine can still practice the rule: the process list or the image digest must match the ticket.

Reporting without fog. A weekly note to leadership is four lines. How many exposed known-exploited findings are open. How many are past SLA. Which owner is blocked, and what decision you need. What you accepted this week and when it expires. Attach the query. Do not attach a heatmap nobody can act on. Infosys-shaped status meetings get shorter when the four lines are true. PayFast-shaped and BHIM UPI-shaped reviews should see the payment systems as a separate four lines so a quiet internal wiki cannot average them into safety.

A teaching sample: a triage row. This is a note for a lab you own. It is not a Paytm ticket.

id: LAB-2026-014
asset: lab-checkout (owner: you, internet: no, data: fake cards)
finding: CVE on libwidget 1.2, CVSS 9.8, EPSS low, known-exploited: no
reachable: yes, called from /pay in the lab app
decision: patch this week, test in lab-stage, no exception
compensating: lab security group already allows only your address

The row is the work. The spreadsheet color is not.

25.3 How.

1. Open a lab inventory file and list every host, image, function, bucket, and repo you actually run, each with an owner.
2. Mark which of those assets are reachable from the internet, from a partner, or only from inside the lab.
3. Mark which assets hold fake payment data, fake messages, or nothing sensitive, so criticality is a column.
4. Run the dependency and image scanners you already trust from earlier chapters, against that lab only.
5. Join scanner rows to inventory rows and drop nothing silently; unmatched findings get an owner of "unknown" and a due date.
6. Add the CVE name, the CWE if you have it, the CVSS vector, and an EPSS band if your source provides one.
7. Check a known-exploited catalog and flag matches; those flags outrank the raw score.
8. For each flagged row, write one sentence on reachability in your code or image, or write "not checked yet."
9. Sort the queue by exposure and known-exploited status first, then by data criticality, then by score.
10. Define three SLA bands in the same file, with day counts and the clock start.
11. Put the top reachable finding onto a branch and bump or rebuild the fixed version.
12. Run your existing tests and a small smoke test before you call it patched.
13. Deploy the fix to a lab slice, watch logs, then deploy the rest of the lab.
14. If the fix needs a restart, restart the lab instance and record that the new version is the one running, not only the one built.
15. Re-scan and show the finding gone, and keep the before and after reports as evidence.
16. For one lower finding, write an acceptance with owner, reason, compensating control, and an end date next month.
17. Add a reminder so the acceptance reopens when the date passes.
18. Note one end-of-life runtime in the lab, even if you have to install nothing new, and write a replace-by date.
19. Count open items past SLA and write that number at the top of the file.
20. Schedule the next scan on a calendar, not on memory.
21. Ask a second lab user, or a second role, to review the acceptance so you practice separation of duties.
22. Export a one-page summary a client-shaped reviewer could read: owner, exposure, SLA, exceptions.
23. Stop. Do not probe, scan, or "verify patches" on Swiggy, Paytm, Amazon, BHIM UPI, WhatsApp, Zomato, Netflix, Infosys, PayFast, or any system you do not own.

25.4 A real public incident.

Name. WannaCry ransomware outbreak, and the NHS impact in the United Kingdom.

Date. The outbreak became public on 12 May 2017. Microsoft had published security updates for the relevant Windows issue, tracked as MS17-010, on 14 March 2017, weeks before the outbreak.

Source. Microsoft's customer guidance published on 12 May 2017, and the UK National Audit Office report "Investigation: WannaCry cyber attack and the NHS," published on 27 October 2017. This chapter uses those public accounts for what failed. It does not describe how the malware spread, and it does not provide a recipe.

What happened. A destructive ransomware program spread quickly across many organizations that still ran unpatched Windows systems. In the United Kingdom, the National Audit Office later reported that the NHS was disrupted even though it was not a specifically targeted victim: appointments and operations were cancelled, and staff fell back to paper in places. The audit office also reported that the NHS had been warned about the need to patch and to manage unsupported systems, and that patches and migration were not complete everywhere. The lesson for this chapter is not a malware story. It is a queue story. A fix existed. Inventory and rollout did not finish. Exposure plus age became an incident. Organizations that had applied the March updates, or that had reduced exposure of the affected service, were in a different position from organizations that had a scanner row and no owner.

How to stop.

1. Isolate affected machines you own so the damage stops growing inside your network.
2. Preserve logs and images for the responders you have authorized.
3. Patch or take offline the remaining unpatched systems, starting with the ones that are still exposed.
4. Restore from clean backups where you must, and confirm the backup itself is not the old vulnerable build.
5. Tell the people who depend on the service, in the plain language the incident deserves.
6. Do not pay, experiment, or "test the malware" on a network you do not own.

How to prevent it again.

1. Keep an owner on every internet-facing and partner-facing asset.
2. Apply security updates on a written SLA, with a restart plan, not a best effort.
3. Treat known-exploited issues as the emergency lane.
4. Remove or isolate end-of-life systems instead of admiring their uptime.
5. Measure age past SLA, not only the count of red cells.
6. Practice the rollout on a lab you own. Do not go looking for unpatched systems on someone else's network.

This is for learning only, and only inside a system you are allowed to test.

25.5 A simple picture.

Score is one column. Exposure, owner, and the known-exploited mark decide the lane. The patch is not done until the running asset shows the new version.

25.6 A short animation.

A finding enters the queue. The clock is the SLA. The stamp is a running version, not a closed ticket with no deploy.

25.7 Conclusion.

Raju deleted the color legend and kept the owner column. Guru-ji nodded. "Chapter 8 told you a host needs patches. This chapter tells you which patch is first, and how you prove the fleet is actually running it. In Chapter 26 we stop handing every team a blank pipeline. We pave a road where the secure build is the easy build."

• Inventory and exposure outrank a lonely CVSS number.
• Known-exploited findings on reachable assets are the emergency lane.
• Acceptances expire. End-of-life software is a migration, not a shrug.
• A patch counts when the running version changed and a rescan agrees.
• WannaCry, public on 12 May 2017, is the late-patch lesson. MS17-010 was already weeks old.
• Own lab only.

END OF CHAPTER 25 MASTER CLASS