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 scanner can be deployed with helm:
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: The ruleset you want to use.
Do not override the option
--report. It is already configured for automatic findings parsing.
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.
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".
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:
For more information on how to use cascades take a look at Scanning Networks Example
|image.repository||string||Container Image to run the scan|
|image.tag||string||defaults to the app version|
|parseJob.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/|
|parserImage.repository||string||Parser image repository|
|parserImage.tag||string||defaults to the charts version||Parser image tag|
|scannerJob.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)|
|scannerJob.env||list||Optional environment variables mapped into each scanJob (see: https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/)|
|scannerJob.extraContainers||list||Optional additional Containers started with each scanJob (see: https://kubernetes.io/docs/concepts/workloads/pods/init-containers/)|
|scannerJob.extraVolumeMounts||list||Optional VolumeMounts mapped into each scanJob (see: https://kubernetes.io/docs/concepts/storage/volumes/)|
|scannerJob.extraVolumes||list||Optional Volumes mapped into each scanJob (see: https://kubernetes.io/docs/concepts/storage/volumes/)|
|scannerJob.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/)|
|scannerJob.securityContext||object||Optional securityContext set on scanner container (see: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/)|
|scannerJob.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/|
An Example for scanning all history of the multi juicer project on GitHub:
Another example for how to scan a private GitLab repository:
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.
Now just mount that config in your scan and select the mounted path for your gitleaks