Is your feature request related to a problem? Please describe.

We tried to integrate Gitleaks into Yocto / BitBake projects and found that the generic-api-key rule causes a massive number of false positives.

Specifically, the rule triggers because of high entropy values that are a direct result of standard BitBake file syntax referencing Git commits by their hash. See also their glossary, in particular the SRC_URI and the license tracking explanations.

Additionally, Yocto / BitBake projects usually contain a lot of Git patch files that are referenced throughout the build and are used to modify the upstream project code. These patch files also cause false positives because they contain Git commit hashes. This is, however, effectively a separate problem and could be tackled independently.

Example projects can be found here:

• Yocto base project: https://git.yoctoproject.org/poky
  The reference distribution of the Yocto Project, containing the OpenEmbedded build system, BitBake, and a set of metadata
• An additional layer project: git.yoctoproject.org/meta-virtualization
  This is a project that is integrated into the custom output artifact in terms of a "layer" adding additional support structures into the custom Yocto project

Example BitBake files:

.bb (same for .bbappend) file example from meta-virtualization:

# ...
SRCREV_moby = "43fc912ef59a83054ea7f6706df4d53a7dea4d80"
SRCREV_cli = "d41cb083c352853f94b292a87df4859c4a96dcc2"
SRCREV_FORMAT = "moby"
SRC_URI = "\
    git://github.com/moby/moby.git;nobranch=1;name=moby;protocol=https;destsuffix=${GO_SRCURI_DESTSUFFIX} \
    git://github.com/docker/cli;nobranch=1;name=cli;destsuffix=git/cli;protocol=https \
    file://docker.init \
        file://0001-cli-use-external-GO111MODULE-and-cross-compiler.patch \
        file://0001-dynbinary-use-go-cross-compiler.patch;patchdir=src/import \
        file://0001-check-config-make-CONFIG_MEMCG_SWAP-conditional.patch;patchdir=src/import \
	"
#...

Example .patch from Yocto / poky:

@@ -3,13 +3,6 @@

@@ -1 +1 @@
-{"files":{"Cargo.toml":"32a7c9ac508dc33ad03b44010f7cd1bb3592fd069e9e0b9caffd909ff2795184",

Describe the solution you'd like

We have currently the following .gitleaks.toml to prevent some of the issues, particularly with the BitBake files:

title = "Gitleaks Config to prevent Yocto false positives"

[extend]
useDefault = true

[[rules]]
# extend the generic API key rule to exclude the Git Patch format from being a problem
id = "generic-api-key"

[[rules.allowlists]]
description = "Ignore some contents of Git patches because they are false positives containing Git commit hashes, not secrets"
condition = "AND"
regexTarget = "line"
regexes = [
    '''(\+|-){"files":.+}'''
]
paths = [
    '''\.patch$'''
]

[[rules.allowlists]]
description = "Ignore BitBake SRC* keywords because they are false positives containing Git commit hashes, not secrets"
condition = "AND"
regexTarget = "line"
regexes = [
    '''SRC[^=]*=\s*"[a-zA-Z0-9]+"'''
]
paths = [
    '''\.bb$''',
    '''\.bbappend$''',
    '''\.bbclass$''',
    '''\.inc$''',
]

[[rules.allowlists]]
description = "Ignore BitBake LICENSE and LIC_FILES_CHKSUM keywords because they are false positives license names or hashes of license files, not secrets"
condition = "AND"
regexTarget = "line"
regexes = [
    '''LICENSE[^=]*=\s*"[^"]+"''',
    '''LIC_FILES_CHKSUM[^=]*=\s*"[^"]+"''',
]
paths = [
    '''\.bb$''',
    '''\.bbappend$''',
    '''\.bbclass$''',
    '''\.inc$''',
]

This gets rid of a lot of the false positives already.

We would like to see these allowlist overrides added to the default configuration of Gitleaks to prevent false positives for Yocto / BitBake projects in general.

Additionally, the Git patch rule is very much incomplete and doesn't cover all cases. We/I haven't investigated much further on that front yet. It is probably a good idea to tackle that separately from Yocto / BitBake specific syntax exceptions.

Describe alternatives you've considered

We could probably try to add such a custom config to all our projects but the communications overhead etc. doesn't appear worthwhile if there's a chance the default rules of Gitleaks can be improved instead.

Not scanning Yocto / BitBake projects with Gitleaks is probably a thing to think about, however, we have organisational constraints that make opting out of checks like secrets scans with Gitleaks difficult to impossible for us.

Additional context

I can try to create a PR for this, if it makes sense.

If there is anything I missed, or if there is a problem with this approach, please let me know. I would also be interested in alternative approaches.

cc @zricethezav