9. Cloud Security Posture, Exposure and Vulnerability Management

Introduction and Context

Cloud environments change continuously. New accounts, subscriptions, regions, containers, serverless functions, identities, storage services, application programming interfaces, and third-party integrations may be created within minutes. This elasticity supports innovation, but it also makes security assessment fundamentally different from periodic auditing of fixed data-centre infrastructure. A secure configuration observed on Monday may be unsafe on Friday because of a changed identity policy, an exposed management interface, an unpatched image, an abandoned storage bucket, or a newly granted privilege.

Cloud security posture, exposure, and vulnerability management therefore form a continuous management discipline. The objective is not merely to discover technical weaknesses. It is to understand which weaknesses are reachable, exploitable, connected to valuable assets, and capable of producing material business harm. Effective programmes combine technical telemetry, asset context, identity analysis, vulnerability intelligence, policy evaluation, threat modelling, and remediation governance.

Several technology categories contribute to this capability. Cloud Security Posture Management (CSPM) identifies insecure configurations and policy violations. Cloud Workload Protection Platforms (CWPP) protect virtual machines, containers, Kubernetes workloads, and serverless functions. Cloud Infrastructure Entitlement Management (CIEM) analyses permissions and excessive privilege. Data Security Posture Management (DSPM) identifies sensitive data, its location, access paths, and exposure. External Attack Surface Management (EASM) discovers internet-facing assets, while Cyber Asset Attack Surface Management (CAASM) helps reconcile asset information across systems. Cloud-Native Application Protection Platforms (CNAPP) increasingly combine these functions across the development and runtime lifecycle.

The central professional challenge is prioritisation. A vulnerability with a high severity score may have little practical significance on an isolated development host, whereas a moderate configuration defect on an internet-facing identity service connected to regulated data may deserve immediate attention. This chapter develops a risk-based approach to finding, interpreting, prioritising, remediating, and verifying cloud security weaknesses.

Learning Objectives

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

1. Explain the relationship between security posture, attack surface, exposure, vulnerability, and business risk.

2. Distinguish the roles and boundaries of CSPM, CWPP, CIEM, DSPM, EASM, CAASM, and CNAPP.

3. Apply a continuous discovery and remediation workflow to cloud environments.

4. Evaluate vulnerabilities using exploitability, asset criticality, exposure, identity paths, and business impact.

5. Design governance, automation, metrics, and escalation processes for cloud security posture management.

6. Analyse the limitations and ethical implications of automated cloud security assessment.

From Configuration Compliance to Exposure Management

A security posture is the current security condition of an environment, including its configurations, identities, workloads, data protections, network controls, monitoring, and compliance with defined policies. A posture assessment asks whether the environment is configured according to organisational requirements. Examples include checking whether storage is encrypted, administrative access requires multifactor authentication, public access is disabled, audit logs are retained, and security groups are restrictive.

An exposure exists when a weakness can be reached through a plausible path. Reachability may arise from the public internet, a compromised workload, a trusted network connection, a permissive identity relationship, a vulnerable application, or a misconfigured service endpoint. Exposure is therefore contextual. A vulnerable package on a private host may be less exposed than the same package in a public container connected to production credentials.

A vulnerability is a weakness that can be exploited to violate confidentiality, integrity, or availability. Vulnerabilities may exist in operating systems, libraries, container images, hypervisors, applications, infrastructure-as-code templates, or managed services. A misconfiguration is an unsafe or non-compliant setting, such as public object storage or unrestricted administrative ports. A misconfiguration may itself enable compromise, or it may combine with a vulnerability to create a more serious attack path.

A useful conceptual model is:

Business risk = likelihood of harmful exploitation × magnitude of impact

Likelihood is influenced by exploit availability, attacker capability, exposure, control strength, and asset accessibility. Impact depends on data sensitivity, business criticality, regulatory obligations, operational dependency, recovery difficulty, and potential consequences for customers or stakeholders. This model is not a precise mathematical truth; it is a decision framework that prevents teams from treating every alert as equally urgent.

The Cloud Security Management Landscape

Cloud Security Posture Management

CSPM continuously evaluates cloud resources against security policies, regulatory requirements, architectural standards, and organisational baselines. It commonly examines identity settings, network exposure, logging, encryption, storage permissions, key management, backup controls, and service configurations. CSPM may operate through provider APIs, configuration snapshots, event streams, or agents.

