We Deleted the Rules Engine, On Purpose
The week we said the release was measured in days, we deleted the entire rules engine: 94,013 lines in a single commit, with nothing staged to replace it. Here is why we tore down the thing every SAST tool ships.
A week ago we wrote that the release was measured in days. Then we deleted the rules engine. Not refactored it, not trimmed it. Deleted it: 94,013 lines across 322 files, in a single commit, with nothing staged to replace it yet.
From the outside, a deletion that size the week before launch looks like panic. It was the opposite: the most deliberate decision we have made all year.
The rules everyone ships
Every static analyzer, ours included, has historically worked the same way. You hand-write a rule for a weakness, then you write it again for the next language, and again for the next framework. SQL injection in Python, then in Java, then in Go, each its own file, each re-deriving the same facts. It is the model the entire industry runs on, because for a long time it was the only model that scaled at all.
It scales the way a filing cabinet scales: every new language multiplies the drawers. Ours had grown through several generations of that, and it worked. It found real bugs. On BenchProctor, the independent benchmark whose answer key we do not control, the established commercial scanners land in the low single digits, and our old engine scored a notch above them. A humble result on a deliberately brutal test, and still ahead of the field.
And we deleted it anyway.
Why tear down something that works
Because “works” was not the standard. The per-language model has a ceiling built into its shape. The more languages you cover, the more places every single rule has to be maintained, and the wider the gap grows between the language you support best and the one you support least. We could feel that ceiling. Adding a new weakness class meant editing a wall of files. Every previous generation of our rule system had died against that same wall, and we were one commit away from shipping a fifth.
Shipping it would have meant putting our name on a design we already knew we would have to tear out later. That is the one thing we will not do.
Done is a standard, not a date
So the release moved. Not because we hit a blocking bug, but because we looked at the core and decided it was not good enough to be permanent. The date on the calendar is downstream of that decision, and it always will be.
What replaced it is the subject of the next few posts. The short version: one system that classifies against public standards instead of a rule per language, so coverage grows by addition rather than by copy-paste. The long version ships when it meets the bar.
Honest scope note
Deleting 94,013 lines is not a feature. It is the removal of a limit, and the work that makes it worth doing came after, not in the deletion itself. We are not claiming the new core is finished here, only that the old one is gone and the reason was deliberate. What we can prove, we will prove, against BenchProctor and in the field after release.
TheAuditor is in final commercial release preparation, and it ships when it meets our standard, not before. Subscribe on the main site for launch news.
Was this useful?