Collector modernization proposal

[robbycochran]

Problem

Collector is a critical C++ eBPF security agent deployed on every stackrox-monitored node. It works, but two things make it expensive to evolve:

1. A vendored fork of falcosecurity-libs (753K lines, upgrades are often stalled because sinsp internals are coupled into ~27 files.
2. No automated dependency version tracking or CVE visibility for 19 source-compiled C++ libraries.

Assumptions

• The C++ is solid. Collector's own code (15K lines) is modern C++17 with clean abstractions
• Falco updates are a primary pain. The coupling between collector and sinsp internals makes upgrades feel risky and expensive.
• We want shared eBPF infrastructure. fact (Rust, Aya, LSM hooks) and collector monitor the same nodes. A shared C BPF process/network probe stack, validated under collector first as a RuntimeAgent implementation, could eventually serve both projects.
• Security hardening is needed Drop-privileges and self-hardening are needed.
• Changes stay inside collector. The gRPC contract with Sensor and the two-stream model (ProcessSignal + NetworkConnectionInfo) are unchanged. this isolation means collector can iterate and validate independently without cross-repo coordination.

---

Feature 1: Dependency Management and Security Posture

Modernize how collector manages C++ dependencies, close the CVE visibility gap, and complete the self-hardening initiative.

Epic: Reduce privileges and drop capabilities

• Launch using minimally needed capabilities.
• Capability drop after BPF loading (CAP_BPF, CAP_PERFMON, CAP_SYS_RESOURCE)
• Openshift specific SCC and SELinux configuration

Epic: Dependency Lifecycle

• Migrate submodule-compiled dependencies to vcpkg where feasible (yaml-cpp, googletest, civetweb, prometheus-cpp, gperftools, jsoncpp, valijson, uthash are candidates). vcpkg provides version pinning, baseline tracking, and a path to automated version bumps via Renovate's native vcpkg.json support.
• Generate CycloneDX SBOM covering all source-compiled deps for CVE scanning
• Automated CVE notification via osv-scanner in CI

---

Feature 2: RuntimeAgent Abstraction

Create a clean internal interface that decouples collector's event processing from falcosecurity-libs. This makes falco upgrades more mechanical and opens a substitution point for alternative backends.

Phase 1: Concentrate Falco Surface

Move all sinsp/scap/ppm includes and type usage from 27 files into 3-4 files within system-inspector/. Minimal to no behavior change intended. Today, sinsp types leak through public headers across the codebase. After this phase, only system-inspector/ internals know about falco.

Phase 2: Define and Implement RuntimeAgent

Introduce a typed event stream interface. One callback, events tagged by type (process exec, network connect, endpoint listen, credential change -- extensible). The runtime produces events; CollectorService routes them to the existing gRPC streams unchanged.

Wrap existing falco code behind this interface using two internal layers:

graph TD
    CS[CollectorService] -->|subscribes| RA[RuntimeAgent]

    subgraph SinspRuntime["SinspRuntime (implements RuntimeAgent)"]
        INS[SinspInspector — event loop, filtering, dispatch]
        FD[FalcoDriver — thin sinsp wrapper]
        INS --> FD
    end

    RA --> INS
    FD --> FALCO[falcosecurity-libs]

    RA -.->|"future"| MBR[ModernBpfRuntime — libbpf, LSM hooks]

Loading

SinspInspector contains collector's own logic: the event loop, event filtering, signal dispatch. This code survives any backend swap.

FalcoDriver is ~15 methods translating sinsp types to collector-owned types. The only file that #includes sinsp headers. Falco upgrades change this file only.

Phase 3: Upgrade Falco

With RuntimeAgent in place, upgrade the fork from 0.18 to 0.25.

---

What This Enables

The RuntimeAgent interface is the strategic asset. It enables three future paths without committing to any:

• Custom C BPF probes (libbpf + LSM/TCP hooks) as a ModernBpfRuntime, validated under collector's existing integration test suite, potentially shared with fact as a common process/network probe stack
• fact convergence where fact's Rust runtime implements RuntimeAgent, enabling a single node agent for process + file + network monitoring
• Easier falco upgrades where a version bump changes FalcoDriver instead of 27 files across every subsystem

Because all changes stay inside collector with no Sensor contract modifications, each phase can be validated independently through the existing integration test suite and shipped incrementally.

What's Not in Scope

• Changing the gRPC contract with Sensor
• Replacing falco with custom probes (enabled, not committed)
• Merging collector and fact binaries (enabled, not committed)
• Language migration to Rust (enabled, not committed)
• Network policy or OVN monitoring
• Config surface cleanup (can happen independently)

[Molter73]

Thanks for the proposal @robbycochran, I'm onboard with it (mostly), but there are some points I want to make:

The C++ is solid. Collector's own code (15K lines) is modern C++17 with clean abstractions

I would argue there are still some things that need modernizing, but OK (I'm looking at you GrpcDuplex that could be completely replaced with gRPC's own callback API).

Epic: Reduce privileges and drop capabilities

* Launch using minimally needed capabilities.

* Capability drop after BPF loading (CAP_BPF, CAP_PERFMON, CAP_SYS_RESOURCE)

* Openshift specific SCC and SELinux configuration

Other than the capabilities being dropped, the other two points need to be addressed in the main repo, we don't own the k8s/openshift deployment. Also, I'm fairly certain the collector daemonset already has a dedicated SCC.

Migrate submodule-compiled dependencies to vcpkg where feasible (yaml-cpp, googletest, civetweb, prometheus-cpp, gperftools, jsoncpp, valijson, uthash are candidates). vcpkg provides version pinning, baseline tracking, and a path to automated version bumps via Renovate's native vcpkg.json support.

Haven't compiled with vcpkg for some time but this is already supported in the repo. The only reason we haven't made the full change is that vcpkg is not supported by hermeto and, by extension, it is not supported by konflux: hermetoproject/hermeto#729

Move all sinsp/scap/ppm includes and type usage from 27 files into 3-4 files within system-inspector/. Minimal to no behavior change intended. Today, sinsp types leak through public headers across the codebase. After this phase, only system-inspector/ internals know about falco.

This has always been the goal, the problem is that we will need "glue code" (specifically a collector owned type) that abstracts from falco without adding overhead when converting from something like sinsp_event to this new type. It can be done, but we will want this to be very explicit about it not making any additional allocations while also not breaking the falco internals (like moving a value that falco then attempts to free at a later point). We will probably want solid benchmarks to ensure this point.

CollectorService routes them to the existing gRPC streams unchanged.

This is not true of how the networking part works right now though. If you truly want to turn collector into something as simple as:

runtime event -> RuntimeAgent creates internal representation -> event is sent over gRPC

First you need to untangle the mess that NetworkStatusNotifier is. This will most likely also require changes to the gRPC interface, since sensor expects a diff of connections not a single connection per message, which means the initial hypothesis of Changes stay inside collector doesn't hold.

FalcoDriver is ~15 methods translating sinsp types to collector-owned types. The only file that #includes sinsp headers. Falco upgrades change this file only.

Mentioned this before, but just to drive the point home, this needs to be a zero cost abstraction, we cannot add overhead in this translation and we will need benchmarking for this.

Phase 3: Upgrade Falco

With RuntimeAgent in place, upgrade the fork from 0.18 to 0.25.

I thought we were in a rush to upgrade because of the verifier issues we are getting on Arm, how long do we expect this proposal will take to be approved and implemented?

Other than that, the proposal looks a bit too broad, a bit hand-wavey even. We probably want to split the two features to their own issues so we can focus a bit more and expand on some of the points in this comment.

[Stringy]

Also worth noting some previous docs/discussion on this subject:

Collector Data Source Expansion