Vulnerability Management, Monitoring and Incident Response

Introduction

Web and application security is not achieved by removing a single defect or deploying a single security product. It is an operational capability that continuously connects knowledge of assets, discovery of weaknesses, risk-based decision-making, telemetry, incident handling and organisational learning. Vulnerability management identifies and reduces exploitable weaknesses; monitoring provides evidence about what systems and users are doing; incident response coordinates action when preventive controls fail.

The strategic challenge is prioritisation. A vulnerability with a high technical severity may affect an isolated development server, while a moderately rated flaw in an internet-facing payment service may present far greater business risk. Effective practitioners therefore combine technical evidence with asset criticality, exposure, exploit intelligence, compensating controls and business impact.

This chapter presents a lifecycle for establishing asset inventories, triaging findings, prioritising remediation, managing disclosure and exceptions, monitoring applications, detecting attacks, and coordinating containment, recovery and lessons learned.

Learning objectives

By the end of this chapter, a learner should be able to:

1. Design an asset and software inventory suitable for vulnerability management.
2. Explain the role and limitations of CVSS and combine it with business context.
3. Prioritise remediation using evidence, exposure and exploitability.
4. Manage vulnerability disclosure, risk acceptance and exceptions ethically.
5. Select useful application telemetry and distinguish signal from noise.
6. Describe detection, containment, eradication, recovery and post-incident learning.
7. Evaluate an incident response process through metrics, governance and a practical case.

1. Vulnerability management as a lifecycle

A vulnerability is a weakness in a system, component, process or control that can be exploited to compromise confidentiality, integrity or availability. Vulnerability management is the repeatable process of discovering, validating, prioritising, treating and verifying such weaknesses. It is broader than vulnerability scanning. Scanners produce findings; management produces decisions and reduced risk.

A mature lifecycle contains the following activities:

1. Prepare and govern: define ownership, scope, risk appetite, service-level targets and escalation routes.
2. Discover and inventory: identify applications, hosts, cloud resources, APIs, identities, data stores, dependencies and responsible owners.
3. Assess: use scanning, code analysis, penetration testing, threat intelligence, vendor advisories and reports from researchers.
4. Validate and triage: remove false positives, confirm affected versions, determine exploitability and assess business context.
5. Treat: remediate, mitigate, transfer, avoid or formally accept the risk.
6. Verify: retest fixes, confirm configuration changes and ensure that a replacement component is not vulnerable.
7. Measure and improve: analyse trends, recurring causes, overdue work and the effectiveness of controls.

The lifecycle is iterative. New deployments, dependencies, vulnerabilities and attack techniques continually change the risk picture.

Asset visibility and ownership

An inventory should answer four questions: What exists? Where is it? What does it support? Who is accountable for it? Useful attributes include a unique identifier, hostname or cloud resource ID, environment, internet exposure, business service, data classification, owner, technology stack, software versions, dependencies, authentication method and lifecycle status.

An inventory that lists only servers is inadequate for modern applications. It should include source repositories, build pipelines, containers, serverless functions, APIs, mobile applications, third-party services, certificates, secrets stores and significant open-source packages. Relationships are important: a vulnerable library may be harmless in one service but dangerous when used in an internet-facing authentication endpoint.

Ownership must be operational rather than merely administrative. The service owner is accountable for business risk; the technical owner coordinates implementation; security validates risk and control evidence; procurement and legal teams may manage supplier obligations. Unowned assets are especially dangerous because findings remain unresolved and incident communications fail.

Asset criticality

Criticality should be determined by consequences, not popularity. A useful classification considers:

• confidentiality of the information processed;
• integrity requirements, including transaction correctness;
• availability and recovery-time requirements;
• regulatory and contractual obligations;
• dependency relationships and concentration risk;
• public exposure and user population.

A low-volume internal system can still be critical if it controls privileged access or supports a safety-related process. Criticality should be reviewed when architecture, data, ownership or business use changes.

2. Finding quality and triage

A security finding is not automatically a vulnerability. Triage establishes whether the finding is real, relevant and actionable. The analyst should confirm the affected asset, software version, vulnerable configuration, attack preconditions, evidence source and potential impact.

