Secret scanning
Gitleaks detects and prevents hardcoded secrets like passwords, API keys, and tokens in code.
Vortex does not install Gitleaks locally. Follow the instructions to install it on your system.
In CI, Gitleaks runs from its official Docker image as part of the security audit workflow.
Usage
gitleaks dir .
Configuration
Global configuration takes place in the .gitleaks.toml
file at the repository root (see the
configuration documentation).
It extends the default rule set with an allowlist for the placeholder values a
Drupal project template legitimately contains, so a clean install reports no
findings while real secrets are still detected.
Ignoring
To ignore a single line, add a gitleaks:allow comment to it:
$settings['example'] = 'not-a-real-secret'; // gitleaks:allow
To ignore a path or a recurring known-safe value across the codebase, add it to
the .gitleaks.toml file.
Continuous integration
Gitleaks runs in the security audit workflow by default and fails that workflow if there are any violations.
Ignoring failures
Set VORTEX_CI_GITLEAKS_IGNORE_FAILURE environment variable to 1 to ignore
failures. The tool will still run and report violations, if any.
➡️ See Ignore tool failures.
Where findings appear
In GitHub Actions, Gitleaks findings are also uploaded to the repository's Security → Code scanning tab under the gitleaks category. Each finding becomes an alert naming the rule that matched, located at the line it was found on.
➡️ See Code scanning.
Dismissing a finding
Dismissing an alert in the Security → Code scanning tab records a reason against that finding and removes it from the open list, which is the right tool for tracking an assessment.
It does not change what the scan does. Gitleaks still matches the value and still fails the workflow until the line carries a gitleaks:allow comment or the value is allowlisted in .gitleaks.toml, as described in Ignoring.