### Problem As discussed in this [customer issue](https://gitlab.com/gitlab-org/gitlab/-/issues/560092), the [v7.10.0 release changes](https://gitlab.com/gitlab-org/security-products/analyzers/secrets/-/merge_requests/401) caused the analyzer to include `.git` directory during the scan, this unnanounced behavior disrupted customer workflow. While this can be perceived as a legitimate finding but the analyzer points at a non-existent location as [mentioned here](https://gitlab.com/gitlab-org/gitlab/-/issues/560092#note_2672133812). This issue aims to investigate this bug further and provide an appropriate root cause and resolution. ### Reproducible Steps 1. Create a dummy file with a secret inside `.git` directory of a project. 2. Run the scan on the project using `v7.10.0` analyzer version 3. You'll notice the analyzer identifying the secret in the dummy file. ### Expected Behavior The expectation is for the Analyzer to skip scanning `.git` directory ### Resolution Add `.git` directory in the `allowlist` field of Ruleset config. Read more details [here](https://gitlab.com/gitlab-org/gitlab/-/issues/560147#note_2678085296). ### Implementation Steps * [x] Release a new ruleset version containing `.git` in the allowlist path in [SD rules repository](https://gitlab.com/gitlab-org/security-products/secret-detection/secret-detection-rules) | [MR](https://gitlab.com/gitlab-org/security-products/secret-detection/secret-detection-rules/-/merge_requests/142) * [x] Bump the ruleset and `gitleaks` to the latest versions | [MR](https://gitlab.com/gitlab-org/security-products/analyzers/secrets/-/merge_requests/411)