rst13

Thanks for the detailed reply! I see custom policy/assertions on kernel behavior as powerful. As a current osquery user managing a fleet of 10k+ hosts (mostly Linux boxes) I find the query model resonates in terms of ux. We have a set of SQL pipelines that run on top of it at my org. osq works well for monitoring but not detections. So this direction is interesting, I'll forward to my detection eng folks

Intrigued by your "real-time kernel-level enforcement" (like freezing suspicious processes). Sounds powerful, but also risky—how do you prevent false positives from bringing down legitimate workloads? Is there a built-in policy tuning mechanism, or are users expected to rely on predefined MITRE detections as-is?

Thanks for the detailed reply! The arch and perf gains sound compelling.

It might be a bit early for benchmarks, but I'd be curious to see how argus compares vis-à-vis other ebpf-based introspection tools at scale, in terms of stability and coverage... Probably makes for a good blog post for some day.

Interesting take. I’ve been looking a lot into hardening build clusters for our dev teams. We’re a k8s shop and use a mix of egress controls, host isolation, and Falco for detections (although we’ve had stability issues running the sidecar architecture).

- How do you capture context from the builds beyond vanilla ebpf traces? is there a way to see the detection ruleset/customize it

- I’m generally wary of running ebpf stuff on prod infra. Whats the threat model for your tool?

I'd love to give this a spin, but browsing through docs it seems like listen.dev works on Github hosted runners right now. Is self-hosted support on the roadmap?

Unfortunately this is something large corps like AWS have been getting away with for a while now. Releasing half-baked product clones as GA when in fact they're still clunky and are probably beta at max.

I wonder how Netlify is doing in comparison

Great tool! Having used wireshark for ages, its refreshing to visualize binaries like this

I've been using Garnet with my k8s setup. They don't have native kube api integration and I suggest developing a controller. But right now you can use the CLI to append any commands or scripts in your docker containers to supply them env variables at build or run time.

E.g. in a Dockerfile … RUN garnet run --service-key=$GARNET_SERVICE_KEY -- npm start

If this container is running on k8s, you can supply $GARNET_SERVICE_KEY as a k8s secret mounted on the pod