What is the difference between Falco’s normal runtime collection and gVisor-based collection?

Falco’s normal collection reads system calls from the host kernel through a kernel module or eBPF probe. With gVisor, Falco receives syscall information from the Sentry process over a Unix Domain Socket, then reconstructs events for the rule engine. The detection goal is the same, but the telemetry source and deployment model differ.

Why Falco Uses Two Collection Paths for the Same Detection Goal

Falco’s collection model changes because the runtime environment changes. On a standard host, Falco can observe system calls close to the kernel and build detections from native execution activity. In a gVisor environment, that direct kernel view is not available in the same way, so Falco has to consume telemetry from the sandbox boundary and reconstruct the event stream for rule evaluation. The practical difference is not the detection intent, but the trust boundary and fidelity of the telemetry source. For practitioners, that means collection choice affects visibility, deployment constraints, and what can be assumed about event completeness.

For teams comparing collection modes, the important question is whether the chosen source preserves enough process, file, network, and syscall context to support the rules they actually rely on. The NIST SP 800-63 Digital Identity Guidelines are not directly about runtime telemetry, but they are a reminder that assurance depends on the strength of the underlying trust mechanism, not just the downstream output. In practice, many security teams discover collection gaps only after they assume the same rules will behave identically across host and sandboxed runtimes.

How Normal Runtime Collection and gVisor Collection Diverge Operationally

Normal Falco collection is built for environments where the host kernel is the authoritative observation point. The collector can use a kernel module or eBPF probe to watch system calls as they occur on the node, which gives the rule engine direct, low-level telemetry. That model is usually the most straightforward when you need broad host coverage and consistent event semantics across workloads.

gVisor-based collection works differently because gVisor interposes a user-space kernel boundary between the workload and the host. Falco receives syscall information from the Sentry process over a Unix Domain Socket, then reconstructs events into a format the rule engine can evaluate. This makes the model suitable for sandboxed deployments where direct host-kernel collection is constrained, but it also means the collector is depending on the fidelity of the sandbox’s exported view rather than observing the host kernel natively.

Normal runtime collection is kernel-centric and generally reflects the host’s native execution path.
gVisor collection is sandbox-centric and reflects what gVisor exposes through Sentry.
Both support Falco’s detection logic, but they do not rely on the same telemetry plumbing.
Rule behaviour can differ if a rule expects event fields or execution context that are less complete in the sandboxed path.

For operators, the key implementation consideration is not whether one path is “better” in the abstract, but whether the collection mode matches the workload isolation model and the detections you care about. If the runtime abstraction changes the shape or timing of events, validation should happen against the exact workload class you plan to monitor. This guidance breaks down when teams assume parity between the two paths without testing the same rules against both telemetry sources.

Where the Runtime Choice Changes the Answer More Than the Rule

Tighter runtime isolation often improves containment, but it also introduces a tradeoff: the deeper the abstraction layer, the more you depend on that layer’s event translation rather than direct kernel observation. That matters when users expect identical visibility from host-based and gVisor-based collection, because the same rule may still be technically valid while becoming less informative or less complete in practice.

The most important edge case is portability. A rule set written around host kernel telemetry may need validation before it is treated as equally reliable in gVisor. Guidance here is framework-neutral in the sense that the operational question is about telemetry fidelity, not policy preference. Where consensus is limited, the safe assumption is that sandboxed collection should be evaluated as a distinct telemetry path, not as a drop-in mirror of native kernel collection.

Another variation is governance rather than mechanics: teams sometimes select gVisor because they need workload confinement first and observability second. In that case, Falco’s collection mode should be treated as part of the platform design decision, not as a bolt-on monitoring choice. The practical constraint is that the monitoring model inherits the runtime model, so visibility, event richness, and troubleshooting paths can shift together.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	8 — Audit Log Management	Falco is a runtime detection and logging control for execution events.
Recommendation — Monitor host and sandbox runtime events continuously and retain telemetry for investigation.
NIST CSF 2.0	DE.CM-8 — Monitoring for Unauthorized Personnel, Connections, Devices, and Software	The question is about runtime monitoring source and visibility differences.
Recommendation — Validate that the chosen runtime sensor preserves the monitoring coverage you depend on.
MITRE ATT&CK	T1003 — OS Credential Dumping	Falco runtime telemetry is often used to detect adversary actions on a host or sandbox.
Recommendation — Map observed runtime events to ATT&CK techniques and tune detections for the telemetry source.
OWASP Non-Human Identity Top 10	NHI-01 — Secrets and Credential Management	Runtime collection quality affects detection around processes handling secrets and credentials.
Recommendation — Track privileged runtime activity that may expose or misuse secrets during execution.

Practitioner Guidance

What to verify: Validate the exact Falco rules you depend on against both telemetry paths before declaring feature parity. Pay special attention to fields, event ordering, and any detection logic that assumes native host-level syscall visibility.

Decision rule: If the workload runs in a sandboxed runtime, treat gVisor collection as a distinct monitoring architecture and confirm that the loss of direct host-kernel observation does not weaken the detections you actually use.

What practitioners underestimate: Teams often focus on whether Falco “works” in both modes and overlook whether the resulting event stream is equally trustworthy for triage, correlation, and incident escalation. That distinction becomes material when alerts need strong execution context.

Practitioner takeaway: The right comparison is not “does Falco detect in both cases,” but “does this collection path preserve enough trustworthy runtime context for the decisions we need to make.”