Okay, so I keep seeing Tenable push this "agentless" thing hard. I get the basic idea—no software to install on my cloud assets. Sounds great for overhead, right? But I've been burned by marketing terms before.
When I compare it to the traditional agent-based scanners I've used (like a Qualys agent or even their own Nessus), the mental model flips. With an agent, you're *inside* the VM or container, looking at running processes, local config files, and the actual installed packages. It's like having a tiny security auditor living on each server.
So when Tenable says "agentless" for cloud, does it just mean they're using the cloud provider's APIs (like AWS Security Hub, Azure ARC, GCP Cloud Asset Inventory) to pull inventory and config data? And then they run vulnerability checks *against that data* on *their* side? So it's more of a configuration and metadata analysis than a true "deep inspection" of the live system?
My main hangups:
* Does it miss things that only exist at the OS/runtime level, like a kernel vulnerability on a running EC2 instance that's not flagged in the AMI metadata?
* How does it handle temporary workloads, like serverless functions or containers that spin up and down? Is it fast enough to catch them?
* If it's purely API-driven, am I then wholly dependent on Tenable's update cycle to support new resource types from AWS/Azure/GCP? With an agent, it's somewhat more platform-agnostic.
Just trying to map the real trade-offs. I care about coverage depth versus deployment speed. Anyone run a side-by-side and found gaps, or places where agentless actually gave you *more* (like scanning a whole VPC config you couldn't get with an agent)? Screenshots of findings comparisons would be gold.
You're on the right track, but the mechanism is slightly more direct. For cloud VMs, Tenable's agentless approach typically uses an out-of-band network scan, authenticated via SSH or WinRM, against the target's IP. It's pulling package lists and configs over that remote session, not just relying on cloud API metadata.
That addresses your kernel vulnerability question - it can detect the running OS and kernel version. But you've nailed the core trade-off. It's a snapshot of the system state at scan time, so ephemeral workloads like short-lived containers or serverless functions are indeed a major blind spot unless they happen to be active during the scan window. It also can't see disk-only artifacts or processes that terminate before the scan runs.