Can regex detectors run without keywords?

[azrsamuel]

Hello,

First of all, thank you very VERY much for maintaining such a wonderful and useful tool!! 🙌

I’ve been experimenting with custom detectors via 'config.yaml' and noticed that keywords seem to be mandatory. For example:

detectors:
- name: IBAN detector
  keywords:
  - IBAN
  regex:
    token: (?i)\b[a-z]{2}\d{2}(?:[ -]?\d){21}\b

This works when the string "IBAN" is present in the code.
However, if I remove the keywords section, the scan doesn’t start and fails with:

error parsing the provided configuration file {"error": "no keywords"}

If I try to use a regex inside keywords, either I got an error or it is treated as a literal string and does not act as a regex.

The challenge is that in many real-world scenarios (IBANs, credit cards, etc.), these values often appear without any keyword nearby. Relying on keywords means maintaining huge lists of possible variations, and still missing many cases.

My question is:

• Is there a way to configure detectors so that the regex runs independently of keywords?

If not, would you consider supporting regex-only detectors, either by making keywords optional or allowing keywords themselves to be also regex patterns?

Thanks a lot for clarifying whether this is already possible, or if it makes sense to be considered as a new feature :)

[kashifkhan0771]

Hey @azrsamuel,
Thank you for raising this. Really appreciate your input.

The main reason we use keywords is to help narrow down the chunks we scan. For example, if you have a token with a predictable pattern like github_pat_<token>, then using github_pat_ as a keyword helps us filter the data to only the chunks that actually include that string. This makes scanning faster and more efficient.

Now, keywords become even more important when you're dealing with common regex patterns like [a-f0-9]{32} - that can match all sorts of unrelated data, leading to a ton of false positives and a heavy load on the engine. So by providing relevant keywords (e.g. abc_token for tokens from application ABC), you're giving the scanner context like, "only bother checking chunks that include this kind of thing." That allows the detectors to run on a much smaller, more relevant set of data.

Hope that clarifies things a bit.

As for your suggestion, we totally hear you. In my opinion, a custom detector should give users full flexibility, total control, but also full responsibility. I’ll bring this up with the team and we’ll see what can be done.