CSPM findings should not be interpreted as automatic proof of compromise. They indicate deviation from a desired state. A public endpoint may be intentional, documented, and protected by compensating controls. Conversely, a resource may pass a narrow compliance rule while remaining exposed through an overlooked identity relationship. Mature CSPM programmes therefore connect findings with asset ownership, data classification, exposure information, and exception records.

Cloud Workload Protection Platforms

CWPP focuses on workloads rather than solely on cloud control-plane configuration. It may provide host intrusion prevention, malware detection, file integrity monitoring, runtime behaviour analysis, vulnerability assessment, container protection, Kubernetes admission controls, and serverless code analysis. CWPP is particularly important where workloads are ephemeral and traditional agents cannot be installed or maintained easily.

The principal design question is lifecycle coverage. Vulnerability detection in a running workload is valuable, but preventing vulnerable images from entering production is often more efficient. Accordingly, CWPP capabilities increasingly integrate with build pipelines, registries, orchestration platforms, and runtime controls.

Cloud Infrastructure Entitlement Management

CIEM analyses who or what can access which cloud resources and under what conditions. It addresses excessive permissions, unused entitlements, privilege escalation paths, cross-account trust, service identities, and toxic combinations of permissions. Unlike simple user inventories, CIEM seeks to understand effective access: the permissions a principal can exercise after role inheritance, group membership, resource policies, federation, and service-to-service relationships are considered.

Least privilege is not achieved merely by removing obviously unused users. It requires continuous analysis of machine identities, temporary credentials, workload roles, emergency accounts, and permissions that enable the creation or modification of other identities. CIEM findings should be reviewed with application owners because aggressive permission reduction can interrupt legitimate services.

Data Security Posture Management

DSPM maps sensitive data stores, classifies data, identifies access patterns, and evaluates whether data is exposed beyond business need. It may identify personal, financial, health, confidential, or intellectual-property data across structured databases, object storage, analytics platforms, backups, and development environments.

DSPM changes the interpretation of other findings. A public storage configuration is more urgent when the bucket contains regulated records than when it contains approved public marketing material. Classification is imperfect, however, and organisations must validate automated data discovery, manage false positives, and protect the sensitive metadata produced by DSPM itself.

Attack-Surface Management and CNAPP

EASM discovers assets visible from outside the organisation, including domains, subdomains, public IP addresses, certificates, exposed services, cloud applications, and forgotten development systems. CAASM reconciles asset information from multiple internal tools and helps address the problem of incomplete inventories. Both approaches are valuable because security teams cannot protect assets that they do not know exist.

CNAPP is an architectural convergence of posture management, workload protection, entitlement analysis, application security, and vulnerability management. Its benefit is context: a platform may link an infrastructure-as-code defect to a deployed resource, a vulnerable library, an exploitable workload, an identity path, and sensitive data. Its risk is over-centralisation. A platform can produce a large volume of correlated findings without resolving ownership, business context, or remediation authority.

A Continuous Management Workflow

Establish an Authoritative Inventory

The process begins with discovery. Inventory should include accounts, subscriptions, projects, regions, resources, workloads, images, repositories, identities, service principals, data stores, public endpoints, certificates, and dependencies. Discovery should combine cloud-native inventory services, provider APIs, network telemetry, endpoint data, identity systems, asset databases, and external reconnaissance.

Every important asset should have an owner, environment classification, business service relationship, data classification, recovery requirement, and lifecycle state. Ownership is not administrative decoration; it determines who can validate a finding and who has authority to remediate it.

Define Policy as Code and Security Baselines

Policies should express organisational expectations in machine-evaluable form. Examples include:

• production storage must not be publicly readable;
• administrative access must use strong authentication;
• critical workloads must send logs to a protected central destination;
• images must not contain known critical vulnerabilities above an approved threshold;
• internet-facing services must use approved network controls;
• identities must not retain unused high-risk permissions.

Policy-as-code enables repeatable assessment in infrastructure-as-code repositories, deployment pipelines, and runtime environments. Baselines must distinguish mandatory controls from recommendations and must support documented exceptions with owners, justification, expiry dates, and compensating controls.

Detect and Correlate Findings

Detection sources include configuration scanners, vulnerability scanners, secret detection, identity analytics, data discovery, external reconnaissance, runtime telemetry, penetration testing, threat intelligence, and incident investigations. Findings should be normalised and deduplicated. A single root cause may generate many alerts, such as one permissive network rule affecting hundreds of resources.

