Custom Detection Rules as Code in Sentinel Repositories: What Your Pipeline Owns Now

Thanks, Jamony. There are two points in your reply I want to pick up on.

I did not give the rule ID issue enough weight in the post. Since the id property uniquely identifies the rule, changing it in a PR would presumably create a new rule rather than update the existing one, potentially leaving the old rule behind. That creates a quiet duplication risk, and a simple CI check that blocks unexpected ID changes would catch it cheaply. Good catch.

On validation against a non-production workspace, I agree that live validation provides the strongest signal, but it has a blind spot worth calling out. It only validates against the tables and columns available in that environment, and the schema can drift from production in either direction. A connector that is missing in dev can make a valid production query fail, while a table or column already migrated in dev but not yet in production can allow a query that would fail in production to pass.

That is why I would pair live validation with a static check against a maintained deprecation list. The static check is environment-independent and can catch known issues such as the AIAgentsInfo retirement regardless of what a particular workspace currently exposes. I am sketching something along those lines at the moment.

Out of curiosity, how would you implement the live validation technically? Would you call the hunting query API with | take 0 appended, or use another approach? And if you get to the retired-table test before I do, I would genuinely like to see the result here. :)