Vulnerability and Exposure Management

Introduction

Vulnerability and exposure management is the disciplined process of identifying weaknesses in an organization’s assets, evaluating the risk those weaknesses create, reducing that risk through appropriate treatment, and confirming that corrective action has worked. It is a central operational activity in cybersecurity because organizations cannot protect what they have not identified, cannot prioritize what they have not assessed, and cannot claim improvement without validation.

The process extends beyond running a vulnerability scanner. It includes asset discovery, ownership, service identification, configuration review, vulnerability analysis, risk-based prioritization, remediation coordination, exception management, and verification. It also requires authorization and professional judgment. An inaccurate scan can create false confidence; an unauthorized scan can disrupt systems or violate law and policy.

A vulnerability is a weakness that could be exploited or could otherwise contribute to an undesirable security outcome. An exposure is a condition that increases the opportunity or impact of harm, even when it is not a conventional software defect. Examples include an internet-facing administrative interface, excessive privileges, unsupported software, weak security configuration, leaked credentials, or an unprotected cloud storage bucket.

Vulnerability and exposure management should therefore be viewed as a continuous risk-management capability rather than a periodic technical exercise.

Learning Objectives

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

• conduct authorized asset discovery and explain why asset inventory is foundational;
• distinguish vulnerability scanning, configuration review, vulnerability assessment, and penetration testing;
• interpret scan findings, including severity, confidence, exploitability, and business context;
• prioritize remediation using risk-based criteria;
• select suitable remediation, mitigation, transfer, or acceptance actions;
• validate that vulnerabilities and configuration weaknesses have been corrected;
• explain ethical, governance, safety, and operational requirements for assessment activities.

1. The Management Problem: Unknown and Changing Attack Surface

An organization’s attack surface includes the hardware, software, identities, services, interfaces, data stores, cloud resources, applications, and third-party connections that could be reached or influenced by an attacker. It changes continuously as systems are deployed, modified, exposed to the internet, connected to suppliers, or abandoned without formal retirement.

A simple asset register may contain hostnames and owners, but effective management requires more information. Useful attributes include:

• asset identifier and business owner;
• location or cloud account;
• IP address, domain name, or application URL;
• operating system and software versions;
• data handled and business function;
• internet exposure and network placement;
• criticality, recovery requirements, and dependencies;
• assessment status and known exceptions.

The most dangerous asset is often not the most technically complex one. A small forgotten server with an exposed management service may create greater risk than a well-maintained production system protected by multiple controls. Consequently, discovery must identify both known assets and discrepancies between authorized inventories and observed reality.

Asset discovery approaches

Passive discovery observes existing information without directly probing target systems. Sources may include DNS records, DHCP logs, cloud inventories, endpoint-management platforms, identity systems, configuration-management databases, certificate transparency records, firewall logs, and vulnerability-management platforms. Passive methods usually create less operational risk but may miss unregistered or inactive assets.

Active discovery sends authorized requests to identify hosts, ports, services, applications, and responses. Examples include network discovery, service enumeration, authenticated inventory collection, and application crawling. Active discovery provides useful detail but can generate load, trigger defensive controls, or affect fragile systems.

Agent-based discovery uses software installed on endpoints or servers to report hardware, software, configuration, and sometimes vulnerability information. It can provide rich local detail, including installed packages that are not visible remotely, but agents require deployment, maintenance, and protection from tampering.

Cloud and application discovery must account for ephemeral resources, containers, serverless functions, APIs, repositories, software-as-a-service platforms, and infrastructure-as-code templates. Traditional IP-based discovery alone is insufficient for modern environments.

A mature process combines these approaches and reconciles their results. Discovery should produce actionable records, not merely a list of addresses.

2. Vulnerabilities, Exposures, Threats, and Risk

These terms are related but not interchangeable.

• A threat is a circumstance, actor, or event capable of causing harm.
• A vulnerability is a weakness that can be exploited or can contribute to failure.
• An exposure is a condition that increases accessibility, opportunity, or potential impact.
• An exploit is a method, code, or technique that takes advantage of a vulnerability.
• An impact is the consequence if an adverse event occurs.
• Risk is the possibility of loss or harm arising from uncertainty, often evaluated through likelihood and impact.