Correlation adds context. Relevant questions include: Is the asset public? Does it contain sensitive data? Is exploitation known? Is the vulnerable component running? Can the attacker obtain credentials? Is lateral movement possible? Is the control violation temporary or persistent? Does a compensating control exist? Correlation transforms isolated alerts into attack paths and remediation themes.

Prioritise with Risk-Based Analytics

Severity scores such as CVSS are useful inputs but should not determine priority alone. A practical prioritisation model can consider:

Priority = technical severity + exploitability + exposure + asset criticality + data sensitivity + business impact − effective controls

This expression is best implemented as a scoring rubric rather than as false precision. Exploitability indicators include public exploit code, active exploitation, ease of weaponisation, required privileges, attack complexity, and exploit maturity. Exposure indicators include public accessibility, reachable ports, identity trust relationships, vulnerable paths, and duration of exposure. Asset factors include production status, service importance, recovery time objectives, data classification, and regulatory significance.

Risk acceptance must be explicit. A business owner may accept a residual risk for a defined period, but acceptance should not erase the finding. It should record scope, rationale, expiration, monitoring, and accountable authority.

Remediate at the Most Effective Layer

Remediation may occur in source code, infrastructure-as-code, images, build pipelines, identity policies, network controls, runtime systems, or cloud configuration. Fixing the root cause is normally preferable to repeatedly correcting deployed instances. For example, editing a production security group may provide immediate containment, but modifying the infrastructure template prevents the unsafe rule from returning at the next deployment.

When immediate correction is impossible, compensating controls may reduce risk. These include restricting network reachability, disabling a vulnerable feature, rotating credentials, applying web-application protections, isolating a workload, increasing monitoring, or reducing permissions. Compensating controls should be treated as risk-reduction measures, not permanent substitutes for sound architecture.

Verify and Learn

Closure requires evidence. Verification may include rescanning, testing effective permissions, confirming image redeployment, checking that a public endpoint is inaccessible, validating log delivery, or conducting a controlled exploitability test. A finding should be reopened if the fix is incomplete or if configuration drift recreates it.

Trend analysis should examine recurrence, mean time to remediate, age of critical findings, exception duration, control coverage, false-positive rates, and the proportion of findings prevented before deployment. Post-incident and post-remediation reviews should improve policies, templates, training, and ownership models.

Prioritisation in Practice

Consider three findings:

1. A high-severity library vulnerability exists on an isolated test server with no sensitive data and no inbound connectivity.

2. A medium-severity identity policy allows a service account to modify network rules in a production account.

3. A public storage endpoint contains regulated customer records, but access logs show no confirmed misuse.

The first may receive a scheduled remediation window if compensating controls are strong. The second may require urgent treatment because it creates a privilege-escalation and lateral-movement path. The third requires immediate containment and investigation even if no exploitation is confirmed, because exposure and business impact are substantial. This example illustrates why risk-based management differs from ranking by a single numerical severity value.

Useful organisational metrics include coverage of inventoried assets, percentage of production assets with owners, number of exploitable critical findings, age-weighted exposure, percentage of high-risk identities reviewed, policy compliance over time, recurrence rate, and remediation service-level performance. Metrics should support decisions rather than reward superficial closure. A team that closes alerts by suppressing them may improve a dashboard while increasing actual risk.

Illustrative Case Study: The Public Analytics Environment

Background

A fictional financial-services organisation, Northbridge Finance, operated cloud analytics environments managed by separate engineering teams. The environments contained transaction data, test datasets, notebooks, container workloads, and automated data-processing identities. Security monitoring covered production accounts but had limited visibility into temporary analytics projects.

Situation and Problem

An EASM exercise discovered an internet-facing notebook service in a development project. CSPM identified a public network rule, while DSPM found that a copied dataset contained customer identifiers. CIEM showed that the notebook’s service identity could read object storage across several projects and could create compute resources. The notebook image also contained an outdated package with a known exploitable weakness.

No evidence initially demonstrated compromise. Nevertheless, the combination of public reachability, a vulnerable workload, broad identity permissions, and sensitive data created a credible attack path. Treating each finding separately would have underestimated the risk.

Analysis

