LESSON 8 · RUNNING COVERAGE · 2 MIN READ

When to add a runtime sensor after agentless coverage

Short answer

Add a sensor where seeing activity changes a decision: internet-facing workloads, workloads that handle sensitive data, and clusters where vulnerability findings are too many to rank without knowing what runs. Leave the rest on agentless scanning until the first group is stable.

Start from the inventory

Once agentless coverage is complete, you know every workload, what it exposes and what it can reach. That list is the input for the sensor plan. Without it, sensor rollouts tend to follow whichever team says yes first.

Three groups that justify a sensor first

  1. Internet-facing workloads. They are where an attack starts, and a sensor can detect and, on several platforms, block activity that a scan only shows afterwards.
  2. Workloads that can reach sensitive data or administrative identities. They are where an attack path ends.
  3. Large Kubernetes clusters with long vulnerability lists. A sensor that reports which packages are executed, as Orca's and Sysdig's pages describe, shortens the list.

Groups that can wait

Short-lived batch jobs, development accounts with no production data, and workloads behind several layers of network controls can usually stay on agentless scanning for longer.

Use the platform you have, if it is enough

Most platforms here offer their own sensor: the Orca Sensor, the Wiz Sensor, Upwind's eBPF sensor, Sysdig's Falco-based agent. Microsoft Defender for Cloud provides runtime protection for servers through Defender for Endpoint. Using the same vendor keeps findings in one place. If runtime detection becomes the main need, compare runtime scores directly: on this site CrowdStrike and Sysdig score 9.6, Upwind 9.4 and Orca 7.6. The coverage calculator has a runtime-first preset.

Plan the rollout

  • One deployment path per workload type, tested on a single cluster or host group first.
  • Agreed resource limits with workload owners.
  • A rule for kernel upgrades, so the sensor and the kernel stay compatible.
  • A record of every workload that cannot carry a sensor, and why.

Measure the effect

Compare the length and accuracy of the fix list before and after the sensor on the same workloads. If it does not change what you fix, the sensor is buying detection and blocking rather than prioritization; decide whether that is what you need there.

Sources

Source: Orca Sensor (runtime) · Read 27 Sep 2026

Source: Wiz Defend and Wiz Sensor · Read 27 Sep 2026

Source: Microsoft Learn: Defender for Servers overview · Read 27 Sep 2026

Source: Sysdig Secure · Read 27 Sep 2026

Next lesson: Keeping cloud security coverage complete as the estate grows