A vulnerability does not automatically mean that compromise is occurring. A flaw on an isolated, noncritical laboratory system may have lower practical risk than a moderately severe flaw on an internet-facing payment service. Conversely, lack of known exploitation does not prove safety; attackers may discover or use weaknesses before they appear in public reporting.

A useful conceptual model is:

Here, likelihood is an informed estimate of how probable an adverse event is within a defined period, and impact represents the magnitude of harm. This is a qualitative or semi-quantitative decision model, not a universal law. Organizations must define their rating scales and avoid presenting subjective estimates as precise measurements.

Likelihood may be influenced by exposure, exploit availability, attacker capability, required privileges, user interaction, compensating controls, and evidence of exploitation. Impact may include confidentiality, integrity, availability, safety, financial loss, legal consequences, privacy harm, and damage to mission or reputation.

3. Vulnerability Assessment and Its Boundaries

A vulnerability assessment is a structured process of identifying, analyzing, and reporting weaknesses. It commonly includes automated scanning, authenticated checks, manual review, configuration analysis, application testing, and contextual risk evaluation.

A vulnerability scan is narrower. It uses tools and checks to identify possible weaknesses, often by matching software versions, configurations, responses, or credentials against detection rules. Scanning is efficient and repeatable, but it may produce false positives, miss vulnerabilities, or fail to understand business context.

A configuration review examines settings against a baseline, policy, or security benchmark. Examples include password policy, unnecessary services, encryption settings, logging, firewall rules, cloud identity permissions, endpoint protections, and secure protocol configuration. A system can be free of known software vulnerabilities and still be dangerously misconfigured.

A penetration test is an authorized, scoped attempt to demonstrate whether vulnerabilities can be exploited and how far an attacker might progress. It normally includes human-led planning, attack-path reasoning, validation of exploitability, and controlled post-exploitation. Penetration testing can reveal chains of weaknesses that scanning does not, but it is more intrusive, expensive, and time-limited.

These activities complement one another. A penetration test is not a substitute for continuous asset discovery and routine scanning, and a scan is not evidence that an organization has tested every realistic attack path.

4. Planning an Authorized Assessment

Before technical activity begins, the assessment must have a documented authorization. The authorization should identify:

1. Scope: systems, networks, applications, cloud accounts, domains, and environments included.
2. Exclusions: fragile systems, safety-critical devices, third-party assets, or prohibited techniques.
3. Purpose and methods: discovery, authenticated scanning, configuration review, application testing, or validation.
4. Time window: permitted dates, hours, and blackout periods.
5. Contacts: technical owner, security contact, incident-response contact, and escalation authority.
6. Safety controls: rate limits, prohibited payloads, backup requirements, and stop conditions.
7. Data handling: collection, encryption, retention, access, and secure disposal of results.
8. Rules of engagement: acceptable test behavior, evidence requirements, and reporting arrangements.

Authorization is not a formality. It establishes legal and organizational authority and reduces the chance that testing will be mistaken for an attack. Testing third-party infrastructure requires explicit permission from the responsible party; ownership of a business relationship does not automatically authorize testing a supplier’s systems.

Assessors should begin with low-impact techniques, confirm that target identification is correct, and monitor for service degradation. Where possible, authenticated scanning is preferable because it can inspect installed packages, patches, local configuration, and permissions with fewer assumptions than unauthenticated probing.

5. Interpreting Findings

A scanner finding is an observation requiring analysis, not automatically a confirmed security defect. Each finding should be examined for:

• affected asset and exact location;
• detection method and evidence;
• vulnerability identifier or configuration requirement;
• affected software, version, or setting;
• severity and confidence;
• exploit availability or observed exploitation;
• prerequisites such as network access or authentication;
• business owner and asset criticality;
• compensating controls;
• recommended action and target date.

False positives and false negatives

A false positive reports a weakness that is not actually present. Causes include inaccurate version detection, backported vendor patches, unusual configurations, virtual hosting, or a service that is not reachable in the assumed way. False positives consume remediation capacity and reduce trust in the program.

A false negative fails to identify a weakness that exists. Causes include incomplete coverage, unsupported technology, blocked probes, insufficient credentials, encrypted or dynamic services, and detection rules that do not recognize a variant. False negatives are especially dangerous because they create invisible gaps.

Verification may involve reviewing package information, checking vendor advisories, examining configuration directly, reproducing a safe non-destructive condition, or comparing results from independent evidence sources. Assessors should record why a finding was confirmed, dismissed, or deferred.

