A recent piece on The Hacker News laid out a scenario most security leaders recognize immediately: a board member asks a straightforward question — “How exposed are we right now?” — and the CISO reaches for three different dashboards, two spreadsheets, and a caveat. Not because the CISO lacks skill, but because the tooling was never designed to produce a unified answer.
That article struck a nerve because it named the structural problem rather than blaming the people. The typical mid-size or growth-stage enterprise runs an identity provider, a CSPM or CNAPP, an EDR, a SIEM, and at least one vulnerability scanner, plus a handful of SaaS applications with their own permission models. Each tool is accurate about its own slice. None of them see how the slices connect. Attackers, of course, don’t care about tool boundaries.
This post unpacks that problem and walks through what it takes to actually close the visibility gap — architecturally, not just politically.
The board asks three questions. Most CISOs cannot answer them.
Board-level security conversations have matured. Directors no longer ask “are we compliant?” in isolation. The questions that come up most often now sound like this:
1. “If an attacker got in today, what is our blast radius?”
This requires understanding not just which assets exist, but how they connect. A misconfigured S3 bucket is one thing. A misconfigured S3 bucket that an over-privileged Lambda role can read, which is triggered by a public API Gateway endpoint, which runs on an EC2 instance with an unpatched CVE — that is a blast radius. Answering the question means tracing relationships across compute, identity, network, and data layers simultaneously.
2. “Where are we most exposed, and what are we doing about the top five risks?”
This sounds simple. It is not. “Most exposed” requires context: exposure to the internet, sensitivity of the data behind the asset, the identity chain that can reach it, and whether compensating controls exist. A vulnerability scanner gives you CVE counts. A CSPM gives you misconfiguration counts. Neither gives you a ranked, contextual view of where actual risk concentrates.
3. “Are we getting better or worse quarter over quarter?”
Trend reporting requires consistent measurement. When each tool uses its own severity model, its own asset inventory, and its own definition of “resolved,” stitching together a trend line means normalizing across five or six different data models every quarter. Most teams do this in spreadsheets, which means the answer is always stale by the time it reaches the board deck.
These are reasonable questions. The inability to answer them cleanly is not a failure of the security team. It is a failure of the architecture underneath the security program.
Why the tool stack is the root cause — not the team
Security teams are not short on data. They are drowning in it. The problem is fragmentation, not scarcity.
Each tool owns a silo
An IdP like Okta or Entra ID knows who has access to what — within its own scope. It does not know that a particular identity also has an IAM role in AWS that grants s3:* on a bucket containing PII. A CSPM knows the bucket is misconfigured. It may not know who can reach it. An EDR knows a host is behaving anomalously. It does not know the host has a database behind it that is logging queries to a public CloudWatch log group.
Every tool answers its own question perfectly. No tool answers the cross-domain question: “Given this misconfiguration, this identity, this vulnerability, and this data store — what is the actual risk?”
Alert fatigue is a symptom, not the disease
The average mid-market security team sees thousands of findings per week across their tools. The instinct is to triage by severity. But severity in isolation is misleading. A “critical” CVE on a host that has no network path to the internet and no access to sensitive data is a lower-priority item than a “medium” misconfiguration on a public-facing load balancer that proxies to a database with customer records. Without context, teams chase the wrong findings. This is well-documented across the industry and is one of the core arguments in the Hacker News piece.
Integration layers are duct tape
Many teams try to solve fragmentation with SIEM correlation rules, SOAR playbooks, or custom scripts that pull data from APIs. This works until it doesn’t. API schemas change. Correlation rules drift. The engineer who wrote the integration leaves. What was supposed to be a unified view becomes another maintenance burden — and another source of stale data when the board asks their questions.
The real solution is not more integration. It is fewer seams.
What “correlated context” actually means in practice
“Context” has become a marketing term. Every vendor claims it. What matters is whether the platform can answer relational questions across domains without requiring the analyst to manually stitch the picture together.
Correlated context means:
-
Identity-to-asset mapping. Not just “this IAM role exists” but “this IAM role can assume this other role, which grants access to these three S3 buckets, one of which is public.” This is what a strong CIEM layer provides — identity correlation that traces effective permissions across trust boundaries, not just policy-level declarations.
-
Vulnerability-to-exposure mapping. A CVE on a host matters differently depending on whether the host has a public IP, whether a security group allows inbound traffic on the relevant port, and whether the host sits in a subnet with a NAT gateway or a direct internet gateway route. A good CSPM with contextual severity evaluates the misconfiguration in the context of the asset — exposure, data sensitivity, identity chain — rather than assigning a flat per-rule score.
-
Data sensitivity awareness. Knowing that a database exists is table stakes. Knowing it contains PII, that its access logs are not being monitored, and that a service account with permanent credentials can reach it — that is contextual risk. This is where capabilities like database activity monitoring become part of the security graph rather than a separate compliance checkbox.
-
Temporal context. Who accessed what, when, and whether that access was expected. CloudTrail events, Entra ID sign-in logs, and GCP audit logs are only useful if they are correlated with the asset graph. An anomalous login matters more when it touches an asset with known misconfigurations.
When these layers are correlated in a single data model, the security team can answer the board’s questions in minutes rather than weeks.
The attack-path perspective: how attackers see your environment
Attackers do not think in tool categories. They think in paths. A typical cloud compromise chain looks something like this:
- Initial access: Stolen credentials from a phishing campaign or a leaked service account key in a public repository.
- Reconnaissance: Enumerate what the compromised identity can access. Discover it can assume a cross-account role.
- Lateral movement: Use the cross-account role to reach a staging environment. Find an EC2 instance with an IMDSv1 endpoint still enabled.
- Privilege escalation: Extract temporary credentials from the metadata service. Discover the instance role has overly broad permissions.
- Data access: Use the escalated permissions to read an S3 bucket. The bucket contains database backups. The backups contain customer data.
Every step in that chain touches a different tool’s domain. The IdP owns step one. The CSPM might flag the IMDSv1 issue in step three. The vulnerability scanner might notice an unpatched package on the EC2 instance. The SIEM might see the CloudTrail events. But no single tool traced the path from stolen credential to data exfiltration.
This is the visibility gap. And it is the gap the board is implicitly asking about when they say “how exposed are we?”
Understanding attack paths requires a graph — a data structure that models assets as nodes and relationships as edges. Not a flat list of findings. Not a spreadsheet of vulnerabilities. A graph.
What a unified asset graph changes
The argument for a unified CNAPP+ platform is not about having fewer vendor logos on a slide. It is about having one data model that represents your entire cloud environment as a connected graph.
One graph, not five dashboards
Cloudanix’s asset graph indexes over 300 resource types with typed relationships between them. Compute instances, IAM roles, policies, security groups, VPCs, S3 buckets, RDS instances, Lambda functions, Kubernetes pods, container registries, code repositories — all represented as nodes in a single graph with edges that describe how they relate.
That means a single query can answer: “Show me every public-facing asset that has a critical CVE, is accessible by an over-privileged identity, and stores or processes sensitive data.” That is not a report you can build from five separate tools. It is a question that only a graph can answer efficiently.
Contextual severity replaces flat scoring
Traditional tools assign severity per rule. “This security group allows 0.0.0.0/0 inbound on port 22” is always a high finding, regardless of whether the instance behind it is a throwaway dev box or the production database server.
Contextual severity — the kind Cloudanix CSPM provides — evaluates the misconfiguration in context. The same open port is scored differently based on:
- Whether the asset is internet-exposed or behind a private subnet
- What data the asset can access (PII, financial records, internal only)
- What identities can reach the asset and what permissions they carry
- Whether compensating controls (WAF, network ACLs, monitoring) are in place
This is how you go from 3,000 findings to 30 that actually matter. And those 30 are the ones you bring to the board.
Surfaces other platforms miss
Most CNAPP platforms cover posture and workload protection. Fewer extend into identity correlation, data security, and access governance. Cloudanix covers surfaces that other platforms treat as separate products:
-
Just-in-time access: Eliminating standing privileges is the single most effective control against lateral movement. JIT replaces permanent role assignments with time-bounded, approval-gated access. When a developer needs production database access, they request it, it gets approved (or auto-approved against policy), and it expires automatically. No standing credentials to steal.
-
Database activity monitoring: Most CNAPP platforms stop at the compute and network layer. They do not monitor what queries are running against your databases, who is running them, and whether the access pattern is normal. DAM closes that gap — and it feeds into the same asset graph, so a suspicious query pattern on an RDS instance is automatically correlated with the IAM identity that initiated it and the network path that allowed it.
-
Natural-language search and BYOR API: Security teams should not need to learn a proprietary query language to ask questions about their environment. Natural-language search makes the graph accessible to anyone on the team. And for teams that want to build their own tooling on top of the graph, the Bring Your Own Rules API means the platform is extensible, not a black box.
Practical consolidation: where to start
Tool consolidation is not a weekend project. It is a multi-quarter initiative that requires sequencing. Based on patterns we see across Cloudanix customers, here is a practical starting point.
Step 1: Anchor on CSPM and build outward
Start with cloud security posture management. This is where the highest volume of findings live and where contextual severity has the most immediate impact. If you are evaluating CSPM tools, prioritize platforms that ingest identity data and network topology natively, not as an add-on.
Step 2: Layer in identity correlation
Once posture is covered, bring identity into the same platform. CIEM — cloud infrastructure entitlement management — should not be a separate product with a separate data model. It should be a lens on the same graph. Effective permission analysis, least-privilege recommendations, and identity-to-asset mapping should be queryable alongside misconfigurations.
Step 3: Extend to data and access governance
This is where JIT access and database activity monitoring fit. These capabilities are force multipliers because they reduce standing access (the primary vector for lateral movement) and provide runtime visibility into data-layer activity (the layer where breach impact actually occurs).
Step 4: Retire the tools you have outgrown
Once the unified platform covers posture, identity, data, and code — the CNAPP+ surface — audit your existing stack. Identify the tools that are now redundant. Quantify the license cost, the integration maintenance cost, and the analyst time spent context-switching between dashboards. Present the consolidation case to the CFO alongside the security case. Both arguments are strong.
For teams looking to structure this as a formal initiative, the tool consolidation use case walks through the assessment framework in more detail.
Step 5: Define shared metrics
Consolidation is not just about fewer tools. It is about consistent measurement. When posture, identity, data, and code all live in the same platform, you can define metrics that span domains:
- Mean time to contextual risk resolution (not just “time to remediate a finding,” but time to resolve the cross-domain risk chain)
- Percentage of assets with identity-aware severity scoring
- Standing privilege ratio (what percentage of active identities have permanent access versus JIT-gated access)
- Data-layer visibility coverage (what percentage of databases and data stores are monitored for access patterns)
These metrics are board-ready because they describe actual risk posture, not tool output volume.
Building board-ready security reporting from a single platform
The board does not want dashboards. They want answers to their three questions, delivered in plain language, backed by data they can trust.
Answer 1: Blast radius
A unified graph lets you model blast radius directly. Starting from any compromised identity or exposed asset, traverse the graph to see what else becomes reachable. This is not hypothetical — it is a real-time computation over the asset graph. Present it as: “If this identity were compromised, the attacker could reach X assets, including Y that contain sensitive data. Here are the three remediation actions that reduce the blast radius by Z percent.”
Answer 2: Top risks
Contextual severity surfaces the findings that actually concentrate risk. Instead of presenting a list of 2,500 findings sorted by CVSS score, present the top five risk chains — each one a connected path from exposure to data — with a clear remediation plan for each. Board members understand “this path connects a public endpoint to a customer database through an over-privileged service account” far better than “we have 47 critical findings in our CSPM.”
Answer 3: Trend over time
When everything is in one platform, trend reporting becomes a query, not a spreadsheet exercise. Track the metrics defined in Step 5 across quarters. Show the board a single chart that answers “are we improving?” with data that comes from a single, consistent source.
Make the reporting cadence sustainable
If reporting requires a two-week war room every quarter, the process is broken. A unified platform should let you generate the board-ready report in hours, not weeks. Automate what can be automated. Reserve human analysis time for the narrative — the “here is what these numbers mean for our business” layer that the board actually cares about.
The consolidation conversation is a strategy conversation
The Hacker News article frames this as a tool problem, and it is. But it is also a strategy problem. The CISO who brings a consolidation plan to the board is not just asking for a budget reallocation. They are making an architectural argument: our security program cannot answer the questions that matter because the data model is fragmented. The fix is structural, not incremental.
That argument is easier to make when you can point to a platform that already unifies the layers — posture, identity, data, code, and runtime — into a single graph. It is easier still when that platform covers surfaces like JIT access and database activity monitoring that most competitors treat as separate products.
The board’s questions are not going to get simpler. The threat landscape is not going to get friendlier. The security team is not going to double in size. The only lever that scales is architecture.
If you are a CISO preparing for your next board conversation and the gap between “what the board asks” and “what your tools can answer” feels uncomfortably wide, it may be time to evaluate whether the tooling architecture itself is the constraint. Take a look at Cloudanix CNAPP+ — one graph, one platform, one set of answers — and see if it closes the gap for your environment.
For more perspectives on cloud security strategy, risk management, and practical implementation, explore the Cloudanix blog.
