I'm going to say something that might ruffle some feathers in the detection engineering community. I wasted years optimizing for the wrong problem.
I was a detection engineer and like a lot of people in this space, I reached a point where I realized our detection workflow was a mess. Rules were scattered across SIEM consoles, there was no version history, no peer review, and no way to know if a rule we shipped last Tuesday was still working this Tuesday. The answer seemed obvious: put everything in GitHub.
So that's what I did. I set up the repos, wrote CI/CD pipelines, fought with YAML configs and built PR workflows. I wired up linters, wrote custom sync scripts to push rules back to the SIEM, and spent my weekends debugging why a pipeline broke because someone changed a field name in a log source.
And honestly? It kind of worked.
We had detections in GitHub. We had version control and pull requests. I could point at the whole setup and say "we do detection as code." It looked great on a slide.
But I still couldn't answer the most basic question my leadership asked me: are our detections actually working?
The Problem Behind the Problem
Here's what I eventually realized. GitHub was never the outcome I needed, it was a means to an end and I'd confused the two.
What I actually wanted was confidence. I wanted to know that my detections were validated, that they had unit tests proving they'd fire on the right data, that I had quality metrics I could report on, and that I wasn't carrying a pile of broken rules creating blind spots in our coverage.
GitHub doesn't give you any of that. GitHub gives you a place to store files and a workflow to review changes. Everything else, the testing, the validation, the quality scoring, the coverage analysis, all of that I had to build myself. And I was spending more time maintaining that custom infrastructure than I was spending on actual detection engineering.
I'd basically become a software engineer who happened to work in security instead of a detection engineer who had good tooling.
The Uncomfortable Truth About Detection as Code
Detection as code is the right idea. Version control, peer review, testing, automation, all of these principles genuinely make detection programs better and I still believe that.
But somewhere along the way the community started treating GitHub as the destination rather than a vehicle. We started measuring maturity by whether detections lived in a repo instead of whether those detections were actually good. Having a GitHub repo full of detection rules that you can't validate is just a more organized version of the same mess you had before.
I've talked to dozens of detection teams since starting Rilevera and the pattern is almost always the same. They spent months building the GitHub pipeline and they're proud of it, which they should be because it's hard work. But when I ask "how many of your rules are currently broken?" the room goes quiet. When I ask "what percentage of your rules have unit tests?" it gets quieter. And when I ask "how do you measure detection quality over time?" total silence.
That's not a GitHub problem. GitHub is doing exactly what it's supposed to do. It's a gap in what we've been building around GitHub.
What Detection Engineers Actually Need
The outcome detection engineers care about, or should care about, is pretty straightforward. They want validated detections that they know are working, with tests that prove it, and metrics that track quality over time.
That means continuous rule validation, not just a CI check that runs on commit. It means unit testing that doesn't require you to write custom frameworks from scratch. It means quality scoring that gives you and your leadership a real number instead of a gut feel. And it means peer review workflows that are purpose-built for detection logic, not borrowed from software development and jammed into a security use case.
Some teams have built impressive custom tooling on top of GitHub to get pieces of this. I respect that work because I used to be one of those people. But I also know the cost. Every hour you spend maintaining that plumbing is an hour you're not spending writing better detections.
Where Rilevera Fits
This is why I built Rilevera. Not to replace GitHub, plenty of our customers use GitHub and that's completely fine. But to deliver the outcomes that detection engineers were trying to get to through GitHub without requiring them to build and maintain software infrastructure to get there.
All the detection as code outcomes you want, version control, peer review, unit testing, quality metrics, continuous validation, without asking detection engineers to become DevOps engineers first.
The goal was never a prettier repo. It was detections you can actually trust.