Severity is not the same as organizational risk

Common severity systems, such as the Common Vulnerability Scoring System (CVSS), provide a standardized technical description of characteristics such as attack vector, privileges required, user interaction, and impacts on confidentiality, integrity, and availability. A CVSS score is useful for comparison, but it is not a complete business-risk decision.

Risk prioritization should incorporate at least:

• technical severity;
• internet or external exposure;
• exploit availability and threat intelligence;
• evidence of active exploitation;
• asset criticality and data sensitivity;
• reachability from likely attacker positions;
• existing preventive and detective controls;
• remediation complexity and operational risk;
• regulatory, contractual, or safety obligations.

A high-severity vulnerability on a disconnected test system may receive a lower treatment priority than a medium-severity issue on an exposed identity server. The reasoning should be documented rather than hidden in an unexplained score.

6. Prioritizing Remediation

A practical prioritization process assigns findings to treatment categories such as critical, high, medium, low, or informational. The categories must have organizational definitions and target response times. For example, a policy might require immediate action for actively exploited weaknesses on internet-facing critical assets, while allowing scheduled treatment for low-impact local configuration issues.

A useful decision sequence is:

1. Is the finding valid?
2. Is the asset in scope and still active?
3. Is the asset exposed or reachable by a credible attacker?
4. Is exploitation known, easy, or likely?
5. What business, safety, privacy, or regulatory impact could result?
6. Are compensating controls effective?
7. What is the safest effective treatment?
8. Who owns the action, and when will it be verified?

Treatment options include:

• Remediation: patch, upgrade, reconfigure, remove, replace, or redesign the affected component.
• Mitigation: reduce likelihood or impact while permanent remediation is pending, for example by restricting access or disabling a vulnerable feature.
• Avoidance: discontinue the exposed service or process.
• Transfer: shift some financial or operational consequences through contracts or insurance; this does not remove the underlying vulnerability.
• Acceptance: formally acknowledge residual risk when treatment is disproportionate or not currently feasible.

Risk acceptance must be explicit, time-bounded, owned by an appropriate authority, and reviewed. It should state the rationale, affected assets, compensating controls, expiration date, and trigger for reassessment. A help-desk ticket that remains open indefinitely is not meaningful risk acceptance.

Worked prioritization example

An organization identifies three findings:

• Finding A: a critical vulnerability with active exploitation on an internet-facing authentication server.
• Finding B: a high-severity vulnerability on an internal reporting server reachable only by a restricted administration network.
• Finding C: a medium-severity configuration weakness on a low-criticality development workstation.

A purely severity-based queue might address A, B, and C in that order, which happens to be sensible here. However, the reason A is urgent is not the label alone: active exploitation, external exposure, identity-system importance, and potentially extensive impact combine to raise its risk. B may require rapid but scheduled treatment, while C can be handled through the normal workstation-hardening cycle. If B stored regulated information or if the administrative network were broadly accessible, its priority could change.

7. Remediation and Validation

Remediation should be planned as a controlled change. Before patching or reconfiguring a production system, teams should identify dependencies, test the change where feasible, confirm backup or recovery arrangements, define rollback steps, and communicate expected service effects.

Validation is a separate activity from remediation. A ticket marked “patched” is not proof that the issue is resolved. Effective validation may include:

• rescanning the affected asset with the appropriate authenticated or unauthenticated method;
• checking the installed package or firmware version;
• reviewing the relevant configuration directly;
• confirming that the vulnerable service is disabled or inaccessible;
• testing that compensating controls operate as intended;
• checking that the fix did not create a new weakness or break a required service.

A finding should be closed only when evidence supports closure. If the vulnerability remains, the record should be reopened or transferred to an approved exception process. If the asset has been retired, evidence of retirement and removal from exposure should be recorded.

Validation should also consider regression. A system may be secure immediately after a patch and become vulnerable again when an image is redeployed, a configuration-management job restores an insecure setting, or a new instance is created from an outdated template. Sustainable remediation therefore addresses the source of recurrence, such as patch automation, secure baselines, change controls, or software-development practices.

8. Governance, Ethics, and Data Protection

Assessment results often contain sensitive information: host addresses, usernames, software inventories, security weaknesses, credentials accidentally exposed in files, and evidence of regulated data. Results must be treated as security-sensitive records. Access should follow least privilege, reports should be encrypted in transit and at rest, and retention should be limited to operational and legal needs.

