Thanks for your input. I think that including patterns from gitleaks would be a good idea. Seems like issues found by one of this patterns could be raised as Vulnerabilities. It seems that if any file matches the pattern then probability of potential leak is quite high. Maybe we could create a ticket for that to and introduce it in checks for all supported languages ? Or maybe we could create/extend a plugin that scans pure content of a file without a context of it’s language (if that’s possible).
This approach is great but does not cover cases where password is just a random string which is also the true in many cases. As you mentioned gathering all XPATHs for all popular frameworks would take a lot of time, and should be maintained quite often as number of frameworks grows.
I was thinking about creating a rule that will test all key-value pairs present in config files (like xml or JSON attribures). I would raise an issue only when key matches the the secret qualifier (lets say it would be a set of regex expressions that could indicate that this property might be a secret) and a value does not match placeholder regex (like ${…}, #{…}, {{…}}) - we could look for all major templating engines and ignore placeholders they use. I am aware that this still can raise some false positives, and in rare cases could ignore real secret leak but to be honest I do not see any better solution that could be implemented easily.
What do you think about approach like that?