Sources of findings

Common sources include authenticated and unauthenticated dynamic scanning, static application security testing, software composition analysis, infrastructure-as-code scanning, container scanning, penetration testing, bug-bounty reports, threat intelligence and vendor notifications. Each source has characteristic blind spots. Static analysis may identify theoretically dangerous code without runtime reachability; dynamic scanning may miss unauthenticated paths; dependency tools may report a vulnerable package that is not loaded or reachable.

Findings should be deduplicated. The same library flaw may appear in many reports, while one application-level weakness may be reported by several tools. A central record should preserve evidence, affected versions, references, dates, status, owner and remediation history.

CVSS and its proper use

The Common Vulnerability Scoring System (CVSS) provides a standardised technical severity assessment. Its base metrics describe characteristics such as attack vector, attack complexity, privileges required, user interaction, scope, confidentiality impact, integrity impact and availability impact. Temporal and environmental considerations can refine the assessment when supported by the applicable CVSS specification.

CVSS is valuable because it improves consistency and communication. It is not a probability of exploitation, a monetary loss estimate or a complete business-risk score. A high CVSS score does not prove that exploitation is occurring, and a medium score does not imply low organisational risk.

Triage should therefore combine CVSS with contextual factors:

A practical prioritisation score can be used as an internal decision aid, but it must not be confused with CVSS. For example, an organisation may use a qualitative or ordinal matrix in which technical severity, exposure, exploit evidence and business criticality are separately rated. The weights should be approved by governance and reviewed against incidents and remediation outcomes.

A simple illustrative risk model is:

where R is a relative risk indicator, L is the assessed likelihood of successful harmful exploitation, and I is the assessed business impact. This is not a universal probability equation: the values may be ordinal categories rather than measured quantities. It is applicable only when the organisation defines consistent scales and explains how the result informs decisions.

A useful operational metric is mean time to remediate (MTTR):

Remediation time should be measured from an agreed start point, such as validated detection or ticket creation, to verified closure. Units must be consistent, such as days. MTTR can be misleading if teams close easy findings while difficult critical findings remain open; it should therefore be segmented by severity, business service and age.

Prioritisation example

Suppose an organisation has three validated findings:

Finding B has the highest technical rating, but Finding A may deserve the shortest deadline because exploitation is observed and the service is publicly exposed. Finding C demonstrates why business impact can elevate a medium technical rating. The decision should be documented, not left to informal intuition.

3. Remediation and exception management

Treatment options include:

• Remediation: patch, upgrade, modify code, remove a feature or correct configuration.
• Mitigation: reduce exploitability through access control, segmentation, virtual patching, rate limiting or monitoring.
• Retirement: decommission an unnecessary asset or component.
• Transfer: place defined responsibilities with a supplier or insurer, without assuming that liability and risk disappear.
• Acceptance: knowingly retain the risk through an authorised, time-bounded decision.

Remediation must be verified. A ticket marked “patched” is not evidence that the vulnerable code is absent. Verification may involve rescanning, version validation, test execution, configuration review or a focused retest. The process should also check that the patch did not introduce authentication, availability or compatibility problems.

Exceptions and risk acceptance

An exception is justified only when the normal control cannot currently be met and the residual risk is understood. A sound exception record states:

1. the asset, vulnerability and affected business service;
2. evidence supporting the assessment;
3. business reason for delay;
4. compensating controls;
5. residual risk and possible consequences;
6. accountable risk owner and approving authority;
7. expiry date, review date and remediation plan.

Exceptions should not be indefinite. Automatic expiry, escalation of overdue reviews and restrictions on accepting repeated exceptions help prevent temporary decisions becoming permanent weaknesses. Risk acceptance belongs to the accountable business owner, within delegated authority; security personnel should advise and challenge rather than silently absorb business accountability.

4. Coordinated vulnerability disclosure

Responsible disclosure provides a structured route for researchers, customers and other parties to report weaknesses. An organisation should publish a security contact, supported communication channel, expected response times, safe-harbour language where appropriate, and rules for testing production systems.

A disclosure process normally includes acknowledgement, validation, severity assessment, assignment of an owner, mitigation, communication with the reporter, coordinated remediation and closure. The organisation should avoid requesting unnecessary personal information and should protect reporter confidentiality. Legal and public-relations teams should be involved when disclosure affects customers, regulated data or contractual duties.

Disclosure decisions must balance safety and transparency. Suppressing credible information can leave users exposed, while premature publication may enable exploitation before a fix is available. Relevant laws, regulatory notification duties, contractual terms and the interests of affected users must be considered. A vulnerability report is not proof of malicious intent; professional handling reduces adversarial escalation.

5. Application telemetry and monitoring

Monitoring turns system activity into evidence for prevention, detection and investigation. Telemetry should be designed around questions rather than collected indiscriminately. Examples include:

• Who authenticated, from where, using which method, and with what result?
• Which sensitive objects or administrative functions were accessed?
• Were there unusual changes to privileges, payment details or application configuration?
• Which requests produced errors, abnormal latency or suspicious sequences?
• Which build, dependency or infrastructure change preceded the event?

Important telemetry sources include web and API access logs, identity-provider events, application security logs, database audit records, cloud control-plane logs, endpoint telemetry, firewall and WAF events, container and orchestration logs, CI/CD records, and vulnerability-management data.

Quality characteristics

Useful telemetry is attributable, timely, tamper-resistant, searchable and proportionate. Events should include a timestamp with a known time standard, source, actor or service identity, action, target, outcome, correlation or request identifier, and relevant risk context. Sensitive values such as passwords, session tokens and full payment-card data must not be logged.

Centralised collection supports correlation and retention management. Access to logs must be restricted and audited because logs may contain personal or confidential information. Time synchronisation is essential: inconsistent clocks can make a sequence appear impossible or obscure the relationship between attacker actions and system changes.

Detection engineering

A detection rule should specify the behaviour of interest, data source, threshold or sequence, severity, response owner and test method. Behavioural detections are usually stronger than isolated indicators. For example, a successful login from a new location is weak evidence alone; a new location followed by privilege elevation, bulk export and disabling of alerts is much stronger.

Detection quality can be discussed using precision and recall. In a defined evaluation set:

Here, TP is the number of true positives, FP false positives, and FN false negatives. Precision describes how many alerts are useful among alerts raised; recall describes how many relevant events are detected. These measures require a labelled or investigated set and can change with thresholds. Increasing sensitivity may improve recall while reducing precision and increasing analyst workload.

Monitoring should not be judged solely by the number of alerts. Excessive false positives create alert fatigue, while silent failures create false confidence. Detection testing, adversary emulation, purple-team exercises and review of real incidents help establish whether controls work.

6. Incident response

Incident response is the organised capability to prepare for, detect, analyse, contain, eradicate and recover from security incidents. An event is an observable occurrence; an alert is an event or pattern requiring review; an incident is an event assessed to threaten confidentiality, integrity or availability and requiring coordinated action.

Preparation

Preparation includes an incident-response policy, roles, contact lists, severity criteria, communication channels, forensic readiness, backups, legal guidance, supplier contacts and exercises. Roles may include incident commander, technical lead, communications lead, legal or privacy adviser, business owner and evidence custodian. One person may hold several roles in a small organisation, but responsibilities should remain explicit.

Runbooks should exist for common scenarios such as account takeover, injection attacks, exposed secrets, ransomware, data exfiltration, supply-chain compromise and cloud credential abuse. They should contain decision points, not rigid assumptions. A runbook that instructs staff to delete a compromised host immediately may destroy evidence and prevent understanding of the attacker’s access.

Detection and analysis

Analysts establish what happened, when it began, which accounts and assets were involved, how the attacker gained access, what actions occurred and whether persistence or lateral movement exists. Evidence should be preserved with appropriate access control and chain-of-custody records. The investigation should distinguish confirmed facts, credible hypotheses and unknowns.

Severity should consider affected data, business service, attacker control, propagation potential, regulatory duties, safety implications and duration. Escalation thresholds should be defined in advance, while allowing the incident commander to seek expert judgement.

Containment, eradication and recovery

