How Wiz Dominates Using Agentless Cloud Security Graphing
For years, enterprise cloud security was plagued by host-based agent exhaustion. Security teams struggled to install, update, and maintain monitoring daemons across thousands of virtual machines, container instances, and serverless environments.
These agents frequently caused performance degradation, compatibility conflicts, and system crashes, leading to severe visibility gaps. Any unmanaged resource, legacy server, or shadow IT instance lacking an agent remained invisible to security audits.
This landscape demanded a paradigm shift away from runtime interception toward out-of-band monitoring. The result was agentless cloud security posture management (CSPM), a methodology pioneered by Wiz.
The Shift from Host Agents to API-First Inspection
The traditional host-based model relied on installing an agent—a daemon with root privileges—on every operating system instance to monitor system calls and inspect local files. In modern cloud-native environments, this approach introduces massive operational overhead.
Autoscaling groups dynamically spin instances up and down, making agent synchronization difficult. Additionally, serverless runtimes and managed container services often restrict host-level access entirely, preventing agent installation. Wiz resolved this by introducing an API-first inspection mechanism that bypasses the operating system runtime entirely.
Instead of executing code inside the workload, the platform interacts directly with cloud provider control planes (such as AWS, Google Cloud, and Microsoft Azure) via read-only API access. By utilizing native cloud APIs, the security platform gains complete, instantaneous visibility into every resource deployed across the infrastructure. This approach ensures there are no blind spots: if a resource exists, it is detected and cataloged automatically.
The Mechanics of Agentless Snapshotting
To analyze the files, operating system configurations, and applications running on virtual machines without using host agents, the platform employs a technique known as block storage snapshotting. When a virtual machine needs to be scanned, the platform triggers a cloud API call to take a read-only snapshot of the machine's block storage volume (such as an AWS EBS volume or GCP Persistent Disk). Once the snapshot is created, it is copied and mounted to an isolated, secure scanning environment managed by the security platform within the same geographical region.
Inside this isolated scanning sandbox, the platform inspects the mounted filesystem out-of-band. Because the analysis occurs on a copy of the block storage, it consumes zero CPU, memory, or network resources on the target production server, eliminating performance degradation.
The scanner analyzes the operating system configuration, looks for installed packages, and identifies application-level dependencies (parsing lockfiles like package-lock.json). It also detects hardcoded secrets—including API keys, database credentials, and private keys—before deleting the snapshot to ensure data isolation.
During the out-of-band scan, the inspection engine focuses on identifying a wide range of security risks, which include:
- Vulnerable operating system packages (e.g., outdated OpenSSL or glibc libraries).
- Embedded application credentials and private cryptographic keys exposed in code repositories.
- Misconfigured daemon parameters and loose file permissions on critical system assets.
- Shadow binaries and unauthorized executables running within container layers.
Building the Cloud Security Graph
Identifying individual vulnerabilities, misconfigured resources, or leaked secrets in isolation provides limited security value. In complex enterprise environments, a high-severity vulnerability on a fully isolated virtual machine poses little threat, whereas a low-severity vulnerability on a public-facing server can lead to a catastrophic breach if that server has access to highly privileged credentials. To solve this, the platform aggregates all gathered data—including software vulnerabilities, configuration settings, identity and access management (IAM) permissions, and network pathways—into a unified graph database, creating the Cloud Security Graph.
Nodes in this directed graph represent specific cloud resources, such as virtual machines, storage buckets, IAM roles, security groups, database instances, and Kubernetes pods. Edges represent the relationships and access routes between these resources, including network connectivity, IAM permissions, trust relationships, and operational dependencies. By representing the entire cloud environment as a graph, the platform bridges the gap between infrastructure configuration, network topology, identity management, and software vulnerability intelligence, enabling security teams to see how their resources interact in the real world.
Attack Path Analysis and Traversal Logic
With the entire cloud infrastructure mapped as a graph, the platform employs advanced graph traversal algorithms to identify critical attack paths. An attack path represents a chain of relationships that an adversary could exploit to travel from the public internet to high-value target assets, such as databases containing sensitive customer data or intellectual property. The system calculates these paths by evaluating network exposure and identity access permissions simultaneously.
For example, the detection engine looks for specific combinations, such as an internet-facing load balancer routing traffic to a virtual machine containing a remote code execution vulnerability, which is associated with an IAM role that has write access to an S3 bucket containing sensitive customer data. By identifying these toxic combinations, the platform filters out thousands of irrelevant alerts, allowing engineering teams to focus on the handful of critical security risks that pose a genuine threat to their data assets.
Ingestion Pipeline and Planetary-Scale Graph Scaling
Processing and maintaining a real-time security graph at planetary scale introduces significant data engineering challenges. Large enterprise customers operate across multiple cloud providers with tens of thousands of projects and millions of active resources.
The ingestion pipeline must handle continuous API polling, event-driven webhooks, and asynchronous snapshot processing without falling behind. This requires a distributed processing pipeline that normalizes diverse cloud metadata into a standardized schema.
High-throughput queues handle the initial load, while specialized graph databases process updates asynchronously to maintain graph consistency without impacting scan times.
Securing the Cloud-Edge Fabric with Bramsley
While agentless security graphs are highly effective at mapping static and control-plane vulnerabilities in cloud environments, they cannot monitor or intercept active malicious traffic targeting transient edge servers and distributed worker systems.
"By embedding active threat mitigation layers directly within edge middlewares, Bramsley sanitizes and validates incoming requests before they reach the core cloud subnet, neutralizing vulnerabilities mapped on the security graph in real time."
Our specialized edge framework implements real-time request sanitization, dynamic edge identity validation, and out-of-band telemetry logging. Reach out to Bramsley's security architecture team to expand your zero-trust edge security perimeter and enforce robust compliance from edge to cloud.