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.
The gitleaks chart can be deployed via helm:
# Install HelmChart (use -n to configure another namespace)helm upgrade --install gitleaks secureCodeBox/gitleaks
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.
--password: Only for non-public repositories.
--config-path: The ruleset you want to use.
At this point we provide three rulesets which you can pass to the
/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.
Do not override the option
--report. It is already configured for automatic findings parsing.
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.
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 Configurationscanner: 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
# 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"
--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'.
--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".
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.
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
|cascadingRules.enabled||bool||Enables or disables the installation of the default cascading rules for this scanner|
|parser.env||list||Optional environment variables mapped into each parseJob (see: https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/)|
|parser.image.repository||string||Parser image repository|
|parser.image.tag||string||defaults to the charts version||Parser image tag|
|parser.ttlSecondsAfterFinished||string||seconds 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.backoffLimit||int||3||There 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.env||list||Optional environment variables mapped into each scanJob (see: https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/)|
|scanner.extraContainers||list||Optional additional Containers started with each scanJob (see: https://kubernetes.io/docs/concepts/workloads/pods/init-containers/)|
|scanner.extraVolumeMounts||list||Optional VolumeMounts mapped into each scanJob (see: https://kubernetes.io/docs/concepts/storage/volumes/)|
|scanner.extraVolumes||list||Optional Volumes mapped into each scanJob (see: https://kubernetes.io/docs/concepts/storage/volumes/)|
|scanner.image.repository||string||Container Image to run the scan|
|scanner.image.tag||string||defaults to the app version|
|scanner.nameAppend||string||append a string to the default scantype name.|
|scanner.resources||object||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.securityContext||object||Optional securityContext set on scanner container (see: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/)|
|scanner.ttlSecondsAfterFinished||string||seconds after which the kubernetes job for the scanner will be deleted. Requires the Kubernetes TTLAfterFinished controller: https://kubernetes.io/docs/concepts/workloads/controllers/ttlafterfinished/|
Code of secureCodeBox is licensed under the Apache License 2.0.
An Example for scanning all history of the multi juicer project on GitHub:
# SPDX-FileCopyrightText: 2021 iteratec GmbH## SPDX-License-Identifier: Apache-2.0 apiVersion: "execution.securecodebox.io/v1"kind: Scanmetadata: name: "scan-multi-juicer-example"spec: scanType: "gitleaks" parameters: - "-r" - "https://github.com/iteratec/multi-juicer" - "--config" - "/home/config_all.toml"
Another example for how to scan a private GitLab repository:
# SPDX-FileCopyrightText: 2021 iteratec GmbH## SPDX-License-Identifier: Apache-2.0 apiVersion: "execution.securecodebox.io/v1"kind: Scanmetadata: 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"
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
# SPDX-FileCopyrightText: 2021 iteratec GmbH## SPDX-License-Identifier: Apache-2.0 apiVersion: "execution.securecodebox.io/v1"kind: Scanmetadata: 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/"