Agentless vs Agent-Based CVE Scanning
Both approaches find missing patches. Both, by default, share one blind spot: a host can show zero open CVEs while still running the vulnerable code in memory. Here is how the two models actually differ, and the failure mode that makes a green dashboard lie.
The short version
| Agentless | Agent-based | |
|---|---|---|
| Deployment | Nothing to install; connects over SSH/API with credentials | Install and maintain an agent on every host |
| Coverage | Ephemeral, unmanaged, and short-lived hosts included | Only hosts where the agent is installed and healthy |
| Telemetry depth | Point-in-time, per scan | Continuous, real-time |
| Operational cost | Credential management | Agent lifecycle, version drift, resource use |
| Patched-but-not-rebooted | Detectable via running-vs-installed kernel check | Detectable, but only if the agent reports it |
When agentless wins
Agentless CVE scanning authenticates to a host, enumerates installed packages, and matches them against live advisory feeds without deploying anything. It covers the boxes an agent never reaches: autoscaled instances that live for an hour, contractor-managed servers, appliances you cannot install software on. It is the fastest way to get fleet-wide coverage, and it scales to hosts you did not know you had.
When an agent earns its keep
An agent gives you continuous telemetry: the moment a package changes or a process starts, you know, without waiting for the next scan window. For a small set of crown-jewel hosts where real-time matters, that is worth the lifecycle cost of keeping an agent installed, updated, and healthy on every one of them.
The blind spot both share: patched, not rebooted
Here is the failure that produces a green dashboard on a vulnerable fleet. Installing a patched package updates the version on disk. It does not swap the kernel your host is running, and it does not restart the service holding the vulnerable library in memory. Until the host reboots, the fix is staged, not live. A scanner that matches installed package versions, agentless or agent-based, reports the CVE as fixed and moves on.
The check is simple and almost nobody surfaces it: compare the running kernel (uname -r) to the newest kernel in /boot, and read the reboot-required marker. If they disagree, the host is patched but exposed.
How ArcScan handles it
- Detect: every agentless probe records the running kernel, the newest installed kernel, and the reboot-required flag.
- Flag: hosts that are patched-on-disk but running an older kernel show as "patched, pending reboot" instead of hiding behind a green check.
- Remediate: ArcScan generates the fix as an Ansible playbook grouped per package, and when the patch is a kernel it reboots the host so the fix is actually running.
- Prove it: remediations are recorded as fixed with an audit trail, so patching a fleet reads as measurable progress, not data that vanished.
Common questions
Is agentless or agent-based CVE scanning better?
Neither universally. Agentless covers more of your fleet with less to maintain; agents give deeper real-time telemetry on the hosts they are installed on. Most teams run agentless for breadth and reserve agents for a critical few. What matters more than the model is whether either one catches the patched-but-not-rebooted gap.
Why does a patched host still show as vulnerable?
Because the patched package is installed on disk but the vulnerable kernel or service is still running in memory. Until a reboot (or service restart), the fix is not in effect.
How do you find patched-but-not-rebooted hosts?
Compare the running kernel to the newest installed kernel and check the reboot-required marker. If they disagree, the host has staged its patches but not activated them.
Scan your fleet free →