Completing CNAPP with DSPM closes the cloud data visibility gap

At a glance

What this is: This report argues that CNAPP is incomplete without DSPM because cloud teams still lack sufficient visibility into where sensitive data and related exposure paths actually live.

Why it matters: It matters because IAM, cloud security, and NHI teams need data visibility to govern secrets, access paths, and blast radius, not just posture and workload alerts.

Context

Cloud security programmes often detect misconfiguration and runtime risk before they can explain which sensitive data is actually exposed. That leaves a governance gap between posture management and data protection, especially in environments where cloud workloads, service accounts, and secrets change faster than manual review can keep up. The identity angle is real here because access paths, not just assets, determine how sensitive data becomes reachable.

DSPM closes that gap by discovering and classifying data, then tying it back to the controls that govern exposure and access. In practice, that changes CNAPP from a workload-centric control plane into a more complete cloud governance model that can support identity, NHI, and data security decisions together.

Key questions

Q: What breaks when CNAPP is used without DSPM for cloud data governance?

A: CNAPP can show that a workload or account is exposed, but without DSPM it often cannot show whether sensitive data is actually at risk. That leaves teams with posture evidence but not data context, which makes prioritisation, compliance reporting, and breach impact assessment weaker. The practical failure is visibility without sensitivity-aware decision-making.

Q: Why do exposed cloud secrets become a data access problem so quickly?

A: Because secrets often belong to service accounts or workloads that already have direct paths to storage, APIs, and downstream services. Once a key or token is exposed, the attacker may not need further privilege escalation if the identity already reaches sensitive data. The risk is not the secret alone, but the access it unlocks.

Q: How do security teams know if public cloud storage controls are working?

A: Measure how quickly changes to bucket policies and ACLs are detected, and track how many identities can alter public access without approval. If sensitive objects are still landing in buckets that external scanners can find, the control is not working. Effective governance should show narrow change authority, clear logs, and rapid remediation of drift.

Q: Should organisations treat NHI governance and cloud data security as the same problem?

A: They are distinct disciplines, but in cloud environments they frequently converge on the same failure path. A service account, token, or API key is only dangerous in context of the data it can reach, so governance should join identity inventory with data classification. Separate teams can operate them, but separate risk views should not.

Technical breakdown

Why CNAPP leaves a data visibility gap

CNAPP unifies cloud posture, workload, and runtime controls, but those signals do not automatically tell teams where sensitive data resides or how it is reachable. Without data classification and context, security teams may know that a workload is exposed without knowing whether it touches regulated data, proprietary data, or low-value data. That distinction matters because risk, remediation priority, and compliance evidence all depend on it. DSPM adds that missing layer by discovering sensitive data across cloud stores and linking it to the surrounding exposure surface.

Practical implication: Treat CNAPP findings as infrastructure context and use DSPM to determine whether the affected systems actually contain sensitive data.

How DSPM changes attack-surface analysis for cloud identities

Cloud data exposure is rarely just a storage problem. Access paths often run through service accounts, application credentials, API keys, and workload permissions that connect identity to data movement. When those identities are overprivileged or poorly inventoried, attackers can move from secret exposure to data access without needing to break the cloud control plane. That is why the identity bridge matters here: the data layer becomes actionable only when tied to the non-human identities and permissions that can reach it.

Practical implication: Map sensitive datasets to the NHI credentials and workload identities that can reach them, then reduce standing access where the mapping shows unnecessary reach.

Why verified exploit paths make data-centric defence practical

The article’s references to exposed AI API keys, cloud secrets, and unpatched vulnerabilities point to a chain-based threat model rather than isolated weaknesses. Attackers do not need every control to fail at once if they can connect one exposed secret to a workload with excessive reach and then pivot into critical data. That is why the rise of shadow AI and secrets sprawl changes the cloud security problem: the real question becomes which paths are actually exploitable, not just which assets are misconfigured.

Practical implication: Prioritise controls that break the chain from exposed secret to reachable workload to sensitive data, instead of treating each issue as a separate ticket.

NHI Mgmt Group analysis

