Feature Request: Ignore string filter

[ryanohoro]

I'd like a set of configurable strings to be ignored when tests are executed. I've found that the following strings cut down on false positives for things like hex and base64 chars definitions.

abcdefghijklmnopqrstuvwxyz
ABCDEFGHIJKLMNOPQRSTUVWXYZ
123456789

[GElkins]

Would also like to have this added. I am running into multiple instances of this. Especially when dealing with people who sign their commits with PGP

[ashmastaflash]

+1 Thoughts on having a yaml file like this?

ignore_strings:
  - "whateverignorethisstring"
  - "ignorethisonetoo
ignore_files:
  - "unit_tests_with_false_positives.py"

[ryanohoro]

I have PR #16 in for file ignore, it's a lazy .conf file format that uses fnmatch. But I'd be happy to merge the two features for files and strings. YML might be a better choice for this

[ashmastaflash]

I'm reconsidering the file match. Initial thought was to ignore .travis.yml and the like, because encrypted credentials look like real credentials to truffleHog.
That being said, it's not hard to imagine someone plugging in real creds in a .yaml file. Maybe should just stick with individual string whitelisting :-)

[buzzdeee]

instead of or additionally to the ignore_files, have a ignore_commitids:, so once a commitid is identified as false positive, it can be added to not show up every time.

[milo-minderbinder]

FWIW, I created #66 which adds --include and --exclude options for filtering by Git object path (similar to @ryanohoro's PR, but with added logic for inclusion patterns, and support for regular expressions [as opposed to globs]).

I feel strongly that some path filtering option should be provided, because string white/blacklisting is not going to be a scalable endeavor across a large organization, or very efficient or accurate in many scenarios for that matter. As a concrete example, repos to which devs have uploaded a .classpath file (which they should not do, but realistically it happens a lot) will contain high entropy strings that change from commit to commit, so it would not be possible to create a whitelist or blacklist string filter against issues found in that file.

Another example case in which devs are not in any way to blame is jmeter .jmx files, which should be tracked with the source, but are programmatically generated XML files with lots of high entropy strings that change every time an integration test is modified.

[apertureless]

+1 for this.

Some regex for ignoring strings / paths would be great as in bigger applications the tests/ generating a lot of false positive noise.

[dalvarezquiroga]

+1

How can I do, when I have false positive truffleHog, for example:

-----BEGIN RSA PRIVATE KEY-----

[scarolan]

One of the files in my repo is training material...about secrets management. It would be great to be able to whitelist these files!

[dustin-decker]

Hey there, we've just released the next major version of TruffleHog!

It doesn't support ignoring strings, but this is a good feature request.

It is a complete rewrite that scans more data sources and now supports detecting and verifying over 600 credentials. Please check it out when you can.

https://trufflesecurity.com/blog/introducing-trufflehog-v3

[jwenz723]

I would love to see a way to commit a suppression of a particular secret into the code next to the secret so that the suppression is auditable just like the original commit of the secret.

Tfsec has a great method of doing this documented here.

[james-callahan]

Is there any work in progress on this? As far as I can see, the only way to exclude a positive result is to ignore the entire file?

[timdittler]

I'm using a jq filter to this end. Integrated would be better, but it gets the job done.

[james-callahan]

I'm using a jq filter to this end. Integrated would be better, but it gets the job done.

Interesting idea! However hooking it up in CI will be a pain. Things to do would include:

• Finding a jq container to use; or adding it to the existing trufflehog container
• When using the json output, after filtering, transforming back into nice human readable output.

[TimKnight-DWP]

Would also love a way to flag false-positives inline (for audit), I'm testing adding this to a pipeline in git and it's flagging jobs-or-pipelines-run- as an unverified result, but simultaneously a fake SSH key is also unverified

 -----BEGIN OPENSSH PRIVATE KEY-----
blahblah
-----END OPENSSH PRIVATE KEY-----

So for testing I can't know if it'll correctly detect real SSH keys as verified, but nor can I remove the --only-verified flag from the scan because I know it'll flag incorrect vars

[zricethezav]

While this isn't top priority for our team, we're happy to review community PRs if someone wants to take a stab at it

[zricethezav]

After some review, we don't plan on supporting this feature. However, if you want to add to the list of stopwords feel free to add to one of the following:

• https://github.com/trufflesecurity/trufflehog/blob/main/pkg/detectors/badlist.txt
• https://github.com/trufflesecurity/trufflehog/blob/main/pkg/detectors/programmingbooks.txt
• https://github.com/trufflesecurity/trufflehog/blob/main/pkg/detectors/words.txt