Secret scanning
Gitleaks detects and prevents hardcoded secrets like passwords, API keys, and tokens in code.
Vortex doesn't 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. A clean install then reports no
findings, while Gitleaks still detects real secrets.
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 still runs and reports 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. That's the right tool for tracking an assessment.
It doesn't 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.