Ethical assessment requires honesty about scope and limitations. An assessor should not exaggerate findings, conceal uncertainty, exploit unrelated data, or collect more information than necessary. If sensitive data is encountered, the assessor should follow the agreed handling procedure and notify the designated contact.

Governance should define:

• ownership of the vulnerability-management program;
• risk-rating and exception standards;
• remediation service-level objectives;
• escalation for overdue critical findings;
• evidence and audit requirements;
• supplier and cloud responsibilities;
• reporting to technical and executive audiences.

Legal and regulatory duties vary by jurisdiction and sector. Privacy, critical infrastructure, healthcare, financial, and contractual requirements may impose additional obligations. Organizations should obtain appropriate legal and compliance advice rather than assuming that a security purpose alone authorizes any test.

9. Contemporary Practices and the Role of Automation and AI

Modern programs increasingly combine vulnerability management with broader exposure management. This includes attack-surface monitoring, cloud-security posture management, identity exposure, application dependencies, external attack-surface discovery, and prioritization based on active threat intelligence.

Automation can improve consistency by discovering assets, scheduling scans, opening tickets, checking patch status, and correlating findings. However, automation must be governed. Poorly configured scanners can overload systems, create duplicate tickets, or repeatedly report false positives. Automated closure is risky unless the evidence is reliable and the asset identity is unambiguous.

Artificial intelligence may assist with deduplication, natural-language explanations, remediation recommendations, anomaly detection, and correlation of technical findings with asset context. It should not be treated as an independent authority. AI-generated conclusions may be based on incomplete inventories, outdated data, or incorrect assumptions. Human review remains necessary for authorization, risk acceptance, safety-sensitive systems, and decisions involving legal or business consequences.

Software supply-chain practices are also important. Organizations should track dependencies, generate or consume software bills of materials where appropriate, monitor vendor advisories, and ensure that build pipelines do not reintroduce vulnerable components. Infrastructure-as-code scanning can identify insecure cloud configurations before deployment, moving exposure management earlier in the lifecycle.

10. Applied Case: Northbridge College Student Portal

The following is an illustrative case.

Background

Northbridge College operates a student portal used for registration, grades, payment information, and identity services. The portal runs in a cloud environment managed jointly by the college’s infrastructure team and a service provider. The college maintains a configuration-management database, but several cloud resources were created during previous projects and are not recorded consistently.

Problem

An external attack-surface review identifies an additional subdomain and an internet-accessible administrative interface. A vulnerability scan reports an outdated web framework, a weak TLS configuration, and an exposed storage container. Some results are duplicates because the same application is represented by several hostnames.

Analysis

The security team first verifies authorization and confirms that the discovered resources belong to the college. It uses cloud inventory records, DNS data, and service-provider documentation to establish ownership. Authenticated review confirms the framework version and identifies that the storage container contains only test exports, not current payment records. Nevertheless, the container is accessible without authentication, and its naming pattern reveals internal project information.

The framework issue is technically high severity, but the team also considers whether the vulnerable component is reachable through the affected application paths. The administrative interface is more urgent because it is internet-facing and protected only by a password policy that does not require multifactor authentication. The TLS weakness is prioritized below the exposed administrative interface but above routine development hardening.

Approach and solution

The team applies temporary network restrictions to the administrative interface, enables multifactor authentication, and schedules an application upgrade after testing. It removes public access to the storage container and verifies that the application uses a private identity with only required permissions. The TLS configuration is changed to the organization’s approved baseline.

The team then performs validation from an authorized external test location and through authenticated cloud checks. It confirms that the administrative endpoint is no longer publicly reachable, the container denies anonymous access, the framework version is supported, and required application functions remain available. The asset inventory is updated, and the service provider is assigned responsibility for future version monitoring.

Outcome

The college reduces immediate exposure, establishes ownership, and prevents the same gap from recurring by adding cloud-resource discovery to its monthly process and infrastructure-as-code checks to its deployment pipeline. The case demonstrates that the most important action was not simply applying a patch. It was correlating discovery, exposure, configuration, business context, remediation, and validation.

Learning points

