Proactively finding Guarded Script violations before the phases begin?

[tomato20250]

Hi everyone,

Our instance is about to be / has been upgraded to one of the releases that include Guarded Script (KittyScript). I've read KB2944435 (Server-Side Sandbox Runtime Replacement) and I understand how it works:

• The instance automatically records incompatible scripts in the Incompatible Guarded Scripts list, and the system creates automatic exemptions before each phase transition.
• However, in the "Why a Phased Rollout?" section, the article makes clear that only scripts that actually execute during a detection window are captured, and that no static scan can produce a complete list of affected scripts, since some scripts can originate at runtime (e.g., a javascript: expression passed as a URL filter parameter).

I fully understand this limitation and I'm not expecting to catch 100%. My goal is simply to minimize risk as much as possible: proactively find and fix as many scripts as I can up front (especially those that live in configuration records on the instance), and leave the small remainder (mostly the runtime-originated ones) to be handled by the phased rollout + exemption mechanism.

My questions:

1. Is there an official ServiceNow tool, or a community-recommended approach, to statically scan configuration records (filters/conditions on business rules, UI actions, reports, scheduled jobs, ACLs, etc.) in order to find scripts that are likely to violate Guarded Script?
   • Per the KB, the blocked constructs are: variable declarations (var/let/const), control flow (if/switch/for/while), function declarations, assignment operators (=), and multiple statements in a single script. The suspect areas also include: javascript: prefixes in filters/conditions or passed to addQuery(), code evaluated via GlideEvaluator/GlideScopedEvaluator with withEnforcedSecurity(true), and AMB/RecordWatcher conditions with complex expressions.
2. If no tool exists yet, does anyone have suggestions for building a custom script that scans the configuration tables to surface suspicious candidates (based on patterns such as containing ;, var , if(, javascript:, etc.) for manual review? (I'm aware this would produce false positives/negatives — I'd only use it to narrow down what needs reviewing.)
3. On a sub-production instance, beyond deliberately running infrequent workflows (quarterly/annual) so they get detected, are there any other best practices to help "force" more scripts to surface during Phase 1?

Thanks in advance.