Containment limits harm. Short-term actions may include disabling a token, blocking a malicious route, isolating a host, restricting an API or applying a temporary rule. Long-term containment addresses the underlying access path while maintaining reliable business operations.

Eradication removes persistence and the root cause: compromised credentials are rotated, vulnerable code is fixed, malicious accounts are removed and insecure configurations are corrected. Recovery restores trusted service from verified systems or backups, increases monitoring and confirms that business processes function correctly. Returning a compromised system to production without understanding the initial access path risks reinfection.

Communication should be accurate, need-to-know and coordinated. Customers and regulators may require notification within defined timeframes. Public statements should avoid speculation and should not expose further weaknesses. Employees should receive practical guidance without blame-oriented language.

Lessons learned

A post-incident review should ask which controls failed, which worked, how long detection and containment took, whether decisions were timely, and what systemic changes are required. It should examine architecture, identity, deployment practices, supplier dependencies, training and governance—not merely the individual who made the final mistake. Actions need owners, deadlines and verification. Findings should feed vulnerability priorities, detection rules, architecture decisions and future exercises.

Useful response metrics include time to detect, time to acknowledge, time to contain, time to recover, percentage of incidents with complete timelines, and recurrence rate. Metrics require clear definitions; otherwise comparisons across teams are unreliable.

7. Integrated case study: illustrative payment API incident

Background

The following is a fictional illustrative case. Meridian Retail operates a public payment API and an internal customer-support portal. Its inventory identified the API as a critical service because it processes regulated personal and transaction data. The organisation used dependency scanning, centralised logs and a 24-hour target for actively exploited critical vulnerabilities.

Problem

A supplier advisory identified a vulnerable API framework. The vulnerability was rated high by CVSS, but exploitation evidence was initially uncertain. The dependency scanner reported the framework in several services, including the payment API and a low-value internal test application. The first asset mapping was incomplete and did not clearly identify the API owner.

Two days later, monitoring detected an unusual sequence: repeated requests to an error-handling endpoint, a successful service-account authentication from an unfamiliar network, and a large increase in customer-record queries. The events were separated across API, identity and database systems, so the initial alert was classified as medium severity.

Analysis

The security team correlated request identifiers, identity events and database audit logs. It confirmed that the vulnerable framework was reachable in the payment API and that the service account had excessive read access. The attacker had queried customer records but evidence did not yet establish whether data had been copied externally.

The technical CVSS rating alone did not capture the situation. Public exposure, active suspicious behaviour, critical business function, sensitive data and excessive privileges increased urgency. The test application remained a lower operational priority, although it was removed from network access as a precaution.

Approach and solution

The incident commander initiated the response plan. The team first restricted the affected endpoint and applied a tested virtual patch at the edge. It disabled and rotated the service-account credentials, reduced database permissions, and increased logging for the affected API. Rather than immediately destroying the host, the team preserved relevant evidence and captured a forensic image according to its procedures.

Developers upgraded the framework and deployed the change through a controlled pipeline. Security retested the endpoint and conducted focused review of adjacent services. The database team searched for anomalous queries and compared records with outbound traffic. Legal and privacy specialists assessed notification obligations. Customers were informed only after facts were verified and communications were coordinated.

Outcome

The API was restored with the patched framework, least-privilege database access and new detection rules for abnormal service-account behaviour. Investigation found unauthorised queries but no conclusive evidence of large-scale external transfer. The organisation nevertheless treated the exposure seriously, documented uncertainty and completed the required risk assessment.

Learning points

The incident demonstrated that asset ownership and dependency reachability are essential. It also showed why CVSS must be combined with exposure and business context, why cross-system correlation improves detection, and why evidence preservation matters during containment. The post-incident programme added automatic software inventory from build pipelines, service-account review, an owner field required before production deployment, and an exercise involving legal and communications teams.

8. Governance, ethics and contemporary developments

Vulnerability management involves power over systems, users and researchers. Testing must be authorised and proportionate. Analysts should protect personal data in logs and reports, avoid unnecessary collection, and disclose weaknesses in ways that reduce harm. AI-assisted code analysis and alert triage can improve scale, but generated findings may be inaccurate, incomplete or biased toward well-represented technologies. Human validation remains necessary, especially for high-impact decisions.

