GitGuardian alternatives: Gitleaks vs GitGuardian

General capabilities

(for both public and internal monitoring products)

Enriched interface and centralization of incidents

GitGuardian

Gitleaks

Rich UI with all data needed for investigation and remediation

Yes

-- No

InfoSec team view (global view)

Yes

-- No

Developer view (local view)

Yes

++ Yes (with GitHub actions)

← swipe left

Detection

Harvest candidates

Filter false positives

GitGuardian

Gitleaks

Regular expressions to match known, distinct patterns

Yes - Over %ndet% secrets detectors (API keys, database connection strings, certificates, usernames and passwords, ...)

++ Yes - Regex on characters chains + entropy filters

High entropy checks to match credentials without distinct patterns and enter “paranoid” mode

Yes, in combination with other techniques to get rid of false positives.

++ Yes, but high level of false positive. Entropy level can be customised by end user.

Contextual analysis

Yes. The context of a presumed credential can help a lot to filter bad candidates (e.g. the import of an API wrapper is a strong indicator of a true positive).

-- No

Credential validity checks

Yes, where feasible.

-- No

Dictionary of anti-patterns

Yes - Ability to exclude folders such as test folders and filter certain credentials like those containing "EXAMPLE" or "QWERTY" in them (placeholders).

++ Yes, manually for each rule you can specify an allowlist regex.

Feedback loop to constantly improve the algorithms

Yes. Approx. %secrets-scanned-in-a-day% alerts sent per day!

-- No

Sensitive File names

Sensitive filetypes raise specific alerts: policy breaks.

Ability to define custom detectors

Yes, but only through our support and if the detector can be deployed for all customers. Full ability to define custom detectors to be expected in H2 2021.

++ Yes

← swipe left

Implementation method

GitGuardian

Gitleaks

Instance Level

Yes

Org Level

Yes, native GitHub app at organisation level (simple integration)

Individual repository level

Yes, upon integration of a GHE organization, users can choose to:
- give access to only one repository in particular
- give access to all repositories (and the ones that will be created).

Secrets Detection API

Core detection engine can be used to scan any type of text files (Slack messages, Gdivre, Jira tickets, etc.) More information: here

← swipe left

Alerting

GitGuardian

Gitleaks

Real-time alerting

Yes

-- No

Email alerting

Yes

-- No

Splunk

Native integration

Integration with most common SIEMs or ITSMs

Yes

-- No

Slack alerting

Yes

-- No

JIRA

Native integration (Q4 2021)

Custom webhook to integrate anywhere

Available to push alerts (JSON output format)

GitLab Issues

Not supported

← swipe left

Incident Life Cycle Management

GitGuardian

Gitleaks

Collect and structure weak signals to prioritize incidents

Yes - For example, credentials containing “admin” or “prod” in their context can be prioritized.

Ability to assign incidents / mark them as resolved / etc.

Yes

-- No

Whitelisting

Yes - Whitelist credentials or folders such as test folders.

++ Yes

Grouping / deduplication of alerts

Yes - Multiple alerts related to the same leaked credential are grouped and can be resolved in a unified manner. No need to triage/resolve every single occurrence.

-- No

REST API

API to retrieve and update secrets incidents

← swipe left

Reporting

GitGuardian

Gitleaks

In app

Yes - Global Health Status, MTTD / MTTR, etc.

-- No

Data exporting

Yes - Enriched data can be exported in CSV format.

++ Yes (Only one scan at a time)

← swipe left

Security

GitGuardian

Gitleaks

SSO authentication

Yes

-- No

RBAC

Yes - Roles available: Owner / Manager (Admin) / Members.

-- No

Audit trail

Yes

-- No

← swipe left

Get a demo

Public monitoring product

(On top of general capabilities)

Monitoring

GitGuardian

Gitleaks

Monitor all GitHub public activity, at scale

Yes

-- No - You need to direct Gitleaks against repositories you know exist

Reliably filter public activity on GitHub that is linked with your company

Yes - We have the ability to match developers, source code and companies using a unique combination of heuristics. Contact us, we will show you our results for your company!

-- No

Identify and monitor developers’ personal repositories

Yes - This is where 80% of corporate leaks occur on GitHub.

-- No

← swipe left

Deployment
of the solution

GitGuardian

Gitleaks

Available in SaaS

Yes

-- No

Available On Prem

No - GitGuardian Public Monitoring scans only public data, thus on prem is often not a requirement for our customers.

Open source

← swipe left

Get a demo

Internal monitoring product

(On top of general capabilities)

Integration with the Version Control System

GitGuardian

Gitleaks

GitHub native integration

Yes - Integration at the GitHub Org level with the ability to select monitored repositories

-- No

GitLab native integration

Yes - Integration at the instance level on full perimeter or at the group level

-- No

Bitbucket native integration

Yes - Bitbucket Server/Data Center customer only

-- No

← swipe left

SDLC stage scanning capabilities

GitGuardian

Gitleaks

Pre-commit

Supported through GitGuardian Shield (view documentation here)

Pre-push

Supported through GitGuardian Shield (view documentation here)

Pre-receive

Supported but not recommended because "pre receive" can block developers and create friction

Post-receive

Yes, supported natively. Real-time incremental scanning.

CI pipeline

Natively integrates with GitLab pipelines, in addition to CircleCI, Travis CI, Drone CI...

Full historical scan

Yes, can be launched on-demand through the interface

← swipe left

Secure the SDLC and more

GitGuardian

Gitleaks

Detection API to integrate anywhere in the SLDC and the tools developers use

Yes - Integrate GitGuardian as a pre-commit or scan Slack messages for secrets using our API (that can be self-hosted)

++ Yes

← swipe left

“Shift left”

GitGuardian

Gitleaks

Put the developer in the loop

InfoSec can collect feedback from the developers directly in the dashboard and collaborate in order to remediate.

-- No

“Auto-heal” incidents

Developers have the ability to resolve certain incidents by themselves without involving InfoSec if not needed.

-- No

← swipe left