CNAPP without DSPM leaves a blind spot at the point that matters most: data reachability. Cloud teams have spent years improving posture and workload detection, but those controls stop short of answering whether an exposed system contains sensitive data that changes the risk calculus. Once a dataset is discovered, the governance question shifts from generic exposure to controllable blast radius. Practitioners should treat data visibility as a core part of cloud security architecture, not an adjacent reporting function.

Service accounts are the missing connective tissue between cloud data and cloud compromise. The report’s visibility problem is not just about storage discovery, it is about the identities that can read, move, and export data once they are compromised. That makes NHI governance central to cloud data protection because service accounts and tokens often outlive the workloads they support. The practical conclusion is straightforward: data governance fails if machine identities are invisible or overbroad.

Shadow AI turns secrets management into a data governance problem, not only an application problem. AI-specific secrets and exposed API keys create new paths into cloud workloads, but the deeper issue is that the organization may not know which data those paths can reach. That combines AI security, NHI exposure, and cloud data classification into one control challenge. Security teams need to govern the credential-to-data path as a single risk surface.

Data-centric cloud defence is becoming the right unit of decision-making for cloud security leaders. Posture findings, identity findings, and data findings are individually useful, but they only become operational when correlated into one view of risk and ownership. That is where CNAPP plus DSPM changes the programme conversation: from detecting cloud issues to understanding which issues can actually expose the crown jewels. The practitioner implication is to re-prioritise remediation around sensitive data reachability.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: Ultimate Guide to NHIs — Key Challenges and Risks

What this signals

Data visibility now sets the ceiling for cloud security maturity. If security teams cannot connect exposed workloads to the data they protect, CNAPP remains a control-plane view rather than a risk view. That is where DSPM changes the operating model: it gives cloud and identity teams a common language for exposure, sensitivity, and prioritisation.

Service-account blind spots are a governance issue, not just an operational annoyance. Only 5.7% of organisations have full visibility into their service accounts, and that lack of inventory makes it difficult to know which identities can touch sensitive datasets. In a cloud estate, invisible machine access is often the shortest path from misconfiguration to data exposure.

Shadow AI is accelerating the need for data-centric NHI controls. When AI-specific secrets and cloud credentials proliferate, teams need to govern not only where secrets are stored but also which data those secrets can reach. The practical shift is toward blast-radius management based on identity, data sensitivity, and exploitability together.

For practitioners

• Map sensitive data to reachable identities Correlate cloud data locations with the service accounts, tokens, and workload identities that can access them, then remove unnecessary paths.
• Classify data before you triage posture Use data classification to separate high-impact exposures from routine misconfigurations so remediation follows business sensitivity, not alert volume.
• Inventory AI-specific secrets and API keys Track exposed cloud secrets, AI API keys, and application credentials as first-class cloud exposure objects, not only as secrets-management events.
• Reduce standing machine access to data stores Review non-human identities that can reach sensitive datasets and narrow their scope so compromise does not immediately become data access.

Key takeaways

• CNAPP alone can surface cloud posture issues, but DSPM is what turns those findings into data-aware risk decisions.
• Visibility into service accounts and workload identities remains weak across most organisations, which makes sensitive data reachability hard to govern.
• The right control objective is to reduce the number of identities that can reach crown-jewel data, not just to reduce the number of alerts.

Key terms

• Cloud Visibility: Cloud visibility is the ability to see workloads, identities, entitlements, configurations, and data exposure across an environment as it changes. In migration work, it is the baseline control that makes prioritisation, compliance, and remediation possible because hidden assets and access paths are the first place drift accumulates.
• Data Security Posture Management: Data Security Posture Management, or DSPM, is the continuous discovery and monitoring of where sensitive data lives, how it is exposed, and where policy gaps exist. Its value rises when it feeds remediation rather than generating findings alone, especially in environments where AI expands the number of data paths.
• Service account visibility: The ability to discover, attribute, and review non-human accounts across an environment. For NHI governance, visibility includes owner mapping, permission history, and lifecycle state so that access is not left to drift in legacy or private systems.
• Verified Exploit Path: A verified exploit path is a realistic sequence of misconfigurations, vulnerabilities, and exposures that an attacker can use to move from entry to impact. It matters because it focuses security attention on reachable compromise routes, not on theoretical weaknesses with no practical path.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the cloud and data security decisions their programmes depend on.