Software supply-chain risk is increasingly significant. Organisations should maintain component inventories, verify build provenance, protect signing keys, review supplier advisories and define contractual notification obligations. Cloud and containerised environments require short-lived assets and automated discovery because static inventories become stale quickly.

Automation should support, not conceal, accountability. Automatic patching is valuable for well-tested low-risk components, but emergency changes to critical payment or safety systems require rollback plans and controlled validation. Likewise, an automated risk score should explain its inputs and permit expert review.

9. Best-practice implementation guide

An organisation beginning or improving the capability should:

1. Establish a continuously updated inventory with accountable owners.
2. Classify services by data, availability, regulatory and dependency impact.
3. Integrate scanning, code, dependency, cloud and supplier findings.
4. Validate important findings before assigning remediation deadlines.
5. Use CVSS as technical evidence, not as the complete business-risk decision.
6. Prioritise active exploitation, public exposure and critical services.
7. Set deadlines by risk category and escalate overdue work.
8. Require evidence for closure and time-bound approval for exceptions.
9. Design telemetry around investigative questions and protect sensitive logs.
10. Test detection and response through exercises and real-world review.
11. Preserve evidence while containing incidents safely.
12. Convert lessons learned into funded, owned and verified improvements.

Challenges and limitations

No inventory is perfectly complete, particularly in environments containing shadow IT, ephemeral cloud resources and supplier-managed services. Scanners have false positives and false negatives, while exploit intelligence may be delayed or incomplete. CVSS provides comparability but cannot represent every business dependency. Metrics such as MTTR can encourage superficial closure if quality is ignored. Monitoring can create privacy risk and costly data volumes. Incident playbooks can become obsolete as architecture changes. Finally, remediation competes with feature delivery and operational stability; effective governance must make these trade-offs visible rather than pretending that all risk can be eliminated.

Chapter Summary

Vulnerability management is a continuous, governed lifecycle that begins with accurate asset visibility and ends with verified risk reduction. Asset inventories must include applications, dependencies, cloud resources, identities and owners. Findings require validation and contextual triage. CVSS standardises technical severity, but exposure, exploit evidence, reachability, asset criticality and business impact determine practical priority.

Remediation may involve fixing, mitigating, retiring, transferring or formally accepting risk. Exceptions must be documented, approved, time-limited and reviewed. Coordinated disclosure protects users and supports constructive relationships with researchers.

Monitoring provides attributable, timely and protected telemetry. Effective detection correlates behaviour across applications, identities, infrastructure and data systems. Incident response requires preparation, analysis, containment, eradication, recovery and lessons learned. The illustrative payment API case showed how dependency reachability, excessive privilege, cross-system correlation and evidence preservation shape outcomes. Strategic maturity comes from integrating these activities into engineering, governance and organisational learning.

Key Terms

Asset inventory: An authoritative record of technology resources, services, ownership and relevant attributes.

Attack surface: The collection of reachable interfaces, components and paths that may be targeted.

CVSS: A standard framework for expressing the technical severity characteristics of a vulnerability.

Compensating control: An alternative measure that reduces risk when the preferred control is unavailable.

Containment: Actions that limit the scope or impact of an ongoing incident.

Detection rule: A defined condition or behavioural pattern that generates an investigative alert.

Exception: A formally approved, time-bounded departure from a required security control.

Exploitability: The degree to which a weakness can be successfully used under stated conditions.

False positive: An alert or finding incorrectly identified as a real security problem.

Incident: A security event assessed to require coordinated response because it threatens security or operations.

Mean time to remediate: The average elapsed time from an agreed detection point to verified resolution.

Mitigation: A measure that reduces likelihood or impact without necessarily removing the underlying weakness.

Precision: The proportion of raised alerts that are true positives in a defined evaluation set.

Recall: The proportion of relevant events detected in a defined evaluation set.

Residual risk: The risk remaining after controls or treatment have been applied.

Risk acceptance: An authorised decision to retain a known risk under defined conditions.

Telemetry: Recorded technical observations used for monitoring, detection and investigation.

Vulnerability: A weakness that can be exploited to compromise security properties or system operation.

