This article explains how secret scanning works on the Pricefx GitLab instance and what to do when your push is rejected because a secret was detected. It is intended for Configuration Engineers, Solution Architects, and anyone who pushes code to Pricefx GitLab repositories.
About Secret Scanning on Pricefx GitLab
Every push to the Pricefx GitLab instance is scanned on the server by a gitleaks pre-receive hook. The hook inspects the commits that a push introduces. If it finds a secret (an API key, token, private key, password, or other credential), it rejects the push before the secret is stored in the repository.
Detecting a secret at push time prevents the secret from entering git history. Removing a secret from git history and rotating the leaked credential afterwards costs much more effort. The scan runs centrally on the server, so it covers every repository and every user without any client-side setup.
The scanner currently runs in a monitoring phase: pushes with findings still succeed. Blocking enforcement starts after a transition period. The enforcement date is announced separately.
Push Rejected Because of a Detected Secret
The scan produces no output for pushes without findings. If your push introduces a secret, the push fails with a message similar to this example:
GL-HOOK-ERR: gitleaks: secrets detected on refs/heads/my-branch
GL-HOOK-ERR: - to suppress a known false positive, add a rule to .gitleaksignore in the repo
Select the section below that matches your situation.
Respond to a Real Secret Finding
Before you start, determine whether the secret has reached any other location (a build, a fork, logs, a backup, or a chat message). If it has, rotate the secret first.
-
Rotate the secret if it was exposed anywhere outside your local repository.
-
Move the secret to a secure store, such as a CI/CD variable or a secrets manager. Keep secrets out of source code.
-
Remove the secret from your local git history with an amend or rebase, then push again. Deleting the secret in a later commit is not sufficient because the secret remains in git history.
After the corrected push, the push succeeds without a gitleaks message.
Suppress a Test or Example Key
If the finding is a known fake key or test fixture, add a rule to a .gitleaksignore file in the repository. The rule suppresses the finding for all users of the repository. See the gitleaksignore section of the gitleaks documentation.
Report a False Positive
If the flagged content is not a secret and a .gitleaksignore rule is not practical, raise a support case in Salesforce. The case is routed to the Pricefx Security Operations team, which reviews the finding and arranges any scanner configuration changes.
Report a Scanner Error or Timeout
If the push fails with a scanner error message instead of a secret finding, the cause is an infrastructure issue on the Pricefx side. Raise a support case in Salesforce so that the issue can be investigated.
Skip Scanning for a Single Push
Use this option only in exceptional cases, because every skipped push is an unscanned push. Prefer fixing the finding or adding a .gitleaksignore rule. All skips are logged and auditable.
To skip the scan, include [skip-gitleaks] anywhere in the tip commit message of the push. The entire push is then skipped. Use this option only when the push is urgent, you confirmed that the finding is not a real secret, and a .gitleaksignore rule is not practical.
Contact and Support
For scanner errors, false positives, or questions about enforcement, raise a support case in Salesforce. Cases are routed to the Pricefx Security Operations team.