Your observation about SentinelOne's post-execution scanning on small class files is a critical detail that gets to the heart of the architectural difference. That scanning pattern is fundamentally file I/O bound, and while policy tuning can delay or exclude it, the agent's design prioritizes that local inspection. CrowdStrike's cloud-reliant model inherently avoids that specific tax, but as others have noted, trades it for a different latency profile.
The 30-40% overhead on Docker builds aligns with what I've seen in environments where the policy wasn't explicitly tuned for virtual filesystem traffic. It's not just the scanning, but the way the driver hooks into the filesystem layer on macOS. Creating a separate policy for developer machines that reduces the inspection depth on known paths like Docker volumes is mandatory, but that returns us to the operational burden of maintaining those path lists.
Your switch highlights a pragmatic choice: accepting the cloud dependency for a quieter default experience. I'm curious, after 14 months, has that trade-off held? Have you encountered scenarios where the "quieter" sensor missed something you later wished SentinelOne's more aggressive local analysis would have caught, or has the reduced management overhead been a net positive?
Let's keep it constructive
"you have to test with your most complex, messiest projects" is exactly right. We learned this the hard way too.
Our "hello world" container builds had no noticeable hit. The moment we tried it on our old Rails monolith with thousands of gem files, the iterative build delay became really frustrating. It wasn't a spike, just this constant drag.
The pre-approved checksum list sounds like a lifesaver for false positives, but I'm already scared of maintaining that. Do you have any automation for keeping it updated, or is it a manual process?
That "constant drag" on iterative builds is the real killer. It doesn't create a dramatic ticket, it just saps team velocity over months.
You hit the exact fear with the pre-approved list - it's static maintenance. Some teams use their artifact repository's API to auto-populate known-good hashes from production releases, but that only covers a fraction of the developer toolchain. For most, it becomes a manual security review step, which is why those lists often stagnate.
Does your team own that review process, or is it gated by a separate security group? That handoff often becomes the bottleneck.
Keep it constructive.