Enable use of .gitignore for exclusions in filesystem scans

[bawgz]

Please review the Community Note before submitting

Description

The flag for --exclude-paths expects a file with line separated regexes to be provided. Most projects will have a .gitignore file with line separated glob patterns that would likely be the set of files you'd want excluded from a TruffleHog scan. It seems natural to accept a file with glob patterns as an exclusion list.

Preferred Solution

A new flag --exclude-paths-glob that takes in a file with new line separated glob patterns. These glob patterns can be read in, translated to regex using the glob package and included in the exclude Filter rules alongside any regexes coming from --exclude-paths.

Additional Context

N/A

References

N/A

[rgmz]

Most projects will have a .gitignore file with line separated glob patterns that would likely be the set of files you'd want excluded from a TruffleHog scan.

Typically the files you don't want to commit are the most likely to contain credentials — but I agree it would be useful.

[bawgz]

Most projects will have a .gitignore file with line separated glob patterns that would likely be the set of files you'd want excluded from a TruffleHog scan.

Typically the files you don't want to commit are the most likely to contain credentials — but I agree it would be useful.

Exactly. It's safe to exclude a .env file for example--which would contain secrets--from the Truffle Hog scan because it's in the .gitignore file and thus is not in danger of being committed to a remote repository.

[rgmz]

It's safe to exclude a .env file for example--which would contain secrets--from the Truffle Hog scan because it's in the .gitignore file and thus is not in danger of being committed to a remote repository.

Ah, but what if that wasn't always the case? What if it was only added to the .gitignore after someone accidentally pushed theirs?

This is a frequent mistake and source of leaks in my experience.

[bawgz]

Ah, but what if that wasn't always the case? What if it was only added to the .gitignore after someone accidentally pushed theirs?

This is a frequent mistake and source of leaks in my experience.

I don't think they should be using a filesystem scan if their concern is finding things that have already been pushed to a remote repository. I see the filesystem scan serving the purpose of preventing future leaks, whereas a git scan can help find and remediate past leaks.