The security team mapped the path as follows: external attacker to public notebook service; exploitation of the vulnerable package; acquisition of the notebook’s temporary credentials; access to customer data through excessive storage permissions; and possible creation of additional compute resources for persistence or abuse. The development label reduced neither the sensitivity of the copied data nor the privileges of the identity.

The team classified the data as regulated, the identity as high risk, and the service as externally exposed. It also reviewed logs, image provenance, recent identity use, and the data-copy process. The investigation distinguished exposure from confirmed compromise while preserving evidence for further analysis.

Approach and Solution

Immediate actions restricted the notebook service to an approved administrative network, disabled unnecessary public access, rotated relevant credentials, and preserved logs. The service identity was replaced with a narrowly scoped role limited to the required dataset and operations. The vulnerable image was rebuilt from an approved base image and blocked from deployment through a registry policy.

Longer-term actions included a CSPM rule against public notebook services, DSPM detection for regulated data in development accounts, CIEM review of high-privilege machine identities, mandatory owners for temporary projects, and infrastructure-as-code controls preventing unrestricted ingress. Exceptions received expiry dates and approval from the data owner and security authority.

Outcome

The exposure was removed, and subsequent testing confirmed that the notebook could not reach unauthorised datasets or create infrastructure. The organisation also discovered two additional unmanaged analytics projects. The most important result was not the closure of individual alerts but the creation of a reusable control pattern for temporary environments.

Learning Points

The case demonstrates that cloud risk is relational. Public access, vulnerability, identity privilege, data sensitivity, and asset ownership must be analysed together. It also shows why development environments require governance, why machine identities deserve the same attention as human users, and why prevention in templates and deployment pipelines is more durable than manual correction after deployment.

Challenges, Limitations, and Common Mistakes

Cloud security tools cannot guarantee complete visibility. Provider APIs may expose different information across services, ephemeral resources may disappear before assessment, encrypted data may complicate classification, and unmanaged accounts may remain outside central governance. Multi-cloud environments add differences in terminology, logging, identity models, and policy semantics.

False positives and false negatives are unavoidable. A scanner may identify a public endpoint that is intentionally protected, or fail to understand a custom control that reduces risk. Automated remediation can also create outages by changing a rule without understanding application dependencies. High-confidence, low-impact automation is appropriate for some controls; ambiguous or business-critical changes should require approval and staged deployment.

Common mistakes include treating compliance as security, relying exclusively on CVSS, ignoring machine identities, scanning only production, failing to distinguish root causes from symptoms, allowing permanent exceptions, measuring closure rather than risk reduction, and neglecting recovery controls. Another mistake is purchasing a CNAPP without defining ownership, policy authority, integration requirements, and operating processes.

Governance, Ethics, and Regulation

Posture management involves extensive observation of identities, workloads, data locations, employee activity, and potentially customer information. Organisations should apply purpose limitation, access control, retention limits, and auditability to security telemetry. Security teams must avoid using vulnerability data to assign blame when the underlying problem is unclear ownership or unrealistic delivery pressure.

Governance should define who may create policies, approve exceptions, execute automated changes, accept residual risk, and investigate suspected exposure. Separation of duties is important where the same person could suppress a finding, approve an exception, and deploy the insecure configuration. Regulatory obligations may require evidence of access control, data protection, incident response, vulnerability management, and audit logging, but compliance evidence should support—not replace—risk analysis.

Responsible disclosure and authorised testing are essential. External scanning, exploit validation, and credential testing must have explicit permission, defined scope, safety controls, and escalation procedures. Security professionals should protect the confidentiality of findings because a vulnerability inventory can itself become an attack resource.

Automation, Analytics, and Artificial Intelligence

Automation can continuously evaluate configurations, open tickets, quarantine exposed resources, rotate credentials, block vulnerable images, and enforce deployment policies. Event-driven remediation is particularly useful for high-confidence conditions such as newly public storage or disabled audit logging. Safe automation requires rollback, approval thresholds, testing, idempotence, and detailed audit trails.

Analytics can combine vulnerability intelligence, asset criticality, exploit evidence, identity graphs, network reachability, and data classification to identify attack paths. Graph models are useful because cloud compromise often depends on relationships rather than isolated defects. Machine-learning and generative-AI techniques may assist with alert deduplication, policy translation, ownership prediction, and remediation recommendations. They should not be treated as authoritative without validation. AI-generated changes can misunderstand business dependencies, leak sensitive configuration, or reproduce flawed assumptions. Human accountability remains necessary for high-impact decisions.