• Asset discovery can reveal risks that routine scanning misses.
• Public exposure and identity controls can make configuration weaknesses urgent.
• Duplicate findings must be consolidated to avoid misleading metrics.
• Remediation should include ownership and recurrence prevention.
• Validation must test both the technical condition and the business service.

Challenges and Limitations

No vulnerability-management program provides perfect knowledge. Important limitations include incomplete asset inventories, short-lived cloud resources, proprietary systems, inaccessible third-party services, scanner coverage gaps, false positives, false negatives, and rapidly changing threat conditions.

Prioritization also involves uncertainty. Technical severity scores cannot fully represent business consequences, and threat intelligence may be incomplete or delayed. Organizations should record assumptions and review priorities when new evidence appears.

Operational constraints create additional challenges. Patching may interrupt critical services, legacy systems may lack vendor support, and remediation teams may have more findings than available capacity. These constraints do not justify ignoring risk; they require transparent mitigation, formal exceptions, compensating controls, and leadership decisions.

Finally, metrics can be misleading. Counting findings closed may reward easy low-risk work while urgent problems remain. More meaningful measures include time to remediate by risk category, percentage of assets with current ownership, recurrence rate, age of accepted risks, validation success rate, and coverage of critical environments.

Best-Practice Checklist

A certificate-level practitioner should be able to explain and apply the following practices:

• obtain written authorization and define scope before testing;
• maintain an inventory with ownership, criticality, exposure, and technology details;
• combine passive, active, agent-based, cloud, and application discovery as appropriate;
• prefer authenticated assessment where safe and feasible;
• distinguish scanner observations from confirmed vulnerabilities;
• use technical severity as an input, not the entire risk decision;
• prioritize active exploitation, external exposure, critical assets, and high-impact paths;
• assign accountable owners and deadlines;
• document mitigation and time-bounded risk acceptance;
• validate fixes with evidence and check for regression;
• protect assessment data and report uncertainty honestly;
• measure coverage, risk reduction, and recurrence rather than ticket volume alone.

Chapter Summary

Vulnerability and exposure management is a continuous process for discovering assets, identifying weaknesses, evaluating risk, treating exposures, and validating results. Asset discovery is foundational because unknown systems cannot be reliably assessed or protected. Passive, active, agent-based, cloud, and application discovery methods provide complementary evidence.

Vulnerability scanning uses automated checks to identify possible weaknesses, while configuration review compares settings with approved baselines. Vulnerability assessment adds analysis and context, whereas penetration testing attempts to demonstrate exploitability and attack paths under controlled authorization. These activities are related but not interchangeable.

Risk-based prioritization combines technical severity with exposure, exploitability, threat evidence, asset criticality, business impact, and compensating controls. Remediation may involve patching, reconfiguration, removal, mitigation, avoidance, transfer, or formal acceptance. A finding should not be closed merely because a change was requested; validation must provide evidence that the weakness is corrected and that essential services continue to operate.

Effective programs are authorized, ethical, measurable, and governed. They protect assessment data, document uncertainty, assign ownership, address recurring causes, and use automation or AI with appropriate human oversight.

Key Terms

Asset discovery: The process of identifying systems, services, applications, and resources in an environment.

Attack surface: The collection of assets and interfaces that may be reached or influenced by an attacker.

Compensating control: An alternative safeguard that reduces risk when the preferred control cannot be implemented.

Configuration review: Examination of system settings against a security baseline, policy, or benchmark.

Exposure: A condition that increases the opportunity or potential impact of harm.

Exploit: A method, code, or technique that takes advantage of a vulnerability.

False negative: A failure to identify a weakness that is actually present.

False positive: A reported weakness that is not actually present.

Impact: The consequence or magnitude of harm resulting from an adverse event.

Penetration testing: Authorized, controlled testing designed to demonstrate exploitability and attack paths.

Remediation: Corrective action that removes or reduces a vulnerability or exposure.

Risk: The possibility of harm arising from uncertainty, commonly considered through likelihood and impact.

Risk acceptance: A documented decision to retain a known residual risk under defined conditions.

Threat: An actor, event, or circumstance capable of causing harm.

Validation: Evidence-based confirmation that remediation has worked.

Vulnerability: A weakness that can be exploited or contribute to an undesirable outcome.

Vulnerability assessment: The structured identification, analysis, and reporting of weaknesses and their significance.

Vulnerability scanning: Automated or semi-automated checking for possible vulnerabilities.

Review Questions

Short Answer Questions

