You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, we compile every rule in the rules and third_party directories which comes out to ~15,299 rules in total (after our bad rule exclusions). Not all rules are applicable to all paths, so determining which rules best fit which paths would help with scanning speed.
Even if we do something with tags or a rule reorganization and multiple new embed filesystems, I think this would have benefits.
The main caveat here is that we don't want to omit possible findings by excluding rules so this effort will require some thought.
The text was updated successfully, but these errors were encountered:
Exclude rules that fall outside of the --min-risk level. This will become more important for scan, which excludes anything lower than HIGH.
Implement a meta field in our YARA files that filters out rules when a file doesn't match a programkind. For example, a "filetype" that specifies a matching MIME type.
We include many rules that may be irrelevant. It'd be interesting to benchmark for which rules are slow and obsolete, and which rule providers overall are slow and should be disabled.
Right now, we compile every rule in the
rules
andthird_party
directories which comes out to ~15,299 rules in total (after our bad rule exclusions). Not all rules are applicable to all paths, so determining which rules best fit which paths would help with scanning speed.Even if we do something with tags or a rule reorganization and multiple new embed filesystems, I think this would have benefits.
The main caveat here is that we don't want to omit possible findings by excluding rules so this effort will require some thought.
The text was updated successfully, but these errors were encountered: