Cloud Security and SecOps Can’t Afford to Keep Ignoring Each Other
While cloud environments have become the default operating surface for most enterprises, the teams responsible for securing them still operate as if the cloud were a separate domain with its own gravity.
As cloud technologies entered the scene, many organizations didn’t have both the tools and expertise in traditional SecOps teams to handle cloud security risks. This led to a situation where cloud security teams run CNAPP tools focused on posture, misconfiguration, and compliance and more recently, runtime as well. SOC teams run SIEM, SOAR, and EDR focused on detection and response, and between those two worlds sits a gap that attackers have learned to exploit with increasing precision.
Other key factors that often contributed to the divide between the two included factors such as the Cloud Security team needing cloud-native telemetry and insights into API’s and the control plane, much of which the traditional SecOps tooling didn’t provide.
Organizationally there were also different ownership and budgets across the teams, as organizations stood up efforts to facilitate cloud migration such as “Cloud Centers of Excellence” and separate cloud security teams.
Lastly, early cloud security tools, such as CSPM were focused on posture (e.g. is this S3 bucket publicly exposed) and compliance, where SecOps was more focused on detection and response workflows to support activities such as incident response.
The organizational boundary between “cloud security” and “security operations” made sense when cloud was a workload migration story, but it doesn’t make sense when cloud is where the business runs and where the majority of attacks now land. As cloud adoption has matured and become an industry standard operating model, it is time for the way we handle cloud security and security operations to mature as well.
I’ve been writing about how AI is reshaping the threat dynamics around vulnerability discovery and exploitation, from the Vulnpocalypse to the AI cyber capability curve that shows frontier model capabilities steepening with every release. Those trends make the silo between cloud security and SecOps more than an operational inconvenience, they make it a structural liability.
When exploitation timelines compress from months to hours and adversaries operate at machine speed, having your posture management on one console and your detection and response on another isn’t a tooling preference, it’s an intentional blind spot with real-world consequences.
The Shadow Cloud SOC
IDC published a report titled “Bridging the CNAPP - SecOps Divide” that put a name to something most practitioners already feel. They call it the “shadow cloud SOC,” the phenomenon where cloud security teams end up performing SOC-like functions, investigating alerts, triaging incidents, and chasing threats in cloud environments, without any formal integration with the actual SOC or SecOps team.
The cloud security team builds its own investigation workflows, its own escalation paths, and its own dashboards because the SOC’s tooling wasn’t designed for cloud-native telemetry and the CNAPP wasn’t designed for real-time detection and response.
My friend James Berthoty of Latio Tech called out this tension in his recent presentation at fwd:cloudsec 2026 in a talk titled “Are We There Yet? Lessons from the 10 Year Cloud Security Ride”. In the talk James discusses the realities of disjointed tools because different feature sets are owned by different personas (e.g. AppSec, Cloud and SecOps) when it comes to CNAPP’s.
The result is two parallel security operations running against the same threat surface with different data, different context, and different response playbooks. IDC’s research found that the average organization uses 6 to 10 separate security tools to cover its cloud environment. 98% of organizations use at least two cloud service providers, and the teams operating these fragmented toolchains aren’t just dealing with tool sprawl.
They’re dealing with context fragmentation, where the information needed to investigate an incident is spread across multiple consoles that don’t share a common data model or timeline.
This isn’t a problem that happens because people are making bad decisions. It’s a structural outcome of how cloud security evolved. CNAPP emerged from the convergence of CSPM, CWPP, and CIEM. These are of course Cloud Security Posture Management (CSPM), Cloud Workload Protection Platforms (CWPP) and Cloud Infrastructure Entitlement Management (CIEM), which were tools aimed at addressing the configuration and posture of cloud environments, the security of cloud workloads and the entitlements associated with Cloud IAM.
Tools such as CSPM, CWPP and CIEM existed out of necessity, given some of the most persistent problems (which are still relevant now) in cloud environments included issues such as misconfigured resources, organizations poorly navigating the shared responsibility model with CSP’s, dealing with ephemeral workflows, containers and functions, as well as IAM and entitlement sprawl across their growing cloud account footprints.
Some of the specific questions these tools were aimed at answering include:
Is this S3 bucket publicly accessible?
Are these IAM permissions overly broad?
Is this container image running with known vulnerabilities?
These are important questions, but they’re fundamentally about the state of the environment at a point in time. They don’t tell you what’s happening right now from a runtime threat perspective. They don’t detect lateral movement, credential abuse, or data exfiltration in progress, and they don’t integrate with the incident response workflows that SOC teams depend on to contain and remediate active threats.
So cloud security teams built their own shadow operations to fill the gap, and the SOC, lacking cloud-native visibility, either ignored cloud alerts or tried to ingest them into tools that lacked the context to make sense of them.
As it goes in security, eventually disparate tools get consolidated into comprehensive platform solutions, which in this case was CNAPP. CNAPP consolidation came out of the need to address the point-tool sprawl, duplicated findings across the tooling, inconsistent context and asset identity, as well as teams struggling with alert fatigue and prioritization issues.
Ironically enough, in the age of AI-driven vulnerability discovery, prioritization is as critical as ever, as organizations race to keep up with the ever mounting list of CVE’s, misconfigurations and now Agentic IAM. Operating in a silo has costs, and it isn’t just budgetary, as it has cognitive impacts on security teams, and also keeps them from effectively reducing organizational risks.
The Cost of the Silo
The operational cost of this fragmentation is measurable. IDC’s North American Vendors and Tools Consolidation Survey found that 43% of organizations identified improved threat detection as their top objective for security tools consolidation.
34% cited faster incident response, and 32% cited streamlining operations and workflows. These aren’t aspirational answers, they’re responses from practitioners who are living with the consequences of fragmented toolchains every day and feeling those impacts in their work and ability to be effective in their roles.
When a cloud security team detects a suspicious configuration change and the SOC detects anomalous API behavior from the same principal in the same timeframe, those two signals should be correlated automatically, but the reality is that in most organizations today, they aren’t.
They land in different dashboards, get triaged by different teams with different escalation paths, and only converge, if they converge at all, through manual handoffs, Slack messages, ad hoc conversations and shared spreadsheets.
The mean time to detect (MTTD) stretches because neither team has the full picture in a consolidated fashion. The mean time to respond (MTTR) stretches because coordination between siloed teams adds friction at exactly the moment when speed matters most for mitigating organizational risks.
The math gets worse as cloud adoption accelerates. Cloud security alerts have increased 388% year over year, and the average cloud intrusion takes only 10 minutes from initial access to lateral movement.
A security architecture that requires manual coordination between two separate teams operating two separate toolchains can’t respond at the speed the threat demands.
This isn’t just a theoretical problem either, it’s the daily reality for security teams in large enterprises running multi-cloud environments with dozens of accounts, hundreds of services, and thousands of ephemeral workloads spinning up and down continuously, and is only going to be exacerbated by AI agents.
CNAPP Is Necessary but Not Sufficient
The industry has done a good job of consolidating cloud security posture capabilities into CNAPP platforms as I mentioned above, as it consolidated some of the emerging cloud security tools into a single comprehensive cloud security platform. Having misconfiguration detection, vulnerability management, identity analysis, and compliance monitoring in a single platform is a real improvement over the point-tool sprawl of five years ago.
But posture management answers the question “are we configured correctly?” It doesn’t answer “are we under attack right now?” One is a static posture perspective, the other is a runtime detection & response analysis.
I’ve also tried to touch on these pain points in prior pieces, such as “How ADR Addresses Gaps in the Detection & Response Landscape”, coming at it from the perspective of AppSec and SecOps, where AppSec and SecOps have similar divides as CloudSec and SecOps.
That distinction matters more than most CNAPP evaluations acknowledge. A CNAPP that identifies a misconfigured IAM role is valuable, but a CNAPP that identifies the misconfigured IAM role, detects that an adversary is actively exploiting it to exfiltrate data from a production database, and triggers an automated containment response in the same platform is a fundamentally different capability.
The first is a compliance finding, the second is threat defense.
IDC makes this point directly, arguing that CNAPP must evolve beyond posture management to include real-time cloud detection and response capabilities integrated with SOC workflows.
The alternative is the status quo, where CNAPP generates findings that feed into a ticketing system while the actual response happens somewhere else entirely, often too slowly to prevent the damage that the finding was meant to flag.
As I explored in The Attack Surface Exponential, the volume of code being pushed to production is accelerating dramatically, with GitHub commits heading toward 14 billion in 2026.
Every one of those commits can introduce a misconfiguration, a vulnerable dependency, or an overly permissive access grant in a cloud environment. The posture-only model of cloud security assumes those issues will be found and fixed before an adversary finds them first. The Vulnpocalypse has made that assumption wishful thinking, because AI is compressing the window between vulnerability discovery and weaponization from months to hours at marginal costs measured in dollars.
If you accept that posture alone can’t prevent all breaches, and every serious practitioner does, then the logical conclusion is that cloud security needs detection and response as a first-class capability, not a handoff to a separate team running separate tooling.
Why the Threat Tempo Forces the Issue
The silo between cloud security and SecOps was tolerable when attack timelines gave defenders time to coordinate. When exploitation timelines ran in weeks or months, having a cloud team generate a finding that eventually made it to the SOC queue was suboptimal but survivable, however that timeline no longer exists.
The AI cyber capability curve shows frontier AI models achieving increasing success on complex cyber tasks with every generation. When I covered Anthropic’s Project Glassswing results in The Receipts Are In, their partners using Claude for security had discovered over 10,000 high-and-critical-severity vulnerabilities in a single month, with discovery rates up more than 10x.
These same capabilities are available to adversaries, and the 2026 DBIR confirmed that vulnerability exploitation has become the leading initial access vector, with exploitation timelines compressing while remediation capacity stays flat.
This is the threat context in which the cloud security and SecOps silo persists. Adversaries aren’t coordinating through Slack and they aren’t handing off between specialized teams with different dashboards.
They’re running automated toolchains that move from reconnaissance to exploitation to lateral movement to exfiltration in continuous, machine-speed workflows. A defender architecture that fragments detection from response, and cloud visibility from SOC operations, is structurally disadvantaged against that kind of adversary.
The convergence of cloud security and SecOps isn’t simply a vendor talking point, it’s a requirement imposed by the threat tempo itself coupled with the security buyer side realities, and security leaders look to rationalize tool sprawl and bring order to the chaos.
What Convergence Looks Like in Practice
IDC’s framework for what they call the “unified cloud security operations platform” has a few characteristics that practitioners should be evaluating against. The core idea is a single platform that combines CNAPP’s posture management capabilities with real-time cloud detection and response, feeding into the same investigation and incident response workflows that the SOC uses across the rest of the enterprise.
This means a common data model that normalizes cloud telemetry (API logs, control plane events, workload behavior, identity activity) with endpoint, network, and identity telemetry from non-cloud environments.
It means correlation engines that can connect a misconfigured resource, a suspicious identity action, and a data access anomaly into a single incident rather than three separate alerts in three separate consoles and none of the connecting context. It also means response automation that works at cloud speed, automatically revoking credentials, isolating workloads, or blocking network paths within seconds rather than waiting for a human to context-switch between platforms. When we hear fighting adversaries with “machine speed”, these are the sort of capabilities that come to mind.
Resilient Cyber’s partner, Palo Alto Networks’ Cortex Cloud is an example of what this convergence can look like in practice, combining what was previously the Prisma Cloud CNAPP with Cortex’s cloud detection and response capabilities into a single platform.
The architectural choice to unify posture management and SOC-grade detection and response in one console reflects the same structural argument IDC is making. When cloud security posture data and real-time threat data live in the same platform, the SOC and the cloud security team stop being separate organizations with separate toolchains and start operating against a shared picture of risk and threat activity.
If we’re being honest, it’s also a push to deliver what only some of the more mature and capable security industry leaders are capable of, given the breadth of coverage and capabilities it demands.
The practical benefit for security leaders is straightforward. Instead of maintaining parallel operations with different escalation paths, you get a single workflow where a posture finding and an active exploit of that same misconfiguration surface in the same investigation timeline, with the context and response actions available in one place.
That reduces the mean time to detect, the mean time to respond, and the operational overhead of maintaining two separate security operations against the same environment while also unifying disjointed tooling in the security tech stack.
The Structural Debt That Compounds
The silo between cloud security and SecOps is a form of structural debt that compounds as cloud adoption grows, as attack surfaces expand, and as adversary capabilities accelerate.
Every multicloud account added, every new service deployed, every ephemeral workload spun up increases the volume of telemetry that needs to be correlated and the speed at which threats need to be detected and contained. Running that through fragmented toolchains with manual handoffs between teams isn’t just inefficient. It’s a scaling problem that gets worse with every increment of cloud adoption.
IDC found that organizations increasingly prefer a single console over managing 10 or more separate dashboards. That preference isn’t driven by aesthetics. It’s driven by the operational reality that context fragmentation directly degrades the ability to detect and respond to threats at the speed the environment demands due to the disjointed communication and collaboration among teams, not to mention the potential cognitive overload for practitioners.
For practitioners evaluating CNAPP solutions today, we can all agree that posture management matters. That said, it is valid t o ask whether a CNAPP that stops at posture, that generates findings but doesn’t detect active threats and doesn’t integrate with SOC response workflows, is sufficient for the threat environment we’re operating in right now, especially against the backdrop of the AI cyber capability curve.
The convergence of cloud security and SecOps shouldn’t just be a future-state aspiration, and instead is a requirement that the current generation of threats are imposing.
I anticipate organizations that recognize this and build accordingly operate with a fundamentally different risk profile than those still running parallel security operations and hoping the handoff between teams is fast enough, especially when teams are already often overwhelmed and struggling to keep pace.