1. Why is asset discovery foundational to vulnerability and exposure management?
2. Distinguish a vulnerability from an exposure.
3. What is the purpose of authenticated vulnerability scanning?
4. Why is technical severity not equivalent to organizational risk?
5. What evidence should support closure of a remediation finding?

Long Answer Questions

1. Compare vulnerability scanning, configuration review, vulnerability assessment, and penetration testing. Explain when each is useful.
2. Describe the contents of an authorization and rules-of-engagement document for an assessment.
3. Explain how false positives and false negatives affect vulnerability-management programs and how they can be handled.
4. Discuss the main remediation treatment options and the governance requirements for risk acceptance.
5. Explain how cloud computing, software supply chains, automation, and AI are changing exposure management.

Analytical / Application Questions

1. An internet-facing server has a medium-severity vulnerability with evidence of active exploitation, while an isolated laboratory server has a critical vulnerability with no known exploit. Which should be addressed first, and what additional information would you seek?
2. A scanner reports that a production system is running vulnerable software, but the vendor states that its security fix was backported without changing the version number. How would you investigate and document the finding?
3. A remediation ticket is marked complete after a patch is installed, but a later scan reports the same vulnerability. Identify possible causes and design a validation and recurrence-prevention process.

Multiple Choice Questions with Answers

Question 1

Which activity is primarily intended to identify systems, services, and resources in an environment?

A. Asset discovery

B. Risk acceptance

C. Penetration testing

D. Incident eradication

Correct Answer: A. Asset discovery

Question 2

What is the main limitation of treating a vulnerability scanner finding as automatically confirmed?

A. Scanners never identify software versions

B. Findings may be false positives or lack business context

C. Scanners can only assess physical security

D. Findings cannot be documented

Correct Answer: B. Findings may be false positives or lack business context

Question 3

Which statement best distinguishes vulnerability assessment from penetration testing?

A. Assessment identifies and analyzes weaknesses; penetration testing attempts controlled exploitation

B. Assessment is always unauthorized; penetration testing is always passive

C. Assessment concerns only policies; penetration testing concerns only hardware

D. There is no meaningful distinction

Correct Answer: A. Assessment identifies and analyzes weaknesses; penetration testing attempts controlled exploitation

Question 4

Which factor should increase the priority of a vulnerability?

A. The asset is scheduled for retirement next year

B. The vulnerability is actively exploited on an internet-facing critical asset

C. The finding has a short description

D. The scanner produced the result during business hours

Correct Answer: B. The vulnerability is actively exploited on an internet-facing critical asset

Question 5

What is a false negative?

A. A weakness reported on an unaffected system

B. A weakness that is missed even though it exists

C. A vulnerability that has been remediated

D. A risk formally accepted by management

Correct Answer: B. A weakness that is missed even though it exists

Question 6

Which action is an example of mitigation rather than permanent remediation?

A. Restricting access to a vulnerable service while a patch is tested

B. Installing the vendor’s corrected version

C. Replacing the vulnerable component

D. Removing the affected system permanently

Correct Answer: A. Restricting access to a vulnerable service while a patch is tested

Question 7

Why should a remediation finding be validated after a patch is applied?

A. To increase the number of open tickets

B. To confirm the weakness is corrected and required services still work

C. To avoid documenting the change

D. To ensure the scanner is disabled

Correct Answer: B. To confirm the weakness is corrected and required services still work

Question 8

Which item should be included in an assessment authorization?

A. Unrestricted permission to test every system on the internet

B. Scope, exclusions, methods, contacts, and stop conditions

C. A guarantee that no finding will be reported

D. A requirement to collect all available personal data

Correct Answer: B. Scope, exclusions, methods, contacts, and stop conditions

Question 9

What does formal risk acceptance mean?

A. The vulnerability has been proven harmless

B. An authorized party knowingly retains residual risk under defined conditions

C. The scanner has produced a false positive

D. The issue is automatically transferred to a supplier

Correct Answer: B. An authorized party knowingly retains residual risk under defined conditions

Question 10

Which statement about technical severity scores is most accurate?

A. They completely determine business priority

B. They are irrelevant to remediation decisions

C. They are useful inputs but should be combined with exposure, impact, and threat context

D. They prove that exploitation has occurred

Correct Answer: C. They are useful inputs but should be combined with exposure, impact, and threat context