When I set out to write detection rules for my SAST tool, I didn't start with a list of regex patterns. I started with the OWASP Top 10. That might sound obvious, but it matters. The OWASP Top 10 is the closest thing the AppSec world has to a universal curriculum. Every security engineer speaks it. Every compliance framework references it. When I map my rules to OWASP categories, I'm not just organising them — I'm making them legible to the people who will ultimately use them. This article is about the thought process behind translating OWASP into a machine-readable rule engine. Not just what rules I wrote, but why I wrote them the way I did, and where the tricky ones gave me the most trouble. The Rule Schema Every rule in the engine follows the same structure: - id : AUTHN-001 title : " JWT Algorithm None Attack Vector" description : " >" The application accepts JWTs with algorithm set to 'none', allowing attackers to forge tokens without a valid signature.…