Current Developments and Emerging Directions

Cloud security programmes are moving toward continuous controls monitoring, in which policy evaluation occurs throughout design, build, deployment, and runtime. Software supply-chain security is increasingly integrated with cloud posture through provenance, signed artifacts, dependency analysis, and deployment attestations. Identity-centred defence is expanding as workload identities, federation, and non-human principals grow.

Security teams are also adopting exposure validation, attack-path analysis, and breach-and-attack simulation to test whether theoretical findings are practically reachable. Platform engineering is incorporating secure golden paths, approved modules, policy libraries, and self-service guardrails. The strategic direction is a shift from discovering isolated misconfigurations to reducing attack paths and preventing unsafe states by design.

Best Practices for Professional Implementation

A mature programme should:

1. Maintain a continuously updated inventory with accountable owners.

2. Classify assets, services, identities, and data according to business importance.

3. Combine CSPM, CWPP, CIEM, DSPM, and attack-surface data rather than operating isolated tools.

4. Evaluate effective exposure and attack paths, not merely individual findings.

5. Use exploitability and business impact to supplement technical severity.

6. Prevent recurring defects through infrastructure-as-code, secure images, and deployment guardrails.

7. Apply least privilege to human and machine identities.

8. Automate high-confidence, reversible controls and govern exceptions rigorously.

9. Verify remediation with evidence and measure recurrence.

10. Protect security telemetry and preserve human judgement for consequential decisions.

Chapter Summary

Cloud security posture, exposure, and vulnerability management is a continuous, context-driven discipline. CSPM identifies configuration and policy deviations; CWPP protects workloads; CIEM analyses effective permissions; DSPM connects security decisions to sensitive data; attack-surface management discovers reachable assets; and CNAPP correlates these perspectives across the cloud lifecycle. Their value depends on accurate inventory, ownership, policy-as-code, meaningful correlation, risk-based prioritisation, controlled remediation, and verification.

Technical severity alone is insufficient. Exploitability, reachability, asset criticality, data sensitivity, identity relationships, compensating controls, and business impact determine urgency. Mature organisations prevent defects in templates and pipelines, use runtime controls where necessary, govern exceptions, measure actual risk reduction, and apply automation with safeguards. Ethical handling of telemetry, authorised testing, accountable governance, and human oversight are essential to trustworthy cloud security.

Key Terms

Security posture: The current security condition of an environment relative to defined controls and risks.

Cloud exposure: The degree to which a cloud asset or weakness is reachable through plausible attack paths.

Misconfiguration: An unsafe, unintended, or policy-violating setting in a system or service.

Vulnerability: A weakness that can be exploited to compromise confidentiality, integrity, or availability.

CSPM: Technology that continuously evaluates cloud configurations and policies.

CWPP: Technology that protects cloud workloads across build, deployment, and runtime stages.

CIEM: Management of effective permissions and entitlement risks in cloud identities.

DSPM: Discovery and protection of sensitive data, its location, access, and exposure.

EASM: External discovery and assessment of internet-visible organisational assets.

CAASM: Reconciliation and management of asset information from internal security sources.

CNAPP: An integrated platform combining cloud posture, workload, identity, and application protections.

Attack path: A sequence of relationships and weaknesses that could enable harmful compromise.

Policy as code: Machine-readable security rules evaluated automatically in development or runtime.

Effective permission: The access a principal can actually exercise after inheritance and trust relationships are considered.

Asset criticality: The importance of an asset to business operations, customers, or regulatory obligations.

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

Risk acceptance: Formal acknowledgement and approval of residual risk for a defined period.

Configuration drift: Unauthorised or unintended movement away from an approved configuration state.

Exposure validation: Testing whether a theoretical weakness is practically reachable or exploitable.

Residual risk: Risk remaining after controls and remediation measures are applied.

Review Questions

Short Answer Questions

1. Distinguish a cloud misconfiguration from a vulnerability.

2. What problem does CIEM address that a conventional user directory may not address?

3. Why should CVSS or technical severity not be used as the sole prioritisation method?

4. What is the purpose of an exception expiry date?

5. Explain the relationship between DSPM and CSPM.

Long Answer Questions

1. Explain the roles of CSPM, CWPP, CIEM, DSPM, EASM, CAASM, and CNAPP in a cloud security programme.

