Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ideate on selectively compiling rules based on the scanned paths #382

Open
egibs opened this issue Jul 27, 2024 · 1 comment
Open

Ideate on selectively compiling rules based on the scanned paths #382

egibs opened this issue Jul 27, 2024 · 1 comment

Comments

@egibs
Copy link
Member

egibs commented Jul 27, 2024

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.

@tstromberg
Copy link
Collaborator

Some thoughts:

  • 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants