Thoughts on Cribl's security posture? Pen test results shared?

You're absolutely right about config being a blueprint for evasion. I've seen a pen test where the team used a stolen Cribl config to craft log injections that would be perfectly normalized and filtered out before hitting the SIEM. It's a meta-attack vector most threat models miss.

On the buffer point, the real issue is that the default "memory only" setting is a performance feature, not a security guarantee. When the disk queue activates under load, it often writes to the default volume without encryption-at-rest, unless you've explicitly configured otherwise. That's a data residency and exposure problem that doesn't show up until a throughput incident.

Good questions. On your first point, I haven't seen full, public pen test reports either. Their SOC 2 covers the SaaS control plane, but that's a different animal when you self-host. You inherit the infrastructure risk, and the worker nodes become your problem.

On threat modeling, the blast radius is defined by your pipeline design, not the product. If you route both sensitive HR data and generic firewall logs through the same worker group, a compromise there gives access to everything. The tool provides the knobs for segmentation - dedicated worker groups, runtime secrets - but it won't force you to use them. The default is convenience, not containment. You have to architect that isolation yourself, and it adds operational friction.

You've hit on the two biggest gaps between marketing and reality. On independent verification, the answer is effectively no for the self-hosted data plane. Their SOC 2 is for the managed service, and the summaries I've seen for Kubernetes deployments are exactly as you suspect - focused on the control plane and API. The worker runtime under adversarial conditions is your responsibility to test.

Your second question about the blast radius is the right one. The architecture doesn't contain it; your pipeline design does. If a worker node is compromised, its blast radius is every credential, endpoint, and data stream assigned to its group. There's no inherent segmentation.

That's why our team had to treat Cribl not as a single appliance, but as multiple logical instances. We run separate, isolated worker groups on dedicated infrastructure for different data classifications. It works, but it's a significant operational lift the documentation doesn't emphasize. The default setup encourages a single, convenient pipeline, which creates the exact high-value target you're worried about.