2. Describe a complete workflow for discovering, prioritising, remediating, and verifying cloud security findings.

3. Discuss how exploitability, exposure, asset criticality, and business impact should influence remediation decisions.

4. Analyse the advantages and limitations of policy-as-code and automated remediation.

5. Explain why machine identities and attack paths require special attention in cloud environments.

Analytical / Application Questions

1. A public storage service contains no classified information, but its access policy permits a service identity to modify production network controls. Analyse the risk and recommend a prioritised response.

2. A critical vulnerability exists on a private production server protected by network segmentation, while a moderate vulnerability exists in a public container with access to sensitive data. Which should be addressed first, and why?

3. Design a governance model for a multi-cloud organisation that wishes to combine CSPM, CIEM, DSPM, and CNAPP while preserving business-owner accountability.

22. Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes posture management from exposure management?

A. Posture management examines only software vulnerabilities, while exposure management examines only compliance.

B. Posture management evaluates security conditions and policies, while exposure management considers whether weaknesses are reachable through plausible attack paths.

C. Posture management applies only to public cloud, while exposure management applies only to private cloud.

D. Posture management is performed after incidents, while exposure management is performed before deployment.

Correct Answer: B. Posture management evaluates security conditions and policies, while exposure management considers whether weaknesses are reachable through plausible attack paths.

Question 2

A service account can create network rules in a production account but has not recently used that permission. Which capability is most directly suited to analysing this risk?

A. DSPM

B. EASM

C. CIEM

D. CWPP

Correct Answer: C. CIEM

Question 3

Why might a medium-severity finding require faster remediation than a high-severity finding?

A. Medium-severity findings are always easier to exploit.

B. Severity scores are unrelated to vulnerabilities.

C. The medium-severity finding may involve greater exposure, asset criticality, or business impact.

D. High-severity findings should only be addressed during audits.

Correct Answer: C. The medium-severity finding may involve greater exposure, asset criticality, or business impact.

Question 4

Which action best addresses recurring insecure security-group rules created by deployments?

A. Suppress the resulting alerts.

B. Modify the infrastructure-as-code template and add a deployment guardrail.

C. Increase the vulnerability scanner frequency only.

D. Classify the affected assets as development systems.

Correct Answer: B. Modify the infrastructure-as-code template and add a deployment guardrail.

Question 5

What is the primary purpose of DSPM in the context of cloud exposure management?

A. To discover compiler errors in application code.

B. To identify sensitive data, its location, access, and exposure.

C. To replace identity and access management.

D. To manage external domain registration.

Correct Answer: B. To identify sensitive data, its location, access, and exposure.

Question 6

In the illustrative Northbridge Finance case, why was the notebook environment considered high risk?

A. It was labelled as a development environment.

B. It had no available logs.

C. It combined public reachability, a vulnerable package, excessive identity permissions, and sensitive data.

D. It used a managed cloud service.

Correct Answer: C. It combined public reachability, a vulnerable package, excessive identity permissions, and sensitive data.

Question 7

Which is the strongest example of a compensating control?

A. Documenting a vulnerability without changing anything.

B. Restricting network reachability while a permanent software fix is being prepared.

C. Changing the finding title in a dashboard.

D. Deleting the asset inventory record.

Correct Answer: B. Restricting network reachability while a permanent software fix is being prepared.

Question 8

What is a major limitation of fully automated remediation?

A. It cannot change cloud configurations.

B. It may cause service disruption when business dependencies are not understood.

C. It cannot operate on high-confidence findings.

D. It always produces more false negatives than manual review.

Correct Answer: B. It may cause service disruption when business dependencies are not understood.

Question 9

Which metric best indicates whether a posture programme is reducing recurring risk rather than merely closing alerts?

A. Number of dashboard views.

B. Number of policy rules created.

C. Recurrence rate of remediated findings and age-weighted exposure.

D. Number of security tools purchased.

Correct Answer: C. Recurrence rate of remediated findings and age-weighted exposure.

Question 10

Why are attack graphs useful in cloud vulnerability management?

A. They eliminate the need for asset ownership.

B. They show relationships among weaknesses, identities, reachability, and valuable assets.

C. They guarantee that every vulnerability is exploitable.

D. They replace all forms of security testing.

Correct Answer: B. They show relationships among weaknesses, identities, reachability, and valuable assets.