Replies: 2 comments
-
I figured out the issue! Gitleaks uses a default rule set that might not cover all secret formats by default. Here's how to address this: Create or edit your
This tells Gitleaks to not use the default rules and rely on your custom configuration. If you want Gitleaks to run as a pre-commit hook (automatically checking for leaks before committing), you can set an environment variable pointing to your
|
Beta Was this translation helpful? Give feedback.
-
I discovered a possible bug in Gitleaks' behavior. After adding a password entry to a test file, removing it, and then adding it again, Gitleaks fails to detect the leak during subsequent scans. This suggests that Gitleaks might be caching some information about previously detected secrets. Has anyone else encountered this behavior? I'm curious if others have experienced this persistence issue. If so, is there a known solution or workaround besides disabling the default rules? |
Beta Was this translation helpful? Give feedback.
-
I'm having trouble getting Gitleaks to detect known passwords in my test commits.
I installed Gitleaks using the following script "bash <(curl https://gitlab.com/gitlab-com/gl-security/security-research/gitleaks-endpoint-installer/-/raw/main/install.sh)". This script created a folder ~/.gitlab-gitleaks which contains the Gitleaks executable.
Test Scenario:
Steps to Reproduce:
I've also tried adding a .gitleaks.toml file in the root directory (content not shown for security reasons), but it doesn't seem to make a difference.
Test File Content:
Pre-commit Hhook Content ( ~/.gitlab-gitleaks/hooks/pre-commit)
Explicitly setting the gitleaks.toml with --config does not help. Attached is the gitleaks.toml.
Do I need to configure Gitleaks further for it to detect these specific password formats? Thanks
gitleaks.txt
Beta Was this translation helpful? Give feedback.
All reactions