We're evaluating VMware Carbon Black for our sales team. All endpoints are company-managed Linux laptops (Ubuntu 22.04 LTS) or macOS. No Windows. Team is fully remote, connecting through a WireGuard VPN to internal tools.
Primary requirement is strong, lightweight malware protection that doesn't break custom sales demo environments (mostly containerized). Need centralized reporting and policy enforcement.
Specifically for Carbon Black on Linux:
* How is the agent's resource footprint on developer-grade hardware?
* Does it play well with Docker/Podman, or does it cause filesystem locking issues on `/var/lib/docker`?
* Can policies effectively allow-list known demo containers without disabling protection entirely?
Current alternative is a basic ClamAV setup with custom signatures, which is becoming unmanageable. Carbon Black's cloud console seems attractive, but I need real-world feedback on Linux agent stability before committing.
I run MLOps for a 100-person fintech. We standardized on SentinelOne for ~200 Linux (Ubuntu, RHEL) and macOS endpoints last year, after trialing Carbon Black and CrowdStrike.
- **Agent footprint (Linux)**: Carbon Black's sensor was heavy, 400-600MB RAM idle and 5-10% CPU on agent updates. SentinelOne sits at ~250MB and negligible CPU. Both will impact battery.
- **Container runtime interference**: Carbon Black had known issues with `overlay2` filesystem locking, causing Docker/Podman hangs. Required path exclusions for `/var/lib/docker`. SentinelOne needed similar exclusions but caused fewer performance hits once configured.
- **Policy granularity**: You can allow-list specific container image hashes or paths with both. Carbon Black's policy engine is more complex, which slowed our rollout. SentinelOne's "Deep Visibility" lets you tag a running container as trusted.
- **Real cost**: Carbon Black came in at ~$65/endpoint/year. SentinelOne was ~$55. Both require a 50-seat minimum. Hidden cost is management time; Carbon Black's console required more tuning to avoid false positives on dev workloads.
My pick is SentinelOne for your use case, specifically for its lighter Linux agent and more straightforward policy creation for containerized environments. If your demo containers are highly volatile, tell us how often you build new images and what your tolerance is for adding hashes to an allow-list.
Prove it with a benchmark.
Those agent footprint numbers for Carbon Black on Linux are brutal, but they track with what I saw about 18 months ago. The real killer for a sales engineer's laptop isn't the average load, it's the 5-10% CPU spike during a signature update happening right in the middle of a live demo. I've had that kill a deal.
One thing you didn't mention about SentinelOne's path exclusions: if you're using rootless Podman, you have to remember to also exclude the user's local storage (`~/.local/share/containers`). Miss that, and you're back in filesystem lock hell, and your sales team will riot because their demo environment is frozen again.
The management time cost for Carbon Black is the real hidden tax. Their policy engine feels like it was built for a locked-down Windows shop, not for an environment where devs are constantly pulling new container images. Getting those allow-lists right took my team weeks of iterative tuning. SentinelOne's tagging is just less friction, even if it feels a bit less precise.