Runtime Security Calculator

Detection score = coverage × 0.5 + latency score × 0.3 + precision score × 0.2 − CPU overhead percentage, where coverage blends node and workload coverage equally. Runtime security only works where the sensor runs, so coverage is half the score, and it only works if somebody reads the output, which is why precision and per-analyst volume are reported explicitly. Precision is scaled by ten because a 10% precision rate is genuinely respectable for behavioural syscall detection, unlike for a signature-based control.

Runtime detection is the last control between a container escape and a compromised node, and it fails in two predictable ways: a node pool that never got the DaemonSet, and four thousand alerts a day that nobody opens.

This calculator takes 10 inputs: Nodes in the fleet, Nodes running a runtime sensor, Workloads in scope, Workloads with runtime policy applied, Runtime rules enabled, Runtime alerts per day, Alerts worth investigating per day, Mean time from event to alert, CPU overhead of the sensor, Analysts triaging runtime alerts. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.

On things that never happen in a healthy container: a shell spawned inside a running pod, writes to /etc or a package manager executing, outbound connections from a process that should only listen, and reads of the service account token by anything other than the SDK. Those four families catch most post-exploitation and are naturally quiet.

Usually, in the 1–5% CPU range, and it is tunable — most of the cost is the breadth of the syscall filter and how much context is enriched per event. Measure it on your busiest node type rather than accepting a vendor figure, because syscall-heavy workloads such as build agents are the worst case.