As has been pointed out already by @orbiton and @itsmpro92,
- Searching for jquery*.js files is not a truly effective solution for any JQuery vulnerabilities, because it’s very common for HTML content to load javascript files from remote sources (such as JQuery’s CDN) without hosting a copy of the file locally; and
- File searches should not be done in pure Relevance; I’ve worked with several customers who have left the clients completely unresponsive because they issue searches with ‘descendant files’ and ‘descendant’ inspectors to search entire hard drives.
What is needed to give the minimal visibility offered by searching for jquery*.js files, is a separate Task that can be executed one-time or on a schedule, and an Analysis to read the results of that scan.
By the way, that is an approach we leverage heavily in Bigfix Inventory – and if you have a BigFix Inventory license, a custom Signature is trivial to add there; if you don’t have Inventory you should consider it if this is a use-case for you.
If you must write your own though, I think probably the most recent versions of filesystem scans I’d reference are from the Spring Boot Vulnerability scans. I have write-ups at Spring Framework RCE Vulnerability – Current BigFix Actions
As part of that Spring scan content we produced scans for WIndows and Linux and an Analysis to read the results. Those are probably the cleanest content from which you could start, and revise it to match the files you want instead. You could probably just remove the portions about extracting .JAR files entirely and only base the results on the directory searches.
Windows Scan:
https://bigfix.me/fixlet/details/26932
Linux Scan:
https://bigfix.me/fixlet/details/26921
Analysis Results:
https://bigfix.me/analysis/details/2998672