Skip to main content

gitleaks


title: Gitleaks category: scanner type: Repository state: in progress appVersion: 6.1.2 usecase: Find potential secrets in repositories custom_edit_url: >-

https://github.com/secureCodeBox/secureCodeBox#main/edit/main/scanners/gitleaks/README.md.gotmpl

gitleaks logo

Gitleaks is a free and open source tool for finding secrets in git repositories. These secrets could be passwords, API keys, tokens, private keys or suspicious file names or file extensions like id_rsa, .pem, htpasswd. Furthermore, gitleaks can scan your whole repository's history with all commits up to the initial one.

To learn more about gitleaks visit https://github.com/zricethezav/gitleaks

Deployment

The gitleaks scanner can be deployed with helm:

# Install HelmChart (use -n to configure another namespace)
helm upgrade --install gitleaks secureCodeBox/gitleaks

Scanner configuration

For a complete overview of the configuration options checkout the Gitleaks documentation.

The only mandatory parameters are:

  • -r: The link to the repository you want to scan.
  • --access-token: Only for non-public repositories.
  • --username and --password: Only for non-public repositories.
  • --config-path: The ruleset you want to use.

Do not override the option --report-format or --report. It is already configured for automatic findings parsing.

secureCodeBox extended GitLeaks Features

info

If you run gitleaks based on a scheduledScan (e.g. one scan per day) it would be enough to scan all git-commits since the last executed schedule. Instead of scanning all commits in the complete git history every day it would save a lot of resources to scan only all commits of the last day.

Problem is: This is a feature and configuration option gitleaks is currently not supporting.

That's why we created an issue and a pull request for that. If you like the idea, please vote for our issue and PR.

If you already want to use our implementation (fork) of this feature you can use our gitleaks forked docker image instead of the gitleaks original image.

# Corresponding HelmChart Configuration
scanner:
  image:
    # scanner.image.repository -- Container Image to run the scan
    repository: docker.io/securecodebox/scanner-gitleaks
    # scanner.image.tag -- defaults to the charts version
    tag: v7.3.0

Deployment with extended GitLeaks

# Install HelmChart (use -n to configure another namespace)
helm upgrade --install gitleaks secureCodeBox/gitleaks \
  --set="scanner.image.repository=docker.io/securecodebox/scanner-gitleaks" \
  --set="scanner.image.tag=v7.3.0"

Additional (Fork) Scanner configuration options

--commit-since-duration= Scan commits more recent than a specific date expresed by an duration (now + duration). A duration string is a possibly signed sequence of decimal numbers, each
                               with optional fraction and a unit suffix, such as '300ms', '-1.5h' or '2h45m'. Valid time units are 'ns', 'us' (or 'µs'), 'ms', 's', 'm', 'h'.
--commit-until-duration= Scan commits older than a specific date expresed by an duration (now + duration). A duration string is a possibly signed sequence of decimal numbers, each with
                               optional fraction and a unit suffix, such as '300ms', '-1.5h' or '2h45m'. Valid time units are 'ns', 'us' (or 'µs'), 'ms', 's', 'm', 'h'.

Ruleset

At this point we provide three rulesets which you can pass to the --config-path oprtion:

  • /home/config_all.toml: Includes every rule.
  • /home/config_filenames_only.toml: Gitleaks scans only file names and extensions.
  • /home/config_no_generics.toml: No generic rules like searching for the word password. With this option you won't find something like password = Ej2ifDk2jfeo2, but it will reduce resulting false positives.

If you like to provide your custom ruleset, you can create a configMap and mount it into the scan. Checkout the examples for more information about providing your own gitleaks rules config.

Other useful options are:

  • --commit-since: Scan commits more recent than a specific date. Ex: '2006-01-02' or '2006-01-02T15:04:05-0700' format.
  • --commit-until: Scan commits older than a specific date. Ex: '2006-01-02' or '2006-01-02T15:04:05-0700' format.
  • --repo-config: Load config from target repo. Config file must be ".gitleaks.toml" or "gitleaks.toml".

Finding format

It is not an easy task to classify the severity of the scans because we can't tell for sure if the finding is e.g. a real or a testing password. Another issue is that the rate of false positives for generic rules can be very high. Therefore, we tried to classify the severity of the finding by looking at the accuracy of the rule which detected it. Rules for AWS secrets or Artifactory tokens are very precise, so they get a high severity. Generic rules on the other hand get a low severity because the often produce false positives.

Please keep in mind that findings with a low severity can be actually very critical.

Cascading Rules

If you want to scan multiple repositories from GitHub or gitlab automatically at once, you should take a look at the cascading rules which get triggered by the git-repo-scanner. For more information on how to use git-repo-scanner checkout the Readme.

For cascading scans on public GitHub repositories you don't need any credentials. For the gitlab and private GitHub rules you need to provide an access token via environment. You could do that with the following commands:

