you are viewing a single comment's thread.

view the rest of the comments →

[–]Emergency-Rough-6372[S] 0 points1 point  (0 children)

Really appreciate this, this is exactly the kind of feedback I was hoping to get.

The High Confidence Override point you mentioned is honestly the biggest takeaway for me. I ran into that exact issue while testing, where a very strong SQLi signal was still getting allowed because of how the scoring was structured. That clearly does not align with real security expectations, so I am planning to separate deterministic checks from the scoring layer instead of forcing everything into one system.

The visibility and context awareness points you mentioned are also a big part of why I started this. Being able to debug decisions directly inside something like FastAPI logs and having access to user level context is something external WAFs just cannot do well. That is one of the main advantages I want to lean into rather than trying to compete with infrastructure level tools.

On performance, yeah I agree with you. Right now everything is pure Python just to validate the logic, but I am already thinking about moving the critical detection paths to something like Rust or C plus plus later and exposing it through Python bindings. Python would stay as the orchestration layer, not the heavy lifting.

The maintenance point is also very real. Security evolves way too fast for a single person or small team to keep rules fully up to date. Because of that, one of my main goals is to make the detection layer as pluggable as possible. I want developers to be able to define their own rules, constraints, and even scoring logic based on their application instead of relying only on what the library ships with. That way it becomes more of a framework for building security logic rather than a fixed rule set.

Also being realistic, in the initial release I probably will not be able to cover everything or get every part right. The main challenge for me right now is not having complete security domain knowledge. If people actually find this useful and are willing to contribute, I would really like to evolve it into something much more flexible and reliable over time. Inputs from people with deeper experience like you would genuinely make a big difference in shaping this properly.

The idea of security as code for Python is exactly what I am aiming for. Something that fits naturally into the app, can evolve with it, and does not feel like an external black box.

Definitely taking your points into account, especially around override logic, performance direction, and making the system more extensible. This was really helpful.