Vulnerability disclosure: The process of reporting, validating, coordinating and communicating information about a weakness.

Review Questions

Short Answer Questions

1. Why is an asset inventory essential to vulnerability management?
2. What does CVSS measure, and what important decision does it not make by itself?
3. Identify four attributes that make application telemetry useful.
4. What information should be included in a risk-acceptance exception?
5. Distinguish containment from eradication in incident response.

Long Answer Questions

1. Explain the vulnerability-management lifecycle and show how verification and lessons learned improve subsequent cycles.
2. Compare technical severity with business risk, using exposure, exploit intelligence and asset criticality in your discussion.
3. Discuss the design of an application-monitoring strategy for a public API handling sensitive information.
4. Explain the responsibilities of preparation, analysis, containment, eradication, recovery and post-incident review.
5. Evaluate the ethical and governance issues involved in coordinated vulnerability disclosure and risk acceptance.

Analytical / Application Questions

1. An internet-facing service has a medium CVSS score but processes regulated data and shows evidence of exploitation. A critical-rated flaw exists only on an isolated test server. Which should be prioritised first, and what additional evidence would you request?
2. A detection programme has 80 true positives, 20 false positives and 10 false negatives in an evaluated sample. Calculate precision and recall using the formulas in this chapter, and explain what each result implies for analyst workload and missed attacks.
3. Design a response plan for an account-takeover incident in which suspicious login activity is followed by privilege elevation and bulk data access. Identify immediate containment, evidence-preservation, recovery and long-term improvement actions.

Multiple Choice Questions with Answers

Question 1

Which statement best describes the role of CVSS in vulnerability management?

A. It is a complete measure of financial loss.

B. It standardises technical vulnerability severity characteristics.

C. It proves that a vulnerability is being actively exploited.

D. It replaces the need for asset ownership.

Correct Answer: B. It standardises technical vulnerability severity characteristics.

Question 2

Which asset-inventory attribute most directly supports accountability for remediation?

A. Screen resolution

B. Responsible service owner

C. Keyboard layout

D. Desk location

Correct Answer: B. Responsible service owner

Question 3

Which action is an example of verification?

A. Assigning a ticket to a developer

B. Changing the vulnerability title

C. Retesting after a patch and confirming the weakness is removed

D. Increasing the scanner schedule without reviewing results

Correct Answer: C. Retesting after a patch and confirming the weakness is removed

Question 4

What is the principal purpose of a time-bounded security exception?

A. To conceal an unresolved vulnerability

B. To authorise and manage temporary departure from a required control

C. To eliminate the need for compensating controls

D. To transfer all accountability to the security team

Correct Answer: B. To authorise and manage temporary departure from a required control

Question 5

Which telemetry practice is most appropriate?

A. Log passwords for forensic completeness

B. Use inconsistent local timestamps

C. Record attributable actions while protecting sensitive values

D. Delete logs immediately after an alert

Correct Answer: C. Record attributable actions while protecting sensitive values

Question 6

In the precision formula, what does FP represent?

A. Failed patch

B. False positive

C. Forensic process

D. Forward privilege

Correct Answer: B. False positive

Question 7

Which activity belongs primarily to containment?

A. Limiting access by disabling a compromised token

B. Writing the annual security strategy

C. Classifying all historical assets

D. Publishing unrelated product documentation

Correct Answer: A. Limiting access by disabling a compromised token

Question 8

Why should an organisation preserve evidence before destroying a compromised host when feasible?

A. To increase storage costs

B. To support investigation and understand the attacker’s access path

C. To guarantee that no notification is required

D. To avoid applying security patches

Correct Answer: B. To support investigation and understand the attacker’s access path

Question 9

A sample contains 80 true positives and 20 false positives. What is its precision?

A. 20%

B. 50%

C. 80%

D. 100%

Correct Answer: C. 80%

Question 10

Which factor can elevate the priority of a medium-severity vulnerability?

A. The asset has no owner and no users

B. The asset is public and processes regulated information

C. The finding has been duplicated in a report

D. The vulnerability is present only in deleted software

Correct Answer: B. The asset is public and processes regulated information