kubectl create secret generic github-access-token --from-literal="token=<YOUR-GITHUB-TOKEN>"
kubectl create secret generic gitlab-access-token --from-literal="token=<YOUR-GITLAB-TOKEN>"

For more information on how to use cascades take a look at Scanning Networks Example

Chart Configuration

KeyTypeDefaultDescription
cascadingRules.enabledbooltrueEnables or disables the installation of the default cascading rules for this scanner
parser.image.repositorystring"docker.io/securecodebox/parser-gitleaks"Parser image repository
parser.image.tagstringdefaults to the charts versionParser image tag
parser.ttlSecondsAfterFinishedstringnilseconds after which the kubernetes job for the parser will be deleted. Requires the Kubernetes TTLAfterFinished controller: https://kubernetes.io/docs/concepts/workloads/controllers/ttlafterfinished/
scanner.backoffLimitint3There are situations where you want to fail a scan Job after some amount of retries due to a logical error in configuration etc. To do so, set backoffLimit to specify the number of retries before considering a scan Job as failed. (see: https://kubernetes.io/docs/concepts/workloads/controllers/job/#pod-backoff-failure-policy)
scanner.envlist[]Optional environment variables mapped into each scanJob (see: https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/)
scanner.extraContainerslist[]Optional additional Containers started with each scanJob (see: https://kubernetes.io/docs/concepts/workloads/pods/init-containers/)
scanner.extraVolumeMountslist[{"mountPath":"/home/","name":"gitleaks-config"}]Optional VolumeMounts mapped into each scanJob (see: https://kubernetes.io/docs/concepts/storage/volumes/)
scanner.extraVolumeslist[{"configMap":{"name":"gitleaks-config"},"name":"gitleaks-config"}]Optional Volumes mapped into each scanJob (see: https://kubernetes.io/docs/concepts/storage/volumes/)
scanner.image.repositorystring"docker.io/securecodebox/scanner-gitleaks"Container Image to run the scan
scanner.image.tagstringnildefaults to the app version
scanner.nameAppendstringnilappend a string to the default scantype name.
scanner.resourcesobject{}CPU/memory resource requests/limits (see: https://kubernetes.io/docs/tasks/configure-pod-container/assign-memory-resource/, https://kubernetes.io/docs/tasks/configure-pod-container/assign-cpu-resource/)
scanner.securityContextobject{}Optional securityContext set on scanner container (see: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/)
scanner.ttlSecondsAfterFinishedstringnilseconds after which the kubernetes job for the scanner will be deleted. Requires the Kubernetes TTLAfterFinished controller: https://kubernetes.io/docs/concepts/workloads/controllers/ttlafterfinished/

Examples

multi-juicer

An Example for scanning all history of the multi juicer project on GitHub:

# SPDX-FileCopyrightText: 2020 iteratec GmbH
#
# SPDX-License-Identifier: Apache-2.0

apiVersion: "execution.securecodebox.io/v1"
kind: Scan
metadata:
  name: "scan-multi-juicer-example"
spec:
  scanType: "gitleaks"
  parameters:
    - "-r"
    - "https://github.com/iteratec/multi-juicer"
    - "--config"
    - "/home/config_all.toml"

private-repository

Another example for how to scan a private GitLab repository:

# SPDX-FileCopyrightText: 2020 iteratec GmbH
#
# SPDX-License-Identifier: Apache-2.0

apiVersion: "execution.securecodebox.io/v1"
kind: Scan
metadata:
  name: "scan-private-repository-example"
spec:
  scanType: "gitleaks"
  parameters:
    - "-r"
    - "https://gitlab.yourcompany.com/group/project"
    - "--access-token"
    - "<YOUR-GITLAB-TOKEN>"
    - "--config"
    - "/home/config_filenames_only.toml"
    - "--commit-since"
    - "2020-04-20"

provide-own-rules

If you don't want to use our predefined rule files you can easily provide your own gitleaks rules config file. Therefore create a configMap from your rules file.

kubectl create configmap --from-file /path/to/my/gitleaks-config.toml gitleaks-config

Now just mount that config in your scan and select the mounted path for your gitleaks --config option.

# SPDX-FileCopyrightText: 2020 iteratec GmbH
#
# SPDX-License-Identifier: Apache-2.0

apiVersion: "execution.securecodebox.io/v1"
kind: Scan
metadata:
  name: "scan-multi-juicer-with-own-rules"
spec:
  scanType: "gitleaks"
  parameters:
    - "-r"
    - "https://github.com/iteratec/multi-juicer"
    - "--config"
    - "/config/gitleaks-config.toml"
  volumes:
    - name: "gitleaks-config"
      configMap:
        name: "gitleaks-config"
  volumeMounts:
    - name: "gitleaks-config"
      mountPath: "/config/"