Hey @DmitriyLewen!

Thanks for creating an issue for it. I also thought of just checking for its' length, however it will still yield false positives for *.pyc files if there are arbitrary strings in between the BEGIN / END markers.

I think the proper fix (==no false positives) would be to parse the string and only report it as a private key if it actually is.

I skimmed through the codebase and it seems that rulesets rely on regexp validation only, so there is no way to insert a custom validator function (if there is then please point me to it).

Specifying a minimal length should help with the current state but won't be enough to eliminate false positives.

Hello @OverOrion
I have seen cases where examples use real secrets. So we will never be able to avoid all false positives.

We already have some allow rules to avoid examples, test secrets, etc. - https://github.com/aquasecurity/trivy/blob/main/pkg/fanal/secret/builtin-allow-rules.go

Using a secret length will also help to avoid false positives. At the moment I think this is all we can do.

For the remaining cases, Trivy has the ability to filter files and disable/create your own rules (for example, you can disable the default correctly and make your own taking into account your case)