GitLab CI template for Gitleaks¶

This project implements a GitLab CI/CD template to detect and prevent hardcoded secrets in your Git repository with Gitleaks.

Usage¶

This template can be used both as a CI/CD component or using the legacy include:project syntax.

Use as a CI/CD component¶

Add the following to your .gitlab-ci.yml:

include:
  # 1: include the component
  - component: $CI_SERVER_FQDN/to-be-continuous/gitleaks/gitlab-ci-gitleaks@2.9.1
    # 2: set/override component inputs
    inputs:
      args: "--no-banner" # ⚠ this is only an example

Use as a CI/CD template (legacy)¶

Add the following to your .gitlab-ci.yml:

include:
  # 1: include the template
  - project: 'to-be-continuous/gitleaks'
    ref: '2.9.1'
    file: '/templates/gitlab-ci-gitleaks.yml'

variables:
  # 2: set/override template variables
  GITLEAKS_ARGS: "--no-banner" # ⚠ this is only an example

Understand¶

Gitleaks performs static analysis of your Git repository to find hardcoded secrets such as passwords, API keys, tokens, and other sensitive information.

It will scan commit history to identify secrets in previous versions of files as well as in the current codebase.

When run on merge requests, Gitleaks will run a quick analysis of added commits (i.e. the diff).
When run on branches, Gitleaks will run an analysis of all commits in the branch.

Dealing with findings¶

If Gitleaks finds hardcoded secrets, the job will fail and the findings will be displayed in the job log.

You should review the findings and take appropriate actions such as rotating the exposed secrets and storing new ones outside of the codebase (e.g. using project variables).

We recommend against rewriting Git history to remove the secrets that were already pushed, as this can cause issues for collaborators and does not prevent future leaks.

Once the secrets have been rotated or confirmed as false positives, you can mark the findings as resolved by adding a .gitleaksignore file to your repository. It should contain one fingerprint per line as reported in the job log.

`gitleaks` jobs configuration¶

Those jobs trigger a Gitleaks analysis (either on the complete repository, either on the current branch). They use the following configuration.

Input / Variable	Description	Default value
`image` / `GITLEAKS_IMAGE`	The Docker image used to run Gitleaks	`docker.io/zricethezav/gitleaks:latest`
`rules` / `GITLEAKS_RULES`	Gitleaks configuration rules to use (you may also provide your own `.gitleaks.toml` configuration file in your project).	none (uses default rules)
`args` / `GITLEAKS_ARGS`	Options for a full Gitleaks analysis (on master or develop branches)	`--verbose --redact`

In addition to a textual report in the console, this job produces the following reports, kept for one day and only available for download by users with the Developer role or higher:

Report	Format	Usage
`reports/gitleaks.native.json`	JSON	DefectDojo integration

Configuring Gitleaks rules¶

Here is how this GitLab CI template chooses the Gitleaks rules to use:

It first looks for a .gitleaks.toml file at the root of your project repository.
If not found, it uses the .toml file specified with the $GITLEAKS_RULES variable.
If not specified, default Gitleaks rules are used.

Your Gitleaks rule file can extend the default rules by using [extend] + useDefault = true as explained in the Gitleaks documentation