Jon,

I apologize for the lack of response.  Hopefully, the following addresses the concerns that you have raised.

Rule Security Analyzer does static scan of underlying java and/or html of a variety of rules like activities like activities, sections, and text files.  The scan uses regular expressions to find common high risk patterns that can cause issues like cross site scripting, SQL injection, and XML External Entity attacks.

While rule security analyzer is not run on rule check-in like guardrail warning checks, I believe that the rule security analyzer is run against our nightly core builds.  It may be worth looking into where the existing rule security analyzer work could be used to used to enhance the existing set of guardrail warnings in order to identify potential issues sooner.  The downsides would be that it would increase the time for rule check in, although I am unsure of the magnitude of the increase, and moving the rule security analyzer checks to the guardrail warning checks could also produce false positives since what is being checked for is a high risk pattern in the code, not a guaranteed issue.  Also, the findings cite the issue in terms of the java code that the rule is converted into rather than in terms of the rule itself.  This is not ideal for PRPC developers.

It would be easier if we could build the filter into the function instead of relying on developers to remember to use the filter and know which filter to use.  Unfortunately, there is no one filter that is ideal for all cases and also putting the filter in the function may cause existing functionality to break (rule analyzer is useful for identifying areas where the existing functionality should be updated).  Another advantage of having the filter functions separate from the input functions is the filters are defined only once and can be reused with the different methods of obtaining input.