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 with credentials over SSH, WinRM, SNMP, SMB, IPMI, or AWS SSM | Install and maintain an agent on every host |
| Coverage | Reaches unmanaged hosts and appliances you cannot install software on, given credentials and network reachability. Hosts that live and die between scan windows are still missed | 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. In ArcScan that means nine feeds, NVD, OSV, GHSA, RHSA, USN, DSA, Alpine, ALAS and MSRC for Windows, with distro-scoped version-range matching so a Debian backport is not reported as an unpatched upstream release. It covers the boxes an agent never reaches: autoscaled instances that outlive one scan interval, 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. It also reaches into segmented networks where nothing outside can open a connection inward. 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. ArcScan's own optional agent, Arc Probe, is cosign-signed, speaks mTLS, connects outbound only, and collects the reverse-dependency and running-service data that makes pre-apply blast radius accurate.
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 credentialed SSH probe records the running kernel, the newest kernel installed in
/boot, and the distribution reboot-required marker. Linux hosts today; Windows probes record the running kernel version only. - Flag: hosts that are patched-on-disk but running an older kernel show as "patched, pending reboot" instead of hiding behind a green check.
- Scope it: before anything runs, ArcScan computes the update impact: the reverse-dependency closure of the package mapped to the services actually running on that host, so the approver sees the restart list rather than a version number. Hosts you are not allowed to touch can be excluded per run or by standing rule (vendor managed, risk accepted, false positive), or pinned instead with apt hold or dnf versionlock and reported honestly as pinned.
- Verify, then apply: ArcScan generates the fix as an Ansible playbook grouped per package, plus its rollback. The play runs in check mode against the real host first, a deterministic dangerous-operations linter reads the result, and only then does it reach an approver. For RHEL and Debian kernel packages the generated play includes a conditional reboot; in every other case ArcScan surfaces a separate, RBAC-gated reboot action on the pending-reboot banner rather than rebooting silently. Nothing applies until it clears the policy gate, the maintenance window, and a human.
- Prove it: remediations are recorded as fixed with a hash-chained audit trail and an HMAC-signed evidence bundle that verifies offline, and a post-apply scan confirms the CVE actually cleared. The Remediation Reliability dashboard reports patch success rate, MTTR by severity, and rollback counts from your own runs, so patching a fleet reads as measurable progress rather than data that vanished.
The other lie: a red dashboard that over-reports
The reverse failure is just as common and nobody talks about it. Remove a Python package badly and it leaves an orphaned .dist-info or .egg-info directory behind. Version-matching scanners read that metadata, conclude the vulnerable release is installed, and hand you a critical finding for software that is not on the box. ArcScan records those remnants as not installed and never matches them against a CVE, then generates a cleanup playbook that deletes them so your other scanners stop flagging them too.
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.
Do you let an LLM patch my kernel?
No. Every generated playbook carries a trust tier. Verified plays come from deterministic, registry-checked templates and are the only ones eligible to auto-apply, and only under a policy you write. Generated plays (the AI-written ones) are dry-run only and always require a human to read the diff. No-template findings are advisory and never execute at all.
Start a 14-day trial: 50 hosts, no card →